Skip to main content

​
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 STT model (e.g. Deepgram nova-3 multilingual) 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 overrides are available for Pipeline and Half-cascade engines because those modes have a separate TTS component. They are hidden for a pure Realtime speech-to-speech engine. The current Cartesia, ElevenLabs, OpenAI, Google, and Azure TTS integrations support live voice updates; the worker translates every override to the provider’s native option. Half-cascade uses the realtime model for speech understanding, but provider transcripts can arrive late and without a detected language. When secondary languages are configured, the platform therefore adds a separate multilingual transcription stream automatically. This supplies reliable language metadata without changing the realtime model’s turn handling.
Switching the editor view to Voice per language does not store a setting by itself. A language_voices entry is created only after you choose a voice for a language. Languages without an entry 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

The language setup is fully scriptable: primary_language, secondary_languages[], auto_language_switch, and the per-language voice map language_voices are regular assistant fields — set them via PATCH /api/v1/assistants/{id} or the MCP update_assistant tool. In the dashboard, auto_language_switch is derived from whether secondary_languages is non-empty. The supported language codes (ISO 639-1) are discoverable via GET /api/v1/languages.

​
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.
Change primary_language and only new summaries follow it — summaries already stored on past calls are not rewritten. Use Re-evaluate on a 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.