i18n: Der grundlegende Leitfaden zur Internationalisierung von Software

Was Internationalisierung (i18n) bedeutet, wie sie sich von Lokalisierung unterscheidet und welche sieben technischen Verfahren es ermöglichen, eine Sprache hinzuzufügen, ohne Code neu schreiben zu müssen: UTF-8, externalisierte Zeichenfolgen, ICU-Pluralformen, Intl-Formatierung, flexible Layouts, Gebietsschema-URLs und Pseudolokalisierung.
Keine Kreditkarte erforderlich Ohne Verpflichtung

· Aktualisiert · Alex B · Der Blog

Fassen Sie diesen Beitrag zusammen mit: 9 Minuten Lesezeit

Internationalisierung (i18n) ist die Arbeit, die Sie im Code erledigen, sodass ein Produkt an jede Sprache oder Region angepasst werden kann, ohne dass es neu entwickelt werden muss. Das W3C definiert es als “den Entwurf und die Entwicklung eines Produkts, einer Anwendung oder eines Dokumentinhalts, der eine einfache Lokalisierung für Zielgruppen unterschiedlicher Kultur, Region oder Sprache ermöglicht” (W3C). In der Praxis bedeutet das überall Unicode, keine fest codierten, benutzerorientierten Zeichenfolgen, eine ortsspezifische Formatierung von Datums-, Zahlen- und Pluralangaben sowie Layouts, die längeren Text und Rechts-nach-links-Skripte überstehen.

Wichtige Erkenntnisse

  • i18n ist Engineering; Lokalisierung (L10n) ist die Anpassung an einen Markt, die i18n ermöglicht. Die Buchstaben “18” und “10” zählen die Buchstaben zwischen dem ersten und letzten Buchstaben jedes Wortes.
  • Die fünf Gewohnheiten, die die meisten i18n-Fehler verhindern: UTF-8-Ende-zu-Ende, externalisierte Zeichenfolgen, Plural- und Variablenbehandlung im ICU-Stil, die lokalen Formatierungs-APIs der Plattform und flexible Layouts.
  • Erstellen Sie niemals Sätze, indem Sie Fragmente verketten. Wortreihenfolge und Pluralregeln unterscheiden sich zu sehr zwischen den Sprachen.
  • Testen Sie mit Pseudolokalisierung, bevor ein Übersetzer die Zeichenfolgen jemals sieht.
  • Eine Website, die bereits live ist und nicht für i18 n erstellt wurde, kann auf der Rendering-Ebene noch mehrsprachig gemacht werden, ohne die Codebasis zu refaktorieren.

i18n, l10n und g11n: der Unterschied

LaufzeitSteht fürWas es bedeutet
i18nInternationalisierungDas Produkt so bauen, dass es können unterstützt jedes Gebietsschema
l10nLokalisierungAnpassung für eins Gebietsschema: Übersetzung, Formate, Bilder, Rechtstext
g11nGlobalisierungDer Geschäftsprozess, der beides kombiniert, um neue Märkte zu erschließen

Das W3C listet auf, was Internationalisierung typischerweise umfasst: das Entfernen von Lokalisierungsbarrieren (Unicode und Zeichenkodierung), die Unterstützung von Funktionen wie bidirektionalem Text, die Unterstützung lokaler Konventionen für Daten, Kalender, Zahlen und Namen und “das Trennen lokalisierbarer Elemente vom Quellcode”, sodass für jeden Benutzer die richtige Version geladen wird (W3C).

Hier ist ein einfacher Test, ob die i18n-Arbeit erledigt ist: Zum Hinzufügen einer neuen Sprache sollten Übersetzer und einige Konfigurationen erforderlich sein. Wenn es einen Entwickler braucht, wurde etwas übersehen.

1. Verwenden Sie Unicode (UTF-8) Ende an Ende

UTF-8 ist die Standardeinstellung für das Web und wird von 99,1% der Websites verwendet, deren Zeichenkodierung bekannt ist (W3Techs, 28. September 2026). Heutzutage sind die Fehler selten im HTML. Sie geschehen in den Schichten drumherum:

  • Datenbankspalten und Verbindungen, die nicht auf volles UTF-8 eingestellt sind. In MySQL, utf8 ist eine 3-Byte-Teilmenge; verwenden utf8mb4 oder Emoji und einige CJK-Zeichen gehen verloren.
  • Zeichenkettenfunktionen, die Bytes statt Zeichen zählen, was „Zürich“ oder „東京“ mitten in einem Zeichen abschneidet.
  • CSV-Exporte wurden in Tabellenkalkulationssoftware mit der falschen Kodierung geöffnet.
  • Sortieren mit Bytereihenfolge statt lokaler Sortierung, bei der “Äpfel” nach “Zebra” steht.

Deklarieren Sie die Kodierung einmal (<meta charset="utf-8">), stellen Sie es auf jede Verbindung ein und verwenden Sie einen ortsabhängigen Vergleich wie z Intl.Collator in JavaScript.

2. Externalisieren Sie jede benutzerorientierte Zeichenfolge

Zeichenfolgen, die Benutzer sehen, gehören in Ressourcendateien und werden durch eine Kennung verschlüsselt. Halten Sie sie von Vorlagen und Code fern:

{
  "cart.title": "Your cart",
  "cart.empty": "Your cart is empty",
  "cart.checkout": "Go to checkout"
}

Jedes Gebietsschema erhält seine eigene Datei und der Code fragt danach cart.title. Frameworks folgen dem gleichen Muster: In Vue stellt die vue-i18n-Bibliothek $t für “Übersetzung von Gebietsschemanachrichten” und $i18n für die globale Instanz, die Orte und Nachrichten verwaltet (Vue-i18n-Dokumente). React (react-intl, i18next), Angular (@angular/localize), Django, Rails und Laravel liefern alle ein Äquivalent.

Ein paar Regeln, die später Schmerzen ersparen:

  • Geben Sie Übersetzern Kontext. “Öffnen” kann ein Verb (Datei öffnen) oder ein Adjektiv (der Store ist geöffnet) sein. Fügen Sie jedem Schlüssel eine Beschreibung hinzu.
  • Verwenden Sie einen Schlüssel nicht wieder, nur weil der englische Text übereinstimmt. “Speichern” auf einer Schaltfläche und “20 % speichern” in einem Banner sind in den meisten Sprachen unterschiedliche Nachrichten.
  • Halten Sie Markup möglichst von Zeichenfolgen fern oder verwenden Sie Platzhalter dafür, damit Übersetzer Ihr HTML nicht beschädigen können.

3. Verketten Sie niemals Sätze; verwenden Sie Platzhalter und Pluralregeln

Das sieht harmlos aus:

'You have ' + count + ' new messages';

Es bricht auf zwei Arten. Die Wortreihenfolge ändert sich zwischen den Sprachen, die Pluralregeln jedoch nicht “1 vs. alles andere”. Die Unicode-CLDR-Pluralregeln geben dem Englischen zwei Kardinalkategorien (eine, andere), dem Japanischen eine, dem Russischen und Polnischen vier (eine, wenige, viele, andere) und dem Arabischen sechs (null, eins, zwei, wenige, viele, andere) (Unicode CLDR).

Verwenden Sie ein Nachrichtenformat, das diese Regeln kennt, z. B. ICU MessageFormat:

{count, plural,
  =0 {You have no new messages}
  one {You have # new message}
  other {You have # new messages}}

Ein russischer Übersetzer kann dann hinzufügen, few „ many Formulare ohne Änderung Ihres Codes. Gleiches gilt für Geschlecht, Ordnungszahlen (“1., 2.”) und Listen (“A, B und C”).

4. Lassen Sie die Plattform Daten, Zahlen und Währung formatieren

03/04/2026 ist der 4. März in den Vereinigten Staaten und der 3. April in den meisten Teilen Europas. 1,234.5 auf Englisch ist geschrieben 1.234,5 auf Deutsch und 1 234,5 auf Französisch. Schreiben Sie Ihre Formatierung nicht selbst. Jede moderne Plattform verfügt über integrierte Gebietsschemadaten, und in JavaScript ist dies der Fall Intl API (MDN):

new Intl.NumberFormat('de-DE', { style: 'currency', currency: 'EUR' }).format(1234.5);
// "1.234,50 €"

new Intl.DateTimeFormat('fr-FR', { dateStyle: 'long' }).format(new Date('2026-09-27'));
// "27 septembre 2026"

Einige damit verbundene Entscheidungen sind es wert, frühzeitig getroffen zu werden:

  • Speichern Sie die Zeit in UTC und konvertieren Sie sie zur Anzeige in die Zeitzone des Benutzers.
  • Halten Sie die Währung vom Gebietsschema getrennt. Ein französischsprachiger Besucher in Kanada zahlt in CAD, nicht in EUR. Das Formatieren einer Zahl als Währung ist i18n; die Preisfestsetzung ist eine geschäftliche Entscheidung.
  • Gehen Sie nicht davon aus, wie Namen und Adressen geformt sind. Viele Menschen haben keinen “Vornamen” und “Nachnamen” im westlichen Sinne, und Postleitzahlen sind nicht immer numerisch.

5. Entwerfen Sie Layouts, die sich dehnen und umdrehen

Übersetzter Text ist oft länger als Englisch und kurze Zeichenfolgen wachsen am stärksten. Der W3C fasst die Richtwerte von IBM zusammen: Zeichenfolgen mit bis zu 10 Zeichen können in europäischen Sprachen um 200 bis 300 % wachsen, während Text mit über 70 Zeichen auf etwa 130 % wächst (W3C, Textgröße in der Übersetzung). Ihr Beispiel ist die italienische Umwandlung von “Ansichten” in “visualizzazioni”.

Für die UI-Arbeit bedeutet das:

  • Keine Schaltflächen oder Registerkarten mit fester Breite, die für englische Etiketten dimensioniert sind.
  • Kein in Bilder eingebauter Text. Es kann nicht übersetzt werden, ohne das Bild neu zu zeichnen.
  • Support Rechts-nach-links-Schriften (Arabisch, Hebräisch, Persisch, Urdu) mit dir="rtl" auf der <html> Element- und CSS-logische Eigenschaften (margin-inline-start statt margin-left), sodass sich das Layout selbst widerspiegelt.
  • Wählen Sie Schriftarten aus, die die Skripte abdecken, die Sie unterstützen möchten, oder definieren Sie Fallbacks.

6. Gehen Sie bewusst mit der Gebietsschemaprokennung und URLs um

Entscheiden Sie, wie das Gebietsschema eines Benutzers ausgewählt wird und wie es gespeichert wird:

  1. Eine explizite Wahl (ein Sprachumschalter) gewinnt immer.
  2. Andernfalls verwenden Sie die des Browsers Accept-Language Header als Vorschlag, keine erzwungene Weiterleitung.
  3. Geben Sie das Gebietsschema in die URL ein (/de/, de.example.com) für jede öffentliche Seite, sodass jede Sprachversion von Suchmaschinen geteilt, zwischengespeichert und indiziert werden kann. Allein Cookies machen übersetzte Seiten für Google unsichtbar.

Wenn das Produkt öffentliche Seiten hat, benötigen diese Sprach-URLs auch hreflang-Anmerkungen; siehe die hreflang-führer.

7. Test mit Pseudolokalisierung

Durch Pseudolokalisierung werden Ihre Quellzeichenfolgen durch eine geänderte Version ersetzt, bevor beispielsweise eine echte Übersetzung vorhanden ist [Ýöûŕ çåŕţ îš éɱþţý !!!!]. Die Akzente erfassen Kodierungsprobleme, die Polsterung erfasst Layouts, die unter längerem Text brechen, und die Klammern zeigen Kürzungen und alle fest codierten Zeichenfolgen an, die sich nicht geändert haben. Viele i18n-Bibliotheken und Build-Tools können ein Pseudo-Locale generieren. Führen Sie Ihre UI-Testsuite bei jeder Version damit aus.

Fügen Sie diese auch zu Ihrer Checkliste hinzu:

  • Wechseln Sie zu einem RTL-Gebietsschema und überprüfen Sie die Navigation, Symbole mit Richtung (Pfeile, Fortschrittsbalken) und Formularausrichtung.
  • Testen Sie die Sortierung und Suche mit akzentuierten Zeichen.
  • Überprüfen Sie E-Mails, PDFs, Fehlermeldungen und Push-Benachrichtigungen, die oft vergessen werden.

Eine i18n-Checkliste für neue Projekte

  • UTF-8 (utf8mb4 in MySQL) in Dateien, Datenbanken, Verbindungen und APIs
  • Alle benutzerorientierten Zeichenfolgen in Ressourcendateien, mit Kontext für Übersetzer
  • ICU MessageFormat (oder gleichwertig) für Pluralformen, Geschlecht und Variablen
  • Intl oder die lokalen APIs der Plattform für Daten, Zahlen, Währungen, Listen und Sortierung
  • UTC-Speicher und Zeitzonenanzeige pro Benutzer
  • Flexible Layouts, logische CSS-Eigenschaften, dir Attributunterstützung
  • Lokalisieren Sie in der URL für öffentliche Seiten, hreflang für Suchmaschinen
  • Pseudolokalisierung in CI

Wenn die Website bereits existiert

Alles oben Genannte gilt für eine Anwendung, die Sie erstellen. Für eine Marketing-Site, einen Store oder ein CMS, das bereits live ist, bedeutet dies ein großes Refactoring, und das Team, dem der Inhalt gehört, ist normalerweise nicht das Team, dem der Code gehört.

In diesem Fall kann die Übersetzung stattdessen auf der Rendering-Ebene erfolgen. ConveyThis liest den Text, den Ihre Website bereits ausgibt, übersetzt ihn in eine von 210 Sprachen und stellt jede Sprache auf ihrer eigenen URL bereit (Unterordner oder Subdomain im Businessplan und höher oder a ?lang Parameter) mit automatisch hinzugefügtem hreflang. Bei Sprachen von rechts nach links wird die Textrichtung umgeschaltet, Bilder können pro Sprache ersetzt werden und ein Glossar und Übersetzungsspeicher Halten Sie Produktnamen und -begriffe konsistent. Es installiert sich als WordPress-Plugin, eine Shopify-App oder ein einzelnes Skript auf einem anderen Stapel, sodass die i18n-Arbeit in Ihrer Codebasis nach ihrem eigenen Zeitplan fortgesetzt werden kann. Um die geschäftliche Seite der Anpassung von Inhalten an jeden Markt zu erfahren, lesen Sie unseren Leitfaden auf Was die Inhaltslokalisierung beinhaltet.

Häufig gestellte Fragen

Warum wird Internationalisierung mit i18n abgekürzt? Zwischen dem ersten “i” und dem letzten “n” in “Internationalisierung” stehen 18 Buchstaben. Die Lokalisierung (l10n) folgt demselben Muster.

Ist i18n dasselbe wie Übersetzung? Nein. Übersetzung ist ein Teil der Lokalisierung. i18n ist die Technik, die die Übersetzung und jede andere lokale Anpassung ohne Codeänderungen ermöglicht.

Wann sollte ein Projekt i18n starten? Am Anfang. Das Externalisieren von Zeichenfolgen und die Verwendung von Gebietsschema-APIs kostet am ersten Tag wenig und ist viel, wenn sie in eine ausgereifte Codebasis nachgerüstet werden.

Was ist $i18n in Vue? In vue-i18n, $i18n ist die globale Instanz, die Orte und Nachrichten verwaltet, und $t ist die Funktion, die eine übersetzte Nachricht für einen Schlüssel zurückgibt (vue-i18n).

Nächster Schritt

Wenn Sie eine Live-Website in mehreren Sprachen benötigen, bevor die Codebasis vollständig internationalisiert ist, Erstellen Sie ein ConveyThis-Konto und veröffentlichen Sie Ihre Muttersprache, dann vergleichen Sie Pläne wenn Sie mehr hinzufügen.

Teilen:
G2 High Performer Spring 2023
G2 Easiest Setup Fall 2024
G2 Best Support Spring 2025