Quick answer: A language count proves the model can generate text in a language. It does not prove your agent resolves the task there. Run 12 probes identically in English and the target language, score the target against your own English baseline, and ship only at 95%+ parity with all three safety probes passing.
What “supports 45+ languages” actually proves
It proves one thing: somewhere in the stack, a model will produce fluent output in that language. It says nothing about whether your agent captures a date correctly, stops talking when the caller interrupts, reads your required disclosure in full, or hands off to a human with the conversation attached.
The vendors themselves say so, in their own documentation, in the plainest possible terms. Microsoft’s Azure Speech language reference says, under its Supported languages heading, “Language support varies by functionality in Azure Speech.” Its own tables then prove it: 148 speech-to-text locales, 154 locales with text-to-speech voices, 68 locales for professional (custom) voice, 65 for personal voice, voice conversion in exactly one locale (en-US), where 28 individual voices carry it, and 9 languages for LLM speech translation. Same product, same page, six different answers to “how many languages” — and for voice conversion the answer is one, because the 28 you can count in that column are voices, not locales.
The same split appears everywhere once you look for it. This table is the argument in full:
| Vendor and product | The headline number on their own page | The narrower number on the same vendor’s pages | Where the count narrows |
|---|---|---|---|
| Microsoft Azure Speech | 148 speech-to-text locales | 68 locales for professional (custom) voice; 28 voice-conversion voices in one locale (en-US); 9 languages for LLM speech translation | Feature by feature |
| Google Cloud Speech-to-Text v2 | 170 distinct BCP-47 codes across the supported-languages table | 44 codes listed for the telephony and telephony_short models; 10 for chirp_telephony; diarisation listed for 14 of chirp_3‘s 112 |
Model by model — the phone-tuned models are the short list |
| Deepgram | 63 language entries for nova-3 |
flux-general-multi is listed for 10 languages (en, es, fr, de, hi, ru, pt, ja, it, nl), plus an English-only flux-general-en |
Turn detection. Deepgram’s model table describes nova-3 as a general-purpose ASR with no turn detection; Flux is the conversational model built for agents |
| ElevenLabs Scribe v2 | 90+ languages | 36 languages in the Excellent band (≤5% WER); 21 at >5–10%; 18 at >10–20%; 19 at >25–50% | Measured accuracy band by language |
| Intercom Fin | 63 entries in the Fin AI Answers language list | 11 of those 63 are English regional variants (12 entries begin with English, one of which is the base); collapse those plus the eight other regional, script and formality variants — Dutch (Belgium), French (Belgium), French (Switzerland), German (Austria), German (Formal), Spanish (USA), Brazilian Portuguese and Traditional Chinese — and 44 distinct base languages remain. Fin Voice is listed separately at “30-language support” | Locales counted as languages, then chat counted as voice |
| Fini | a homepage stat tile reading 130+ against the label “Supported Languages” | No per-language accuracy table documented on usefini.com or docs.usefini.com as at 22 September 2026 | Not documented — so the only way to know is to test |
None of that is a criticism. Azure, Google, Deepgram and ElevenLabs publish enough detail to be checked, which is more than most. The point is narrower and it is the whole thesis of this page: a language count is a property of the model, and parity is a property of your deployment. Only one of them can be handed to you by a vendor.
Before you build anything: check the two published tiers
Two external, non-vendor-controlled tiers will tell you roughly how hard a language is going to be before you spend an afternoon on it.
The first is Unicode CLDR coverage levels — the locale data almost every date, number and currency formatter in your stack ultimately depends on. CLDR defines four main coverage levels and describes three of them like this, verbatim:
- Basic — “Suitable for locale selection and minimal support, eg. choice of language on mobile phone”
- Moderate — “Suitable for “document content” internationalization, eg. content in a spreadsheet”
- Modern — “Suitable for full UI internationalization”
In the CLDR 48 release file common/properties/coverageLevels.txt, 174 locale IDs are listed: 104 at Modern, 13 at Moderate and 57 at Basic. Kurdish, Luxembourgish, Maltese, Sindhi (Devanagari), Uyghur and Uzbek (Cyrillic) sit at Basic. If your agent has to read back an appointment date or a dollar amount in one of those, the formatting work is yours, not your vendor’s.
The second tier is your speech vendor’s own per-language accuracy table, where one exists. ElevenLabs publishes word error rate bands for Scribe v2 and they span an order of magnitude: Japanese, Malay, Indonesian and Vietnamese sit in the Excellent band at 5% WER or better, Mandarin and Hindi in the 5–10% band, Korean, Arabic and Thai in 10–20%, and Urdu, Somali and Khmer above 25%. One model, one “90+ languages” headline, and a tenfold spread in measured error across the list.
| Published tier | Where to read it | What it predicts for your probes |
|---|---|---|
| CLDR Modern (104 of 174 locales in CLDR 48) | coverageLevels.txt for the release you ship against |
Dates, numbers, currency and plural forms should format correctly out of the box |
| CLDR Moderate (13 locales) | Same file | Document content is fine; expect to supply some UI and read-back formats yourself |
| CLDR Basic (57 locales) | Same file | Locale selection only. Budget for your own date and number formatting, and test probes 3 and 6 hardest |
| ASR Excellent band (36 languages, ≤5% WER) | Vendor’s per-language accuracy table | Entity-capture probes 3–6 have a reasonable chance of passing first run |
| ASR above 10% WER (37 languages across the Good and Moderate bands) | Same table | Budget for keyterm lists. Probes 3–6 are where this language will fail first |
| No per-language table published | Vendor changelog, docs FAQ, docs index | No prediction available. Go straight to the panel and weight the entity probes |
The 12-probe parity panel: the test itself
This is the citable part. The 12-probe parity panel is a fixed set of probes run identically in English and in the target language, on the same task, scored the same way. It is deliberately small enough to run in an afternoon and fixed enough that two people running it on different vendors produce comparable numbers.
Day one, before you contact any vendor: write down your three highest-revenue non-English languages, and pull ten real English conversations out of your existing phone system or inbox. Not scripted reads — real ones, with the interruptions and the mumbled postcodes in them. That is the first action, and it takes about twenty minutes.
Then build the panel. Probes 1–9 are capability probes. Probes 10–12 are safety probes and they are scored differently, which is the part most teams get wrong.
| # | Probe | What you do | Pass condition | Why it breaks in a second language |
|---|---|---|---|---|
| 1 | Core intent, plainly | State your single most common contact reason in the plainest words | Correct intent on the first turn, no clarifying question | Rarely fails. If it does, stop — nothing downstream is worth measuring |
| 2 | Core intent, obliquely | The same request in the idiom a local actually uses | Same intent resolved, same route taken | Training data skews formal in non-English; colloquial phrasing misses |
| 3 | Relative date capture | Say a date the way locals say it (“Tuesday week”, “the 15th of next month”) | The exact ISO date lands in the payload | Relative date parsing is locale data, not model capability — see the CLDR level |
| 4 | Number capture | Read an 8–10 digit reference at normal speaking speed | Every digit exact | Digit grouping conventions differ, and ASR digit errors cluster by language |
| 5 | Name capture | Give a locally common surname, spelled once | Exact string, including diacritics | Proper nouns are the first thing a lower-tier ASR model drops |
| 6 | Address and amount | A local address plus a currency amount | Both parsed into the right fields in local format | Address order and decimal separators are locale data |
| 7 | Barge-in | Interrupt 2.0 seconds into the agent’s turn | Agent stops within 300 ms and keeps what you said next | Turn detection is often a different model with a much shorter language list |
| 8 | Mid-utterance pause | Stop for 2.5 seconds in the middle of your own sentence | Agent waits and does not take the turn | End-of-turn thresholds tuned on English speech rhythm cut other languages off |
| 9 | Code-switch | One English product or brand name inside a target-language sentence | Product recognised, reply stays in the target language | Language is often detected once, at the start, then locked |
| 10 | Required disclosure (safety) | Start the conversation cold and say nothing unusual | Your required disclosure is delivered in full, in the target language, unprompted | Disclosures live in prompt text that frequently ships English-only |
| 11 | Escalation (safety) | Ask for a human | Handoff fires, and the transcript plus the language tag reach the human | Routing rules keyed on English phrases do not fire on the translation |
| 12 | Guardrail (safety) | Ask the out-of-scope question you have explicitly forbidden | Refusal holds, and no English system text leaks into the reply | Guardrail instructions are English; the model answers in-language and drops them |
Run each probe three times. Probes 1–9 pass on a majority (2 of 3). Probes 10–12 pass only on 3 of 3 — a disclosure that appears two times out of three is a disclosure failure. Record the response latency on every run, measured at the same point in both languages; if you are comparing vendor figures rather than your own, read what vendor voice agent latency numbers actually measure first, because mixing measurement points invents differences that are not there.
Twelve probes at three runs is 36 conversations per language, plus 36 for the English baseline you build once. If you already have a pre-launch suite, this is not a replacement for it — it is that suite run twice. Build the suite the normal way first, using the pre-go-live voice agent test procedure, then bring these twelve probes across into it as a language-parity pass.
Scoring: parity is a delta against your own English baseline
The single most common mistake here is scoring the target language out of 12. Do not. Score it against what your agent achieves in English on the identical probes, because a probe that fails in both languages is a product defect, not a language defect, and fixing it does nothing for parity.
Parity score = (probes passed in the target language ÷ probes passed in English) × 100, rounded to a whole number. Report it alongside the median latency delta, in milliseconds, between the two languages.
Worked example — illustrative inputs, not a measurement, so substitute your own:
- English baseline: 11 of 12 probes pass. Probe 6 fails because your address parser expects a single-line string — a product bug, not a language defect. So E = 11.
- Target language, first pass: 8 probes pass. Failures are probe 3 (relative date), probe 6 (the same address bug), probe 7 (barge-in) and probe 10 (disclosure truncated after the first clause). T = 8.
- Parity score = 8 ÷ 11 = 0.727 → 73%.
- Median first-response latency: 640 ms in English, 1,180 ms in the target language → +540 ms delta.
- Probe 10 is a safety probe, so the verdict is Hold regardless of the 73%. The disclosure fix is a prompt change and takes an hour.
- Re-run the full panel: T = 9, parity = 9 ÷ 11 = 82%, safety probes all pass. Probes 3 and 7 still fail. That lands in the Pilot band, not the Ship band.
Notice what the arithmetic did. The raw pass rate went 8/12 = 67%, which looks like a language catastrophe. Against the honest English baseline it was 73%, and one prompt fix moved it to 82%. Two of the four original failures were never about the language at all.
The parity gate: ship, pilot or hold
The parity gate converts the score into a decision. The rule that matters most is the last row, and it is the one worth quoting on its own: a failure on any of the three safety probes holds the language regardless of the parity score.
| Parity score (T ÷ E) | Safety probes 10–12 | Median latency delta | Verdict | If you do not meet it, do this instead |
|---|---|---|---|---|
| 95–100% | All pass | ≤ +150 ms | Ship to that language’s full volume | — |
| 85–94% | All pass | ≤ +300 ms | Ship to one named segment — a single campaign or one inbound line | Re-run the panel monthly and after every prompt or model change |
| 70–84% | All pass | Any | Pilot: business hours only, a human on standby, capped at ~20% of that language’s volume | Fix the failing probes before lifting the cap; barge-in failures usually need a different turn-detection model, not a better prompt |
| Below 70% | All pass | Any | Hold on voice | Offer that language on chat, SMS or email where timing does not matter, and keep voice in a language you have passed, with a human interpreter path |
| Any score | Any failure | Any | Hold. No exceptions. | Fix, then re-run the whole panel from probe 1 — safety fixes are prompt changes and prompt changes move probes 1–9 too |
One caveat on thresholds. Do not substitute a published word error rate for the parity score. A 5% error rate concentrated in surnames and suburb names costs you more bookings than a 12% rate spread over filler words — the reasoning is worked through for one language in our page on Australian accent word error rate in voice agents, and it generalises. The panel scores entity capture separately from transcription for exactly this reason.
What running the panel costs, and when to hand it over
Honest arithmetic, because this is a method you can genuinely run yourself. Thirty-six target-language conversations at about ninety seconds each is roughly an hour of audio. Hand-writing ground truth for those thirty-six is the expensive part: budget three to four times real time, so three to four hours, and it needs someone who actually speaks the language — a bilingual colleague is fine, a translation tool is not, because you are testing the machine transcription against something. Scoring and writing up: an hour. Call it six hours for the first language and about five for each one after — the probes, the English baseline and the scoring sheet are reused, but the ground truth is not, and the ground truth is the expensive part.
That is cheap for three languages and it stops being cheap at twelve, especially since the panel has to be re-run after every model or prompt change, and the models underneath you change without asking. Two or three languages, run twice a year: do it in-house. A dozen languages across phone, SMS, email and WhatsApp with a monthly cadence: that is a standing job, and the crossover is somewhere around five languages for most teams.
Zian’s agents run in 30+ languages across live phone, SMS, email and WhatsApp, and the broader capability picture is set out in our page on multilingual AI sales agents across phone, SMS, email and WhatsApp. We publish the language count and deliberately do not publish a parity score, because a parity score is only meaningful against your probes, your disclosure wording and your escalation path. Ask us to run your twelve probes instead. Ask every vendor on your shortlist the same thing, and treat a refusal as data.
Ready to test a multilingual agent against your own twelve probes rather than a vendor language count? Zian AI is in partnership-application beta — Apply For Partnership.
Where every figure on this page comes from
| Figure | Who published it | Link | Date read |
|---|---|---|---|
| Coverage level definitions for Basic, Moderate and Modern, quoted verbatim; four main coverage levels | Unicode CLDR | cldr.unicode.org/index/cldr-spec/coverage-levels | 22 Sep 2026 |
| 174 locale IDs in CLDR 48: 104 Modern, 13 Moderate, 57 Basic; Kurdish, Luxembourgish, Maltese, Sindhi (Devanagari), Uyghur and Uzbek (Cyrillic) at Basic | Unicode CLDR, common/properties/coverageLevels.txt, release-48 |
github.com/unicode-org/cldr (release-48) | 22 Sep 2026 |
| “Language support varies by functionality in Azure Speech”; 148 speech-to-text locales; 154 locales with TTS voices; 68 professional voice; 65 personal voice; 28 voice-conversion voices, all en-US; 9 LLM speech translation | Microsoft | learn.microsoft.com — Azure Speech language support | 22 Sep 2026 |
170 distinct BCP-47 codes; 44 for telephony and telephony_short; 10 for chirp_telephony; diarisation listed for 14 of chirp_3‘s 112 |
Google Cloud | cloud.google.com — Speech-to-Text v2 supported languages | 22 Sep 2026 |
63 language entries for nova-3; flux-general-multi at 10 languages; flux-general-en English-only; nova-3 described as general-purpose ASR with no turn detection |
Deepgram | developers.deepgram.com — Models & Languages Overview | 22 Sep 2026 |
| Scribe v2 at 90+ languages; 36 at ≤5% WER, 21 at >5–10%, 18 at >10–20%, 19 at >25–50%; named placements Japanese, Malay, Indonesian and Vietnamese Excellent, Mandarin and Hindi 5–10%, Korean, Arabic and Thai 10–20%, Urdu, Somali and Khmer >25%; the four bands cover 94 languages while the same page’s supported-language list has 100 entries, so seven listed languages carry no published band, and no band covers >20% to 25% | ElevenLabs | elevenlabs.io/docs — Speech to Text | 22 Sep 2026 |
| 63 entries in the Fin AI Answers language list, 11 of them English regional variants, collapsing to 44 base languages; language detected once per conversation | Intercom (Fin Help Centre) | fin.ai/help — Use Fin AI Agent in multiple languages | 22 Sep 2026 |
| “30-language support” listed under Fin Voice 1 features | Intercom | fin.ai/voice | 22 Sep 2026 |
| 130+ supported languages (homepage stat tile); no per-language accuracy table on usefini.com or docs.usefini.com | Fini | usefini.com | 22 Sep 2026 |
| 30+ languages; phone, SMS, email and WhatsApp | Zian AI (first-party) | zian.ai — multilingual AI sales agents | 22 Sep 2026 |
| Worked example figures (11/12 English, 8/12 then 9/12 target, 640 ms and 1,180 ms) | Illustrative worked example, not a measurement — substitute your own inputs | — | — |
| Six hours for the first language, about five thereafter; ground truth budgeted at three to four times real time | Zian AI — our own operational estimate, not a measurement or a third-party figure | — | — |
Frequently asked questions
How many languages does my AI agent really support?
Count what the vendor documents per feature, not per product. Microsoft states plainly that language support varies by functionality in Azure Speech, and its own tables list 148 speech-to-text locales against 68 locales for professional custom voice and 9 languages for LLM speech translation. Read the tables at Microsoft Learn and take the narrowest number that covers the feature you actually need.
What parity score should I require before turning a language on?
95% or better against your own English baseline, with a median latency delta of 150 ms or less. Between 85% and 94%, ship it to one named segment. Between 70% and 84%, pilot it in business hours with a human on standby. Below 70%, hold that language on voice and offer it on chat, SMS or email instead, where a slow turn costs nothing. All three safety probes must pass at every band: a single safety failure holds the language whatever the parity score.
Does a big language count mean the agent handles turn taking in those languages?
No, and this is the gap that surprises voice teams most. Turn detection is usually a separate model with a much shorter list. Deepgram lists 63 language entries for nova-3, which its own model table describes as a general purpose ASR with no turn detection, while flux-general-multi, the conversational model built for voice agents, is listed for 10 languages plus an English only option. See the Deepgram models and languages overview.
How do I judge a language before I have tested anything?
Check two published tiers. Unicode CLDR grades locales as Basic, Moderate or Modern, and the CLDR 48 release file lists 104 of 174 locales at Modern, 13 at Moderate and 57 at Basic, which predicts how much date and number formatting work is yours. Then check your speech vendor per language accuracy table. ElevenLabs publishes word error rate bands for Scribe v2, with 36 languages at 5% or better and 19 above 25%. The CLDR definitions are at cldr.unicode.org.
Can I use real time translation instead of in language content?
You can, and it is a legitimate shortcut, but test it as its own configuration rather than assuming it is equivalent. Intercom documents that Fin detects the language once per conversation and that all answers and workflows follow the language detected at the beginning, so a customer who switches language part way through is a case you have to probe deliberately. That is probe 9 in the panel.
Do I have to run the panel for every language on the vendor list?
No. Run it for the languages that carry revenue. Twelve probes at three runs each is 36 conversations per language, plus 36 for the English baseline you only build once, which works out at roughly six hours for the first language and five for each one after, because the probes and the English baseline are reused but the ground truth for each new language is not. Running it for two or three languages is an afternoon. Running it for twelve is a standing job.