App Store localization traps: inheritance, editable state and review
Localizing a store listing is not the same job as localizing the app. You can ship a listing in a dozen languages while the app itself stays English-only. Apple is explicit that App Store Connect metadata is separate from the app binary — you add a localized entry without changing anything in the build. Google Play works the same way: store-listing text and graphics are their own thing, uploaded in Play Console.
So the reason localization feels like a slog isn't the stores fighting you. It's the volume of manual, per-locale data entry — and two traps that only show up after you've already clicked into the tenth language. Here's the step-by-step for each store, then the gotchas.
What "localize the listing" actually covers
On both stores, the localizable listing fields are roughly: the app name / title, subtitle (Apple) or short description (Google), the full description, the keyword field (Apple only — Google indexes the whole description instead), and the screenshots. None of that requires a new binary submission. A translated listing can go live for a market where the app UI is still in English.
Localizing on the App Store (App Store Connect)
- Get the app into an editable state. Apple's help is blunt here: "You can manage languages only when the app status is editable." If your version is In Review or Pending Developer Release, you can't add or change localizations until it moves back to an editable status.
- Open the language menu. In the app's page (or the App Information page for shared fields), click the primary language name in the top right, scroll to "Not Localized," and click the + next to the language you want.
- Fill in the fields that did NOT copy over. This is the trap. When you add a language, Apple copies your screenshots and most properties from the primary language "except for the description and keywords." Those two land blank. Nothing warns you — the locale looks mostly populated, so it's easy to save a listing whose description silently fell back to the primary language.
- Handle App Information separately. The app name, subtitle, and privacy policy URL live under App Information (shared metadata), not the version page. Add the language there too and enter those values per locale.
- Localize the screenshots. Because screenshots inherit from the primary language, a new locale ships with your English screenshots unless you replace them. If your captions are baked into the images, that means uploading a translated set per locale.
- Save, then submit for review. New-language metadata isn't live just because you saved it. App Review must approve the new language; you submit a version carrying the localized metadata for approval. Plan for that latency, not an instant flip.
Localizing on Google Play (Play Console)
- Open the translations tool. In Play Console, go to Grow › Store presence › Store listings and products, then Manage translations. This is where all languages for the listing are managed in one place.
- Add the languages. Under Manage translations, choose Select languages, tick the languages you want, click Apply, then Save. They now appear as rows you can fill in.
- Provide the text — three options. Paste your own translations; or use Google's free machine translation for a rough draft; or, from the same menu, order paid human translation from Google's third-party vendors. Google quotes roughly USD 0.07 per word with translations back within about seven days, covering the store listing (title, short description, full description) and in-app products.
- Apply per language, then Save. After translations come back, open the row for each language, review the title / short description / full description / screenshots, and save. Google also reviews store-listing changes before they go live, so this isn't instant either.
How many languages does Google Play support for the listing? Google doesn't publish one clean headline number, and the commonly cited figures run from roughly 77 to about 88 store-listing languages and dialects depending on how variants get counted — so treat any single figure you see as approximate. The practical point: it's dozens, more than enough to cover every market worth targeting.
The gotchas nobody spells out
- Apple's inheritance trap. Screenshots and most fields copy from the primary language; description and keywords don't. Half your work is remembering which locales still have a blank description hiding behind an otherwise-full page.
- Screenshots inherit too — which cuts the other way. A new locale ships with your primary-language screenshots automatically. Convenient if you haven't localized the images yet, misleading if you forget to swap them and ship English captions to a Japanese storefront.
- The keyword field is per-locale and worth guarding. Apple gives you a 100-character keyword field per language, and it's hidden from users. Machine-translating it word-for-word wastes the slot — the terms people actually search in each market rarely match a literal translation. Google has no separate keyword field; it indexes your full description, so keyword intent has to live inside the prose per locale.
- Editable-state timing. On Apple you can only touch localizations while the app status is editable. Batching your localization work before you lock a version for review saves a round of "why is this field greyed out."
- Review applies per new language. Both stores review new-language metadata. There's no path where you paste 40 translations and they're all live in the next minute — the copy step is yours, but the go-live is still on the store's clock.
- Character limits differ and translations expand. German and Finnish routinely run 30-40% longer than English; a subtitle that fit in English can overflow Apple's 30-character limit once translated. Check the limit per field, per locale, not just once.
Where Mokbi fits
The stores handle the plumbing — adding a locale, storing the text, reviewing it. What they don't do is write the per-locale metadata for you, and that's the part that turns 50 languages into a week of copy-paste. Mokbi generates and translates every locale's listing fields — title, subtitle, keywords, and description — into 50 languages in one pass, so you're not filling each App Store Connect language by hand or pasting rows into Play Console one at a time. The keyword field gets treated as keywords, not run through a literal translation, so that 100-character slot isn't wasted.
Being honest about the boundary: this gets you a complete, localized set of fields ready to drop into each store. It doesn't bypass review. Each new language's metadata still goes through App Review on Apple and Google's own listing checks — no tool can auto-publish around that, and anyone claiming otherwise is glossing over how the stores work. What you save is the manual authoring and the per-locale copy, which is where the days actually go.
You can localize the screenshots in the same project — build the carousel once, translate the captions across all 50 languages, and export a set per locale so you're not shipping English images under a translated listing.