React i18n: Der vollständige Leitfaden zur React-Internationalisierung im Jahr 2024

React i18n: Der vollständige Leitfaden zur React-Internationalisierung im Jahr 2024

Eine React-App zu entwickeln, die für Nutzer auf der ganzen Welt funktioniert, ist längst kein optionales Feature mehr – sie ist eine wettbewerbsentscheidende Anforderung. Ob Sie in neue Märkte in Europa, Lateinamerika oder Asien vordringen wollen: React-Internationalisierung (allgemein als React i18n abgekürzt) bildet die Grundlage, die das erst möglich macht.

Dieser Leitfaden deckt alles ab: von dem, was React i18n eigentlich bedeutet, über die traditionelle Einrichtung, den Vergleich der beliebtesten React-Lokalisierungsbibliotheken, bis hin dazu, wie moderne Plattformen wie better-i18n den Entwickler-Engpass vollständig beseitigen.

Inhaltsverzeichnis

1. Was ist React i18n?
2. Warum React-Lokalisierung wichtig ist
3. Kernkonzepte: i18n vs. l10n vs. g11n
4. React i18n auf die traditionelle Weise einrichten
5. Beliebte React-i18n-Bibliotheken im Vergleich
6. react-i18next: Deep Dive
7. react-intl: Deep Dive
8. Die versteckten Kosten der traditionellen React-Lokalisierung
9. Wie better-i18n die React-Internationalisierung vereinfacht
10. Codebeispiele: Traditionell vs. better-i18n
11. Best Practices für React i18n
12. Häufig gestellte Fragen

Was ist React i18n? {#what-is-react-i18n}

React i18n bezeichnet den Prozess, React-Anwendungen so zu gestalten und zu entwickeln, dass sie mehrere Sprachen und regionale Einstellungen unterstützen. Der Begriff „i18n" ist eine Kurzform für „internationalization" – zwischen dem „i" und dem „n" im englischen Wort befinden sich 18 Buchstaben.

Internationalisierung ist weit mehr als nur Übersetzung. Sie umfasst:

• Textübersetzung – UI-Zeichenketten in der Sprache des Nutzers anzeigen
• Datums- und Zeitformatierung – verschiedene Regionen formatieren Datumsangaben unterschiedlich (MM/DD/YYYY vs. DD/MM/YYYY)
• Zahlen- und Währungsformatierung – Komma vs. Punkt als Dezimaltrennzeichen, Währungssymbole
• Pluralregeln – Sprachen wie Russisch oder Arabisch haben komplexe Pluralformen
• Rechts-nach-links-Unterstützung (RTL) – Arabisch, Hebräisch und andere Sprachen werden von rechts nach links gelesen
• Gebietsschema-bewusstes Sortieren – die alphabetische Reihenfolge unterscheidet sich je nach Gebietsschema

Im React-Ökosystem wird i18n entweder über dedizierte Bibliotheken wie react-i18next und react-intl, über eigene Implementierungen oder zunehmend über Content-Plattformen wie better-i18n abgewickelt, die den gesamten Workflow übernehmen, ohne Ihren Code zu berühren.

Warum React-Lokalisierung wichtig ist {#why-react-localization-matters}

Die geschäftlichen Argumente für React-Lokalisierung liegen auf der Hand:

• 72,4 % der Verbraucher verbringen den Großteil oder die gesamte Zeit auf Websites in ihrer eigenen Sprache (CSA Research)
• 56,2 % der Verbraucher geben an, dass die Möglichkeit, Informationen in der eigenen Sprache zu erhalten, wichtiger ist als der Preis
• Apps, die in 5+ Sprachen lokalisiert wurden, generieren bis zu 3-mal mehr Umsatz als rein englischsprachige Apps
• Google und andere Suchmaschinen ranken lokalisierte Inhalte für nicht-englische Suchanfragen höher – React-JS-Lokalisierung wirkt sich also direkt auf die SEO aus

Für SaaS-Produkte, E-Commerce-Shops und auf React basierende Content-Plattformen bedeutet das Auslassen der Lokalisierung, erhebliche Umsatzpotenziale zu verschenken. React-JS-Lokalisierung ist eine Investition, die sich mit der Zeit auszahlt.

Kernkonzepte: i18n vs. l10n vs. g11n {#core-concepts}

Bevor wir in die Implementierung einsteigen, ist es hilfreich, drei verwandte Begriffe zu verstehen:

In der React-Entwicklung gilt:

• i18n ist das, was Sie im Code tun – die Infrastruktur aufsetzen
• l10n ist das, was Übersetzer tun – den tatsächlich übersetzten Inhalt verfassen
• Das Ziel ist, diese beiden Aufgaben so weit wie möglich voneinander zu trennen

Die meisten React-i18n-Probleme entstehen dadurch, dass diese Bereiche vermischt werden: Entwickler verwalten am Ende Übersetzungsdateien, koordinieren sich mit Übersetzern über JSON-Dateien und müssen bei jeder UI-Änderung manuell neue Schlüssel extrahieren. Moderne Plattformen wie better-i18n existieren genau dafür, diese Reibung vollständig zu beseitigen.

React i18n auf die traditionelle Weise einrichten {#traditional-setup}

Um zu verstehen, warum es bessere Ansätze gibt, lohnt es sich, das traditionelle React-JS-i18n-Setup durchzugehen. Die meisten klassischen Ansätze folgen demselben Muster:

Schritt 1: Eine Bibliothek installieren

npm install react-i18next i18next i18next-browser-languagedetector

Schritt 2: JSON-Übersetzungsdateien erstellen

Sie erstellen eine Ordnerstruktur wie diese:

src/
  locales/
    en/
      translation.json
    fr/
      translation.json
    de/
      translation.json

Jede JSON-Datei enthält Schlüssel-Wert-Paare:

// src/locales/en/translation.json
{
  "welcome": "Welcome to our app",
  "nav": {
    "home": "Home",
    "about": "About",
    "pricing": "Pricing"
  },
  "cta": {
    "signup": "Sign up for free",
    "login": "Log in"
  }
}

// src/locales/fr/translation.json
{
  "welcome": "Bienvenue dans notre application",
  "nav": {
    "home": "Accueil",
    "about": "À propos",
    "pricing": "Tarifs"
  },
  "cta": {
    "signup": "S'inscrire gratuitement",
    "login": "Se connecter"
  }
}

Schritt 3: i18next konfigurieren

// src/i18n.js
import i18n from 'i18next';
import { initReactI18next } from 'react-i18next';
import LanguageDetector from 'i18next-browser-languagedetector';

import enTranslation from './locales/en/translation.json';
import frTranslation from './locales/fr/translation.json';
import deTranslation from './locales/de/translation.json';

i18n
  .use(LanguageDetector)
  .use(initReactI18next)
  .init({
    resources: {
      en: { translation: enTranslation },
      fr: { translation: frTranslation },
      de: { translation: deTranslation },
    },
    fallbackLng: 'en',
    debug: process.env.NODE_ENV === 'development',
    interpolation: {
      escapeValue: false,
    },
  });

export default i18n;

Schritt 4: Die App einbetten

// src/index.js
import React from 'react';
import ReactDOM from 'react-dom/client';
import './i18n';
import App from './App';

const root = ReactDOM.createRoot(document.getElementById('root'));
root.render(<App />);

Schritt 5: Übersetzungen in Komponenten verwenden

// src/components/HeroSection.jsx
import { useTranslation } from 'react-i18next';

function HeroSection() {
  const { t } = useTranslation();

  return (
    <section>
      <h1>{t('welcome')}</h1>
      <a href="/signup">{t('cta.signup')}</a>
    </section>
  );
}

export default HeroSection;

Dieses Setup funktioniert – verursacht jedoch erhebliche laufende Kosten, sobald Ihre App wächst.

Beliebte React-i18n-Bibliotheken im Vergleich {#libraries-compared}

Es gibt mehrere ausgereifte Bibliotheken für die React-Lokalisierung. Hier ist eine Übersicht der am häufigsten genutzten Optionen.

react-i18next

GitHub-Sterne: 9.000+ | Wöchentliche Downloads: 4 Mio.+

Die beliebteste React-i18n-Bibliothek. Aufgebaut auf i18next, bietet sie Hooks (useTranslation), Higher-Order-Komponenten und eine Trans-Komponente für komplexe Übersetzungen.

Vorteile:

• Riesiges Ökosystem und Community
• Flexible Backend-Plugins (Übersetzungen aus Dateien, APIs, CDNs laden)
• Unterstützt Namespaces zur Aufteilung von Übersetzungen nach Feature
• Gute TypeScript-Unterstützung
• Lazy Loading von Übersetzungs-Namespaces

Nachteile:

• Ausführliche Erstkonfiguration
• Manuelle Verwaltung von JSON-Übersetzungsdateien erforderlich
• Schlüsselextraktion muss separat erfolgen (z. B. mit i18next-parser)
• Übersetzer müssen mit JSON-Dateien arbeiten, was nicht übersetzerfreundlich ist
• Keine integrierte Übersetzungsverwaltungs-UI

react-intl (FormatJS)

GitHub-Sterne: 14.000+ | Wöchentliche Downloads: 2,5 Mio.+

Als Teil der FormatJS-Suite wird react-intl von Yahoo/Formatjs gepflegt und folgt dem ICU-Message-Format-Standard.

Vorteile:

• Branchenstandard-ICU-Message-Format
• Ausgezeichnete Plural- und Genus-Behandlung
• Integrierte Datums-, Zeit- und Zahlenformatierung
• Geeignet für große Enterprise-Anwendungen
• Starke TypeScript-Typen

Nachteile:

• Steilere Lernkurve als react-i18next
• Ausführlichere API (alles in <FormattedMessage> einwickeln)
• ICU-Syntax kann für Übersetzer komplex sein
• Übersetzungsdateien müssen nach wie vor manuell verwaltet werden
• Keine integrierte Übersetzungsverwaltung

Lingui

GitHub-Sterne: 4.000+ | Wöchentliche Downloads: 300.000+

Eine neuere Bibliothek mit Fokus auf Developer Experience, die Makros zur automatischen Nachrichtenextraktion nutzt.

Vorteile:

• Automatische Nachrichtenextraktion via Makros
• Sauberere Komponentensyntax
• ICU-Message-Format-Unterstützung
• TypeScript-first

Nachteile:

• Kleinere Community
• Erfordert Babel- oder SWC-Makros
• Benötigt weiterhin externe Übersetzungsverwaltung

next-intl

GitHub-Sterne: 8.000+ | Wöchentliche Downloads: 1,2 Mio.+

Speziell für Next.js entwickelt, mit App-Router-Unterstützung, Server-Komponenten und integrierter Typsicherheit.

Vorteile:

• Erstklassige Next.js-App-Router-Unterstützung
• Server-Side-Rendering-freundlich
• Hervorragende TypeScript-Erfahrung
• Typsichere Übersetzungsschlüssel

Nachteile:

• An Next.js gebunden
• Benötigt weiterhin JSON-Übersetzungsdateien
• Übersetzer benötigen weiterhin Entwicklerbeteiligung

Vergleichstabelle

react-i18next: Deep Dive {#react-i18next}

Da react-i18next die dominierende Bibliothek für React-JS-i18n ist, verdient sie einen näheren Blick auf die reale Nutzung.

Namespaces

Für größere Apps hält die Aufteilung von Übersetzungen in Namespaces die Dateien überschaubar:

// Verwendung mit Namespace
const { t } = useTranslation('checkout');

// In der Übersetzungsdatei: locales/en/checkout.json
{
  "summary": "Order Summary",
  "total": "Total: {{amount}}",
  "confirm": "Confirm Order"
}

Interpolation

Dynamische Werte in übersetzte Zeichenketten einfügen:

// Übersetzungsschlüssel: "greeting": "Hello, {{name}}!"
t('greeting', { name: 'Alice' });
// Ausgabe: "Hello, Alice!"

Pluralformen

// Übersetzungsschlüssel:
// "item_one": "{{count}} item"
// "item_other": "{{count}} items"
t('item', { count: 5 });
// Ausgabe: "5 items"

Die Trans-Komponente

Für Zeichenketten, die React-Elemente enthalten (Links, Fettschrift):

import { Trans } from 'react-i18next';

// Übersetzungsschlüssel: "termsText": "I agree to the <1>Terms of Service</1>"
<Trans i18nKey="termsText">
  I agree to the <a href="/terms">Terms of Service</a>
</Trans>

Das Problem der Schlüsselextraktion

Jedes Mal, wenn ein Entwickler neuen UI-Text hinzufügt, muss er:

1. Einen Schlüssel zur Quell-JSON-Datei hinzufügen
2. Den Schlüssel-Extraktor ausführen: npx i18next-parser
3. Die aktualisierte JSON-Datei an Übersetzer senden
4. Auf Übersetzungen warten
5. Übersetzungen zurück in die JSON-Dateien importieren
6. Committen und deployen

Dieser Workflow schafft einen Entwickler-Engpass, der jedes Content-Update verlangsamt und Entwickler zwingt, Vermittler zwischen Produkt-Managern und Übersetzern zu sein.

react-intl: Deep Dive {#react-intl}

React-intl verfolgt einen anderen philosophischen Ansatz: Nachrichten werden inline in der Komponente definiert, nicht in separaten JSON-Dateien. Der defineMessages-Helfer dient dazu, Nachrichten zu deklarieren, die extrahiert werden können.

import { useIntl, defineMessages } from 'react-intl';

const messages = defineMessages({
  greeting: {
    id: 'app.greeting',
    defaultMessage: 'Hello, {name}!',
    description: 'Greeting shown on the home page',
  },
});

function Greeting({ name }) {
  const intl = useIntl();
  return <p>{intl.formatMessage(messages.greeting, { name })}</p>;
}

ICU-Message-Format

React-intl verwendet das ICU-Message-Format für komplexe Pluralisierung und Genus:

// Komplexer Plural mit ICU
const message = `{count, plural,
  =0 {No items in cart}
  one {# item in cart}
  other {# items in cart}
}`;

Das ist leistungsstark, fügt aber eine Komplexität hinzu, mit der Übersetzer oft zu kämpfen haben – sie müssen die ICU-Syntax verstehen, um korrekt übersetzen zu können.

Provider-Einrichtung

import { IntlProvider } from 'react-intl';
import enMessages from './locales/en.json';
import frMessages from './locales/fr.json';

function App() {
  const locale = navigator.language.split('-')[0];
  const messages = locale === 'fr' ? frMessages : enMessages;

  return (
    <IntlProvider locale={locale} messages={messages}>
      <MainApp />
    </IntlProvider>
  );
}

Die versteckten Kosten der traditionellen React-Lokalisierung {#hidden-costs}

Traditionelle React-i18n-Bibliotheken sind gut durchdacht, aber der Betriebsaufwand, den sie verursachen, wird häufig unterschätzt.

1. Entwickler-Engpass

Jede Inhaltsänderung erfordert einen Entwickler. Ein Marketer, der einen CTA von „Start free trial" in „Try for free" ändern möchte, muss ein Ticket eröffnen, warten, bis ein Entwickler den JSON-Schlüssel aktualisiert, einen PR einreichen und deployen. Dieser Engpass verlangsamt die gesamte Organisation.

2. JSON-Dateiverwaltung im großen Maßstab

Eine ausgereifte React-App kann Tausende von Übersetzungsschlüsseln über Dutzende von Namespaces hinweg haben. Die Verwaltung von 5 Sprachen bedeutet, 5-mal so viele Dateien zu pflegen. Merge-Konflikte in JSON-Übersetzungsdateien sind schmerzhaft und fehleranfällig.

3. Schlüsseldrift und verwaiste Schlüssel

Mit der Zeit werden Schlüssel hinzugefügt, umbenannt und gelöscht. Ohne strikte Werkzeuge entstehen verwaiste Schlüssel (Schlüssel in JSON, die in der UI nicht mehr verwendet werden) und fehlende Schlüssel (UI-Zeichenketten, die nie in JSON aufgenommen wurden). Tools wie i18next-parser helfen, müssen aber in CI/CD integriert werden.

4. Übersetzer-Reibung

Übersetzer sind professionelle Sprachwissenschaftler, keine Entwickler. Sie mit JSON-Dateien arbeiten zu lassen, heißt, ihnen das falsche Werkzeug in die Hand zu geben. Die meisten professionellen Übersetzer nutzen CAT-Tools (Computer-Assisted Translation) wie Phrase, Lokalise oder Crowdin – was bedeutet, dass Sie eine dritte Integrationsschicht zwischen Ihrem Code und Ihren Übersetzern benötigen.

5. Kontextfreie Übersetzung

Wenn Übersetzer nur einen JSON-Schlüssel und eine Zeichenkette sehen, haben sie keinen Kontext darüber, wo diese Zeichenkette in der UI erscheint. „Abbrechen" bedeutet auf einer Abo-Kündigungsseite etwas anderes als in einem Datei-Upload-Dialog. Kontextfreie Übersetzung führt zu geringerer Qualität.

6. Deployment-Kopplung

In traditionellen Setups werden Übersetzungen mit der App gebündelt. Jedes Übersetzungsupdate erfordert ein neues Deployment. Das ist langsam und riskant – eine Tippfehlerkorrektur in einer französischen Übersetzung erfordert einen vollständigen Release-Zyklus.

Wie better-i18n die React-Internationalisierung vereinfacht {#better-i18n-section}

better-i18n wurde entwickelt, um jedes der oben beschriebenen Probleme zu lösen. Es ist eine KI-gestützte Content-Lokalisierungsplattform, die speziell für React- und Next.js-Anwendungen konzipiert wurde.

Die Kernidee: Content als Service

Anstatt Übersetzungsstrings in Ihrer Codebasis zu verwalten, behandelt better-i18n Ihre Inhalte als verwalteten Service. Ihre React-App verbindet sich mit dem better-i18n-CMS, und Übersetzungen werden dynamisch bereitgestellt – keine JSON-Dateien in Ihrem Repository, keine Schlüsselextraktion, kein Deployment für Content-Updates erforderlich.

So funktioniert es

1. Verbinden Sie Ihre React-App mit dem better-i18n-CMS über eine einzige SDK-Integration
2. Erstellen und verwalten Sie Inhalte in der better-i18n-UI – kein JSON, kein Entwickler für Content-Updates erforderlich
3. KI übersetzt automatisch, wenn Sie neue Inhalte veröffentlichen oder bestehende ändern
4. Ihre React-App erhält Übersetzungen in Echtzeit – kein Rebuild, kein Redeploy

Kein Entwickler-Engpass

Mit better-i18n kann ein Marketing-Manager eine Überschrift an einem Freitagabend um 15 Uhr aktualisieren, und sie erscheint innerhalb von Minuten in allen 12 unterstützten Sprachen – ohne Ticket, ohne Entwickler, ohne Deployment.

Kontextbewusste KI-Übersetzung

Da better-i18n Inhalte mit vollem Kontext speichert (Seite, Abschnitt, Content-Typ, Autorennotizen), liefert die KI-Übersetzungsengine qualitativ hochwertigere Übersetzungen als Tools, die nur isolierte Zeichenketten sehen. Sie können auch Übersetzungsnotizen und Reviewer-Workflows direkt in der Plattform hinzufügen.

CMS-gesteuerter Workflow

Das better-i18n-CMS gibt Ihrem gesamten Team – Entwicklern, Marketern, Textern und Übersetzern – einen gemeinsamen Arbeitsbereich. Übersetzer nutzen eine speziell entwickelte Übersetzungs-UI, keine JSON-Dateien. Marketer können übersetzte Inhalte vor der Veröffentlichung in der Vorschau anzeigen. Entwickler bleiben im Code.

Funktioniert mit Ihrem bestehenden React-Stack

better-i18n ist kein Ersatz für Ihr React-Framework – es integriert sich daneben. Ob Sie Create React App, Next.js, Remix oder Vite verwenden, better-i18n funktioniert ohne Änderung Ihrer Komponentenarchitektur.

Codebeispiele: Traditionell vs. better-i18n {#code-examples}

Schauen wir uns ein konkretes Beispiel an: eine Produkt-Landingpage mit einem Hero-Bereich, einer Feature-Liste und einem Pricing-CTA.

Traditioneller react-i18next-Ansatz

Was Sie im Code verwalten:

// public/locales/en/landing.json (und eine für jede Sprache)
{
  "hero": {
    "headline": "Ship your product to the world",
    "subheadline": "The fastest way to go global without slowing down your team",
    "cta_primary": "Start for free",
    "cta_secondary": "See how it works"
  },
  "features": {
    "title": "Everything you need to go global",
    "item1_title": "Instant AI Translation",
    "item1_desc": "Translate your entire product in minutes, not weeks",
    "item2_title": "No developer bottleneck",
    "item2_desc": "Marketers update content directly — no tickets, no PRs",
    "item3_title": "Real-time updates",
    "item3_desc": "Content updates go live instantly, no redeployment needed"
  }
}

Die Komponente:

// src/components/LandingHero.jsx
import { useTranslation } from 'react-i18next';

function LandingHero() {
  const { t } = useTranslation('landing');

  return (
    <section className="hero">
      <h1>{t('hero.headline')}</h1>
      <p>{t('hero.subheadline')}</p>
      <div className="cta-group">
        <a href="/signup" className="btn-primary">
          {t('hero.cta_primary')}
        </a>
        <a href="/demo" className="btn-secondary">
          {t('hero.cta_secondary')}
        </a>
      </div>
    </section>
  );
}

Um eine neue Sprache hinzuzufügen, müssen Sie:

1. Eine neue JSON-Datei erstellen (fr/landing.json)
2. Alle Übersetzungen manuell hinzufügen oder über ein TMS exportieren/importieren
3. fr zur i18next-Ressourcen-Konfiguration hinzufügen
4. Die App neu bauen und deployen

better-i18n-Ansatz

Die Komponente (für jede Sprache unverändert):

// src/components/LandingHero.jsx
// Diese Komponente ändert sich für i18n überhaupt nicht
// Inhalte kommen aus dem CMS; better-i18n übernimmt das Locale-Routing

function LandingHero({ content }) {
  return (
    <section className="hero">
      <h1>{content.headline}</h1>
      <p>{content.subheadline}</p>
      <div className="cta-group">
        <a href="/signup" className="btn-primary">
          {content.ctaPrimary}
        </a>
        <a href="/demo" className="btn-secondary">
          {content.ctaSecondary}
        </a>
      </div>
    </section>
  );
}

Um eine neue Sprache hinzuzufügen:

1. Im better-i18n-Dashboard auf „Sprache hinzufügen" klicken
2. KI übersetzt alle bestehenden Inhalte automatisch
3. Fertig – die neue Sprache ist sofort live

Keine JSON-Dateien. Keine Schlüsselextraktion. Kein Rebuild. Kein Redeploy.

Dynamische Inhalte verarbeiten

Der traditionelle Ansatz für nutzergenerierte oder datenbankgesteuerte Inhalte erfordert in der Regel, jede Zeichenkette in t() einzuwickeln und Schlüssel für jeden dynamischen String zu pflegen – was oft unmöglich ist. Mit better-i18n sind im CMS verwaltete Inhalte automatisch in allen konfigurierten Sprachen verfügbar, unabhängig davon, ob es sich um statischen UI-Text oder lange Inhalte wie Blog-Beiträge oder Produktbeschreibungen handelt.

Best Practices für React i18n {#best-practices}

Ganz gleich, ob Sie eine traditionelle Bibliothek oder better-i18n verwenden – diese Grundsätze gelten für alle React-Lokalisierungsarbeiten.

1. Alle Strings von Anfang an externalisieren

Hardcodieren Sie niemals benutzerseitige Zeichenketten direkt in JSX. Selbst wenn Sie mit nur einer Sprache beginnen, erleichtert das Externalisieren von Strings von Anfang an die spätere i18n erheblich.

2. Für Textexpansion planen

Deutscher Text ist typischerweise 30–40 % länger als entsprechender englischer Text. Russisch kann 50 % länger sein. Gestalten Sie Ihre UI mit ausreichend Flexibilität, um Textexpansion zu bewältigen, ohne Layouts zu zerstören. Verwenden Sie CSS-Eigenschaften wie overflow: hidden, text-overflow: ellipsis oder flexible Container statt fixer Breiten.

3. String-Konkatenation vermeiden

Erstellen Sie niemals übersetzte Zeichenketten durch Verkettung:

// FALSCH — funktioniert für Sprachen mit anderer Wortstellung nicht
const message = t('hello') + ', ' + userName + '!';

// RICHTIG — Interpolation verwenden
const message = t('hello_user', { name: userName });
// Übersetzung: "hello_user": "Hello, {{name}}!"

4. Pluralformen korrekt handhaben

Englisch hat zwei Pluralformen (Singular/Plural). Viele Sprachen haben mehr. Arabisch hat sechs Pluralformen. Verwenden Sie immer die Plural-Behandlung Ihrer Bibliothek – schreiben Sie niemals eigene:

// FALSCH
const label = count === 1 ? t('item_singular') : t('item_plural');

// RICHTIG
const label = t('item', { count });
// Mit korrekten Plural-Schlüsseln: item_one, item_other, item_few, usw.

5. Sprachpräferenz speichern

Speichern Sie die Sprachwahl des Nutzers dauerhaft:

// Bei Sprachwechsel
localStorage.setItem('preferred-locale', newLocale);

// Bei App-Initialisierung
const savedLocale = localStorage.getItem('preferred-locale');
const browserLocale = navigator.language.split('-')[0];
const locale = savedLocale || browserLocale || 'en';

6. Gebietsschema-bewusste Formatierung verwenden

Verwenden Sie immer Intl-APIs oder die Formatierungsfunktionen Ihrer i18n-Bibliothek für Datumsangaben, Zahlen und Währungen:

// FALSCH
const formatted = '$' + price.toFixed(2);

// RICHTIG
const formatted = new Intl.NumberFormat(locale, {
  style: 'currency',
  currency: 'USD',
}).format(price);
// Für deutsches Gebietsschema: "1.234,56 $"
// Für US-Gebietsschema: "$1,234.56"

7. RTL frühzeitig einplanen

Wenn Sie Arabisch, Hebräisch, Farsi oder Urdu unterstützen möchten, planen Sie RTL von Anfang an ein. Verwenden Sie logische CSS-Eigenschaften statt physischer:

/* Physisch (bricht im RTL-Modus) */
.container { margin-left: 16px; padding-right: 24px; }

/* Logisch (funktioniert sowohl in LTR als auch RTL) */
.container { margin-inline-start: 16px; padding-inline-end: 24px; }

8. Mit Pseudo-Lokalisierung testen

Bevor Sie Strings an echte Übersetzer senden, verwenden Sie Pseudo-Lokalisierung, um zu überprüfen, ob Ihre UI Textexpansion und Sonderzeichen verarbeitet:

// Pseudo-Locale wandelt "Hello, World!" in "[Ĥéĺĺô, Ŵôŕĺď!]" um
// Das findet Layout-Fehler, bevor echte Übersetzungen eintreffen

9. Schlüsselextraktion in CI automatisieren

Wenn Sie eine Bibliothek verwenden, die Schlüsselextraktion erfordert, machen Sie diese zu einem Teil Ihrer CI-Pipeline. Ein fehlender Schlüssel in der Produktion zeigt Nutzern leere Zeichenketten – was schlimmer ist als englischen Text anzuzeigen.

10. Übersetzungsupdates von Code-Deployments trennen

Die besten Architekturen entkoppeln Content-Updates von Code-Releases. Das ist der Grund, warum CMS-gesteuerte Ansätze wie better-i18n zunehmend bevorzugt werden – Übersetzungen können unabhängig von Application-Deployments aktualisiert und veröffentlicht werden.

Häufig gestellte Fragen {#faq}

Was ist der Unterschied zwischen React i18n und React-Lokalisierung?

React i18n (Internationalisierung) bezeichnet die technische Arbeit, Ihre App fähig zu machen, mehrere Sprachen zu unterstützen – Infrastruktur aufsetzen, Bibliotheken wählen und Code so strukturieren, dass er gebietsschema-fähig ist. React-Lokalisierung (l10n) bezeichnet die eigentliche Anpassung Ihrer App für ein bestimmtes Gebietsschema – der übersetzte Text, Datumsformate und kulturelle Konventionen für eine bestimmte Sprache und Region. i18n ist die Voraussetzung; l10n ist die laufende Arbeit.

Welche React-i18n-Bibliothek sollte ich verwenden?

Für die meisten neuen Projekte ist react-i18next aufgrund seiner Ökosystem-Größe und Flexibilität die sicherste Wahl. Für Next.js-Projekte bietet next-intl eine hervorragende App-Router-Integration und Typsicherheit. Wenn Sie die JSON-Dateiverwaltung vollständig eliminieren und Ihrem Content-Team Autonomie geben möchten, entfernt better-i18n die gesamte traditionelle Bibliotheksschicht und bietet einen CMS-gesteuerten Workflow.

Wie füge ich i18n zu einer bestehenden React-App hinzu?

Das Hinzufügen von i18n zu einer bestehenden React-App umfasst drei Phasen: (1) Alle hartcodierten Strings in Ihren Komponenten prüfen, (2) eine i18n-Bibliothek wählen und konfigurieren, und (3) Strings in Übersetzungsdateien extrahieren und hartcodierten Text durch Übersetzungsfunktionsaufrufe ersetzen. Mit better-i18n ist der Prozess einfacher – Sie verbinden das SDK und migrieren Inhalte ins CMS, ohne Ihre Komponentenlogik zu ändern.

Beeinflusst React i18n die Performance?

Bei traditionellen Bibliotheken werden JSON-Übersetzungsdateien typischerweise mit der App gebündelt oder per Locale lazy-geladen. Große Übersetzungs-Bundles können die anfängliche Ladezeit beeinträchtigen. Namespace-Splitting und Lazy Loading (unterstützt von react-i18next) mildern das. better-i18n liefert Inhalte über ein Edge-CDN, sodass Übersetzungen mit minimaler Latenz bereitgestellt werden – unabhängig vom Standort des Nutzers.

Wie verarbeite ich dynamische Inhalte (nutzergenerierte Inhalte) in React i18n?

Dynamische Inhalte – wie Benutzernamen, Post-Titel oder Produktbeschreibungen – können nicht statisch übersetzt werden. Optionen sind: (1) maschinelle Übersetzung zur Laufzeit über eine API, (2) vorübersetzte Versionen in der Datenbank speichern, oder (3) eine Content-Plattform wie better-i18n verwenden, die sowohl statische UI-Strings als auch lange dynamische Inhalte in einem einzigen Workflow verwaltet.

Kann ich react-i18next mit Next.js verwenden?

Ja. React-i18next funktioniert sowohl mit dem Next.js Pages Router als auch mit dem App Router, obwohl die App-Router-Integration eine sorgfältige Behandlung von Server-Komponenten erfordert. Für Next.js-Projekte ist next-intl oft die bessere Wahl, da es speziell für Next.js mit nativer Server-Komponenten-Unterstützung entwickelt wurde.

Wie viele Sprachen sollte meine React-App unterstützen?

Beginnen Sie mit den Sprachen, die Ihre Zielmärkte sprechen. Für ein US-fokussiertes SaaS-Produkt deckt das Hinzufügen von Spanisch, Französisch, Portugiesisch und Deutsch typischerweise 80 %+ der nicht-englischsprachigen Märkte ab, die Sie voraussichtlich erreichen werden. Verwenden Sie Analytics, um herauszufinden, wo Ihre bestehenden Nutzer herkommen, bevor Sie Sprachen priorisieren.

Was kostet es, meine React-App nicht zu internationalisieren?

Der Preis ist Marktausschluss. 75 % der Internet-Nutzer weltweit sind keine Muttersprachler des Englischen. Apps ohne Lokalisierung können nicht für nicht-englische Suchanfragen bei Google ranken, können nicht-englische Besucher nicht effektiv konvertieren und signalisieren internationalen Nutzern, dass das Produkt nicht für sie gebaut wurde. Für die meisten Software-Produkte ist der ROI beim Hinzufügen von 3–5 Sprachen im ersten Jahr positiv.

Wie handhabt better-i18n die Übersetzungsqualität?

better-i18n nutzt KI-Übersetzung mit Kontextbewusstsein – die KI sieht nicht nur die zu übersetzende Zeichenkette, sondern auch ihren Content-Typ, ihren Seitenstandort und alle von Ihnen hinzugefügten Übersetzernotizen. Die Plattform unterstützt auch Human-Review-Workflows, bei denen professionelle Übersetzer KI-generierte Übersetzungen vor der Veröffentlichung prüfen und genehmigen können. Das gibt Ihnen sowohl die Geschwindigkeit von KI als auch die Qualitätssicherung durch menschliche Aufsicht.

Ist better-i18n für große React-Anwendungen geeignet?

Ja. better-i18n ist skalierbar konzipiert – von Startups mit einem einzelnen Produkt bis hin zu Unternehmen, die Inhalte über mehrere Produkte und Dutzende von Sprachen hinweg verwalten. Das CMS ist für die Team-Zusammenarbeit ausgelegt, mit rollenbasierter Zugriffskontrolle, Freigabe-Workflows und Translation Memory, das die KI-Qualität im Laufe der Zeit verbessert.

Fazit

React i18n hat sich erheblich weiterentwickelt. Der traditionelle Ansatz – react-i18next installieren, JSON-Dateien für jede Sprache erstellen und Übersetzungsschlüssel manuell pflegen – funktioniert zwar noch, schafft aber einen anhaltenden Betriebsaufwand, der Teams verlangsamt, sobald ihr Produkt wächst.

Moderne Alternativen wie better-i18n vertreten eine grundlegend andere Philosophie: Content als Service, vom Code entkoppelt, verwaltet von den Menschen, die ihm am nächsten sind (Marketer, Autoren, Übersetzer), und KI-gestützt, sodass das Hinzufügen einer neuen Sprache eine Produktentscheidung ist, kein Entwicklungsprojekt.

Ganz gleich, ob Sie eine neue React-App starten oder i18n zu einer bestehenden hinzufügen: Das Ziel ist dasselbe – Ihr Produkt für Nutzer in ihrer Sprache und in ihrem kulturellen Kontext zugänglich zu machen, ohne Lokalisierung zu einer dauerhaften Quelle von Entwickleraufwand zu machen.

Bereit, React i18n ohne die Komplexität zu Ihrer App hinzuzufügen? Starten Sie mit better-i18n – verbinden Sie Ihre React-App in wenigen Minuten und lassen Sie Ihr Content-Team den Rest erledigen.

Zuletzt aktualisiert: März 2024. Keywords: react internationalization, react i18n, react localization, react js i18n, react js localization, reactjs localization.