Your App Speaks 21 Languages. Your Listing, One

We found this in our own portfolio

Cosmo Sudoku ships with 21 localisation files. Every string in the app is translated. Its App Store listing declares one language.

Nobody decided that. The engineering work was done properly and the store side quietly was not, which is how it goes almost everywhere: translating the app feels like the task, and the listing feels like paperwork. It is the other way around. The app's translation serves people who already installed it. The listing's translation is how anyone finds it.

We are fixing ours. Here is the shape of the problem.

Two localisations, two different jobs

In the app, Flutter gives you flutter_localizations and ARB files. It is well-trodden: extract strings, translate, wire up the delegate, and the framework handles selection. The interesting parts are the ones a translation spreadsheet hides:

• Plurals and gender are grammar, not string substitution. Ukrainian has three plural forms, Polish has three with different rules. "$count items" is a bug in both.
• Dates, numbers, currency come from intl, never from string concatenation. Hard-coding dd/MM/yyyy breaks for half your users.
• Layout expansion. German runs 30% longer than English, Ukrainian is close behind. A button that fits in English clips in Munich. Test the longest locale, not the shortest.

In the store, none of that applies. Each localisation is a separate listing with its own title, subtitle, keyword field, description and screenshots — and its own byte budget. Adding a language to the app changes nothing about discovery until the listing follows.

Why the listing side gets skipped

Because it lives in a different tool, belongs to a different person, and has no compiler to complain.

Nothing fails when a listing is missing a language. The app simply does not appear for searches in that market, which is invisible unless you go looking. There is no error, no crash report, no test — just absence.

Which languages, and in what order

Not by intuition, and not "all of them". Two signals decide it:

1. Where the installs already come from. Your store console shows territories. A market delivering installs against an English-only listing will deliver more against a localised one — that is the cheapest win available. 2. Where competition is thin. A crowded English keyword may be uncontested in Polish or Ukrainian. Smaller markets are where a small studio can actually rank.

Then localise the listing properly: title, subtitle, keywords, description, and screenshots with translated captions. A translated description over English screenshots reads as machine output and converts like it.

Remember the byte budget

Each localised keyword field is capped at 100 bytes, not characters — and Cyrillic costs two bytes per character, so a Ukrainian listing has roughly half the room the English one has. We wrote about that trap separately; it is the single most common way a localised listing loses half its keywords silently.

Which is the same lesson as the 21 ARB files: the work is not finished when the translation is delivered. It is finished when the listing in that language is as deliberate as the English one.