App localization is more than translated copy
An app is localized for a market only when its store page, interface, examples, legal information and support work together. A translated description alone does not create a local product.
Apple and Google Play support localized metadata and images, but handle missing languages differently. Apple selects another relevant localization or the primary language, depending on the language and storefront. Google Play users can choose an automatic translation or the default language; when localized graphics are missing, the default-language graphics remain. We therefore check text and images separately: translating a description does not make foreign-language screenshots understandable.
We plan localization as a product change. Every language gets ownership, source copy, a glossary, screenshots, test states and an approval path. Machine translation can assist a draft, but it does not replace domain review.
Market fit before language
Before translation, confirm that the product can be offered, paid for, supported and operated legally in the market. Search demand alone is not enough.
Even a shared language contains regional differences. US, British and Australian English can share one page when the offer is genuinely the same, but local claims must not be invented.
Keep store and product in sync
App name, subtitle, descriptions, keywords and screenshots need to reflect the current product. When a listing promises a localized function but the core flow falls back to the source language, trust breaks.
Store localization is therefore reviewed together with interface strings, error states, email and support material.
Before translation, confirm that the product can be offered, paid for, supported and operated legally in the market. Search demand alone is not enough.
App name, subtitle, descriptions, keywords and screenshots need to reflect the current product. When a listing promises a localized function but the core flow falls back to the source language, trust breaks.
Localize images for real
A screenshot can contain more foreign-language content than the headline above it. Date formats, map locations, names, examples and navigation labels all need review.
When an image does not fit culturally or operationally, use a different subject instead of a new text layer. Every variant remains grounded in a controlled product state.
Publish statically and connect versions
For the supporting website, we use static, editorially reviewed language pages. Each version has its own URL and canonical; hreflang connects only genuine equivalents. Content stays consistent for people and crawlers without runtime translation.
After release, queries, store views, install steps and support questions are reviewed by market. A language should not remain published if nobody can maintain it.
Localization definition of done
A language is complete only when these areas agree.
- Real market and support scope confirmed
- Glossary and product vocabulary approved
- Store metadata manually reviewed
- Screenshots and example content localized
- Core journey, errors and email tested
- Privacy and support links reachable
- Canonical and hreflang technically validated
Localization is product maintenance
Steingraf Labs connects store, interface, website and release checks. A new language becomes an operable part of the product instead of an isolated marketing asset.
View the related serviceReviewed primary sources
Platform rules change. Each guide therefore links to the official material behind its technical statements.