Ist vue-i18n im Jahr 2026 veraltet?

In der Vue-Community ist kaum eine Bibliothek so verbreitet wie vue-i18n. Seit Vue 2 von Kazupon gepflegt, treibt sie @nuxtjs/i18n an und gilt als Standard für mehrsprachige Vue-Apps.

Unsere Benchmarks 2026 lieferten jedoch ein bemerkenswertes Ergebnis: vue-i18n war die schwerste Lokalisierungs-Runtime über alle getesteten Frontend-Frameworks hinweg.

Ausgehend von einer schlanken Vite + Vue-Basis von 31.5 KB steigerte vue-i18n das durchschnittliche Seiten-JavaScript auf 136.4 KB, mehr als eine Vervierfachung des Payloads.

Wie konnte ein für seine Leichtigkeit geschätztes Framework einen derart schweren i18n-Stack hervorbringen? Und ist das klassische Runtime-Modell heute noch zeitgemäß?

Wichtigste Erkenntnisse

Schwerste getestete Runtime:

Mit 24.3 KB gzipped (83.2 KB minified) vor dem ersten Text ist vue-i18n etwa 9-mal schwerer als die 2.7 KB Runtime von intlayer.

330% Payload-Zuwachs:

vue-i18n vergrößerte eine 31.5 KB Vue-Seite auf 136.4 KB. Intlayer erzielte 59.3 KB, ein 56% kleinerer Seiten-Payload.

Versteckter Browser-Compiler:

Standardmäßig lädt vue-i18n einen vollständigen Nachrichten-Compiler in den Browser, um Texte zur Laufzeit zu parsen.

Wartungsfokus:

Im letzten Jahr verzeichnete vue-i18n ~259 Commits, fokussiert auf Bugfixes und Vue-Versionskompatibilität.

Fehlendes modernes Tooling:

Keine native Unterstützung für Language Server (LSP), KI-MCP-Server oder automatisierte CLI-Übersetzungspipelines.

Wartung vs. modernes Tooling

Alle Tabellendaten anzeigen

Alle Tabellendaten anzeigen

Tabelle in einem Modal öffnen, um alle Daten übersichtlich anzuzeigen

Repository	Stars	Commits gesamt	Commits / Jahr	Letzter Commit
intlify/vue-i18n
aymericzip/intlayer

Vergangene zwölf Monate:

• intlify/vue-i18n: 259 Commits (Pflege für Vue 3 und Nuxt).
• aymericzip/intlayer: 4.343 Commits (Compiler-Optimierungen, LSP-Erweiterungen und KI-Agenten-Unterstützung).

Eine etablierte Bibliothek bietet Stabilität. Moderne Frontend-Stacks nutzen jedoch AST-Transformationen im Build, Dead-Code-Elimination und KI-Lokalisierung. Eine reine Laufzeitarchitektur kann diese Entwicklungen nur schwer adaptieren.

Performance in Vite + Vue

Gemessen an einer Anwendung mit 10 Seiten und 10 Sprachen mit Vite und Vue 3:

Getestet in realen Browserumgebungen mit Gzip-Kompression. Vollständige Daten in der Vue-Benchmark-Dokumentation.

Basis-Overhead

Overhead vor dem Hinzufügen von Übersetzungstexten:

Die Runtime von vue-i18n wiegt allein 24.3 KB gzipped, fast so viel wie der gesamte Vue-Core. Intlayer fügt lediglich 2.7 KB hinzu.

Seitengewicht und Daten-Leakage

Wichtige Beobachtungen

Hoher relativer Zuwachs:

Da Vue von Haus aus sehr kompakt ist (~31 KB), vervierfacht vue-i18n das Gewicht der Anwendung.

Leakage anderer Seiten:

Standardmäßig gehören 90% der geladenen Übersetzungen zu anderen Seiten. Intlayer reduziert dies auf 0.0%.

Gewicht isolierter Komponenten:

Komponenten mit lokalen Scopes erreichten unter vue-i18n durchschnittlich 196 KB durch duplizierte Kataloge, verglichen mit 6.5 KB bei Intlayer.

Warum ist vue-i18n schwer?

Integrierter AST-Compiler im Browser

vue-i18n enthält einen eigenen Nachrichtenformat-Compiler. Pluralregeln und Variablenersetzungen werden zur Laufzeit in Abstract Syntax Trees überführt.

Um dies zu vermeiden, müssen Bundler-Aliase für vue-i18n/dist/vue-i18n.runtime.esm-bundler.js konfiguriert und Kataloge mit @intlify/unplugin-vue-i18n vorkompiliert werden. Viele Projekte übersehen diesen Schritt.

Monolithischer Funktionsumfang

vue-i18n bündelt Formatierer für Zahlen und Daten, verkettete Nachrichten, Brücken zur Options-API ($t, v-t) und reaktive Proxys. Selbst wenn Sie nur simple Strings in <script setup> übersetzen, zahlen Sie für das gesamte Paket.

Dynamische Schlüssel blockieren Tree-Shaking

Da "home.hero.title" dynamisch aufgelöst wird, können Bundler nicht ermitteln, welche Schlüssel genutzt werden. Ungenutzte Übersetzungen verbleiben im Bundle.

<script setup>
import { useI18n } from "vue-i18n";

const { t } = useI18n();
</script>

<template>
  <h1>{{ t("home.hero.title") }}</h1>
</template>

<script setup>
import { useIntlayer } from "vue-intlayer";

const { title } = useIntlayer("hero");
</script>

<template>
  <h1>{{ title }}</h1>
</template>

Der Intlayer-Compiler erfasst verwendete Eigenschaften präzise und entfernt ungenutzte Inhalte vor dem Erstellen der Client-Chunks. Details in der Bundle-Optimierung.

Entwicklererfahrung

Getrennte Kataloge vs. Co-Location

Bei vue-i18n liegen Texte in einem separaten locales/-Verzeichnis. Intlayer organisiert Inhaltsdateien direkt neben den Komponenten:

{
  "hero": {
    "title": "Ship in every language"
  }
}

{
  "hero": {
    "title": "Veröffentliche in jeder Sprache"
  }
}

<script setup>
import { useI18n } from "vue-i18n";

const { t } = useI18n();
</script>

<template>
  <h1>{{ t("hero.title") }}</h1>
</template>

import { t, type Dictionary } from "intlayer";

export default {
  key: "hero",
  content: {
    title: t({
      en: "Ship in every language",
      de: "Veröffentliche in jeder Sprache",
    }),
  },
} satisfies Dictionary;

<script setup>
import { useIntlayer } from "vue-intlayer";

const { title } = useIntlayer("hero");
</script>

<template>
  <h1>{{ title }}</h1>
</template>

Wird Hero.vue gelöscht oder verschoben, werden die Übersetzungen direkt mitangepasst.

Autovervollständigung vs. strikte Vollständigkeit

DefineLocaleMessage bietet Autovervollständigung gegen das Basisschema. Es garantiert jedoch nicht, dass alle Sprachen vollständig gepflegt sind. Fehlt ein Schlüssel in de.json, meldet TypeScript beim Build keinen Fehler.

Mit Intlayer werden Wörterbücher strikt geprüft. Das Aktivieren von strictMode lässt den Build bei jeder fehlenden Übersetzung fehlschlagen.

Modernes Tooling für IDEs und KI

Übersetzungspipelines

vue-i18n bietet keinen integrierten Übersetzungsbefehl. Teams greifen meist auf externe Dienste wie Crowdin oder Phrase zurück.

Intlayer liefert integrierte Werkzeuge:

Lokales KI-Auto-Fill (intlayer fill):

Ergänzt fehlende Übersetzungen mit eigenen API-Schlüsseln von OpenAI, Anthropic, Mistral oder Gemini.

Selbst hostbares visuelles CMS:

Nutzen Sie das Intlayer CMS, damit Content-Teams Texte visuell bearbeiten und direkt in Git committen können.

Freie Open-Source-Lizenz:

Die gesamte Toolchain steht unter Apache 2.0.

Wann bleibt vue-i18n sinnvoll?

Wie verbessere ich mein bestehendes vue-i18n-Setup?

Intlayer bietet Drop-in-Kompatibilitätspakete an, die exakt dieselben Funktionssignaturen von vue-i18n und @nuxtjs/i18n (useI18n, $t, <i18n-t>) bereitstellen. Sie müssen Ihre Templates oder Composables nicht neu schreiben, um von einer leichtgewichtigen, compilergestützten Architektur zu profitieren.

Die Einrichtung erfolgt mit einem einzigen Befehl:

npx intlayer init --interactive

Dieses interaktive CLI-Tool:

1. Installiert das Kompatibilitätspaket @intlayer/vue-i18n oder @intlayer/nuxt-i18n.
2. Richtet Vite- oder Nuxt-Bundler-Aliase ein, sodass Ihre bisherigen Importe und Template-Direktiven nahtlos auf Intlayer umgeleitet werden und vue-i18n aus der package.json entfernt werden kann.
3. Aktiviert sofort Sprachserver-Diagnosen (LSP), entfernt den 24-KB-AST-Parser aus dem Client-Bundle und schaltet lokale KI-Übersetzungsprozesse frei, ohne ein großes Refactoring zu verlangen.

Detaillierte Schritt-für-Schritt-Anleitungen finden Sie hier:

• Direkte Kompatibilität: Nutzen Sie bestehende Templates mit dem vue-i18n-Kompatibilitäts-Layer oder @nuxtjs/i18n-Kompatibilitäts-Layer.
• Geführte Migration: Konvertieren Sie JSON-Dateien mit unseren Migrationsleitfäden: von vue-i18n oder von @nuxtjs/i18n.
• Hybride Lösung: Behalten Sie vue-i18n für die Anzeige bei und verwenden Sie Intlayer mit vue-i18n für strikte Typen und lokale KI-Übersetzung.

Prüfen Sie Ihre Website mit dem kostenlosen i18n SEO Scanner:

Weiterführende Links

• Vue & Vite i18n Benchmark: Detaillierte Analyse
• vue-i18n vs Intlayer im direkten Vergleich
• Ist next-intl im Jahr 2026 veraltet?
• Compiler-gestützte vs. deklarative Internationalisierung