Manage multiple languages in your app

Flutter handles localization through the official intl package and ARB files. ARB, short for Application Resource Bundle, is a simple JSON format where each key maps to a translated string, and you keep one file per locale, such as app_en.arb and app_es.arb. You enable code generation in your pubspec so that Flutter builds a typed messages class from those files, then you read strings through AppLocalizations.of(context) instead of hard-coding them. The framework picks the right ARB file based on the device locale, and MaterialApp exposes a supportedLocales list plus localization delegates that also translate built-in widgets like date pickers. The workflow is: extract every string into your template ARB, translate the copies, regenerate, and reference the generated getters in your widgets.

1. Add flutter_localizations and intl to pubspec.yaml, and turn on generate: true under the flutter section.
2. Create a template file such as lib/l10n/app_en.arb with your source strings and their descriptions.
3. Add one ARB file per target locale, keeping the same keys with translated values.
4. Wire supportedLocales and localizationsDelegates into your MaterialApp so Flutter resolves the device locale.
5. Replace hard-coded text with AppLocalizations.of(context) getters and rebuild.

React Native has no built-in localization layer, so the common stack is i18next with react-i18next, paired with a locale detector. You store translations as JSON namespaces, one object per language, and wrap your app in an I18nextProvider. Components then read copy through the useTranslation hook and a t('key') call. To detect the device language you add a small library such as react-native-localize, which reports the preferred locales and the region so you can pick a sensible default and fall back gracefully when a translation is missing. i18next also has first-class support for pluralization and interpolation, which saves you from writing that logic by hand. The mental model is identical to Flutter: strings live in data files, code references keys, and the active language decides which file wins.

• i18next plus react-i18next for the translation store and the useTranslation hook.
• react-native-localize to read the device's preferred languages and region.
• One JSON file per language, ideally split into namespaces by feature so files stay small.
• A missing-key handler that falls back to your default language instead of showing a raw key.

These are the details that separate a translated app from a genuinely localized one. Plural rules differ by language: English has two forms, but Polish and Arabic have several, so you must use the plural syntax your library provides rather than an if-else on count. Dates and numbers also vary, where 1,000.50 in the United States is 1.000,50 in much of Europe, and calendar formats flip day and month order. Both intl in Flutter and Intl in JavaScript format these correctly from the locale, so never format them by hand. Right-to-left languages such as Arabic and Hebrew need the whole layout mirrored, not just the text. Flutter does this automatically when you set the text direction from the locale, and React Native exposes I18nManager for the same purpose. Test RTL early, because retrofitting a mirrored layout late is painful.

Translation files rot fast when a team grows, so a little structure pays off. The goal is that any developer can add a string, any translator can find it, and no key ever ships empty. A few habits keep it clean across both Flutter and React Native projects.

• Keep one source-of-truth locale, usually English, and treat every other file as a translation of it.
• Split strings into namespaces or feature files so a checkout screen does not live in the same 4,000-line file as onboarding.
• Add a description or comment to each key so translators know the context, since 'Open' can be a verb or an adjective.
• Run a lint step in CI that fails the build when a locale is missing a key that exists in the source file.
• Never let developers write final copy inline. Add the key first, then fill translations, so nothing bypasses the pipeline.

Once the app itself speaks several languages, the store page has to as well, and this is where a lot of installs are won or lost. Both the Apple App Store and Google Play let you add a localization per language, each with its own title, subtitle or short description, full description, keyword field, and its own set of screenshots. A visitor browsing the store in French sees your French listing, and if you have not created one, they see your default language instead. That mismatch quietly kills conversion, because someone who cannot read your screenshots rarely installs. Localizing the listing means three things: translating the metadata, adapting the keywords for how people actually search in that language, and localizing the screenshots so the captions and the on-device text match. You do not need to localize every market at once, but each market you enter should get all three.

The metadata and the visuals are separate jobs. For the words, our guide on how to generate app store metadata covers writing titles, subtitles, and descriptions that fit each store's character limits. For the images, creating app store visuals easily walks through building localized screenshot sets without a designer for every language. Treat the two as a pair, because a translated description above English screenshots looks unfinished and reviewers notice.

You should not localize into every language at once, because each one adds ongoing maintenance for translations, screenshots, and support. Prioritize by weighing two forces against each other: market size and competition. Market size is how many potential users and how much revenue a language unlocks, where English, Spanish, Portuguese for Brazil, Japanese, German, French, and Simplified Chinese cover a large share of global app spend. Competition is how hard it is to rank in that language's store, and a smaller market with weak localized competitors can convert better than a huge market that is already saturated. Look at where you already get organic downloads with an English listing, because those countries are telling you demand exists before you have spent a cent on translation.

• Start with the languages already appearing in your install analytics, since demand is proven.
• Add high-spend markets where your category is not already dominated by localized incumbents.
• Prefer languages that unlock several countries at once, such as Spanish or Arabic, for leverage.
• Deprioritize a language if you cannot support its users, because installs you cannot serve churn fast.

A localized listing helps twice, once in the algorithm and once with the human. On ranking, both stores index your localized keyword fields, so a French keyword set makes you discoverable for French search terms you would never rank for with an English listing. Machine-translating your English keywords misses this entirely, because the words people type in French are rarely the literal translation of the English ones. On conversion, a visitor who reads your title, description, and screenshots in their own language trusts the app more and installs at a higher rate than one squinting at a foreign listing. This is why real per-language ASO beats a single machine translation: you research the actual search terms for each language, then write the metadata around them. The result compounds, because a higher install rate also feeds back into ranking. For the mechanics of ASO per store, see our guide on how to improve ASO in App Store Connect, and for turning that traffic into installs, improving store listing conversion.

Machine translation is a fine starting draft but a poor finished listing. It handles the descriptive sentences acceptably, yet it fails on the two things that matter most for the store: keywords and tone. Search terms rarely match the literal translation, and machine copy often sounds slightly off to a native speaker, which erodes trust. Use it for a first pass, then have a native speaker adjust the keywords and polish the phrasing before you publish.

Yes, and strongly. Each localization you add gives the store a new keyword field to index, so you become discoverable for search terms in that language that your default listing could never rank for. On the App Store, localizations even let you target additional keyword sets that can help in nearby markets. Adding a language is one of the highest-leverage ASO moves available, provided you research the keywords rather than translating them literally.

Most new apps should launch with one to three languages, not ten. Start with your primary market and any language that already appears in your early install data, then expand as you confirm demand and can support the users. Localizing too many languages at launch spreads your screenshots, metadata, and customer support too thin, and half-maintained localizations look worse than a clean single-language listing. Grow the list deliberately, one market at a time.

Localize both, because screenshots drive more of the install decision than the description does. A visitor skims the images first, so captions in their language and localized on-device text make the app feel built for them. Leaving English screenshots under a translated description is the most common half-done localization, and it visibly lowers conversion. If you can only localize one element well, make it the screenshots, then translate the metadata around them.