Which languages should you localize your app into?

Almost every article on this gives you the same list of large app markets. That list is not wrong, it is just not about your app — and picking from it is how teams end up with six languages, none of which earn their maintenance.

Here is a method that uses your own data instead.

Start with where you already have traction

Open your App Store Connect or Play Console analytics and sort installs by territory.

Look for territories that are already installing despite an English-only listing. Those users wanted your app enough to push through a barrier. Removing the barrier is the highest-confidence change available, because the demand is demonstrated rather than assumed.

This beats any general market list, because it accounts for your category, your positioning and your existing distribution — none of which a generic ranking knows about.

Then weigh three factors

Demonstrated demand. Installs, impressions or paid conversion from that territory today.

English proficiency. The lower it is, the larger the effect of localizing. This is why localizing into the Nordics often does less than the market size suggests, and why Japan, Korea, Brazil and much of Latin America often do more.

Your app's language dependence. A photo editor needs less localization than a note-taking app. If someone can use your product without reading much, listing localization alone goes further.

A territory scoring high on all three is an obvious yes. High demand plus high English proficiency is a maybe. Low demand and low proficiency is a bet, not a decision.

What the stores support

The App Store carries a defined set of storefront locales — we currently handle 50 of them, taken from the same registry our publisher validates against, including three right-to-left languages: Arabic, Hebrew and Urdu.

Play uses a broader list and allows more granular regional variants.

Two practical notes:

• Regional variants matter more than people expect. Brazilian Portuguese and European Portuguese are genuinely different markets; so are Latin American and European Spanish. Picking the wrong one reads as carelessness to a native speaker.
• Some storefronts expect a specific variant. Shipping European Portuguese to Brazil is worse than shipping English, because it signals you did not look.

Start with two or three, not eight

Pick two or three, do them properly, measure, and expand from evidence.

Half-localizing is usually wrong

A listing where the description is translated but the screenshots are still English is the common failure. The screenshots are the part a browsing user actually looks at, so the translated description is doing the least valuable half of the job.

If you are only going to do one thing: localize the first two screenshots and the metadata. Skip the rest of the set until those show a result.

Right-to-left is a design change, not a translation

Arabic, Hebrew and Urdu mirror the layout. A panel with the device on the left and text on the right becomes a panel with the device on the right and text on the left — not the same layout with different words in it.

If you are not prepared to check those layouts, do not ship them. A broken RTL listing is more damaging than an English one, because it signals you tried and did not care enough to look.

Measure it properly

Localization is well suited to testing, because the comparison is clean: Play's Store Listing Experiments can run per-localization, and Apple's PPO supports per-localization treatments.

Run one language, measure it, then decide about the next. That is a much better process than translating into six at once and never knowing which worked.