i18n Best Practices 2026: 15 essentielle Regeln

Einführung

Nach der Hilfe für tausende Teams bei der Internationalisierung ihrer Apps haben wir die Praktiken identifiziert die reibungslose, skalierbare i18n-Implementierungen von schmerzhaften, fehlerhaften unterscheiden.

Hier sind 15 Regeln für erfolgreiche Internationalisierung.

Code-Architektur

1. Alle benutzer-sichtbaren Strings von Tag Eins extrahieren

Warten Sie nicht bis "wir übersetzen müssen." Dann haben Sie tausende hardcoded Strings.

JavaScript
1// Schlecht - hardcoded String
2<button>Submit</button>
3
4// Gut - von Anfang an extrahiert
5<button>{t('form.submit')}</button>

2. Niemals Strings konkatenieren

Verschiedene Sprachen haben verschiedene Wortordnungen. Konkatenation bricht Übersetzungen.

JavaScript
1// Schlecht - bricht in Deutsch, Japanisch, Arabisch...
2const message = "Hello " + name + ", you have " + count + " messages";
3
4// Gut - nutzt Interpolation
5const message = t('greeting', { name, count });
6// en: "Hello {name}, you have {count} messages"
7// de: "Hallo {name}, Sie haben {count} Nachrichten"

3. ICU Message Format für komplexe Strings verwenden

ICU behandelt Plurale, Geschlecht und Auswahl elegant:

{count, plural,
  =0 {Keine Nachrichten}
  one {# Nachricht}
  other {# Nachrichten}
}

{gender, select,
  male {Er hat Ihren Beitrag geliked}
  female {Sie hat Ihren Beitrag geliked}
  other {Die Person hat Ihren Beitrag geliked}
}

4. Übersetzungsschlüssel semantisch halten

Keys sollten Inhalt beschreiben, nicht Position:

JavaScript
1// Schlecht - an UI-Position gebunden
2"homepage_header_title"
3"sidebar_menu_item_3"
4
5// Gut - beschreibt Inhalt
6"welcome.title"
7"navigation.settings"
8"error.network_unavailable"

5. Keys nach Feature organisieren, nicht nach Datei

Strukturieren Sie Übersetzungen nach Feature-Domain:

/locales/de.json
{
  "auth": {
    "login": { ... },
    "signup": { ... }
  },
  "dashboard": {
    "overview": { ... },
    "settings": { ... }
  },
  "checkout": {
    "cart": { ... },
    "payment": { ... }
  }
}

Formatierung

6. Native Formatierungs-APIs nutzen

Niemals Zahlen-, Datums- oder Währungsformate hardcoden:

JavaScript
1// Schlecht - nur US-Format
2const date = `${month}/${day}/${year}`;
3const price = `$${amount}`;
4
5// Gut - locale-aware
6const date = new Intl.DateTimeFormat(locale).format(dateObj);
7const price = new Intl.NumberFormat(locale, {
8  style: 'currency',
9  currency: userCurrency
10}).format(amount);

Locale-Unterschiede:

	US	Deutschland	Japan
Datum	12/31/2026	31.12.2026	2026/12/31
Zahl	1,234.56	1.234,56	1,234.56
Währung	$99.99	99,99 €	¥100

7. Pluralisierung richtig behandeln

Verschiedene Sprachen haben verschiedene Pluralregeln:

Sprache	Pluralformen
Englisch	2 (one, other)
Französisch	2+ (one, other, many)
Russisch	3 (one, few, many)
Arabisch	6 (zero, one, two, few, many, other)

8. RTL-Sprachen unterstützen

Arabisch, Hebräisch, Persisch und Urdu lesen von rechts nach links:

CSS
1/* Logische Eigenschaften verwenden */
2.card {
3  margin-inline-start: 1rem;  /* Nicht margin-left */
4  padding-inline-end: 1rem;   /* Nicht padding-right */
5}

JSX
<html dir={isRTL ? 'rtl' : 'ltr'}>

Übersetzungsqualität

9. Kontext für Übersetzer bereitstellen

Übersetzer müssen wissen wo und wie Strings verwendet werden:

JSON
1{
2  "save": {
3    "value": "Speichern",
4    "context": "Button um Profiländerungen zu speichern, erscheint am Formularende",
5    "maxLength": 12,
6    "screenshot": "save-button.png"
7  }
8}

10. Ein Glossar verwenden

Konsistente Terminologie über Übersetzungen hinweg beibehalten:

Englisch	Deutsch	Kontext
Dashboard	Dashboard	Haupt-Benutzeroberfläche
Settings	Einstellungen	Benutzereinstellungen
Submit	Absenden	Formular-Absende-Button

11. Translation Memory nutzen

Dieselbe Phrase nicht zweimal übersetzen. TM fängt:

Exakte Treffer: "Änderungen speichern" = "Änderungen speichern"
Fuzzy Treffer: "Änderungen speichern" ≈ "Alle Änderungen speichern"

ROI: 30-60% Reduktion der Übersetzungskosten über Zeit.

Prozess

12. Übersetzungs-Sync automatisieren

Manuelles Syncing verschwendet Zeit und führt zu veralteten Übersetzungen:

Terminal
1# Übersetzungen in CI synken
2npx @intlpullhq/cli upload
3npx @intlpullhq/cli download
4
5# Oder Watch-Modus für lokale Entwicklung
6npx @intlpullhq/cli sync --watch

13. Continuous Localization nutzen

Übersetzungen nicht batchen. Kontinuierlich lokalisieren.

14. Mit Pseudo-Lokalisierung testen

Vor echten Übersetzungen mit Pseudo-Übersetzungen testen:

"Willkommen" → "[Ẃíĺĺķőḿḿéń !!!!!!]"

Pseudo-Lokalisierung enthüllt:

Hardcoded Strings (nicht transformiert)
Layout-Probleme (Textexpansion)
Abschneidungsprobleme
Zeichenkodierungsprobleme

15. OTA-Updates für Mobile implementieren

Nicht auf App-Store-Releases warten um Übersetzungen zu fixen:

Swift
// Mit OTA sind Übersetzungsupdates sofort
let message = IntlPull.t("welcome.message")
// Änderung im Dashboard → Benutzer sehen es sofort

Ohne OTA: 1-2 Wochen Verzögerung für jede Übersetzungsänderung Mit OTA: Sofortige Updates, kein App-Release nötig

Anti-Patterns vermeiden

Nicht: String-Konkatenation verwenden

JavaScript
// Niemals so
"Willkommen, " + name

Nicht: Formatierung hardcoden

JavaScript
// Niemals so
date.toLocaleDateString('de-DE')

Nicht: Sätze aufteilen

JavaScript
1// Niemals so
2<span>{t('click')}</span>
3<Link>{t('here')}</Link>
4<span>{t('to_continue')}</span>

Checkliste

Vor dem Launch in einer neuen Sprache:

Fazit

Gutes i18n bedeutet:

Saubere Architektur: Strings früh extrahieren, Interpolation nutzen
Richtige Formatierung: APIs Locale-Unterschiede behandeln lassen
Qualitätsübersetzungen: Kontext, Glossare, TM
Smarter Prozess: Automatisierung, kontinuierlicher Flow, Testing

Folgen Sie diesen 15 Praktiken und Sie bauen Apps die global skalieren ohne die typischen i18n-Schmerzen.

Bereit Ihr i18n zu verbessern? Testen Sie IntlPull kostenlos und setzen Sie diese Best Practices mit den richtigen Tools um.

i18n Best Practices: 15 Regeln für Internationalisierung 2026