App screenshot localization checklist

Run this before you ship a localized set. It is ordered by when each check actually has to happen, because several of them are impossible to do retroactively.

For the reasoning behind any of it, see how to translate screenshots.

Before you translate anything

1. Pick markets from your own data, not a generic list — territories already installing despite an English listing.
2. Confirm the regional variant. Brazilian vs European Portuguese, Latin American vs European Spanish. The wrong one reads as carelessness.
3. Write the glossary. Product name, feature names, trademarks, anything that must not be translated.
4. Shorten the English captions. If English fits with room to spare, most expansions fit too. This is the cheapest fix available and it has to happen first.
5. Check font glyph coverage for every target script — CJK, Cyrillic, Arabic, Devanagari. Missing ranges produce empty boxes.
6. Decide the RTL position. If you ship Arabic, Hebrew or Urdu, decide now whether you have a genuine RTL build to capture. If not, plan to mirror the layout only and keep the original screenshot.

While translating

1. Supply context, not bare strings: what the text is, where it appears, the maximum length, the tone.
2. Supply the glossary explicitly to the translator.
3. Keep one source of truth. One design rendered per locale — never a separate design file per language.
4. Note per-locale overrides as you make them, so a future you knows which ones are deliberate.

After translating, before exporting

This is the pass almost everyone skips. Look at every locale as rendered, not as a spreadsheet of strings.

1. No unintended wrapping. A caption that was one line in English and is three in German is a layout failure, not a translation one.
2. No clipping or overlap with the device or the panel edge.
3. No tofu boxes or obviously substituted fallback fonts.
4. RTL locales actually mirrored — layout, alignment, arrow direction, reading order.
5. The screenshot itself is not mirrored. Your UI is a photograph; a mirrored one shows a product that does not exist.
6. Product name intact in every locale. This catches the glossary failure.
7. Numbers and dates in local format where they appear in captions.
8. Type size consistent within each locale. It need not match across locales, but within one language the set must look deliberate.

Before uploading

1. Exact pixel dimensions per display class, per locale — localization does not exempt you from the size rules. The fix if it fails.
2. Consistent within each display class, in every locale.
3. The right count per locale. Ten maximum per class on the App Store, eight on Play.
4. Metadata localized too — name, subtitle, keywords, description. Translated screenshots over an English subtitle is a half-finished listing.
5. Keywords rewritten, not translated. Search terms in another language are different words, not the same words in translation. This is genuinely a research task per market.
6. Nothing fabricated in any locale. Invented numbers are a removal risk in every language.

After shipping

1. Watch reviews in the new markets for the specific complaint that the listing is localized but the app is not.
2. Compare install rate before and after in those territories, allowing for seasonality.
3. Test one language properly rather than assuming — Play supports per-localization experiments and Apple supports per-localization treatments.
4. Decide the next language from the result, not from a market-size list.

The maintenance question

Before adding a fifth language, answer one question: what happens to all of them at your next redesign?

If the answer is "somebody regenerates ninety-six files by hand", you will stop maintaining them, and a stale localized listing is worse than an English one. The only sustainable model is one design that re-renders per locale.