Angular-Übersetzung: ngx-translate vs. automatische Übersetzung (2026)
Angular bietet zwei Ansätze für i18n — ein zur Compile-Zeit arbeitendes, in die Plattform integriertes Framework und eine beliebte Laufzeit-Bibliothek — sowie die Option der DOM-basierten automatischen Übersetzung, die überhaupt keine Code-Änderungen erfordert. So funktioniert jeder Ansatz, wann er passt und wie Sie wählen.
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.
| Ansatz | Wann Übersetzungen greifen | Bundles pro Sprache |
|---|---|---|
@angular/localize | Build-Zeit | Eines pro Locale |
@ngx-translate/core | Laufzeit (Start) | Ein gemeinsames Bundle |
| Automatische Übersetzung | Laufzeit (DOM) | Ein gemeinsames Bundle |
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.jsonbei 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.
@angular/localize: ein CI-Build pro Locale
Ein separater Build pro Sprache ist für Besucher schnell, aber in der CI teuer. Bei 5 Sprachen verfünffachen sich Build-Zeit und Artefakt-Speicher etwa. Bei über 10 Sprachen — ein übliches Ziel für globale Produkte — wird die Matrix zu einem echten Infrastrukturproblem: längere Pipelines, mehr Speicherbedarf, komplexeres Deployment.
ngx-translate: zu pflegende Locale-JSON-Dateien
Jeder String in der App braucht einen Schlüssel in jeder Locale-JSON-Datei. Mit wachsender App wird das Synchronhalten der Dateien zu einer Fehlerquelle: fehlende Schlüssel fallen stillschweigend zurück, veraltete Übersetzungen gehen ohne Warnung live, und typsicheres Schlüsselmanagement erfordert zusätzliches Tooling.
Beide: Übersetzungsdateien sind ein bewegliches Ziel
UI-Texte ändern sich während der Produktentwicklung häufig. Jede Textänderung bedeutet, XLIFF- oder JSON-Dateien zu aktualisieren, Schlüssel neu zu extrahieren und dies mit Übersetzern oder einem Translation-Management-System zu koordinieren. Für Teams ohne dedizierten Lokalisierungs-Workflow summiert sich dieser Aufwand schnell.
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/localizeund 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/localizekorrekt 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
| Schritt | @angular/localize | ngx-translate | Lingvit |
|---|---|---|---|
| Installation | ng add @angular/localize | Paket installieren, TranslateModule konfigurieren | — |
| Strings markieren | Attribut i18n zu jedem Element hinzufügen | Jeden String mit der translate-Pipe umschließen | — |
| Übersetzungsdateien | XLIFF extrahieren, pro Locale ausfüllen | JSON pro Locale schreiben | — |
| CI-Pipeline | Build-Matrix pro Locale | Ein Build | Ein Build |
| Sprachen hinzufügen | Neuer Build pro Locale | Neue JSON-Datei | Dashboard-Umschalter |
| Script-Tag in index.html | Nicht nötig | Nicht nötig | Ein Tag vor </body> |
Horizontal scrollen, um alle Spalten zu sehen.
Häufig gestellte Fragen
- Funktioniert Lingvit mit Angular SSR / Angular Universal?
- Ja. Fügen Sie den Lingvit-Script-Tag zum HTML-Template hinzu, das vom Server ausgeliefert wird (typischerweise src/index.html oder das Express-Server-Template). Das Widget initialisiert sich, nachdem Angular die Seite auf der Client-Seite hydriert hat, und der MutationObserver übernimmt nachfolgende DOM-Aktualisierungen von Angulars Router und Komponenten-Re-Renderings.
- Funktioniert es mit Angular-Material-Komponenten?
- Ja. Angular Material rendert Standard-DOM-Elemente — MatButton, MatInput, MatTable und alle anderen Komponenten erzeugen normales HTML, das der MutationObserver beobachtet. Tooltips und Overlays, die sich an den document body anhängen, werden ebenfalls erfasst.
- Was ist mit Nx-Monorepos mit mehreren Angular-Apps?
- Jede Angular-App in einem Nx-Monorepo ist ein separates Deployable mit eigener index.html. Fügen Sie den Lingvit-Script-Tag zur index.html jeder App unabhängig hinzu. Sie können dasselbe Lingvit-Projekt für Apps auf derselben Domain verwenden oder separate Projekte pro App — im Dashboard lassen sich beide Konfigurationen verwalten.
Weitere Leitfäden
Fügen Sie Ihrer Angular-App Sprachen hinzu
Funktioniert mit Angular 15+, Angular Material und Angular Universal. Ein Script-Tag.