Mobile App Localization Guide: i18n for International Apps

Localization is one of the highest-leverage decisions a mobile app can make — and one of the easiest to do badly. A well-localized app unlocks markets that already want what you offer; a poorly localized one becomes a credibility liability the first time a German user sees a date in MM/DD/YYYY. This guide covers the architectural and workflow decisions that separate clean i18n from the kind that haunts your codebase for years.

Internationalization vs Localization

The two terms get used interchangeably, but they describe different work. Internationalization (i18n) is the engineering work of preparing your app to support multiple languages and regional formats. Localization (l10n) is the content work of producing the actual translated strings, currency formats, and culturally appropriate copy.

i18n is a one-time architectural investment. l10n is recurring operational work that grows with every market you enter. Confusing them leads to under-investing in the architecture and over-investing in translation tooling that the codebase can't actually use.

For a related architecture topic, see our guide on mobile development best practices.

String Externalization: The Foundation

Every user-facing string must live outside your code. No exceptions. Strings inline in JSX or Swift views are the single biggest cause of half-localized apps.

React Native

The standard pattern is a translation file per locale and a hook to look up keys:

// locales/en.json
{
  "welcome": "Welcome back, {{name}}",
  "items_count_one": "{{count}} item",
  "items_count_other": "{{count}} items"
}

// usage
const { t } = useTranslation();
<Text>{t('welcome', { name: user.firstName })}</Text>

Use i18next with react-i18next for production apps. It handles plurals, interpolation, namespacing, and lazy-loading translation bundles by route.

iOS (Swift)

Use Localizable.strings files per locale and the String(localized:) initializer. Xcode 15+ supports String Catalogs (.xcstrings) which dramatically improve the workflow over legacy strings files.

Android (Kotlin)

Use strings.xml in values-{locale} resource folders. Android's plural rules and string formatting are mature and well-documented; lean on the platform rather than rolling your own.

Locale-Aware Formatting

Translation is the obvious work. Locale-aware formatting is where most apps quietly fail:

• Dates: 5/7/2026 in the US is 7/5/2026 in most of Europe. Use Intl.DateTimeFormat in JavaScript, DateFormatter in Swift, or java.time.format in Kotlin — never string concatenation.
• Numbers: 1,000.50 in the US is 1.000,50 in Germany. Use Intl.NumberFormat or platform equivalents.
• Currencies: $9.99 vs €9,99 vs ¥9 (no decimals). Currency formatting is locale-dependent, not just symbol substitution.
• Plurals: English has two forms (one, other); Russian and Arabic have many more. Use ICU MessageFormat-aware libraries.
• Sort order: Å sorts after Z in Swedish but with A in English. Use locale-aware collation.

Right-to-Left (RTL) Support

Adding Arabic, Hebrew, or Urdu support means the entire UI mirrors. This is more than flipping text alignment — it affects layout direction, navigation, icons, and animations.

What flips automatically

With proper RTL setup, text alignment, flexbox direction, padding/margin start/end, and navigation transitions all mirror. React Native's I18nManager.allowRTL(true) and using start/end instead of left/right in styles handles most of it.

What doesn't

Icons that imply direction (back arrows, send icons, progress bars) need RTL variants. Hard-coded animations that translate "from right to left" become "from left to right" in RTL. Time-based content (a chat thread) usually keeps its temporal flow but reverses its visual layout.

Test RTL early. Adding it to a mature app is a 4–8 week project; building it in from day one is a few extra hours per screen.

Translation Workflows

The translation pipeline matters as much as the code.

Translation Management Systems

Don't email translators a spreadsheet. Use a TMS:

• Lokalise — strong React Native and iOS/Android integrations, screenshots for context
• Crowdin — community translation, in-context editor, GitHub sync
• Phrase (formerly PhraseApp) — enterprise-grade, machine translation pre-fill

Each integrates with CI to pull new strings on commit and push translations back as PRs.

Context for Translators

The single biggest quality lift is providing screenshots and context notes. "Save" with no context could be a button label, a verb, or a noun. A screenshot shows the translator exactly what they're translating. Most TMS tools support automatic screenshot capture.

Pseudolocalization

Generate a fake locale that wraps every string with accents and expansion characters: "Save" becomes "[!! Šávé !!]". Run your app in this locale to catch hard-coded strings, layout breaks from longer translations, and missing string externalizations — without waiting for real translations to come back.

App Store Localization

The store listing matters as much as the app. Localize:

• App name (when culturally appropriate)
• Short description / subtitle
• Full description
• Keywords (huge ASO impact)
• Screenshots (text in screenshots must be in the target language)
• Preview videos and captions

App Store Connect and Google Play Console both support per-locale store metadata. Localized keywords alone can lift install rates 20–40% in target markets.

Common Pitfalls

Patterns that quietly break localized apps:

• Concatenating strings: "You have " + count + " items" doesn't translate cleanly. Use full sentences with interpolation.
• Hard-coded English plurals: count + (count === 1 ? " item" : " items") assumes English plural rules. Use the i18n library's plural function.
• Fixed-width UI: German is often 30% longer than English. Buttons sized for "Save" overflow with "Speichern unter".
• Imageified text: Text inside images can't be translated. Render text in HTML/native views, not in image assets.
• Forgetting accessibility labels: VoiceOver and TalkBack labels need translation too.

Frequently Asked Questions

Should we use machine translation?

Use it for first-pass drafts and for low-stakes content (admin tools, internal apps). For user-facing strings in supported markets, always have a human reviewer. Machine translation has gotten dramatically better but still misses tone, register, and culturally specific phrasing.

How many languages should we launch with?

Start with English plus 2–3 high-priority markets based on actual user demand or planned expansion. Adding languages costs ongoing maintenance; resist the urge to launch in 20 markets at once unless you have a localization team.

What about regional variants?

Spanish-Spain vs Spanish-Mexico, Portuguese-Brazil vs Portuguese-Portugal, French-France vs French-Canada — these matter. Falling back from es-MX to es-ES usually works as a stopgap, but for primary markets, pay for the regional variant.

How do we handle user-generated content in multiple languages?

Detect the language of submitted content (most cloud providers offer language detection APIs) and let users filter or auto-translate. Don't try to enforce a single language for UGC — you'll lose users in non-primary markets.

Related Reading

• Mobile Development: The Complete Guide
• Internationalization for Websites
• Mobile UX Design Principles
• Mobile App Onboarding UX