Teams enable multilingual chat because visitors ask in languages the team speaks, or because the market demands it, while the help centre remains English-only. That is a common starting point. It is also a common source of quiet wrong answers, when translation smooths over gaps the English pages never filled.
Multilingual output from monolingual sources is not the same as multilingual knowledge. The product can reply in Spanish while retrieving English chunks; the citation may still be English. Whether that is acceptable depends on your audience, your legal exposure, and how clearly you signal what was translated versus what was written for them.
What works without translated docs
Straightforward FAQ retrieval often works well: shipping times, password reset steps, return windows stated clearly on one English page. The model renders the answer in the visitor’s language; the citation points at the English source. Many visitors prefer a fast, accurate answer with an English link over waiting for localised docs that do not exist.
- Procedural questions with one canonical English page.
- Product facts that do not change by locale — SKUs, dimensions, integrations listed in English.
- Escalation to humans who speak the language, when chat cannot ground an answer.
Set expectations in the widget
A one-line note — “Answers are based on our English help centre and may link to English pages” — is not a downgrade. It is the difference between informed consent and surprise when someone opens a citation. For EU visitors, pairing that with a human path in local language is often more important than perfect machine translation.
Let visitors choose language explicitly rather than guessing from browser headers alone. Wrong-language guesses feel careless; a visible language control feels deliberate.
Test refusals and gaps in every enabled language
English-only evaluation misses half the failure mode. A question with no English source should refuse in French, German, and Portuguese too — not invent a plausible policy because the model is fluent. Run the same paraphrase and gap tests you run in English; use native speakers or staff who can spot “sounds right but isn’t ours”.
- Ten questions you know the English pages answer — verify citations still land on the right URL.
- Ten questions you know are gaps — verify refusal, not invention, in each language.
- Five policy questions with strict wording — compare translation to the English sentence on the page.
- One handoff request per language — confirm it completes in one step.
Prioritise translating pages that hurt when wrong
You do not need forty localised articles to launch. You need the pages where mistranslation or paraphrase creates liability or chargebacks: returns, billing, privacy, medical disclaimers, age restrictions. Translate those properly; leave the blog archive in English until there is demand.
Track content gaps by language in your inbox. If German visitors repeatedly ask something the English FAQ almost covers, that is a translation candidate — not a prompt tweak.
Citations in English under non-English answers
Many visitors are fine following an English policy link if the chat summary is in their language. Others are not. Know your audience: expatriate SaaS users often prefer English sources; local service customers may not. You can offer both — short answer in their language, citation label noting the source language — without pretending the page is translated.
Do not auto-translate citations in the URL bar. Link to the authoritative page; let the browser’s translate feature do optional work. Machine-translated policy pages you do not review become a second source of truth you never approved.
When to disable a language until sources exist
Fluency without grounding is worse in non-English locales because your team cannot skim the answer at a glance. If you serve a regulated market and cannot yet publish verified translations, turn off automated answers in that language and offer human contact instead. A narrow honest channel beats a wide confident one.
“Speaking the visitor’s language is not the same as having something authoritative to say in it.”
Staff language versus visitor language
Internal docs often use English product names visitors never type. Retrieval matches what is indexed: if only English internal wikis are crawled, non-English questions may still retrieve English chunks and reply in the visitor’s language anyway. That can work for factual product names; it fails for policy nuance. Prefer public help wording in the index even when drafting in English first.
English-only sources are a workable phase — not a secret. Design for citations visitors can use, refusals that survive translation, and a roadmap driven by gaps rather than by vanity coverage metrics. When you do publish translations, recrawl them the same day — partial multilingual coverage is harder to debug than English-only honesty.
