React Native Internationalisierung mit i18next: mehrsprachige Apps

1. Warum Internationalisierung mehr ist als Textdateien

Internationalisierung wird oft missverstanden als reines Auslagern von Texten in Übersetzungsdateien. Tatsächlich beginnt sie bei der Architekturentscheidung, dass kein sichtbarer String jemals direkt im Komponentencode steht, sondern immer über einen Übersetzungsschlüssel referenziert wird. i18next stellt dafür die Infrastruktur bereit, aber die Disziplin, konsequent keine hartcodierten Strings zu schreiben, liegt beim Entwicklungsteam.

Der Unterschied zwischen Lokalisierung und Internationalisierung mit i18next ist wichtig: Internationalisierung ist die technische Vorbereitung, Lokalisierung die konkrete Übersetzung für einen Markt. Eine App kann vollständig internationalisiert, aber noch nicht in eine Zielsprache lokalisiert sein. Wer beides vermischt, unterschätzt meist den Aufwand für Pluralregeln, Textrichtung und kulturelle Formatierung.

In React Native kommt hinzu, dass Layouts, die für westliche Sprachen gebaut wurden, bei rechts-nach-links-Sprachen wie Arabisch oder Hebräisch oft brechen. Eine solide Internationalisierung mit i18next plant diese Fälle von Anfang an ein, statt sie erst beim ersten arabischsprachigen Markteintritt als Krise zu entdecken.

2. i18next und react-i18next einrichten

Die Grundinstallation besteht aus i18next als sprachagnostischer Übersetzungs-Engine und react-i18next als React-Bindungsschicht mit Hooks wie useTranslation(). Die Initialisierung erfolgt einmalig, meist in einer eigenen i18n.ts-Datei, die vor dem Rendern der Root-Komponente importiert wird, damit Übersetzungen sofort verfügbar sind.

Zentrale Konfigurationswerte sind fallbackLng für den Fall einer nicht unterstützten Sprache, interpolation.escapeValue: false, weil React bereits selbst gegen XSS escaped, und compatibilityJSON: 'v4' für korrekte Pluralregeln in neueren i18next-Versionen. Diese Basiskonfiguration bildet das Fundament jeder React Native Internationalisierung mit 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 und Ressourcen-Organisation

Eine einzige riesige Übersetzungsdatei pro Sprache wird schnell unübersichtlich und verlangsamt das Bundle, weil sie beim App-Start immer vollständig geladen wird. Namespaces gruppieren Übersetzungen nach Feature-Bereich, etwa common, checkout und profile, und ermöglichen, dass nur benötigte Namespaces geladen werden.

Innerhalb eines Namespace sorgt verschachtelte JSON-Struktur für zusätzliche Klarheit, etwa checkout.errors.paymentFailed statt eines flachen Schlüssels wie checkout_error_payment_failed_v2. Diese Struktur macht die Internationalisierung mit i18next auch bei hunderten Übersetzungsschlüsseln navigierbar und verständlich für Übersetzer ohne Entwicklungshintergrund.

{
  "common": {
    "save": "Speichern",
    "cancel": "Abbrechen"
  },
  "checkout": {
    "title": "Kasse",
    "itemCount_one": "{{count}} Artikel im Warenkorb",
    "itemCount_other": "{{count}} Artikel im Warenkorb",
    "errors": {
      "paymentFailed": "Zahlung fehlgeschlagen, bitte erneut versuchen"
    }
  }
}

4. Gerätespracherkennung mit expo-localization

expo-localization beziehungsweise react-native-localize in Bare-React-Native-Projekten liest die auf dem Gerät konfigurierte Spracheinstellung aus, noch bevor der Nutzer explizit eine Sprache in der App wählt. Diese Erkennung sollte als initialer Standardwert dienen, nicht als endgültige, unveränderliche Entscheidung, denn Nutzer möchten oft eine andere Sprache als die Systemsprache verwenden.

Ein robustes Muster für Internationalisierung mit i18next speichert die vom Nutzer explizit gewählte Sprache separat von der erkannten Gerätesprache, etwa in AsyncStorage, und priorisiert diese explizite Wahl bei jedem App-Start über die automatische Erkennung.

#!/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. Pluralisierung und Interpolation

Pluralregeln unterscheiden sich massiv zwischen Sprachen: Englisch kennt nur Singular und Plural, Polnisch mehrere Plural-Kategorien, Arabisch bis zu sechs. i18next löst dieses Problem über die CLDR-Pluralregeln automatisch, solange Übersetzungsschlüssel korrekt mit Suffixen wie _one und _other versehen sind, wie im Beispiel oben gezeigt.

Interpolation fügt dynamische Werte in Übersetzungen ein, etwa einen Nutzernamen oder eine Zahl, über die {{variable}}-Syntax. Wichtig für die Wartbarkeit: Variablennamen in Übersetzungsschlüsseln sollten sprachunabhängig und stabil bleiben, damit Übersetzer sie nicht versehentlich umbenennen und die Interpolation dadurch bricht.

// 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 von Übersetzungs-Namespaces

Für Apps mit vielen Features und entsprechend vielen Übersetzungs-Namespaces lohnt sich Lazy-Loading: Statt alle Namespaces beim App-Start zu laden, wird ein Namespace erst dann nachgeladen, wenn der zugehörige Screen tatsächlich geöffnet wird. Das reduziert die initiale Bundle-Größe und die Zeit bis zur ersten Interaktion.

In der Praxis wird dieses Muster seltener genutzt als in Web-Anwendungen, weil React Native Apps ohnehin ihr komplettes JavaScript-Bundle beim Start laden. Trotzdem lohnt sich getrenntes Laden von Namespaces bei sehr umfangreichen Internationalisierung mit i18next-Setups mit mehreren Dutzend Sprachen, um Speicherverbrauch zur Laufzeit zu reduzieren.

7. RTL-Layouts mit I18nManager

Sprachen wie Arabisch, Hebräisch und Urdu werden von rechts nach links gelesen, was bedeutet, dass nicht nur Text, sondern auch das gesamte Layout gespiegelt werden muss: Icons, Navigationsrichtung, Padding und Margin. React Natives I18nManager.forceRTL() steuert diese Spiegelung global, erfordert aber in den meisten Fällen einen App-Neustart, um konsistent zu greifen.

Der wichtigste praktische Hinweis: Flexbox-Eigenschaften wie marginLeft und marginRight sollten durch logische Eigenschaften wie marginStart und marginEnd ersetzt werden, damit sie sich bei aktiviertem RTL automatisch korrekt verhalten, statt manuell für jede Richtung Bedingungen zu schreiben. Eine gründliche Internationalisierung mit i18next testet RTL-Layouts von Beginn an, nicht erst kurz vor dem Release in einem arabischsprachigen Markt.

// 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. Datum, Zahlen und CI-Checks gegen fehlende Keys

Datum, Uhrzeit und Zahlenformate unterscheiden sich kulturell erheblich, von der Reihenfolge der Datumskomponenten bis zum Dezimaltrennzeichen. Die eingebaute Intl-API, verfügbar über Hermes in modernen React Native Versionen, formatiert diese Werte konsistent mit der aktiven Sprache, ohne dass eigene Formatierungslogik geschrieben werden muss.

Fehlende Übersetzungsschlüssel fallen oft erst spät auf, wenn ein Nutzer plötzlich einen englischen Fallback-Text in der deutschen App sieht. Ein CI-Schritt mit i18next-parser extrahiert alle im Code verwendeten t()-Aufrufe und vergleicht sie automatisch gegen die vorhandenen Übersetzungsdateien, sodass fehlende Keys den Build fehlschlagen lassen, bevor sie in Produktion gelangen.

9. i18next im Vergleich zu react-intl und LinguiJS

i18next ist nicht die einzige Option für Internationalisierung in React Native. Die Wahl hängt von bestehenden Konventionen im Team und den Anforderungen an Pluralisierung und Tooling ab.

react-intl punktet mit ICU-Message-Syntax und starker Verbreitung im Web-Ökosystem, bringt aber weniger native Namespace-Unterstützung mit. LinguiJS überzeugt durch kompilierte, kleine Bundles, hat aber ein kleineres Ökosystem. Für die meisten React Native Projekte bleibt i18next wegen seiner Reife, Plugin-Vielfalt und nativen Namespace-Unterstützung die pragmatischste Wahl für Internationalisierung.

10. Zusammenfassung

Internationalisierung mit i18next in React Native beginnt mit der Disziplin, niemals sichtbaren Text hartcodiert im Komponentencode zu schreiben. Namespaces organisieren Übersetzungen nach Feature-Bereich, expo-localization erkennt die Gerätesprache als sinnvollen Startwert, und CLDR-basierte Pluralregeln decken auch komplexe Sprachen wie Polnisch oder Arabisch korrekt ab.

RTL-Layouts mit I18nManager und logischen Flexbox-Eigenschaften verhindern gebrochene Oberflächen in rechts-nach-links-Sprachen, während ein CI-Check mit i18next-parser fehlende Übersetzungsschlüssel abfängt, bevor sie in Produktion sichtbar werden. Wer diese Bausteine von Anfang an einplant, erschließt neue Sprachmärkte ohne größere Nacharbeiten an der Architektur.

11. FAQ: React Native Internationalisierung mit i18next