The traditional way to support customers in another language is to translate your help centre, hire a speaker, and maintain both forever. The cost scales linearly with languages, which is why most companies stop at two.
A retrieval-based assistant breaks that link — but only if you are precise about where translation happens.
Three architectures, one obvious winner
| Approach | How it works | The catch |
|---|---|---|
| Translate the docs | Maintain a full corpus per language | Linear cost, and every translation drifts out of date separately |
| Translate the question | Translate query → English, retrieve, translate the answer back | Two lossy hops; product terms get mangled on the way in |
| Multilingual embeddings | Index English once; embed the question in its own language and match across languages | Needs a genuinely multilingual embedding model |
The third is what you want. A modern multilingual embedding model places "how do I cancel my subscription" and "wie kündige ich mein Abonnement" close together in the same vector space, so a German question retrieves your English documentation directly. Only the final answer is generated in German, from English sources, in one step instead of three.
Where it actually goes wrong
The architecture is the easy part. These are the things that bite in production.
Product nouns should not be translated
If your dashboard is in English, telling a French customer to click "Paramètres" when the button says "Settings" is worse than not answering. Keep UI strings, plan names and menu paths verbatim, and instruct the model explicitly to do so.
Reply in the language of the question.
Keep these EXACTLY as written in the source, untranslated:
- UI labels and menu paths (Settings › Chat widget)
- Plan names (Free, Hobbyist, Pro)
- Error messages and error codes
- Product and feature names
Translate the surrounding explanation only.Detect language per message, not per session
People code-switch, especially technical users who write half a sentence in English. Detecting once at the start and locking it in produces the frustrating experience of a bot that will not switch back. Detect on every turn, with a light bias toward continuity so a single English product name does not flip the whole conversation.
Register matters more than you think
Some languages carry a formality decision in every sentence — du/Sie, tu/vous, informal and honorific Japanese. Pick a policy per language and state it in the prompt. Defaulting to whatever the model prefers means your brand voice is set by a coin flip.
Right-to-left is a UI problem, not a model problem
Arabic and Hebrew answers will be correct and will render badly if your widget does not set direction per message. Check it with real text before you claim support.
How to verify before you announce it
- 1Take your ten most common questions and have native speakers write them naturally in each target language — not machine-translated from English, which produces unnaturally clean queries.
- 2Confirm the retrieved passages are the same ones the English question retrieves. If they differ, the embedding model is the problem, not the generation.
- 3Have a speaker read the answers for register and terminology, not just correctness.
- 4Check the widget rendering for RTL and for scripts with tall glyphs.
The customer does not care that your documentation is in English. They care that they asked in Portuguese and got a correct, natural answer that matched the buttons on their screen.
Done properly, the marginal cost of the eleventh language is zero. That is the actual product change — not the language count on the pricing page, but the fact that it stopped being a decision you have to budget for.
- Localisation
- Product
- Retrieval
