Multilingual is a product decision, not a translation job
Teams usually discover the hard way that a multilingual assistant is not an English assistant with a translation layer bolted on. Language changes how users phrase requests, how long a polite answer should be, which scripts have to render correctly, and which regulations apply. If you treat it as a copy task you end up with an assistant that reads fluently but misreads intent. The planning work happens before the first model call: decide which languages are first-class, what "good" looks like in each of them, and who signs off on the tone in each one.
Start with a language inventory ranked by value and risk
Not every language deserves equal effort on day one. A workable approach is to sort languages along two axes: how much of your audience or revenue they represent, and how expensive a mistake in that language would be.
- Tier 1 — languages where you take real money or handle regulated data. These need native review, monitored quality and a human escalation path.
- Tier 2 — languages with meaningful traffic but low risk. Machine quality is often acceptable if you set expectations clearly.
- Tier 3 — long-tail languages. Cover them with a graceful fallback to a well-chosen lingua franca rather than pretending to support them.
Writing this ranking down early prevents the most common failure: an assistant that is excellent in two languages and embarrassing in fourteen.
Decide where translation lives in your pipeline
There are three broad architectures, and each carries a different cost profile.
- Native multilingual model. One model handles every language directly. Simplest to operate, but quality varies by language and you cannot tune one language without touching the others.
- Translate, then answer. Incoming text is translated into a pivot language, processed, and the answer is translated back. Easy to add languages, but errors compound and idioms get flattened twice.
- Language-specific assistants. A router sends each request to a model or adapter tuned for that language. Best quality, highest operational load.
Most teams land on a hybrid: a native multilingual model for the bulk of traffic, with specialised adapters or prompts for the two or three languages that carry the most weight.
Quality has to be measured per language
A single aggregate score hides the problem you are trying to find. Track accuracy, refusal behaviour and hallucination rate separately for every supported language, using evaluation sets written by speakers rather than translated from English. Watch for two traps: translated benchmarks that are stiffer than real usage, and token arithmetic that quietly changes the economics, because the same sentence can cost several times more in one script than in another.
- Build native test sets of at least a few hundred realistic prompts per Tier 1 language.
- Include code-switching — mixed-language sentences — because real users rarely stay in one language for a whole message.
- Test names, addresses, numbers and dates, which are where locale formatting breaks first.
Encoding, layout and the unglamorous plumbing
Many "multilingual bugs" are not model problems at all. They are UTF-8 handling, right-to-left layout, missing font coverage for CJK or Devanagari, or date and currency formatting. A handful of checks saves weeks of rework.
- Normalise input to UTF-8 end to end, and test emoji, combining marks and zero-width characters.
- Render right-to-left languages properly — a mirrored layout, not merely mirrored text.
- Never uppercase or title-case strings as a display trick; it corrupts many scripts.
- Store the user's language preference explicitly instead of inferring it again on every request.
Fallbacks, escalation and legal expectations
Decide what happens when confidence is low in a language you only nominally support. A short, honest answer in a language the user understands beats a confident wrong answer. Route to a human when a request involves money, health or legal exposure. In some jurisdictions consumers have a right to information in an official language; plan for that from the start rather than retrofitting it after launch.
A practical rollout order
- Pick one Tier 1 language pair and instrument it fully before adding a third.
- Write evaluation sets before you tune anything, so you can prove improvement.
- Ship a visible language switcher; silent detection frustrates bilingual users.
- Review tone with native speakers, not translators working from English drafts.
- Re-measure after every model or prompt change, because multilingual quality drifts quietly.
The teams that get this right treat language as a first-class product dimension. They scope it, measure it per locale, and accept that a small number of well-supported languages beats a long list of shallow ones.
