How Multilingual an AI Product Needs to Be for a Global Launch

The usual answer to this is a number between ten and thirty, arrived at by looking at a list of the world’s most-spoken languages. The argument here is that the list is the wrong input, the curve flattens much earlier than it appears to, and the honest answer for most products is a handful — chosen by revenue geography, not by population.

The coverage curve, and where it flattens

Start with the shape of the distribution, because it is the part people reason about correctly. Speaker populations follow a steep power law. The largest languages by combined first- and second-language speakers — English, Mandarin Chinese, Hindi, Spanish, Arabic in aggregate, French, Bengali, Portuguese, Russian and Urdu — are each counted in the hundreds of millions. By the twentieth entry the figures are in the high tens of millions, and by the fiftieth they are in the low tens.

The curve is steep, so adding the second language buys far more than adding the twelfth, and adding the thirtieth buys almost nothing. That much is standard. But the curve as usually drawn overstates its own early gains in two ways, and both matter more than the flattening.

First, the totals double-count: a large share of the second-language speakers of English are also counted in Hindi, Spanish or French. Summing the top ten does not give you a population, it gives you a number larger than the population you would actually reach. Second, English absorbs the top of the curve for exactly the audiences most products sell to — professionals, developers, and urban consumers in high-income markets are disproportionately comfortable operating in English.

Why speaker count is the wrong axis

This is the core of the argument. Speaker population is a proxy for nothing you care about. What you care about is the number of people who will pay you, and that quantity is governed by market size, payment infrastructure, purchasing power, regulatory access and competitive position — none of which correlates strongly with speaker count.

Bengali has an enormous speaker population and a small addressable software market. Dutch, Swedish, Danish and Norwegian have small populations, very high English proficiency, and large software spending. Japanese has a moderate population, low English proficiency and an unusually strong preference for localised products — which makes it a high-return localisation despite ranking well below several languages nobody would localise into first.

A related axis is worth checking, and is easier to get than speaker data: the language distribution of web content. Surveys such as W3Techs’ content-language survey consistently put English at close to half of surveyed websites, far above its share of speakers. That gap is the same gap that shows up in training corpora — the subject of which languages dominate training data — and it is the reason both model quality and user expectation lean English-ward well beyond what population figures predict.

What a language actually costs to maintain

The other half of the argument is that the cost curve is nearly flat per language, which is what turns a shallow benefit curve into a bad deal. Generating text in a new language is close to free now — that is genuinely new, and it is what makes people overestimate how cheap launching in twelve languages is. The generation was never the expensive part.

• Locale correctness, not translation. Plural categories, date and number formats, currency placement, name order, address shape, sort order and week start all vary independently of the language and each has its own failure. The plural rules alone are a real system: CLDR defines up to six plural categories and languages such as Polish, Russian, Arabic and Welsh use several of them.
• Evaluation. Every language needs its own quality check, and for most of them no public benchmark exists — the situation described on languages with no standard AI benchmark. Without one you are shipping generated text you cannot assess.
• Support. Inbound messages arrive in the languages you advertise. A language you launched in is a language you have committed to staffing, or to answering badly.
• Legal and policy text. Terms, privacy notices and consumer-rights disclosures are the documents where a machine translation error is a liability rather than an embarrassment, and several jurisdictions require a local-language version.
• Ongoing drift. Every product change invalidates strings in every locale. This cost recurs forever and scales linearly with the number of locales.

Set a flat recurring per-language cost against a benefit curve that has already flattened by the sixth or eighth language, and the crossing point arrives early. Most teams cross it without noticing, because the launch cost is visible and the maintenance cost arrives quarterly.

The number, and how to arrive at yours

The defensible answer is: English plus the languages of the markets producing your revenue, which for most products at launch is between two and five, and rarely more than eight even at scale. Not because more languages are undesirable, but because a language done properly is worth more than three done badly, and the third-done-badly one generates support load and refunds rather than revenue.

To arrive at your own number, do this rather than consulting a population table. Look at where your existing traffic comes from and which of it converts. Look at where your competitors are absent. Check the Accept-Language headers you are already receiving. Then check model quality in each candidate language against your own small evaluation set, because for a language in the tail your product quality is capped by the model’s, and a language where the model is weak is a language you should not launch in regardless of its market size.

A tiered alternative to launching in twelve

The false choice is between full localisation and English only. A tiered approach captures most of the coverage at a fraction of the recurring cost, and it degrades honestly:

• Tier 1 — fully localised. Interface, generated output, documentation, support, legal text, and per-language evaluation. Two to four languages.
• Tier 2 — interface and output. The product works in the language and the model responds in it, with documentation in English and support in English. Another handful.
• Tier 3 — respond in the user’s language. No localised interface, but the model answers in whatever language the user writes in. This costs almost nothing to enable and covers the long tail, provided you handle the case described on output language ignoring the instruction.

The discipline that makes tiering work is being explicit about which tier a language is in, both internally and to the user. A product that silently answers in a language it has never evaluated is making a quality claim it cannot support; one that says which languages it is tested in, and answers helpfully in the rest, is making a claim it can keep. That distinction, rather than the raw count, is what “multilingual enough” should mean.