A product team translates its App Store listing into eight languages, ships it with the next release, and watches installs drop in three of those markets. The copy is accurate. The grammar is correct. Any native speaker would call it good translation. It still lost rankings the English listing had held for a year.
This happens because a store listing is not a page of copy. It is a set of fields with different jobs, different character budgets and different indexing rules, sitting inside a search engine that behaves nothing like Google. Translating all of it faithfully, field by field, is the most reliable way to make a listing perform worse than the one it replaced.
App store localization done properly is keyword work first and translation second. What follows covers what each store actually indexes, which fields have to be rewritten rather than translated, how to route listing assets so cost tracks risk, and what changed when Apple expanded metadata support to 50 languages in March 2026.
Why localized listings lose rankings the English listing already held
Localized listings lose rankings when translation overwrites the keyword targeting the original listing was built on. The English name, subtitle and keyword field were chosen against measured search demand. Their translations were not chosen against anything.
The mechanism is simple enough to reproduce. An English subtitle is engineered to carry two terms with real volume. A linguist translates it into German accurately, and the German result now carries two phrases that German users never type. Ranking on the App Store and on Google Play is per market and per term. A term with no local volume returns nothing, so the listing quietly stops appearing for anything at all in that market while reading perfectly to anyone who visits it directly.
The second failure is subtler. Teams often translate the same source keyword set into every locale, which produces ten locales carrying the same ten concepts. Apple forms keyword phrases only inside a single locale, so repeating terms across locales spends the budget without adding coverage. The fix is a rule, not a tool: every field under roughly 100 characters is researched against local demand before anyone writes a word in it.
What the App Store indexes that Google Play does not
The App Store indexes keywords from more than one language inside a single territory. Google Play does not. This one difference should change how a listing budget is spent across the two stores.
Each App Store territory has a primary locale and a set of secondary locales that Apple also crawls for ranking. In the United States the primary locale is English (US), and the secondary set includes Spanish (Mexico), Chinese (Simplified), Arabic, French, Portuguese (Brazil), Russian, Chinese (Traditional), Vietnamese and Korean. France runs on French with English (UK) as secondary. Brazil runs on Portuguese (Brazil) with English (UK) as secondary.
Every locale carries 160 indexable characters: a 30-character app name, a 30-character subtitle and a 100-character keyword field. A US listing that fills its primary locale and all nine secondary locales has access to roughly 1,440 indexable characters in that one territory, against 160 for an English-only listing. A vendor who translates every locale faithfully repeats one keyword set nine times and captures none of it.
Cross-localization is an App Store mechanic with no Google Play equivalent. Notice that the secondary locale fields are keyword inventory, not translations of the primary.
Google Play works differently and rewards a different tactic. It indexes the title, short description and full description per language, with no primary and secondary structure. What it offers instead is up to 50 custom store listings per app, targeted by country, install state or ad audience. That is a positioning and conversion tool rather than a keyword multiplier, and it is wasted on teams who use it only to hold translations.
The listing fields that cannot be translated
Any field under roughly 100 characters has to be rewritten rather than translated, because target languages do not fit inside the source language’s character budget. This is a hard constraint, not a stylistic preference.
German, French and Russian commonly run 25 to 35 percent longer than English for the same meaning. CJK languages contract sharply in the other direction. A 25-character English subtitle becomes 34 to 37 characters in three of the four largest European markets, which means the store truncates it or the linguist trims it, and the trim almost always removes the keyword rather than the adjective.
The same English subtitle across four target languages. Three breach the 30-character limit before anyone has considered whether the words match local search demand.
Once expansion is on the table, the field-by-field job changes. The table below sets each listing field against its real budget in both stores and against what the field actually needs from a linguist.
| Listing Field | App Store | Google Play | What the Field Actually Needs |
|---|---|---|---|
| App Name | 30 chars | 30 chars | Keyword-led rewrite, never a translation |
| Subtitle | 30 chars | Not available | Keyword-led rewrite against local demand |
| Short Description | Not available | 80 chars | Primary keyword inside the first 30 chars |
| Keyword Field | 100 chars | Not available | Per-locale research, no terms repeated |
| Description | 4,000 chars | 4,000 chars | Human translation, refined for tone |
| Promotional Text | 170 chars | Not available | Transcreation, refreshed per campaign |
| What’s New | 4,000 chars | 500 chars | AI draft with a human accuracy check |
Character limits reset per localization, so every language added is a fresh budget rather than a share of one.
The practical consequence is that constrained fields belong with keyword-led rewriting rather than with a standard translation queue. A linguist asked to translate a 30-character subtitle will produce a faithful phrase that does not fit. A linguist given the local keyword data and the character budget will produce something that fits and ranks.
Route listing assets by risk, not the listing as one job
A store listing should be routed asset by asset, because a single submission contains content at three different risk levels. Sending all of it through one workflow either overpays for release notes or underprotects a regulated claim.
The NEX Translation Matrix™ scores content on five inputs: content type, business risk, customer impact, regulatory requirement and quality expectation. It produces three outcomes: AI drafting is sufficient, human linguists refine meaning, or independent Linguistic Quality Assurance (LQA) runs before publication. The rule that matters here is that the matrix routes content, not projects. One App Store submission usually produces all three outcomes at once, so routing runs per asset, never per release.
Five listing assets, three outcomes. The name and keyword fields sit in the middle tier not because the text is hard but because the ranking consequence of getting them wrong is high.
| Listing Asset | Business Risk | Workflow | Review Layers |
|---|---|---|---|
| Release notes, minor version copy | Low | AI drafting is sufficient | Spot check |
| Full description body | Medium | Human linguists refine meaning | Editor review |
| App name, subtitle, keywords | Medium to high | Keyword research plus rewrite | Native linguist and ASO check |
| Screenshot captions | Medium | Human linguists refine meaning | Editor and layout check |
| Health, finance or kids claims | High | Independent LQA before publication | Second linguist signs off |
Routing runs per asset. A single release commonly produces all three outcomes.
Release notes are the clearest case for automation. They are short, repetitive, low risk and shipped every sprint, which makes them a natural fit for Machine Translation Post-Editing (MTPE) rather than full human translation. Category claims are the opposite. A health app describing an outcome, or a finance app describing a return, carries regulatory exposure that varies by market and needs a second linguist to sign it off before it reaches a store review queue.
A four-stage workflow that survives weekly releases
A listing workflow works when it can absorb a release every week without someone re-briefing translators each time. Most localized listings decay not because the first pass was bad but because nothing was built to maintain it.
Keyword research comes first and gates everything after it. Reversing stages one and two is the single most common workflow error.
Stage one maps local search demand per locale, before any copy exists. Stage two rebuilds the name, subtitle and keyword field inside the character budget, using that data rather than the English source as the brief. Stage three refines the description and screenshot captions with native linguists, where meaning and tone matter more than character counts. Stage four checks the assembled listing in context for truncation, claim accuracy and store guideline compliance.
Stage four is the one teams skip, and it is where the recoverable errors live. A subtitle that reads correctly in a spreadsheet can still truncate on a 4.7-inch device. Listing work sits alongside the in-product strings handled through software UI translation, and the two should share a translation memory (TM) and glossary so the feature named in the listing matches the button label a user finds after installing. Teams running broader website and app localization programmes usually already have that memory in place and are simply not pointing the store listing at it.
Which languages to add first after Apple’s 2026 expansion
Start with languages where the product already shows unserved demand, not with the largest app markets. Signup geography, in-language organic search and support tickets in a language the product does not speak are better evidence than a market size chart.
On 31 March 2026 Apple added 11 languages for localized App Store metadata: Bangla, Gujarati, Kannada, Malayalam, Marathi, Odia, Punjabi, Slovenian, Tamil, Telugu and Urdu. That takes the App Store to 50 supported localizations and weights the expansion heavily toward India, where a single English listing has been serving a market with several hundred million non-English-first smartphone users. Google Play already supported more than 70 languages, so for many teams the Indian-language opportunity has been open on one store and closed on the other until now.
The NEX Framework™ sorts this decision into three gates. Need asks whether demand is validated by the product’s own data. Economics asks whether the case survives the full cost, including ongoing listing maintenance and in-language review responses rather than the translation line alone. eXecution asks whether the organisation can sustain the locale after launch. Most failed language launches clear Need and Economics comfortably and fail on eXecution. The guide to SaaS global expansion works through that sequencing in depth, and the search side of it is covered in the companion piece on multilingual SEO, since a localized store listing and a localized web presence reinforce each other in the same market.
The demand-side case is well established. CSA Research surveyed 8,709 consumers across 29 countries and found 76 percent prefer to buy products with information in their own language. Download-lift figures circulating in ASO content, commonly quoted as 26 to 128 percent, come from small vendor studies rather than independent research, so they are worth treating as directional rather than as a forecast.
What app store localization costs
The listing itself is a small line item. The recurring maintenance around it is the real cost, and it is the part most budgets leave out.
A complete listing runs roughly 700 to 1,200 words per locale once the description, screenshot captions and release notes are counted. At professional per-word rates that is a modest one-time spend per language. What follows it is not: release notes every sprint, screenshot refreshes at every major redesign, and review responses in-language if the team intends to answer users at all.
That maintenance pattern is why per-word rates matter less than what is bundled into them. NexTranslate includes human proofreading at every tier of its three-tier pricing model, which most providers charge separately at USD 0.02 to 0.05 per word. Across a listing portfolio refreshed a dozen times a year, a bundled review layer is the difference between a listing that stays current and one that is quietly two versions behind in six markets. The transparent per-word pricing published for each tier makes that arithmetic checkable before a single locale is commissioned.
Frequently asked questions
Is app store localization the same as app localization?
No. App store localization covers the store listing: name, subtitle, keywords, description, screenshots and release notes. App localization covers the strings inside the product. They are separate workstreams with different constraints, but they should share one translation memory and glossary so the terminology matches on both sides of the install button.
Should the app name be translated?
Usually not translated, and often not changed at all. A recognised brand name should stay intact, with the localized keyword work happening in the descriptor that follows it and in the subtitle. Names that are descriptive English phrases rather than brands are different, and those are worth rebuilding per locale against local search terms.
Does machine translation work for app store listings?
It works for release notes and for a first pass at the long description. It does not work for the name, subtitle, short description or keyword field, because those are keyword decisions constrained by character limits, and machine translation optimises for fidelity to the source rather than for local search demand or character budget.
How many languages should a listing launch in?
Fewer than most teams start with. Three to five locales that the team can maintain will outperform fifteen that go stale within two releases. The App Store’s secondary locale structure means a well-chosen handful can also earn keyword coverage in territories the team has not formally launched in.
How often should a localized listing be updated?
Release notes every release, keyword fields every quarter, and screenshots whenever the product’s core screens change. Quarterly keyword review matters because local search demand shifts with competitors and seasonality, and a listing built on last year’s terms decays without anything visibly breaking.
Conclusion: a store listing is a search asset, not a page of copy
The teams who get this right stop treating the listing as a document to be translated and start treating it as a set of ranked fields with individual jobs. Keyword research leads. Constrained fields get rewritten. The description and screenshots get human refinement. Regulated claims get an independent review layer. Release notes get automated. That sequence costs less than translating everything to the same standard and performs better than translating everything to the cheapest one.
If your listing is live in several languages and rankings have not moved, the diagnosis is usually in the constrained fields rather than in the prose. We can audit an existing listing set against local search demand and show where the character budget is being spent on terms nobody searches. Request a localization quote with your current locales and target markets, and bring the in-product strings into the same audit if they have never been checked against the listing they sit behind.
Written by Karuppusamy Arunachalam, NexTranslate
Published August 2026 · Filed under Localization
