Multilingual bots: detection, registers, and what never gets translated
Language is not locale. Where automatic detection fails, why formality is a correctness problem, and which messages must be written by a human translator.
On this page
- What we'll cover
- Language, locale and the difference
- Where automatic detection fails
- Code-switching, which is normal
- Formality is a correctness problem
- Building it with CodeWords
- What must never be machine translated
- The escalation problem
- Scripts, direction and the things that break
- Testing in a language you do not speak
- Making it survive
- Limits worth knowing about
- What to build first
- Frequently asked questions
- Related reading
Answering somebody in the language they wrote to you in is one of the genuinely large improvements available in conversational automation, and modern models make the basic version nearly free. The difficulty is that the basic version is where most implementations stop, and the gap between "replies in French" and "usable by French speakers" contains everything that matters.
Language is also not the same as locale. Somebody writing in Portuguese may be in Lisbon or São Paulo, with different currencies, different date formats, different opening hours and different consumer rules. Getting the language right while getting all of that wrong produces something that reads fluently and is useless.
What we'll cover
- Language, locale and the difference
- Where automatic detection fails
- Code-switching, which is normal
- Formality is a correctness problem
- Building it with CodeWords
- What must never be machine translated
- The escalation problem
- Scripts, direction and the things that break
- Testing in a language you do not speak
- Making it survive
- Limits worth knowing about
- What to build first
- Frequently asked questions
Language, locale and the difference
Language decides the words. Locale decides almost everything else, and it is set by where somebody is rather than what they speak.
Dates. The same eight digits mean different days in different places, and an appointment confirmation is precisely where that matters.
Currency and price presentation. Symbol, position, separators, and whether tax is shown inclusive.
Addresses and postcodes, which have genuinely different shapes and different validation.
Phone number formats, including whether a leading zero is dropped.
Opening hours and holidays, which differ within a single language.
Consumer rules. Cancellation rights, cooling-off periods and what a quote has to state vary by country, not by language.
The practical consequence: store language and locale separately, infer locale from something reliable rather than from the language, and write dates out in words where there is any doubt. "Thursday 14 May" is unambiguous everywhere.
Where automatic detection fails
Detection works well on a paragraph and poorly on the messages people actually send.
Very short messages. "Ok", "si", "no", "merci" are ambiguous or shared between languages, and the first message in a conversation is frequently one of them.
Names and addresses, which 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 rather than its own defeats naive detection entirely, and it is extremely common in messaging.
Voice notes, where detection depends on transcription quality, which depends on accent and background noise.
Two things help more than a better detector. Decide on the basis of a few messages rather than one, and let people set it explicitly and remember that choice, because a stated preference beats any inference.
Code-switching, which is normal
Plenty of people mix languages within a single message, particularly for technical terms, product names and numbers. This is ordinary behaviour rather than an edge case, and a system that treats each message as being in exactly one language will oscillate.
Two rules. Be sticky: once a language is established for a conversation, keep it unless there is clear evidence to change, rather than re-detecting on every message. And never translate proper nouns, product names, model numbers, registrations or reference codes, which is a surprisingly common failure and produces references nobody can look up.
Formality is a correctness problem
Many languages distinguish formal and informal address grammatically, and there is no neutral option. Every sentence takes a position.
Getting it wrong is not a stylistic wobble. In some contexts informal address to a stranger reads as rude, and in others excessive formality reads as cold or sarcastic. The appropriate register also varies by country within a language and by the nature of the business.
So decide per language, deliberately, with somebody who speaks it. Then apply it consistently, since drifting between registers within one conversation is more jarring than picking the less usual one and sticking to it. Honorifics, name order and how to address somebody you have not met are all part of the same decision.
Building it with CodeWords
CodeWords connects to more than 3,000 integrations, and the connection is made once and reused.
- Open CodeWords and start a new automation.
- 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.
- Authorize the connections to your customer records and your WhatsApp Business Platform account, storing the language preference against the customer rather than the conversation.
- Describe the exceptions: a language you do not support, a mixed-language message, anything requiring escalation, anything legally sensitive.
- Have a speaker of each language read real conversations before you launch in it, because this is the one area where testing it yourself tells you nothing.
You describe the outcome; Cody builds it, connects it, and deploys it. The free plan covers light use, with Pro at $39 per month and Business at $100 per month as usage grows; details are on the pricing page.
What must never be machine translated
The line worth drawing firmly.
Safety instructions. What to do about a gas smell, a chemical, an allergic reaction. These need a human translation, checked, and they are worth paying for.
Legal and contractual text. Terms, cancellation rights, consent wording, anything that has to mean a specific thing.
Medical or clinical content, which should be produced by whoever is qualified to produce it, in each language.
Prices and what they include, where an ambiguity becomes a dispute.
Anything regulated. Financial promotions, health claims and similar carry requirements that differ by jurisdiction.
For everything else, generated translation is fine and is a large improvement on replying in a language the customer does not read. For these, use pre-written text produced by a person and stored as a fixed string.
The escalation problem
The failure nobody designs for: the bot handles a conversation in a language nobody in your business speaks, and then something needs a person.
Now you have a customer mid-problem, expecting continuity, and whoever picks it up cannot read the thread. Doing this badly is worse than never having offered the language, because you raised an expectation and then dropped it at the hardest moment.
Three workable positions. Support the language fully, with somebody who can take over. Support it for straightforward work and say plainly, early, that complex matters will be handled in another language. Or do not offer it. All three are honest; the one that damages you is offering it and discovering the gap during a complaint.
Where you translate for a human agent, tell the customer that is what is happening. People are far more tolerant of an imperfect translated reply from a person than of discovering it afterwards.
Scripts, direction and the things that break
Practical details that cause visible problems.
Right-to-left scripts, where mixed text with Latin numerals and references needs checking rather than assuming.
Length. Translated text can be substantially 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 in another.
Names. Order, honorifics, characters outside a narrow set, and anything that assumes a first and last name.
Sorting and matching, where accents and case behave differently than you expect.
Most of these are found by putting real text through the system rather than by reasoning about it.
Testing in a language you do not speak
You cannot check this yourself, which is the uncomfortable part.
Get a speaker to read real conversations, not sample sentences. Fluency is not the question; appropriateness is.
Ask specifically about register, because it is the thing a fluent reader notices immediately and a translator asked for accuracy will not mention.
Test the failure messages. The apologetic "I did not understand" is the sentence most likely to read badly in translation and the one nobody checks.
Test the templates, which are pre-approved and fixed, so an error there ships to everybody.
Ask for a sample review periodically, since prompts and content drift.
Making it survive
Store language and locale separately, and let customers set language explicitly.
Keep safety, legal and price text as fixed human translations.
Check template length in every language before submitting them.
Be sticky within a conversation rather than re-detecting each message.
Have a speaker review real conversations quarterly.
Limits worth knowing about
Detection is unreliable on short messages, which is most of what people send.
Fluent output is not correct output, and 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 places, and getting the language right does not satisfy them.
What to build first
The explicit language choice, stored against the customer. One question, once, remembered afterwards, which removes most detection failures without any detection at all and gives people something they can correct.
Two habits make the difference. Keep safety, legal and price wording as fixed human translations, because those are the sentences where a fluent approximation does real harm. And decide what happens when the conversation needs a person before you launch in a language, since 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; locale decides dates, currency, address formats, opening hours and consumer rules, and it follows where somebody is rather than what they speak. Store them separately.
Why does automatic language detection fail?
Short messages, names, closely related languages, transliteration into Latin script, and voice notes where transcription quality varies. Most first messages are exactly the hard case.
How should the language be chosen?
Let people set it explicitly and remember it. Where you must infer, decide on several messages rather than one and stay with that choice unless there is clear evidence to change.
What about people who mix languages?
Normal behaviour rather than an edge case. Be sticky within a conversation, and never translate proper nouns, product names, model numbers or reference codes.
Why does formality matter?
Many languages distinguish formal and informal address grammatically, with no neutral option. The wrong register reads as rude or as cold, and the right one varies by country and by trade. Decide with a speaker.
What should never be machine translated?
Safety instructions, legal and contractual wording, clinical content, prices and what they include, and anything regulated. Use pre-written human translations stored as fixed text.
What happens when a conversation needs a person?
Decide before launching. Either staff the language, or say early and plainly that complex matters will be handled in another language. Discovering the gap during a complaint is the bad outcome.
What breaks technically?
Right-to-left mixed text, translated length against character limits in templates and buttons, name assumptions, and sorting or matching with accents.
How do I test a language I do not speak?
Have a speaker read real conversations rather than sample sentences, ask specifically about register, and check the failure messages and templates, which are the ones nobody reviews.
Is it better to reply in poor translation or in English?
Fluent and inappropriate is worse than plain and clear. For safety, legal and price wording, pre-written human text; for the rest, generated translation is a genuine improvement.