🌍 Internationalisierung (i18n) in Angular – Übersetzungsstrategie, die skaliert

Mehrsprachigkeit ist mehr als nur translate('HELLO').
Im Enterprise braucht dein i18n-System Klarheit, Struktur und Wartbarkeit.

In diesem Beitrag zeige ich dir:

• Wie du Angular i18n professionell aufsetzt
• Welche Strategien sich bewährt haben
• Wie du Teams, Sprachen und Features organisierst

🛠 Die zwei Haupt-Ansätze

1. 🧩 Angular Built-in i18n (Compiler-basiert)

• statisch (mit XLIF oder XMB Dateien)
• Übersetzungen via i18n="..." im Template
• Compile-Zeit-Sprachvarianten

✅ Performance
✅ SEO
❌ Kein Runtime-Switch
❌ Aufwändig bei dynamischen Texten

2. 🔌 ngx-translate (oder Transloco)

• JSON-basiert, zur Laufzeit ladbar
• {{ 'WELCOME' | translate }}
• Sprachwechsel on the fly

✅ Flexibel
✅ Runtime Switch
✅ Lazy Load Support
❌ Weniger stark im SEO

💡 Best Practice Struktur

assets/i18n/
├── de.json
├── en.json
├── fr.json

Nutze Namespaces pro Feature:

// en.json
{
  "login": {
    "title": "Welcome Back",
    "button": "Sign in"
  },
  "profile": {
    "greeting": "Hello {{name}}"
  }
}

🌍 Dynamische Sprache setzen

translateService.use('en');

Oder per LocalStorage & Browser-Language automatisch initialisieren:

const browserLang = translate.getBrowserLang();
translate.use(browserLang.match(/en|de|fr/) ? browserLang : 'en');

📦 Lazy Load mit Feature-Modulen

TranslateModule.forChild({
  extend: true
})

➡ Du kannst Sprachen on demand laden & modular halten.

🧪 Testbarkeit von Übersetzungen

TestBed.configureTestingModule({
  imports: [
    TranslateModule.forRoot(),
  ],
  providers: [
    { provide: TranslateLoader, useClass: FakeTranslateLoader }
  ]
});

➡ Trenne View-Logik & Sprache = besser testbar!

✅ Fazit

Angular i18n wird erst dann stark, wenn du es architektonisch ernst nimmst:

• Nutze Namespaces
• Organisiere Sprachdateien pro Feature
• Entscheide klar zwischen Build-Time vs Runtime

📍 Bald im Blog: 🧱 Angular Forms: Reactive vs. Signals – Was du wann brauchst