Internationalisierungs-Review

Das Problem

Internationalisierung nachtraeglich aufzusetzen ist zehnmal teurer als sie von Anfang an einzubauen. Hardcodierte Strings verstecken sich in Fehlermeldungen, Tooltips, aria-Labels und E-Mail-Templates. Datumsformatierung, die in den USA funktioniert, bricht in Deutschland (ist 1/2/2026 der 2. Januar oder der 1. Februar?). Layouts, die fuer Englisch entworfen sind, brechen zusammen, wenn deutscher Text 30% laenger ist oder arabischer Text von rechts nach links fliesst.

Der Prompt

Pruefe den folgenden Code auf Internationalisierungstauglichkeit. Handle als i18n-Spezialist, der diese Anwendung fuer den Launch in 5 weiteren Sprachen vorbereitet.

FRAMEWORK: [z.B. React + react-i18next, Vue + vue-i18n, Astro, Next.js]
AKTUELLE SPRACHEN: [z.B. nur Englisch, Englisch + Deutsch]
ZIELSPRACHEN: [z.B. Deutsch, Franzoesisch, Arabisch (RTL), Japanisch]

CODE:
[Komponenten-Code und i18n-Konfiguration einfuegen]

UEBERSETZUNGSDATEIEN (falls vorhanden):
[Locale JSON/YAML-Dateien einfuegen]

Bewerte in diesen Dimensionen:

1. **String-Externalisierung**
   - Sind alle nutzer-sichtbaren Strings in Uebersetzungsdateien extrahiert?
   - Pruefen: Button-Labels, Fehlermeldungen, Platzhalter, aria-Labels, Seitentitel
   - Gibt es String-Konkatenierungen, die in anderen Sprachen brechen?

2. **Formatierung**
   - Werden Datumsangaben mit Intl.DateTimeFormat formatiert?
   - Werden Zahlen mit Intl.NumberFormat formatiert (Dezimaltrennzeichen variieren)?
   - Werden Waehrungen korrekt angezeigt (Symbolposition variiert)?

3. **Pluralisierung**
   - Behandelt die i18n-Library Pluralregeln jenseits von "eins/mehrere"?
   - Gibt es manuelle `count === 1 ? "Artikel" : "Artikel"` Patterns?

4. **Layout & RTL**
   - Nutzen Layouts logische Properties (margin-inline-start, nicht margin-left)?
   - Ist das `dir`-Attribut auf dem HTML-Element gesetzt?
   - Werden Icons mit Richtungsbedeutung fuer RTL gespiegelt?
   - Bricht Textexpansion (Deutsch +30%) Layouts?

5. **Uebersetzungsqualitaet**
   - Sind Uebersetzungsschluessel semantisch (user.greeting, nicht text_1)?
   - Ist Kontext fuer Uebersetzer bereitgestellt?

6. **Technisches Setup**
   - Ist Locale-Erkennung implementiert (URL, Cookie, Browser-Praeferenz)?
   - Sind locale-spezifische URLs fuer SEO eingerichtet (hreflang, canonical)?
   - Sind API-Responses lokalisiert?

Fuer jedes Problem liefere:
- **Ort**: Datei und Zeile oder Uebersetzungsschluessel
- **Schweregrad**: Kaputt-in-Locale / Unvollstaendig / Verbesserung
- **Betroffene Sprachen**: Welche Sprachen betroffen sind
- **Fix**: i18n-korrekter Code

Beispielausgabe

## i18n-Review: 6 Probleme gefunden

### Kaputt in Locale: Konkatenierter String
Ort: src/components/Greeting.tsx:5
Code: `<h1>{"Welcome to " + city + "!"}</h1>`
Problem: Wortstellung variiert. Deutsch: "Willkommen in Berlin!" / Japanisch: "ベルリンへようこそ！"
Fix: Interpolation verwenden:
  t('greeting.welcome', { city }) → "Welcome to {{city}}!"
  de: "Willkommen in {{city}}!" / ja: "{{city}}へようこそ！"

### Kaputt in Locale: Manuelle Datumsformatierung
Ort: src/utils/format.ts:12
Code: `${month}/${day}/${year}` — MM/DD/YYYY ist nur in den USA ueblich.
Fix:
  new Intl.DateTimeFormat(locale, { year: 'numeric', month: 'long', day: 'numeric' }).format(date)

Wann verwenden

Vor dem Hinzufuegen einer zweiten Sprache, beim Audit bestehender mehrsprachiger Apps oder bei Vorbereitung auf RTL-Maerkte ausfuehren. Unverzichtbar am Start jedes Projekts, das spaeter lokalisiert werden koennte.

Profi-Tipps

• Mit Extremsprachen testen — Deutsch (lange Woerter), Japanisch (keine Leerzeichen), Arabisch (RTL) decken die meisten i18n-Bugs auf.
• Pseudo-Lokalisierung nutzen — “Generiere eine Pseudo-Locale-Datei, die alle Stringlaengen verdoppelt und Akzente hinzufuegt.”
• Vollstaendige Oberflaeche pruefen — E-Mail-Templates, PDF-Generierung und Push-Notifications werden beim String-Extrahieren haeufig uebersehen.
• hreflang-Tags pruefen — “Verifiziere alle hreflang-Tags auf Korrektheit und vollstaendige bidirektionale Verlinkung.”