The tempting approach to multi-lingual dialogue is the translation pipeline: translate the user's non-English input to English, run your English NLU model, translate the response back. It is quick to prototype and produces apparently acceptable results in demos. It fails in three specific ways in production, and the failure rate is high enough that teams deploying translation pipelines for bilingual or multilingual user bases consistently rebuild them with per-language models within 12 months. Here is why, and what the correct architecture looks like.
Translation Errors Compound with NLU Errors
A translation pipeline introduces two independent error sources: translation error and NLU classification error. If your MT (machine translation) system has a 5% error rate and your NLU has a 6% error rate, your end-to-end accuracy is not 89% - it is lower, because some NLU errors are caused by the translation errors. Sentences that were correctly translatable but lost nuance in translation arrive at the NLU model as semantically shifted inputs that the model classifies with reduced confidence or incorrectly.
Named entity translation compounds this problem. Proper names, product names, and domain-specific terminology often translate poorly or do not translate at all. "Book me a seat on JAL flight 034" translated from Japanese should leave "JAL" and "034" intact. Translation systems that are not domain-adapted for your entity vocabulary frequently mangle proper nouns, dates in non-standard formats, and domain-specific abbreviations. The entity extractor then operates on corrupted input.
In a benchmark comparison we ran across 1,200 test utterances in Spanish and Japanese (two common non-English support languages), the translation pipeline approach produced 8.3% more NLU errors than per-language models. Most of those errors traced to translation issues rather than NLU model limitations - the NLU model was fine; the input it received was garbled by translation.
Translation Adds Latency
An MT call is a network round-trip to an external service. At typical MT service latency (25-40ms P50, 80-120ms P95 on cloud translation APIs), you are adding 100-250ms to your critical path. For a voice deployment where the total latency budget is 250ms, an MT call consumes it entirely. Even for chat, 100ms of pure overhead for translation is a significant share of your latency budget that produces no user-facing value - it only exists to avoid maintaining per-language NLU models.
Code-Switching Is Invisible to Translation Pipelines
Code-switching is when a user shifts between languages within a single utterance or across turns. "Reserve me una mesa for tonight" (English + Spanish). "Cancel my reservation - ik had het toch al verwacht" (English + Dutch). This is common among multilingual users and appears more frequently in support dialogues where users use their first language for emotional content and the interface language for technical content.
A translation pipeline handles code-switching poorly because it treats the utterance as uniformly one language. A Spanish MT model may not correctly handle the English portion of a mixed utterance, and the resulting translation degrades both portions. Per-language NLU models with a language detection layer handle code-switching better because the language detection can flag mixed-language input and route to a multi-language NLU model trained explicitly on code-switched data.
Code-switching handling is particularly important for Japanese-English (a high-frequency code-switching pair in tech support), Spanish-English in US markets, and Arabic-English in MENA markets. These pairs represent the majority of code-switching events in enterprise dialogue deployments globally.
The Per-Language Architecture
The correct multi-lingual architecture has three layers. First: language detection - a lightweight classifier that identifies the primary language of each turn (runs in under 2ms at production volume). Second: per-language NLU models - separate intent classifiers and entity extractors trained on native-language examples for each supported language. Third: a unified entity state model that is language-independent - the context object stores entity types and values, not language-specific strings. Dates, names, and quantities normalize to the same schema regardless of which language they were extracted from.
The unified entity state layer is the key to making per-language NLU work in practice. Without it, you would need to translate entity values between languages for cross-turn reference to work when a user switches languages mid-conversation. With a language-independent entity schema, the entity is stored as a typed value (DateEntity: 2026-04-15, PersonEntity: "John Smith") and is accessible to the NLU regardless of which language the current turn is in.
Training Data Requirements for Per-Language Models
The objection teams raise to per-language models is training data. If you need 2,000 examples per intent class in English, do you need 2,000 more in Spanish, 2,000 in Japanese, and so on? In practice, no. Transfer learning from multilingual pretrained models (mBERT, XLM-RoBERTa) means per-language fine-tuning requires significantly less data than training from scratch. For languages similar to English in script and syntax, 300-500 per-language examples per intent class is typically sufficient for production quality. For more distant languages (Japanese, Arabic), 500-800 examples per intent class is a more reliable target.
The ongoing maintenance burden is also lower than teams estimate. NLU drift in non-English languages tends to be slower than in English because non-English user vocabulary evolves more slowly in enterprise dialogue contexts. Quarterly retraining cadences that would be insufficient for English are often adequate for secondary language models.
When Translation Pipelines Are Acceptable
Translation pipelines are acceptable in two cases: when your non-English traffic is low enough that per-language model maintenance is economically unjustifiable (under 2% of volume is a reasonable threshold), and when the dialogue use case is simple enough that translation errors are unlikely to produce consequential NLU errors (simple FAQ lookups with no slot-dependent flows). For complex multi-turn task-oriented dialogue with slot-filling and context tracking, translation pipelines consistently underperform per-language models at any traffic volume.
Conclusion
Translation-first is the wrong default architecture for production multi-lingual dialogue systems handling complex, slot-intensive conversations. Compounding errors, latency overhead, and code-switching failures are costs that accumulate with traffic volume. Per-language NLU models with a unified entity state layer scale better, produce lower error rates, and handle the edge cases that translation pipelines systematically fail on. The additional training data investment pays back within the first six months at any deployment with meaningful non-English traffic.