App Localization Guide for Product Teams

Shipping a mobile app in a new language is a different problem than translating a marketing page. You're handing off structured string files instead of prose, your UI has to survive text expansion without breaking, and half your visibility comes from a store listing most teams write last. Here's how product teams get app localization right the first time.

Start with clean string files, not screenshots

Never send translators a spreadsheet of English phrases with no source. Export your actual resource files: .strings and .stringsdict for iOS, strings.xml for Android, JSON or ARB for cross-platform frameworks like Flutter or React Native. Structured formats preserve the keys your app references, so nothing gets mismatched on import.

Two things break app localization projects at this stage more than anything else:

• Concatenated strings. Code that builds a sentence from fragments ("You have " + count + " items") breaks grammar and word order in most target languages. Use full-sentence templates with placeholders instead.
• Missing plural handling. English has two plural forms; Arabic has six, Polish has four. Use your platform's plural rules system (ICU MessageFormat, Android quantity strings) rather than hardcoding "item(s)".

Give translators context, not just strings

A string like "Save" could be a button, a menu item, or a settings label, and it translates differently in French, German or Japanese depending on which. Attach context to every key:

• A short comment describing where the string appears
• Character limits for buttons and labels that can't wrap
• Screenshots for any screen with ambiguous strings
• A glossary of product and feature names that should never be translated

This single step eliminates most of the back-and-forth queries that stall app localization timelines. It also makes review faster on your side: a translator working from real context sends back fewer questions and fewer strings that need a second pass once someone on your team actually sees them in the app.

Handle pluralization and gender by rule, not by hand

Beyond the two-form plural handling above, some languages inflect adjectives and past-tense verbs based on the grammatical gender of the noun they modify, a detail that doesn't exist in English and that string-concatenation code routinely ignores. If your app assembles a sentence like " added " from separate translated fragments, the fragments can end up grammatically inconsistent in languages with gendered agreement. The fix is the same as for plurals: pass full context to the translator and use your platform's formatting system, since ICU MessageFormat handles both plural and select/gender rules, instead of string concatenation in code.

Design for text expansion and RTL

German, Finnish and Russian UI strings routinely run 30-100% longer than the English source. Test your layouts with pseudo-localized strings before real translation lands, not after. Catching a truncated button label in staging is free; catching it in a live store review is not.

If Arabic, Hebrew, Urdu or Farsi are on your roadmap, right-to-left support needs to be built with logical CSS/layout properties (start/end instead of left/right) from the start. Retrofitting RTL into a layout built with hardcoded left/right values is a rebuild, not a patch. Mirrored navigation, flipped icons, and bidirectional text handling all need to be verified on-device, not just in a simulator.

Don't forget the store listing

App Store and Google Play visibility runs on localized metadata, and it's easy to leave for last:

• Title and subtitle: localized keywords, not literal translation of the English tagline.
• Description: the first two lines matter most on both stores; lead with what the app does, not a slogan.
• Screenshots: captions and any on-image text need translation, and screenshots ideally reflect the localized UI, not the English build.
• What's New notes: translate these per release if you want retention in that market, not just the initial listing.

An app that's fully localized inside but ships an English-only store listing loses most of the organic discovery it should be getting in that market.

Keyword research for store listings, not literal translation

Store search behaves like web search: people type what they'd naturally search for, not a literal translation of your English keywords. A fitness app's English title might lead with "workout tracker," but the term a Spanish-speaking user actually searches for in the App Store may be phrased differently enough that a direct translation underperforms. This is worth researching per market before finalizing the localized title and subtitle, the same way you'd research keywords for a web page rather than assume the translation carries the same search intent.

QA the build, not just the text

Have a native speaker test the actual installed app, not just review translated strings in isolation. This catches truncation, RTL mirroring bugs, and context mismatches that never show up in a spreadsheet. Pay particular attention to:

• Dynamic content built from user data or API responses, which are the strings most likely to have been missed during extraction
• Push notifications and system-level alerts, which sometimes live in a separate resource file from the main UI strings and get forgotten
• Onboarding flows, since a confusing first screen in the wrong language costs you the user before they've seen anything else the app does well

What a launch-ready localization batch looks like

For most product teams, a first localization pass covers three things in this order: the core UI string files, the onboarding and paywall screens specifically since these drive conversion, and the store listing. Legal text (terms, privacy policy, subscription disclosures) needs the same accuracy bar as the UI but can usually be scheduled in parallel rather than blocking the rest of the release.

Send us your exported string files and target languages through our localization service. We translate with full context notes, flag any strings that look ambiguous or hardcoded before work starts, and can cover store listing copy in the same order. Get a quote for your app and tell us which platforms and languages you're targeting.