Multilingual bots: detection, registers, and what never gets translated

To build a multilingual WhatsApp bot, store each customer's language and locale separately, let the customer choose the language explicitly, and use pre-written human translations for safety, legal and price text. Modern models make "replies in French" nearly free. The gap between that and "usable by French speakers" contains everything that matters.

Language is not locale. A customer writing in Portuguese may be in Lisbon or São Paulo, with different currencies, date formats, opening hours and consumer rules. A bot that gets the language right and the locale wrong reads fluently and is useless.

What we'll cover

• Language and locale are different
• Where automatic detection fails
• Code-switching is normal
• Formality is a correctness problem
• Building it with CodeWords
• What must never be machine translated
• The escalation problem
• Scripts, direction and what breaks
• Testing in a language you do not speak
• How to make the bot reliable
• Limits of multilingual bots
• What to build first
• Frequently asked questions

Key takeaways

• Language decides the words and locale decides dates, currency, addresses and consumer rules, so store the two separately.
• Automatic language detection fails on short messages, so ask the customer to choose a language once and remember the choice.
• Safety instructions, legal wording, clinical content and prices need pre-written human translations, not generated text.
• Choose a formal or informal register for each language with a native speaker, and apply it consistently.
• Decide how to hand a conversation to a person before launching a language, because the gap shows up during a complaint.

Language and locale are different

Language decides the words. Locale decides almost everything else, and it is set by where a customer is, not by what the customer speaks.

Dates. The same eight digits mean different days in different places, and an appointment confirmation is where that matters most.

Currency and price presentation. Symbol, position, separators, and whether tax is shown inclusive.

Addresses and postcodes have different shapes and different validation.

Phone number formats differ, including whether a leading zero is dropped.

Opening hours and holidays differ within a single language.

Consumer rules. Cancellation rights, cooling-off periods and what a quote must state vary by country, not by language.

In practice, store language and locale separately, infer locale from something reliable instead of from the language, and write dates out in words where any doubt exists. "Thursday 14 May" is unambiguous everywhere.

Where automatic detection fails

Automatic language detection works on a paragraph and fails on the messages people actually send.

Very short messages. "Ok", "si", "no" and "merci" are ambiguous or shared between languages, and the first message in a conversation is often one of them.

Names and addresses look like nothing in particular.

Closely related languages. A short message in one may be read as another, and answering a Portuguese speaker in Spanish is worse than answering in English.

Transliteration. A language written in Latin script instead of its own script defeats naive detection, and messaging uses it often.

Voice notes. Detection depends on transcription quality, which depends on accent and background noise.

Two measures help more than a better detector. Decide from a few messages instead of one, and let customers set the language explicitly and remember the choice. A stated preference beats any inference.

Code-switching is normal

Code-switching, mixing languages inside one message, is ordinary behaviour. People do it for technical terms, product names and numbers. A system that treats each message as exactly one language will oscillate between languages.

Two rules apply. Be sticky: once a language is established for a conversation, keep it unless there is clear evidence to change, instead of re-detecting on every message. And never translate proper nouns, product names, model numbers, registrations or reference codes. Translating them produces references nobody can look up.

Formality is a correctness problem

Formality is a correctness problem because many languages distinguish formal and informal address grammatically, and there is no neutral option. Every sentence takes a position.

The wrong register is not a style wobble. In some contexts informal address to a stranger reads as rude, and in others excessive formality reads as cold or sarcastic. The right register varies by country within a language and by the nature of the business.

Decide per language, deliberately, with someone who speaks it. Then apply the choice consistently, because drifting between registers inside one conversation is more jarring than picking the less usual register and keeping it. Honorifics, name order and how to address someone you have not met belong to the same decision.

Building it with CodeWords

CodeWords connects to 3,000+ integrations (CodeWords integrations page, 2026), and each connection is made once and reused.

1. Open CodeWords and start a new automation.
2. Describe what should happen in plain language to Cody, the automation builder: which languages you support, how the choice is made and stored, the register for each, and what must use pre-written text.
3. Authorize the connections to your customer records and your WhatsApp Business Platform account, and store the language preference against the customer, not the conversation.
4. Describe the exceptions: a language you do not support, a mixed-language message, anything that needs escalation, and anything legally sensitive.
5. Have a speaker of each language read real conversations before you launch in it. Testing it yourself tells you nothing here.

You describe the outcome; Cody builds it, connects it, and deploys it. The Free plan costs $0, Pro costs $39 per month and Business costs $100 per month (CodeWords pricing page, 2026). Details are on the pricing page.

What must never be machine translated

Never machine translate safety, legal, clinical, price or regulated text. Use pre-written text produced by a person and stored as a fixed string.

Safety instructions. What to do about a gas smell, a chemical or an allergic reaction needs a checked human translation, and the cost is worth paying.

Legal and contractual text. Terms, cancellation rights, consent wording and anything that must mean a specific thing.

Medical or clinical content. A qualified person should produce it in each language.

Prices and what they include. An ambiguity here becomes a dispute.

Regulated content. Financial promotions, health claims and similar content carry requirements that differ by jurisdiction.

For everything else, generated translation is fine and a large improvement on replying in a language the customer does not read.

The escalation problem

The escalation problem appears when the bot handles a conversation in a language nobody in your business speaks, and then something needs a person. The customer is mid-problem and expects continuity, and whoever picks up the thread cannot read it.

Doing this badly is worse than never offering the language, because you raised an expectation and dropped it at the hardest moment.

Three positions are workable:

1. Support the language fully, with someone who can take over.
2. Support it for straightforward work, and say plainly and early that complex matters are handled in another language.
3. Do not offer it.

All three are honest. The damaging option is offering the language and discovering the gap during a complaint. Where you translate for a human agent, tell the customer, because people tolerate an imperfect translated reply from a person better than discovering the translation afterwards.

Scripts, direction and what breaks

Real text breaks a multilingual bot in five visible places.

Right-to-left scripts. Mixed text with Latin numerals and references needs checking.

Length. Translated text can be much longer or shorter, which breaks anything with a character limit, including message templates and button labels.

Buttons and list items have their own limits, and a label that fits in one language may not fit in another.

Names. Order, honorifics, characters outside a narrow set, and any assumption of a first and last name.

Sorting and matching. Accents and case behave differently than expected.

Find these problems by putting real text through the system, not by reasoning about it.

Testing in a language you do not speak

You cannot check a language you do not speak yourself, so test with a native speaker.

Get a speaker to read real conversations, not sample sentences. The question is appropriateness, not fluency.

Ask specifically about register. A fluent reader notices register immediately, and a translator asked only for accuracy will not mention it.

Test the failure messages. The apologetic "I did not understand" is the sentence most likely to read badly in translation, and nobody checks it.

Test the templates. Templates are pre-approved and fixed, so an error ships to every customer.

Repeat the sample review periodically, because prompts and content drift.

How to make the bot reliable

A reliable multilingual bot keeps language data separate, keeps sensitive text fixed and is reviewed by speakers.

Store language and locale separately, and let customers set the language explicitly.

Keep safety, legal and price text as fixed human translations.

Check template length in every language before submitting templates.

Be sticky within a conversation instead of re-detecting on each message.

Have a speaker review real conversations quarterly.

Limits of multilingual bots

Multilingual bots have five limits.

Detection is unreliable on short messages, which are most of what people send.

Fluent output is not correct output. A confidently wrong register reads worse than plain English.

You cannot evaluate your own quality in a language you do not speak.

Supporting a language commits you to supporting escalation in it, which is a staffing decision.

Locale requirements are legal in some places, and getting the language right does not satisfy them.

What to build first

Build the explicit language choice first, stored against the customer: one question, asked once, remembered afterwards. This removes most detection failures without any detection, and gives customers something they can correct.

Two habits make the difference. Keep safety, legal and price wording as fixed human translations, because a fluent approximation does real harm in those sentences. And decide what happens when the conversation needs a person before you launch in a language, because offering a language and then dropping the customer at the hardest moment is worse than never offering it.

Frequently asked questions

Is language the same as locale?

No. Language decides the words, while locale decides dates, currency, address formats, opening hours and consumer rules, and it follows where a customer is, not what the customer speaks. Store the two separately so a Portuguese speaker in Lisbon and one in São Paulo each get the correct details.

Why does automatic language detection fail?

Detection fails on short messages, names, closely related languages, transliteration into Latin script, and voice notes where transcription quality varies. The first message of a conversation is often exactly the hard case, so a bot that relies on detection alone makes mistakes at the start.

How should the language be chosen?

Let customers set the language explicitly and remember the choice. Where you must infer it, decide from several messages instead of one, and stay with that choice unless there is clear evidence to change. A stated preference is more reliable than any inference the bot makes.

What about customers who mix languages?

Mixing languages is normal behaviour, not an edge case. Keep the conversation in one established language and avoid re-detecting on every message. Never translate proper nouns, product names, model numbers or reference codes, because translated references cannot be looked up by staff or customers.

Why does formality matter?

Many languages distinguish formal and informal address grammatically, with no neutral option. The wrong register reads as rude or cold, and the right one varies by country and by trade. Decide the register for each language with a native speaker, and apply it consistently.

What should never be machine translated?

Never machine translate safety instructions, legal and contractual wording, clinical content, prices and what they include, or regulated claims. Use pre-written human translations stored as fixed text, so a fluent but wrong approximation cannot cause harm or create a dispute.

What happens when a conversation needs a person?

Decide before launching the language. Either staff the language so someone can take over, or say early and plainly that complex matters are handled in another language. Discovering the gap during a complaint is the outcome to avoid, because the customer is already frustrated.

What breaks technically in a multilingual bot?

Right-to-left mixed text, translated length against character limits in templates and buttons, assumptions about names, and sorting or matching with accents all break. Put real text from each language through the system to find these problems, because reasoning about them in advance misses most.

How do I test a language I do not speak?

Have a native speaker read real conversations, not sample sentences, and ask specifically about register. Also check the failure messages and the templates, which are the texts nobody reviews and which reach every customer. Repeat the review periodically as prompts change.

Is it better to reply in poor translation or in English?

A fluent but inappropriate reply is worse than plain, clear English. For safety, legal and price wording, use pre-written human text. For everything else, generated translation is a genuine improvement over replying in a language the customer does not read.

Related reading

• Voice messages and lossy transcription
• The edge cases that actually matter
• What a bot should remember