@intlayer/docs 9.5.6 → 9.5.8

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).