A language component is not a multilingual service: an India release review

A multilingual demonstration can sound convincing while the service around it remains unusable. A clean recording is transcribed; a short sentence is translated; a selected page is read by OCR; a synthetic voice returns an answer. None of those moments establishes that a citizen or employee can complete the intended task when audio is noisy, scripts are mixed, a name is transliterated, a document table is damaged, an API rejects the request, or the user needs assisted support.

The release decision must therefore be framed around the journey rather than the component. Selecting a speech, translation, synthesis, or OCR capability is not evidence that a multilingual service works for a defined task, language variety, channel, user group, and failure condition. The evidence has to connect the user’s intent to the final system action, including clarification, authorization, backend state, accessibility, handoff, monitoring, and recovery.

The Digital India Corporation Bhashini page provides official context for four technology areas: automatic speech recognition, machine translation, text to speech, and optical character recognition. That is a useful vocabulary for decomposing a system. It is not a promise about a particular language, dialect, domain, model, endpoint, latency, or customer workflow. The Bhashini portal was reachable when this draft was prepared, but its directly fetched response was only a small JavaScript shell. This review therefore makes no detailed portal-feature or access claim.

Freeze one service journey before comparing components

Begin with one verb that a user is trying to complete: submit an application, understand a status, search a document, correct a record, book an appointment, or transfer to an agent. Record the entry channel, expected language choices, identity state, source systems, final write or decision, and acceptable exits. “Supports Indian languages” is too broad to test. “A caller can provide a reference number in this channel, confirm the retrieved record in this language context, and reach an agent without repeating the interaction” is testable.

Draw the journey as a sequence of state changes. A voice flow may include consent or notice playback, speech capture, language or locale selection, transcription, intent extraction, entity confirmation, authorization, a business API call, response composition, speech synthesis, and a completion record. A document flow may include upload, malware checks, page classification, OCR, layout reconstruction, field confirmation, rule evaluation, storage, and human review. Translation can appear in either path, but it does not remove the need to preserve the authoritative original and identify which representation drove the system action.

Each transition needs an owner and a failure exit. If language detection is uncertain, does the service ask rather than guess? If the back-end record is unavailable, does it explain that state without fabricating an answer? If a name or number is ambiguous, can the user confirm it through a different modality? If the service transfers to an agent, does the agent receive the approved context and current transaction state? The component shortlist comes after these questions, not before them.

Treat language technology as replaceable boundaries

The four areas named by DIC should be modeled as interfaces with explicit inputs, outputs, uncertainty, and retention behavior.

Speech recognition receives audio shaped by microphone quality, codec, background noise, speaking rate, accent, dialect, names, numbers, and code-switching. Store enough test evidence to reproduce a failure without retaining more personal audio than the customer’s approved policy allows. A transcript confidence value is not a release verdict; errors in a reference number may matter more than several harmless filler-word differences.

Machine translation can change terminology, named entities, politeness, negation, dates, units, and legal or procedural meaning. Preserve source and translated text with version information when the workflow requires audit. Product and language reviewers should maintain approved terms and examples for the specific domain. Machine output should not silently become authoritative policy wording.

Text to speech must be assessed for intelligibility, pronunciation, pacing, abbreviation handling, interruption, and replay in the real channel. A pleasant sample voice does not show that a long identifier can be checked accurately or that a user can navigate with assistive technology.

Optical character recognition is only one stage of document understanding. Page rotation, scans, stamps, handwriting, tables, columns, mixed scripts, and low contrast can alter structure even when many characters look correct. Field-level confirmation and page references matter when extracted values trigger a consequential action.

Keeping these boundaries replaceable prevents one provider’s response format from spreading through the service. It also allows the team to compare components against the same task set rather than redesigning the evaluation for each candidate.

Build an acceptance matrix from real variation

A single average accuracy figure hides the failures that matter. The test set should be stratified by the dimensions that change the journey, using examples the customer has approved for evaluation.

Start with the downloadable service-release case register. Keep the working copy inside the customer’s approved evidence store; the public file contains headings only. Create one row for each task, language context, channel, input condition, business-state response, and safe-failure case. A test summary without stable case IDs cannot support a release decision.

Record results at the task and critical-field level. For a status enquiry, successful completion and correct record selection may matter more than verbatim transcription. For document intake, the decisive measure may be whether required fields were extracted, confirmed, and tied to the correct page. For a translation-assisted journey, reviewers may need to inspect whether the intended instruction survived, not merely whether two sentences appear similar.

Each case row must contain enough information for another reviewer to reproduce and classify the result:

Use blocker classes that identify the correction path: meaning-or-critical-field, capture-or-document-quality, integration-or-state, authorization-or-data-handling, accessibility-or-fallback, operations-or-ownership, or evidence-gap. A blocked case means the test could not establish a result; it is not a pass.

Do not publish a universal threshold. Each owner should define which errors block release, which require assisted handling, and which are acceptable for the specific use. The decision record should include the test-set version, component version, configuration, prompt or terminology version, environment, result, exception rationale, and approver.

Exercise code-switching, terminology, audio, and document damage

The test set should contain difficult but plausible conditions instead of being built only from ideal examples. Include utterances that move between languages, names spoken in one language inside a sentence in another, abbreviations, domain terms, regional pronunciations, and numbers expressed in different forms. For audio, vary noise, clipping, distance, silence, interruption, and poor network encoding. For documents, vary scan angle, compression, tables, multi-column layout, seals, faint text, handwriting, and mixed-script pages.

A failure taxonomy is more useful than a pile of anecdotes. Tag whether the issue arose in capture, language identification, recognition, translation, synthesis, OCR, layout recovery, intent mapping, entity extraction, business rules, API integration, or user-interface state. The same visible symptom can have different causes. Replacing the speech model will not fix a duplicate API request; changing OCR will not fix a field mapped to the wrong back-end property.

Language and domain reviewers should inspect examples selected for impact and representativeness. Their corrections must enter the evaluation corpus through a controlled process: source, approval, version, and allowed use should be recorded. User conversations or documents should not be copied into a test set merely because they are convenient.

Make API and identity state visible

A multilingual layer does not own the business truth. The authoritative status, eligibility rule, appointment, account, or application remains in the relevant system. The integration boundary should carry a stable request identifier, authenticated identity or session state, authorized scope, schema version, idempotency behavior, timeout policy, and machine-readable error. The NeGD API Setu page is public context for interoperability and controlled exchange, but it does not grant access to any interface or establish that this design is required.

Test the language experience when the business API rejects a field, returns no match, times out, or reports a conflict. A polished translation of an invented success message is still a service failure. User-facing wording should be derived from the actual state and should preserve a route to clarification or assisted handling. Logs need to connect the language-component call to the business transaction without exposing raw content more broadly than the customer has approved.

Version interface contracts independently from language prompts and terminology. A back-end schema change can invalidate entity mapping while every component health check remains green. Contract tests should run alongside the language acceptance set before release.

Design assisted fallback as a first-class path

Fallback is not a disclaimer at the end of a script. Define when the service asks the user to repeat, switches modality, offers language selection, narrows the task, or transfers to a person. Preserve only the context the receiving channel is authorized to use, and show the user what will happen. An agent should receive the confirmed language, completed steps, outstanding question, and relevant reference—not an opaque model transcript with uncertain content.

The NeGD UX4G page provides official context for citizen-centred and accessible digital-service design. It does not certify a journey. Accessibility review must test keyboard operation, focus order, screen-reader labels, captions or transcripts where appropriate, contrast, timing, error recovery, language declaration, and alternatives to voice-only interaction against the actual interface and user needs.

Track transfers, abandoned loops, repeated clarifications, and manual corrections as service signals, not as evidence that users are the problem. Reviewers should determine whether the system is failing disproportionately for a language context, channel, or task and whether the safe action is retraining, configuration change, journey redesign, narrowed scope, or temporary withdrawal.

Put monitoring and ownership around the full path

Component uptime cannot describe journey health. Monitor completion state, critical-field confirmation, clarification loops, fallback rate, business-API failures, authorization denials, latency by stage, and unresolved handoffs. Segment carefully enough to diagnose language and channel behavior while applying the customer’s approved privacy and retention rules. Do not turn sensitive attributes into an unrestricted analytics dimension.

Name owners for the journey, language review, component configuration, back-end contract, accessibility, security, privacy, incidents, and release. Define who can disable one language path, route traffic to assisted support, roll back a component version, correct terminology, and approve its return. A degraded journey should have a visible operating state rather than continuing because each vendor endpoint reports healthy.

Sign a release decision for one multilingual journey

The downloadable release decision record is the cover sheet for the evidence pack. Complete one row for one named journey version. Counts and exception IDs must reconcile with the case register; a slide summary or meeting note is not a substitute.

A reviewer should not sign until the records show, rather than merely assert, that:

• the task and authoritative system action are unambiguous;
• language, script, dialect or code-switch, channel, difficult-input, and accessibility cases have stable IDs in the approved test set;
• critical names, numbers, dates, terms, and document fields are evaluated by impact;
• clarification, correction, opt-out, modality change, and assisted handoff preserve the approved state;
• authorization failures, API errors, duplicate requests, timeouts, and version changes produce truthful user-visible behavior;
• raw audio, documents, transcripts, translations, prompts, logs, and corrections follow approved access and retention instructions;
• a failed outcome can be traced across capture, language components, business interfaces, and handoff; and
• blocking cases, accepted exceptions, owners, rollback actions, and revalidation triggers are recorded.

Approve-with-conditions is not permission to hide failed or blocked cases. Every condition must point to a case or exception ID, state the permitted scope, name an owner, and expire or trigger review. If the evidence cannot establish a safe outcome for a required case, the decision is do-not-release for that scope until the gap is closed and retested.

The decision applies only to the named journey and versions in the record. It must not be converted into a blanket statement that a component, language, or platform is “supported.” The defensible claim is smaller: a defined journey version was reviewed against a named test set and operating boundary, with its conditions and unresolved exceptions visible.