TTS Language Routing: Why One Model Per Locale Beats a Global Default

TLDR: TTS language routing is the production rule that selects a model and voice per locale instead of one global engine. ElevenLabs language counts change by model: Multilingual v2 is 29, Flash v2.5 is 32, v3 is 70+, v4 is 90+. Cartesia Sonic 3.6 lists 44 languages. Amazon Polly binds each voice to a language code. A catalog count is not a production score.

TTS language routing is the decision layer that maps each utterance's locale to a specific engine, voice ID, and language code before synthesis. The core answer is that multilingual marketing copy hides per-model tables, so a single default engine will accept Korean or Odia text and still ship English-biased audio. It matters because HTTP success does not mean the locale was in that model's list.

This is not TTS provider failover (retry on error) and not a pronunciation lexicon (grapheme maps). Routing is the choice of which engine you even call.

What is TTS language routing?

TTS language routing is a lookup: locale in, model plus voice plus language parameter out. You run it before the first byte of audio. It is not "the vendor supports many languages," which is a catalog claim. It is "this utterance uses this engine because we measured it for this locale."

A useful mental model is three layers:

1. Catalog: the vendor language list for that model ID.
2. Binding: the voice ID and language / locale field the API requires.
3. Score: a pronunciation check on the clip, not WER on a transcript of English.

Skip layer 3 and you will keep the cheapest global default forever.

How do vendor language tables actually differ?

They differ by model ID, not by brand homepage.

ElevenLabs is explicit: pick a voice whose accent matches the target language. Cartesia is explicit: set language such as en or a regional locale such as en-GB. Polly will reject or degrade if you pair Joanna (en-US) with Hindi text. Those are routing inputs, not post-production fixes.

Why does a global default TTS model fail in production?

A global default fails because the API will often still return audio. The miss is phonetic, not HTTP.

Typical failure modes:

• Wrong table: Flash v2.5 covers Vietnamese. Multilingual v2 does not list it. Same ElevenLabs account, different model ID.
• Wrong binding: Cartesia gets text in Urdu without language: ur.
• Wrong voice: An English-trained clone speaking Japanese script with English timing.
• Wrong engine class: Polly Standard for a locale that only has Neural, or Neural for a locale that only has Standard (Icelandic is-IS is Standard-only on the public table).

TTS evaluation methodology already warns that WER on ASR of the clip measures lexical match, not native pronunciation. Language routing is the control that decides which model even enters that scorecard.

Failover without routing copies the same bad default onto the backup. Routing without failover still dies when the chosen region's quota hits. You need both.

How should production teams route TTS per locale?

Keep a locale table above any vendor console, then compile.

A working loop:

1. Inventory locales you actually ship (BCP-47), not languages marketing listed.
2. For each locale, store primary model ID, voice ID, language/locale field, and a scored backup that is a different vendor, not a sibling model with the same gap.
3. Reject synthesis if the locale is missing from that model's documented list.
4. Score the clip for pronunciation of brand terms in that locale (lexicon compile still applies).
5. Pin snapshots when the vendor versions the table (Cartesia dated sonic-3.6-YYYY-MM-DD).

Onepin is a voice workflow platform that orchestrates, validates, and ships production-ready audio across 100+ TTS models. Locale routing sits above ElevenLabs model IDs, Cartesia language fields, and Polly voice codes. You are not locked to one language table when a new market goes live.

If every locale still hits the same model_id, you do not have routing. You have a default. Start at onepin.ai/docs.