The Language Routing Contract: Localization Beyond Fluency

Multilingual, cross-cultural and localization engineering proves an AI system works in a language and a culture, not just that it produces fluent text in one. A model can translate cleanly and still misname a local institution, misstate a permission, or answer a question that made sense in English but not in the target language, and one aggregate score hides all of it.

What it is

Localization adapts an interaction to a language, a locale and a culture, and it is broader than translation. Translationese names features of text that has passed through translation, and finding those features in output does not prove a model reasoned in English first, only that the output resembles translated text: native reasoning needs its own test. A refusal-rate comparison across two languages is not interpretable unless the prompts are equally harmful and culturally loaded.

Five capabilities need separate tests, and none validates the others: language proficiency, task reasoning, translation adequacy, local factual knowledge and culturally appropriate interaction. A translationese classifier measures a proxy that can learn genre habits rather than reasoning, so it belongs alongside a native reader's judgment, not in place of it. Original entities, units, dates and names must survive every translation step, and permission boundaries need their own test separate from refusal style, since a polite local-language response can still authorize the wrong action.

Two 2026 studies show both the mechanism and the limits of current evaluation. A study made public August 18, 2026 examined translationese in Gemini-2-Flash and Llama-3.3-70B across five languages and found German classifier flag rates of 60.2 percent and 37.6 percent, a result its own authors do not treat as proof of internal English reasoning, since native checks on 60 sentences per language for German and Spanish diverged from the classifier. SurakshaEval, made public August 8, 2026, covers 2,968 prompts across ten Indic languages plus English and 27 models, and found overall human agreement of 69.2 percent that fell to 44.16 percent on sociocultural judgments, the category where cultural interpretation matters most. A safety average that looks acceptable in aggregate can conceal a rubric barely two in five evaluators agree on for exactly the judgments carrying the most cultural risk.

The architecture

I call the answer the language routing contract: a versioned record attached to a task, not a language label, that forces a routing decision through an explicit gate before any answer is trusted. It exists because picking one model and assuming it behaves the same way in every language it claims to support has no evidence behind it here.

The contract runs in a fixed order. A task first states its language, locale, script and original entities, none discarded once processing begins. It then routes on held-out performance for that workload: native prompting, translate-then-solve, multilingual retrieval when facts only exist in local sources, a language-specific adapter when behavior is narrow enough to justify its upkeep, deterministic conversion for dates and units, or human escalation when the decision depends on local expertise, ambiguous intent or an unverifiable fact. Whichever route runs, the contract checks units, dates, names and authorization scope before the answer is accepted, because a translate-then-solve path compounds error: an illustrative pipeline with a 95 percent chance of preserving meaning, a 90 percent chance of solving the task, and a 97 percent chance of a faithful back-translation succeeds end to end only about 83 percent of the time.

The most common failure is skipping the gate and treating one translated score as global truth. The second is letting a route go unmonitored after a model, tokenizer, glossary or retrieval source updates.

Ownership sits with a named localization owner accountable for the contract across every language shipped, holding the routing decisions, the glossary, and the authority to pull a language back to human escalation without asking permission.

Fund native task construction and native adjudication in every claimed language, and held-out route comparisons priced on translation, retrieval and review, not model tokens alone. Per-language safety testing needs a hard floor: zero violations across 30 prompts still permits an underlying rate near 9.5 percent, and only roughly 300 prompts brings that bound near 1 percent. Stop funding parity claims resting on a translated benchmark with no native check, since SurakshaEval's own agreement rate drops 25 points on the sociocultural judgments that matter most.

Two decisions belong to an executive: which languages get native task construction and adjudication funded, since that budget line turns a claim of supporting dozens of languages into a tested one, and where the human escalation threshold sits, a risk-appetite call a benchmark score cannot make.

What it is worth

Money and risk show up in three places: compute and review spent on a route a matched-cost comparison would have ruled out, incidents where a permission boundary held in the tested language and failed in an untested one, and rework when a translated benchmark score does not predict native performance.

Measure before and after with the same yardstick across languages: native task success, translation-path reliability end to end, per-language safety agreement rather than one global figure, and cost per validated task including translation, retrieval and review. The 2026 evidence supports that translationese detection and native checks can disagree, and that a safety benchmark's agreement rate varies sharply by category. It does not support a matched-cost ranking of native prompting against translation, a settled measure of code-switching cost, or proof that any tested safety boundary holds across every language a deployment will see. No return figure appears in that evidence, and none should be assumed here.