How to Localize Your App Store Listing by Reusing Your Strings File

You already did the hard part. A translated strings file is not just UI copy. It is a glossary of feature names, actions, and benefits written in context for a real locale. Treat the store listing as a reuse job: mine that vocabulary, then write listing text that sounds like the app the user will actually open. Do not start from a blank marketing brief and machine-translate English ASO copy.

That reuse has a hard stop. Description and promotional text can be assembled from in-app language. The App Store keyword field cannot. It is a ranking surface with a byte budget, not prose, and filling it is search research, not translation.

What the strings file already gives you

Open the locale you are about to ship (for example Localizable.strings, xliff, or Android strings.xml). You are looking for tokens users will type into store search and for phrases that already explain what the app does:

• Feature nouns as they appear on screens, settings, and empty states (not internal key names).
• Primary verbs on buttons and menus: export, scan, sync, track, convert.
• Category language the UI already committed to: habit, invoice, workout, caption, and so on.
• Short benefit lines from onboarding or paywall copy that survived translation in context.

Prefer terms that translators chose while looking at the UI. Those are usually more natural than a glossary applied to an English listing after the fact. Drop developer-facing strings, formatters, plurals plumbing, and anything the user never sees.

Build a locale-specific term list before you touch App Store Connect. That list is the raw material for description and promotional text. It is only a candidate list for keywords.

App Store fields you can localize (confirmed limits)

Apple documents localizable platform version metadata per language in App Store Connect. The numeric limits below are the ones Apple states explicitly. Do not substitute third-party “character” figures where Apple specifies bytes, and do not invent limits for fields Apple’s reference does not quantify.

App Name and Subtitle exist in App Information / platform version metadata and are part of the localization you fill in Connect. Apple’s retrieved reference does not state their character limits, so do not assume a number. Type into the console and respect whatever it enforces.

Promotional text is the right place for one localized claim you already paid to translate in onboarding: what the app does, in 170 characters. Description is where you expand with the feature vocabulary from the strings file, up to 4000 characters.

Keywords are not a translation of the English keyword field

Apple’s definition: one or more keywords, each greater than two characters, describing your app, with up to 100 bytes of content. That is the entire official constraint set to use. Apple specifies bytes, not characters. Multi-byte scripts consume the budget faster than English. Count in bytes before you paste.

The retrieved Apple reference does not document comma rules, spaces, or which other metadata fields are indexed. Do not treat blog formatting lore as policy. Use the field as a compact list of search terms, not as a sentence, not as a comma-separated translation of your English keywords.

Reuse from the strings file only when a UI term is also a term people search in that locale. A perfectly translated settings label can be useless for ranking. A search term that never appears in the UI can still belong in the 100-byte field. Workflow:

1. Start from the mined term list so you do not invent a second vocabulary.
2. Check each candidate against how users in that language actually search (autocomplete, competitor listings, your own support mail).
3. Keep terms longer than two characters.
4. Stop at 100 bytes. Cut low-value synonyms first, not the primary feature noun the UI already uses.

If a term is already in your localized name or description, you may still want it in keywords, or you may spend the bytes elsewhere. Apple’s retrieved reference does not define overlap rules. Optimize empirically; do not assume indexing behavior that is not documented there.

How you add a localization

In App Store Connect, add a language/locale, then supply that locale’s metadata on the platform version information screens: description, promotional text, keywords, screenshots, and the other version fields the console shows. There is no separate “ASO project.” It is the same version record, duplicated per localization.

Apple’s retrieved reference does not document what a storefront displays when you have not supplied a localization for that language (including whether text or screenshots fall back to a default such as English (U.S.)). Do not plan on an undocumented fallback. If you care about a storefront, add the localization and fill the text fields.

Screenshots: required, inherited, or neither?

Apple treats screenshots as platform version assets associated with specific localizations: “Screenshots that show what your app looks like on a device.” App previews are likewise version assets you can configure per localization. The retrieved reference does not say localized screenshots are required, does not give a per-locale count, and does not say missing sets are inherited from a base language.

Practical rule for an indie build: if you created a localization, capture screenshots from the localized binary so the listing chrome matches the UI strings you already translated. That is consistency with the product, not a documented inheritance policy. If you skip locale-specific screenshots, do not claim Apple will or will not substitute another set; the official page does not say.

Google Play: same reuse job, different console

Play Console store listing localization is a parallel task, not a copy of App Store Connect fields. Industry pages commonly talk about app name (title), short description, and full description, plus extra custom store listings targeted by country or URL. Official Google numeric limits, custom-listing caps, and in-console machine or human translation options are not confirmed in the documentation set used for this guide. Read the limits from Play Console as you type; do not paste Apple’s 4000 / 170 / 100-byte figures into Play.

Reuse still applies. Mine the same translated string resources for Play body copy. Do not translate Apple keywords into a Play description, and do not invent a Play “keyword field” equivalent that Google does not document here. Custom store listings, when the console offers them, are additional listing variants. Fill them from the same term list if you use them; do not assume a documented maximum count.

Workflow: strings file to listing

1. Freeze the locale in the app. Listing copy should follow the shipped UI language, not lead it. If a feature name is still disputed in translation, it does not belong on the store yet.
2. Export the translated file for that locale. Grep or spreadsheet-filter user-visible values. Collapse duplicates.
3. Cluster terms: product category, core actions, differentiators, audience. This is your outline for description.
4. Write description in the target language using those clusters. Stay inside 4000 characters on Apple. Do not back-translate English ASO paragraphs unless the strings file actually supports those claims.
5. Write promotional text last as a 170-character slice of the same pitch, not a new slogan invented in English.
6. Build keywords separately. Run search research in the locale. Intersect with the term list. Pack the 100-byte field with terms greater than two characters. This step is ASO, not localization.
7. Paste into a new App Store Connect localization for that language. Confirm Name and Subtitle in the console without assuming an undocumented length.
8. Optional visuals: run the localized build, capture screenshots (and previews if you use them) for that localization. Apple does not document inheritance; supplying them is how you control what appears.
9. Repeat in Play Console with that store’s fields and the limits the UI enforces. Reuse the description draft; re-fit it. Do not reuse Apple keyword bytes as if Play had the same control.
10. What’s New: if you localize release notes, keep them to 4000 characters and aligned with what the version actually changed. Do not spend translation budget restating the full description.

The quality bar is simple: a user who reads the listing, installs, and opens the app should see the same words. You already paid for those words in the strings file. The listing is where you put them in front of search and the product page, except for the keyword field, which exists to get the page found, not to be read.

The full list of App Store languages covers which localizations exist and a sensible order to add them, and the download numbers cover what to expect afterwards. For the binary side, start with the complete app localization guide.

Frequently asked questions

What does it mean to localize an App Store listing if I already translated my app?

It means adding a language in App Store Connect (and the matching Play listing) and filling that locale’s metadata. Reuse feature vocabulary from the translated strings file for description and promotional text; do not treat keywords as a translation of the English keyword field.

Which App Store listing fields are localizable and what are the official length limits?

Apple documents description at 4000 characters, promotional text at 170 characters, keywords at up to 100 bytes with each keyword greater than two characters, and What’s New at 4000 characters. Screenshots and app previews can be set per localization; Apple’s retrieved reference does not give their counts. Name and subtitle exist as metadata but their limits are not in that reference.

Can I translate my English keywords into each language?

No. Keywords are a 100-byte ranking field, not prose. Mine UI terms as candidates only, then keep or drop them based on search research in that locale. Apple specifies bytes, so dense scripts fill the budget faster.

Does Apple require localized screenshots, or does it inherit the default set?

Apple associates screenshots with each localization but does not document a requirement to upload them or inheritance from a base language. If you need the product page to show localized UI, capture shots from the localized build yourself.

What does a storefront show if I never add that language?

Apple’s retrieved platform version reference does not define fallback for missing localizations. If a storefront matters, add the localization and supply the text fields rather than relying on undocumented behavior.

How do I localize a Google Play listing using the same strings file?

Use the same mined terms for Play’s listing copy, then enter them in Play Console and obey the limits the console shows. Official Google character limits and custom store listing quotas are not confirmed in the documentation set for this guide; do not copy Apple’s 100-byte keyword model onto Play.