5.5 Internationalisierung und Lokalisierung

Überblick und Motivation

Internationalisierung (i18n) ist die Engineering-Arbeit, Software so zu bauen, dass sie an jede Sprache, Region, und Kultur angepasst werden kann, ohne den Code zu ändern. Lokalisierung (l10n) ist die Arbeit, die folgt: ein Produkt tatsächlich für ein spezifisches Gebietsschema anzupassen, durch Übersetzen von Text, Formatieren von Daten und Zahlen, Anpassen von Layout, und Berücksichtigen kultureller Erwartungen. Die beiden sind unterschiedlich. Internationalisierung geschieht einmal, in der Architektur. Lokalisierung geschieht viele Male, im Inhalt. Bekommen Sie die Architektur vorab richtig hin, und jede Lokalisierung ist günstig. Machen Sie sie falsch, und jede wird eine schmerzhafte, fehleranfällige Nachrüstung.

Für große Teams ist i18n eine grundlegende architektonische Entscheidung. Sie berührt jede Schicht: Datenspeicherung, String-Handhabung, Layout, und Inhaltspipelines. Wenn Sie sie nicht früh etablieren und durch geteilte Bibliotheken und Lint-Regeln durchsetzen, codieren Teams englische Strings fest, verketten übersetzte Fragmente, und nehmen lateinische Schriften an. Diese Schuld muss abgewickelt werden, bevor das Produkt in irgendeinen neuen Markt eintreten kann. Ein geteiltes i18n-Framework und Lokalisierungsarbeitsablauf erlauben Dutzenden Teams, ein Produkt in vielen Sprachen auszuliefern, ohne dass jedes die Sanitärinstallation neu erfindet.

Unternehmens- und Behördenrelevanz ist direkt. Multinationale Unternehmen müssen Kundinnen und Angestellte über Länder, Sprachen, und regulatorische Regime hinweg bedienen. Regierungen müssen sprachlich diverse Bevölkerungen bedienen. Viele Länder sind offiziell mehrsprachig, und viele sind gesetzlich verpflichtet, Dienste in mehreren Sprachen bereitzustellen, einschließlich von-rechts-nach-links-Schriften und indigenen oder Minderheitensprachen. Für öffentliche Dienste ist Sprachzugang eine Gerechtigkeits- und Rechtsfrage: eine Bürgerin, die die einzige verfügbare Sprache nicht lesen kann, wird dem Dienst effektiv verweigert.

Kernprinzipien

Internationalisieren Sie die Architektur einmal; lokalisieren Sie den Inhalt viele Male.
Codieren Sie nutzerzugewandten Text nie fest; externalisieren Sie alle Strings in verwaltete Ressourcen.
Nutzen Sie überall Unicode (UTF-8); nehmen Sie an, dass Text in jeder Schrift sein kann.
Verketten Sie übersetzte Fragmente nie; Grammatik und Wortreihenfolge unterscheiden sich nach Sprache.
Planen Sie für Textexpansion, von-rechts-nach-links-Schriften, und komplexe Plural- und Genus-Regeln.
Formatieren Sie Daten, Zahlen, Währungen, und Namen nach Gebietsschema, nicht nach Code.
Trennen Sie übersetzbaren Inhalt von Code, damit Übersetzerinnen nie Quellcode berühren.
Lokalisierung ist kulturell, nicht nur sprachlich: Farben, Bildsprache, und Beispiele zählen.

Empfehlungen

Eine solide Internationalisierungsarchitektur bauen

Speichern und verarbeiten Sie allen Text durchgehend als Unicode (UTF-8) (Datenbank, APIs, und UI), damit jede Schrift darstellbar ist. Externalisieren Sie jeden nutzerzugewandten String in Ressourcendateien oder einen Nachrichtenkatalog, mit Bezeichner geschlüsselt, nie in Code oder Markup eingebettet. Repräsentieren Sie ein Gebietsschema als Sprache plus Region (und Schrift, wo nötig), damit Sie zum Beispiel die Varianten einer Sprache über Länder hinweg unterscheiden können. Halten Sie Formatierungslogik in einer gut getesteten Internationalisierungsbibliothek statt Datums-, Zahlen-, und Währungsformatierung von Hand zu rollen. Speichern Sie Daten in neutralen, eindeutigen Formen (UTC-Zeitstempel, ISO-Länder- und Währungscodes, Basiseinheiten) und formatieren Sie nur auf der Präsentationsschicht.

Sprachkomplexität korrekt handhaben

Nehmen Sie keine Textlänge an; lassen Sie großzügig Raum, weil Übersetzungen häufig weit länger als Englisch laufen, und gestalten Sie Layouts, die neu fließen statt abzuschneiden oder zu überlappen. Unterstützen Sie bidirektionale (von-rechts-nach-links) Schriften, indem Sie logische statt physische Layout-Eigenschaften nutzen und die Oberfläche wo angemessen spiegeln. Nutzen Sie die Pluralregeln des Gebietsschemas durch Ihre i18n-Bibliothek (Sprachen haben irgendwo zwischen einer und sechs Pluralformen) statt naive Singular/Plural-Logik. Handhaben Sie Genus und grammatische Übereinstimmung, wo die Sprache es fordert. Bauen Sie nie Sätze durch Verkettung; nutzen Sie vollständige, parametrisierte Nachrichtenvorlagen, damit Übersetzerinnen die Wortreihenfolge kontrollieren.

Einen Lokalisierungsarbeitsablauf und Übersetzungsverwaltung etablieren

Behandeln Sie Lokalisierung als kontinuierliche Pipeline, keinen Vor-Start-Stapel. Extrahieren Sie Strings automatisch, schieben Sie sie zu einem Übersetzungsverwaltungssystem, und ziehen Sie fertige Übersetzungen zurück, idealerweise integriert mit CI, damit neue Strings markiert werden und lokalisierte Versionen synchron bleiben. Geben Sie Übersetzerinnen Kontext: Screenshots, Beschreibungen, Zeichenbegrenzungen, und ein Glossar und Styleguide pro Sprache, um Terminologie und Ton konsistent zu halten. Nutzen Sie Übersetzungsspeicher, um vorherige Arbeit wiederzuverwenden und Kosten zu senken. Entscheiden Sie absichtlich, wo maschinelle Übersetzung akzeptabel ist (niedrigriskanter, hochvolumiger Inhalt) und wo menschliche Übersetzung und Prüfung gefordert sind (rechtlich, medizinisch, sicherheitsrelevant, markenkritisch). Pseudolokalisieren Sie früh, Strings durch verlängerte, akzentuierte Platzhalter ersetzend, um fest codierte Strings, Abschneidung, und Kodierungsfehler zu erwischen, bevor echte Übersetzung beginnt.

Formate, Kultur, und Inhalt lokalisieren, nicht nur Worte

Formatieren Sie Daten, Zeiten, Zahlen, Währungen, Adressen, Telefonnummern, und Namen pro Gebietsschema, lokale Konventionen respektierend (Datumsreihenfolge, Dezimal- und Gruppierungstrennzeichen, Währungsplatzierung, Namensreihenfolge). Passen Sie Bildsprache, Icons, Farben, Beispiele, und Metaphern an lokale kulturelle Bedeutung an, denn Symbole und Farben tragen unterschiedliche Konnotationen über Kulturen hinweg. Berücksichtigen Sie lokale rechtliche und regulatorische Inhaltsunterschiede. Unterscheiden Sie globale Konsistenz (Marke, Kernfunktionalität) von regionaler Anpassung (Inhalt, Beispiele, Compliance) und entscheiden Sie explizit, welche Elemente fest sind und welche flexen.

i18n als geteilte Infrastruktur verwalten

Stellen Sie eine geteilte i18n-Bibliothek, String-Externalisierungs-Lint-Regeln, und einen Standard-Gebietsschema-Auflösungsmechanismus bereit, damit Teams nicht versehentlich Text fest codieren können. Etablieren Sie Besitz der Lokalisierungspipeline und Glossare. Testen Sie in mehreren Gebietsschemata in CI, einschließlich eines von-rechts-nach-links-Gebietsschemas und eines Langtext-Pseudogebietsschemas, damit Regressionen automatisch erwischt werden.

Abwägungen: Vor- und Nachteile

Entscheidung	Vorteile	Nachteile
Von Tag eins internationalisieren	Günstiger späterer Markteintritt, keine Nachrüstung	Vorabkosten, selbst bevor irgendein zweites Gebietsschema gebraucht wird
i18n später nachrüsten	Kosten aufschieben, falls globaler Bedarf unsicher ist	Sehr teuer und riskant, fest codierte Annahmen abzuwickeln
Menschliche Übersetzung	Hohe Qualität, kulturell akkurat	Langsamer und kostspieliger
Maschinelle Übersetzung	Schnell, günstig, skaliert auf riesiges Volumen	Qualitäts- und Genauigkeitsrisiko; ungeeignet für hocheinsatzigen Inhalt
Kontinuierliche Lokalisierungspipeline	Gebietsschemata bleiben synchron, kein Start-Gedränge	Werkzeug- und Prozessinvestition
Tiefe kulturelle Anpassung pro Region	Bessere lokale Passung und Vertrauen	Mehr Inhaltsvarianten zu bauen und zu pflegen

Die zentrale Abwägung ist, wann in Internationalisierung zu investieren. i18n in ein Produkt voller fest codierter, verketteter, lateinisch annehmender Code nachzurüsten ist eine der teureren Formen technischer Schuld, die zu begleichen ist. Für jede Organisation mit plausiblen internationalen oder mehrsprachigen Ambitionen, was im Wesentlichen alle großen Unternehmen und mehrsprachigen Regierungen umfasst, ist es weit günstiger, die Architektur früh zu internationalisieren als nachzurüsten, auch wenn die Auszahlung aufgeschoben ist.

Fragen zur Diskussion mit Ihrem Team

Setzen wir String-Externalisierung mit Lint-Regeln durch, und läuft Pseudolokalisierung in CI, bevor irgendeine echte Übersetzung geschieht? Die Schuld, die Internationalisierung teuer macht (fest codierte englische Strings, verkettete Satzfragmente, lateinisch-schrift-annehmender Code), häuft sich still an, sofern Werkzeug sie nicht zum Commit-Zeitpunkt stoppt. Lint-Regeln, die fest codierten Nutzertext markieren, plus ein akzentuiertes Langtext-Pseudogebietsschema, das in CI läuft, erwischen Abschneidung, Überlappung, und Kodierungsfehler, während sie günstig zu beheben sind. Das ist, was Dutzenden Teams erlaubt, ein Produkt in vielen Sprachen auszuliefern, ohne dass jedes die Sanitärinstallation neu erfindet oder Annahmen später unter einem Termin abwickelt. Bringen Sie eine Suche nach fest codierten Strings und fragen Sie, ob irgendein Team heute versehentlich einen ausliefern könnte. Wenn nichts in der Pipeline es erwischen würde, ist das die zuerst zu schließende Lücke.
Wo speichern wir kanonische Daten, und ist Formatierung auf die Präsentationsschicht beschränkt? Zeitstempel als UTC zu speichern, Länder und Währungen als ISO-Codes, und Beträge in Basiseinheiten, bedeutet, dass jedes Gebietsschema sie am Rand korrekt formatieren kann, während in die Datenschicht gebackene Formatierungslogik Fehler produziert, die schmerzhaft abzuwickeln sind. Einigen Sie sich, dass Daten, Zahlen, Währungen, Adressen, und Namen nur bei Präsentation formatiert werden, durch eine gut getestete Bibliothek statt handgerollten Code. Das zählt für multinationale Unternehmen und mehrsprachige Regierungen, wo eine Bürgerin korrekte Datumsreihenfolge, Dezimaltrennzeichen, und Namensreihenfolge in ihrer eigenen Konvention sehen muss. Bringen Sie ein Beispiel eines Werts, den Ihr System bereits formatiert speichert, und verfolgen Sie, was bricht, wenn ein neues Gebietsschema ihn anders braucht. Wenn Daten und Präsentation verwickelt sind, entscheiden Sie, wie Sie sie entwirren, bevor Sie Gebietsschemata hinzufügen.
Wo genau ist maschinelle Übersetzung akzeptabel, und wie wird unsere Lokalisierungspipeline kontinuierlich statt stapelweise gehalten? Maschinelle Übersetzung ist schnell und günstig für niedrigriskanten, hochvolumigen Inhalt, aber ungeeignet für rechtlichen, medizinischen, sicherheitsrelevanten, oder markenkritischen Text, wo eine Fehlübersetzung echten Schaden verursacht, die Grenze muss also eine explizite Richtlinie sein, keine Pro-Team-Vermutung. Ebenso garantiert Lokalisierung als Vor-Start-Stapel zu behandeln ein Übersetzungsgedränge, während Strings automatisch zu extrahieren und durch ein Übersetzungsverwaltungssystem zu synchronisieren jedes Gebietsschema aktuell hält. Entscheiden Sie, wer die Pipeline, die Glossare, und das menschliche-Prüfung-Tor für hocheinsatzige Strings besitzt. Bringen Sie eine jüngste Veröffentlichung und fragen Sie, wie lange ihre neuen Strings brauchten, um in jeder Sprache zu erscheinen. Wenn Gebietsschemata zwischen Veröffentlichungen aus der Synchronisation driften, ist Ihre Pipeline ein verkleideter Stapel.
Testen wir automatisch ein von-rechts-nach-links-Gebietsschema und ein Langtext-Pseudogebietsschema, oder nehmen wir still lateinische Schriften und englisch-lange Layouts an? Bidirektionale (von-rechts-nach-links) Unterstützung und Textexpansion sind die Annahmen, die in einem neuen Markt am sichtbarsten brechen: gespiegelte Oberflächen, die nie gespiegelt wurden, und Buttons, die abschneiden, sobald Deutsch oder Finnisch vierzig Prozent länger als Englisch läuft. Der konkurrierende Zug ist Geschwindigkeit, denn auf logischen statt physischen Layout-Eigenschaften zu bauen und ein akzentuiertes Pseudogebietsschema in kontinuierliche Integration (CI) zu verdrahten kostet Aufwand, bevor irgendeine echte Kundin es braucht. Bringen Sie einen Screenshot Ihrer meistbesuchten Bildschirme, gerendert in einem von-rechts-nach-links-Gebietsschema und in einem verlängerten Pseudogebietsschema, und zählen Sie die Überlappungen, abgeschnittenen Beschriftungen, und feststeckenden Pfeile. Für ein multinationales Unternehmen oder eine Behörde, gesetzlich verpflichtet, eine von-rechts-nach-links- oder Minderheitensprache zu bedienen, ist ein Layout, das nicht spiegeln kann, kein kosmetischer Defekt, es ist ein Markt oder eine gesetzliche Pflicht, die Sie ohne einen Neubau nicht erfüllen können.
Welche Teile des Produkts sind global fest, und welche flexen nach Region, und wer hat die Autorität, das zu entscheiden? Lokalisierung ist kulturell, nicht nur sprachlich, Farben, Bildsprache, Beispiele, Anredeformen, und sogar welche Features angeboten werden, können sich also nach Markt unterscheiden, doch jede regionale Variante, die Sie erlauben, ist ein weiteres Artefakt, das für immer zu bauen, zu übersetzen, zu prüfen, und zu pflegen ist. Die Spannung ist zwischen lokaler Passung, die Vertrauen und Konversion aufbaut, und Konsistenz, die die Marke kohärent und die Pflegelast begrenzt hält. Bringen Sie eine konkrete Liste, was ein vorgeschlagenes neues Gebietsschema über übersetzte Strings hinaus ändern würde, und bepreisen Sie die laufende Instandhaltung jeder Variante, nicht nur ihren ersten Bau. In einem großen Unternehmen braucht diese Entscheidung eine benannte Besitzerin, damit regionale Teams das Produkt nicht ad hoc abspalten, und in Behörden muss sie rechtliche und Barrierefreiheits-Inhaltsregeln respektieren, die nach Rechtsprechung variieren und nicht optional sind.
Zu welchen Gebietsschemata verpflichten wir uns tatsächlich, wie halten wir Terminologie über sie hinweg konsistent, und welcher Beleg treibt diese Liste? Eine Sprache hinzuzufügen ist leicht zu versprechen und teuer zu erhalten, weil jede ein Glossar, einen Styleguide, menschliche Prüfung für hocheinsatzige Strings, und korrekte Plural- und Genus-Handhabung braucht, die naive Singular-oder-Plural-Logik in den meisten Sprachen falsch macht. Die konkurrierenden Überlegungen sind Reichweite gegen Kosten: ein Markt oder eine Bevölkerung, schlecht bedient, kann schlimmer sein als eine, die gar nicht bedient wird. Bringen Sie die Bevölkerung oder den Umsatz hinter jedem Kandidaten-Gebietsschema, die Pluralregel- und Formatierungsabdeckung, die Ihre Bibliothek dafür bietet, und wer sein Glossar besitzt. Für ein multinationales Unternehmen ist der Treiber adressierbarer Markt und Support-Kosten pro Sprache, während es für Behörden die gesetzliche Sprachzugangspflicht und Gerechtigkeit ist, quantifiziert durch die Anzahl der Einwohnerinnen, die nur in dieser Sprache transagieren können.

Branchenperspektive

Startup. Treffen Sie die günstigen architektonischen Wahlen an Tag eins und stoppen Sie dort: durchgehend UTF-8, jeder nutzerzugewandte String in einem Nachrichtenkatalog, und Daten, Zahlen, und Währungen, formatiert durch eine gebietsschema-bewusste Bibliothek. Das kostet fast nichts, während Sie in einer Sprache ausliefern, und spart eine Neuschreibung, wenn Ihre erste große Kundin eine zweite will. Stellen Sie keine Übersetzungspipeline auf oder unterstützen Sie Gebietsschemata, für die noch niemand bezahlt; halten Sie die Tür offen, nicht das ganze Haus möbliert.

Kleinunternehmen. Ohne Internationalisierungsspezialistin und mit engem Budget, stützen Sie sich auf die i18n-Features, die bereits in Ihrem Framework sind, und einen gehosteten Übersetzungsverwaltungsdienst statt selbst Pipelines zu bauen. Nutzen Sie maschinelle Übersetzung für niedrigriskanten, hochvolumigen Inhalt, und bezahlen Sie für menschliche Übersetzung nur, wo ein Fehler Sie eine Kundin kosten oder eine Regel verletzen würde, wie rechtlicher, sicherheitsrelevanter, oder Abrechnungstext. Verpflichten Sie sich nur zu einem Gebietsschema, wenn ein spezifischer Markt die laufenden Übersetzungs- und Prüfungskosten klar rechtfertigt.

Großunternehmen. Das Problem ist Governance über viele Teams: eine geteilte i18n-Bibliothek, Lint-Regeln, die fest codierte Strings ablehnen, eine kontinuierliche Lokalisierungspipeline mit Übersetzungsspeicher und Pro-Sprache-Glossaren, und Multi-Gebietsschema-CI, die ein von-rechts-nach-links- und ein Langtext-Pseudogebietsschema einschließt. Betreiben Sie Lokalisierung als geteilte Infrastruktur mit einer klaren Besitzerin, damit Gruppen aufhören, die Sanitärinstallation neu zu erfinden oder aus der Synchronisation zu driften. Messen Sie Sprachabdeckung, Lokalisierungsqualität, und Zeit, ein neues Gebietsschema zu starten, und verwalten Sie das Gebietsschema-Portfolio gegen diese Zahlen statt Märkte ad hoc zu starten.

Behörde. Sprachzugang ist oft eine gesetzliche Pflicht, die offizielle Sprachen, von-rechts-nach-links-Schriften, und indigene oder Minderheitensprachen abdeckt, Transparenz und Gerechtigkeit formen also jede Wahl. Bauen Sie ein geteiltes i18n-Framework und einen Übersetzungsarbeitsablauf über Behörden hinweg, fordern Sie menschliche Prüfung für rechtliche und sicherheitsrelevante Terminologie, und veröffentlichen Sie Glossare, damit Begriffe zwischen Diensten konsistent bleiben. Beschaffung sollte Gebietsschema-, von-rechts-nach-links-, und Barrierefreiheitsunterstützung in Verträgen fordern, und die in jeder Sprache bediente Bevölkerung ist die Kennzahl, die die Ausgabe gegenüber der Öffentlichkeit rechtfertigt.

Beispiele

Startup. Ein kleines Startup, das nur auf Englisch auslieferte, traf trotzdem ein paar günstige architektonische Entscheidungen an Tag eins: überall UTF-8, jeder nutzerzugewandte String in einen Nachrichtenkatalog gezogen statt fest codiert, und Daten und Währungen, formatiert durch eine gebietsschema-bewusste Bibliothek. Es kostete sie fast nichts, während sie eine Sprache hatten. Ein Jahr später, als ihre größte Interessentin um eine französische und deutsche Version bat, war das Hinzufügen dieser Gebietsschemata größtenteils eine Übersetzungsübung, an eine Auftragnehmerin übergeben, keine Neuschreibung, und sie schlossen den Deal in Wochen ab statt ihn für ein Quartal Engineering-Arbeit aufzuschieben.

Großunternehmen. Eine globale E-Commerce-Firma internationalisierte ihre Plattform früh: durchgehend UTF-8, externalisierte Strings, eine gebietsschema-bewusste Formatierungsbibliothek, und eine kontinuierliche Lokalisierungspipeline mit Übersetzungsspeicher und Pro-Sprache-Glossaren. Ein neuer Markt zu betreten wurde größtenteils eine Inhaltsübung (übersetzen, prüfen, Bildsprache anpassen) statt ein Engineering-Projekt, was der Firma erlaubte, in neuen Gebietsschemata binnen Wochen zu starten. Von-rechts-nach-links-Unterstützung, auf logischen Layout-Eigenschaften gebaut, bedeutete, dass arabische und hebräische Märkte wenig neue UI-Arbeit forderten.

Behörde. Eine nationale Regierung, gesetzlich verpflichtet, Dienste in mehreren offiziellen Sprachen zu liefern, einschließlich einer von-rechts-nach-links-Schrift und Minderheitensprachen, baute ein geteiltes i18n-Framework und einen Übersetzungsarbeitsablauf, über Behörden hinweg genutzt. Pseudolokalisierung in CI erwischte fest codierte Strings und Abschneidung vor dem Start; ein geteiltes Glossar hielt rechtliche Terminologie über Dienste und Sprachen hinweg konsistent. Bürgerinnen können Steuer-, Gesundheits-, und Leistungstransaktionen in ihrer eigenen Sprache mit korrekter Datums-, Zahlen-, und Namensformatierung abschließen, Sprachzugangsrecht erfüllend und Gerechtigkeit für Nicht-Mehrheitssprachen-Sprecherinnen verbessernd.

Geschäftsnutzen: Motivation, ROI und Gesamtbetriebskosten

Der ROI von Internationalisierung ist Marktzugang und Geschwindigkeit. Ein gut internationalisiertes Produkt kann schnell und günstig in neue Länder und Sprachmärkte eintreten, jedes neue Gebietsschema in inkrementellen Umsatz oder Bürgerinnenreichweite statt in ein großes Projekt verwandelnd. Lokalisierungsqualität treibt Konversion, Vertrauen, und Support-Kosten in jedem Markt: Nutzerinnen transagieren mehr und kontaktieren Support weniger, wenn das Produkt ihre Sprache korrekt spricht und ihre Konventionen respektiert.

Bei Gesamtbetriebskosten sind die Übernahmekosten das Vorab-Engineering zur Internationalisierung, plus laufende Übersetzungs- und Pipeline-Kosten. Die Kosten der Nicht-Übernahme sind die teure Nachrüstung: fest codierte Strings, Verkettung, Kodierungsfehler, und Layout-Annahmen über eine ganze Codebasis abzuwickeln, oft unter einem Termin, getrieben von einem Markt- oder rechtlichen Erfordernis. Schlechte Lokalisierung trägt auch versteckte Kosten: verlorene Verkäufe in schlecht bedienten Märkten, Support-Last durch verwirrende Formate, und rechtlichen oder Reputationsschaden durch fehlübersetzten hocheinsatzigen Inhalt. Kontinuierliche Lokalisierung vermeidet teure Vor-Start-Übersetzungsgedränge.

Um den Fall gegenüber der Führung zu machen, rahmen Sie Internationalisierung als Option auf zukünftige Märkte. Es ist eine bescheidene Vorabinvestition, die die Kosten und Zeit jedes zukünftigen Markteintritts dramatisch senkt. Für Behörden ist der Treiber gesetzliche Sprachzugangspflicht und Gerechtigkeit, quantifiziert durch die in jeder Sprache bediente Bevölkerung.

Anti-Muster und Fallstricke

Fest codierte Strings: Nutzertext in Code gebacken, Pro-Gebietsschema-Code-Änderungen erzwingend.
String-Verkettung: Sätze aus Fragmenten bauen, was Grammatik und Wortreihenfolge bricht.
Nicht-Unicode-Annahmen: Kodierungsfehler, Mojibake (verstümmelter Text von fehlangepassten Zeichenkodierungen), und Unfähigkeit, Schriften darzustellen.
Englische Textlänge annehmen: Layouts, die abschneiden oder überlappen, wenn übersetzt.
Von-rechts-nach-links ignorieren: physisches links/rechts-Layout nutzen, das nicht spiegeln kann.
Naive Pluralisierung: Singular/Plural-Logik, die in den meisten Sprachen falsch ist.
Gebietsschema-blinde Formatierung: fest codierte Datums-, Zahlen-, und Währungsformate.
Übersetzen ohne Kontext: Übersetzerinnen raten Bedeutung, Fehler produzierend.
Stapelweise, Last-Minute-Lokalisierung: ein Vor-Start-Gedränge statt einer kontinuierlichen Pipeline.
Kulturelle Taubheit: Bildsprache, Farben, oder Beispiele, die lokal beleidigen oder verwirren.

Reifegradmodell

Stufe 1: Beginnen. Einzelne Sprache, fest codierte Strings, Nicht-Unicode-Annahmen, und durch Verkettung gebauter Text. Internationalisierung ist reaktiv: jedes neue Gebietsschema bedeutet Code zu ändern, und Kodierungs- und Layout-Fehler werden zufällig in Produktion gefunden.

Stufe 2: Entwickeln. Manche Strings sind externalisiert und Unicode wird stellenweise genutzt, aber die Praxis ist über Teams hinweg inkonsistent. Lokalisierung ist ein manueller, stapelweiser, Vor-Start-Aufwand, und Formatierung, Plural-Handhabung, und von-rechts-nach-links-Unterstützung werden von einem Team zum nächsten unterschiedlich (oder gar nicht) gehandhabt.

Stufe 3: Standardisieren. Eine geteilte i18n-Architektur und gebietsschema-bewusste Formatierungsbibliothek sind der dokumentierte, organisationsweit durchgesetzte Standard. String-Externalisierung wird durch Lint-Regeln geprüft, ein Übersetzungsverwaltungssystem und kontinuierliche Pipeline sind mit Glossaren und Übersetzungsspeicher vorhanden, und Pseudolokalisierung plus Multi-Gebietsschema-Testen (einschließlich eines von-rechts-nach-links- und eines Langtext-Gebietsschemas) laufen in CI.

Stufe 4: Steuern. Das Lokalisierungsprogramm wird gegen Baselines gemessen und gesteuert. Teams verfolgen Sprachabdeckung, Lokalisierungsqualität und Fehlerraten, String-Synchronisations-Latenz von Commit zu übersetzter Veröffentlichung, pro Veröffentlichung erwischte Abschneidungs- und von-rechts-nach-links-Rendering-Fehler, Übersetzungskosten pro Gebietsschema, und Zeit, ein neues Gebietsschema zu starten, und diese Kennzahlen torwächten Veröffentlichungen und treiben, wo in menschliche Prüfung versus maschinelle Übersetzung zu investieren.

Stufe 5: Orchestrieren. Internationalisierung und Lokalisierung werden kontinuierlich verbessert und über die Organisation integriert. Lokalisierung ist kontinuierlich, maschinelle und menschliche Übersetzung werden absichtlich pro Inhaltsklasse gewählt, und kulturelle Anpassung ist systematisch. Die Organisation fügt Gebietsschemata hinzu, zieht sie zurück, und rahmt sie neu, auf Markt- und Gerechtigkeitsbeleg reagierend, und neue Gebietsschemata starten schnell in hoher Qualität ohne eine Nachrüstung.

Diskussionsideen

Wie früh sollte ein Produkt internationalisieren, wenn internationale Nachfrage unsicher ist?
Wo ist maschinelle Übersetzung akzeptabel, und wo müssen Menschen prüfen?
Wie halten Sie Terminologie über viele Sprachen und Teams hinweg konsistent?
Wie viel regionale kulturelle Anpassung ist die zusätzliche Variantenpflege wert?
Wie sollten von-rechts-nach-links- und Minderheitensprachenunterstützung priorisiert und getestet werden?
Wie geben Sie Übersetzerinnen genug Kontext, ohne die Pipeline zu verlangsamen?

Wichtigste Erkenntnisse

Internationalisieren Sie die Architektur einmal; lokalisieren Sie Inhalt viele Male.
Nutzen Sie überall Unicode, externalisieren Sie alle Strings, und verketten Sie nie Übersetzungen.
Planen Sie für Textexpansion, von-rechts-nach-links-Schriften, und gebietsschema-spezifische Plural- und Formatierungsregeln.
Betreiben Sie eine kontinuierliche Lokalisierungspipeline mit Übersetzungsspeicher, Glossaren, und Kontext.
Pseudolokalisieren Sie früh in CI, um i18n-Fehler vor echter Übersetzung zu erwischen.
Lokalisierung ist kulturell, nicht nur sprachlich.
Frühe Internationalisierung ist weit günstiger als Nachrüstung; für Behörden ist sie eine gesetzliche Gerechtigkeitsanforderung.

Referenzen und weiterführende Literatur

The Unicode Consortium, The Unicode Standard und Common Locale Data Repository (CLDR)
W3C Internationalization (i18n) Activity, Techniken und bewährte Praktiken
Richard Ishida, W3C-Internationalisierungsartikel und -Tutorials
Bert Esselink, A Practical Guide to Localization
John Yunker, Beyond Borders: Web Globalization Strategies
Unicode Technical Standard #35 (Locale-Daten-Markup) und ICU-Bibliotheksdokumentation
IETF BCP 47 Sprachtags
Behörden-Mehrsprachendienst- und Sprachzugangsleitlinien
Nielsen Norman Group und W3C-Artikel über RTL, Textexpansion, und Lokalisierungs-UX