@intlayer/docs 9.5.6 → 9.5.7

package/blog/de/next-intl_vs_intlayer-next-intl.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2026-09-13
-updatedAt: 2026-09-13
+updatedAt: 2026-09-22
 title: "next-intl vs @intlayer/next-intl: Gleiche API, Unterschiedliches Bundle"
 description: Was sich ändert, wenn die next-intl-Importe einer Next.js-App vom @intlayer/next-intl-Kompatibilitäts-Adapter bereitgestellt werden. Bundle-Größe, Speicherlecks, Komponentengröße und Hydration gemessen an denselben Code, plus was der Adapter behält, ignoriert und nicht ersetzen kann.
 keywords:
@@ -26,6 +26,8 @@ author: aymericzip
 
 # next-intl VS @intlayer/next-intl | Gleiche API, Unterschiedliches Bundle
 
+![next-intl VS Intlayer](https://github.com/aymericzip/intlayer/blob/main/docs/assets/i18next-next-intl-intlayer.webp?raw=true)
+
 `@intlayer/next-intl` ist ein Compat-Adapter: Er stellt die `next-intl` API (`useTranslations`, `getTranslations`, `useLocale`, `t.rich()`, ICU Plurals, `NextIntlClientProvider`...) bereit und serviert diese aus von Intlayer kompilierten Dictionaries. Der Application Code ändert sich nicht. Das Bundle schon.
 
 Dieser Artikel vergleicht die beiden auf derselben Next.js-Anwendung, einmal gebaut mit `next-intl` und einmal mit dem Adapter. Die Zahlen stammen von [Benchmark Bloom](https://github.com/intlayer-org/benchmark-bloom), einer Open-Source-Suite, die aufzeichnet, was der Browser tatsächlich herunterlädt. Wenn Sie den `next-intl` vs Intlayer Vergleich als Bibliotheken möchten, lesen Sie [next-intl vs Intlayer](https://intlayer.org/blog/next-intl-vs-intlayer). Dieser Artikel handelt davon, was der Adapter ändert, wenn Sie Ihre Komponenten unverändert lassen.
@@ -109,6 +111,10 @@ Für jeden Build zeichnet die Suite auf:
 
 ### Ergebnisse auf Next.js
 
+Wählen Sie die Metriken und Bibliotheken aus, die für Sie wichtig sind:
+
+<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,6 +135,15 @@ Für jeden Build zeichnet die Suite auf:
 - **Hydration ist 2 ms schneller** (12,8 vs 14,7 ms): Es gibt kein Message-Objekt, das vor der React-Hydration aus der RSC-Payload deserialisiert werden muss.
 - **Der Adapter ist nicht die native Runtime.** `next-intlayer` liegt bei **141,3 KB**, +0,3 KB über der Base-App, mit einer 5,5 KB Runtime. Der Adapter bietet die `next-intl` API-Oberfläche (`useFormatter`, `t.rich`, der ICU-Resolver) auf top von Intlayers Core, daher 8,0 KB und +6 KB pro Seite. Es ist die Brücke, nicht das Ziel.
 
+<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;"
+/>
+
+> Vollständige Tabelle, jede Bibliothek und jede Strategie, im [Next.js-Benchmark-Bericht](https://intlayer.org/de/doc/benchmark/nextjs).
+
 ### Ergebnisse auf TanStack Start (`use-intl`)
 
 `use-intl` ist der Framework-agnostische Core von `next-intl`. Sein Adapter, `@intlayer/use-intl`, folgt dem gleichen Design mit einem Vite-Plugin (`@intlayer/use-intl/plugin`).
@@ -152,11 +167,24 @@ Für jeden Build zeichnet die Suite auf:
 - **Locale-Wechsel ist schneller.** Die optimierten `use-intl` Setups benötigen **13-21 ms** um `html[lang]` zu aktualisieren; der Adapter benötigt **4-9 ms**. Weniger Komponenten werden neu gerendert, und nichts wird aus einem Message-Baum neu ausgewählt.
 - **`static` behält jedes Locale.** Die `static` Zeile des Adapters zeigt 49,7% Locale-Leckage, dasselbe wie natives Intlayer im `static` Modus: alle Locales werden gebündelt, nur die Dictionaries der Seite. Eine Konfigurationszeile (`importMode: 'dynamic'`) entfernt es.
 
+<ClickToOpenIframe
+src="https://intlayer.org/markdown?url=https%3A%2F%2Fraw.githubusercontent.com%2Fintlayer-org%2Fbenchmark-i18n%2Fmain%2Freport%2Fscripts%2Fsummarize-tanstack.md"
+width="100%"
+height="600px"
+style="border:none;"
+/>
+
+> Vollständige Tabelle im [TanStack Start-Benchmark-Bericht](https://intlayer.org/de/doc/benchmark/tanstack).
+
 ## Warum sich die Zahlen ändern
 
+![The Intlayer compiler extracts content from components](https://github.com/aymericzip/intlayer/blob/main/docs/assets/compiler.webp?raw=true)
+
 Nichts in der Komponente hat sich geändert, daher stammen die Verbesserungen vollständig davon, woran `useTranslations` gebunden ist.
 
-**Mit `next-intl`** ist die Bindung der Provider. `NextIntlClientProvider` erhält das gesamte `messages`-Objekt für das Locale; jeder `useTranslations("about")`-Aufruf liest daraus. Der Bundler sieht eine Komponente, die einen Hook importiert, der einen Context liest, und kann nicht wissen, dass nur der `about`-Zweig verwendet wird. Die Routen unten teilen sich alle das gleiche Message-Objekt, daher zeigt die Spalte page-leak ~90%, bis du die Datei selbst aufteilst.
+**Mit `next-intl`** ist die Bindung der Provider. `NextIntlClientProvider` erhält das gesamte `messages`-Objekt für das Locale; jeder `useTranslations("about")`-Aufruf liest daraus. Der Bundler sieht eine Komponente, die einen Hook importiert, der einen Context liest, und kann nicht wissen, dass nur der `about`-Zweig verwendet wird. Die Routen unten teilen sich alle das gleiche Message-Objekt, daher zeigt die Spalte page-leak ~90%, bis du die Datei selbst aufteilst, und der Overhead wächst auf zwei Achsen gleichzeitig, Seiten und Sprachen:
+
+![Theoretical content leakage by architecture](https://github.com/aymericzip/intlayer/blob/main/docs/assets/theorical_content_leakage.webp?raw=true)
 
 ```bash
 .
@@ -280,25 +308,106 @@ export default withIntlayer(nextConfig);
 
 ## Zu beachtende Limits vor dem Start
 
-- **Routing-Konfiguration verschiebt sich zu `intlayer.config.ts`.** `createNavigation(routing)` und `createMiddleware(routing)` behalten ihre Signatur, ignorieren aber das Argument: Locales, Default-Locale und Präfix-Strategie kommen aus Intlayers `routing`-Konfiguration. Wenn du `next-intl`'s lokalisierte `pathnames` verwendest (`/about` → `/a-propos`), interpoliert der Adapter diese nicht; Intlayers `routing.rewrite` deckt diesen Fall ab, aber es ist eine separate Änderung.
-- **Namespace-loses `useTranslations()` ist nicht gebunden.** Der Optimize-Pass benötigt einen statischen Namespace, um zu wissen, welches Dictionary importiert werden soll. Ein bloßer Aufruf funktioniert immer noch über eine Runtime-Registry, die auf jedes Dictionary verweist, was genau das Leck ist, das du entfernen wolltest. Übergib den Namespace.
-- **Der Adapter ist nicht kostenlos.** 8,0 KB Runtime gegenüber 5,5 KB für `next-intlayer`, und +6-7 KB pro Seite gegenüber dem nativen Build. Dies zahlt sich durch die `next-intl` API-Oberfläche aus. Wenn Sie an den Punkt gelangen, an dem jede Komponente zu `useIntlayer` verschoben wurde, lassen Sie den Adapter fallen.
-- **`messages`, `timeZone`, `now` auf dem Provider werden ignoriert.** Die Formatter werden durch natives `Intl` gestützt und nur das Locale beeinflusst deren Ausgabe; wenn Sie auf eine erzwungene Zeitzone oder ein fixes `now` für Hydrations-stabile Daten angewiesen sind, handhaben Sie dies am Aufrufort.
+<AccordionGroup>
+<Accordion header="Routing-Konfiguration wird nach intlayer.config.ts verlagert">
+
+`createNavigation(routing)` und `createMiddleware(routing)` behalten ihre Signatur, ignorieren jedoch das Argument: Sprachen, Standardsprache und Präfixstrategie stammen aus Intlayers `routing`-Konfiguration. Wenn Sie die lokalisierten `pathnames` von `next-intl` (`/about` zu `/a-propos`) verwenden, interpoliert der Adapter diese nicht; `routing.rewrite` von Intlayer deckt diesen Fall ab, ist jedoch eine separate Änderung.
+
+</Accordion>
+<Accordion header="useTranslations() ohne Namespace ist nicht gebunden">
+
+Der Optimierungsschritt benötigt einen statischen Namespace, um zu wissen, welches Wörterbuch importiert werden soll. Ein Aufruf ohne Namespace funktioniert weiterhin über eine Laufzeit-Registry, die jedes Wörterbuch referenziert, was genau dem Leakage entspricht, das Sie vermeiden wollten. Übergeben Sie den Namespace.
+
+</Accordion>
+<Accordion header="Der Adapter ist nicht umsonst">
+
+8.0 KB Laufzeit gegenüber 5.5 KB für `next-intlayer` und +6-7 KB pro Seite gegenüber dem nativen Build. Er bezahlt für die `next-intl`-API-Oberfläche. Wenn jeder Teil auf `useIntlayer` umgestellt ist, entfernen Sie den Adapter.
+
+</Accordion>
+<Accordion header="messages, timeZone und now auf dem Provider werden ignoriert">
+
+Die Formatierer basieren auf nativem `Intl` und nur die Sprache beeinflusst ihre Ausgabe. Wenn Sie für hydratationsstabile Daten auf eine erzwungene Zeitzone oder ein festes `now` angewiesen sind, handhaben Sie dies am Aufrufort. Siehe [Datums-, Uhrzeit- und Zahlenformatierung](https://intlayer.org/de/blog/date-time-number-formatting-locales).
+
+</Accordion>
+</AccordionGroup>
 
 ## Wann sollte man welche verwenden?
 
-- **Bleiben Sie bei `next-intl`**, wenn Ihre App klein ist, Ihr Bundle kein Problem ist, und Ihr Team sich damit wohlfühlt, Namespaces und `pick()` pro Seite zu verwalten.
-- **Nutzen Sie `@intlayer/next-intl`**, wenn Sie derzeit `next-intl` verwenden und von Bundlegröße, weniger Leakage, Hydration-Verbesserungen, typisierten Keys und den CLI-/CMS-Tools ohne vollständiges Rewrite profitieren möchten. Dies ist der empfohlene Einstiegspunkt für bestehende `next-intl`-Codebasen.
-- **Wechseln Sie zu nativen Lösungen (`next-intlayer`)** für neue Projekte oder sobald der Adapter seinen Zweck erfüllt hat. Es ist die leichteste der drei Varianten (5,5 KB, +0,3 KB pro Seite) und ermöglicht synchrone Server Components, per-Component `.content.ts`-Dateien und den vollständigen Feature-Set.
+<AccordionGroup>
+<Accordion header="Bei next-intl bleiben">
+
+Ihre Anwendung ist klein, das Bundle stellt kein Problem dar und Ihr Team verwaltet Namespaces und `pick()` pro Seite problemlos manuell.
+
+</Accordion>
+<Accordion header="@intlayer/next-intl verwenden">
+
+Sie nutzen bereits `next-intl` und möchten die Bundle-, Leakage- und Hydratationsvorteile, typisierte Schlüssel und die CLI / CMS-Tools ohne Neuschreiben nutzen. Dies ist der empfohlene Einstiegspunkt für jede bestehende `next-intl`-Codebasis.
+
+</Accordion>
+<Accordion header="Nativ werden (next-intlayer)">
+
+Für neue Projekte oder sobald der Adapter seinen Dienst getan hat. Es ist das leichteste der drei (5.5 KB, +0.3 KB pro Seite) und schaltet synchrone Serverkomponenten, komponentenspezifische `.content.ts`-Dateien und den vollen Funktionsumfang frei. Starten Sie mit [Intlayer mit Next.js](https://intlayer.org/de/doc/environment/nextjs).
+
+</Accordion>
+</AccordionGroup>
+
+## FAQ
+
+<FAQ>
+
+<Question title="Bleibt mein Anwendungscode wirklich unberührt?">
+
+Auf Next.js ja für Komponenten: Der Benchmark-Build änderte nur `next.config.ts` und `intlayer.config.ts`. `getRequestConfig` in `src/i18n.ts`, die `messages`-Prop auf dem Provider und `pick()`-Aufrufe pro Seite werden zu totem Code, den Sie danach löschen können.
+
+</Question>
+
+<Question title="Was passiert mit ICU-Nachrichten?">
+
+Sie funktionieren weiterhin. `t("key", { count })`, `t.rich()`, `t.markup()`, `select`, `selectordinal`, `#` und `{ts, date, long}` werden über Intlayers ICU-Resolver aufgelöst. Siehe [ICU-Nachrichtenformat](https://intlayer.org/de/blog/icu-message-format).
+
+</Question>
+
+<Question title="Warum ist der Adapter schwerer als natives next-intlayer?">
+
+Er trägt die `next-intl`-API-Oberfläche zusätzlich zum Intlayer-Kern: `useFormatter`, `t.rich`, den ICU-Resolver, die Navigationshelfer. Das sind 8.0 KB gegenüber 5.5 KB und +6 KB pro Seite. Er ist die Brücke, nicht das Endziel.
+
+</Question>
+
+<Question title="Kann ich Komponente für Komponente migrieren?">
+
+Ja. Jede Komponente kann von `useTranslations("about")` zu `useIntlayer("about")` mit einer danebenliegenden `.content.ts`-Datei wechseln. JSON- und `.content.ts`-Wörterbücher koexistieren und verschmelzen.
+
+</Question>
+
+<Question title="Funktionieren lokalisierte Pfadnamen?">
+
+Nicht über die `pathnames` von `next-intl`: Der Adapter akzeptiert sie für die Typisierung, interpoliert sie jedoch nicht. Verwenden Sie stattdessen `routing.rewrite` von Intlayer, das die lokalisierten Literale in die Typregistry überträgt.
+
+</Question>
+
+</FAQ>
 
 ## Verwandte Vergleiche
 
-- [next-intl vs Intlayer](https://intlayer.org/blog/next-intl-vs-intlayer) (die Bibliotheken, gleicher Benchmark)
-- [i18next vs @intlayer/i18next](https://intlayer.org/blog/i18next-vs-intlayer-i18next) (gleiche Adapter-Serie)
-- [Lingui vs @intlayer/lingui](https://intlayer.org/blog/lingui-vs-intlayer-lingui) (gleiche Adapter-Serie)
-- [vue-i18n vs @intlayer/vue-i18n](https://intlayer.org/blog/vue-i18n-vs-intlayer-vue-i18n) (gleiche Adapter-Serie)
-- [Migrationsleitfaden: next-intl zu Intlayer](https://intlayer.org/doc/migration/next-intl)
-- [Kompatibilitäts-Adapter-Referenz: next-intl](https://intlayer.org/doc/compatibility/next-intl)
+Gleiche Adapter-Serie:
+
+- [i18next vs @intlayer/i18next](https://intlayer.org/de/blog/i18next-vs-intlayer-i18next)
+- [Lingui vs @intlayer/lingui](https://intlayer.org/de/blog/lingui-vs-intlayer-lingui)
+- [vue-i18n vs @intlayer/vue-i18n](https://intlayer.org/de/blog/vue-i18n-vs-intlayer-vue-i18n)
+
+Die Bibliotheken im direkten Vergleich:
+
+- [next-intl vs Intlayer](https://intlayer.org/de/blog/next-intl-vs-intlayer), gleicher Benchmark
+- [next-i18next vs next-intl vs Intlayer](https://intlayer.org/de/blog/next-i18next-vs-next-intl-vs-intlayer)
+- [Is next-intl outdated?](https://intlayer.org/de/blog/is-next-intl-outdated)
+
+Referenzdokumentation:
+
+- [Compat adapter: next-intl](https://intlayer.org/de/doc/compatibility/next-intl)
+- [Migrationsleitfaden: next-intl zu Intlayer](https://intlayer.org/de/doc/migration/next-intl)
+- [Next.js-Benchmark-Bericht](https://intlayer.org/de/doc/benchmark/nextjs) und [TanStack Start-Benchmark-Bericht](https://intlayer.org/de/doc/benchmark/tanstack)
+- [Bundle-Optimierung](https://intlayer.org/de/doc/concept/bundle-optimization) und [der Intlayer-Compiler](https://intlayer.org/de/doc/compiler)
+- [Visual Editor](https://intlayer.org/de/doc/concept/editor), [CMS](https://intlayer.org/de/doc/concept/cms) und [KI-Übersetzung](https://intlayer.org/de/doc/concept/auto-fill)
 
 ## Fazit
 

package/blog/de/next-intl_vs_intlayer.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2026-09-13
-updatedAt: 2026-09-13
+updatedAt: 2026-09-22
 title: "next-intl vs Intlayer: 2026 Benchmark & Comparison"
 description: Bundle size, content leakage, locale-switch reactivity and developer experience measured on Next.js and TanStack Start. Which i18n library should you pick in 2026?
 keywords:
@@ -24,6 +24,8 @@ author: aymericzip
 
 # next-intl VS Intlayer | Next.js Internationalisierung (i18n) Benchmark
 
+![next-intl VS Intlayer](https://github.com/aymericzip/intlayer/blob/main/docs/assets/i18next-next-intl-intlayer.webp?raw=true)
+
 `next-intl` ist die beliebteste i18n-Bibliothek für Next.js. Intlayer ist eine compiler-basierte, component-scoped Alternative. Beide lokalisieren eine App Router-Anwendung. Die Frage ist, was jede Bibliothek kostet, sobald die App erstellt ist.
 
 Dieser Artikel ist kein Tutorial. Es ist ein Vergleich, der durch Zahlen aus [Benchmark Bloom](https://github.com/intlayer-org/benchmark-bloom) gestützt wird, einer Open-Source-Benchmark-Suite, die die gleiche Anwendung mit jeder Bibliothek erstellt und misst, was der Browser tatsächlich herunterlädt und ausführt.
@@ -96,6 +98,10 @@ Für jeden Build zeichnet die Suite Folgendes auf:
 
 ### Ergebnisse auf Next.js (App Router)
 
+Wählen Sie die Metriken und Bibliotheken, die Sie interessieren:
+
+<I18nBenchmark framework="nextjs" vertical/>
+
 | Library                        | Strategy       | Lib size (gz) | Page JS avg (gz) | Locale leak | Page leak | Component avg (gz) | E2E reactivity | Hydration |
 | ------------------------------ | -------------- | ------------: | ---------------: | ----------: | --------: | -----------------: | -------------: | --------: |
 | **base** (keine i18n)          | -              |        0.0 KB |         141.0 KB |        0.0% |      0.0% |             0.9 KB |        13.4 ms |   11.8 ms |
@@ -116,6 +122,15 @@ Für jeden Build zeichnet die Suite Folgendes auf:
 - **Komponentengröße.** Eine Komponente, die `useTranslations()` aufruft, wird im Durchschnitt zu 21,8 KB kompiliert; die gleiche Komponente mit `useIntlayer()` wird zu 6,9 KB kompiliert. Im `scoped-static`-Setup springen die `next-intl`-Komponenten auf 80,1 KB, weil jede ihren Namespace-Katalog inline einfügt.
 - **Reaktivität und Hydration** liegen für beide Bibliotheken auf Next.js im gleichen Bereich (15-18 ms). Keine von beiden ist hier ein Engpass.
 
+<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;"
+/>
+
+> Vollständige Tabelle, jede Bibliothek und jede Strategie, im [Next.js-Benchmark-Bericht](https://intlayer.org/de/doc/benchmark/nextjs).
+
 ### Ergebnisse auf TanStack Start (`use-intl`)
 
 `use-intl` ist der Framework-agnostische Kern von `next-intl`. Gleiche API, gleiches Nachrichtenformat. Der Vergleich mit `intlayer` auf TanStack Start entfernt die Next.js-spezifischen Teile der Gleichung.
@@ -139,8 +154,19 @@ Für jeden Build zeichnet die Suite Folgendes auf:
 - **Komponenten-Größe ist der Punkt, wo die Architektur sich zeigt**: 76-87 KB pro Komponente mit `use-intl` gegenüber 6-8 KB mit Intlayer. `useTranslations()` bindet jede Komponente an den globalen Message-Tree; `useIntlayer()` bindet sie an ihr eigenes Dictionary.
 - **Locale-Wechsel** ist mit Intlayer 2x-4x schneller (3 ms vs 7-21 ms).
 
+<ClickToOpenIframe
+src="https://intlayer.org/markdown?url=https%3A%2F%2Fraw.githubusercontent.com%2Fintlayer-org%2Fbenchmark-i18n%2Fmain%2Freport%2Fscripts%2Fsummarize-tanstack.md"
+width="100%"
+height="600px"
+style="border:none;"
+/>
+
+> Vollständige Tabelle im [TanStack Start-Benchmark-Bericht](https://intlayer.org/de/doc/benchmark/tanstack).
+
 ## Warum der Unterschied? Zentralisierte Kataloge vs. kompilierte Wörterbücher
 
+![Centralized catalogs versus per-component dictionaries](https://github.com/aymericzip/intlayer/blob/main/docs/assets/project_stucture_18n_vs_intlayer.png?raw=true)
+
 `next-intl` folgt dem klassischen Modell: eine JSON pro Locale, geladen in `getRequestConfig`, gepusht in einen `NextIntlClientProvider`, gelesen durch `t("namespace.key")`.
 
 ```bash
@@ -162,6 +188,10 @@ Für jeden Build zeichnet die Suite Folgendes auf:
 
 Die Runtime kann nicht wissen, welche Keys eine Seite verwenden wird, also ist der sichere Standard, den gesamten Katalog zu senden. Optimierung bedeutet, dass **Sie** den Katalog in Namespaces aufteilen, **Sie** entscheiden, welche Namespaces jede Seite benötigt, und **Sie** diese Zuordnung synchron halten, während sich Komponenten bewegen. Die `scoped-dynamic`-Zeile des Benchmarks ist die Belohnung für diese Arbeit, und die meisten Teams erreichen das nie.
 
+Die Kosten, dieses Ziel nicht zu erreichen, steigen auf zwei Achsen gleichzeitig: Seiten und Locales:
+
+![Theoretical content leakage by architecture](https://github.com/aymericzip/intlayer/blob/main/docs/assets/theorical_content_leakage.webp?raw=true)
+
 Intlayer dreht die Verantwortung um. Inhalte werden neben der Komponente deklariert:
 
 ```bash
@@ -189,7 +219,8 @@ Zur Build-Zeit sieht der Compiler (`@intlayer/swc` / `@intlayer/babel`), welche
 
 ### Client-Komponente
 
-**next-intl**
+<Tabs defaultTab="intlayer" group="techno">
+<Tab label="next-intl" value="next-intl">
 
 ```json fileName="messages/en.json"
 {
@@ -224,7 +255,8 @@ export const Counter = () => {
 
 > Denken Sie daran, den `counter`-Namespace in die Nachrichten einzubeziehen, die an `NextIntlClientProvider` auf jeder Seite übergeben werden, die diese Komponente rendert.
 
-**Intlayer**
+</Tab>
+<Tab label="Intlayer" value="intlayer">
 
 ```ts fileName="src/components/Counter/index.content.ts"
 import { t, type Dictionary } from "intlayer";
@@ -265,11 +297,14 @@ export const Counter = () => {
 
 Nichts auf der Seite zu registrieren: die Komponente bringt ihren eigenen Inhalt mit.
 
+</Tab>
+</Tabs>
 ### Synchrone Server-Komponente
 
 Design-System-Komponenten (Navbar, Footer, Cards) sind oft Server-Komponenten, die als untergeordnete Elemente von Client-Komponenten gerendert werden, daher können sie nicht `async` sein.
 
-**next-intl**
+<Tabs defaultTab="intlayer" group="techno">
+<Tab label="next-intl" value="next-intl">
 
 ```tsx fileName="src/components/ServerCounter.tsx"
 type ServerCounterProps = {
@@ -287,7 +322,8 @@ export const ServerCounter = ({ t, formattedCount }: ServerCounterProps) => (
 
 Die Seite muss `await getTranslations("counter")` und `await getFormatter()` aufrufen und die Ergebnisse dann als Props nach unten weiterleiten. Die Komponente ist nicht mehr in sich geschlossen.
 
-**Intlayer**
+</Tab>
+<Tab label="Intlayer" value="intlayer">
 
 ```tsx fileName="src/components/ServerCounter.tsx"
 import { useIntlayer } from "next-intlayer/server";
@@ -306,9 +342,12 @@ export const ServerCounter = ({ count }: { count: number }) => {
 };
 ```
 
+</Tab>
+</Tabs>
 ### Metadaten
 
-**next-intl**
+<Tabs defaultTab="intlayer" group="techno">
+<Tab label="next-intl" value="next-intl">
 
 ```tsx fileName="src/app/[locale]/about/page.tsx"
 import type { Metadata } from "next";
@@ -341,7 +380,8 @@ export const generateMetadata = async ({
 };
 ```
 
-**Intlayer**
+</Tab>
+<Tab label="Intlayer" value="intlayer">
 
 ```tsx fileName="src/app/[locale]/about/page.tsx"
 import { getIntlayer, getMultilingualUrls } from "intlayer";
@@ -365,6 +405,9 @@ export const generateMetadata = async ({
 };
 ```
 
+</Tab>
+</Tabs>
+
 ## Behalte die next-intl API, erhalte die Ausgabe von Intlayer
 
 Du musst Komponenten nicht neu schreiben, um die oben genannten Benchmark-Zahlen zu erreichen. `@intlayer/next-intl` ist ein Drop-in-Adapter: Er behält `useTranslations`, `getTranslations`, `useFormatter`, `t.rich()`, ICU-Plurale und die `next-intl/navigation` Helper bei und stellt sie aus den vom Intlayer-Compiler kompilierten Intlayer-Wörterbüchern bereit.
@@ -386,17 +429,84 @@ Siehe den [next-intl-Migrationsleitfaden](https://intlayer.org/doc/migration/nex
 
 ## Wann sollte man was wählen?
 
-- **Wählen Sie next-intl**, wenn Sie den Ökosystem-Standard für Next.js mögen, Sie sich auf ICU MessageFormat verlassen, Ihre App klein bis mittelgroß ist, oder Sie mit einer Übersetzungsplattform (Crowdin, Phrase, Lokalise...) integrieren, die zentralisierte JSON erwartet. Planen Sie Zeit für das Namespace von Katalogen und wählen Sie Nachrichten pro Seite, wenn Performance wichtig ist.
-- **Wählen Sie Intlayer**, wenn Sie **komponentengebundene Inhalte**, **striktes TypeScript**, **Build-Zeit-Fehler bei fehlenden Schlüsseln**, **müheloses Tree-Shaking und Lazy Loading**, synchrone Server Components und integrierte redaktionelle Tools (Visual Editor, CMS, AI-Übersetzung, MCP-Server) mögen. Besonders relevant für große, modulare Codebases und Design Systems.
-- **Wählen Sie `@intlayer/next-intl`**, wenn Sie bereits `next-intl` verwenden und die Bundle-Gewinne ohne Umschreiben mögen.
+<AccordionGroup>
+<Accordion header="next-intl wählen">
+
+Sie möchten den Ökosystem-Standard für Next.js, setzen auf ICU MessageFormat, Ihre App ist klein bis mittelgroß oder Sie integrieren eine Übersetzungsplattform (Crowdin, Phrase, Lokalise...), die zentrales JSON erwartet. Planen Sie Zeit ein, um Kataloge in Namespaces zu gliedern und Nachrichten pro Seite mit `pick()` auszuwählen, wenn Performance zählt.
+
+</Accordion>
+<Accordion header="Intlayer wählen">
+
+Sie möchten **komponentenbezogenen Inhalt**, **striktes TypeScript**, **Fehler bei fehlenden Schlüsseln zur Build-Zeit**, **müheloses Tree-Shaking und Lazy Loading**, synchrone Serverkomponenten und integrierte redaktionelle Werkzeuge ([Visueller Editor](https://intlayer.org/de/doc/concept/editor), [CMS](https://intlayer.org/de/doc/concept/cms), [KI-Übersetzung](https://intlayer.org/de/doc/concept/auto-fill), [MCP-Server](https://intlayer.org/de/doc/mcp-server)). Besonders relevant für große, modulare Codebasen und Design-Systeme.
+
+</Accordion>
+<Accordion header="@intlayer/next-intl wählen">
+
+Sie nutzen bereits `next-intl` und möchten die Bundle-Vorteile ohne Umschreiben nutzen. Der [Kompatibilitäts-Adapter](https://intlayer.org/de/doc/compatibility/next-intl) behält Ihre Imports und Ihre Datei `messages/{locale}.json` als Quelle der Wahrheit bei. Direkt verglichen in [next-intl vs @intlayer/next-intl](https://intlayer.org/de/blog/next-intl-vs-intlayer-next-intl).
+
+</Accordion>
+</AccordionGroup>
+
+## FAQ
+
+<FAQ>
+
+<Question title="Ist next-intl langsamer als Intlayer?">
+
+Nicht zur Renderzeit. Der Unterschied liegt darin, was ausgeliefert wird: `next-intl` verursacht **+12.6 KB gzip** Runtime auf jeder Seite und sendet in Standardkonfigurationen ~90% der Texte fremder Seiten mit jeder Seite mit. Sprachwechsel und Hydration sind bei Next.js vergleichbar (15-18 ms); bei TanStack Start benötigt `use-intl` 7-21 ms gegenüber 3-4 ms bei Intlayer.
+
+</Question>
+
+<Question title="Kann ich mit next-intl 0% Leakage erreichen?">
+
+Ja, mit dem `scoped-dynamic`-Setup: Teilen Sie `messages/{locale}.json` in einen Namespace pro Route auf, verwenden Sie `pick(messages, [...])` auf jeder Seite und halten Sie dieses Mapping aktuell, wenn sich Komponenten bewegen. Die `scoped-*`-Zeilen des Benchmarks spiegeln genau diese Arbeit wider. Intlayer erreicht 0% ohne diesen Aufwand, weil der Compiler Inhalte komponentenbezogen scoped. Siehe [Bundle-Optimierung](https://intlayer.org/de/doc/concept/bundle-optimization).
+
+</Question>
+
+<Question title="Muss ich meine Komponenten für eine Migration umschreiben?">
+
+Nein. `@intlayer/next-intl` behält `useTranslations`, `getTranslations`, `useFormatter`, `t.rich()`, ICU-Plurale und die Navigations-Helfer bei und stellt sie aus kompilierten Wörterbüchern bereit. Eine einzige Plugin-Zeile in `next.config.ts`. Schritt für Schritt im [next-intl-Migrationsleitfaden](https://intlayer.org/de/doc/migration/next-intl).
+
+</Question>
+
+<Question title="Unterstützt Intlayer ICU MessageFormat?">
+
+Die native ICU-Unterstützung befindet sich in der Entwicklung. Die Kompatibilitäts-Adapter (`@intlayer/next-intl`, `@intlayer/use-intl`) führen ICU jedoch bereits aus: Plurale, `select`, `selectordinal`, `#` und `{ts, date, long}` laufen über den ICU-Resolver von Intlayer. Details finden Sie unter [ICU-Nachrichtenformat](https://intlayer.org/de/blog/icu-message-format).
+
+</Question>
+
+<Question title="Kann ich meine messages/{locale}.json-Dateien behalten?">
+
+Ja. Das [JSON-Synchronisierungs-Plugin](https://intlayer.org/de/doc/compatibility/next-intl) liest sie ein, teilt die obersten Schlüssel in Wörterbücher auf und schreibt Übersetzungen in dieselben Dateien zurück, wenn die CLI oder das CMS sie aktualisiert. Der Arbeitsablauf Ihrer Übersetzer ändert sich nicht.
+
+</Question>
+
+</FAQ>
 
 ## Verwandte Vergleiche
 
-- [i18next vs Intlayer](https://intlayer.org/blog/i18next-vs-intlayer) (gleicher Benchmark)
-- [Lingui vs Intlayer](https://intlayer.org/blog/lingui-vs-intlayer) (gleicher Benchmark)
-- [vue-i18n vs Intlayer benchmark](https://intlayer.org/blog/vue-i18n-vs-intlayer-benchmark) (gleicher Benchmark)
-- [next-i18next vs next-intl vs Intlayer](https://intlayer.org/blog/next-i18next-vs-next-intl-vs-intlayer)
-- [Is next-intl outdated?](https://intlayer.org/blog/is-next-intl-outdated)
+Gleicher Benchmark, andere Bibliotheken:
+
+- [i18next vs Intlayer](https://intlayer.org/de/blog/i18next-vs-intlayer)
+- [Lingui vs Intlayer](https://intlayer.org/de/blog/lingui-vs-intlayer)
+- [vue-i18n vs Intlayer benchmark](https://intlayer.org/de/blog/vue-i18n-vs-intlayer-benchmark)
+- [next-i18next vs next-intl vs Intlayer](https://intlayer.org/de/blog/next-i18next-vs-next-intl-vs-intlayer)
+- [react-i18next vs react-intl vs Intlayer](https://intlayer.org/de/blog/react-i18next-vs-react-intl-vs-intlayer)
+
+Vertiefung zu next-intl:
+
+- [next-intl vs @intlayer/next-intl](https://intlayer.org/de/blog/next-intl-vs-intlayer-next-intl), der Adapter gemessen an derselben App
+- [Is next-intl outdated?](https://intlayer.org/de/blog/is-next-intl-outdated)
+- [Using Intlayer with next-intl](https://intlayer.org/de/blog/intlayer-with-next-intl)
+- [How to internationalize a Next.js app with next-intl](https://intlayer.org/de/blog/nextjs-internationalization-using-next-intl)
+
+Referenzdokumente:
+
+- [Next.js-Benchmark-Bericht](https://intlayer.org/de/doc/benchmark/nextjs) und [TanStack Start-Benchmark-Bericht](https://intlayer.org/de/doc/benchmark/tanstack)
+- [Kompatibilitäts-Adapter: next-intl](https://intlayer.org/de/doc/compatibility/next-intl) und [Migrationsleitfaden](https://intlayer.org/de/doc/migration/next-intl)
+- [Bundle-Optimierung](https://intlayer.org/de/doc/concept/bundle-optimization) und [der Intlayer-Compiler](https://intlayer.org/de/doc/compiler)
+- [Komponentenbezogene vs. zentrale i18n](https://intlayer.org/de/blog/per-component-vs-centralized-i18n)
+- [Compiler-gesteuerte vs. deklarative i18n](https://intlayer.org/de/blog/compiler-vs-declarative-i18n)
 
 ## GitHub STARS
 

package/blog/de/vue-i18n_vs_intlayer-vue-i18n.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2026-09-13
-updatedAt: 2026-09-13
+updatedAt: 2026-09-22
 title: "vue-i18n vs @intlayer/vue-i18n: Gleiche API, Anderes Bundle"
 description: Was sich ändert, wenn eine Vue 3-App ihre vue-i18n-Aufrufe beibehält, aber sie über den @intlayer/vue-i18n Compat-Adapter bereitstellt. Pro-Seite JavaScript, Laufzeit-Größe, Komponenten-Größe und Leakage gemessen auf demselben Vite + Vue Code, plus was der Adapter behält, ignoriert und nicht ersetzen kann.
 keywords:
@@ -25,6 +25,8 @@ author: aymericzip
 
 # vue-i18n VS @intlayer/vue-i18n | Gleiche API, Anderes Bundle
 
+![Vue i18n library ecosystem](https://github.com/aymericzip/intlayer/blob/main/docs/assets/cloud_i18n_logo.webp?raw=true)
+
 `@intlayer/vue-i18n` ist ein Kompatibilitätsadapter: Er stellt die `vue-i18n` API (`createI18n`, `useI18n`, `t()`, `d()`, `n()`, `$t`, `v-t`, `i18n.global.locale`...) bereit und bedient sie aus von Intlayer kompilierten Wörterbüchern. Ihre `.vue` Dateien ändern sich nicht. Woran sich `t("footer.github")` bindet, tut es.
 
 Dieser Artikel misst diesen Austausch auf derselben Vite + Vue 3 Anwendung, die einmal mit `vue-i18n` und einmal mit dem Adapter gebaut wurde. Die Zahlen stammen von [Benchmark Bloom](https://github.com/intlayer-org/benchmark-bloom). Für `vue-i18n` und Intlayer als Bibliotheken verglichen, lesen Sie [vue-i18n vs Intlayer](https://intlayer.org/blog/vue-i18n-vs-intlayer) und den [vue-i18n vs Intlayer Benchmark](https://intlayer.org/blog/vue-i18n-vs-intlayer-benchmark). Diesen Artikel geht es darum, was der Adapter ändert, wenn Sie Ihre Komponenten so behalten, wie sie sind.
@@ -105,6 +107,10 @@ Für jeden Build zeichnet die Suite folgendes auf:
 
 ### Ergebnisse auf Vite + Vue 3
 
+Wählen Sie die Metriken und Bibliotheken aus, die für Sie wichtig sind:
+
+<I18nBenchmark framework="vite-vue" vertical/>
+
 | Setup                    | Strategie | Lib-Größe (gz) | Lib-Größe (min) | Page JS ø (gz) | Locale Leak | Page Leak | Component ø (gz) | E2E Reaktivität | Seiten-Ladung |
 | ------------------------ | --------- | -------------: | --------------: | -------------: | ----------: | --------: | ---------------: | --------------: | ------------: |
 | **base** (kein i18n)     | -         |         0.0 KB |          0.0 KB |        41.3 KB |        0.0% |         - |           1.1 KB |          1.8 ms |       10.8 ms |
@@ -124,11 +130,24 @@ Für jeden Build zeichnet die Suite folgendes auf:
 - **Reaktivität und Seitenladezeit.** Locale-Wechsel sind kostengünstig für beide (1,5–2,8 ms); Vues Reaktivitätssystem macht es so, sobald Nachrichten im Speicher sind. Die Seitenladezeit geht von 13,6 ms auf **9,3 ms** zurück, in Übereinstimmung mit 88 KB weniger JavaScript zum Parsen.
 - **Zu den nativen Zeilen.** `vue-intlayer` bundelte in diesem Durchlauf jedes Locale im `static`-Modus und erreichte 57,1 KB mit einer 3,9-KB-Runtime; die synchronisierten Wörterbücher des Adapters trugen weniger fremdsprachige Strings, daher die niedrigere Zahl pro Seite. Die native Runtime bleibt die leichteste der drei, und ihr `.content.ts`-Modell ist der Ort, an dem SFC `<i18n>`-Blöcke ihr Äquivalent finden.
 
+<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, jede Bibliothek und jede Strategie, im [Vue-Benchmark-Bericht](https://intlayer.org/de/doc/benchmark/vue).
+
 ## Warum sich die Zahlen verschieben
 
+![The Intlayer compiler extracts content from components](https://github.com/aymericzip/intlayer/blob/main/docs/assets/compiler.webp?raw=true)
+
 Nichts in `src/components/` hat sich geändert, daher stammen die Gewinne von dem, an das `useI18n` gebunden ist.
 
-**Mit `vue-i18n`** ist die Bindung die globale Instanz. `createI18n({ messages: { en, fr, ... } })` ist ein Import, der alles enthält; jede Komponente, die `useI18n()` aufruft, kann auf alles zugreifen, daher kann der Bundler nicht unter der Instanz aufteilen. Optimieren bedeutet, dass _Sie_ `en.json` nach Route aufteilen, `setLocaleMessage()` in einem Router Guard aufrufen und die Route-to-File-Zuordnung korrekt halten, während sich Komponenten verschieben.
+**Mit `vue-i18n`** ist die Bindung die globale Instanz. `createI18n({ messages: { en, fr, ... } })` ist ein Import, der alles enthält; jede Komponente, die `useI18n()` aufruft, kann auf alles zugreifen, daher kann der Bundler nicht unter der Instanz aufteilen. Optimieren bedeutet, dass _Sie_ `en.json` nach Route aufteilen, `setLocaleMessage()` in einem Router Guard aufrufen und die Route-to-File-Zuordnung korrekt halten, während sich Komponenten verschieben. Die Verschwendung wächst auf zwei Achsen gleichzeitig, Seiten und Sprachen:
+
+![Theoretical content leakage by architecture](https://github.com/aymericzip/intlayer/blob/main/docs/assets/theorical_content_leakage.webp?raw=true)
 
 ```bash
 .
@@ -258,26 +277,107 @@ export const i18n = createI18n({ locale: "en" });
 
 ## Einschränkungen, die Sie kennen sollten, bevor Sie beginnen
 
-- **SFC `<i18n>` Blöcke werden nicht gelesen.** Wenn sich Ihre Meldungen in Komponenten befinden, müssen sie in die Locale-Dateien verschoben werden (oder zu `.content.ts`, was die gleiche Idee mit Typen ist).
-- **Laufzeit-Meldungsladung ist weg.** `setLocaleMessage()` und `mergeLocaleMessage()` geben eine Warnung aus und kehren zurück. Übersetzungen, die zur Laufzeit von einem CMS abgerufen werden, benötigen Intlayers CMS oder die Befehle `intlayer pull` / `push`.
-- **`messages` ist ein Fallback, nicht kostenlos.** Das Beibehalten der JSON-Importe in `createI18n()` behält die 75 KB im Bundle. Löschen Sie sie, sobald `intlayer test` bestanden hat.
-- **Der Adapter ist nicht die native Runtime.** 7,9 KB gegen 3,9 KB für `vue-intlayer`. Sobald jede Komponente zu `useIntlayer` migriert ist, kann er gelöscht werden.
+<AccordionGroup>
+<Accordion header="SFC <i18n>-Blöcke werden nicht gelesen">
+
+Wenn sich Ihre Nachrichten innerhalb von Komponenten befinden, müssen sie in die Sprachdateien oder in eine `.content.ts`-Datei verschoben werden, was dieselbe Idee mit generierten Typen darstellt.
+
+</Accordion>
+<Accordion header="Das Laden von Nachrichten zur Laufzeit entfällt">
+
+`setLocaleMessage()` und `mergeLocaleMessage()` geben eine Warnung aus und brechen ab. Übersetzungen, die zur Laufzeit von einem CMS abgerufen werden, erfordern das [Intlayer-CMS](https://intlayer.org/de/doc/concept/cms) oder die Befehle `intlayer pull` / `push`.
+
+</Accordion>
+<Accordion header="messages ist ein Fallback, nicht kostenlos">
+
+Das Beibehalten der JSON-Importe in `createI18n()` behält die 75 KB im Bundle bei. Löschen Sie sie, sobald `intlayer test` erfolgreich ist.
+
+</Accordion>
+<Accordion header="Der Adapter ist nicht die native Laufzeit">
+
+7.9 KB gegenüber 3.9 KB für `vue-intlayer`. Sobald jede Komponente auf `useIntlayer` umgestellt ist, entfernen Sie ihn.
+
+</Accordion>
+</AccordionGroup>
 
 ## Wann welche Option verwenden?
 
-- **Bleiben Sie bei `vue-i18n`**, wenn Ihre App von SFC `<i18n>` Blöcken abhängt, von Runtime `setLocaleMessage()` Flows, oder wenn 90 KB pro Seite für Ihr Publikum kein Problem darstellen.
-- **Verwenden Sie `@intlayer/vue-i18n`**, wenn Sie auf `vue-i18n` sind und die 88 KB, die 23x kleineren Komponenten, 0% Seiten-Leakage, typsichere Keys und CI-Checks ohne das Bearbeiten einer `.vue` Datei möchten. Dies ist der Einstiegspunkt für eine bestehende `vue-i18n` codebase.
-- **Gehen Sie native (`vue-intlayer`)** für neue Projekte oder sobald der Adapter seine Arbeit getan hat. Es hat die leichteste Runtime (3,9 KB) und das per-Komponenten `.content.ts` Modell, das `<i18n>` Blöcke durch typsichere Inhalte ersetzt.
+<AccordionGroup>
+<Accordion header="Bei vue-i18n bleiben">
+
+Ihre Anwendung hängt von SFC `<i18n>`-Blöcken oder Laufzeit-`setLocaleMessage()`-Abläufen ab, oder 90 KB pro Seite stellen für Ihr Publikum kein Problem dar.
+
+</Accordion>
+<Accordion header="@intlayer/vue-i18n verwenden">
+
+Sie nutzen `vue-i18n` und möchten 88 KB einsparen, 23-mal kleinere Komponenten, 0% Seiten-Leakage, typisierte Schlüssel und CI-Prüfungen erhalten, ohne eine einzige `.vue`-Datei zu bearbeiten. Dies ist der Einstiegspunkt für eine bestehende `vue-i18n`-Codebasis.
+
+</Accordion>
+<Accordion header="Nativ werden (vue-intlayer)">
+
+Für neue Projekte oder sobald der Adapter seinen Dienst getan hat. Er bietet die leichteste Laufzeit (3.9 KB) und das komponentenspezifische `.content.ts`-Modell, das `<i18n>`-Blöcke durch typisierten Inhalt ersetzt. 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>
+</AccordionGroup>
+
+## FAQ
+
+<FAQ>
+
+<Question title="Muss ich meine .vue-Dateien bearbeiten?">
+
+Nein. Der Benchmark-Build änderte nur `vite.config.ts`, `intlayer.config.ts` und eine Zeile in `src/i18n.ts`, den `messages`-Import. Jeder Aufruf von `useI18n()`, `$t`, `v-t` und der Options-API blieb unverändert.
+
+</Question>
+
+<Question title="Warum ist die Komponentengröße 23x kleiner?">
+
+Weil `useI18n()` nicht mehr auf die globale Instanz zugreift. `createI18n({ messages })` enthält jede Nachricht jeder Sprache, sodass eine isoliert kompilierte Komponente 196 KB mitschleppt. Mit dem Adapter greift sie nur auf ihr eigenes Wörterbuch zu: 8.4 KB.
+
+</Question>
+
+<Question title="Was ist mit d()- und n()-Formatierung?">
+
+Beibehalten. Die an `createI18n()` übergebenen `datetimeFormats` und `numberFormats` werden respektiert und durch natives `Intl` unterstützt. Siehe [Datums-, Uhrzeit- und Zahlenformatierung](https://intlayer.org/de/blog/date-time-number-formatting-locales).
+
+</Question>
+
+<Question title="Funktioniert es mit Nuxt?">
+
+`@intlayer/vue-i18n` zielt auf Vite + Vue ab. Für `@nuxtjs/i18n` verwenden Sie den [Nuxt i18n-Kompatibilitätsadapter](https://intlayer.org/de/doc/compatibility/nuxtjs-i18n) und lesen Sie [Intlayer mit Nuxt](https://intlayer.org/de/doc/environment/nuxt-and-vue) für das native Setup.
+
+</Question>
+
+<Question title="Kann ich Komponente für Komponente migrieren?">
+
+Ja. Jede Komponente kann mit einer danebenliegenden Inhaltsdatei von `useI18n()` zu `useIntlayer("footer")` wechseln. JSON- und `.content.ts`-Wörterbücher koexistieren und verschmelzen.
+
+</Question>
+
+</FAQ>
 
 ## Zugehörige Vergleiche
 
-- [vue-i18n vs Intlayer](https://intlayer.org/blog/vue-i18n-vs-intlayer) (Features und DX)
-- [vue-i18n vs Intlayer benchmark](https://intlayer.org/blog/vue-i18n-vs-intlayer-benchmark) (die Bibliotheken, gleicher Benchmark)
-- [next-intl vs @intlayer/next-intl](https://intlayer.org/blog/next-intl-vs-intlayer-next-intl) (gleiche Adapter-Serie)
-- [i18next vs @intlayer/i18next](https://intlayer.org/blog/i18next-vs-intlayer-i18next) (gleiche Adapter-Serie)
-- [Lingui vs @intlayer/lingui](https://intlayer.org/blog/lingui-vs-intlayer-lingui) (gleiche Adapter-Serie)
-- [Migrationsleitfaden: vue-i18n zu Intlayer](https://intlayer.org/doc/migration/vue-i18n)
-- [Compat adapter reference: vue-i18n](https://intlayer.org/doc/compatibility/vue-i18n), [Nuxt i18n](https://intlayer.org/doc/compatibility/nuxtjs-i18n)
+Gleiche Adapter-Serie:
+
+- [next-intl vs @intlayer/next-intl](https://intlayer.org/de/blog/next-intl-vs-intlayer-next-intl)
+- [i18next vs @intlayer/i18next](https://intlayer.org/de/blog/i18next-vs-intlayer-i18next)
+- [Lingui vs @intlayer/lingui](https://intlayer.org/de/blog/lingui-vs-intlayer-lingui)
+
+Die Bibliotheken im direkten Vergleich:
+
+- [vue-i18n vs Intlayer](https://intlayer.org/de/blog/vue-i18n-vs-intlayer), Features und DX
+- [vue-i18n vs Intlayer benchmark](https://intlayer.org/de/blog/vue-i18n-vs-intlayer-benchmark)
+- [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)
+
+Referenzdokumentation:
+
+- [Compat adapter: vue-i18n](https://intlayer.org/de/doc/compatibility/vue-i18n) and [Nuxt i18n](https://intlayer.org/de/doc/compatibility/nuxtjs-i18n)
+- [Migrationsleitfaden: vue-i18n zu Intlayer](https://intlayer.org/de/doc/migration/vue-i18n)
+- [Vue-Benchmark-Bericht](https://intlayer.org/de/doc/benchmark/vue)
+- [Bundle-Optimierung](https://intlayer.org/de/doc/concept/bundle-optimization) und [der Intlayer-Compiler](https://intlayer.org/de/doc/compiler)
+- [Visual Editor](https://intlayer.org/de/doc/concept/editor), [CMS](https://intlayer.org/de/doc/concept/cms) und [KI-Übersetzung](https://intlayer.org/de/doc/concept/auto-fill)
 
 ## Fazit
 
@@ -285,4 +385,4 @@ export const i18n = createI18n({ locale: "en" });
 
 Alle Rohdaten, die Test-Apps und die Scripts befinden sich im [Benchmark Bloom Repository](https://github.com/intlayer-org/benchmark-bloom). Führen Sie es selbst aus.
 
-Weitere Details finden Sie in der [Dokumentation 'Why Intlayer?'](https://intlayer.org/doc/why).
+Weitere Details finden Sie in der [Dokumentation 'Why Intlayer?'](https://intlayer.org/de/doc/why).