Localizing a React Native app looks like localizing a React web app until you hit the parts that are only on mobile: translations have to ship inside the app, the language comes from the phone's settings, right-to-left needs a restart, and the app name and permission prompts live in native files that t() never sees. This guide sets up i18n in an Expo app with i18next step by step, then covers each of those mobile-only problems.
Install i18next, react-i18next and expo-localization. Put one JSON file per language in src/locales/ and bundle them with the app. Initialize i18next once, before the first screen renders, with the device's preferred language that you have translations for. Use useTranslation() in components, plural keys for counts, Intl for numbers and dates, I18nManager plus a reload for right-to-left languages, and Expo's locales config for the app name and permission prompts.
/locales/de.json on demand. A mobile app should work offline and on first launch, so the JSON files ship inside the app bundle./de/pricing and no Accept-Language header. The phone's language list decides, and users can change it while your app is in the background.strings.xml are not JavaScript, so your i18n library can't reach them.npx expo install expo-localization
npm install i18next react-i18next
npx expo install picks the expo-localization version that matches your Expo SDK. In a bare React Native app without Expo, use react-native-localize instead (and run pod install); the rest of this guide stays the same.
One JSON file per language, with identical keys:
// src/locales/en.json
{
"home": {
"welcome": "Welcome back, {{name}}",
"signedInAs": "Signed in as <bold>{{name}}</bold>"
},
"cart": {
"items_one": "{{count}} item",
"items_other": "{{count}} items",
"removeTitle": "Remove item?",
"removeMessage": "{{name}} will be removed from your cart."
},
"common": {
"cancel": "Cancel",
"remove": "Remove"
},
"settings": {
"title": "Settings",
"language": "Language"
}
}
i18next uses {{name}} for variables and a key suffix per plural form: _one and _other in English. The <bold> tag is for styled text inside a sentence, covered in step 5. If the format itself is new to you, JSON translation files explained walks through it, and how to translate JSON files covers producing de.json and the rest without breaking placeholders.
// src/i18n.ts
import i18n from "i18next";
import { initReactI18next } from "react-i18next";
import { getLocales } from "expo-localization";
import en from "./locales/en.json";
import de from "./locales/de.json";
import pl from "./locales/pl.json";
import ar from "./locales/ar.json";
export const resources = {
en: { translation: en },
de: { translation: de },
pl: { translation: pl },
ar: { translation: ar },
} as const;
export type Language = keyof typeof resources;
// The first language in the device's list that we have translations for:
// the full tag first (pt-BR, zh-Hant), then the language (pt), else English.
function deviceLanguage(): Language {
for (const locale of getLocales()) {
if (locale.languageTag in resources) return locale.languageTag as Language;
if (locale.languageCode && locale.languageCode in resources) return locale.languageCode as Language;
}
return "en";
}
i18n.use(initReactI18next).init({
resources,
lng: deviceLanguage(),
fallbackLng: "en",
interpolation: { escapeValue: false }, // React already escapes output
});
export default i18n;
getLocales() returns the user's languages in order of preference, so someone with "Portuguese (Brazil), English" gets Portuguese if you have it and English otherwise. Don't just take the first entry: if a user's first language is Dutch and you don't ship Dutch, their second choice is a better fallback than your default.
Importing the JSON directly bundles it, which is what you want on mobile. TypeScript projects need resolveJsonModule, which expo/tsconfig.base already enables.
i18next must be initialized before any component calls t(), or the first render shows raw keys. Import the config as the very first line of your entry point. With Expo Router, that's the root layout:
// src/app/_layout.tsx
import "../i18n";
import { Stack } from "expo-router";
export default function RootLayout() {
return <Stack />;
}
In classic Expo, import it at the top of the file main points to (usually index.ts). In bare React Native, at the top of index.js. Because the resources are bundled and passed in synchronously, there's nothing to wait for.
The basic case is text inside <Text>:
import { Text, TextInput, View } from "react-native";
import { useTranslation } from "react-i18next";
export function Home({ name }: { name: string }) {
const { t } = useTranslation();
return (
<View>
<Text>{t("home.welcome", { name })}</Text>
<TextInput placeholder={t("settings.language")} accessibilityLabel={t("settings.language")} />
</View>
);
}The places that are easy to miss in a React Native codebase:
accessibilityLabel and accessibilityHint are read aloud by VoiceOver and TalkBack. An English label in a German app is a bug for exactly the users who depend on it.title, headerTitle, tabBarLabel and drawerLabel in screen options.<Button title>: it's a prop, not a child, so a search for <Text> won't find it.import { Alert } from "react-native";
import { Stack } from "expo-router";
// Screen title, inside the component so t() is in scope
<Stack.Screen options={{ title: t("settings.title") }} />
// Alert: title, message and buttons
Alert.alert(t("cart.removeTitle"), t("cart.removeMessage", { name: item.name }), [
{ text: t("common.cancel"), style: "cancel" },
{ text: t("common.remove"), style: "destructive", onPress: () => remove(item.id) },
]);
Don't split a sentence into pieces to bold one word. "Signed in as" plus a bold name becomes three fragments that translators can't reorder, and many languages put the name first. Keep it one message and let <Trans> map the tag to a styled <Text>:
import { Text } from "react-native";
import { Trans } from "react-i18next";
<Text>
<Trans
i18nKey="home.signedInAs"
values={{ name }}
components={{ bold: <Text style={styles.bold} /> }}
/>
</Text>
The outer <Text> matters: React Native only renders strings inside a <Text>, and <Trans> doesn't add one for you.
Pass count and i18next picks the right key for the current language:
t("cart.items", { count: 1 }); // "1 item"
t("cart.items", { count: 3 }); // "3 items"
English needs two forms; other languages need more. Polish uses different words for 1, for 2 to 4 and for 5 and up, so pl.json needs four keys where English has two:
// src/locales/pl.json
{
"cart": {
"items_one": "{{count}} produkt",
"items_few": "{{count}} produkty",
"items_many": "{{count}} produktów",
"items_other": "{{count}} produktu"
}
}
i18next chooses the form with Intl.PluralRules, which Hermes provides from React Native 0.73 and Expo SDK 50. On older versions, or with JavaScriptCore, add a polyfill such as intl-pluralrules, or every count falls back to _other. For the full set of rules per language, see the ICU plurals guide.
Following the device language is the right default, but some people run their phone in English and want your app in their own language, or the reverse. Switching is one call, and remembering the choice takes two more lines:
// src/i18n.ts (after init)
import AsyncStorage from "@react-native-async-storage/async-storage";
i18n.on("languageChanged", (lng) => AsyncStorage.setItem("language", lng));
AsyncStorage.getItem("language").then((lng) => {
if (lng && lng in resources) i18n.changeLanguage(lng);
});
// In a settings screen
<Button title="Deutsch" onPress={() => i18n.changeLanguage("de")} />
Components using useTranslation() re-render with the new language straight away. Show each language in its own name ("Deutsch", not "German"), since a user who can't read the current language still needs to find theirs. iOS and Android 13+ also let users pick a language per app in system settings; your app sees that as the device language on the next launch.
Never build "$1,234.50" or "10/26/2026" by hand. Germans write 1.234,50 EUR and most of the world reads 10/26 as nonsense. Use Intl with the app's language:
import i18n from "./i18n";
const price = new Intl.NumberFormat(i18n.language, { style: "currency", currency: "EUR" }).format(1234.5);
// en: "EUR 1,234.50" de: "1.234,50 EUR "
const date = new Intl.DateTimeFormat(i18n.language, { dateStyle: "medium" }).format(new Date());
// en: "Oct 25, 2026" de: "25.10.2026"
Hermes supports Intl.NumberFormat and Intl.DateTimeFormat on both platforms in current React Native versions. The Intl API guide covers relative times, lists and units.
For Arabic, Hebrew, Persian and Urdu the whole layout should mirror: back arrows point right, rows start on the right. React Native does this through I18nManager, but the change only applies after a reload:
import { I18nManager } from "react-native";
import * as Updates from "expo-updates";
import i18n from "./i18n";
export async function applyDirection(lng: string) {
const rtl = i18n.dir(lng) === "rtl";
if (I18nManager.isRTL !== rtl) {
I18nManager.allowRTL(rtl);
I18nManager.forceRTL(rtl);
await Updates.reloadAsync();
}
}
Call it after changeLanguage and at startup. Then check your styles: marginStart and paddingEnd flip automatically, marginLeft doesn't, and icons that imply direction (arrows, progress) may need a mirrored version. The same ideas on the web are covered in RTL support with CSS logical properties.
The name under the icon and messages like "Allow access to your camera?" are native strings. In Expo, translate them with the locales config:
// app.json
{
"expo": {
"ios": {
"infoPlist": { "CFBundleAllowMixedLocalizations": true }
},
"locales": {
"de": "./languages/de.json"
}
}
}// languages/de.json
{
"ios": {
"CFBundleDisplayName": "Meine App",
"NSCameraUsageDescription": "Wir brauchen die Kamera, um Belege zu scannen."
},
"android": {
"app_name": "Meine App"
}
}These are applied at build time, so they need a new native build, not just an over-the-air update. App Store and Google Play listings (description, screenshots, keywords) are separate again and live in the store consoles.
en.json, so a missing key fails the build instead of reaching a store review.
The slow part of all this is the first pass: finding every string in <Text>, props, navigation options and alerts, inventing keys, and wiring t() in. Babelize (our product) does that pass for Expo Router, classic Expo and bare React Native apps, in beta:
npx babelize translate --to de,pl,ar
git diff
It extracts text from <Text>, placeholder, title, accessibility props, screen options and Alert.alert, keeps styled sentences as one message rendered with <Trans>, writes the locale files and an i18n.ts that bundles them and picks the device language, and imports it at the top of your entry point. Reruns translate only new or changed strings.
What it doesn't do: switch the layout direction for RTL languages, or translate native strings (the app name, permission prompts, strings.xml), so the RTL and locales steps above are still yours. Because React Native support is in beta, review the diff before merging. The React Native docs list exactly what it changes.
<Button title>, not only <Text>.<Trans>.Intl.PluralRules exists.Intl and the app's language.I18nManager and a reload, and use start/end styles.locales config.