Localisation as transcreation

Expert: with sources and numbers. Plain: the same, without them, for beginners.

Why translating metadata produces text that ranks for nothing, and what to do instead.

Verified 2026-09-19 · 37 days ago both keywords localisation

Translation converts your words into another language. Transcreation finds out what people in that market actually type, and writes for that. The first produces metadata that ranks for terms nobody searches.

Why translation fails

A translated keyword field is a list of correct words that are not the words people use.

  • The common term is often not the dictionary term. Loanwords, English borrowings and local brand-generics are frequently what people type, and a translator will correctly avoid them.
  • Query length varies by language and market. How people phrase a search is a cultural habit, not a grammatical fact.
  • Ambiguity does not survive. A word that usefully covers two meanings in English usually splits into two words elsewhere, doubling your keyword cost or halving your coverage.
  • The category vocabulary may differ. What an app “is” can be named differently in different markets.

A This matters because every text field is set per localization (Required, localizable and editable properties, verified 2026-09-18), and A Apple’s search matches against title, subtitle, keywords and primary category (App Store search), in whichever localization the user is served.

Start from storefronts, not languages

A Each storefront has a default language plus additional supported languages, and which languages those are differs sharply: the US supports eight additional languages, Germany one, India ten. A What a user sees depends on the App Store language for their location, their device language, the localizations you have added, and your primary language; where nothing matches, it falls back to the storefront default or your primary language. (App Store localizations, verified 2026-09-18)

Two consequences people miss:

One localization can serve several storefronts. Spanish (Mexico) is indexed in the US storefront as well as across Latin America.

The cheapest expansion is usually inside a market you already have. Adding a language that your existing storefront additionally supports is often better value than entering a new country. See 10-07, and 10-11 for which languages each storefront indexes.

How to do it

Research in the target language, from scratch. Not “translate the English list then check it”. Start from how the problem is described locally: competitor listings in that storefront, reviews written in that language, store autocomplete with the storefront set correctly, your own support tickets from that market.

Use a person who uses apps in that language. Not only a translator. The question is not “what is the correct word” but “what would you type”.

Validate before committing. Terms you are unsure of can be tested in an Apple Ads campaign in that storefront before they take metadata space (30-09).

Localize indexed fields first, visible fields second. If budget forces a sequence: name, subtitle and keywords carry search; description and promotional text carry conversion. But do not ship a localized subtitle above an English description and call the market localized.

Tier your markets. A handful get real research and localized creative; the rest get correct, unembarrassing metadata. Fifty markets at equal depth produces fifty mediocre ones (00-06).

The cheap way in: machine translation where nobody reads it

Everything above is an argument against machine translation. There is one place the argument does not apply, and it is the useful exception when you are deciding whether a market is worth real money.

The iOS keyword field is not visible to users. So a machine-translated keyword field carries no conversion risk at all, the worst case is that it ranks for terms nobody types. That makes it a probe: fill it, watch whether anything moves in impressions and installs from that storefront over a quarter, and use the answer to decide whether to fund a real localization. Practitioners call this a minimum viable localization.

Two conditions, and they are not optional.

Check every translated term against a live search before you use it. A translation can be correct and still be the wrong word. The example that makes this concrete: machine-translating “film editor” into German returns Filmredakteur: which is the job title, not the activity, and a search shows almost no apps competing for it, because nobody looking for a video editing app types it. The translation is right; the term is dead. A results count or a Search Popularity check catches this in seconds (30-01, 30-02).

Do not extend it to visible text. Title, subtitle, short description and screenshots are read, and a machine-translated visible page costs conversion and credibility in exactly the market you are trying to evaluate. If the probe works, the visible text is the thing you then pay a human for.

This does not apply on Play. Play’s description is indexed and visible, so there is no hidden field to probe with. And Google already offers users an automated translation of an untranslated listing (20-01), so adding your own machine translation on top mostly replaces one automatic translation with a worse one you now own.

Creative is part of this

B Creative localisation is the most commonly skipped lever in ASO, and it is skipped because it is expensive rather than because it does not work. Screenshot captions are text a user reads in the search result itself; leaving them in English in a non-English storefront is the most visible possible signal that the app was not made for that market. See 40-07.

What goes wrong

Machine-translating the keyword field. Produces correct words nobody types.

Localising visible text only. The keyword field is where the ranking is, and it is the field nobody reviews internally because nobody reads it.

Treating a language as a market. Spanish in Mexico, Spain and the US are three different search vocabularies.

Leaving the primary language wrong. It is the fallback for every storefront you have not localised, the default experience for most of the world.

Adding localizations you will not maintain. A stale localization is worse than none: users still see it.

In short

Every fact on this page in one line, with its evidence tier, source and verification date, 4 A · 1 B. Generated from the claim register, so it cannot drift from the page above.

A Apple's App Store localizations reference lists 50 languages and locales for app metadata, including Croatian.
IOS-LOC-001 · verified 2026-09-18
A Each storefront has a default language plus additional supported languages. For example the US storefront defaults to English (US) and additionally supports Arabic, Chinese (Simplified and Traditional), French, Korean, Portuguese (Brazil), Russian, Spanish (Mexico) and Vietnamese.
IOS-LOC-002 · verified 2026-09-18
A The localization a user sees is determined by the App Store language setting for their location, their device language settings, the localizations added to the app, and the app's primary language; where nothing matches, the store falls back to the storefront default or the primary language.
IOS-LOC-003 · verified 2026-09-18
A App name, subtitle, keyword field, promotional text, description and What's New are all set per localization.
IOS-LOC-004 · verified 2026-09-18
B Creative localisation is the most commonly skipped lever in ASO, skipped because of production cost rather than because it does not work.
CRE-LOC-001 · verified 2026-09-18

Think your app deserves better?

Send the App Store link.
The audit comes back within two working days, whether you hire us or not.

Free, and we mean it. No card, no call required.