Internationalisierungs-Design-System (i18n)

Internationalisierungs-Design-System

Zweck

Die Fähigkeit des Internationalisierungs-Design-Systems (i18n) bietet eine Methodik für die Gestaltung von Oberflächen, die für ein globales Publikum bereit sind. Sie geht über die einfache Übersetzung hinaus und adressiert die räumlichen, typografischen und visuellen Auswirkungen verschiedener Sprachen und Kulturen. Dieses System stellt sicher, dass Layouts flexibel genug sind, um unterschiedliche Textlängen aufzunehmen, dass bidirektionale (Rechts-nach-Links) Layouts korrekt gespiegelt werden und dass visuelle Hinweise kulturell angemessen bleiben.

Anwendungsfälle

• Entwurf einer globalen SaaS-Plattform oder einer E-Commerce-Website für die regionale Veröffentlichung.
• Anpassung einer bestehenden englischsprachigen Oberfläche für RTL-Sprachen (Arabisch, Hebräisch, Persisch).
• Festlegung typografischer Standards für nicht-lateinische Schriften (CJK, Kyrillisch, Devanagari).
• Überprüfung von UI-Komponenten auf „Expansion-Readiness“ (Umgang mit Textwachstum in Deutsch oder Finnisch).
• Erstellung von Iconsets, die kulturell spezifische oder richtungsbezogene Verzerrungen vermeiden.

Wann NICHT zu verwenden

• Single-Region/Single-Language-Seiten: Wo es keinen Plan für zukünftige Erweiterungen gibt und lokale Konventionen streng bekannt sind.
• Reine visuelle narrative Seiten: Wo das Design ein künstlerischer Ausdruck ist, der auf festen, nicht umfließenden räumlichen Beziehungen beruht.
• Nur-Inhaltsübersetzung: Wenn die Aufgabe lediglich das Übersetzen von Texten ohne Änderung der UI oder des Layoutverhaltens ist.

Eingaben

1. Liste der Zielsprachen: Welche Sprachen und Schriften sollen unterstützt werden?
2. Leserichtung: Fließt die Sprache von links nach rechts (LTR) oder von rechts nach links (RTL)?
3. Typografie-Assets: Lokalisierte Schriftfamilien, die die Stimme der Marke über alle Schriften hinweg bewahren.
4. Kultureller Kontext: Regionalspezifische Konventionen für Farben, Symbole und Datenformate (Datum, Währung).
5. Layout-Breakpoints: Aus dem responsive-grid-system.

Ausgaben

1. Bidirektionale (RTL) Spiegelungsspezifikation: Eine Karte, welche Elemente gespiegelt werden und welche fest bleiben (z. B. Fortschrittsbalken vs. Mediensteuerung).
2. Typografische Skalierungsmatrix: Angepasste Schriftgrößen und Zeilenhöhen für verschiedene Schriftfamilien.
3. Expansions-Blueprint: UI-Muster, die für eine Textlängenvariation von +/- 40 % ausgelegt sind.
4. Ikonografie-Logik: Richtlinien für gespiegelte vs. nicht gespiegelte Icons.
5. Lokalisierungs-Design-Tokens: Logische Eigenschaften (z. B. padding-inline-start), die im Design-Spezifikation definiert sind.

Arbeitsablauf

1. Design für Texterweiterung

Gehen Sie nie davon aus, dass ein Label kurz bleibt. Sprachen wie Deutsch oder Italienisch können 30-50 % länger sein als Englisch.

• Flexible Container: Vermeiden Sie Buttons oder Karten mit fester Breite; verwenden Sie min-width oder fit-content.
• Textumbruch: Stellen Sie sicher, dass UI-Elemente (wie Tabs oder Menüpunkte) elegant umbrechen oder zu einem „Überlauf“-Menü übergehen können.
• Dynamische Zentrierung: Wenn Text expandiert, stellen Sie sicher, dass er nicht mit benachbarten Elementen überlappt.

2. Implementierung der RTL-Spiegelungslogik

Bei rechts-nach-links-Sprachen kippt das „mentale Modell“ der Seite:

• Layout-Spiegelung: Die Seitenleiste bewegt sich von links nach rechts; das Logo bewegt sich von oben links nach oben rechts.
• Logische Eigenschaften: Annotieren Sie Designs mit „Start“ und „Ende“ anstelle von „Links“ und „Rechts“.
• Navigationsfluss: Zurück-Buttons in LTR (die nach links zeigen) müssen in RTL nach rechts zeigen, um „Zurück zum vorherigen Zustand“ anzuzeigen.

3. Lokalisierung von Typografie und vertikalem Rhythmus

Nicht-lateinische Schriften haben unterschiedliche Höhen, Dichten und Lesbarkeitsanforderungen:

• CJK (Chinesisch, Japanisch, Koreanisch): Benötigt etwas größere Basisschriftgrößen und großzügigere Zeilenhöhe (Leading) aufgrund der Zeichenkomplexität.
• Arabisch: Hat hohe Oberlängen und tiefe Unterlängen; erhöhen Sie den vertikalen Abstand, um ein „Aneinanderstoßen“ der Zeilen zu verhindern.
• Fallback-Stapel: Definieren Sie System-Schrift-Fallbacks, die der Gewichtung und x-Höhe Ihrer primären Markenschrift so genau wie möglich entsprechen.

4. Überprüfung der Ikonenrichtungsabhängigkeit

Nicht alles wird in RTL gespiegelt:

• Spiegeln: Richtungsicons (Pfeile, Flugzeuge, Fahrräder), Fortschrittsbalken und Icons, die „vorwärts/rückwärts“-Bewegung darstellen.
• Nicht spiegeln: Im oder gegen den Uhrzeigersinn drehende Icons (Uhren, neu laden), Medienwiedergabesteuerung (Play, Pause, Suchen) und „Häkchen“ (die universell sind).
• Zahlen: Die meisten RTL-Regionen verwenden westliche arabische Ziffern (1, 2, 3), die auch innerhalb von RTL-Text immer noch von links nach rechts gelesen werden.

5. Festlegung von Datenformatierungsstandards

• Datum & Uhrzeit: Definieren Sie eindeutig DD/MM/YYYY vs. MM/DD/YYYY, um Verwirrung zu vermeiden.
• Währung: Definieren Sie, ob das Symbol vor oder nach dem Betrag steht (z. B. $10 vs. 10 €).
• Kalender: Einige Regionen verwenden unterschiedliche Starttage der Woche (Montag vs. Sonntag).

Entscheidungsregeln

• Die Spiegelungsregel: Wenn ein UI-Element „Richtung“ oder „Zeit“ (vorwärts bewegen) darstellt, MUSS es in RTL gespiegelt werden. Wenn es ein physisches Objekt darstellt (wie eine Kamera oder eine Uhr), bleibt es normalerweise fest.
• Die „35 % Puffer“-Regel: Lassen Sie während der englischen Designphase immer 35 % leeren Raum in Buttons und Labels, um Expansion zu berücksichtigen.
• Schriftspezifische Größenanpassung: Wenn eine Schrift hochkomplex ist (z. B. Devanagari), erhöhen Sie die Schriftgröße um 10-15 % im Vergleich zum lateinischen Äquivalent für eine bessere Lesbarkeit.
• Kulturelle Sensibilität: Vermeiden Sie Icons, die westlich zentriert sind (z. B. ein Sparschwein für Ersparnisse, das in vielen Kulturen unangemessen ist).

Einschränkungen

• Barrierefreiheit: Texterweiterung darf interaktive Elemente nicht verbergen oder horizontalen Überlauf verursachen. Kontrastverhältnisse müssen in allen lokalisierten Versionen erhalten bleiben.
• Responsivität: Layouts müssen stabil bleiben, wenn die Richtung gewechselt wird. Verwenden Sie padding-inline und margin-inline in den Spezifikationen.
• Hierarchie: Der primäre CTA muss unabhängig von der Leserichtung das markanteste Element bleiben.

Häufige Fehlermuster

• Der „Expansion Break“: Hartcodierte Breiten, die dazu führen, dass übersetzter Text abgeschnitten wird oder überlappt.
• „Lazy Mirroring“: Das Spiegeln von Icons, die nicht gespiegelt werden sollten (wie ein „Play“-Button oder eine Uhr), was die Benutzer verwirrt.
• Die „English-First“-Falle: Entwurf einer engen, minimalistischen UI auf Englisch, die in Sprachen mit langen Wörtern völlig unbenutzbar wird.
• Fehlende Fallbacks: Keine Angabe von Schriftarten für nicht-lateinische Schriften, was zu „Tofu“ (kaputten Zeichenblöcken) führt.
• Inkonsistente Ausrichtung: Mischen von gespiegeltem Layout mit ungespiegelter Textausrichtung, was ein zerklüftetes, unfertiges Gefühl erzeugt.

Validierungskriterien

• Layout ist für RTL-Ansichtsfenster erfolgreich gespiegelt (Sidebar/Logo-Tausch).
• UI-Komponenten verarbeiten 40 % Texterweiterung ohne Bruch oder Überlappung.
• Typografische Skalierung ist an die Schreibkomplexität angepasst (z. B. Zeilenhöhe erhöht für Arabisch/CJK).
• Ikonografie folgt der „Spiegelung vs. Fest“-Logik.
• Designs verwenden logische Eigenschaften (Start/Ende) anstelle von absoluten (Links/Rechts).
• Datums-, Währungs- und Zahlenformate sind korrekt lokalisiert.
• Fallback-Schriftstapel sind für alle Zielschriften definiert.