Vue i18n vs. automatische Übersetzung: der richtige Ansatz für Ihre Vue-App (2026)

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-extract helfen, 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- und numberFormats-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

Wann automatische Übersetzung gewinnt

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.html vor </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-if einen Bereich anzeigt, v-for eine 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.script in nuxt.config.ts mit tagPosition: 'bodyClose' hinzu. Für Nuxt 2 verwenden Sie die head-Eigenschaft in nuxt.config.js.

Einrichtungsvergleich

Häufig gestellte Fragen