React Native Internationalization with i18next: Multilingual Apps

1. Why internationalization is more than text files

Internationalization is often misunderstood as simply moving text into translation files. In reality, it starts with an architectural decision: no visible string ever lives directly in component code, it's always referenced through a translation key. i18next provides the infrastructure for this, but the discipline of consistently avoiding hardcoded strings lies with the development team.

The distinction between localization and internationalization with i18next matters: internationalization is the technical preparation, localization is the actual translation for a market. An app can be fully internationalized but not yet localized into a target language. Teams that conflate the two usually underestimate the effort required for plural rules, text direction, and cultural formatting.

In React Native, there's an added wrinkle: layouts built for Western languages often break under right-to-left languages such as Arabic or Hebrew. Solid internationalization with i18next plans for these cases from the start, rather than discovering them as a crisis right before the first Arabic-speaking market launch.

2. Setting up i18next and react-i18next

The base setup consists of i18next as the language-agnostic translation engine and react-i18next as the React binding layer with hooks like useTranslation(). Initialization happens once, usually in a dedicated i18n.ts file imported before the root component renders, so translations are immediately available.

Key configuration values are fallbackLng for the case of an unsupported language, interpolation.escapeValue: false, because React already escapes against XSS on its own, and compatibilityJSON: 'v4' for correct plural rules in newer i18next versions. This base configuration forms the foundation of any React Native internationalization with i18next.

// i18n/index.ts — initialize i18next with react-i18next bindings
import i18n from 'i18next';
import { initReactI18next } from 'react-i18next';
import * as Localization from 'expo-localization';
import en from './locales/en.json';
import de from './locales/de.json';

i18n.use(initReactI18next).init({
  resources: { en: { translation: en }, de: { translation: de } },
  lng: Localization.getLocales()[0]?.languageCode ?? 'en',
  fallbackLng: 'en',
  compatibilityJSON: 'v4',
  interpolation: { escapeValue: false }, // React already escapes by default
});

export default i18n;

3. Namespaces and resource organization

A single giant translation file per language quickly becomes unwieldy and slows down the bundle, because it's always loaded in full at app start. Namespaces group translations by feature area, such as common, checkout, and profile, and let you load only the namespaces that are actually needed.

Within a namespace, nested JSON structure adds further clarity, for example checkout.errors.paymentFailed instead of a flat key like checkout_error_payment_failed_v2. This structure keeps internationalization with i18next navigable even at hundreds of translation keys, and understandable to translators without a development background.

{
  "common": {
    "save": "Save",
    "cancel": "Cancel"
  },
  "checkout": {
    "title": "Checkout",
    "itemCount_one": "{{count}} item in cart",
    "itemCount_other": "{{count}} items in cart",
    "errors": {
      "paymentFailed": "Payment failed, please try again"
    }
  }
}

4. Device locale detection with expo-localization

expo-localization, or react-native-localize in bare React Native projects, reads the language setting configured on the device before the user explicitly picks a language in the app. This detection should serve as an initial default, not a final, unchangeable decision, since users often want a different language than their system language.

A robust pattern for internationalization with i18next stores the user's explicitly chosen language separately from the detected device language, for example in AsyncStorage, and prioritizes that explicit choice over automatic detection on every app start.

#!/usr/bin/env bash
# Install i18next, react-i18next, and Expo's localization module
npx expo install expo-localization
npm install i18next react-i18next

echo "i18next stack installed, ready for i18n/index.ts initialization"

5. Pluralization and interpolation

Plural rules differ massively between languages: English has only singular and plural, Polish has several plural categories, Arabic has up to six. i18next resolves this automatically via CLDR plural rules, as long as translation keys are correctly suffixed with _one and _other, as shown in the example above.

Interpolation inserts dynamic values into translations, such as a username or a number, via the {{variable}} syntax. Important for maintainability: variable names inside translation strings should stay stable and language-independent, so translators don't accidentally rename them and break the interpolation.

// CartScreen.tsx — useTranslation hook with pluralization and interpolation
import { useTranslation } from 'react-i18next';

function CartSummary({ itemCount, userName }: { itemCount: number; userName: string }) {
  const { t } = useTranslation();

  return (
    <Text>
      {t('checkout.itemCount', { count: itemCount })}
      {t('checkout.greeting', { name: userName })}
    </Text>
  );
}

6. Lazy-loading translation namespaces

For apps with many features and correspondingly many translation namespaces, lazy-loading pays off: instead of loading every namespace at app start, a namespace is only loaded once the corresponding screen is actually opened. This reduces the initial bundle size and time to first interaction.

In practice, this pattern is used less often than in web applications, since React Native apps load their entire JavaScript bundle at start anyway. Still, separately loading namespaces is worthwhile for very extensive internationalization with i18next setups with dozens of languages, in order to reduce runtime memory usage.

7. RTL layouts with I18nManager

Languages such as Arabic, Hebrew, and Urdu are read right to left, which means not just text but the entire layout needs to be mirrored: icons, navigation direction, padding, and margin. React Native's I18nManager.forceRTL() controls this mirroring globally, but in most cases requires an app restart to take effect consistently.

The most important practical tip: flexbox properties like marginLeft and marginRight should be replaced with logical properties like marginStart and marginEnd, so they automatically behave correctly under RTL instead of requiring manual conditionals for each direction. Thorough internationalization with i18next tests RTL layouts from the start, not shortly before releasing into an Arabic-speaking market.

// android/app/src/main/AndroidManifest.xml
// android:supportsRtl="true" must be set on the application tag,
// otherwise Android ignores I18nManager.forceRTL() at the native layer
// and layouts stay left-to-right regardless of the JS-side setting.

// ios/Info.plist — CFBundleLocalizations lists all supported languages
// for App Store metadata and the iOS system language picker:
//   <key>CFBundleLocalizations</key>
//   <array><string>en</string><string>de</string><string>ar</string></array>
//
// CFBundleDevelopmentRegion sets the base development locale, typically "en".

8. Dates, numbers, and CI checks against missing keys

Date, time, and number formats differ significantly across cultures, from the order of date components to the decimal separator. The built-in Intl API, available via Hermes in modern React Native versions, formats these values consistently with the active language, without requiring custom formatting logic.

Missing translation keys often only surface late, when a user suddenly sees an English fallback text inside a German app. A CI step using i18next-parser extracts every t() call used in the code and automatically compares it against the existing translation files, so missing keys fail the build before they reach production.

9. i18next compared to react-intl and LinguiJS

i18next is not the only option for internationalization in React Native. The choice depends on existing conventions on the team and the requirements around pluralization and tooling.

react-intl scores with ICU message syntax and strong adoption in the web ecosystem, but ships with less native namespace support. LinguiJS wins on compiled, small bundles, but has a smaller ecosystem. For most React Native projects, i18next remains the most pragmatic choice for internationalization thanks to its maturity, plugin variety, and native namespace support.

10. Summary

Internationalization with i18next in React Native starts with the discipline of never writing visible text hardcoded into component code. Namespaces organize translations by feature area, expo-localization detects the device language as a sensible starting value, and CLDR-based plural rules correctly cover even complex languages like Polish or Arabic.

RTL layouts with I18nManager and logical flexbox properties prevent broken UIs in right-to-left languages, while a CI check with i18next-parser catches missing translation keys before they become visible in production. Teams that plan for these building blocks from the start can expand into new language markets without major architectural rework.

11. FAQ: React Native Internationalization with i18next