App store localization adapts the listing people see before downloading: the name, short copy, description, keywords where supported, screenshots, and release notes. Start with a supported market, create a reviewed draft, and verify the published listing before measuring results.
This workflow covers store listings. For string resources, plural forms, RTL layouts, and in-app testing, use the separate mobile app implementation guide. Translating a product page does not translate the product.
Step 1: Choose the market and the job
Use a concrete signal: existing users asking for a language, meaningful visits from a market, local demand for the core task, or a client requirement. Check whether your content, purchase flow, service availability, and support work there. Language and country are not interchangeable.
Write down the locale, intended audience, reviewer, source version, and what success would mean. For a first market, check whether people understand the listing and can complete the task it describes. Use your own results to set the next goal. Compare options with the language prioritization guide.
Step 2: Freeze an accurate source listing
Before translating, remove outdated features, unqualified superlatives, invented reviews, and promises your product cannot fulfill. State the main task in the opening. Record which features need an account, subscription, network connection, or supported device.
If you need a new source draft, metadata generation can prepare fields for review. Give it actual features, audience, relevant terms, and the claims to avoid. Check every generated claim against the app before translating it.
Step 3: Map the correct fields
| Apple App Store | Google Play | Review task |
|---|---|---|
| Name | Name | Keep the brand recognizable and the function clear |
| Subtitle | Short description | Write separately for each field allowance |
| Keyword field | No equivalent dedicated field | Research relevance; avoid stuffing descriptions |
| Description and promotional text | Full description | Explain real features, scope, and requirements |
| Screenshots, previews, release notes | Visual assets and release notes | Match the shipped product and current release |
Use the current character-limit reference as a drafting aid, then validate in the store console. Google documents localization separately from its default and translated listing behavior; review language fallback instead of assuming every visitor sees the same page.
Step 4: Translate with context
Provide the source copy, screenshot context, product glossary, and regional variant. Research how people describe the task locally; an English keyword translated literally may miss the phrasing people use. Keep claims, amounts, and product limitations intact.
AppDrift metadata translation supports 60+ languages and prepares AI drafts adapted to their context. Check the token quote for your work and review the result. Start with the languages you have time to review and maintain.
Step 5: Localize the visual explanation
Use actual localized UI captures where the app supports them. Rewrite captions for readability and check text direction, local number/date formats, and important labels. Avoid a generic rule that every country prefers one visual style; ask a reviewer whether the campaign explains the task clearly.
Keep one coherent campaign with the strongest explanation first. The screenshot editor can assemble those captures; public template previews show Free and Pro collections before selection. Check every exported size on a phone-sized view, not only on a large desktop canvas.
Step 6: Review the complete version
- Read every field independently for meaning and length.
- Check terms against your glossary and the app's actual labels.
- Test the core task in the product with the intended language settings.
- Review captions, visible UI, screenshots, links, and release notes together.
- Record unresolved questions and the version the reviewer approved.
Use Listing updates to keep the next version together. Preparation is free; translation shows its token quote, while paid workflows include supported store sending and approved-wording reuse. If you use approval, you still choose when to send the approved version.
Step 7: Send only the approved scope
Review the app, store, locale, fields, and destination state before sending. A saved AppDrift draft, a successful API response, an accepted review submission, and a public store page are separate states. Apple's editable-property reference explains why field changes depend on app status.
AppDrift supports sending listing text to connected stores with paid access. Supported Apple screenshot uploads go to an App Store Connect draft after setup; Google Play screenshots require export and manual upload. Binary upload, code signing, review, and public availability remain separate release work.
Step 8: Measure and maintain
Save the live URL, publication date, source version and locale. Then check how people found the listing, how many installed and whether they used or paid for the app. A before-and-after change is observational; note paid campaigns, product updates, and seasonality before drawing a conclusion.
Update translations when the underlying promise changes. Keep unchanged approved wording only when the context still matches. If the market has little traffic, say that the result is inconclusive and use feedback to fix evident problems. For the complete review list, follow the 28-step localization checklist.
Frequently asked questions
What is minimum viable listing localization?
It is a small, complete listing for a supported market, with accurate copy, relevant terminology, reviewed screenshots, and a way to maintain the work. Keep the first release small enough to review completely.
Should I translate every supported language before launch?
No. Prioritize demand, product support, review capacity, and maintenance. More translated fields do not establish more customers.
Can I publish immediately after translation?
Review the draft first. Store editing permissions, app state, review, and release availability still apply. A successful translation does not publish a listing.
How does this differ from in-app localization?
Store listing localization changes the page before installation. In-app localization changes resource strings, layouts, formats, and user journeys inside the product.
