Internationalisierung (i18n): Vorteile, Best Practices und Tipps zur Implementierung

Was ist i18n?

Internationalisierung (i18n) ist der Prozess des Entwerfens von Software, die an verschiedene Sprachen und Regionen angepasst werden kann, ohne Ihren Code zu ändern. Der Spitzname "i18n" kommt von der Tatsache, dass zwischen dem "i" und dem "n" in der Internationalisierung 18 Buchstaben liegen.

Stellen Sie sich i18n als Grundstein vor für:

• Lokalisierung (l10n): Übersetzung und Anpassung Ihrer Inhalte für einen bestimmten Markt.
• Globalisierung (g11n): Koordination der Produktbereitschaft und des Betriebs in allen Märkten.
  
  

In der Praxis geht es bei i18n darum, sicherzustellen, dass Ihre App Folgendes verarbeiten kann:

• Text in jeder Sprache
• Datum, Uhrzeit, Zahlen und Währungen im richtigen Format
• Pluralisierungsregeln, die der lokalen Grammatik entsprechen
• Layouts von rechts nach links (z. B. Arabisch oder Hebräisch)

Warum i18n wichtig ist

Die Investition in i18n im Voraus bringt Ihren Engineering- und Produktteams greifbare Vorteile:

• Niedrigere Lokalisierungskosten: Das Extrahieren und Ersetzen von Zeichenfolgen ist einfacher, wenn die Übersetzungslogik von Anfang an integriert ist.
• Schnellere Entwicklung: Die gemeinsam genutzte Infrastruktur für die Verwaltung von Zeichenfolgen reduziert zukünftige Nacharbeiten.
• Bessere UX: Benutzer sehen Inhalte in ihrer Sprache, die so formatiert sind, dass sie sich natürlich anfühlen.
• Skalierbarkeit: Apps können mit weniger Codeänderungen in neuen Märkten eingeführt werden.

i18n-Implementierungsmuster in modernen Apps

Im Folgenden finden Sie einige gängige Muster für die Implementierung von i18n in produktionstauglichen Apps. Wir gehen durch React (Frontend), iOS und Android.

Unabhängig von der Plattform stammen Übersetzungen in der Regel aus einem Translation-Management-System (TMS) wie Smartling als JSON- oder Ressourcendateien. Diese Dateien werden dann von Ihrer App zur Laufzeit über ein i18n-Framework oder eine native Lokalisierungs-API geladen, um sicherzustellen, dass die richtigen Zeichenfolgen für die Sprache oder das Gebietsschema des Benutzers angezeigt werden.

Frontend (Reagieren)

Moderne React-Apps verwenden in der Regel eine dedizierte i18n-Bibliothek. Zwei der beliebtesten sind i18next und FormatJS, die beide Framework-agnostisch sind. In React sind die jeweiligen Implementierungen react-i18next (funktions- und hookbasiert) und react-intl (komponenten- und hookbasiert, basierend auf ICU MessageFormat). Beide lassen sich sauber in Unternehmenspipelines integrieren und verarbeiten Pluralisierung, Variablen und gebietsschemaabhängige Formatierung.

1. Reagieren Sie mit i18next + react-i18next

i18next ist eine der beliebtesten JavaScript-i18n-Bibliotheken und bietet in Kombination mit den react-i18next-Bindungen React-Apps eine leistungsstarke, Hook-freundliche API zum Laden und Rendern von Übersetzungen.

Im folgenden Beispiel führen wir ein gängiges i18n-Muster für Unternehmen durch. Wir definieren Übersetzungsdateien, initialisieren i18next am Einstiegspunkt der App und rendern dann die Übersetzungen in Komponenten. Dieser Ansatz funktioniert über Frameworks hinweg, lässt sich nahtlos in die meisten Translation-Management-Systeme (TMS) integrieren und lässt sich gut skalieren, wenn Ihre App wächst – unabhängig davon, ob Sie statische Zeichenfolgen oder dynamische, variablengesteuerte Nachrichten wie Zählungen anzeigen.

Beispiel für ein i18n-Muster: i18next + reacti18next

Wahrscheinlich erhalten Sie Inhalte als JSON-Dateien von Ihrem Übersetzungsmanagementsystem. Das folgende Beispiel für eine JSON-Datei zeigt, wie Übersetzungen für Englisch gespeichert werden. Jeder Eintrag verfügt über einen eindeutigen Schlüssel, und Pluralformen werden separat definiert, sodass die Bibliothek basierend auf der von Ihnen übergebenen Anzahl die richtige auswählen kann. Ihr TMS generiert für jede unterstützte Sprache eine passende Datei.

{

  "welcome": "Welcome",

  "visits_one": "Sie haben {{count}} Mal besucht.",

  "visits_other": "Du hast {{count}} mal besucht."

}

Als Nächstes sehen Sie ein Beispiel dafür, wie Sie i18next so konfigurieren, dass es weiß, welche Sprachen Ihre App unterstützt, wo die Übersetzungen zu finden sind und was zu tun ist, wenn eine Übersetzung fehlt. Diese Setupdatei wird einmal ausgeführt, wenn Ihre App gestartet wird (häufig in der Einstiegspunktdatei wie index.js oder main.tsx) , damit die Übersetzungen bereit sind, bevor die Benutzeroberfläche gerendert wird. Durch die Zentralisierung der Konfiguration an einem Ort bleibt Ihre Lokalisierungslogik in Ihrer gesamten App konsistent.

i18next aus 'i18next' importieren;

import { initReactI18next } von 'react-i18next';

import en from './locales/en/translation.json';

import fr von './locales/fr/translation.json';

const Gebietsschema = 'fr'; in der Produktion, dynamisch auflösen

i18Nächste

  .use(initReactI18next)

  .init({

    lng: locale,

    fallbackLng: 'en',

    Ressourcen: {

      en: { translation: en },

      fr: { Übersetzung: fr }

    },

    Interpolation: { escapeWert: falsch }

  });

export default i18next;

Sobald i18next initialisiert ist, können Sie es überall in Ihrer App verwenden. Im folgenden Beispiel ruft der useTranslation-Hook die t-Funktion ab , die einen Schlüssel und optionale Variablen benötigt, um die richtige Zeichenfolge zu rendern. Wenn Sie count als Variable übergeben, wählt i18next automatisch die richtige Pluralform basierend auf der Übersetzungsdatei aus.

import { useTranslation } von 'react-i18next';

import './i18n';

Standardfunktion exportieren App() {

  const { t } = useTranslation();

  const Anzahl = 3;

  return (

    <>

      <h1>{t('welcome')}</h1>

      <p>{t('Besuche', { count })}</p>

    </>

  );

}

2. Reagieren Sie mit FOrmatJS + react-intl

react-intl ist Teil des FormatJS-Ökosystems und bietet einen komponentenbasierten Ansatz für i18n in React. Es basiert auf dem ICU MessageFormat-Standard, sodass Sie eine integrierte Pluralisierung, Datums-/Zahlenformatierung und Gebietsschema-Fallback erhalten.

Im folgenden Beispiel richten wir Übersetzungsdateien ein, umschließen die App in einem IntlProvider und rendern lokalisierten Text mit FormattedMessage. Dieser Ansatz eignet sich gut für Teams, die einen deklarativen, komponentengesteuerten Stil für die Handhabung von i18n in React wünschen.

Beispiel für ein i18n-Muster: FormatJS + react-intl

Die folgende JSON-Datei enthält Übersetzungen unter Verwendung der ICU MessageFormat-Syntax, die Plurallogik in die Zeichenfolge selbst einfügt. Auf diese Weise bleiben alle Sprachregeln an einem Ort und Übersetzer können die Grammatik vollständig kontrollieren, ohne dass Entwickler eingreifen müssen. Ihr TMS verwaltet diese Dateien pro Gebietsschema.

{

  "welcome": "Welcome",

Als Nächstes sehen Sie ein Beispiel für das Umschließen Ihrer App in der IntlProvider-Komponente . Hierbei handelt es sich um eine einmalige Einrichtung, die in der Regel in einer Stammkomponente wie Root.tsx oder index.jsx durchgeführt wird. Es macht das aktive Gebietsschema und seine Nachrichten in der gesamten App verfügbar, sodass sie von jeder Komponente ohne zusätzliche Importe verwendet werden können.

import { IntlProvider } von 'react-intl';

import en from './locales/en.json';

import fr von './locales/fr.json';

const MESSAGES = { en, fr };

const locale = 'fr';

Standardfunktion exportieren Root() {

  return (

    <IntlProvider locale={locale} messages={MESSAGES[locale]}>

      <App />

    </IntlProvider>

  );

}

Lesen Sie abschließend weiter unten, um zu erfahren, wie die FormattedMessage-Komponente eine Übersetzung anhand ihrer ID nachschlägt und die Pluralisierung automatisch handhabt. Alles, was Sie übergeben müssen, ist die Anzahl, und die Bibliothek wendet die richtigen Sprachregeln aus Ihrer JSON-Datei an.

import { FormattedMessage } von 'react-intl';

Standardfunktion exportieren App() {

  const Anzahl = 3;

  return (

    <>

      <h1><FormattedMessage id="welcome" defaultMessage="Welcome" /></h1>

      <p><FormattedMessage id="visits" values={{ count }} /></p>

    </>

  );

}

Ein paar zusätzliche Tipps für den Einsatz in der Produktion:

• Quelle des Gebietsschemas: Bestimmen Sie in echten Apps das Gebietsschema zentral (z. B. aus einer URL wie /fr/*, dem Benutzerprofil oder einer vom Server bereitgestellten Einstellung) und übergeben Sie es an <IntlProvider>.
• Organisation der Nachricht: Unterteilen Sie die Nachrichtendateien zur Skalierung nach Domäne oder Funktion (z. B. auth.json, dashboard.json) und führen Sie sie für das aktive Gebietsschema zusammen.
• Fallbacks: defaultMessage ist Ihr Sicherheitsnetz während der Einführung – behalten Sie es in Ihrer Ausgangssprache bei.
• Asynchrones Laden (optional): Importieren Sie bei großen Paketen dynamisch Nachrichtendateien pro Gebietsschema (Code-Split), bevor Sie<IntlProvider> rendern.

Ios

iOS bietet Ihnen standardmäßig solide Lokalisierungstools, aber eine saubere Skalierung auf viele Gebietsschemata erfordert eine durchdachte Implementierung der Best Practices für i18n. Andernfalls können Sie ohne eine klare Struktur mit doppelten Schlüsseln, inkonsistenten Formatierungen und Übersetzungsdateien enden, die bei der Pflege Kopfschmerzen bereiten. Der Schlüssel liegt darin, frühzeitig einige strukturelle Entscheidungen zu treffen, damit Ihre Lokalisierung organisiert bleibt und leicht erweitert werden kann, wenn neue Märkte hinzukommen.

Tipp 1: Organisieren Sie Ressourcen so, dass sie skalierbar sind

Ein guter Ausgangspunkt sind Zeichenfolgenkataloge (.xcstrings) in Xcode 15 und höher oder .strings/.stringsdict Dateien, wenn Sie ein älteres Setup verwenden. Diese funktionieren gut mit einem TMS, das Ihnen in der Regel Übersetzungen im XLIFF-Format zusendet. Sie können diese direkt in Ihren Katalog importieren, und das System übernimmt die schwere Arbeit, sie zusammenzuführen und zu verwalten.

Wahrscheinlich fällt es Ihnen leichter, Ordnung zu halten, wenn Sie Kataloge nach Funktionen oder Modulen organisieren. Kleinere, zielgerichtete Dateien erleichtern das Auffinden von Schlüsseln, das Überprüfen von Änderungen und das Übergeben von Aufgaben an Übersetzer. Hier ist ein Beispiel dafür, wie Sie sie organisieren sollten:

Ressourcen

  i18n/

    Auth.xcstrings

    Auschecken.xcstrings

    Profile.xcstrings

Tipp 2: Behandeln Sie die Pluralisierung im Katalog, nicht im Code

Pluralisierung ist ein weiterer Punkt, an dem sich Struktur auszahlt. Es ist besser, alle Pluralregeln im Katalog statt in Swift zu definieren, sodass Ihr Code nur Variablen übergibt und die richtige Phrase automatisch für jede Sprache ausgewählt wird. So könnte das im Katalog aussehen:

Schlüssel: unread_messages

Format: Plural

Erstens: "%d ungelesene Nachricht"

Sonstiges: "%d ungelesene Nachrichten"

Und so können Sie es in Swift verwenden:

let unreadCount = 3

let format = Zeichenfolge(lokalisiert: "unread_messages")

let Nachricht = String.localizedStringWithFormat(format, unreadCount)

"3 ungelesene Nachrichten"

Auf diese Weise müssen Sie die Grammatik nicht fest in Code codieren, und Übersetzer können die Details für jede Sprache richtig machen.

Tipp 3: Zentralisieren Sie die Formatierung für Zahlen, Datumsangaben und Währungen

Sie sollten auch die Formatierung von Zahlen, Datum und Währung zentralisieren, damit sich jeder Teil der App einheitlich anfühlt. Ein gemeinsam genutztes Dienstprogramm oder ein gemeinsam genutzter Dienst kann dabei helfen. Hier ist ein einfaches Beispiel mit der modernen FormatStyle-API von Swift:

Preis = 19,99

let display = price.formatted(.currency(Code: "EUR"))

"19,99 €" oder "19,99 €" je nach Gebietsschema

Indem Sie Ihre Zeichenfolgenressourcen organisieren, die Pluralisierung im Katalog handhaben und die gesamte Formatierung nach dem Gebietsschema zentralisieren, können Sie Ihre iOS-App so einrichten, dass sie wächst, ohne dass zusätzlicher Wartungsaufwand erforderlich ist. Sobald diese Praktiken eingeführt sind, wird der Prozess des Hinzufügens neuer Sprachen weitaus vorhersehbarer – und viel weniger stressig. Schauen wir uns nun Android an, das seine eigenen integrierten Lokalisierungstools bietet.

Android

Das Ressourcensystem von Android wurde bereits mit Blick auf die Lokalisierung entwickelt, aber es in vielen Sprachen wartbar zu halten, erfordert einige Planung. Wenn Sie alles in einer großen Datei aufbewahren oder Grammatikregeln im Code verstreuen, kann es schnell chaotisch werden. Priorisieren Sie stattdessen die segmentierte Organisation von Dateien, definieren Sie alle Grammatikregeln in XML, und stellen Sie sicher, dass Ihre Formatierung und Layouts für jedes Schriftsystem funktionieren, das Sie unterstützen möchten.

Tipp 1: Organisieren Sie Ressourcen nach Funktionen

Für die meisten Teams kommen die Übersetzungen aus einem TMS als XLIFF-Dateien. Sie importieren diese in die res/values-Verzeichnisse für jedes Gebietsschema, und Android kümmert sich darum, die richtigen Zeichenfolgen mit der Sprache des Benutzers abzugleichen.

Das Aufteilen Ihrer Ressourcen in separate Dateien nach Funktionen ist eine einfache Möglichkeit, das Leben zu erleichtern. Kleinere Dateien beschleunigen die Überprüfung von Änderungen und helfen, Zusammenführungskonflikte zu vermeiden.

app/src/main/res/

  values/strings_auth.xml

  values/strings_checkout.xml

  values/plurals_checkout.xml

Tipp 2: Definieren Sie Grammatikregeln in Ressourcen, nicht in Code

Wie in iOS ist die Pluralisierung eines der Dinge, die am besten in Ressourcen gehandhabt werden, damit Übersetzer sie pro Sprache anpassen können, ohne dass Sie den Code ändern müssen. Hier ist ein Beispiel für eine Ressource im Plural auf Englisch:

<plurals name="checkout_cart_items_count">

    <item quantity="one">%1$d item</item>

    <item quantity="other">%1$d Artikel</item>

</plurals>

Und so würden Sie es in Kotlin verwenden:

val msg = resources.getQuantityString(

    R.plurals.checkout_cart_items_count, zählen, zählen

)

Auf diese Weise bleibt unser Code sauber und Android wählt automatisch das richtige Formular basierend auf dem Gebietsschema aus.

Tipp 3: Verwenden Sie eine Formatierung, die das Gebietsschema berücksichtigt 

Für Layouts ist es eine gute Angewohnheit, Anfang und Ende anstelle von Links und Rechts zu verwenden, damit sie sich an Rechts-nach-Links-Sprachen wie Arabisch oder Hebräisch anpassen:

<LinearLayout

    android:paddingStart="16dp"

    android:paddingEnd="16dp"

    android:layout_width="match_parent"

    android:layout_height="wrap_content">

</LinearLayout>

Und wenn Sie Zahlen oder Währungen formatieren, übergeben Sie das aktuelle Gebietsschema der App, damit alles einheitlich aussieht:

val appLocale = LocaleListCompat.getAdjustedDefault()[0] ?: Locale.getDefault()

val price = NumberFormat.getCurrencyInstance(appLocale).format(1234.56)

"1.234,56 $" oder "1 234,56 €"

Letzten Endes geht es bei Android i18n vor allem darum, die Plattform die schwere Arbeit machen zu lassen. Indem Sie den gesamten Text in Ressourcen aufbewahren, diese Ressourcen mit gebietsschemaspezifischen Ordnern strukturieren und RTL und gebietsschemabezogene Formatierung vom ersten Tag an integrieren, vermeiden Sie die üblichen Fallen, die die Lokalisierung brüchig machen. Viele dieser Prinzipien spiegeln die Best Practices für iOS wider, aber das Ressourcenqualifizierersystem von Android bedeutet, dass Sie neue Sprachen oft unterstützen können, indem Sie einfach die richtigen Dateien hinzufügen. Wenn es gut gemacht wird, wird das Skalieren auf neue Gebietsschemata zu einem vorhersehbaren Prozess mit geringem Aufwand.

Häufige i18n-Fallstricke

Leider stoßen auch gut ausgebaute Systeme manchmal auf vermeidbare Probleme. In der folgenden Tabelle sind einige der häufigsten Fehltritte aufgeführt, warum sie Probleme verursachen und wie man sie vermeiden kann. Betrachten Sie dies als eine Kurzreferenz, die Sie verwenden können, um Ihr eigenes Setup vor dem Versand zu überprüfen.

Vorbereitung der Lokalisierung in großem Maßstab

Sobald Ihre App für die Internationalisierung eingerichtet ist, besteht der nächste Schritt darin, die Lokalisierung so effizient und wartungsarm wie möglich zu gestalten. Mit ein paar Automatisierungstools und Workflows können Sie von "wir können übersetzen" zu "wir können neue Sprachen schnell und ohne zusätzlichen Entwicklungsaufwand einführen" führen. Erwägen:

• Verwendung eines Translation-Management-Systems (TMS) mit einer unternehmensweiten API wie Smartling zur Synchronisierung von Übersetzungsdateien und zur Verwaltung von Überprüfungs-Workflows.
• Automatisieren Sie die Extraktion und Bereitstellung von Strings mithilfe Ihrer CI/CD-Pipeline.
• Verwendung von KI-Tools (wie dem AI Hub von Smartling) für schnelle First-Pass-Übersetzungen mit integrierten Qualitätsprüfungen wie Fallback-Handling und Halluzinationsminderung.

Abschließende Gedanken

Internationalisierung ist eine grundlegende Praxis für jedes Produkt, das global wird, und je früher Sie sie implementieren, desto weniger Kopfschmerzen werden Sie später haben. Kombinieren Sie solide i18n-Praktiken mit Übersetzungsautomatisierung und Test-Workflows, und Ihr Team ist gut gerüstet, um international reife Software schneller und sicherer bereitzustellen.

Möchten Sie tiefer gehen? Schauen Sie sich Smartling's an Webinar der Global Ready Conference auf i18n Strategie im Zeitalter der KI.