OpenL logo

How to Localize a Mobile App

OpenL Team 3/14/2026

TABLE OF CONTENTS

If you’re searching for how to localize a mobile app, you usually don’t need “translation tips.” You need a release-safe workflow that covers app strings, layout, plural rules, right-to-left support, screenshots, and store metadata without breaking the product.

That’s the key distinction: mobile app localization is not just translating text. It’s adapting the app, the product page, and the QA process for each target market. Apple says the App Store is available in 175 regions and 40 languages, while Android 13 introduced system-level per-app language preferences. In other words, both major platforms now assume language choice is a core product experience, not an afterthought.

This guide walks through the practical steps for iOS and Android teams.

At a glance:

  • Separate in-app localization from App Store and Google Play localization.
  • Externalize strings before you translate anything.
  • Handle plurals, variables, dates, currency, and RTL early.
  • Test with pseudolanguages before you ship real translations.
  • Localize screenshots and store assets, not just descriptions.

What Mobile App Localization Actually Includes

Localization work usually falls into two tracks.

1. In-app localization

This is the product itself:

  • UI strings
  • error messages and onboarding copy
  • dates, time, numbers, currency, and units
  • plural and gender-sensitive strings
  • layout expansion and right-to-left behavior
  • images or icons that contain text or directional meaning

Apple explicitly recommends using Xcode, Foundation APIs, Auto Layout, Unicode support, localized asset catalogs, and direction-aware symbols to prepare apps for global markets. Android similarly recommends locale-aware resources, app language support, and RTL-aware layouts instead of hardcoded text and positioning.

2. Store listing localization

This is how users discover your app:

  • app name
  • subtitle or short description
  • full description
  • keywords
  • screenshots
  • app previews or promo videos

Treat this as a separate deliverable. A well-localized app can still underperform if the product page is generic, untranslated, or visually mismatched for the target market.

Start With Internationalization, Not Translation

Translation is the last step in a pipeline that starts with structure.

Externalize strings and keep a complete fallback locale

On Android, Google warns that your default res/values/strings.xml must define every string your app needs. If the default file is incomplete and the device runs in an unsupported locale, the app can fail to load and show an error with a Force Close button. That is why localization starts with resource hygiene, not language selection.

For iOS, Apple recommends separating user-visible text and images from executable code so they can be localized as resource files. In modern Apple workflows, string catalogs are the recommended approach in Xcode 15 and later for strings that contain plurals.

Practical rule:

  • never hardcode UI text in views or controllers
  • keep one canonical source language
  • make sure every user-facing string has a stable key, context, and fallback
  • include translator comments for ambiguous strings

A tiny example makes this easier to picture.

Android usually starts with a default strings.xml file:

<!-- Primary CTA on the checkout screen. Keep it short. -->
<string name="checkout_cta">Pay now</string>
<string name="welcome_title">Welcome back, %1$s</string>

Then your UI reads the resource instead of hardcoding English:

Text(text = stringResource(R.string.checkout_cta))

On Apple platforms, Xcode 15+ often manages the same idea in a string catalog. A simplified Localizable.xcstrings excerpt can look like this:

{
  "sourceLanguage": "en",
  "strings": {
    "Pay now": {
      "localizations": {
        "en": { "stringUnit": { "value": "Pay now" } },
        "fr": { "stringUnit": { "value": "Payer maintenant" } }
      }
    }
  }
}

You don’t need to memorize the file format. The operational lesson is simpler: every user-visible string needs one source of truth, enough context for translators, and a safe fallback when a locale is incomplete.

If your app also ships structured language files, our guide to Best JSON Translators in 2026 can help you think through automation and format preservation.

If you want a direct tool option for app resource files, OpenL JSON Translator is worth a look. It is designed to translate .json files without breaking keys or structure, which is exactly what you need when app strings are stored in machine-readable localization files. The workflow is simple: upload the JSON exported from your app, CMS, or localization pipeline, choose the target language, and download a translated JSON file with the same structure. According to the product page, it supports 100+ languages and files up to 50 MB, making it a practical first-pass tool for app localization teams handling structured content.

Support app-level language selection

Users increasingly expect to choose an app language separately from their device language.

On Apple platforms, users can select their preferred language for an app independently of the device language. On Android, Android 13 added a centralized app-language setting, and Google recommends enabling automatic per-app language support or wiring your picker into the official APIs.

This matters for real products. Bilingual and multilingual users may keep their phone in English but prefer a shopping, banking, or delivery app in another language. If your app forces one language model, you’re creating friction before translation quality even becomes a question.

Use the platform localization stack

Resist the urge to invent a parallel localization system unless you truly need one.

For most teams, the default platform stack is enough:

  • iOS: string catalogs, Localizable.strings, .stringsdict, Foundation formatters, Auto Layout
  • Android: res/values/, locale-specific resource folders, LocaleConfig, setApplicationLocales(), supportsRtl

Custom localization infrastructure makes sense at very large scale, but it adds operational overhead. Start with the native system, then extend only where you feel real pain.

Localize the Parts That Most Teams Miss

Teams often translate visible sentences and miss the product mechanics around them.

Plurals, variables, and grammar

Plural rules are not universal. The Unicode CLDR plural rules define categories such as zero, one, two, few, many, and other, and different languages use different subsets. Apple notes that in older .stringsdict workflows, other is the only required category, but skipping language-specific categories can still produce grammatically wrong output. Android and iOS both rely on locale-aware plural handling for a reason.

This is where naive machine translation breaks down:

  • 1 file vs 2 files is easy in English
  • Slavic languages often need more than two plural forms
  • some languages change nouns, verbs, or surrounding words together

Never build pluralized UI by concatenating fragments like "You have " + count + " messages". Use platform plural resources instead.

Here is the minimal shape of that on each platform.

Android:

<plurals name="files_remaining">
  <item quantity="one">%1$d file remaining</item>
  <item quantity="other">%1$d files remaining</item>
</plurals>
Text(text = pluralStringResource(R.plurals.files_remaining, count, count))

iOS legacy .stringsdict example:

<plist version="1.0">
<dict>
  <key>%#@files@</key>
  <dict>
    <key>NSStringLocalizedFormatKey</key>
    <string>%#@files@</string>
    <key>files</key>
    <dict>
      <key>NSStringFormatSpecTypeKey</key>
      <string>NSStringPluralRuleType</string>
      <key>NSStringFormatValueTypeKey</key>
      <string>d</string>
      <key>one</key>
      <string>%d file remaining</string>
      <key>other</key>
      <string>%d files remaining</string>
    </dict>
  </dict>
</dict>
</plist>

In Xcode 15 and later, Apple recommends handling plurals in string catalogs instead, but the principle stays the same: give the platform one message pattern and let it choose the right language form.

For deeper workflow guardrails around placeholders and structured strings, see How to Translate Technical Docs Without Breaking Code.

Dates, numbers, currency, and units

Apple explicitly recommends using Foundation APIs to format dates, lengths, weights, prices, and currency symbols across locales. The same principle applies on Android: format data with locale-aware APIs instead of hardcoding punctuation, decimal marks, or unit order.

Typical failures include:

  • 03/04/2026 meaning different things in different regions
  • hardcoded dollar signs for non-USD markets
  • 1,234.56 displayed incorrectly in locales that use commas as decimal separators
  • measurement units shown in the wrong system

If your app contains scheduling, billing, delivery windows, or analytics, this is part of localization, not polish.

Layout expansion and right-to-left support

English is usually compact. German gets longer. Arabic and Hebrew reverse reading direction. A layout that looks fine in English can break badly in other locales.

Apple recommends testing with pseudolanguages, including a right-to-left pseudolanguage and a double-length pseudolanguage, before you even import real translations. Android recommends using start and end instead of left and right, enabling android:supportsRtl="true", and testing RTL layouts on-device with Force RTL.

Your checklist here is simple:

  • allow buttons and labels to grow
  • avoid fixed-width text containers for important UI
  • mirror directional UI where appropriate
  • verify icons, chevrons, progress flows, and carousels in RTL
  • test mixed-direction text such as Arabic UI with Latin product names or coupon codes

Images, icons, screenshots, and video

Apple’s localization guidance makes an important point that many teams overlook: images can be localized too. That includes image sets, symbol sets, and directionality for custom symbols. If your screenshot contains English UI, English text in banners, or left-to-right arrows, then the screenshot itself is not localized.

That is especially important for onboarding screens, tutorial cards, and App Store assets. Users do not mentally separate “marketing visuals” from “product language.” They judge the whole experience at once.

Localize Your App Store and Google Play Pages Separately

This is where many teams lose installs even after doing the in-app work well.

App Store requirements to plan for

Apple recommends localizing metadata in App Store Connect, including the app description, keywords, app previews, and screenshots. Apple also says you can feature up to 10 screenshots on your product page, and up to 3 app previews per supported device size and language. App previews can be up to 30 seconds long, and screenshots matter even more when no preview is present because the first one to three screenshots may appear in search results.

That has two implications:

  1. Your first screenshots are discoverability assets, not just documentation.
  2. You should localize screenshots and previews for top-priority markets instead of reusing English assets everywhere.

Google Play requirements to plan for

Google Play treats listing localization as its own workflow too. Play Console lets you add localized text, in-language screenshots, and localized graphic assets. If you add text translations without localized graphic assets, Google says the default-language visuals will still show.

Google also notes that if you don’t add your own store listing translations, users may see an automated translation with a notice that it was generated automatically. That is useful as a fallback, but not a strong market entry strategy.

One especially relevant current feature: Play Console says it can continuously translate app strings using Gemini models at no cost. More specifically, Google says this applies to app strings from strings.xml in app bundles uploaded to draft releases, and that you can preview the generated translations in a built-in emulator before publishing. That’s a strong way to speed up first-pass coverage, but it should still be followed by human review for critical flows.

Build a Release and QA Workflow

A good localization process is less about translating faster and more about shipping fewer surprises.

Step 1. Pick target locales deliberately

Don’t start with “translate everything into 20 languages.”

Start with:

  • your current download mix
  • countries you actively support
  • billing, legal, and customer support coverage
  • whether you can localize both the app and store listing together

Shipping one market end-to-end usually beats shipping five markets halfway.

Step 2. Create localization-ready assets

Before translation starts, freeze and prepare:

  • source strings with context
  • screenshot list by locale
  • glossary and product-name rules
  • placeholder rules
  • character-limit guidance for store copy
  • locale-specific review owners

If the app uses separate repos or multiple file formats, standardize naming and extraction early.

Step 3. Test with pseudolocalization first

On Apple platforms, use double-length and right-to-left pseudolanguages. On Android, test unsupported locales, Force RTL, and app language settings. This catches:

  • truncated buttons
  • clipped headers
  • hidden text
  • wrong alignment
  • non-localized strings
  • hardcoded left/right assumptions

This is one of the cheapest QA passes you can run.

Step 4. Run linguistic QA on real devices

After translations land:

  • test critical flows in each target language
  • compare system language and app language behavior
  • verify plural behavior and placeholders
  • check payments, dates, and addresses
  • review screenshots and store listings in-market

If a bug affects onboarding, checkout, identity verification, or notifications, treat it as a release blocker.

A first localization sprint checklist

If this is your first serious rollout, keep the sprint small enough to finish cleanly:

  • Pick 1 target locale, not 10.
  • Freeze source strings for one release branch.
  • Export all onboarding, checkout, account, and notification strings with context comments.
  • Capture the screenshots you want to localize for App Store and Google Play.
  • Run one pseudolocalization pass before sending real text to translators.
  • Translate app strings and store listing copy in the same sprint.
  • Re-import translations and test app-language switching on both iOS and Android.
  • QA the top 5 user journeys on real devices.
  • Update screenshots, app previews, and store metadata for the same locale.
  • Ship to TestFlight or an internal track first, then watch support tickets and crash reports.

That checklist is intentionally narrow. One locale with a clean app experience and synchronized store assets teaches you far more than a rushed launch across many markets.

Real-World Examples

The core ideas above are not theoretical.

DoorDash built translation as a platform problem

In 2022, DoorDash said it had already translated more than one million strings across four languages and reduced new-language onboarding from hours of developer effort to a single command in one minute. The interesting lesson is not just scale. It’s structure: DoorDash separated static and dynamic strings, added glossary and style-guide support, and built guardrails to keep untranslated strings from slipping through.

In a February 2, 2026 DoorDash blog post, the company said its rebuilt onboarding platform now powers signups across all DoorDash markets and supports rapid international launches with seamless localization. That is exactly what mature localization looks like: reusable workflows, regional flexibility, and fewer one-off hacks.

Meta treated localization as both a language problem and an app-size problem

Meta says around 57% of Facebook for Android users and 49% of Facebook for iOS users use the app in a language other than English. In the same write-up, Meta says removing bundled translation files saved up to 16.6 MB in the iOS app and allowed Android to add nearly a dozen more languages without increasing app size.

The takeaway is useful even for smaller teams: localization has engineering consequences. It affects binary size, runtime loading, translation delivery, and release mechanics, not just copywriting.

Final Checklist Before You Ship

Use this as a last pass:

  • All user-visible strings are externalized.
  • Default fallback resources are complete.
  • Plurals and placeholders use platform-native localization support.
  • Dates, time, numbers, currencies, and units are locale-aware.
  • RTL layouts and mixed-direction text have been tested.
  • Store listing text is localized for target markets.
  • Screenshots and previews are localized for priority languages.
  • In-app language selection works as expected on iOS and Android.
  • Linguistic QA has covered the most important user journeys.

Final Thoughts

The simplest way to think about mobile app localization is this: translate the product, localize the experience, and test the release.

If you’re doing this for the first time, don’t aim for perfect global coverage on day one. Pick one or two strategic locales, localize the app and the store page together, run a serious QA pass, and learn from real usage. If you’re already managing resource files and developer-facing content, pair this workflow with How to Translate Technical Docs Without Breaking Code and Best JSON Translators in 2026.

If you only take one action this week, do this: choose 1 locale, run 1 pseudolocalization pass, and localize 1 matching App Store or Google Play listing. That three-part test will tell you more about your readiness than translating twenty locales in parallel.

If you need a fast first pass for app copy, screenshots, or structured language files, use automation to accelerate the draft, then keep a human QA step before release. That’s the part that protects user trust and prevents a “translated but not truly localized” launch.

References

Tags

i18n how to
Share this post on:
Share this post on X Share this post on Facebook Share this post via WhatsApp

Related Posts

How to Translate a Birth Certificate

How to Translate a Birth Certificate

A step-by-step guide to translating birth certificates for immigration, visa applications, and legal use — including certified translation requirements by country and common rejection mistakes.

3/6/2026
How to Translate Diploma

How to Translate Diploma

Need a certified diploma translation for immigration, university, or a job abroad? Here's how certification, notarization, and apostilles work—plus country-specific rules and tips to avoid rejections.

1/25/2026
How to Translate a CSV File

How to Translate a CSV File

Learn how to translate CSV files online without breaking columns, encoding, IDs, or special characters. Includes a step-by-step workflow, QA checklist, and troubleshooting fixes.

1/9/2026