Vue i18n vs. automatische Übersetzung: der richtige Ansatz für Ihre Vue-App (2026)
Vue hat eine ausgereifte, beliebte i18n-Bibliothek. Es gibt aber auch ein Ökosystem DOM-basierter Übersetzungstools, die keinerlei Änderungen am Quellcode erfordern. Welcher Ansatz für Ihr Projekt richtig ist, hängt von Faktoren ab, die die meisten Leitfäden auslassen — hier die ehrliche Einordnung.
Vues i18n-Geschichte
vue-i18n (erstellt von kazupon, mittlerweile unter der Organisation @intlify als @intlify/vue-i18n-next gepflegt) ist der De-facto-Standard für Vue-Internationalisierung. Es bietet erstklassige Unterstützung sowohl für Vue 2 (vue-i18n v8) als auch für Vue 3 (vue-i18n v9+).
Die API ist übersichtlich und gut dokumentiert. In einer Vue-3-App mit der Composition API:
// main.ts
import { createI18n } from 'vue-i18n'
const i18n = createI18n({
legacy: false,
locale: 'en',
fallbackLocale: 'en',
messages: { en, fr, de },
})
app.use(i18n)
Innerhalb von Komponenten verwenden Sie das useI18n-Composable und die t()-Funktion:
<script setup lang="ts">
const { t } = useI18n()
</script>
<template>
<h1>{{ t('home.title') }}</h1>
<p>{{ t('home.description') }}</p>
</template>
In Vue 2 oder der Options API wird derselbe String in Templates als $t('home.title') abgerufen. Die Bibliothek ist bewährt, hat eine aktive Community und unterstützt alles von einfachen String-Lookups bis hin zu komplexer Zahlen-/Datumsformatierung über die ECMAScript-Internationalisierungs-API.
Der Wartungsaufwand
vue-i18n ist leistungsfähig — aber diese Leistungsfähigkeit hat einen Wartungsaufwand, der mit dem Wachstum Ihrer Anwendung zunimmt:
- →JSON-Sprachdateien pro Sprache. Jeder String in Ihrer App muss für jede unterstützte Sprache in eine Key-Value-Datei extrahiert werden. Ein typisches SaaS-Produkt hat Hunderte bis Tausende von Schlüsseln. Jede neue Funktion bedeutet neue Schlüssel in jeder Sprachdatei.
- →Dateien synchron halten. Wenn ein Entwickler einen neuen UI-String hinzufügt und vergisst, die französische Sprachdatei zu aktualisieren, zeigt die Fallback-Sprache französischen Nutzern oft still und leise Englisch an. Tools wie
vue-i18n-extracthelfen, bedeuten aber zusätzlichen Einrichtungsaufwand. - →Bundle-Größe und Lazy-Loading. Wenn alle Sprach-JSONs von Anfang an ausgeliefert werden, bläht das den initialen Bundle auf. Lazy-Loading pro Sprache erfordert asynchrone Chunk-Konfiguration in Vite/webpack und die Behandlung des Ladezustands beim Sprachwechsel.
- →Pluralregeln pro Sprache. Englisch hat zwei Pluralformen, Russisch vier, Arabisch sechs. vue-i18n behandelt das mit ICU-Message-Syntax, aber jemand muss die Pluralstrings für jede Sprache schreiben und prüfen.
- →Datums- und Zahlenformatierung. Sprachabhängige Formatierung erfordert explizite
datetimeFormats- undnumberFormats-Konfiguration pro Sprache — stundenlange Einrichtungsarbeit, bevor ein Nutzer ein korrekt formatiertes Datum sieht.
Für ein Team ohne dedizierte i18n-Entwickler bedeutet dieser Aufwand oft, dass die Übersetzung hinter dem Produkt zurückbleibt — internationalen Nutzern werden englische Strings ausgeliefert, obwohl deren Sprache offiziell „unterstützt” wird.
Wann vue-i18n die richtige Wahl ist
Open-Source-Apps mit Community-Übersetzungen
Wenn Ihr Projekt auf Community-Mitwirkende für Übersetzungen angewiesen ist — üblich bei Open-Source-Tools —, lassen sich die JSON-Sprachdateien von vue-i18n nahtlos in Plattformen wie Crowdin oder Weblate integrieren, auf denen Übersetzer direkt an den Dateien arbeiten.
Strenger Freigabe-Workflow für Übersetzungen
Rechts-, Medizin- oder Behördenanwendungen, bei denen jeder String vor der Veröffentlichung geprüft und freigegeben werden muss, profitieren von der expliziten Kontrolle pro Schlüssel, die vue-i18n bietet.
Komplexe Zahlen-, Datums- und Währungsformatierung
Anwendungen, die Finanzdaten, wissenschaftliche Messwerte oder komplexe Datumsbereiche anzeigen, benötigen sprachspezifische Formatierungsregeln. Die integrierte ICU-Message-Unterstützung von vue-i18n deckt diese Fälle systematisch ab.
Apps mit Offline-Anforderung
Wenn Ihre Vue-App offline funktionieren muss (PWAs, Electron-Apps), müssen alle Sprachstrings gebündelt und ohne Netzwerkanfrage verfügbar sein. vue-i18n-Sprachdateien werden zur Build-Zeit gebündelt.
Wann automatische Übersetzung gewinnt
Bestehende Vue-App wird ohne Neuentwicklung mehrsprachig
Das nachträgliche Einbauen von vue-i18n in eine bestehende Vue-2- oder Vue-3-Anwendung bedeutet, jede Komponente anzufassen, die Text rendert — oft Hunderte von Dateien. Ein DOM-basiertes Übersetzungswidget benötigt nur einen einzigen Script-Tag und keine Komponentenänderungen.
Teams ohne dedizierte i18n-Entwickler
Sprachdateien akkurat zu pflegen erfordert jemanden, der sowohl das Produkt als auch jede Zielsprache versteht. Ohne diese Person liefert automatische Übersetzung bessere Ergebnisse als veraltete oder unvollständige Sprachdateien.
Schnelle UI-Iteration
Wenn sich das Produkt wöchentlich ändert, wird die Pflege von Übersetzungsschlüsseln mühsam. Jede Textänderung in der UI erfordert die Aktualisierung jeder Sprachdatei. Automatische Übersetzung verarbeitet neue Strings beim ersten Rendern ohne Entwicklereingriff.
SaaS-Produkte mit Fokus auf Time-to-Market
Internationale Umsätze erfordern, in diesen Märkten präsent zu sein. Ein DOM-basierter Ansatz bringt Sie an einem Nachmittag statt nach einem dreiwöchigen Engineering-Sprint zu „live auf Französisch”.
Wie Lingvit mit Vue funktioniert
Das Widget von Lingvit ist framework-agnostisch — es arbeitet auf DOM-Ebene, nicht auf Framework-Ebene. Für Vue-Apps:
- →Fügen Sie den Script-Tag in Ihrer
index.htmlvor</body>ein. Vue mountet, nachdem das Script geparst wurde, und das Widget initialisiert sich, sobald der DOM befüllt ist. - →Ein MutationObserver übernimmt Vues reaktives Rendering. Wenn
v-ifeinen Bereich anzeigt,v-foreine Liste rendert oder eine Komponente nach einer asynchronen Operation mountet, werden die neuen DOM-Knoten sofort übersetzt. - →Funktioniert mit Vue 2 und Vue 3. Die Rendering-Interna unterscheiden sich, aber die Ausgabe sind immer DOM-Knoten — mehr braucht das Widget nicht.
- →Nuxt.js wird unterstützt. Für Nuxt 3 (serverseitig gerendert) fügen Sie das Script über Nuxts
app.head.scriptinnuxt.config.tsmittagPosition: 'bodyClose'hinzu. Für Nuxt 2 verwenden Sie diehead-Eigenschaft innuxt.config.js.
Einrichtungsvergleich
vue-i18n-Einrichtung
- 1.
vue-i18ninstallieren undcreateI18ninmain.tskonfigurieren - 2.
src/locales/en.json,fr.jsonusw. erstellen - 3. Jeden Template-String in jeder Komponente mit
t()oder$t()umschließen - 4. Vite-Plugin für Lazy-Loading der Sprachen konfigurieren
- 5. UI-Komponente für Sprachumschaltung hinzufügen
- 6. Übersetzungsdateien pro Sprache befüllen
Lingvit-Einrichtung
- 1. Einen
<script>-Tag zuindex.htmlhinzufügen - 2. Zielsprachen im Dashboard auswählen
Häufig gestellte Fragen
- Funktioniert es mit Nuxt.js?
- Ja. Für Nuxt 3 fügen Sie das Script über app.head.script in nuxt.config.ts mit tagPosition: 'bodyClose' hinzu. Lingvit beobachtet den finalen DOM, nachdem Nuxts serverseitig gerendertes HTML hydratisiert ist und nach jeder clientseitigen Navigation über die Vue-Router-Integration.
- Funktioniert es mit Vue 2?
- Ja. Lingvit ist framework-agnostisch und arbeitet auf DOM-Ebene. Vue 2 und Vue 3 erzeugen beide Standard-DOM-Knoten, sodass der MutationObserver reaktive Updates unabhängig von der verwendeten Version behandelt.
- Was ist mit v-model-Eingabefeldern — wird vom Nutzer eingegebener Text übersetzt?
- Nein. Lingvit übersetzt Textknoten im DOM, aber nicht den Wert von Eingabeelementen, die an v-model gebunden sind. Von Nutzern eingegebener Inhalt ist standardmäßig ausgeschlossen. Sie können auch das Attribut data-lingvit-ignore zu jedem Element hinzufügen, um dessen Teilbaum von der Übersetzung auszuschließen.
Weitere Anleitungen
Fügen Sie Ihrer Vue-App Sprachen hinzu
Funktioniert mit Vue 2, Vue 3 und Nuxt.js. Ein Script-Tag, keine Neuentwicklung.