i18n vs l10n: Was ist der Unterschied?

Genau wie bei In-N-Out Burgers berühmter *geheimer* Speisekarte hat jede Branchennische ihre eigene Geheimsprache, und wenn man sie einmal beherrscht, fühlt man sich wie ein Teil einer besonderen Gruppe. Die Übersetzungs- und Lokalisierungsbranche bildet da keine Ausnahme. Da unsere Branche sich gegenüber ihren mathematischen Freunden immer ein wenig minderwertig fühlt, hat sie beschlossen, Zahlen mitten in ihre Schlüsselwörter einzufügen: i18n und l10n.

Klingt technisch und einschüchternd, nicht wahr?

Es stellt sich heraus, dass es sich lediglich um eine Kurzform für Internationalisierung und Lokalisierung handelt.

Internationalisierung , oder i18n (ausgesprochen „eye-eighteen-en“), bezeichnet die Entwicklungsarbeit, die Software so vorbereitet, dass sie in jeder beliebigen Sprache ausgeführt werden kann. Dies geschieht durch das Extrahieren von Textzeichenketten aus dem Code, die Verarbeitung der Zeichenkodierung und die Erstellung flexibler Formatierungen für Datumsangaben, Währungen und Einheiten. Schritt i18n umfasst die technischen, im Hintergrund stattfindenden Arbeiten zur Vorbereitung der Lokalisierung (Schritt l10n), die für jedes Gebiet und jeden Markt einzeln durchgeführt werden.

Die meisten Erklärungsseiten, die ich sehe, sind etwas unübersichtlich, weil sie i18n und l10n als zwei Varianten derselben Aufgabe behandeln und dann den Rest des Artikels damit verbringen, über Codebibliotheken zu sprechen. Es handelt sich nicht um dieselbe Aufgabe. Internationalisierung ist etwas, das Ihr Entwicklerteam hoffentlich nur einmal macht! Lokalisierung hingegen ist das, was mit Ihrer Website jedes Mal passiert, wenn Sie einen neuen Markt hinzufügen. Sie ist der Teil, der darüber entscheidet, ob sich ein mehrsprachiger Besucher willkommen fühlt oder ob er das Gefühl hat, in die Uncanny Valley eingetreten zu sein, d. h. irgendetwas stimmt nicht, aber er kann es nicht genau benennen.

Diese Unterscheidung ist mehr als nur Pedanterie (das ist sie natürlich auch, aber in diesem Fall ist sie wichtig für Teams, die Lokalisierungen durchführen !). Eine Website kann perfekt internationalisiert sein und in der Zielsprache trotzdem als „unpassend“ wahrgenommen werden. Ihr Team hat sorgfältig darauf geachtet, Schaltflächen zu entwerfen, die sich an die deutsche Textausdehnung anpassen, Preisschilder mit dem richtigen Währungssymbol und Datumsangaben in einem dem Leser vertrauten Format. Das ist i18n! Aber was steht neben dem Button? Klingt es so, als ob es von jemandem geschrieben wurde, der den Markt versteht, oder eher so, als ob es durch eine Übersetzungs-App gejagt und direkt auf die Seite gestellt wurde? Das ist die Aufgabe der Lokalisierung und der entscheidende Faktor dafür, ob der Besucher weiterklickt oder die Seite verlässt.

Wofür steht i18n eigentlich?

Ich habe es schon einmal gesagt, aber es lohnt sich, es noch einmal deutlich zu machen (Wortspiel beabsichtigt): Internationalisierung ist ein Numeronym. Man nehme den ersten Buchstaben (i), den letzten Buchstaben (n), zähle die 18 Buchstaben dazwischen, und voilà , man erhält i18n. Es ist eine Kurzform, die sich durchgesetzt hat, weil Entwickler eine Möglichkeit wollten, das Wort zu tippen, ohne es bei einer Codeüberprüfung fünfzig Mal ausschreiben zu müssen. Daher l10n für Lokalisierung und a11y für Barrierefreiheit usw.

Aber die Abkürzung ist der langweilige Teil. Entscheidend ist, was i18n tatsächlich bewirkt.

Es handelt sich um den Prozess der Strukturierung einer Codebasis, sodass sie jede Sprache oder jedes Gebietsschema ohne Neuentwicklung unterstützen kann:

• Textzeichenfolgen werden aus dem Code in externe Dateien ausgelagert, anstatt fest codiert zu sein.
• UTF-8-Kodierung, sodass Sonderzeichen und nicht-lateinische Schriften korrekt dargestellt werden.
• Layout, das nicht davon ausgeht, dass Text immer von links nach rechts gelesen wird
• Datums-, Zahlen- und Währungsformate werden als Variablen und nicht als feste Annahmen behandelt.

Wenn es gut gemacht ist, ist i18n wie Wasser für einen Goldfisch, unsichtbar und unbemerkt (im bestmöglichen Sinne).

l10n: Der Teil, der nie endet

Wenn i18n das Auto ist, dann ist l10n der Kraftstoff. Wenn Sie sich entscheiden, Französisch hinzuzufügen, lokalisieren Sie. Wenn man Japanisch hinzufügt, lokalisiert man erneut. Es handelt sich nicht um eine abgeschlossene Phase, sondern um einen sich wiederholenden Prozess. Deshalb benötigt die Lokalisierung einen eigenen Workflow, einen eigenen Verantwortlichen und ein eigenes Toolset, die von der Entwicklung getrennt bleiben.

Ein Team kann ein wirklich internationalisiertes Produkt auf den Markt bringen und trotzdem im Bereich der Lokalisierung hinter den Erwartungen zurückbleiben, denn Lokalisierung bedeutet nicht einfach nur, Wörter auszutauschen. Dazu gehören auch Redewendungen und Formalitäten, Bildtausch und sogar subtile Farbverschiebungen!

Wo der Unterschied auf einer Live-Seite sichtbar wird

Die Formatprobleme sind der einfachste Weg, um zu sehen, dass i18n und l10n unabhängig voneinander funktionieren.

Nehmen wir zum Beispiel Zahlen. In den USA schreibt man eintausend Dollar und fünfzig Cent als 1,000.50. In weiten Teilen Europas wird der gleiche Wert als 1.000,50 geschrieben, wobei Komma und Punkt vertauscht sind. Ein Währungsfeld zeigt 99.00 US-Dollar und 99,00 Euro in Deutschland an, die Symbole befinden sich auf gegenüberliegenden Seiten. Die Termine sind noch weiter auseinander. 03/04/2026 Das bedeutet, dass in den USA der 4th . März und fast überall sonst der 3rd . April ist. Aus diesem Grund gibt es ISO 8601 (YYYY-MM-DD), um die Mehrdeutigkeit zu umgehen, anstatt in jedem Land einzeln darüber zu streiten. Auch Sprachcodes folgen einem Standard: ISO 639-1 weist zweistellige Codes wie de, ja und pt zu, sodass ein Gebietsschemasystem über eine stabile Kennung verfügt, mit der es arbeiten kann, anstatt anhand eines Ländernamens raten zu müssen.

Die Texterweiterung ist das, was Entwicklerteams am meisten unterschätzen. Phrases eigene i18n -Dokumentation Als anschauliches Beispiel dient eine Schuhgröße: Eine britische Größe 10 entspricht einer europäischen Größe 38, und eine US-Größe 38 entspricht einer völlig anderen europäischen Größe 6. Übersetzt man nun eine UI-Beschriftung auf die gleiche Weise, erhält man die gleiche Art von Wortlängenabweichung. Deutsche und finnische Texte sind regelmäßig 20 bis 35 Prozent länger als der englische Ausgangstext. Deshalb passt ein Button mit der Bezeichnung „Submit“ gut, „Zur Kasse gehen“ hingegen nicht, es sei denn, das Layout wurde mit flexiblen Containern erstellt. Arabisch und Hebräisch, als RTL-Sprachen (von rechts nach links geschrieben), bringen ein ganz anderes Problem mit sich: Das gesamte Layout spiegelt sich, und nicht nur die Textrichtung.

Keines dieser Probleme lässt sich zum Zeitpunkt der Übersetzung zufriedenstellend lösen. Das Problem sollte im Code gelöst sein, daher mein Drängen darauf, dass Schritt i18n ordnungsgemäß ausgeführt wird, bevor Schritt l10n beginnt.

Der Arbeitsablauf: Bauen Sie Ihr Haus auf einem starken Fundament

In einem gesunden Umfeld findet die Internationalisierung einmalig statt, und die Lokalisierung wiederholt sich anschließend unbegrenzt. Sie extrahieren Ihre Zeichenketten, legen Ihre Kodierung fest und erstellen flexible Layouts in einem einzigen Arbeitsgang. Dann lokalisieren Sie ins Französische. Später wird dies ins Japanische lokalisiert. Später dann Arabisch, ohne die zugrundeliegende Architektur erneut anzutasten, denn die Architektur war von Anfang an darauf ausgelegt, mit jedem beliebigen Ort zurechtzukommen.

Das Problem bei Teams ist, dass sie den ersten Schritt überspringen und versuchen, ihn im zweiten Schritt nachträglich einzufügen. Das ist der Fall, wenn man fest codierte Zeichenketten drei Komponenten tief vergraben hat und Datumsauswahlfelder nur das Format MM/TT/JJJJ verstehen. Letztendlich entwickelt sich das Übersetzungsprojekt zu einer Umstrukturierung, die niemand eingeplant hatte.

Müssen wir unsere gesamte Architektur neu aufbauen?

Ich habe schon an genügend Verkaufsgesprächen teilgenommen, um zu wissen, worüber die meisten Teams besorgt sind: „Müssen wir unsere gesamte Infrastruktur neu aufbauen, um das richtig zu machen?“ Die Annahme hierbei ist, dass, wenn ihre Website nicht von Anfang an internationalisiert wurde, eine korrekte Lokalisierung eine komplette Überarbeitung und Neugestaltung erfordert. Meistens lautet die Antwort: Nein.

Wenn die Lokalisierungsschicht auf der bestehenden Website und nicht innerhalb ihrer Codebasis ausgeführt wird, ist kein Neuaufbau erforderlich. Ich gebe hier ein kleines Geheimnis preis, aber genau so funktioniert Bablic . In den meisten Fällen wird ein leichtgewichtiges JavaScript-Snippet im Browser des Besuchers ausgeführt und tauscht den übersetzten Text zum Zeitpunkt der Anfrage gegen den richtigen Text in der entsprechenden Sprache aus, ohne die Ursprungsseite (den ursprünglichen Server, auf dem die Seite tatsächlich liegt) zu crawlen oder neu aufzubauen.

Die damit einhergehende Sorge um die Performance besteht üblicherweise darin, dass ein browserseitiger Ansatz das Laden eines gesamten Übersetzungskorpus bei jedem Seitenaufruf erfordert. Wenn Ihnen das wirklich wichtig ist, dann wählen Sie ein Tool, das eine Zwischenspeicherung der Übersetzungsinformationen bietet. Dadurch wird bereits übersetzter Text gespeichert, sodass der Browser nicht bei jeder Anfrage die Übersetzungs-API erneut aufruft.

Sie werden jetzt wahrscheinlich sagen: „Aber mein Produkt ist eine native App mit tief verschachtelter bedingter Logik und ohne Trennung zwischen Zeichenketten und Code“...blablabla. Das ist ein technisches Problem, das sich nicht durch eine browserseitige Schicht lösen lässt! Suchen Sie in diesem Fall nach einer Lösung mit einem SDK. Doch für Marketing-Websites und E-Commerce-Shops, deren Seiten einmal in einer Sprache erstellt wurden und nun fünf Märkte bedienen müssen, ist die Annahme einer Re-Architektur im Allgemeinen falsch.

Nicht ohne Kontext übersetzen

Eine Seite kann alle i18n Prüfungen bestehen (die Währung stimmt, das Datumsformat stimmt) und trotzdem für die Person, an die sie sich richtet, offensichtlich fremd klingen. Kunden merken, wenn eine Botschaft ihr Ziel verfehlt oder nur geringfügig falsch ist, und diejenigen, die das bemerken, konvertieren nicht. Das ist das Uncanny Valley, das ich vorhin erwähnt habe, und das ist ein echter Konversionskiller.

Das Verstehen und Durchsetzen des Kontextes trägt zur Lösung dieses Problems bei. Erstens, durch die Kontrolle über spezifische Begriffe, wie Ihren Markennamen und die Eigennamen Ihres Produkts, stellen Sie sicher, dass wichtige Formulierungen immer gleich wiedergegeben werden, unabhängig davon, was eine maschinelle Übersetzungssoftware standardmäßig verwendet. Ein Glossar, mit dem Sie diese Entscheidungen festschreiben können, sorgt dafür, dass eine übersetzte Seite nach Ihrer Marke klingt und nicht nach einer generischen Version, die sich an niemanden im Besonderen richtet.

Die zweite Möglichkeit besteht darin, sich die übersetzte Seite anzusehen und Fehler direkt vor Ort zu korrigieren, ohne die Zielsprache fließend beherrschen zu müssen, um unpassende Formulierungen zu erkennen. Ein Editor im Kontext zeigt Ihnen die live übersetzte Seite und ermöglicht Ihnen die direkte Bearbeitung. Das bedeutet, dass ein spanischsprachiger Kollege die Ausgabe in wenigen Minuten stichprobenartig überprüfen kann, anstatt dass ein Übersetzer alles anhand einer Tabellenkalkulation neu erstellen muss.

Für die meisten Seiten ist maschinelle Übersetzung (MT) ein sinnvoller Ausgangspunkt. Bablic verwendet standardmäßig Google Translate und DeepL, die den ersten Entwurf in einer Geschwindigkeit erstellen, die kein menschliches Team erreichen kann. Für die meisten Unternehmen, mit denen wir sprechen, reichen diese Suchmaschinen in Kombination mit einem Glossar und einer Stichprobenprüfung durch einen kontextbezogenen Redakteur aus, um das Gefühl zu vermitteln, dass die Website wirklich lokalisiert ist.

FAQ