Skip to content

Blog

Why localizing your screenshots works, and what it actually costs

Localization is one of the few ASO changes with a clean mechanism rather than a persuasion argument. The honest case for it, the real cost, and why the numbers you see quoted are mostly useless.

A wide arc of smoked glass tiles fanned across the frame

Most ASO advice is about persuasion at the margin — better captions, better ordering, a stronger first frame. Localization is different, and the difference is why it tends to work.

Someone who cannot read your caption is not weighing your value proposition and finding it unconvincing. They are skipping it. Removing that barrier is mechanical rather than rhetorical, which is why it is one of the more reliable changes available to a listing.

Why the numbers you see are not useful

You will find case studies claiming very large download increases from localization. Some are real. Almost none report the things that would make them meaningful: the baseline, which markets, whether the app itself was localized or only the listing, what else shipped that month, or how long the measurement ran.

We are not going to quote any of them, because a percentage without its methodology is decoration. What is well supported and worth acting on is much plainer:

  • People install what they can read.
  • The effect is largest where your listing is currently English and the market's English proficiency is low.
  • The effect is largest on markets where you already have organic traction, because those users wanted the app enough to get past a barrier.

Your own numbers will be your own. The way to find them is a test, not somebody else's case study.

The two things people conflate

Localizing the listing — store metadata and screenshots. This is what changes install rate, because it is what a browsing user sees before they decide.

Localizing the app — the interface itself. This changes retention and reviews, and it is a much larger engineering job.

You can do the first without the second. Whether you should is a real trade-off: a localized listing over an English app can convert someone who then finds an interface they cannot use, which shows up in one-star reviews.

Two honest mitigations: pick markets where your app is usable without much reading — visual tools, utilities, games — or say plainly in the description which languages the app itself supports.

What it actually costs

This is the part usually left out.

Translation is the cheap half. Machine translation with a glossary is adequate for short marketing copy, and human review of a handful of captions is not expensive.

Layout is the expensive half. Translated text is a different length and sometimes a different direction:

  • German and Finnish routinely run considerably longer than English.
  • Japanese and Chinese run shorter, leaving captions floating in space.
  • Arabic, Hebrew and Urdu are right-to-left, which mirrors the layout rather than just swapping the words.
  • Fonts need the glyph coverage, or you ship tofu boxes in a screenshot.

Maintenance is the hidden half. Every language multiplies every future change. Eight panels, two display classes and six languages is 96 files that all need regenerating when you redesign.

A wide arc of smoked glass tiles fanned across the frame
Panels × display classes × languages. Adding a language is cheap once; it is the recurring cost that stops teams.

The order that works

  1. Localize metadata first — name, subtitle, keywords, description. Cheapest, and it affects search visibility in that storefront as well as conversion.
  2. Then the first two screenshots. They carry most of the weight, and doing two languages properly beats doing eight badly.
  3. Then the rest of the set for the markets that responded.
  4. Then the app, if the listing results justify it.

Most teams do step one and stop, which leaves the highest-leverage assets — the screenshots — in a language the visitor cannot read.

Making it sustainable

The only model that survives more than two languages is one design that re-renders per locale, with per-locale overrides only where a translation genuinely needs a different layout rather than a different string.

The alternative — a separate design file per language — diverges within two releases. Someone fixes a caption in English and the other five drift, and nobody notices because nobody on the team reads those languages.

Practical detail in how to translate screenshots and the checklist. If you are still deciding which languages, start here.

Localization

App screenshot localization checklist

A pre-flight list for shipping a localized set — before translating, after translating, and before uploading. Written to be run down rather than read.

Read
Localization

How to translate App Store screenshots without breaking them

The translation is the easy half. The hard half is that the new text is a different length, sometimes a different direction, and occasionally not in your font. A working process for both.

Read
Localization

Which languages should you localize your app into?

The usual answer is a list of big markets, which is the wrong way round. A method for picking from your own data, plus what the App Store and Play actually support.

Read