@intlayer/docs 9.5.6 → 9.5.8

package/blog/de/lingui_vs_intlayer.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2026-09-13
-updatedAt: 2026-09-13
+updatedAt: 2026-09-22
 title: "Lingui vs Intlayer: 2026 Benchmark & Vergleich"
 description: "Zwei compilerbasierte i18n-Bibliotheken gemessen auf Next.js und TanStack Start. Bundle-Größe, Content-Leakage, Komponentengröße, Hydratisierung, Sprachwechsel-Reaktivität und Developer Experience."
 keywords:
@@ -24,6 +24,8 @@ author: aymericzip
 
 # Lingui VS Intlayer | React & Next.js Internationalisierungs-Benchmark (i18n)
 
+![JavaScript i18n library ecosystem](https://github.com/aymericzip/intlayer/blob/main/docs/assets/cloud_i18n_logo.webp?raw=true)
+
 Lingui und Intlayer sind die beiden Bibliotheken in diesem Benchmark, die auf einen **Compiler** anstelle einer reinen Runtime setzen. Lingui extrahiert Nachrichten aus Makros zur Build-Zeit und kompiliert Kataloge pro Sprache. Intlayer kompiliert komponentenbasierte Wörterbücher und unterzieht sie pro Sprache einem automatischen Tree-Shaking. Auf dem Papier klingen beide Ansätze ähnlich. Die Messwerte zeigen jedoch, wo sie sich deutlich unterscheiden.
 
 Die Messdaten stammen aus [Benchmark Bloom](https://github.com/intlayer-org/benchmark-bloom), einer quelloffenen Benchmark-Suite, die dieselbe Anwendung mit jeder Bibliothek baut und erfasst, was der Browser tatsächlich herunterlädt und ausführt.
@@ -96,6 +98,10 @@ Für jeden Build erfasst die Suite:
 
 ### Ergebnisse auf Next.js
 
+Wählen Sie die Metriken und Bibliotheken aus, die für Sie wichtig sind:
+
+<I18nBenchmark framework="nextjs" vertical/>
+
 | Bibliothek           | Strategie      | Lib size (gz) | Page JS Ø (gz) | Sprach-Leak | Seiten-Leak | Komponente Ø (gz) | E2E-Reaktivität | Hydratisierung |
 | -------------------- | -------------- | ------------: | -------------: | ----------: | ----------: | ----------------: | --------------: | -------------: |
 | **base** (ohne i18n) | -              |        0,0 KB |       141,0 KB |        0,0% |        0,0% |            0,9 KB |         13,4 ms |        11,8 ms |
@@ -114,6 +120,15 @@ Für jeden Build erfasst die Suite:
 - **Quellsprachen-Leakage bleibt bestehen.** Selbst in den optimierten Setups werden **3-15% englische Texte in französischen Seiten mitgeliefert**. Lingui-Makros halten den Quelltext als Fallback vorrätig, wodurch er im Bundle landet. Intlayer löst Fallbacks zur Build-Zeit auf und liefert ausschließlich die aktive Sprache aus.
 - **Komponentengröße explodiert in `scoped-dynamic`.** Jede einzeln kompilierte Komponente wiegt im Schnitt **152,6 KB**, da alle Routenkataloge über die Komponentenimporte erreichbar bleiben. Dieselbe Komponente mit `useIntlayer()` wiegt im Schnitt nur **6,9 KB**.
 
+<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
 
 | Bibliothek                  | Strategie      | Lib size (gz) | Page JS Ø (gz) | Sprach-Leak | Seiten-Leak | Komponente Ø (gz) | E2E-Reaktivität | Hydratisierung |
@@ -135,8 +150,19 @@ Für jeden Build erfasst die Suite:
 - **Intlayers `static`-Zeile erreicht bereits 0% Seiten-Leakage**, da nur Wörterbücher gebündelt werden, die von den Komponenten dieser Seite tatsächlich importiert werden. Eine einzige Konfigurationszeile (`importMode: 'dynamic'`) beseitigt auch die Sprach-Leakage.
 - **`@intlayer/lingui`** behält Linguis Makrosyntax bei und bezieht Daten aus Intlayer-Wörterbüchern. Es tauscht etwas Gesamtgröße pro Seite (137 KB, da die Makro-Runtime verbleibt) gegen drastisch leichtere Komponenten (12,8 KB) und schnellere Hydratisierung. Eine hervorragende Migrationshilfe.
 
+<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 dieser Unterschied? Zwei Compiler, zwei Arbeitseinheiten
 
+![The Intlayer compiler extracts content from components](https://github.com/aymericzip/intlayer/blob/main/docs/assets/compiler.webp?raw=true)
+
 Beide Lösungen kompilieren. Der Unterschied liegt darin, **was** sie kompilieren.
 
 **Lingui kompiliert Kataloge.** Makros in Ihrem Quelltext werden in eine `.po`-Datei pro Sprache extrahiert und anschließend in ein JS-Modul pro Sprache kompiliert. Die Arbeitseinheit ist die **Sprache**. Eine feinere Zerlegung nach Routen oder Komponenten verlangt mehrere Kataloge, eine erweiterte `lingui.config.ts` und eine händische Ladelogik pro Route. Die `I18n`-Instanz ist global; jeder `useLingui()`-Aufruf verbindet die Komponente mit ihr.
@@ -176,7 +202,9 @@ Beide Lösungen kompilieren. Der Unterschied liegt darin, **was** sie kompiliere
             └── about.content.ts
 ```
 
-Genau deshalb ist das `scoped-dynamic`-Muster bei Intlayer ein automatisches Build-Ergebnis, während es bei Lingui ein eigenständiges Konfigurationsprojekt darstellt.
+Genau deshalb ist das `scoped-dynamic`-Muster bei Intlayer ein automatisches Build-Ergebnis, während es bei Lingui ein eigenständiges Konfigurationsprojekt darstellt. Die Lücke vergrößert sich 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)
 
 > Um die Werte der Zeile `dynamic` zu erreichen, setzen Sie `dictionary.importMode: 'dynamic'` in Ihrer `intlayer.config.ts`. Siehe die [Dokumentation zur Bundle-Optimierung](https://intlayer.org/de/doc/concept/bundle-optimization).
 
@@ -184,7 +212,8 @@ Genau deshalb ist das `scoped-dynamic`-Muster bei Intlayer ein automatisches Bui
 
 ### Einrichtung
 
-**Lingui**
+<Tabs defaultTab="intlayer" group="techno">
+<Tab label="Lingui" value="lingui">
 
 ```ts fileName="lingui.config.ts"
 import { defineConfig } from "@lingui/cli";
@@ -215,7 +244,8 @@ export const loadCatalog = async (locale: string) => {
 
 Anschließend fügen Sie `@lingui/babel-plugin-lingui-macro` (oder `@lingui/swc-plugin`) zum Bundler hinzu, führen `lingui extract` nach Codeänderungen und `lingui compile` vor dem Build aus, und umschließen die Anwendung mit `<I18nProvider i18n={i18n}>`.
 
-**Intlayer**
+</Tab>
+<Tab label="Intlayer" value="intlayer">
 
 ```ts fileName="intlayer.config.ts"
 import { type IntlayerConfig, Locales } from "intlayer";
@@ -232,9 +262,12 @@ export default config;
 
 Fügen Sie `intlayer()` in `vite.config.ts` (oder `withIntlayer()` in `next.config.ts`) hinzu und umschließen Sie den Baum mit `<IntlayerProvider>`. Keine separaten Extraktions- oder Kompilierschritte: Wörterbücher werden direkt beim Start des Bundlers verarbeitet.
 
+</Tab>
+</Tabs>
 ### Komponente
 
-**Lingui**
+<Tabs defaultTab="intlayer" group="techno">
+<Tab label="Lingui" value="lingui">
 
 ```tsx fileName="src/components/Counter.tsx"
 import { useState } from "react";
@@ -258,7 +291,8 @@ export const Counter = () => {
 
 Der englische Text steht in der Komponente; die französische Übersetzung landet in `src/locales/fr/messages.po` unter einer gehashten ID, sobald `lingui extract` ausgeführt wurde. Vergisst man die Extraktion oder das Kompilieren, wird stillschweigend auf Englisch zurückgegriffen.
 
-**Intlayer**
+</Tab>
+<Tab label="Intlayer" value="intlayer">
 
 ```ts fileName="src/components/Counter/index.content.ts"
 import { t, type Dictionary } from "intlayer";
@@ -297,11 +331,14 @@ export const Counter = () => {
 
 Beide Sprachen liegen gemeinsam in einer Datei neben der Komponente. Ein fehlender `fr`-Wert erzeugt einen Build-Fehler, ein falscher Schlüssel sofort einen TypeScript-Fehler.
 
+</Tab>
+</Tabs>
 ### Außerhalb von Komponenten
 
 Metadaten, Loader, Serverfunktionen: überall dort, wo kein React-Baum existiert.
 
-**Lingui**
+<Tabs defaultTab="intlayer" group="techno">
+<Tab label="Lingui" value="lingui">
 
 ```ts fileName="src/routes/$locale/about.tsx"
 import { setupI18n } from "@lingui/core";
@@ -324,7 +361,8 @@ export const loader = async ({ params }: { params: { locale: string } }) => {
 
 Eine frische `I18n`-Instanz pro Aufruf, manuelle Zuweisung des passenden Katalogs und `msg` + `i18n._()` anstelle von `t`. Wie die [Benchmark-Notizen](https://github.com/intlayer-org/benchmark-bloom/blob/main/report/NOTE.md) festhalten, ist die Entscheidung zwischen `t`, `` t` ` ``, `i18n.t()`, `msg` oder `<Trans>` oft nicht intuitiv.
 
-**Intlayer**
+</Tab>
+<Tab label="Intlayer" value="intlayer">
 
 ```ts fileName="src/routes/$locale/about.tsx"
 import { getIntlayer } from "intlayer";
@@ -336,6 +374,9 @@ export const loader = async ({ params }: { params: { locale: string } }) => {
 };
 ```
 
+</Tab>
+</Tabs>
+
 ## Lingui-Makros behalten, Intlayer-Wörterbücher nutzen
 
 `@intlayer/lingui` dient als Drop-in-Adapter für `@lingui/core` und `@lingui/react`. Makros kompilieren weiterhin normal; die erzeugten `i18n._()`-Aufrufe werden über Intlayer-Wörterbücher bedient, während `.po`-Synchronisations-Plugins bestehende Kataloge als Wahrheitsquelle beibehalten. ICU-Pluralformen und Selects rendern identisch.
@@ -353,16 +394,82 @@ Belassen Sie `@lingui/babel-plugin-lingui-macro` / `@lingui/swc-plugin` im Build
 
 ## Wann welche Bibliothek wählen?
 
-- **Wählen Sie Lingui**, wenn Sie **ICU MessageFormat** mit typisierten Makros benötigen, Ihre Übersetzer mit **`.po`**-Dateien in bestehenden TMS-Pipelines arbeiten, Sie Quelltexte inline im JSX bevorzugen und Ihr Team die Verwaltung von Extraktions-, Kompilier- und Aufteilungsschritten beherrscht. Bei konfiguriertem Lazy Loading ist die Seitengröße sehr konkurrenzfähig.
-- **Wählen Sie Intlayer**, wenn Sie **komponentenbezogene Inhalte**, **strikte TypeScript-Typisierung**, **Fehler bei fehlenden Schlüsseln zur Build-Zeit**, **automatisiertes Tree-Shaking und Lazy Loading ohne Konfiguration**, kleine Komponenten, schnelle Hydratisierung, sofortigen Sprachwechsel und integrierte Redaktionstools (visueller Editor, CMS, KI-Übersetzung, MCP-Server) suchen. Besonders empfehlenswert für modulare Architekturen und Design-Systeme.
-- **Wählen Sie `@intlayer/lingui`**, wenn Sie Lingui nutzen und schrittweise auf Intlayers Wörterbuch-Architektur umsteigen möchten, ohne bestehende Makros umschreiben zu müssen.
+<AccordionGroup>
+<Accordion header="Lingui wählen">
+
+Sie möchten **ICU MessageFormat** mit typisierten Makros, Ihre Übersetzer arbeiten in **`.po`** mit einer bestehenden TMS-Pipeline, Sie bevorzugen Quellstrings inline in JSX und Ihr Team bewältigt den Workflow aus Extraktion / Kompilierung / Katalogaufteilung problemlos. Sein JS pro Seite ist wettbewerbsfähig, sobald Lazy Loading eingerichtet ist.
+
+</Accordion>
+<Accordion header="Intlayer wählen">
+
+Sie möchten **komponentenbezogene Inhalte**, **striktes TypeScript**, **Fehler bei fehlenden Schlüsseln zur Build-Zeit**, **müheloses Tree-Shaking und Lazy Loading**, schlanke Komponenten, schnelle Hydratisierung, sofortigen Sprachwechsel und integrierte Redaktionstools ([Visual 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 Designsysteme.
+
+</Accordion>
+<Accordion header="@intlayer/lingui wählen">
+
+Sie nutzen bereits Lingui und möchten schrittweise zu Intlayer-Wörterbüchern wechseln, ohne Makros anzutasten. Ihre `.po`-Kataloge bleiben über das [PO-Synchronisations-Plugin](https://intlayer.org/de/doc/compatibility/lingui) die Quelle der Wahrheit. Seite an Seite gemessen in [Lingui vs @intlayer/lingui](https://intlayer.org/de/blog/lingui-vs-intlayer-lingui).
+
+</Accordion>
+</AccordionGroup>
+
+## FAQ
+
+<FAQ>
+
+<Question title="Lingui kompiliert ebenfalls. Warum ist die Ausgabe so unterschiedlich?">
+
+Weil sich die Einheit der Kompilierung unterscheidet. Lingui kompiliert **einen Katalog pro Sprache**: Alles darunter (Kataloge pro Route, Lazy Loading, Ausschluss des Fallbacks aus dem Bundle) ist Konfigurationsaufwand. Intlayer kompiliert **ein Wörterbuch pro Komponente**, sodass die Routenabgrenzung automatisch im Build entsteht. Deshalb wiegt eine isoliert kompilierte Lingui-Komponente 58-153 KB gegenüber 6-8 KB bei Intlayer.
+
+</Question>
+
+<Question title="Warum erreicht das Locale-Leakage bei Lingui nie 0%?">
+
+Makros halten die Quellnachricht als Laufzeit-Fallback bereit, sodass der englische String neben seiner Übersetzung ausgeliefert wird. Der Benchmark misst **3-15% `en`-Strings in `fr`-Seiten** in jedem optimierten Setup. Intlayer löst Fallbacks zur Build-Zeit auf und liefert nur die aktive Sprache aus.
+
+</Question>
+
+<Question title="Ist das JavaScript pro Seite von Lingui wirklich wettbewerbsfähig?">
+
+Ja, und auf TanStack Start gewinnt es hauchdünn: 115.2 KB in `dynamic` gegenüber 118.6 KB bei Intlayer. Kompilierte Kataloge mit gehashten IDs sind kompakt. Die Kosten zeigen sich an anderer Stelle: Hydratisierung bei 28-34 ms gegenüber 11-14 ms und ein **42 ms** dauernder Sprachwechsel im `scoped-dynamic`-Setup.
+
+</Question>
+
+<Question title="Muss ich Makros aufgeben, um zu migrieren?">
+
+Nein. `@intlayer/lingui` kompiliert `` t`...` ``, `<Trans>`, `msg`, `plural`, `select` und `selectOrdinal` wie gewohnt weiter; nur die Auflösung unter `i18n._()` ändert sich. Behalten Sie `@lingui/babel-plugin-lingui-macro` oder `@lingui/swc-plugin` im Build. Siehe [Lingui-Kompatibilitätsdokumentation](https://intlayer.org/de/doc/compatibility/lingui).
+
+</Question>
+
+<Question title="Was ist mit den Extraktions- und Kompilierungsschritten?">
+
+Sie bleiben für die Makros bestehen und entfallen für Intlayers eigene Inhalte. `.content.ts`-Wörterbücher werden beim Ausführen des Bundlers ohne separaten CLI-Schritt erstellt, und [`intlayer test`](https://intlayer.org/de/doc/concept/cli) lässt CI bei fehlenden Schlüsseln fehlschlagen, anstatt stillschweigend auf den Quellstring zurückzugreifen.
+
+</Question>
+
+</FAQ>
 
 ## Weiterführende Vergleiche
 
-- [next-intl vs Intlayer](https://intlayer.org/de/blog/next-intl-vs-intlayer) (auf demselben Benchmark)
-- [i18next vs Intlayer](https://intlayer.org/de/blog/i18next-vs-intlayer) (auf demselben Benchmark)
-- [vue-i18n vs Intlayer](https://intlayer.org/de/blog/vue-i18n-vs-intlayer-benchmark) (auf demselben Benchmark)
-- [Compiler vs deklaratives i18n](https://intlayer.org/de/blog/compiler-vs-declarative-i18n)
+Gleicher Benchmark, andere Bibliotheken:
+
+- [next-intl vs Intlayer](https://intlayer.org/de/blog/next-intl-vs-intlayer)
+- [i18next vs Intlayer](https://intlayer.org/de/blog/i18next-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:
+
+- [Lingui vs @intlayer/lingui](https://intlayer.org/de/blog/lingui-vs-intlayer-lingui), der Adapter gemessen auf derselben Anwendung
+- [Compiler-driven vs declarative i18n](https://intlayer.org/de/blog/compiler-vs-declarative-i18n)
+- [Per-component vs centralized i18n](https://intlayer.org/de/blog/per-component-vs-centralized-i18n)
+- [ICU message format explained](https://intlayer.org/de/blog/icu-message-format)
+
+Referenzdokumentation:
+
+- [Next.js-Benchmark-Bericht](https://intlayer.org/de/doc/benchmark/nextjs) und [TanStack Start-Benchmark-Bericht](https://intlayer.org/de/doc/benchmark/tanstack)
+- [Compat adapter: Lingui](https://intlayer.org/de/doc/compatibility/lingui)
+- [Bundle-Optimierung](https://intlayer.org/de/doc/concept/bundle-optimization) und [der Intlayer-Compiler](https://intlayer.org/de/doc/compiler)
 
 ## GitHub STARS
 

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