Languages

Every answer comes back in the language the question was asked in, in the same script and the same register. There is nothing to configure: it applies to POST /v1/chat, POST /v1/chat/stream, the dashboard chat routes, and the embed widget alike, on every plan.

Your documents do not have to be in that language. An English-only knowledge base answers a Japanese question in Japanese — the facts come from the search results, the language comes from the visitor. Suggested follow-up chips come back in the answer's language too.

How it works

1. On the first message of a conversation, one short classification call identifies the language, script, and register of the question — for example *Hinglish (Hindi in Latin script, casual register)*.
2. A local Unicode script check runs first and is treated as the authority, so text typed in Latin letters is never answered back in a native script it was not written in.
3. That description is written into the answer prompt, so the model is told which language to answer in rather than left to infer it while composing a grounded answer.
4. The result is stored on the conversation and reused for every later message in the same thread, which is what keeps a long thread from drifting into English halfway through.

Reading the detected language back

Dashboard (JWT) conversation endpoints return what was detected, so an inbox can label a thread by language. The field is optional — it is absent on threads that predate the feature and on turns where detection did not complete.

{
  "conversation": {
    "conversationId": "conv_xyz789",
    "projectId": "proj_abc123",
    "detectedLanguage": {
      "label": "Hinglish (Hindi in Latin script, casual register)",
      "isRomanizedOrCodeMixed": true
    }
  }
}

It is returned by GET /v1/conversations, GET/PATCH /v1/conversations/{conversationId}, the project-scoped conversation routes, and POST /v1/projects/{projectId}/chat. It is not part of the public POST /v1/chat response — an anonymous visitor has no use for it.

Custom generation prompts

settings.advanced.generationPromptOverride replaces the platform answer prompt in full, which includes the language instruction. To keep language matching, put {{detected_language_instruction}} where you want that instruction to land.

Answer in at most three short sentences using ONLY the search results below.

{{detected_language_instruction}}

Search results:
$search_results$

User question:
$query$

$output_format_instructions$

settings.systemPromptOverride is different: it is prepended to the platform prompt rather than replacing it, so it keeps language matching with no placeholder needed.

Verified languages

Detection is model-based, so languages outside this table generally work. These 60 are the ones actually checked end to end on 7 September 2026 — one fresh conversation each, with a reviewer confirming the answer *and* its follow-up chips came back in the question's language and script.

Script continuity across a multi-turn thread was checked separately for Hindi, Hinglish, Arabic, and Japanese.

Known gaps

• Malay was answered in Indonesian and labelled Indonesian. The two are largely mutually intelligible, but Malay is not verified.
• Romanized Tamil (Tanglish) and romanized Arabic (Arabizi) are covered by the script check and its unit tests, but have not yet been re-verified live.
• settings.defaultLanguage is not connected to anything. Language comes from the question, not from project settings.
• Language matching decides the answer's language. Retrieval still searches your documents as they are written, so a term that only appears in English is found by its English form.