> ## Documentation Index
> Fetch the complete documentation index at: https://docs.famulor.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Languages

> Single-language setup, multilingual assistants, and automatic language switching

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:

```text theme={null}
Always answer in German, regardless of the language the caller uses.
```

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](/assistants/engine-modes) use a separate speaking voice. They are hidden for a pure **Realtime** speech-to-speech engine.

<Note>
  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.
</Note>

<Tip>
  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."
</Tip>

## 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](/assistants/models-and-voices#speaking-style) 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.

<Note>
  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.
</Note>

## 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.