i18n vs. l10n: Was ist der Unterschied zwischen Internation…

i18n vs. l10n: Was ist der Unterschied zwischen Internationalisierung und Lokalisierung?

Wenn Sie jemals einem Projekt beigetreten sind, das global ausgerichtet ist, und jemanden sagen hörten "wir müssen i18n und l10n machen", sind Sie nicht allein, wenn Sie sich fragen, ob diese beiden Begriffe Synonyme, Gegensätze oder einfach Jargon für dieselbe Aufgabe mit unterschiedlicher Verpackung sind.

Sie sind keines davon. Internationalisierung und Lokalisierung sind zwei unterschiedliche Disziplinen, die in einer bestimmten Reihenfolge stattfinden, unterschiedliche Teams involvieren und unterschiedliche Arten von Artefakten erzeugen. Sie zu verwechseln — oder sie in der falschen Reihenfolge durchzuführen — ist einer der teuersten Fehler, den ein Produktteam beim Eintritt in neue Märkte machen kann.

Dieser Artikel erklärt beide Begriffe klar, behandelt das verwandte Vokabular, das die Branche verwendet, und gibt Ihnen praktische Checklisten für die technische und die inhaltliche Seite des Prozesses.

TL;DR / Wesentliche Erkenntnisse

i18n steht für Internationalisierung (zwischen dem "i" und dem "n" befinden sich 18 Buchstaben). Es ist die technische Arbeit, die ein Produkt in die Lage versetzt, mehrere Sprachen und Regionen zu unterstützen.
l10n steht für Lokalisierung (10 Buchstaben zwischen dem "l" und dem "n"). Es ist die Inhalts- und Anpassungsarbeit, die ein Produkt dazu bringt, tatsächlich eine bestimmte Sprache und Kultur zu sprechen.
i18n ist eine einmalige Investition in die Technik; l10n ist ein wiederholender operativer Prozess, der einmal pro Ziel-Locale durchgeführt wird.
i18n muss immer vor l10n abgeschlossen sein. Es umgekehrt zu tun erzeugt Nacharbeit, die fast immer teurer ist als es beim ersten Mal richtig zu machen.
Der übergeordnete Begriff ist g11n (Globalisierung), der sowohl i18n als auch l10n zusammen mit der Marktstrategie umfasst.

Was ist Internationalisierung (i18n)?

Internationalisierung ist der Prozess der Gestaltung und Entwicklung eines Produkts, sodass es an verschiedene Sprachen, Regionen und kulturelle Konventionen angepasst werden kann, ohne dass bei jeder Hinzufügung eines neuen Locale Änderungen am Quellcode erforderlich sind.

Das Numeronym i18n stammt vom Wort selbst: "internationalization" hat 18 Buchstaben zwischen seinem ersten "i" und seinem letzten "n". Da das vollständige Wort in technischer Dokumentation wiederholt zu schreiben umständlich wurde, übernahm die Branche die Kurzform. Sie werden i18n austauschbar mit "internationalisation" (britische Schreibweise) verwenden — beide beziehen sich auf dieselbe technische Disziplin.

Internationalisierung ist grundsätzlich eine technische Angelegenheit. Die Menschen, die diese Arbeit erledigen, sind Softwareingenieure, und das Ergebnis ist Infrastruktur: Code, Konfiguration und Architekturentscheidungen, die die Grundlage schaffen, auf der später Übersetzungen aufgebaut werden können.

Was i18n-Engineering umfasst

String-Externalisierung ist der grundlegendste Schritt. Jedes benutzergerichtete Textelement — Schaltflächenbeschriftungen, Fehlermeldungen, Tooltips, E-Mail-Betreffzeilen, Benachrichtigungstexte — muss aus dem Quellcode entfernt und in Ressourcendateien (wie .json-, .po-, .resx- oder .yaml-Dateien) verschoben werden. Ein fest codierter String wie <button>Submit</button> in einer React-Komponente kann nicht übersetzt werden, ohne den Quellcode zu berühren. Ein externalisierter String wie <button>{t('form.submit')}</button> kann durch Aktualisierung einer Ressourcendatei und Neudeployment übersetzt werden, ohne dass eine Codeänderung erforderlich ist.

Unicode und Zeichenkodierung müssen auf jeder Ebene des Stacks korrekt gehandhabt werden. Das W3C empfiehlt UTF-8 als Zeichenkodierung für alle Webinhalte nachdrücklich, da es jedes Skript im Unicode-Standard abdeckt — Latein, Kyrillisch, Arabisch, CJK (Chinesisch, Japanisch, Koreanisch) und Tausende andere. [^1] Ein Produkt, das Daten in einer Legacy-Kodierung wie Latin-1 speichert, wird Zeichen beschädigen, sobald ein Benutzer einen japanischen Namen oder eine arabische Adresse eingibt.

Datums-, Zeit-, Zahlen- und Währungsformatierung variiert erheblich zwischen Locales. Das Datum "03/04/2026" bedeutet den 4. März in den USA und den 3. April in den meisten europäischen Ländern. Die Zahl "1.000" bedeutet eintausend in Deutschland und eins (mit drei Dezimalstellen) in den USA. Das Unicode Common Locale Data Repository (CLDR) definiert die Formatierungsregeln für über 900 Locales. [^2] Ein internationalisiertes Produkt verwendet locale-bewusste Formatierungsfunktionen — wie Intl.DateTimeFormat und Intl.NumberFormat in JavaScript — anstatt Formatstrings manuell zu erstellen.

Pluralisierungsregeln unterscheiden sich zwischen Sprachen auf nicht offensichtliche Weise. Englisch hat zwei Pluralformen (1 Element, 2 Elemente). Arabisch hat sechs. Russisch hat drei, mit komplexen Regeln darüber, welche Form auf welche Zahlen angewendet wird. Eine i18n-Bibliothek muss die CLDR-Pluralregeln unterstützen, damit Übersetzungsteams die korrekte Anzahl von Pluralvarianten pro Sprache bereitstellen können, ohne dass das Technikteam für jede Sprache benutzerdefinierte Logik schreiben muss.

Rechts-nach-links (RTL) Layout-Unterstützung ist für Arabisch, Hebräisch, Persisch und Urdu erforderlich — Sprachen, die von rechts nach links gelesen werden. Das bedeutet, dass die Benutzeroberfläche gespiegelt werden muss: Navigation wechselt auf die rechte Seite, Textausrichtung wird umgekehrt, Richtung implizierende Icons (Pfeile, Breadcrumbs) werden umgekehrt, und CSS-Layout-Eigenschaften müssen logische Werte verwenden (margin-inline-start statt margin-left), damit der Browser das Layout basierend auf dem Dokumentrichtungs-Attribut automatisch spiegeln kann.

Locale-bewusstes Routing bestimmt, wie Locale-Bezeichner in URLs erscheinen. Die beiden gängigen Konventionen sind Unterverzeichnisse (better-i18n.com/fr/pricing) und Subdomains (fr.better-i18n.com). Das W3C empfiehlt die Verwendung von Sprach-Tags basierend auf BCP 47 (z.B. en, en-US, pt-BR, zh-Hant) für die Locale-Identifikation. [^3] Die Routing-Schicht muss die bevorzugte Locale des Benutzers erkennen, den richtigen Inhalt bereitstellen und den korrekten Content-Language HTTP-Header und hreflang-Attribute für Suchmaschinen-Crawler zurückgeben.

Keine verketteten Strings ist eine Regel, die besondere Betonung verdient. Code wie "Your order of " + count + " items has shipped" ist eine Verkettung, die nicht korrekt übersetzt werden kann, weil die Wortreihenfolge in der Zielsprache völlig anders sein kann. Korrektes i18n verwendet Meldungsformat-Strings mit benannten Platzhaltern: "Your order of {count} items has shipped" — wobei der Übersetzer den vollständigen Satz erhält und den Platzhalter dort positionieren kann, wo die Zielsprache es erfordert.

Was ist Lokalisierung (l10n)?

Lokalisierung ist der Prozess der Anpassung eines Produkts — seiner Texte, Bilder, des Tons und der Funktionalität — für ein bestimmtes Ziel-Locale. Wenn Internationalisierung den Behälter erstellt, füllt Lokalisierung ihn.

Das Numeronym l10n folgt demselben Muster: "localization" hat 10 Buchstaben zwischen seinem "l" und seinem "n".

Lokalisierung ist primär eine inhaltliche und kulturelle Angelegenheit. Die Menschen, die diese Arbeit erledigen, sind Übersetzer, Lokalisierungsingenieure, Kulturberater und Rechtsexperten. Das Ergebnis sind locale-spezifische Assets: übersetzte String-Dateien, angepasste Bilder, regionsspezifische rechtliche Texte und locale-getestete Builds.

Was l10n-Inhaltsarbeit umfasst

Übersetzung ist der sichtbarste Teil der Lokalisierung. Jeder String, der während i18n externalisiert wurde, muss in die Zielsprache übersetzt werden — nicht Wort für Wort, sondern idiomatisch. Eine gute Übersetzung bewahrt Bedeutung, Ton und Absicht. Maschinelle Übersetzung (MT) hat sich mit großen Sprachmodellen erheblich verbessert, aber professionelle menschliche Überprüfung bleibt wichtig für Marketingtexte, rechtliche Inhalte und jeden Text, bei dem die Markenstimme wichtig ist.

Kulturelle Anpassung geht über wortgetreue Übersetzung hinaus. Bilder, Farbgebung, Humor und Metaphern tragen alle kulturelles Gewicht. Ein Daumen-hoch-Symbol ist in vielen westlichen Kulturen positiv, aber in Teilen des Nahen Ostens anstößig. Ein Foto eines Händedrucks muss möglicherweise in Märkten, in denen physische Kontaktnormen unterschiedlich sind, durch eine andere Geste ersetzt werden. Datumsbeispiele, Namensformate (Vor- vs. Nachname-Reihenfolge), Adressformate und Telefonnummernformate erfordern alle locale-spezifische Behandlung.

Rechtliche und regulatorische Compliance variiert je nach Markt. Die EU verlangt explizite Cookie-Zustimmung gemäß DSGVO und ePrivacy-Richtlinie. Brasilien hat die LGPD. Kalifornien hat den CCPA. Steueranzeigeregeln, Preisoffenlegungsanforderungen und erforderliche rechtliche Hinweise unterscheiden sich je nach Jurisdiktion. Lokalisierungsteams sind dafür verantwortlich, diese Anforderungen pro Zielmarkt zu identifizieren und sicherzustellen, dass das Produkt sie erfüllt.

Locale-spezifisches Testen validiert, dass das übersetzte Produkt tatsächlich korrekt im Kontext funktioniert. Dies umfasst die Überprüfung, dass übersetzte Strings in ihre UI-Container passen (deutsche Strings sind typischerweise 30–40 % länger als ihre englischen Entsprechungen), dass RTL-Layouts korrekt dargestellt werden, dass locale-spezifische Datums- und Zahlenformate wie erwartet angezeigt werden, und dass locale-spezifische rechtliche Inhalte vorhanden sind.

Vergleichstabelle: i18n vs. l10n

Dimension	Internationalisierung (i18n)	Lokalisierung (l10n)
Wer macht es	Softwareingenieure	Übersetzer, Lokalisierungsingenieure, Kulturberater
Wann es passiert	Vor jeder locale-spezifischen Arbeit; einmal pro Produkt	Nach Abschluss von i18n; einmal pro Ziel-Locale
Was es umfasst	String-Externalisierung, Unicode, Formatierung, RTL, Routing	Übersetzung, kulturelle Anpassung, rechtliche Compliance, Locale-Tests
Primäre Ausgabe	Code, Architektur, Ressourcedateistruktur	Übersetzte String-Dateien, angepasste Assets, Locale-Builds
Verwendete Tools	i18n-Bibliotheken (next-intl, i18next, ICU), CLDR, Unicode	TMS-Plattformen, CAT-Tools, MT-Engines, QA-Tools
Kostenprofil	Fixe Vorab-Engineering-Kosten, einmalig bezahlt	Pro-Locale-Kosten, wiederholend mit jedem Inhalts-Update
Umkehrbarkeit	Schwer im Nachhinein nachzurüsten	Unkompliziert zu aktualisieren oder zu ersetzen
Geschäftstreiber	Technische Bereitschaft	Markteintritt und Umsatz

Die richtige Reihenfolge: Immer zuerst i18n, dann l10n

Dies ist keine Präferenz — es ist eine harte Abhängigkeit. Lokalisierung kann ohne funktionierende i18n-Infrastruktur nicht stattfinden, und der Versuch von l10n, bevor i18n abgeschlossen ist, erzeugt Verschwendung, die sich schnell vervielfacht.

Was schiefläuft, wenn Sie die Reihenfolge umkehren:

Stellen Sie sich ein Entwicklungsteam vor, das ein Produkt auf Englisch ausliefert und dann, wenn die Entscheidung getroffen wird, in den deutschen Markt einzutreten, die Codebasis einem Übersetzungsanbieter übergibt. Der Übersetzer öffnet den Code und findet fest codierte englische Strings in den JSX-Komponenten, SQL-Abfragen, die nur englische Feldwerte zurückgeben, ein Datumsformatierungs-Hilfsprogramm, das immer MM/DD/YYYY ausgibt, und ein CSS-Layout, das durchgängig margin-left und text-align: left verwendet, ohne RTL-Überlegungen.

Der Übersetzungsanbieter kann mit dieser Codebasis nichts Nützliches anfangen. Das Technikteam muss nun String-Externalisierung in einem ausgereiften Produkt nachrüsten — Hunderte von Komponenten berühren, Datenbankschemas umstrukturieren, Formatierungs-Hilfsprogramme neu schreiben und jedes Layout auf RTL-Sicherheit prüfen. Diese Nachrüstungsarbeit ist nicht nur additiv; sie birgt das Risiko, Regressionen in einem Produktionssystem einzuführen. Der deutsche Launch verzögert sich um Monate, und die Kosten sind ein Vielfaches der vorgelagerten i18n-Investition.

Ein zweites Fehlermuster ist partielles i18n. Ein Team externalisiert Strings im Frontend, vergisst aber, Pluralisierung korrekt zu handhaben. Der Übersetzer liefert deutsche Pluralformen, aber der Code verwendet immer nur die Singularform, weil das Technikteam count + " Artikel" statt eines korrekten Meldungsformats geschrieben hat. Das Ergebnis ist grammatikalisch falsches Deutsch in der Produktion — sichtbar für jeden Benutzer in diesem Markt.

Ein drittes Fehlermuster sind locale-spezifische Features, die hinzugefügt werden, bevor Routing internalisiert ist. Ein Team fügt einen französischsprachigen Blog-Bereich hinzu, indem es manuell ein /fr/-Verzeichnis erstellt, ohne ein korrektes Locale-Routing-System aufzubauen. Wenn sie später Italienisch hinzufügen möchten, müssen sie das Routing vollständig umstrukturieren, und die französischen URLs können brechen und im Laufe der Zeit aufgebaute SEO-Signale beschädigen.

Die praktische Regel lautet: i18n ist eine Voraussetzung. Definieren und implementieren Sie Ihr Locale-Routing, Ihre String-Externalisierung, Ihre Formatierungs-Hilfsprogramme und Pluralisierungsunterstützung, bevor Sie eine einzige Übersetzung in Auftrag geben. Sobald die Infrastruktur vorhanden ist, ist das Hinzufügen jedes neuen Locale ein vorhersehbarer, begrenzter Vorgang.

i18n-Checkliste für Entwickler

Verwenden Sie diese Checkliste beim Aufbau oder der Prüfung von Internationalisierungsinfrastruktur.

String-Externalisierung abgeschlossen: Jeder benutzergerichtete String ist in einer Ressourcendatei gespeichert, nicht im Quellcode fest codiert. Dies schließt Fehlermeldungen, Validierungsmeldungen, E-Mail-Templates und Meta-Tags ein.
UTF-8-Kodierung durchgesetzt: Datenbankspalten verwenden UTF-8 (oder utf8mb4 in MySQL), HTTP-Antworten deklarieren charset=utf-8, und Datei-I/O verwendet UTF-8 durchgehend.
Locale-bewusste Datums- und Zeitformatierung: Datumsangaben und Uhrzeiten werden mit locale-bewussten Funktionen (z.B. Intl.DateTimeFormat) formatiert und als UTC gespeichert, wobei das Locale nur in der Anzeigeschicht angewendet wird.
Locale-bewusste Zahlen- und Währungsformatierung: Zahlen und Währungswerte werden mit Intl.NumberFormat oder einem Äquivalent formatiert. Währungssymbole sind nicht fest codiert.
Pluralisierung über CLDR-Regeln behandelt: Die i18n-Bibliothek unterstützt CLDR-Pluralkategorien (null, eins, zwei, wenige, viele, andere) und Übersetzer können Varianten für jede Kategorie bereitstellen.
Keine verketteten Strings: Alle benutzergerichteten Strings, die Variablen enthalten, verwenden benannte Platzhalter innerhalb einer einzelnen übersetzbaren Meldung. Kein String wird durch Verkettung von übersetzten Fragmenten aufgebaut.
RTL-Layout-Unterstützung: CSS verwendet logische Eigenschaften. Das dir-Attribut wird dynamisch auf dem <html>-Element gesetzt. UI-Komponenten werden mit RTL-Locales getestet.
Locale-Routing implementiert: URLs folgen einer einheitlichen Locale-Konvention (z.B. /en/, /fr/). Die Routing-Schicht erkennt und verhandelt Locales aus Accept-Language-Headern und Benutzerpräferenzen.
hreflang-Tags vorhanden: Jede Seite deklariert <link rel="alternate" hreflang="..."> Tags für alle verfügbaren Locale-Varianten, einschließlich x-default.
Locale-Bezeichner folgen BCP 47: Sprach-Tags verwenden das IETF BCP 47-Format (z.B. en-US, pt-BR, zh-Hant) statt benutzerdefinierter oder inkonsistenter Bezeichner.

l10n-Checkliste für Content-Teams

Verwenden Sie diese Checkliste bei der Planung und Durchführung eines Lokalisierungsprojekts für ein neues Ziel-Locale.

Übersetzungsworkflow etabliert: Ein Translation Management System (TMS) oder strukturierter Überprüfungsprozess ist vorhanden. Quell-Strings sind versionskontrolliert und Änderungsbenachrichtigungen erreichen das Übersetzungsteam.
Übersetzer-Briefing abgeschlossen: Übersetzer haben einen Stilguide, ein Glossar produktspezifischer Begriffe, Ton-der-Stimme-Leitlinien und Kontext (Screenshots oder Zugang zur Staging-Umgebung) für jeden String erhalten.
Maschinelle Übersetzung von Menschen überprüft: Jeder maschinell übersetzte Inhalt wurde von einem qualifizierten menschlichen Übersetzer nachbearbeitet, insbesondere für Marketingtexte, rechtliche Texte und benutzergerichtete Fehlermeldungen.
Kulturelle Überprüfung durchgeführt: Bilder, Farbwahl, Icons und Beispiele wurden von jemandem mit kulturellem Wissen über den Zielmarkt überprüft. Möglicherweise anstößige oder verwirrende Inhalte wurden angepasst.
Rechtliche und regulatorische Anforderungen identifiziert: Das Team hat festgestellt, welche Datenschutzhinweise, Cookie-Hinweise, rechtliche Haftungsausschlüsse und regulatorische Anforderungen auf dem Zielmarkt gelten, und hat locale-spezifische Versionen erstellt.
String-Länge in UI getestet: Übersetzte Strings wurden in der tatsächlichen UI im Ziel-Locale überprüft. Abschneidung, Überlauf und Layout-Fehler wurden identifiziert und behoben.
Locale-spezifische Formate verifiziert: Datumsangaben, Zahlen, Adressen, Telefonnummern und Postleitzahlen werden alle im Format angezeigt, das Benutzer im Ziel-Locale erwarten.
Funktionelles Testen abgeschlossen: Das Produkt wurde im Ziel-Locale von Ende zu Ende getestet — einschließlich Checkout-Flows, Formularvalidierungsmeldungen, E-Mail-Benachrichtigungen und locale-spezifischen rechtlichen Flows.

FAQ

Ist i18n dasselbe wie Übersetzung?

Nein. Übersetzung (t9n) ist eine Teilmenge der Lokalisierung (l10n), und Lokalisierung ist eine nachgelagerte Aktivität, die davon abhängt, dass Internationalisierung (i18n) zuerst abgeschlossen ist. i18n ist die technische Arbeit, die Übersetzung möglich macht. Übersetzung ist der Akt, Text von einer Sprache in eine andere zu konvertieren. Die beiden sind verwandt, aber unterschiedlich — Sie können ohne i18n-Infrastruktur nicht effektiv übersetzen, aber das Abschließen von i18n bedeutet nicht, dass irgendeine Übersetzung erfolgt ist.

Kann ein Produkt internationalisiert, aber nicht lokalisiert sein?

Ja, und das ist ein häufiger Zwischenzustand. Ein Produkt, das seine Strings externalisiert, locale-bewusstes Routing implementiert und RTL-Unterstützung aufgebaut hat, ist vollständig internationalisiert — aber wenn keine übersetzten Ressourcendateien erstellt wurden, operiert es effektiv nur im Standard-Locale. Die Infrastruktur ist bereit für die Lokalisierung, aber es wurde noch keine Lokalisierung geliefert. Dies ist der korrekte Zustand, in dem man sein sollte, bevor Übersetzungsarbeit in Auftrag gegeben wird.

Haben die Numeronyme i18n und l10n offiziellen Status?

Sie sind weit verbreitete Branchenkonventionen eher als formale Standards. Die W3C Internationalization Activity verwendet "i18n" in all ihren veröffentlichten Spezifikationen und Arbeitsgruppendokumentationen. Die Localization Industry Standards Association (LISA), die das GILT-Framework entwickelt hat, verwendete "l10n" konsequent vor ihrer Auflösung. Beide Begriffe werden branchenweit universell verstanden.

Was ist der Unterschied zwischen l10n und kultureller Anpassung?

Kulturelle Anpassung ist eine Komponente von l10n, keine separate Disziplin. Lokalisierung umfasst Übersetzung, kulturelle Anpassung, rechtliche Compliance und locale-spezifisches Testen. Einige Organisationen verwenden "Transkreation", um Fälle zu beschreiben, in denen Marketinginhalte für einen Zielmarkt wesentlich neu geschrieben werden, anstatt übersetzt zu werden — dies ist eine aufwandsintensive Form der kulturellen Anpassung, bei der der Quelltext eher als Absichtsführung dient als als wörtliche Vorlage.

Wie beeinflusst i18n SEO?

Erheblich. Eine korrekt internationalisierte Website verwendet hreflang-Annotationen, um Suchmaschinen mitzuteilen, welche URL welche Sprache und Region bedient, verwendet BCP 47-Locale-Bezeichner konsistent, sendet den korrekten Content-Language HTTP-Header und vermeidet Duplicate-Content-Probleme, indem sichergestellt wird, dass jedes Locale eine kanonische URL hat. Googles Leitlinien zum internationalen Targeting stützen sich auf diese Signale, um Benutzern in jedem Markt die korrekte locale-spezifische Seite bereitzustellen. Eine i18n-Implementierung, die das Routing oder die hreflang-Konfiguration falsch macht, kann dazu führen, dass das falsche Locale in Suchergebnissen rankt — oder gar kein Locale.

Fazit

Internationalisierung und Lokalisierung sind komplementäre Disziplinen, keine austauschbaren Begriffe. i18n ist das technische Fundament — die Engineering-Arbeit, die Sprach- und Locale-Belange aus dem Quellcode abstrahiert und in konfigurierbare, austauschbare Ressourcendateien überführt. l10n ist die Content-Operation, die dieses Fundament mit den übersetzten, kulturell angepassten und rechtlich konformen Inhalten füllt, die echte Benutzer in echten Märkten sehen werden.

Die Reihenfolge ist wichtig: Internationalisierung kommt immer zuerst. Sobald die Infrastruktur vorhanden ist, wird jedes neue Locale ein begrenzter, wiederholbarer Vorgang und keine Quelle von Engineering-Nacharbeit.

Für Teams, die beide Seiten davon ohne separate Tools für jedes Anliegen implementieren möchten, übernehmen Plattformen wie Better i18n sowohl die i18n-Infrastruktur (SDK, Locale-Routing) als auch den l10n-Workflow (KI-Übersetzung, CDN-Lieferung) in einer einzigen Plattform — was den Koordinationsaufwand zwischen der Engineering- und der Content-Seite des Prozesses reduziert.

Ob Sie ein neues Produkt mit globalen Ambitionen aufbauen oder ein bestehendes für neue Märkte anpassen — die i18n-vs.-l10n-Unterscheidung zu verstehen ist der erste Schritt dazu, beides gut zu machen.

Referenzen

[^1]: W3C Internationalization Working Group. "Character encodings: Essential concepts." W3C. https://www.w3.org/International/articles/definitions-characters/

[^2]: Unicode Consortium. "Common Locale Data Repository (CLDR)." Unicode. https://cldr.unicode.org/

[^3]: W3C Internationalization Working Group. "Language tags in HTML and XML." W3C. https://www.w3.org/International/articles/language-tags/

[^4]: W3C Internationalization Working Group. "Localization vs. Internationalization." W3C. https://www.w3.org/International/questions/qa-i18n

[^5]: Internet Engineering Task Force. "Tags for Identifying Languages (BCP 47)." IETF RFC 5646. https://www.rfc-editor.org/rfc/rfc5646

[^6]: Unicode Consortium. "Plural Rules." Unicode CLDR. https://cldr.unicode.org/index/cldr-spec/plural-rules

i18n vs. l10n: Was ist der Unterschied zwischen Internationalisierung und Lokalisierung?