Angular-Übersetzung: ngx-translate vs. automatische Übersetzung (2026)

Angulars zwei integrierte i18n-Ansätze

Angular hat sein eigenes i18n-Framework, @angular/localize, das XLIFF-Dateien und Übersetzung zur Compile-Zeit nutzt. Die entscheidende Eigenschaft: Sie führen einen separaten Build pro Locale aus. Jede Sprache erzeugt ihr eigenes optimiertes Bundle mit zur Build-Zeit eingebackenen Übersetzungen — die schnellstmögliche Laufzeit, da es keinen Übersetzungs-Lookup-Overhead im Browser gibt.

Die beliebte Drittanbieter-Alternative ist @ngx-translate/core, die zur Laufzeit arbeitet. Sie liefern ein Bundle aus und laden beim Start Locale-JSON-Dateien. Nutzer, die die Sprache wechseln, erhalten die neuen Strings ohne Seiten-Reload.

Horizontal scrollen, um alle Spalten zu sehen.

ngx-translate in der Praxis

@ngx-translate/core ist die am weitesten verbreitete Angular-i18n-Bibliothek außerhalb des integrierten Frameworks. Das Kernmuster besteht aus drei Teilen:

• →TranslateModule — importiert in jedes Angular-Modul (oder Standalone-Komponente), das Übersetzungen benötigt. Stellt die Pipe und die Direktive bereit.
• →TranslateService — wird in Komponenten injiziert, die die Sprache programmatisch wechseln oder auf Übersetzungen in TypeScript zugreifen müssen.
• →translate-Pipe — wird in Templates verwendet: {{ "HELLO" | translate }}. Reaktiv: aktualisiert sich automatisch, wenn sich die aktive Sprache ändert.
• →HttpLoader — der Standard-Loader lädt /assets/i18n/fr.json bei einem Sprachwechsel. Sie pflegen eine JSON-Datei pro Locale.

Das Ökosystem ist ausgereift: Community-Pakete übernehmen ICU-Pluralformen, lazy-geladene Übersetzungsmodule und serverseitiges Rendering. Die meisten Angular-Teams, die Projekte vor Angular 13 gestartet haben, nutzen ngx-translate.

Die Angular-i18n-Kosten

Beide integrierten Ansätze bringen einen Wartungsaufwand mit sich, der zu Beginn eines Projekts leicht unterschätzt wird.

Wann Angulars i18n-Tooling die richtige Wahl ist

Der integrierte Angular-i18n-Stack glänzt in spezifischen Kontexten wirklich:

• →Enterprise-Apps mit dediziertem Lokalisierungsteam. Wenn Sie professionelle Übersetzer, ein TMS und einen Review-Workflow haben, fügt sich die XLIFF-Extraktion direkt in diese Prozesse ein.
• →Compliance-Anforderungen für menschlich freigegebene Übersetzungen. Finanz-, Rechts- oder medizinische Apps, die keine ungeprüften Texte veröffentlichen dürfen, profitieren von dem expliziten Übersetzungsfreigabeschritt, den XLIFF-Workflows erzwingen.
• →Starke Nutzung des ICU-Nachrichtenformats. Plural- und Select-Regeln (z. B. „{count, plural, one {1 result} other {# results}}”) sind erstklassige Bürger in @angular/localize und mit einem ICU-Plugin auch in ngx-translate gut unterstützt.
• →Build-Zeit-Optimierung pro Locale ist erforderlich. Wenn die Bundle-Größe kritisch ist und jeder Markt tatsächlich unterschiedliche Inhalte hat (nicht nur übersetzte Strings), ermöglichen Per-Locale-Builds Tree-Shaking von ungenutztem Locale-spezifischem Code.

Wann automatische Übersetzung gewinnt

DOM-basierte automatische Übersetzung — das Hinzufügen eines Script-Tags zur Host-Seite der Angular-App — überspringt die Übersetzungs-Pipeline komplett. Es gibt klare Szenarien, in denen dies die bessere Wahl ist:

• →Bestehende Angular-App wird ohne Neu-Build mehrsprachig. Eine laufende App ohne i18n-Investition kann noch heute mehrsprachig werden, ohne eine einzige Komponente anzufassen.
• →Startup-Teams ohne i18n-Ingenieure. ngx-translate oder @angular/localize korrekt einzurichten braucht Zeit. Ein Script-Tag kann den Integrationsaufwand reduzieren, aber die Setup-Zeit variiert je nach App.
• →SaaS-Dashboards mit sich schnell ändernder UI. Wenn sich UI-Texte wöchentlich ändern, wird die Pflege von Übersetzungsdateien zum Vollzeitjob. Automatische Übersetzung hält mit dem DOM Schritt, ohne jegliche Dateiaktualisierungen.
• →Time-to-Market ist entscheidend. Französische, deutsche, spanische und japanische Nutzer an einem Tag zu erreichen — nicht in einem Quartal — ist für viele Produkte ein echter Wettbewerbsvorteil.

Wie Lingvit mit Angular funktioniert

Lingvit wird einer Angular-App über einen einzelnen Script-Tag in src/index.html vor dem schließenden </body>-Tag hinzugefügt.

Angulars Change Detection aktualisiert das DOM, während Komponenten neu rendern. Lingvit nutzt einen MutationObserver, um diese DOM-Mutationen zu erkennen und neuen Inhalt beim Erscheinen zu übersetzen — dies funktioniert korrekt sowohl mit zone.js-basierter Change Detection als auch mit der neueren, signalbasierten Reaktivität, die in Angular 16+ eingeführt wurde.

• →

  Angular 15+ Standalone Components

  Funktioniert ohne Änderungen. Standalone-Komponenten rendern in dasselbe DOM; der MutationObserver erfasst alle Aktualisierungen unabhängig davon, ob die App NgModule oder Standalone-Architektur nutzt.

• →

  Angular Universal / SSR

  Serverseitiges Rendering wird unterstützt. Der Script-Tag wird dem serverseitig gerenderten HTML-Template hinzugefügt. Nach der Hydration übernimmt der MutationObserver alle clientseitigen DOM-Aktualisierungen von Angulars Router oder Komponenten-Re-Renderings.

• →

  Älteres NgModule-Muster

  Apps auf Angular 12 und früher, die NgModules verwenden, funktionieren identisch. Der Script-Tag ist auf Host-Seiten-Ebene — er hat keine Abhängigkeit von der Angular-Version oder dem Modulsystem innerhalb der App.

Setup-Vergleich

Horizontal scrollen, um alle Spalten zu sehen.

Häufig gestellte Fragen