Multilingual customer support on a single knowledge base: setup and gotchas

Selling into three countries used to mean one of two unattractive things: hire support staff in three languages, or maintain your entire help centre three times over. Grounded AI support changes that arithmetic, because retrieval and generation are separate steps — the system can find the answer in an English article and write it out in Dutch. That genuinely works. So the interesting question is no longer whether it can, but which parts of your content still need writing per language, and how you would notice when a translated answer is quietly wrong.

What actually decides the language of the answer

The mental model most people arrive with — "it detects German and switches to the German knowledge base" — is not what happens, and the difference determines how you should write.

1. The question goes into the search step first. In CustomerEagle a non-English question is translated to English internally before searching, because the index matches on meaning and searching from one pivot language is more reliable. Product names, SKUs and order references are left alone, and very short or code-like queries skip the step.
2. The search itself is not filtered by language. A German question routinely retrieves English passages. That is the whole trick: one set of articles serves every market.
3. Those passages go to the model with an instruction to answer in the language of the customer's most recent message, translating the retrieved material as needed. That instruction is switched on by the "reply in the customer's language" setting, which is on by default. Switch it off and the AI answers in English regardless of what the customer wrote.

Three strategies, and what each one really costs

Every multilingual setup lands on one of three shapes. The common mistake is treating this as one decision for the whole knowledge base rather than a choice per article.

Most teams end up on the hybrid, for a reason that fits in one sentence: translating costs you nothing, keeping it current costs you everything. An article translated once and then changed four times over the following year, where two of those changes never reached the German copy, is a liability with a citation underneath it.

What crosses a border intact, and what does not

• Survives: procedures, product behaviour, troubleshooting steps, definitions, and policy stated as fact. A 30-day return window is a 30-day return window everywhere.
• Breaks: values that differ per market. That is the big one, and it gets its own section below.
• Breaks: legally precise wording, idiom, and anything where the phrasing is the product. A statutory term has an exact name in each jurisdiction, and brand voice does not survive the round trip.
• Uneven: interface strings. An English app and a French customer produce a French sentence with an English button name in it — correct, and careless-looking.

The values problem, which is the one that actually bites

Your source article says "delivery takes 1–2 working days" and "returns are free". Both were true when you wrote them, about one market. Answer a German customer from that article and the AI states them confidently, in German, with a citation. It is not hallucinating. It is repeating what you wrote.

This is the most common way a multilingual setup goes wrong, and it has everything to do with how the article was written rather than with language. The fix is structural: any fact that varies by market has to carry its condition in the same sentence.

Note what this is not: a translation problem. No amount of translating would have fixed it. It is the same discipline that makes an article answerable at all — real values as text, conditions before conclusions — applied to a second axis. If you have not read how to write help-center articles an AI can answer from, start there: an article already vague about its own conditions becomes actively misleading the moment it serves four markets.

Detection will sometimes be wrong — leave an escape hatch

Language detection is a guess: a good one on a paragraph, a poor one on "ok", "ja" or an order number. Languages that share vocabulary — Dutch and German, Spanish and Portuguese — are the ones most likely to be confused on a short message. Design for the guess being wrong occasionally.

• Never detect from IP address alone. A Dutch speaker in Germany, an expat in Amsterdam and anyone behind a VPN all get it wrong, and being addressed in the wrong language is a worse first impression than a neutral one.
• Let the customer override, visibly. The widget's interface language can be pinned per page, set once for the workspace, or left automatic, following the visitor's browser setting.
• Remember that the interface language and the AI's reply language are decided separately: the interface follows the browser, the answer follows what the customer typed. When they disagree, the answer language is the one the customer notices.
• Write your greeting per language, and check the strings around the AI. Greetings, handoff messages, out-of-hours notices and pre-chat forms are the parts that most often stay stubbornly English inside an otherwise fluent conversation.

The help centre is a separate decision

Teams assume that going multilingual in chat means going multilingual in the public help centre on the same day. It does not, and the economics differ. The bot answers a question that was just asked; the help centre is a browsable, indexable library someone has to keep current. Four languages there is four sites to maintain, and it is entirely reasonable to leave it in one or two for considerably longer than the bot.

When you do publish natively, keep the versions linked rather than loose. In CustomerEagle a help-centre article carries its own language, and translations of the same article can be grouped so the set is visible as a set — which is what stops the German version quietly falling three policy changes behind. Keep control of what is indexed for AI answering, too: an article that exists for people does not have to be an answer source.

Measuring per language, where most setups stop too early

One aggregate resolution rate hides a per-language problem completely: three markets working and one badly broken produces a headline number that looks like a mild content gap. The remedy is manual work in most stacks — budget for it rather than expecting a dashboard to hand it over.

• Sample rather than aggregate. Twenty conversations per language per month, read by someone who speaks it, beat any dashboard — and it is the only way to catch answers that are fluent, confident and wrong.
• Group handoffs by reason and by language. A drop in one market is almost always one missing market-specific article rather than a model problem.
• Watch for the mixed-language answer: a French reply quoting an English policy sentence verbatim. It signals a source passage too rigid to translate cleanly.
• Re-run your test set per market, and track what each market asks about rather than only how. The biggest topic in your second market is frequently not in your own top ten.

A setup order that works

1. Pick one source language and write that content properly. A vague source article becomes a vague answer in four languages instead of one.
2. Go through every article for market-specific values and fold the conditions into the sentences. Do this before enabling anything: it decides whether cross-lingual answering is safe or dangerous.
3. Check what the automatic language setting is actually doing, then write per-language greetings and check the handoff and out-of-hours strings in each language you serve.
4. Test each market with a native speaker and real phrasings before announcing anything. Score coverage first, tone second.
5. Write the top five articles natively per market, in the order your test results dictate, then set a monthly sampling routine per language.

Done in that order, adding a market becomes a content decision rather than a hiring decision, which is the actual point. What the answering side looks like in the product is on the features page. The fastest way to find out how your content holds up in a second language is to ask it a question in that language and read what comes back.