A customer asks a question in German about an order shipping to the Netherlands. The product documentation is in English, while the return conditions depend on the selling entity and delivery market.
Translating an English answer into German solves only one part of that problem. The system must first determine which information applies, retrieve it, and preserve its meaning through the response.
Represent language and market separately
I avoid using a single locale field to represent everything about a conversation. The customer’s preferred language, the storefront language, the destination country, and the transaction currency can differ.
Browser preferences can provide a useful initial language signal, but the user’s actual message or explicit choice should be able to override it. The W3C explanation of browser language preferences describes the mechanism; it should not be mistaken for evidence of a customer’s location or applicable commercial terms.
For a support request, I would resolve market scope from trusted order or storefront context where available. If the answer depends on a missing country or product variant, asking a short clarifying question is better than guessing.
Retrieve across languages without changing identifiers
A multilingual embedding model may connect a German question to an English passage, but that behavior needs evaluation on the actual corpus. Domain vocabulary, abbreviations, and short queries can be challenging.
Query rewriting is another option. I preserve the original message and produce a retrieval-oriented version only for searching. Product codes, order references, measurements, and brand names should remain identifiable through that transformation.
I also keep the original query in the retrieval trace. If the rewrite changes “does not fit” into “fits,” debugging only the translated query hides the source of the error.
Do not let a translation become a policy decision
Suppose the source says a return requires prior approval. A fluent paraphrase that implies returns are always accepted has changed the policy. Similar problems appear with qualifying words, exclusions, and deadlines.
I prefer an evidence representation that records the policy’s conditions before the response is phrased in the customer’s language. For structured facts, the pipeline can preserve the value and unit independently of the surrounding sentence.
Currency formatting deserves the same care. Displaying a value using local punctuation is different from converting it to another currency. A language switch should never silently turn a euro price into a different monetary amount.
Make source fallback an explicit product rule
If a localized document is missing, using an English source can be useful. The fallback must still respect tenant, market, and document validity. A well-written policy from the wrong region is not a safe substitute.
I record which source language was used and whether the response required translation. That makes it possible to find gaps in the knowledge base and prioritize translations based on real conversations.
When no applicable source exists, the system should ask or escalate. Missing translation coverage and missing business information are different problems, and the operator needs to know which one occurred.
Evaluate meaning, not only fluency
I build parallel cases across languages for the same underlying customer intent. The review checks source selection, entity preservation, factual support, response language, and whether the handoff decision remains appropriate.
Native or proficient human review matters for cases where a subtle condition changes the outcome. A fluent automated translation is not sufficient evidence that a contractual or operational nuance survived.
The most useful multilingual metric is whether customers in each language receive the same standard of supported assistance. That includes knowing when the system needs one more fact before it can answer.
Updated 25 September 2026.