Design-System-Lokalisierung: Komponenten für jede Sprache anpassen

Design-System-Lokalisierung: Komponenten für jede Sprache anpassen

Design-Systeme sind das Fundament einer konsistenten und skalierbaren UI-Entwicklung. Ein Design-System, das Internationalisierung nicht berücksichtigt, wird jedoch auf vorhersehbare und schmerzhafte Weise scheitern, sobald Ihr Produkt global wird.

Text dehnt sich aus. Layouts müssen gespiegelt werden. Schriften ändern ihre Richtung. Zeichensätze erfordern unterschiedliche Font-Konfigurationen. Datumswähler setzen westliche Kalender voraus. Farbpaletten tragen kulturelle Bedeutung. Ein wirklich globales Design-System muss die Antworten auf all diese Probleme von Anfang an in seine Komponenten eincodieren.

Dieser Leitfaden zeigt, wie Sie Lokalisierung in Ihr Design-System integrieren – egal ob Sie von Grund auf neu beginnen oder ein bestehendes System nachrüsten.

Das Kernproblem: Design-Systeme werden oft für eine einzige Sprache entwickelt

Die meisten Design-Systeme werden mit einer einzigen Sprache im Blick entwickelt – meist Englisch – und geraten in Schwierigkeiten, wenn Lokalisierungsanforderungen auftauchen. Die Symptome sind vertraut:

• Text läuft in Deutsch über Button-Grenzen hinaus
• Arabischer Text erscheint linksbündig statt rechtsbündig
• Datumswähler zeigen Sonntag als ersten Wochentag für Nutzer aus Kulturen an, in denen Montag der erste Tag ist
• Icons mit Richtungsbedeutung (Zurück-Pfeile, Fortschrittsanzeigen) werden für RTL nicht gespiegelt
• Währungssymbole erscheinen an der falschen Position
• Zeilenhöhen sind zu eng für Sprachen mit Ober- und Unterlängen wie Thailändisch oder Devanagari

Das sind keine Randfälle – es sind vorhersehbare Fehler, die jedes Mal auftreten, wenn ein englischzentriertes Design-System auf eine neue Sprache trifft.

Textausdehnung: Für sprachliche Flexibilität gestalten

Englisch ist eine der kompakteren Schriftsprachen. Wenn UI-Texte übersetzt werden, dehnen sie sich fast immer aus:

Design-System-Muster für Textausdehnung

Vermeiden Sie Container mit fester Breite für Text: Verwenden Sie statt width: 120px lieber min-width: 120px oder max-content-Breiten mit geeignetem Overflow-Handling.

Testen Sie mit der längstmöglichen Übersetzung: Gewöhnen Sie sich daran, Komponenten mit deutschen oder finnischen Zeichenketten zu testen. Wenn Ihr Button „Subscribe to Newsletter" enthält, muss Ihr deutscher Übersetzer möglicherweise „Newsletter abonnieren" rendern – etwas länger, aber handhabbar – oder eine vollständig ausgeschriebene Version, die deutlich länger ist.

Verwenden Sie flexible Layouts: CSS Flexbox und Grid behandeln Textausdehnung elegant, wenn sie richtig konfiguriert sind. Vermeiden Sie pixelbasierte Abstände zwischen Textelementen.

Stellen Sie Zeichenlimit-Hinweise in Ihren Design-Tokens bereit: Dokumentieren Sie empfohlene maximale Zeichenlängen für jeden Komponententyp. Geben Sie Übersetzern diese Informationen im Voraus. Lesen Sie Übersetzungskontext, um zu erfahren, wie diese Metadaten die Übersetzungsqualität verbessern.

Textkürzung als letztes Mittel: Wenn Text gekürzt werden muss, bieten Sie einen Tooltip mit dem vollständigen Text an (der ebenfalls übersetzbar sein muss) und stellen Sie sicher, dass die Kürzungslogik sprachbewusst ist (keine Kürzung mitten in einem CJK-Zeichen).

RTL-Unterstützung: Mehr als nur die Textrichtung spiegeln

Die Unterstützung von Rechts-nach-links (RTL)-Sprachen ist eine der umfassendsten Transformationen, die ein Design-System unterstützen muss. Es geht nicht nur um die Textrichtung – es geht um räumliches Denken in einer gespiegelten Welt.

Was sich bei RTL umkehrt

Layout: Das gesamte Seitenlayout wird gespiegelt. Die linke Spalte wird zur rechten Spalte. Navigationsschubladen, die sich von links öffnen, öffnen sich von rechts.

Textausrichtung: Die Standard-Textausrichtung wird rechtsbündig. Linksbündiger Text in LTR wird in RTL rechtsbündig.

Richtungsbezogene Icons: Icons mit Richtungsbedeutung müssen gespiegelt werden:

• Zurück-Pfeil (←) in LTR wird zur Vorwärts-Pfeil-Richtung (→ visuelle Position) in RTL
• Häkchen (Fortschritt von links nach rechts) wird gespiegelt
• Listen-Icons (Aufzählungspunkte, nummerierte Listen) wechseln die Seite

Icons, die NICHT gespiegelt werden: Abstrakte Icons, Logos und Icons ohne Richtungsbedeutung sollten nicht gespiegelt werden:

• Warndreieck: identisch in beiden Richtungen
• Herz, Stern, kreisförmige Icons: identisch in beiden Richtungen
• Logos: niemals spiegeln

Formularfelder: Eingabetextausrichtung, Platzhalterposition und Icon-Positionen innerhalb von Eingabefeldern kehren sich um.

Padding und Margins: padding-left wird zu padding-right und umgekehrt.

CSS Logical Properties verwenden

Die moderne Lösung sind CSS Logical Properties, die sich automatisch an die Schreibrichtung anpassen:

/* Alter Ansatz: fest codierte Richtungen */
.card {
  padding-left: 16px;
  padding-right: 24px;
  margin-left: auto;
  border-left: 2px solid blue;
  text-align: left;
}

/* Moderner Ansatz: Logical Properties */
.card {
  padding-inline-start: 16px;
  padding-inline-end: 24px;
  margin-inline-start: auto;
  border-inline-start: 2px solid blue;
  text-align: start;
}

Mit Logical Properties und dir="rtl" am <html>-Element wird Ihr Layout automatisch gespiegelt.

Einen vollständigen Leitfaden finden Sie unter RTL-Unterstützung in CSS und React.

RTL in Ihren Design-Tokens

Definieren Sie Richtungs-Tokens mit logischen Eigenschaftsnamen:

{
  "spacing": {
    "inline-start": { "value": "16px" },
    "inline-end": { "value": "24px" }
  }
}

Stellen Sie außerdem sicher, dass Ihr Design-Tool Logical Properties exportiert, keine Richtungseigenschaften (Figmas neuere Updates haben das verbessert, aber prüfen Sie Ihre Export-Pipeline).

Typografie: Multi-Schrift-Font-Systeme

Ein Design-System muss Fonts angeben, die für alle Schriften funktionieren, die Ihr Produkt unterstützt.

Font-Stacks für Multi-Schrift-Unterstützung

Ein Font, der für lateinischen Text funktioniert, fehlen möglicherweise Glyphen für kyrillische, arabische, CJK-, Devanagari- oder thailändische Schriften. Bauen Sie Ihren Font-Stack so auf, dass er geeignet kaskadiert:

/* Umfassender Multi-Schrift-Font-Stack */
font-family: 
  'Your Brand Font',          /* Latein, primäre Marke */
  'Noto Sans',                 /* Universelle Schriftabdeckung */
  -apple-system,              /* Apple-Systemfonts (gutes CJK auf macOS/iOS) */
  BlinkMacSystemFont,         /* Chrome auf macOS */
  'Hiragino Kaku Gothic ProN', /* Japanisch */
  'Hiragino Sans',            /* Japanisch */
  'Meiryo',                   /* Japanisch (Windows) */
  sans-serif;

Für Arabisch benötigen Sie spezifische arabische Fallbacks:

font-family: 
  'Your Brand Font',
  'Noto Sans Arabic',
  'Arabic Typesetting',
  sans-serif;

Zeilenhöhen-Anpassungen für verschiedene Schriften

Verschiedene Schriften erfordern unterschiedliche Zeilenhöhen:

• Latein: 1,4–1,6
• Arabisch/Hebräisch: 1,6–1,8 (Diakritika erstrecken sich nach oben und unten)
• Thailändisch: 1,8–2,0 (komplexe Konsonantencluster und Diakritika)
• CJK: 1,5–1,8

Eine einzige Zeilenhöhe fest zu codieren führt bei Schriften mit großen Oberlängen zu Beschneidungen. Verwenden Sie schriftbewusste Zeilenhöhen in Ihrem Design-System:

:root { --line-height-body: 1.5; }
:lang(ar), :lang(he) { --line-height-body: 1.7; }
:lang(th) { --line-height-body: 1.9; }
:lang(zh), :lang(ja), :lang(ko) { --line-height-body: 1.6; }

Datums-, Uhrzeit- und Zahlenkomponenten

Kalender- und Datumswähler-Komponenten gehören zu den lokalisierungsintensivsten Komponenten in jedem Design-System.

Anforderungen an Kalender-Komponenten

• Erster Wochentag: Sonntag (USA), Montag (der größte Teil Europas und Asiens), Samstag (einige Länder des Nahen Ostens)
• Kalendersystem: Gregorianisch (Standard), Hebräisch, Islamisch (Hijri), Persisch (Jalali), Buddhistisch (Thailand), Japanischer Kaiserkalender
• Datumsformat: MM/TT/JJJJ, TT/MM/JJJJ, JJJJ/MM/TT sowie viele gebietsschemaspezifische Variationen
• Wochenendtage: Samstag/Sonntag (USA/Europa), Freitag/Samstag (Naher Osten), variiert anderswo
• Feiertags-Hervorhebung: Falls unterstützt, muss sie gebietsschemaspezifisch sein

Verwenden Sie die Intl.DateTimeFormat-API für die Formatierung und ziehen Sie etablierte headless-Kalender-Bibliotheken in Betracht (wie @internationalized/date), die die Komplexität des Kalendersystems behandeln.

Zahleneingabe-Komponenten

Zahleneingabe-Komponenten müssen gebietsschemaspezifische Dezimaltrennzeichen verarbeiten. Ein deutscher Nutzer, der „1.234,56" eingibt, erwartet den Punkt als Tausendertrennzeichen und das Komma als Dezimaltrennzeichen. Wenn Ihre Eingabe den Punkt entfernt und „123456" an Ihre API übergibt, haben Sie ein Datenintegritätsproblem.

Währungsanzeige

Währungs-Komponenten sollten folgendes akzeptieren:

• Betrag (als Integer in der kleinsten Einheit oder als Decimal)
• Währungscode (ISO 4217: USD, EUR, GBP, JPY usw.)
• Gebietsschema

Verwenden Sie Intl.NumberFormat für die Formatierung. Codieren Sie Währungssymbole niemals fest.

Komponentendokumentation für die Lokalisierung

Eine gute Design-System-Dokumentation enthält Lokalisierungsleitlinien für jede Komponente:

Zeichenkettenbeschränkungen: Dokumentieren Sie maximale Zeichenzahlen für jede übersetzbare Zeichenkette. „Button-Beschriftungen: max. 25 Zeichen in der Anzeigeschrift, 40 Zeichen für die kompakte Anzeige."

Übersetzungshinweise: Fügen Sie für UI-Zeichenketten in Ihrem Design-System (z. B. Standard-Platzhaltertext, eingebaute Validierungsmeldungen) Kontextnotizen für Übersetzer hinzu.

RTL-Varianten: Zeigen Sie jede Komponente sowohl in LTR als auch in RTL in Ihrer Dokumentation. Storybook unterstützt Gebietsschema-Umschaltung, die das unkompliziert macht.

Schrift-Beispiele: Zeigen Sie Komponenten gerendert in allen unterstützten Schriften, nicht nur auf Englisch.

Die Checkliste für ein lokalisierungsbereites Design-System

Layout:

• CSS Logical Properties durchgehend verwendet (keine Richtungseigenschaften)
• dir-Attribut-Unterstützung für Root und Komponenten
• Grid und Flexbox verwendet (kein absolutes Positioning für das Layout)

Typografie:

• Multi-Schrift-Font-Stack definiert
• Schriftbewusste Zeilenhöhen
• Schriftgröße in relativen Einheiten (rem, em)
• Keine Text-Container mit fester Breite

Komponenten:

• Buttons: min-width, keine feste Breite
• Inputs: logisches Padding, RTL-bewusste Icon-Platzierung
• Modals/Drawers: RTL-Öffnungsrichtungs-Unterstützung
• Datumswähler: gebietsschema-bewusster erster Wochentag, Format, Kalendersystem
• Zahleneingaben: gebietsschema-bewusste Dezimalverarbeitung
• Icons: gespiegelte Varianten für Richtungs-Icons dokumentiert

Dokumentation:

• Zeichenketten-Zeichenlimits dokumentiert
• Übersetzungskontext für eingebaute Zeichenketten bereitgestellt
• RTL-Beispiele in der Komponentendokumentation
• Multi-Schrift-Rendering gezeigt

Tests:

• Storybook-Gebietsschema-Umschalter konfiguriert
• Automatisierte visuelle Regression in mehreren Gebietsschemata
• RTL-Smoke-Tests in CI

Informationen zu Test-Ansätzen finden Sie unter i18n-Testing-Tools, Strategien und Automatisierung.

Machen Sie Ihre App global mit better-i18n

better-i18n kombiniert KI-gestützte Übersetzungen, git-native Workflows und globale CDN-Auslieferung in einer entwicklerzentrierten Plattform. Hören Sie auf, Tabellenkalkulationen zu verwalten, und beginnen Sie, in jeder Sprache zu veröffentlichen.

Kostenlos starten → · Funktionen erkunden · Dokumentation lesen