Chapter 5: Multilingual ASR

Speech Recognition — WIA-AI-ASR-001

BCP 47 + RFC 5646 language tags, code-switching per Anuj Diwan + Rakesh Vaideeswaran + Sanket Shah + Ankita Singh + Srinivasa Raghavan + Shreya Khare + Vinit Unni + Saurabh Vyas + Akash Rajpuria + Chiranjeevi Yarra + Ashish Mittal + Prasanta Ghosh + Preethi Jyothi + Kalika Bali + Vivek Seshadri + Sunayana Sitaram + Samarth Bharadwaj + Jai Nanavati + Raoul Nanavati + Karthik Sankaranarayanan 2021, Whisper Large-v3 per OpenAI 99-language coverage.

This chapter elaborates on the Multilingual ASR portion of Speech Recognition (WIA-AI-ASR-001). The speech recognition canonical envelope shape, API surface, and protocol exchanges are designed to interoperate across implementations published under the WIA Standards family. Each Phase file in `spec/` documents one architectural layer (envelopes, REST surface, federation, ecosystem) and the present chapter focuses on the multilingual asr subset of that layering.

Implementations of multilingual asr need to reconcile the per-standard expectations of ISO/IEC 22989:2022 (AI concepts), ISO/IEC 23053:2022 (AI ML framework), W3C Voice Browser Working Group SRGS 1.0, W3C Speech Recognition API draft, ITU-T P.863 POLQA. The Phase 1 envelope class for Speech Recognition carries the per-host identifier and per-tenant identifier so that audit records can be reconstructed across hosts that federate through the Phase 3 protocol layer.

Operators stepping into multilingual asr typically follow this trajectory: stand up the reference simulator at `simulator/index.html`, walk the canonical envelope per the CLI helper at `cli/speech-recognition.sh envelope`, then exercise the Phase 2 endpoints with curl/Postman against a host running the reference container at `wia/speech-recognition-host:1.0.0`. Once those steps complete, integrators wire the real backend one endpoint at a time per the Phase 1 §A.* envelope catalogue and the Phase 2 §B.* endpoint catalogue.

A common operational concern in the multilingual asr space is observability. Every Phase 1 envelope SHOULD emit a structured log line at the host's audit transport with: timestamp per RFC 3339, host identifier, tenant identifier, envelope class, envelope identifier, operation outcome, and a W3C Trace Context `traceparent` propagated end-to-end. Phase 2 surfaces this trace identifier as the `X-WIA-Trace-Id` response header. Phase 3 protocol exchanges propagate the trace identifier inside the exchange envelope so that a federation crossing remains correlatable end-to-end.

The multilingual asr portion of the standard composes with: WIA-OMNI-API for credential storage, WIA-AIR-SHIELD for runtime trust list, WIA-INTENT for workload intent declaration, and WIA Secure Enclave for sealed-data envelopes where personal data is processed. The composition lets one host running multiple WIA family standards reuse one identity, one signing-key chain, and one audit transport rather than maintaining N parallel per-standard implementations.

Normative references touched in this chapter

Implementation worksheet

  1. Read the corresponding Phase file in spec/ (Phase 1 for envelopes, Phase 2 for API, Phase 3 for protocol, Phase 4 for ecosystem).
  2. Walk the CLI helper: ./cli/speech-recognition.sh envelope emits a sample Phase 1 envelope.
  3. Exercise the simulator at simulator/index.html.
  4. Cross-reference the standards listed above to align with the operator's per-jurisdiction obligations.
  5. Wire the conformance suite at https://github.com/WIA-Official/wia-speech-recognition-conformance.

Cross-standard composition recap

This chapter, like every other Phase 1-4 chapter in the Speech Recognition eBook, composes with the wider WIA Standards family. Implementations that adopt the canonical envelope reuse the cross-standard audit transport (W3C Trace Context plus OpenTelemetry semantic conventions), the cross-standard identity (WIA-OMNI-API), and the cross-standard runtime trust list (WIA-AIR-SHIELD) without per-standard re-implementation. The federation handshake described in Phase 3 §3 follows the same challenge-response pattern as the rest of the WIA Standards family so that one operator can federate across multiple standards using one signing-key chain and one audit transport.