Multilingual Chatbots: What Breaks When You Add the Second Language

Teams approach multilingual chatbots as a translation project, budget accordingly, and are surprised by what the budget did not cover. Modern models translate well and will answer in the language they were asked in with no configuration at all.

What breaks is everything around the translation: knowing which language to use before the user has said anything, having content to ground answers in for each language, staffing a handover queue in four languages, and a layout that fits words of very different lengths.

None of that is solved by a translation step, and all of it decides whether the second language is actually usable.

Language detection works well once someone has written a sentence. The problem is the greeting, which comes first.

Why the opening message is hard

The bot has to choose a language before the user has typed anything. Get it wrong and the visitor's first impression is a wall of text they cannot read - and the option to switch is written in that same language.

Signals, in order of reliability

1. An explicit choice the user made - a language switcher on your site, or a stored preference. Always the best signal and usually ignored.
2. The page they are on. A visitor reading the German version of your site should get German. Obvious, frequently unimplemented.
3. Browser Accept-Language. Decent, but reflects the device rather than the person - shared and corporate machines lie routinely.
4. IP geolocation. The weakest. It confuses location with language, which fails for every multilingual country and every traveller.

The rule that saves you

Whatever you detect, make switching obvious and language-neutral. A row of flags is the wrong pattern - flags are countries, not languages, and no flag represents Spanish or Arabic honestly. Use language names written in their own language: Deutsch, Español, العربية.

This is where most multilingual projects quietly fail. The bot can speak eight languages. The content it answers from exists in one.

What happens in practice

A model asked in French, retrieving from English content, will usually answer in French. Whether that answer is accurate depends on whether it retrieved the right English passage, which depends on whether the retrieval step understood the French question. Retrieval quality across languages is markedly worse than generation quality, and this is invisible unless someone who speaks French tests it.

Three approaches, honestly compared

• Translate at answer time. Cheapest, no extra content to maintain. Weakest retrieval, and terminology drifts - your product names and policy terms get translated inconsistently between answers.
• Translate the knowledge base once. Better retrieval because the question and content are in the same language. Now you have two sets of content to keep in sync, and they will drift.
• Write natively per market. Best quality, and genuinely different content - markets have different questions, not just the same questions in different words. Most expensive.

How to choose

Translate at answer time for languages that are a small share of traffic. Translate the content properly once a language passes roughly a tenth of volume. Write natively where the market is genuinely different - different products, regulations or buying process.

The bot answers in Portuguese. It reaches its limit and offers a human. Who picks that up?

This is the question that turns a multilingual chatbot from a feature into an operational commitment, and it is routinely discovered after launch.

The options

• Staff the language. Best experience, real cost, and only viable above a volume threshold.
• Machine-translate the agent conversation. Workable for straightforward support, poor for anything nuanced or emotional, and you must tell the customer it is happening.
• Restrict handover hours by language. Honest if stated clearly up front.
• Take a message and reply by email. Perfectly acceptable if the bot says so rather than implying live chat.

The failure to avoid

Offering live handover in a language nobody is staffed for. The customer waits, nobody comes, and the experience is worse than a bot that had said "our team replies in English, or leave a message and we will respond in Portuguese by email".

Deciding this is part of owning the bot rather than building it - the ownership guide covers the rota side.

The interface was designed around English string lengths. Other languages do not cooperate.

• German runs 20 to 35% longer than English. Button labels that fit will truncate.
• Finnish and Hungarian compound words can be a single very long token with nowhere to break.
• CJK is shorter but needs more line height to stay readable.
• Arabic and Hebrew are right-to-left, which mirrors the whole layout - including which side message bubbles sit on and which corner the widget belongs in.

What to do

Test the interface with the longest translation you have rather than the shortest. Quick replies are where this bites hardest, since they render across a narrow panel and truncate silently. If a row of three buttons fits in English and truncates in German, the German user gets an unusable interface with no error to report.

For right-to-left languages, check the widget corner as well as the text direction. Bottom-right is the convention because of left-to-right reading order; for an RTL layout the mirrored position is the correct one.

1. Find out which languages you already get. Check your existing transcripts and analytics before deciding. Teams usually guess wrong about which second language matters.
2. Start with one, not five. The operational load is per language, not per project.
3. Decide the handover answer first. If you cannot staff or honestly message it, the bot should not offer it.
4. Translate at answer time to begin with, and measure. Move to translated content once the language earns it.
5. Have a speaker test it. Not a colleague with school-level knowledge - someone who would notice that your product name has been translated into something absurd.
6. Check the buttons at the longest string length.

The model choice matters here too: some models are markedly stronger on some language families than others, and that is worth testing on your own questions rather than assuming. Choosing an LLM covers running that comparison, and you can trial a second language on the free plan before committing to translated content.

The build cost is per project. The running cost is per language, and it is the one that gets underestimated.

Flow edits multiply

This is the cost nobody models. Changing one question in a flow is a five-minute edit in one language and a thirty-minute job across six, including getting each translation reviewed. Teams add languages, then find they have stopped iterating on the flow because every change has become expensive.

The mitigation is to keep the flow structure identical across languages and vary only the strings, so one structural change propagates once. Flows that diverge per market become separate products with separate maintenance, which is occasionally right and usually accidental.

The threshold worth using

Add a language when it is either a strategic market with a plan behind it, or already above roughly a tenth of your traffic. Adding languages speculatively produces a set of half-maintained flows, and the half-maintained ones are worse than not offering the language at all - they promise support that does not really exist.

Grammatical translation is solved. Consistent terminology is not, and it is what makes a bot read as professional or improvised.

What goes wrong

• Product names get translated. A feature called "Flow Builder" should stay "Flow Builder" in German, not become "Ablaufersteller" in one answer and something else in the next.
• Policy terms drift. "Refund window" rendered three ways across three answers makes the policy sound negotiable.
• Register shifts. Formal and informal address - Sie and du, vous and tu - chosen inconsistently is immediately noticeable to a native speaker and invisible to everyone else.
• Legal phrasing loosens. Terms with a specific meaning in your jurisdiction get paraphrased into something weaker.

The fix is a glossary, not a better model

Maintain a short list of terms that must not be translated and terms that must be translated one specific way, and put it in the system prompt or the translation brief. Twenty entries covers most products, and it removes the majority of the drift.

The review that catches it

A speaker reading twenty real answers, not a spot check of three. Ask them specifically whether the terminology is consistent and whether the register is right, because those are the two things a fluent-but-inattentive review misses.

Real multilingual users do not behave like the test cases. Four patterns worth designing for.

Mid-conversation switching

Someone starts in English, gets stuck, and switches to their first language. The bot should follow rather than insisting on the language it started in - and the transcript should record both so the agent who picks up is not confused.

Mixed within one message

Code-switching within a sentence is normal in many regions. Detection has to cope rather than picking one language and mistranslating the rest. Models handle this better than rule-based detection, which is an argument for letting the model answer rather than routing on a detected language label.

Writing in a language they read poorly

A user may write in English because your site is in English, while understanding a reply far better in their own language. An explicit, visible switcher matters more than detection for exactly this case.

Transliteration

Arabic, Hindi and Greek speakers frequently type in Latin characters. Detection commonly labels this as English and answers in English. If you serve those markets, test it - it is invisible in any test suite written by a native English speaker.

A sequence that avoids the common failure of launching five languages and maintaining none.

1. Check what you already get. Look at existing transcripts and analytics rather than guessing. Teams frequently pick the wrong second language.
2. Settle the handover answer first. If you cannot staff it or message it honestly, do not offer live handover in that language.
3. Translate at answer time to begin with. Cheapest, and enough to measure real demand.
4. Add the glossary before quality complaints start rather than after.
5. Have a speaker review twenty real answers.
6. Test the interface at the longest string length, and check right-to-left layout if relevant.
7. Measure for a month, then decide whether to translate the knowledge base properly.

What to watch once live

A markedly higher fallback rate in the second language almost always means the knowledge base is the bottleneck rather than the model, which is the point at which translating content properly earns its cost. Model choice matters here too - strength varies by language family, so test rather than assume, as covered in choosing an LLM.

Practical notes

Language handling interacts with accessibility: each message needs a lang attribute so screen readers switch voice, covered in the accessibility guide. Deployment is unchanged across WhatsApp, Telegram and your website, the template library gives you a structure to translate rather than invent, and you can trial one additional language on the free plan before committing to translated content.

Model comparisons are almost all conducted in English, and the rankings do not transfer cleanly. A model that leads on English reasoning can be noticeably weaker on Arabic morphology or Japanese politeness levels, and none of that appears in the headline numbers.

Where the differences show up

• Morphologically rich languages - Finnish, Turkish, Hungarian - where a single word carries what English spreads across five. Retrieval suffers more than generation here.
• Languages with formality systems - Japanese, Korean, German - where getting the register wrong is not a style issue but a correctness one.
• Right-to-left scripts, where the model may be fine and the rendering is not.
• Lower-resource languages, where quality drops sharply and confidently - the model does not signal that it is less sure.

How to test it properly

Run your twenty real questions in the target language, not translations of English ones. Translated test questions carry English sentence structure and are easier than what a native speaker actually types. Then have a speaker mark each answer as shipped, fixable or wrong, exactly as in the English evaluation.

If one model is clearly better for a market that matters, the useful question is whether your platform lets you set the provider per chatbot - which turns this into a configuration rather than a compromise. Choosing an LLM covers running the comparison, and the provider list shows which options exist.

Adding Arabic or Hebrew is different in kind from adding another left-to-right language. The text direction is the smallest part of it.

What mirrors

• Message alignment. User messages move to the left, bot messages to the right - the opposite of the LTR convention.
• The widget corner. Bottom-right is conventional because of reading order; for RTL the mirrored corner is correct.
• Icons with direction. Send arrows, back chevrons and progress indicators all point the other way.
• Padding and margins. Anything using left and right rather than logical start and end properties.

What does not mirror

Numbers, Latin-script brand names, phone numbers and code stay left-to-right, embedded within right-to-left text. Mixed-direction lines are where rendering breaks, and where a naive implementation produces text that is technically present and genuinely unreadable.

The practical approach

Use logical CSS properties - inline-start and inline-end rather than left and right - and set dir on the container rather than per element. Then test with real content containing a phone number and a Latin product name in the same sentence, which is the case that fails.

This interacts with accessibility as well: a screen reader needs the lang attribute to switch voice, and a mirrored layout with the wrong reading order confuses the virtual cursor. The accessibility guide covers the attributes involved.