Which Languages Should You Localize First? A Business Priority Ranking for 66 Language Versions

When working on multilingual projects, you will eventually run into one question:

Which languages should you translate first?

If you are only supporting three to five languages, the question is not complicated. English, Chinese, Japanese, German, French, Spanish—just pick a few major markets.

But once a project plans to support dozens of languages, the problem is completely different.

My Go multilingual project initially started as a translation of A Tour of Go. Due to time constraints, I didn’t design a massive plan covering the entire Go documentation system from the start. Instead, I finished the Tour first and then gradually expanded to Learn, Tutorial, Database, Modules, Security, and other content.

As the project progressed, I eventually completed 65 community locales and began thinking about another, more long-term question:

If there are new multilingual projects in the future, will I have to research “which languages to support and which to do first” all over again?

My answer gradually became: There is no need.

Since I have already spent a lot of time researching language scope, regional variants, commercial value, and implementation costs, I can completely establish a language pool and default order for long-term use. Future projects can simply reuse it, skipping the source language when needed.

And this time, I decided to have this base order answer only one question:

In terms of long-term advertising revenue potential, which language is more worth prioritizing for completion?

From 65 locales to 66 cross-project targets

First, I need to explain a potentially confusing number here.

The fixed scope already completed for the current Go project is 65 community locales.

The official Go Tour uses generic en as the English authority, but this en is the source language and does not belong to the 65 community locales mentioned above.

This is fine for the Go Tour because the original text is in English.

But a language pool that can be reused across projects cannot assume that the source will always be English.

In the future, it is entirely possible to have:

source = zh-CN
source = ja-JP
source = de-DE

source = zh-CN
source = ja-JP
source = de-DE

If the language pool does not include American English, then a Chinese project would ironically lack a target for the most important English commercial market.

Therefore, I additionally added the following to the cross-project language pool:

en-US

en-US

This results in:

66 cross-project target locales.

From now on, each project only needs to follow one simple rule:

Skip whichever locale the canonical source already covers, and keep the original commercial order for the remaining languages.

Thus, an English project can skip en-US, and a Chinese project can skip zh-CN, without needing to create another language ranking.

I am not ranking “language importance”

This ranking can easily lead to a misunderstanding:

Are the languages ranked higher “more important,” and are the languages ranked lower “unimportant”?

No.

This table does not evaluate the importance of languages, cultures, countries, ethnic groups, or speakers.

It is merely estimating a business question:

If the same technical content project receives reasonable local traffic, how much advertising revenue can each language version generate in the future?

In other words, what I am actually estimating is:

Expected advertising revenue
≈ Potential obtainable traffic
× Commercial value per unit of traffic

Expected advertising revenue
≈ Potential obtainable traffic
× Commercial value per unit of traffic

Without real operational data, neither of these values can be directly known; they can only be estimated using proxy metrics.

Potential traffic is influenced by the language-speaking population, internet population, country size, developer population, and technical content usage habits.

The commercial value per unit of traffic is highly correlated with factors such as the purchasing power of the economy, the number of advertisers, advertising spending, and digital advertising maturity.

So a large population does not necessarily mean the highest ranking.

A small population does not necessarily mean a very low ranking either.

A typical example: India and the Nordics

India has an extremely large internet population and developer base.

GitHub’s 2025 Octoverse data shows that India now has approximately 21.9 million GitHub developers, making it the second-largest developer community globally; Brazil has about 6.89 million, and Indonesia about 4.37 million. The GitHub Blog

This means India, Brazil, and Indonesia cannot simply be placed at the bottom of the ranking just because their ad rates are lower.

On the other hand, countries like Norway, Denmark, Sweden, and Switzerland have small populations but possess very high per capita incomes, mature digital economies, and high-value advertising markets.

So:

Low ad rate × Huge population

and:

High ad rate × Smaller population

can ultimately yield similar commercial values.

This is why it is unreasonable to decide the order of multilingual projects simply based on a “language population ranking.”

Why the US should rank first

After adding en-US, American English ranks first almost without suspense.

Data from IAB and PwC shows that US internet advertising revenue reached $294.6 billion in 2025, a year-over-year increase of 13.9%. IAB

This market simultaneously boasts:

multiple advantages such as massive advertising scale, high purchasing power, a mature advertising ecosystem, a huge developer population, and mature consumption of English technical content.

Therefore, for a technical content website aimed at developers, American English should be one of the default top commercial priorities.

Why China is still very high up

If we only considered Google AdSense, mainland China might be severely downgraded.

But I am deliberately not ranking it this way now.

The reason is that this table is intended to be a cross-project, cross-advertising-platform long-term commercial order, not a “Google AdSense support ranking.”

China’s GDP in 2024 is approximately $18.74 trillion, remaining the world’s second-largest economy. Major target markets like Germany, Japan, India, the UK, France, Canada, and Brazil are also among the world’s largest economies. World Bank Data Catalog

If a future Chinese project uses a local advertising platform in mainland China or other business models, then the commercial value of zh-CN clearly cannot be artificially pushed down because of Google’s restrictions.

The same principle applies to markets like Russian and Persian.

Therefore, this time I am not using “whether a specific ad platform can currently be used” as a base ranking factor.

Why Europe has many languages in the top half

Europe has many language markets with relatively small populations, such as Dutch, Swedish, Norwegian, Danish, Finnish, and Czech.

But these markets cannot be ranked simply by population.

IAB Europe’s 2025 AdEx Benchmark shows that the European digital advertising market has reached €131 billion, a year-over-year increase of 10.5%; mature Western European markets continue to maintain steady growth. IAB Europe

Therefore, a high-purchasing-power market with only a few million or just over ten million people could very well be worth completing earlier than a market with tens of millions of people but lower commercial value.

“Ethnicity” is not a suitable field for direct ranking

When initially compiling the data, I considered factors like population, continent, country, ethnicity, economic size, and advertising market.

Later, I decided not to use “ethnicity” as a standalone field, changing it to:

Major countries / regions and language communities

Because language and ethnicity are often not a one-to-one mapping.

English, Spanish, Arabic, French, Russian, and Swahili all span multiple countries and a large number of different ethnic groups.

For business analysis, what is truly meaningful is:

Where the speakers of this language are primarily located, and what their economic and advertising markets look like.

Advertising revenue potential order for 66 language versions

The table below is the first version of the commercial order I ultimately adopted.

The “potential audience” is merely an order-of-magnitude indicator and is not equivalent to strict native speaker statistics; “advertising potential” is also a comprehensive expectation given the current lack of real PV, RPM, and fill rate data.

Why exact rankings are actually not that important

Seeing a 66-row table like this makes it easy to start arguing:

Between 24th and 27th place, who should actually be higher?

I later felt this isn’t a question worth investing too much time in.

The reason is very practical:

If a mature AI-assisted localization workflow allows me to complete all languages in about two months, then whether a language is moved up by two weeks or delayed by two weeks has very little impact on the project’s long-term revenue.

What really matters is avoiding two extreme mistakes.

The first is leaving markets with very high commercial value at the very end for a long time.

The second is spending a few days re-researching language rankings every time a new project is added.

As long as these two issues are solved, the value of this table is already significant enough.

Therefore, I focus more on these commercial tiers of S, A, B, and C, rather than a difference of one or two ranks between adjacent languages.

Four special strategic languages

There are four other languages that need to be explained separately:

sw-TZ
kk-KZ
fa-IR
am-ET

sw-TZ
kk-KZ
fa-IR
am-ET

They are not necessarily ranked very high in a pure advertising revenue order.

But they used to hold another very special value:

Ecosystem entry points.

For example, if a project hopes to apply for an official documentation site, a community project, or a language link like go.dev, then these under-served, less competitive languages can sometimes gain very high strategic priority.

So I will not change their positions in the base commercial table.

Instead, I am setting a project-level rule:

If a project has clear opportunities for official links, ecosystem partnerships, or directory recommendations, these languages can be temporarily moved up; if no such opportunities exist, implementation continues according to the base advertising revenue order.

This way, “commercial ranking” and “ecosystem strategy” will not pollute each other.

The same applies to markets like ru-RU and fa-IR, which are currently unsuitable for certain international advertising platforms.

The base ranking estimates:

The commercial potential of the language market itself.

Whether to ultimately use Google, local ad networks, direct sponsorships, affiliate programs, or other business models is a specific project’s subsequent monetization implementation issue.

Technical projects also need to consider developer distribution

My projects are primarily programming and technical documentation, so there is another factor that an average website might not need to focus on as heavily:

Developer population.

GitHub 2025 data already clearly shows that the developer landscape is changing.

India has reached about 21.9 million GitHub developers, Brazil about 6.89 million, and Indonesia about 4.37 million; at the same time, mature tech markets like Germany, the UK, Korea, France, Canada, and Japan still possess very active developer communities. The GitHub Blog

So for programming documentation:

Markets with large populations but low developer penetration cannot be calculated simply based on the national population.

Conversely, small but highly digitalized countries with large numbers of tech workers should not be severely underestimated just because of their small populations.

This is also why this ranking can only be called:

Advertising revenue potential ranking

rather than an absolute mathematical formula.

When to re-rank

I plan to freeze this order for now.

Subsequent Site v2, Site v3, and new multilingual projects will all implement this order by default.

The right time to re-rank is not when I see another “global CPM leaderboard,” but after I start having enough real data of my own.

For example:

Locale PV
× Actual Page RPM
× fill rate
= Actual advertising revenue

Locale PV
× Actual Page RPM
× fill rate
= Actual advertising revenue

At that stage, there will no longer be a need to guess which market is more valuable.

Real revenue itself is the answer.

Until then, constantly tweaking the 34th and 38th places will only consume time and won’t actually improve project revenue.

Final principles

After this period of multilingual practice, I am now more inclined to split language selection into three layers.

The first layer is the fixed language pool.

I am now selecting 66 cross-project target locales to avoid re-researching global languages for every new project.

The second layer is the commercial base order.

It ranks solely based on long-term advertising revenue potential, without mixing whether a specific ad platform currently supports the language into the language’s value itself.

The third layer is the project-level override.

Special factors like official links, ecosystem partnerships, regional policies, and existing source languages can change the actual implementation order of a specific project, but they do not modify the underlying commercial ranking.

This way, one project can prioritize Swahili to apply for an official link; another project can start entirely with American English according to the advertising revenue order.

There is no conflict between the two.

For me, the real problem this table solves is not “which is exactly the 37th most valuable language in the world.”

It solves a more practical problem:

From now on, when I start another multilingual project, I won’t need to ask myself again what the next language should be.

Having a reasonable enough, reusable order for the long term, and then continuously completing it, is enough.