Multilingual AI Support: What Actually Breaks

Is multilingual support actually a translation problem?

Mostly no, and this is the reframe that changes what you build. Translation is the part that current models handle well and the part that gets all the attention. The parts that break are adjacent to translation rather than inside it.

Think about what has to be true for a Spanish-speaking customer to get a good answer. The model has to understand the question, which is usually fine. It has to find the right content, which is a retrieval problem across a language boundary and is often not fine. It has to answer in the right register, which is a cultural problem. And if it cannot answer, someone has to pick the conversation up, which is a staffing problem.

Three of those four are not translation. Teams that treat this as "switch on translation and ship" get surprised by the other three in that order.

The research points the same way. Work presented at EMNLP 2025 measured up to a 29% accuracy drop in non-English languages compared with English, even with retrieval-augmented generation in place. The retrieval layer did not rescue it, which is the part worth internalising before you enable a language.

Why bother at all? Because language preference is close to absolute. The European Commission's Flash Eurobarometer 313, based on 13,752 interviews across the EU27, found that "9 in 10 Internet users in the EU said that, when given a choice of languages, they always visited a website in their own language", and that 44 percent thought they missed interesting information because sites were not available in a language they understood. The fieldwork is from January 2011, so read it as a durable statement about preference rather than a current market number.

Why does formality break first?

Because most languages encode social distance in grammar and English barely does, so an English-authored system prompt has nothing to say about it. German has du and Sie. Spanish has tú and usted. French has tu and vous. Japanese has an entire honorific system where the wrong level is not a small error, it is a statement about the relationship.

The default behaviour of a model given no instruction is to pick whatever register dominates in its training data for that language, which for consumer-facing web text often skews informal. That produces a support reply that reads to a German business customer roughly the way "hey buddy" reads to an English one. Perfectly comprehensible, and wrong.

Fix it explicitly per language rather than globally. Specify the register in the prompt, and be aware the correct choice depends on your market: informal is normal for a consumer app in Spain, and not for a B2B tool in Germany. This is the single cheapest quality improvement available and almost nobody does it before launch.

Translate-then-respond, or answer natively?

Two architectures, and the difference matters more for retrieval than for output quality.

Translate-then-respond converts the incoming message to your base language, runs the whole pipeline in that language, then translates the answer back. Two conversion steps, each of which can lose nuance. Its real advantage is that retrieval happens entirely in one language, so your existing search behaves exactly as it always has.

Native multilingual has the model read the original message, retrieve against your base-language knowledge base, and answer in the customer's language. Output reads more naturally because the model composes rather than converts. The catch is cross-language retrieval: the customer wrote "factura duplicada" and your article says "duplicate charge", and whether those match depends entirely on your embedding model.

We prefer native multilingual, but with a caveat worth stating plainly. If your retrieval quality drops across the language boundary, native multilingual produces fluent, well-phrased answers drawn from the wrong article. That is a more dangerous failure than a clumsy translation of the right one, because nothing in the output looks wrong.

Test this specifically. Take twenty real questions in your top non-English language and check which articles the system retrieves, not just what it says.

Which knowledge base strategy fits your volume?

You have three options and most teams should be running a mix rather than picking one.

The mistake is treating this as a single decision for the whole company. It is a per-article decision. Your top ten articles in German may be worth translating while article ninety is not, and that is the correct outcome rather than an inconsistency.

When is translating an article actually worth it?

Here is the arithmetic. Every input below is illustrative, chosen to show the method rather than measured from any deployment.

Say an article gets 300 views a month across all languages, and German is 12% of your traffic, so roughly 36 German views a month. Suppose that on machine-translated content, one in ten of those views ends in a follow-up ticket that a properly translated article would have prevented. That is about 3.6 extra tickets a month, or 43 a year.

Now the cost side. Having a bilingual person translate and review the article takes about 90 minutes once, plus roughly 15 minutes a quarter to keep it in sync as the product changes, so 90 plus 60 equals 150 minutes in year one.

150 minutes to avoid 43 tickets is about 3.5 minutes of effort per ticket avoided. Almost no support ticket costs less than 3.5 minutes to handle end to end, so this article is worth translating.

Run the same calculation on an article with 30 views a month and 12% German traffic and you get 3.6 German views a month, roughly 4 tickets a year, and 150 minutes to avoid them. That is 37 minutes per ticket avoided, which is clearly not worth it.

The threshold falls out of the arithmetic rather than out of an opinion, and it is usually much higher than teams assume. Most knowledge bases have five to fifteen articles that clear the bar in any given language, not fifty.

What happens when the AI cannot answer?

This is the part that gets planned last and should be planned first. A fluent AI conversation in Portuguese that escalates to a support team where nobody reads Portuguese is a worse experience than an English-only widget, because you raised the expectation and then dropped it.

Three workable designs, in descending order of quality. Route to a language-matched human where one exists, even part-time and even on a contract. Or run agent-side live translation, where your agent types in English and the customer reads their own language, which works acceptably for factual back-and-forth and poorly for anything emotional. Or state the limit up front: offer the AI in that language and be explicit that human follow-up is in English.

The third option is honest and underrated. Customers deal with it fine when told in advance and resent it when discovered mid-complaint. Whichever you choose, decide before you enable the language, not after the first escalation. The handover guide covers the context-carrying part.

Why is language-specific CSAT usually misleading?

Because a lower score in one language gets read as a translation problem when it is almost always a content problem.

Suppose your English satisfaction is healthy and your Japanese satisfaction is visibly worse. The instinct is to blame the Japanese output. Usually the real cause is that Japanese customers ask about things your knowledge base does not cover: a local payment method, a regional shipping partner, a compliance requirement that does not exist in your home market. The AI translates beautifully and has nothing correct to say.

The diagnostic is straightforward. Pull the questions the AI failed to answer in that language and read them, translated if you must. If they cluster around topics your knowledge base genuinely does not discuss, you have a content gap. If they are ordinary questions you cover well in English, then you have a retrieval or translation problem. These two causes need completely different fixes, and the aggregate score cannot tell them apart.

Track resolution rate per language alongside satisfaction, because a language where the AI answers little but scores well is a different situation from one where it answers plenty and scores badly.

What should never be machine-translated?

A short list, and it should be enforced as a hard rule rather than a preference.

Contract terms and terms of service. Refund and cancellation policy wording, as opposed to a general explanation of how refunds work. Anything describing a legal right, a warranty or a regulatory obligation. Data processing and privacy commitments. Formal complaint outcomes and anything that might be produced as evidence.

The reason is not that machine translation gets these wrong more often. It is that when it does get one wrong, you may be bound by the wrong version, and you will have no record of who approved the wording. Keep these in human-translated form, keep the source of truth versioned, and have the AI quote from it rather than paraphrase it.

Where multilingual AI support breaks

Cross-language retrieval, as covered above, and it is the failure worth designing tests for.

Mixed-language conversations. Real customers switch mid-thread, quote an English error message inside a Spanish sentence, or write in a third language they are less comfortable in. Language detection on a single short message is unreliable, so detect on the conversation rather than the message and let the customer override.

Names, products and errors that must not be translated. A model translating your product name, a plan name, or a verbatim error string produces text that cannot be searched for or matched against your documentation. Maintain a do-not-translate list.

Right-to-left and typographic assumptions. Arabic and Hebrew break layouts built for left-to-right text, and this is a widget problem rather than an AI problem, but customers do not distinguish.

Where we are wrong about this

We have made the cost argument for multilingual AI more confidently than the evidence supports. The pitch is that flat pricing gives you every language for the price of one, which is true of the software line item and misleading about the total. Adding a language adds content work, review time, and often a contractor for escalations. It is cheaper than hiring a native-speaking agent per market. It is not free, and describing it as free sets teams up to be annoyed at month two. Our pricing page is honest about the software cost and says nothing about the operational one.

We are also more sceptical than we used to be about launching many languages at once. Turning on twenty is technically trivial and that is exactly the trap: you now have twenty quality surfaces and no capacity to review any of them. Two languages you have actually inspected beat twenty you have not.

A 30-day rollout

Days 1 to 5: pick one language, set the formality register explicitly, and build a do-not-translate list of product names, plan names and error strings.

Days 6 to 15: run twenty real questions in that language and check which articles get retrieved, not just what the answers say. Fix retrieval before touching phrasing. Decide and staff the escalation path.

Days 16 to 30: have a native speaker review a sample of real conversations weekly. Run the translation arithmetic above on your top articles and translate only the ones that clear the bar.

Then, and only then, add the second language. If you want to test how this behaves on your own content, you can try it free.