Translating your widget is not the same as supporting a language. A translated interface wrapped around English-only answers produces a familiar, dispiriting experience: the buttons are in Spanish and the help is not.
Retrieval changes the economics here, because meaning survives the language boundary better than wording does. One maintained knowledge base can answer in dozens of languages without maintaining dozens of copies of it.
Translation Is Not Multilingual Support
The traditional approach is to translate the knowledge base, which creates a maintenance problem that grows with every language and every edit. Each policy change becomes N translation tasks, and the translations drift out of date at different speeds.
Translated knowledge base
- Every policy edit becomes N translation tasks
- Languages drift out of date at different rates
- Translation cost scales with content, forever
- A missed update means a customer reads the old policy
One base, answered in any language
- Edit the source once, every language follows
- No translated copies to keep in sync
- New languages cost nothing to add
- Answers always come from the current source
How One Knowledge Base Serves Many Languages
- 1Detect the languageFrom the message itself, not from a browser header that is frequently wrong.
- 2Retrieve across languagesA multilingual embedding model places the question near the passage that answers it, whatever language each is written in.
- 3Generate in the asker's languageThe answer is composed in the customer's language, still bounded by the retrieved passage.
What Actually Breaks in Other Languages
The model handles grammar. The failures are elsewhere, and they are the sort of thing a native speaker spots in five seconds and a monolingual team never sees.
- Formality register — German, Japanese and Korean encode politeness grammatically. Getting it wrong reads as rude rather than as a translation artefact.
- Dates, units and currency — “3/5” means two different days on two continents, and quoting the wrong currency in a refund answer is a support ticket in itself.
- Right-to-left layout — Arabic and Hebrew need the interface mirrored, not just the text replaced.
- Legally binding wording — Statutory return and warranty rights differ by jurisdiction. Those passages should be written per market, not generated.
- Product and feature names — These usually should not be translated at all, and need to be pinned as untranslatable terms.
Quality Checks Per Language
You do not need a reviewer for every language you support. You need a repeatable check and a native reader for the languages that carry real volume.
Before you advertise a language
- Twenty real customer questions answered and read by a native speaker
- Formality register checked against how your brand speaks
- Dates, currency and units correct for the market
- Product names left untranslated where they should be
- Legally sensitive passages authored per jurisdiction
- Right-to-left rendering verified in the widget
- Escalation path staffed, or the language honestly labelled AI-only