Short answer. Order your languages by four factors scored together, not by speaker counts: the revenue and users each language unlocks, how well base models already handle it, what data will cost to reach your quality bar, and the operational load after launch. Most teams should ship a first wave of three to five languages, then add more in waves.
Key takeaways
- Language order is a portfolio decision across four factors: market value to you, base-model readiness, data cost to target quality, and permanent operational load.
- A CSA Research survey of 8,709 consumers in 29 countries found 76% prefer buying with product information in their own language and 40% will not buy from websites in other languages.
- The cost of reaching the same product quality varies by an order of magnitude between languages, and is highest where base models are weakest.
- A language is supported only when a native evaluation set exists, the model clears the quality bar on it, and a native-speaker escalation path is staffed.
- Translated benchmarks overstate model capability, so readiness must be tested natively or the roadmap will be mis-ordered.
Why is language order a data decision, not just a market decision?
Because supporting a language in an AI product is not a translation line item. It is a data programme covering collection, fine-tuning material and an evaluation set that can tell you whether the product works there, and the cost of that stack varies enormously between languages.
Language support means a language in which the model has been collected for, tuned on and evaluated against native-quality data, not merely a translated interface.
The variance is the point. For a high-resource language, usable text and speech data may be licensable off the shelf and base models already perform well, so your incremental data work is thin. For a low-resource language, the data must be collected rather than found, the field-operations reality described in how speech data is collected for low-resource languages, and base-model quality starts lower, so the data requirement is larger exactly where the data is hardest to get. The same hour of audio can cost from under a dollar through an automated pipeline to over a hundred dollars for specialist human collection, a spread unpacked in the economics of multilingual AI data collection.
A low-resource language is a language with little digitised text or speech available for model training, so data usually has to be collected from native speakers.
So two languages with identical market sizes can differ several-fold in the cost of reaching the same product quality. A roadmap drawn from a market-size spreadsheet alone will systematically overcommit to expensive languages early and leave cheap wins on the table. The order has to price both sides.
What does language coverage actually buy you?
More than reach: it buys preference, trust and completed transactions, and the research is unusually consistent. Customers favour their own language when they buy, and an AI product that handles a language badly does more harm than one that does not offer it.
CSA Research's "Can't Read, Won't Buy" series, built with Kantar on a survey of 8,709 consumers across 29 countries, found that 76% of online shoppers prefer to buy products with information in their native language, 40% will not buy from websites in other languages at all, and 65% prefer content in their own language even when its quality is imperfect. The preference is not an inability to read English: even among respondents most confident in their English, a clear majority still favoured their own language for customer care.
| Finding | Share |
|---|---|
| Prefer to buy with product information in their own language | 76% |
| Prefer own-language content even if quality is imperfect | 65% |
| Will not buy from websites in other languages | 40% |
Preference intensity varies by country, and the series notes Japan at the lower end (50%), which is itself an argument for scoring markets individually rather than applying one global assumption.
For AI products the stakes are higher than for websites, because a model's failure mode in an unsupported language is not a missing translation but a fluent wrong answer. Model capability tracks the volume of data a language had at training time, and that distribution is extremely uneven. The measurable penalties, lower accuracy, worse reasoning and more fabrication, are covered in why generative AI gets worse in your second language. Shipping a language your model handles badly is worse than not shipping it, because users cannot tell confident errors from competence.
There is also a visibility dividend: AI assistants retrieve answers language by language, so the languages you invest in are also the markets where your brand can appear in AI-generated answers.
What are the four factors that should set your order?
Market value unlocked, base-model readiness, data cost to target quality, and operational load after launch. Score all four together, because any one of them alone produces a misleading order.
Factor 1 - Market value unlocked. Not speaker population: your addressable users, revenue and strategic accounts per language. A language with 40 million speakers where you have a sales team and inbound demand outranks one with 300 million speakers where you have neither. Score it from your own pipeline, support tickets in unsupported languages and market plans, not from a world-languages table.
Factor 2 - Base-model readiness. How well do the models you build on already perform in this language? This is measurable before you spend: run your own task, not a generic benchmark, in each candidate language and score it with native speakers. High readiness means your data programme is a top-up; low readiness means it is a build. Translated benchmarks systematically mislead here, overstating capability for reasons covered in how multilingual AI models are benchmarked, so test natively or you are not testing.
Factor 3 - Data cost to target quality. What will it cost to close the gap Factor 2 revealed? This turns on data availability (licensable versus must-collect), speaker recruitability, script and tooling complexity, and whether "the language" is really one locale or several. Right-to-left and complex scripts carry their own tax, as collecting text data for right-to-left and complex scripts shows.
A locale is a language as used in one region, with its own vocabulary, accents and conventions; Arabic, Spanish and Chinese are each families of locales, not single entries.
Locales differ in vocabulary and, for speech, in acoustics, so scoping language coverage at locale level applies before any costing is credible.
Factor 4 - Operational load after launch. A live language needs ongoing evaluation, content refresh, escalation paths with native speakers and model-update regression testing, forever. Five languages at depth beat fifteen at neglect; an abandoned language quietly decays into the fluent-wrong-answer failure mode.
How do you score and sequence a shortlist?
Shortlist eight to twelve candidates, score each on the four factors from 1 to 5, and sequence them in waves rather than a single ranking. Keep it simple enough to defend in a budget meeting.
Step 1 - Shortlist eight to twelve candidates from real signals: current traffic and tickets by language, sales pipeline by market, competitor coverage and regulatory requirements.
Step 2 - Score each on the four factors, 1 to 5, with Factor 3 entered inversely (cheap = high). Weight market value double if you must weight at all.
Step 3 - Sequence in waves, not a ranking. The useful output is three tiers:
- Wave 1 (now): high value, high readiness. Markets that matter where base models are already strong. This is the fastest payback, often shippable with modest fine-tuning and a native evaluation set.
- Wave 2 (next): high value, low readiness. Markets worth a genuine data programme. Start the collection now, because it has the longest lead time; ship when evaluation says ready, not when the roadmap says so.
- Wave 3 (watch): lower value or unresolved locale questions. Revisit quarterly; base-model readiness moves fast enough to promote languages between reviews.
Step 4 - Attach a per-language definition of done: a native evaluation set exists, the model clears your quality bar on it, and a native-speaker escalation path is staffed. A language without all three is announced, not supported.
A native evaluation set is a test set written or reviewed by native speakers of the target locale and built around your real task, used to decide whether the model is ready to ship in that language.
Data cost (Factor 3) stretches or compresses Wave 2 timelines, and operational load (Factor 4) caps how many languages any wave can hold.
Which mistakes make language roadmaps fail?
Ranking by speaker count, treating translation as support, launching without a native evaluation set, averaging locales, and spreading the operational budget across too many languages.
Ranking by speaker count. The world's largest languages are not your largest markets, and the correlation between speaker population and base-model quality is loose. Some mid-sized European languages are better served by current models than far larger languages elsewhere, a consequence of the divide explained in high-resource versus low-resource languages in AI training.
Treating translation as support. Translating the interface while the model underneath still reasons poorly in the language produces the most trust-damaging combination available: a localised wrapper around degraded answers. The deeper issue is that translation moves words while leaving knowledge and cultural context behind, the subject of why AI needs culturally relevant data.
Launching without a native evaluation set. If you cannot measure quality in the language, you will discover problems from user churn. The evaluation set is the cheapest component of the whole stack and the one most often skipped, a gap addressed in how to build multilingual evaluation sets for LLMs.
Averaging locales. One "Spanish" dataset drawn from Spain, deployed across Latin America, fails in ways your Spain-based evaluation never shows.
Spreading the operational budget across too many languages. The roadmap slide says twenty; the maintenance budget supports six. The other fourteen decay. Decide the number the budget truly supports and sequence honestly within it.
How can a data partner help you sequence language expansion?
A data partner can run the readiness assessment, scope locales, model per-language data costs and build evaluation sets first, so the roadmap is priced before collection starts.
Language prioritisation is where many of Lifewood's managed multilingual data collection engagements begin, because the sequencing question has to be answered before any collection brief makes sense. The working method follows this article: a native-speaker readiness assessment of the client's actual task across the candidate languages, locale-level scoping rather than language-level, per-language cost modelling for the data needed to close each gap, and a waved roadmap with evaluation sets built first. Lifewood Data Technology, founded in 2004, works across 100+ languages through 40+ delivery centres across 30+ countries, including low-resource languages where collection is field work, so the cost side of the model is drawn from operations rather than estimation.
If you are comparing providers, top multilingual data collection companies ranks them against a stated criterion. The market-value side of the decision benefits from independent sources: CSA Research's consumer series is the standard reference for language preference by market. For base-model readiness, published multilingual benchmarks are a starting point, with the translated-benchmark caveat above, and your own natively evaluated task is the finishing one. However you weight the factors, the discipline that matters is pricing all four before committing the roadmap, whoever builds the data.
What should you do before you commit to a language roadmap?
Pull your own language signals, test your real task natively in each candidate language, scope at locale level, cost the full stack, and define done per language before committing.
- Pull your own language signals first. Traffic, tickets, pipeline and churn by language and market; the demand evidence is already in your systems.
- Run your real task in each candidate language and have native speakers score it. It is one week of work, and it replaces the biggest assumption in the plan.
- Scope at locale level before costing anything. "Arabic" and "Spanish" are portfolios, not entries.
- Cost the full stack per language: collection, tuning data, evaluation set and ongoing maintenance, not the translation line.
- Sequence in waves of three to five, with Wave 2 data collection starting now, since it is the long pole.
- Define done per language: native eval set, quality bar cleared, native escalation staffed.
- Re-score quarterly. Base-model readiness moves fast; last year's Wave 3 language may be this year's quick win.