App store listing localization: what to translate, in what order

Your game is on the App Store or Google Play, almost every install comes from one country, and you would like that to change. The answer most people reach for first is to translate the game, which is a real project with a real schedule. The answer available to you this week, for a fraction of the effort, is the store listing.

The listing is the text and images the store itself shows: the name, the one-line hook, the description, the screenshots, and on one of the two stores a dedicated field of search terms. It runs to a few hundred words at most. It is also the only thing a person in another country reads before deciding whether to install, which is why it deserves to be treated as its own piece of work rather than a leftover from localizing the app.

This article covers what each field is actually doing, why the two stores need different source text, how search behaves per language, and a sensible order to work in.

Listing localization and app localization are separate things

On both platforms, listing text lives on the store side and is edited in a web console. The app's own translated strings live inside the build you upload. These are two different storage locations, edited by different people at different times, and either can be done without the other. That is mostly good news: in the usual case you can add or fix a language on the listing without shipping a new build, which makes the listing the cheapest surface you own to iterate on.

It also creates a trap worth knowing about. On the App Store, the languages shown in the product page's information section are derived from the localizations inside your app binary, not from which listing languages you filled in. A listing translated into ten languages on an English-only build still tells visitors the app is in English. Translating the listing does not change what the store says your app supports, and it should not — that field is doing an honest job.

The practical consequence is that you should decide separately, and deliberately, what you want each layer to say. The listing can reach a market. Only the build can serve it.

What each field is doing, and why the two stores differ

The fields look similar across the two stores, but they carry different weight, and a couple of them exist on only one side. That asymmetry matters more than it looks: one store gives you a hidden keyword field, and the other indexes the description your players actually read.

Because of that, pasting the same translated text into both is a small waste on one side and a missed opportunity on the other. On the store with a keyword field, the description can be written purely for a human reader, since search terms are handled elsewhere. On the store without one, the description has to carry both jobs at once: read naturally, and contain the words people actually type.

Field lengths are enforced strictly. Both consoles count characters as you type and refuse to save an overlong value, so check the current limit in the console rather than trusting a number you read somewhere — and give your translator that limit up front. Asking for a title that fits a specific budget is a different brief from asking for a title, and languages that run longer than your source will otherwise come back needing a rewrite only you can approve.

One more thing worth knowing before you conclude that one listing per language is your only option: some consoles let you create additional listings aimed at particular countries or audiences, on top of the per-language ones. That is a marketing tool rather than a localization one, but it exists.

• App name / title — the strongest single signal in store search and the only text guaranteed to be read in a results list. Very short, and truncated further on small screens
• Subtitle (App Store) / short description (Google Play) — the line directly under the name. For many browsers this is the entire pitch
• Full description — read by a minority of visitors, but it is where a curious player decides whether the game is for them, and on Google Play it is also search-indexed text
• Keyword field (App Store only) — a small fixed budget of comma-separated search terms, invisible to players. Google Play has no equivalent field; there the description text does that job
• Screenshots and preview video — a separate asset set per language, and the part most people actually look at
• Release notes / what's new — short, recurring, and the field most likely to sit untranslated for months

Search terms are not translations of each other

This is the part that surprises people who treat the listing as a translation task. The words a player types into a store search box in another language are not the dictionary equivalents of the words you would type. Markets differ in whether they search a genre in their own script, in a borrowed English word, or in a transliteration of one — and often all three coexist with one clearly dominant. No amount of translating your existing keywords produces that answer, because the answer is a fact about a market rather than about a language.

Japanese search behaviour is a good illustration: a genre or mechanic may be searched in katakana, in its English spelling, or in a native word, and which of the three wins is not something a translator can derive from your source text. The same is true in reverse for a Japanese developer guessing at English search terms.

You can research this without buying a tool. Look at the games already ranking in your genre in that country's store and read what they call themselves — those names are the result of other teams' experiments. Type partial words into that store's search box and read the suggestions, which are drawn from real queries. And read what your existing players in that country already write about your game in reviews and social posts: they are using the words that come naturally to them, which is exactly what you are trying to learn.

Screenshots do more work than the description

Most store visitors scan the image strip and never open the full description. The first two or three screenshots — the ones visible without swiping — are doing most of the persuading, so any text baked into them matters more per word than anything in your description.

That text is an image, not a string, which changes how you have to work. Build the caption layer so it can be regenerated: keep caption text on its own layer in the source file, keep captions short enough that a longer language still fits, and avoid designs that only look right with one specific line break. If a caption has to be recreated by hand for every new language, you will stop adding languages.

The screenshots also make a promise about the app's interface. If your game is not localized, screenshots showing your source-language UI at least tell the truth, and a visitor who installs anyway knows what they are getting. Screenshots mocked up in a language the build does not support are the fastest way to earn a refund and a one-star review about it.

Should you localize the listing if the game is not localized?

There are two honest answers, and which one applies depends on how much your game leans on text. A puzzle, arcade, racing, or sports game that a player can understand from the screenshots loses very little by having an untranslated interface, and a translated listing genuinely opens a market for it. A story-driven or systems-heavy game does not: a translated listing brings in installs from people who cannot play it, and the resulting reviews will say so in a place every future visitor reads.

If you do it, do it plainly. State which languages the game itself is in near the top of the description rather than in the last line, keep the screenshots in the real interface language, and do not imply support you do not have. A visitor who installs with correct expectations is a customer; one who installs with wrong expectations is a refund plus a public complaint.

There is a real upside to doing it this way, beyond the installs. A listing translated into a language whose build you have not translated is a demand experiment: whatever conversion you see comes from people who wanted the game enough to try it in a language they do not read. That is a far more concrete signal for deciding your next localization language than a general sense that a market is large.

An order to work in, and how to judge the result

If you are starting from a single-language listing, the sequence below front-loads the fields with the highest ratio of impact to effort. Do one language completely before adding the next, so you learn how the process behaves before you multiply it.

Then judge it on conversion rather than raw installs. Both consoles report acquisition data by country, and traffic volume varies enormously between countries for reasons that have nothing to do with your listing — so a market that sends you fewer visitors can still be the one converting them best. The ratio is the part your listing controls.

Give a change a few weeks before drawing a conclusion, change one thing at a time where you can, and write down what you changed and when. Store consoles do not keep an annotated history of your listing edits for you, and six months from now the difference between a listing that works and one that does not will come down to remembering which version was live when the numbers moved.

• Pick one target language, chosen from where your installs and reviews already come from rather than from market-size charts
• Title and the one-line field first — highest visibility, smallest word count, hardest to get right, so give them the most attention per word
• Search terms next, researched in that market rather than translated from yours
• Screenshot captions, produced from a source file you can regenerate
• Full description, written to read naturally rather than to mirror your source sentence structure
• Release notes, only if you can commit to keeping them up — a stale translated field looks worse than an untranslated one

listing-source/
  en/  title.txt  short.txt  full.txt  keywords.txt  captions.csv
  ja/  title.txt  short.txt  full.txt  keywords.txt  captions.csv
  screenshots/  01.psd  02.psd  03.psd   (caption text on its own layer)