@intlayer/docs 9.5.6 → 9.5.7

package/blog/de/vue-i18n_vs_intlayer.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2024-08-11
-updatedAt: 2025-08-23
+updatedAt: 2026-09-22
 title: vue-i18n vs Intlayer
 description: Vergleich von vue-i18n mit Intlayer für Internationalisierung (i18n) in Vue/Nuxt-Apps
 keywords:
@@ -20,6 +20,8 @@ author: aymericzip
 
 # vue-i18n VS Intlayer | Vue Internationalisierung (i18n)
 
+![Vue i18n library ecosystem](https://github.com/aymericzip/intlayer/blob/main/docs/assets/cloud_i18n_logo.webp?raw=true)
+
 Dieser Leitfaden vergleicht zwei beliebte i18n-Optionen für **Vue 3** (und **Nuxt**): **vue-i18n** und **Intlayer**.
 Wir konzentrieren uns auf moderne Vue-Tools (Vite, Composition API) und bewerten:
 
@@ -31,6 +33,8 @@ Wir konzentrieren uns auf moderne Vue-Tools (Vite, Composition API) und bewerten
 6. **Entwicklererfahrung (DX), Tools & Wartung**
 7. **SEO & Skalierbarkeit für große Projekte**
 
+<TOC/>
+
 > **Kurzfassung**: Beide können Vue-Apps lokalisieren. Wenn Sie **komponentenbezogenen Inhalt**, **strenge TypeScript-Typen**, **Build-Zeit-Prüfungen für fehlende Schlüssel**, **tree-shakbare Wörterbücher** und **integrierte Router-/SEO-Hilfen** sowie **Visuellen Editor & KI-Übersetzungen** wünschen, ist **Intlayer** die umfassendere, modernere Wahl.
 
 ## Übergeordnete Positionierung
@@ -38,6 +42,30 @@ Wir konzentrieren uns auf moderne Vue-Tools (Vite, Composition API) und bewerten
 - **vue-i18n** - Die de-facto i18n-Bibliothek für Vue. Flexible Nachrichtenformatierung (ICU-Stil), SFC-`<i18n>`-Blöcke für lokale Nachrichten und ein großes Ökosystem. Sicherheit und groß angelegte Wartung liegen größtenteils bei Ihnen.
 - **Intlayer** - Komponentenorientiertes Inhaltsmodell für Vue/Vite/Nuxt mit **strenger TS-Typisierung**, **Build-Zeit-Prüfungen**, **Tree-Shaking**, **Router- & SEO-Hilfen**, optionalem **Visuellen Editor/CMS** und **KI-unterstützten Übersetzungen**.
 
+## Was es zur Build-Zeit kostet
+
+Vor den Feature-Tabellen der gemessene Teil. [Benchmark Bloom](https://github.com/intlayer-org/benchmark-bloom) baut dieselbe Vite + Vue 3-App (10 Seiten, 10 Sprachen) mit jeder Bibliothek und zeichnet auf, was der Browser herunterlädt:
+
+<I18nBenchmark framework="vite-vue" vertical/>
+
+| Setup                | Lib size (gz) | Page JS avg (gz) | Page leak | Component avg (gz) |
+| -------------------- | ------------: | ---------------: | --------: | -----------------: |
+| **base** (no i18n)   |        0.0 KB |          41.3 KB |         - |             1.1 KB |
+| `vue-i18n`           |       24.3 KB |         134.9 KB |     90.0% |           196.0 KB |
+| `@intlayer/vue-i18n` |        7.9 KB |          47.0 KB |      0.0% |             8.4 KB |
+| **`vue-intlayer`**   |    **3.9 KB** |      **57.1 KB** |  **0.0%** |         **7.7 KB** |
+
+Die `vue-i18n`-Laufzeit allein wiegt **das 6-fache** von Intlayer, jede Seite transportiert **90% fremde Seiten-Strings**, und eine isoliert kompilierte Komponente schleppt **196 KB** mit sich, weil `useI18n()` sie an den globalen Nachrichtenbaum bindet. Der vollständige Durchlauf mit Reaktivitäts- und Seitenladezeiten findet sich im [vue-i18n vs Intlayer Benchmark](https://intlayer.org/de/blog/vue-i18n-vs-intlayer-benchmark).
+
+<ClickToOpenIframe
+src="https://intlayer.org/markdown?url=https%3A%2F%2Fraw.githubusercontent.com%2Fintlayer-org%2Fbenchmark-i18n%2Fmain%2Freport%2Fscripts%2Fsummarize-vite_vue.md"
+width="100%"
+height="600px"
+style="border:none;"
+/>
+
+> Vollständige Tabelle im [Vue-Benchmark-Bericht](https://intlayer.org/de/doc/benchmark/vue).
+
 ## Gegenüberstellung der Funktionen (Vue-fokussiert)
 
 | Funktion                                           | **Intlayer**                                                                                   | **vue-i18n**                                                                                               |
@@ -63,59 +91,74 @@ Wir konzentrieren uns auf moderne Vue-Tools (Vite, Composition API) und bewerten
 
 ## Tiefgehender Vergleich
 
-### 1) Architektur & Skalierbarkeit
+<AccordionGroup>
+<Accordion header="1) Architektur und Skalierbarkeit">
 
-- **vue-i18n**: Übliche Setups verwenden **zentralisierte Kataloge** pro Locale (optional aufgeteilt in Dateien/Namespaces). SFC-`<i18n>`-Blöcke erlauben lokale Nachrichten, aber Teams greifen oft auf gemeinsame Kataloge zurück, wenn Projekte wachsen.
+- **vue-i18n**: Übliche Setups verwenden **zentralisierte Kataloge** pro Locale (optional aufgeteilt in Dateien/Namespaces). SFC-`<i18n>`-Blöcke erlauben lokale Nachrichten, aber Teams greifen oft auf gemeinsame Kataloge zurück, wenn Projekte wachsen. Siehe [Komponenten-basierte vs. zentralisierte i18n](https://intlayer.org/de/blog/per-component-vs-centralized-i18n).
 - **Intlayer**: Fördert **pro-Komponenten-Wörterbücher**, die neben der jeweiligen Komponente gespeichert werden. Dies reduziert Konflikte zwischen Teams, hält Inhalte auffindbar und begrenzt natürlich Drift/ungenutzte Schlüssel.
 
 **Warum das wichtig ist:** In großen Vue-Anwendungen oder Designsystemen skaliert **modularer Inhalt** besser als monolithische Kataloge.
 
-### 2) TypeScript & Sicherheit
+</Accordion>
+<Accordion header="2) TypeScript und Sicherheit">
 
 - **vue-i18n**: Gute TS-Unterstützung; **strikte Schlüsseltypisierung** erfordert typischerweise benutzerdefinierte Schemata/Generics und sorgfältige Konventionen.
 - **Intlayer**: **Erzeugt strenge Typen** aus deinen Inhalten, bietet **IDE-Autovervollständigung** und **Kompilierzeit-Fehler** bei Tippfehlern oder fehlenden Schlüsseln.
 
 **Warum das wichtig ist:** Starke Typisierung erkennt Probleme **vor** der Laufzeit.
 
-### 3) Umgang mit fehlenden Übersetzungen
+</Accordion>
+<Accordion header="3) Behandlung fehlender Übersetzungen">
 
-- **vue-i18n**: **Laufzeit**-Warnungen/Fallbacks (z.B. Rückfall auf Locale oder Schlüssel).
-- **Intlayer**: **Buildzeit**-Erkennung mit Warnungen/Fehlern über alle Locales und Schlüssel hinweg.
+- **vue-i18n**: **Laufzeit**-Warnungen/Fallbacks (z.B. Rückfall auf Locale oder Schlüssel). Siehe [Erkennung fehlender Übersetzungen](https://intlayer.org/de/blog/detecting-missing-translations).
+- **Intlayer**: **Buildzeit**-Erkennung mit Warnungen/Fehlern über alle Locales und Schlüssel hinweg., plus `npx intlayer test` in CI.
 
 **Warum das wichtig ist:** Durchsetzung zur Buildzeit hält die Produktions-UI sauber und konsistent.
 
-### 4) Routing- & URL-Strategie (Vue Router/Nuxt)
+</Accordion>
+<Accordion header="4) Routing- und URL-Strategie (Vue Router/Nuxt)">
 
-- **Beide** können mit lokalisierten Routen arbeiten.
+- **Beide** können mit lokalisierten Routen arbeiten. Siehe den [hreflang-Leitfaden](https://intlayer.org/de/blog/hreflang-guide-multilingual-seo).
 - **Intlayer** bietet Hilfsmittel, um **lokalisierte Pfade zu generieren**, **Locale-Präfixe zu verwalten** und **`<link rel="alternate" hreflang>`** für SEO auszugeben. In Kombination mit Nuxt ergänzt es das Routing des Frameworks.
 
 **Warum das wichtig ist:** Weniger individuelle Verbindungs-Schichten und **saubereres SEO** über verschiedene Sprachen hinweg.
 
-### 5) Leistung & Ladeverhalten
+</Accordion>
+<Accordion header="5) Performance und Ladeverhalten">
 
-- **vue-i18n**: Unterstützt asynchrone Locale-Nachrichten; das Vermeiden von Über-Bundling liegt bei dir (Kataloge sorgfältig aufteilen).
+- **vue-i18n**: Unterstützt asynchrone Locale-Nachrichten; das Vermeiden von Über-Bundling liegt bei dir (Kataloge sorgfältig aufteilen). Der obige Benchmark belegt dies mit Zahlen: 134.9 KB gegenüber 57.1 KB pro Seite.
 - **Intlayer**: **Tree-shaking** zur Build-Zeit und **Lazy-Loading pro Wörterbuch/Locale**. Unbenutzte Inhalte werden nicht ausgeliefert.
 
 **Warum das wichtig ist:** Kleinere Bundles und schnellerer Start für mehrsprachige Vue-Anwendungen.
 
-### 6) Entwicklererfahrung & Werkzeuge
+</Accordion>
+<Accordion header="6) Entwicklererfahrung und Tooling">
 
 - **vue-i18n**: Ausgereifte Dokumentation und Community; in der Regel verlassen Sie sich auf **externe Lokalisierungsplattformen** für redaktionelle Workflows.
-- **Intlayer**: Bietet einen **kostenlosen visuellen Editor**, ein optionales **CMS** (Git-freundlich oder externalisiert), eine **VSCode-Erweiterung**, **CLI/CI**-Werkzeuge und **KI-unterstützte Übersetzungen** mit Ihren eigenen Anbieter-Schlüsseln.
+- **Intlayer**: Bietet einen **kostenlosen visuellen Editor**, ein optionales **CMS** (Git-freundlich oder externalisiert), eine **VSCode-Erweiterung**, **CLI/CI**-Werkzeuge und **KI-unterstützte Übersetzungen** mit Ihren eigenen Anbieter-Schlüsseln., ein **MCP-Server**
 
 **Warum das wichtig ist:** Geringere Betriebskosten und eine kürzere Entwicklungs-Content-Schleife.
 
-### 7) SEO, SSR & SSG
+</Accordion>
+<Accordion header="7) SEO, SSR und SSG">
 
-- **Beide** funktionieren mit Vue SSR und Nuxt.
+- **Beide** funktionieren mit Vue SSR und Nuxt. Siehe [Internationalisierung und SEO](https://intlayer.org/de/blog/SEO-and-i18n).
 - **Intlayer**: Fügt **SEO-Hilfsmittel** hinzu (Sitemaps/Metadaten/`hreflang`), die frameworkunabhängig sind und gut mit Vue/Nuxt-Builds zusammenarbeiten.
 
 **Warum das wichtig ist:** Internationale SEO ohne maßgeschneiderte Verkabelung.
 
+</Accordion>
+</AccordionGroup>
+
 ## Warum Intlayer? (Problem & Ansatz)
 
+![Centralized catalogs versus per-component dictionaries](https://github.com/aymericzip/intlayer/blob/main/docs/assets/project_stucture_18n_vs_intlayer.png?raw=true)
+
 Die meisten i18n-Stacks (einschließlich **vue-i18n**) starten mit **zentralisierten Katalogen**:
 
+<Tabs defaultTab="per-locale" group="catalog">
+<Tab label="Eine Datei pro Sprache" value="per-locale">
+
 ```bash
 .
 ├── locales
@@ -127,7 +170,8 @@ Die meisten i18n-Stacks (einschließlich **vue-i18n**) starten mit **zentralisie
         └── MyComponent.vue
 ```
 
-Oder mit pro-Locale-Ordnern:
+</Tab>
+<Tab label="Ein Ordner pro Sprache" value="per-folder">
 
 ```bash
 .
@@ -146,6 +190,34 @@ Oder mit pro-Locale-Ordnern:
         └── MyComponent.vue
 ```
 
+</Tab>
+</Tabs>
+
+Dieser Ordner wächst ständig, ein Namespace pro Feature in jeder Sprache:
+
+```txt
+locales
+├── EN
+│   ├── blog.json
+│   ├── about.json
+│   ├── auth.json
+│   ├── blog.json
+│   ├── cart.json
+│   ├── categories.json
+│   ├── contact.json
+│   ├── dashboard.json
+│   ├── errors.json
+│   ├── faq.json
+│   ├── footer.json
+│   ├── form.json
+│   ├── home.json
+│   ├── language.json
+│   ├── navbar.json
+│   ├── ... 65 files
+│   └── validation.json
+└── ES
+```
+
 Dies verlangsamt die Entwicklung oft, wenn Anwendungen wachsen:
 
 1. **Für eine neue Komponente** erstellen/bearbeiten Sie entfernte Kataloge, verbinden Namespaces und übersetzen (oft durch manuelles Kopieren/Einfügen aus KI-Tools).
@@ -161,7 +233,33 @@ Dies verlangsamt die Entwicklung oft, wenn Anwendungen wachsen:
         └── MyComponent.vue
 ```
 
-**Inhaltsdeklaration** (pro Komponente):
+<Tabs defaultTab="intlayer" group="techno">
+<Tab label="vue-i18n" value="vue-i18n">
+
+```json fileName="./locales/en.json"
+{
+  "componentExample": {
+    "greeting": "Hello World"
+  }
+}
+```
+
+```vue fileName="./components/MyComponent.vue"
+<script setup lang="ts">
+import { useI18n } from "vue-i18n";
+
+const { t } = useI18n();
+</script>
+
+<template>
+  <span>{{ t("componentExample.greeting") }}</span>
+</template>
+```
+
+Jede Sprachdatei muss manuell bearbeitet werden, und der Schlüssel ist eine einfache Zeichenkette: Ein Tippfehler wird in der Produktion als `componentExample.greting` ausgegeben.
+
+</Tab>
+<Tab label="Intlayer" value="intlayer">
 
 ```ts fileName="./components/MyComponent/myComponent.content.ts"
 import { t, type Dictionary } from "intlayer";
@@ -171,8 +269,8 @@ const componentExampleContent = {
   content: {
     greeting: t({
       en: "Hello World",
-      es: "Hola Mundo",
       fr: "Bonjour le monde",
+      es: "Hola Mundo",
     }),
   },
 } satisfies Dictionary;
@@ -180,11 +278,10 @@ const componentExampleContent = {
 export default componentExampleContent;
 ```
 
-**Verwendung in Vue** (Composition API):
-
 ```vue fileName="./components/MyComponent/MyComponent.vue"
 <script setup lang="ts">
-import { useIntlayer } from "vue-intlayer"; // Vue-Integration
+import { useIntlayer } from "vue-intlayer"; // Vue integration
+
 const { greeting } = useIntlayer("component-example");
 </script>
 
@@ -193,6 +290,11 @@ const { greeting } = useIntlayer("component-example");
 </template>
 ```
 
+Alle Sprachen liegen in einer einzigen typisierten Datei neben der Komponente.
+
+</Tab>
+</Tabs>
+
 Dieser Ansatz:
 
 - **Beschleunigt die Entwicklung** (einmal deklarieren; IDE/AI vervollständigt automatisch).
@@ -220,22 +322,71 @@ Dieser Ansatz:
 
 ## Wann welches wählen?
 
-- **Wählen Sie vue-i18n**, wenn Sie den **standardmäßigen Vue-Ansatz** bevorzugen, gerne selbst Kataloge/Namespaces verwalten und Ihre App **klein bis mittelgroß** ist (oder Sie bereits Nuxt i18n verwenden).
-- **Wählen Sie Intlayer**, wenn Sie **komponentenbezogenen Inhalt**, **striktes TypeScript**, **Build-Zeit-Garantien**, **Tree-Shaking** und **umfangreiche Routing/SEO/Editor-Tools** schätzen – besonders für **große, modulare Vue/Nuxt-Codebasen**.
+<AccordionGroup>
+<Accordion header="vue-i18n wählen">
+
+Sie möchten den **Standard-Vue-Ansatz**, können Kataloge und Namespaces problemlos selbst verwalten und Ihre Anwendung ist **klein bis mittelgroß** (oder Sie setzen bereits auf Nuxt i18n). SFC `<i18n>`-Blöcke und Laufzeit-`setLocaleMessage()` sind Funktionen, die Intlayer bewusst nicht repliziert.
+
+</Accordion>
+<Accordion header="Intlayer wählen">
+
+Sie legen Wert auf **komponentenbezogenen Inhalt**, **striktes TypeScript**, **Garantien zur Build-Zeit**, **Tree-Shaking** und integrierte Routing-, SEO- und Editor-Tools, insbesondere für **große, modulare Vue/Nuxt-Codebasen** und Design-Systeme. Starten Sie mit [Intlayer mit Vue](https://intlayer.org/de/doc/environment/vite-and-vue) oder [mit Nuxt](https://intlayer.org/de/doc/environment/nuxt-and-vue).
+
+</Accordion>
+<Accordion header="@intlayer/vue-i18n wählen">
+
+Sie nutzen heute `vue-i18n` und möchten Bundle-Einsparungen ohne Bearbeitung einer `.vue`-Datei erzielen. Der [Kompatibilitätsadapter](https://intlayer.org/de/doc/compatibility/vue-i18n) behält `createI18n`, `useI18n`, `t()`, `d()`, `n()`, `$t` und `v-t` bei und bedient sie aus kompilierten Wörterbüchern. Seite an Seite gemessen in [vue-i18n vs @intlayer/vue-i18n](https://intlayer.org/de/blog/vue-i18n-vs-intlayer-vue-i18n).
+
+</Accordion>
+</AccordionGroup>
 
 ## Interoperabilität mit vue-i18n
 
 `intlayer` kann auch bei der Verwaltung deiner `vue-i18n` Namespaces helfen.
 
-Mit `intlayer` kannst du deinen Content im Format deiner bevorzugten i18n-Bibliothek deklarieren, und intlayer generiert deine Namespaces an dem Ort deiner Wahl (Beispiel: `/messages/{{locale}}/{{namespace}}.json`).
+Mit `intlayer` kannst du deinen Content im Format deiner bevorzugten i18n-Bibliothek deklarieren, und intlayer generiert deine Namespaces an dem Ort deiner Wahl (Beispiel: `/messages/{{locale}}/{{namespace}}.json`). Siehe die [vue-i18n-Kompatibilitätsdokumentation](https://intlayer.org/de/doc/compatibility/vue-i18n) und den [Nuxt i18n-Adapter](https://intlayer.org/de/doc/compatibility/nuxtjs-i18n).
+
+## FAQ
+
+<FAQ>
+
+<Question title="Ist Intlayer ein Ersatz für vue-i18n oder eine Schicht darüber?">
+
+Beides, je nachdem, wie Sie es einsetzen. `vue-intlayer` ist eine native Laufzeit mit einem eigenen `useIntlayer()`-Composable. `@intlayer/vue-i18n` ist ein Kompatibilitätsadapter, der die `vue-i18n`-API beibehält und deren Bindung austauscht, sodass Sie ohne Änderung der Komponenten migrieren und später Datei für Datei umstellen können.
+
+</Question>
+
+<Question title="Was passiert mit meinen SFC <i18n>-Blöcken?">
+
+Der Adapter liest sie nicht. Verschieben Sie diese Nachrichten in Ihre Sprach-JSON oder in eine `.content.ts`-Datei neben der Komponente, was dieselbe Idee mit generierten Typen darstellt. Das ist die einzige `vue-i18n`-Funktion, die nicht übernommen wird.
 
-## Praktische Migrationshinweise (vue-i18n → Intlayer)
+</Question>
 
-- **Pro Funktion starten**: Verschieben Sie eine Route/Ansicht/Komponente nach der anderen in lokale Intlayer-Wörterbücher.
-- **Brücke während der Migration**: Behalten Sie die vue-i18n-Kataloge parallel bei; ersetzen Sie die Abfragen schrittweise.
-- **Strenge Prüfungen aktivieren**: Lassen Sie fehlende Schlüssel/Locales frühzeitig zur Build-Zeit erkennen.
-- **Router/SEO-Hilfen übernehmen**: Standardisieren Sie die Lokalerkennung und `hreflang`-Tags.
-- **Bundles messen**: Erwarten Sie **Reduzierungen der Bundle-Größe**, da ungenutzte Inhalte ausgeschlossen werden.
+<Question title="Funktioniert Intlayer mit Nuxt?">
+
+Ja. [Intlayer mit Nuxt](https://intlayer.org/de/doc/environment/nuxt-and-vue) umfasst mehrsprachiges Routing, Middleware zur Spracherkennung und Sitemap-Generierung. Wenn Sie `@nuxtjs/i18n` nutzen, ist der [Nuxt i18n-Kompatibilitätsadapter](https://intlayer.org/de/doc/compatibility/nuxtjs-i18n) der Migrationspfad.
+
+</Question>
+
+<Question title="Kann ich meine locales/{locale}.json als Source of Truth behalten?">
+
+Ja. Das [JSON-Sync-Plugin](https://intlayer.org/de/doc/compatibility/vue-i18n) liest sie mit dem `vue-i18n`-Dialekt (`{name}`, `{0}`, Pipe-Plurale `"car | cars"`) und schreibt Übersetzungen zurück, wenn die CLI oder das CMS sie aktualisiert.
+
+</Question>
+
+<Question title="Funktioniert ICU mit Intlayer auf Vue?">
+
+Die native ICU-Unterstützung ist in Arbeit. Der `@intlayer/vue-i18n`-Adapter unterstützt die eigene Nachrichtensyntax von `vue-i18n`, einschließlich Pipe-Pluralen sowie benannter und Listen-Interpolation. Für das Pluralisierungsmodell von Intlayer siehe [Aufzählungsinhalt](https://intlayer.org/de/doc/concept/content/enumeration).
+
+</Question>
+
+</FAQ>
+
+## GitHub STARs
+
+GitHub-Stars sind ein starker Indikator für die Beliebtheit eines Projekts, das Vertrauen der Community und die langfristige Relevanz. Sie sind zwar kein direktes Maß für die technische Qualität, spiegeln jedoch wider, wie viele Entwickler das Projekt nützlich finden, seine Fortschritte verfolgen und es wahrscheinlich übernehmen werden. Zur Bewertung des Projektwerts helfen Stars dabei, das Interesse alternativer Lösungen zu vergleichen und Einblicke in das Wachstum des Ökosystems zu gewinnen.
+
+[![Star History Chart](https://api.star-history.com/chart?repos=intlify%2Fvue-i18n%2Caymericzip%2Fintlayer&type=date&legend=top-left)](https://star-history.com/#intlify/vue-i18n&aymericzip/intlayer)
 
 ## Fazit
 
@@ -244,4 +395,15 @@ Sowohl **vue-i18n** als auch **Intlayer** lokalisieren Vue-Apps gut. Der Untersc
 - Mit **Intlayer** sind **modularer Inhalt**, **striktes TypeScript**, **Build-Zeit-Sicherheit**, **baumgeschüttelte Bundles** sowie **Router-/SEO-/Editor-Tools** **standardmäßig enthalten**.
 - Wenn Ihr Team **Wartbarkeit und Geschwindigkeit** in einer mehrsprachigen, komponentenbasierten Vue/Nuxt-Anwendung priorisiert, bietet Intlayer heute die **vollständigste** Erfahrung.
 
-Siehe das Dokument ['Warum Intlayer?'](https://intlayer.org/doc/why) für weitere Details.
+## Weiterführende Literatur
+
+- [vue-i18n vs Intlayer benchmark](https://intlayer.org/de/blog/vue-i18n-vs-intlayer-benchmark), der gemessene Durchlauf hinter der obigen Tabelle
+- [vue-i18n vs @intlayer/vue-i18n](https://intlayer.org/de/blog/vue-i18n-vs-intlayer-vue-i18n), der Adapter auf derselben App
+- [Is vue-i18n outdated?](https://intlayer.org/de/blog/is-vue-i18n-outdated)
+- [How to pick a Vue i18n library](https://intlayer.org/de/blog/how-to-pick-vue-i18n-library)
+- [Using Intlayer with vue-i18n](https://intlayer.org/de/blog/intlayer-with-vue-i18n)
+- [Vue benchmark report](https://intlayer.org/de/doc/benchmark/vue)
+- [Migration guide: vue-i18n to Intlayer](https://intlayer.org/de/doc/migration/vue-i18n)
+- [Bundle optimization](https://intlayer.org/de/doc/concept/bundle-optimization) and [the Intlayer compiler](https://intlayer.org/de/doc/compiler)
+
+Refer to ['Why Intlayer?' doc](https://intlayer.org/de/doc/why) for more details.

package/blog/en/i18next_vs_intlayer-i18next.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2026-09-13
-updatedAt: 2026-09-13
+updatedAt: 2026-09-22
 title: "i18next vs @intlayer/i18next: Same API, Different Bundle"
 description: What changes when a React or Next.js app keeps its i18next, react-i18next and next-i18next calls but serves them through the @intlayer/i18next adapters. Per-page JavaScript, component size, leakage and hydration measured on the same code, plus what the adapters keep, ignore and cannot replace.
 keywords:
@@ -28,6 +28,8 @@ author: aymericzip
 
 # i18next VS @intlayer/i18next | Same API, Different Bundle
 
+![i18next VS Intlayer](https://github.com/aymericzip/intlayer/blob/main/docs/assets/i18next-next-intl-intlayer.webp?raw=true)
+
 `@intlayer/i18next`, `@intlayer/react-i18next` and `@intlayer/next-i18next` are compat adapters. They expose the `i18next` API your code already uses (`useTranslation`, `t()`, `<Trans>`, `i18n.changeLanguage()`, `getFixedT`, `serverSideTranslations`...) and serve it from dictionaries compiled by Intlayer. The components do not change. The runtime underneath them does.
 
 This article measures that swap on the same Next.js application, built once with `next-i18next` and once with `@intlayer/next-i18next`. The numbers come from [Benchmark Bloom](https://github.com/intlayer-org/benchmark-bloom). For `i18next` and Intlayer compared as libraries, read [i18next vs Intlayer](https://intlayer.org/blog/i18next-vs-intlayer). This one is about what the adapter changes when you keep your code as it is.
@@ -109,6 +111,10 @@ For each build, the suite records:
 
 ### Results on Next.js
 
+Pick the metrics and the libraries you care about:
+
+<I18nBenchmark framework="nextjs" vertical/>
+
 | Setup                        | Strategy       | Lib size (gz) | Page JS avg (gz) | Locale leak | Page leak | Component avg (gz) | E2E reactivity |   Hydration |
 | ---------------------------- | -------------- | ------------: | ---------------: | ----------: | --------: | -----------------: | -------------: | ----------: |
 | **base** (no i18n)           | -              |        0.0 KB |         141.0 KB |        0.0% |      0.0% |             0.9 KB |        13.4 ms |     11.8 ms |
@@ -129,10 +135,21 @@ For each build, the suite records:
 - **Hydration and switching are faster.** Hydration goes from 15.6 ms to **11.3 ms** (and from 27.7 ms in the `dynamic` setup, where the backend fetch sits on the critical path). Locale switching goes from 15-16 ms to **11-12 ms**.
 - **The adapter is not the native runtime.** `next-intlayer` lands at **141.3 KB**, +0.3 KB over the base app. The adapter carries the `i18next` API surface (interpolation dialect, plural and context suffix resolution, `<Trans>` tag parsing) on top of Intlayer's core: 9.4 KB and +9.4 KB per page over native. It is the bridge, not the destination.
 
+<ClickToOpenIframe
+src="https://intlayer.org/markdown?url=https%3A%2F%2Fraw.githubusercontent.com%2Fintlayer-org%2Fbenchmark-i18n%2Fmain%2Freport%2Fscripts%2Fsummarize-nextjs.md"
+width="100%"
+height="600px"
+style="border:none;"
+/>
+
+> Full table, every library and every strategy, in the [Next.js benchmark report](https://intlayer.org/doc/benchmark/nextjs).
+
 > The `react-i18next` adapter on Vite / TanStack Start was not part of this run. The `react-i18next` baseline on TanStack Start is in [i18next vs Intlayer](https://intlayer.org/blog/i18next-vs-intlayer): 127-184 KB per page and a 123-185 ms locale switch when the backend is lazy.
 
 ## Why the numbers move
 
+![The Intlayer compiler extracts content from components](https://github.com/aymericzip/intlayer/blob/main/docs/assets/compiler.webp?raw=true)
+
 Nothing in `components/` changed, so the gains come from what `useTranslation` is bound to.
 
 **With `i18next`**, the binding is the global instance. Whatever was loaded into it (all locales in `static`, the active locale's whole namespace in `dynamic`) is reachable from every component that calls `useTranslation()`. The bundler cannot split below what the instance holds, and the runtime cannot know which keys a component will ask for.
@@ -149,6 +166,10 @@ Nothing in `components/` changed, so the gains come from what `useTranslation` i
     └── About.tsx                     # useTranslation(); t("about.title")
 ```
 
+Whatever the instance holds ships to every page, and the waste grows on two axes, pages and locales:
+
+![Theoretical content leakage by architecture](https://github.com/aymericzip/intlayer/blob/main/docs/assets/theorical_content_leakage.webp?raw=true)
+
 **With `@intlayer/next-i18next`**, the binding is the dictionary. `syncJSON` turns each namespace file into a dictionary; the optimize pass hands the component the dictionary it names, as an import the bundler can trace and split per page and per locale.
 
 ```bash
@@ -297,26 +318,112 @@ export default defineConfig({
 
 ## Limits to know before you start
 
-- **Backends and detectors are inert.** `i18n.use(HttpBackend)` calls the plugin's `init` and nothing else. If your app relied on fetching translations from a CMS at runtime, that flow is gone; use Intlayer's CMS or the `intlayer pull` / `push` commands instead.
-- **`resources` is ignored, not merged.** Unlike some other adapters, `@intlayer/i18next` does not use inline `resources` as a fallback. Every key must exist in the synced dictionaries, which `intlayer test` verifies.
-- **App Router needs the provider edit.** One file, shown above. Pages Router with `appWithTranslation` needs nothing.
-- **`next-i18next.config.js` is not read.** `localePath`, `fallbackLng`, `reloadOnPrerender` and friends have no equivalent; locales and fallback come from `intlayer.config.ts`.
-- **The adapter is not free.** 9.4 KB of runtime and +9.4 KB per page over `next-intlayer`. Once every component has moved to `useIntlayer`, drop it.
+<AccordionGroup>
+<Accordion header="Backends and detectors are inert">
+
+`i18n.use(HttpBackend)` calls the plugin's `init` and nothing else. If your app relied on fetching translations from a CMS at runtime, that flow is gone; use the [Intlayer CMS](https://intlayer.org/doc/concept/cms) or the `intlayer pull` / `push` commands instead. Locale detection becomes Intlayer's routing config (URL prefix, cookie, header).
+
+</Accordion>
+<Accordion header="resources is ignored, not merged">
+
+Unlike some other adapters, `@intlayer/i18next` does not use inline `resources` as a fallback. Every key must exist in the synced dictionaries, which `intlayer test` verifies.
+
+</Accordion>
+<Accordion header="App Router needs the provider edit">
+
+One file, shown above. Pages Router with `appWithTranslation` needs nothing.
+
+</Accordion>
+<Accordion header="next-i18next.config.js is not read">
+
+`localePath`, `fallbackLng`, `reloadOnPrerender` and friends have no equivalent; locales and fallback come from `intlayer.config.ts`.
+
+</Accordion>
+<Accordion header="The adapter is not free">
+
+9.4 KB of runtime and +9.4 KB per page over `next-intlayer`. Once every component has moved to `useIntlayer`, drop it.
+
+</Accordion>
+</AccordionGroup>
 
 ## When to use which?
 
-- **Stay on `i18next`** if your app depends on runtime backends (translations served by a CMS at request time), on the plugin ecosystem, or on a non-React target the adapters do not cover.
-- **Use `@intlayer/*`** if you are on `react-i18next` / `next-i18next` and want the 68 KB, the 8x smaller components, 0% leakage, typed keys and CI checks without a rewrite. This is the entry point for an existing `i18next` codebase.
-- **Go native (`next-intlayer` / `react-intlayer`)** for new projects, or once the adapter has done its job. It is the lightest of the three (5.5 KB, +0.3 KB per page) and unlocks synchronous server components and per-component `.content.ts` files.
+<AccordionGroup>
+<Accordion header="Stay on i18next">
+
+Your app depends on runtime backends (translations served by a CMS at request time), on the plugin ecosystem, or on a non-React target the adapters do not cover.
+
+</Accordion>
+<Accordion header="Use @intlayer/*">
+
+You are on `react-i18next` / `next-i18next` and want the 68 KB, the 8x smaller components, 0% leakage, typed keys and CI checks without a rewrite. This is the entry point for an existing `i18next` codebase.
+
+</Accordion>
+<Accordion header="Go native (next-intlayer / react-intlayer)">
+
+For new projects, or once the adapter has done its job. It is the lightest of the three (5.5 KB, +0.3 KB per page) and unlocks synchronous server components and per-component `.content.ts` files. Start with [Intlayer with Next.js](https://intlayer.org/doc/environment/nextjs) or [with Vite and React](https://intlayer.org/doc/environment/vite-and-react).
+
+</Accordion>
+</AccordionGroup>
+
+## FAQ
+
+<FAQ>
+
+<Question title="Where do the 68 KB come from?">
+
+From `resources: { en, fr, ... }`. The naive `next-i18next` setup imports every locale's JSON into `init()`, so every page carries every namespace in every language: **218.5 KB** per page. The adapter never bundles that block; it hands each component the dictionary it names, in the active locale.
+
+</Question>
+
+<Question title="Do my <Trans> components keep working?">
+
+Yes, with `components`, numbered `<1>...</1>` tags and `values`. So do `{{interpolation}}`, `$t(key)` nesting, `key_one` / `key_other` plurals (evaluated with `Intl.PluralRules`), context suffixes and `returnObjects`.
+
+</Question>
+
+<Question title="What if I use a single translation.json per locale?">
+
+Set `splitKeys: false` in the `syncJSON` plugin. The whole file stays one dictionary and a bare `useTranslation()` keeps resolving against it.
+
+</Question>
+
+<Question title="Is this the same as migrating to Intlayer?">
+
+No, it is the bridge. The adapter keeps the `i18next` API and costs 9.4 KB of runtime; native `next-intlayer` costs 5.5 KB and adds synchronous server components and co-located `.content.ts` files. You can move component by component, since JSON and `.content.ts` dictionaries coexist.
+
+</Question>
+
+<Question title="Can translators keep working the way they do today?">
+
+Yes. `locales/{lng}/{ns}.json` stays the source of truth: `syncJSON` reads it with the i18next dialect and writes translations back when the CLI or the CMS updates them.
+
+</Question>
+
+</FAQ>
 
 ## Related comparisons
 
-- [i18next vs Intlayer](https://intlayer.org/blog/i18next-vs-intlayer) (the libraries, same benchmark)
-- [next-intl vs @intlayer/next-intl](https://intlayer.org/blog/next-intl-vs-intlayer-next-intl) (same adapter series)
-- [Lingui vs @intlayer/lingui](https://intlayer.org/blog/lingui-vs-intlayer-lingui) (same adapter series)
-- [vue-i18n vs @intlayer/vue-i18n](https://intlayer.org/blog/vue-i18n-vs-intlayer-vue-i18n) (same adapter series)
+Same adapter series:
+
+- [next-intl vs @intlayer/next-intl](https://intlayer.org/blog/next-intl-vs-intlayer-next-intl)
+- [Lingui vs @intlayer/lingui](https://intlayer.org/blog/lingui-vs-intlayer-lingui)
+- [vue-i18n vs @intlayer/vue-i18n](https://intlayer.org/blog/vue-i18n-vs-intlayer-vue-i18n)
+
+The libraries compared head to head:
+
+- [i18next vs Intlayer](https://intlayer.org/blog/i18next-vs-intlayer), same benchmark
+- [next-i18next vs next-intl vs Intlayer](https://intlayer.org/blog/next-i18next-vs-next-intl-vs-intlayer)
+- [react-i18next vs react-intl vs Intlayer](https://intlayer.org/blog/react-i18next-vs-react-intl-vs-intlayer)
+- [Is i18next outdated?](https://intlayer.org/blog/is-i18next-outdated)
+
+Reference docs:
+
+- Compat adapters: [i18next](https://intlayer.org/doc/compatibility/i18next), [react-i18next](https://intlayer.org/doc/compatibility/react-i18next), [next-i18next](https://intlayer.org/doc/compatibility/next-i18next)
 - Migration guides: [i18next](https://intlayer.org/doc/migration/i18next), [react-i18next](https://intlayer.org/doc/migration/react-i18next), [next-i18next](https://intlayer.org/doc/migration/next-i18next)
-- Compat adapter references: [i18next](https://intlayer.org/doc/compatibility/i18next), [react-i18next](https://intlayer.org/doc/compatibility/react-i18next), [next-i18next](https://intlayer.org/doc/compatibility/next-i18next)
+- [Next.js benchmark report](https://intlayer.org/doc/benchmark/nextjs) and [TanStack Start benchmark report](https://intlayer.org/doc/benchmark/tanstack)
+- [Bundle optimization](https://intlayer.org/doc/concept/bundle-optimization) and [the Intlayer compiler](https://intlayer.org/doc/compiler)
+- [Visual Editor](https://intlayer.org/doc/concept/editor), [CMS](https://intlayer.org/doc/concept/cms) and [AI translation](https://intlayer.org/doc/concept/auto-fill)
 
 ## Conclusion