Skip to main content
Set the language an assistant listens for, add secondary languages so it can switch automatically as a caller’s language changes, and choose a matching voice for each one.

​
Setting the primary language

Each assistant has an STT language that tells the transcription model what to expect. Set it to the language your callers actually speak — it measurably improves recognition of names, numbers, and addresses. For the assistant’s output language, be explicit in the system prompt:
Turn detection supports a multilingual semantic model (default) that understands sentence boundaries across languages, plus an English-optimized variant and plain VAD.

​
Multilingual assistants

For markets where callers switch languages (common in DACH: German, Turkish, English), configure automatic language switching:
  1. Choose a multilingual speech-recognition model so the transcription follows the caller.
  2. Add at least one secondary language. Automatic switching turns on as soon as a secondary language is present and turns off when the last one is removed.
  3. Optionally map a voice per language — e.g. a German voice for de, an English voice for en. When the caller switches, the assistant answers in the new language with the matching voice.
The assistant also receives a prompt hint to respond in the detected language, so the LLM follows along without extra prompt engineering. Per-language voice choices are available for Pipeline and Half-cascade engines because those engine modes use a separate speaking voice. They are hidden for a pure Realtime speech-to-speech engine.
Switching the editor view to Voice per language does not change the assistant by itself. Choose a voice for a language to save an override; languages without one keep the assistant’s main voice.
Keep the system prompt in one language (ideally English — LLMs follow English instructions most reliably) and state the answering rule explicitly: “Answer in the language the caller speaks.”

​
API and MCP

The same language and voice settings are available through PATCH /api/v1/assistants/{id} and the MCP update_assistant tool. Use GET /api/v1/languages to list supported ISO 639-1 language codes; see the API reference for the request fields.

​
Pronunciation across languages

The pronunciation dictionary applies in every language — useful for brand names that TTS voices mangle differently per language. Tenant admins can define a tenant-wide default map that merges with per-assistant entries.

​
Post-call summary language

The Conversation Summary on a call detail is always written in the assistant’s primary language — not in the language the call was held in. A German assistant that took a call in English still gets a German summary, so a history list stays readable in one language. Re-evaluating a call (History → Re-evaluate) uses the same rule. Everything else stays in the original language: the transcript, recordings, and extracted analysis fields are never translated.
When you change the primary language, only new summaries follow it. Use Re-evaluate on an older call to regenerate its summary in the new language.

​
Documentation vs. call language

Note that the platform UI language and the assistant’s call language are independent: your team can operate an English dashboard while assistants speak German to customers, and vice versa.