Where every Atlas number comes from

Sources

The Atlas fetches two datasets live and caches them on disk; the rest are curated tables in the repo. When a fetch fails, the Atlas serves the last good cache.

The EF EPI table ships 116 of the 123 countries in the 2025 edition. It includes a country only when the official report PDF and an independent transcription of the same edition agree on its score, and omits the seven where they disagreed.

The launch score

The launch planner scores each candidate market as a weighted blend of three components, each normalized to 0–100: incremental reach, GDP, and engineering ease. The weights come from the selected product profile:

Reach (0–100)

Net-new speakers gained worldwide when the market's primary language is added, computed under the overlap model in the next section. A market already half-covered earns only half credit. The raw speaker count maps to the score linearly: 200,000,000 net-new speakers scores 100, and anything above saturates. The 200M anchor is a choice that makes the largest realistic language additions fill the scale; no market fact says 200M rather than 250M. The "% of world" figure beside it divides by a fixed 8.0 billion world-population constant.

GDP (0–100)

The country's CLDR long-run nominal GDP, normalized so the largest economy in the dataset scores 100. The result is a relative ordering; it does not forecast revenue. Scores are comparable within a run but not across datasets, since the normalizing maximum comes from the country list in play.

Engineering ease (0–100)

A checklist score for the candidate language: start at 70, then apply each adder that fires. The adder sizes are judgment, chosen to order markets by integration effort; no project data measured them. The model clamps the result to 0–100.

Plural-category counts are CLDR plural rules, checked against Intl.PluralRules. The model attributes a candidate language only to countries where it holds at least a 30% L1+L2 share, so Spanish surfaces against Mexico and Spain rather than the US.

The overlap model

CLDR reports each language's share of a territory as L1 plus L2 speakers, so a bilingual person counts once per language and the shares of one country routinely sum past 100%. Every Atlas aggregate handles this the same way: within each country, the model sums the selected-language shares and caps them at 100% of the population. Incremental reach applies the cap before and after, so adding a minority language to a saturated bilingual market contributes only the uncovered remainder.

The cap bounds the error without resolving it. Within the capped total, the model may still credit a trilingual speaker to whichever of their languages was selected first: the data gives share totals and never says which individuals overlap.

How speaker shares are printed

Every share of a territory's population is printed to one decimal place, rounded up, by a single formatter shared across the Atlas. Russian is spoken by 0.24% of the United States, 820,000 speakers, which whole-number rounding printed as 0%. Rounding up is safe here because CLDR's territory data is read at a 0.1% floor, so no row rounds up from zero, and the largest possible overstatement is 0.09 points on a figure that is already a survey estimate.

How Chinese is counted

Simplified and Traditional Chinese are separate languages in every reach and coverage figure. They are different written standards with different character sets and terminology, and CLDR's territory data already keeps their audiences apart: mainland China and Singapore carry a zh row, while Taiwan, Hong Kong, and Macau carry zh_Hant, along with Traditional-reading communities in a dozen more territories. Shipping one never earns credit for the other, so a product with only Simplified Chinese shows Taiwan as uncovered. When a source names a Chinese interface without saying which form (the App Store search API does this), the model counts it as Simplified, the majority case, and the page says so where it happens.

CLDR also records spoken Sinitic varieties as their own rows: Cantonese, Wu, Xiang, Hakka, Min Nan, Gan. These stay out of coverage maths entirely, because their speakers read the written standard of their territory, which the standard Chinese row already counts. The rows remain visible on country and language pages as demographic facts.

The cost model

Costs start from per-word rates times word counts, using this site's curated 2025 planning defaults. Three adjustments then move each estimate toward a real quote: a per-language-pair rate index, a translation-memory leverage discount, and a separate one-time engineering-setup line. One LQA round prices at 20% of the tier's per-word rate, charged on every word regardless of leverage.

Per-language-pair rate index

A word into Japanese, Icelandic, or a Nordic language costs more than the same word into Spanish. The cause is translator scarcity and source-market cost of living, not script difficulty. The estimator multiplies each locale's per-word rate by an index, with a mainstream pair at 1.0, the default for anything not listed. These are planning indices rather than sourced rates.

Translation-memory leverage

Words already in the translation memory bill below the new-word rate: repetitions and exact matches pay 25% of it, fuzzy 75–99% matches 60%, and new words full price. A first launch has no memory to draw on (0% leverage); a mature product reuses a large share of prior wording. The estimate applies leverage to translation and to the schedule, never to LQA.

Engineering setup

The work a per-word rate never captures, priced once as its own line so an RTL or new-script launch is not quoted like a Latin one. Planning figures, derived from the locale set:

The launch planner prices three launch depths by assigning each content bucket (UI strings, docs, support content) one of the tiers above. Even the cheapest depth keeps a light human review pass on the UI strings.

The figures above price a one-time launch; ongoing upkeep is estimated separately. The model assumes 40% of the source word corpus is retranslated each year (new features, edited strings, refreshed docs) and prices that through the same depth machinery: same tier rates, LQA rounds, and PM overhead. The churn rate is a planning assumption; replace it with a measured figure when one exists.

The briefing's derived numbers

The executive briefing combines the models above into a few numbers of its own, each with a fixed convention.

Budget ask

The decision block's budget ask auto-fills from the recommended market's launch cost (the first row of the cost appendix) plus that locale's one-time engineering setup, which the appendix itemizes. Setup credits what the portfolio already has: a second RTL language does not pay for RTL enablement again, an already-shipped script does not re-buy its webfont, and a portfolio with more than one language is assumed to have an i18n framework in place. The ask leaves out the all-markets total, because the decision on the table approves a single launch; the appendix prints that total on its own labeled row. A typed budget-ask override always replaces the auto-filled figure, and when the cost appendix is off or unpriced the drafted ask carries no dollar amount.

Proposed sequence

The ranking table scores every candidate against the same fixed portfolio, so its reach numbers must never be summed: two overlapping languages would double-count their shared markets. The briefing's Now / Next / Later tiles are the one surface that orders launches in time, and each tile's net-new count is recomputed as if the earlier tiles had already shipped. Those three numbers do sum cleanly.

Payback scenario

The payback card combines four terms of different provenance, and its footer labels each one ("headroom: estimate · ARPU: your data · capture: your assumption · upkeep: 40% annual string churn, an assumption"). Online headroom, the estimated term, is the anchor market's online population minus the reported MAU there. ARPU comes from the uploaded data, as that market's revenue divided by its MAU. Capture and churn are the assumptions. From there the arithmetic is short: users = headroom × capture, monthly revenue = users × ARPU, and months to recover = launch cost ÷ monthly revenue net of upkeep, rounded up. The card renders only when every term exists: a priced cost appendix plus an uploaded row for the anchor market carrying both revenue and an online-population estimate. When a term is missing, the briefing omits the card and never prints a zero. The card is a scenario, not a forecast.

Custom weights

The launch planner's Custom profile exposes three sliders. On every change, they renormalize to integers that sum to 100. The briefing accepts the same override as a URL parameter: weights=R-G-E, three non-negative integers, normalized by their sum. For example, weights=55-15-30 weighs reach 55%, GDP 15%, and ease 30%. The briefing ignores a malformed value and applies the selected profile preset. While the override is active, the memo header shows "custom weights" and the methodology footer prints the exact split and its source parameter. Picking any profile button clears the override.

Snapshot deltas

When the diff compares two uploads of the same product, per-market penetration deltas divide both snapshots' MAU by the same online-population estimate (the current one), so the delta isolates MAU movement rather than drift between two vintages of that estimate. Markets present in only one snapshot appear as added or removed, never as ±100% changes, and the totals cover only markets present in both. The diff can report what moved but not why.

What the numbers are not

• Double-counting is capped but not resolved. L1+L2 shares still overlap inside the 100% cap, so the model can credit a multilingual person to the wrong selected language.
• Two GDP figures coexist. CLDR's long-run GDP estimate drives the launch score and the nominal-GDP metric. World Bank GDP per capita (current US$, most recent year) appears on country pages and drives the per-capita lenses. CLDR long-run GDP ÷ population fills in where the World Bank has no figure. The two are different vintages and can disagree. Any single number comes from one source, never an average of the two.
• No revenue estimates. The Atlas sizes audiences and costs, never revenue. The only usage numbers it shows are uploaded ones (Your data), and they stay display-only, never entering scoring.
• The ease model has a coverage edge. Its metadata table covers 80 language codes. Outside it, the model defaults to the flattering shape (Latin script, LTR, 2 plural categories, no webfont). The planner therefore flags those rows as "No engineering metadata".
• EF EPI is context, not an input. The index samples self-selected online test takers, skewed young and toward people already learning English. It never enters planner scoring.