@intlayer/docs 9.5.5 → 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/transform_existing_vite_react_app_using_compiler.md

@@ -284,7 +284,9 @@ const pathList = [
   { path: "/about", changefreq: "monthly", priority: 0.7 },
 ];
 
-const sitemapXml = generateSitemap(pathList, { siteUrl: SITE_URL });
+const sitemapXml = generateSitemap(pathList, {
+  siteUrl: "https://example.com",
+});
 fs.writeFileSync(path.join(__dirname, "public", "sitemap.xml"), sitemapXml);
 
 const getAllMultilingualUrls = (urls) =>
@@ -297,7 +299,7 @@ const robotsTxt = [
   "Allow: /",
   ...disallowedPaths.map((path) => `Disallow: ${path}`),
   "",
-  `Sitemap: ${SITE_URL}/sitemap.xml`,
+  `Sitemap: https://example.com/sitemap.xml`,
 ].join("\n");
 
 fs.writeFileSync(path.join(__dirname, "public", "robots.txt"), robotsTxt);