@intlayer/docs 9.0.0-canary.3 → 9.0.0-canary.5

package/docs/de/CI_CD.md

@@ -26,6 +26,10 @@ author: aymericzip
 
 Intlayer ermöglicht die automatische Generierung von Übersetzungen für Ihre Content-Deklarationsdateien. Es gibt verschiedene Möglichkeiten, dies je nach Ihrem Workflow zu realisieren.
 
+## Inhaltsverzeichnis
+
+<TOC/>
+
 ## Verwendung des CMS
 
 Mit Intlayer können Sie einen Workflow verwenden, bei dem nur eine einzige Locale lokal deklariert wird, während alle Übersetzungen remote über das CMS verwaltet werden. Dies ermöglicht es, Inhalte und Übersetzungen vollständig von der Codebasis zu trennen, bietet mehr Flexibilität für Content-Editoren und ermöglicht ein Hot Content Reloading (kein erneutes Bauen der Anwendung erforderlich, um Änderungen anzuwenden).

package/docs/de/autoFill.md

@@ -28,6 +28,53 @@ history:
 author: aymericzip
 ---
 
+# Füllen Sie Content Declaration File Translations aus
+
+**Autofill content declaration files** in Ihrer CI sind eine Möglichkeit, Ihren Entwicklungs-Workflow zu beschleunigen.
+
+## Das Verhalten verstehen
+
+Der `fill`-Befehl umfasst zwei Modi:
+
+- **Complete**: Füllt automatisch alle fehlenden Inhalte für jedes Locale aus und bearbeitet die aktuelle Datei oder eine andere angegebene Datei. Das heißt, der Complete-Modus überspringt die Übersetzung bereits vorhandener Inhalte, falls diese bereits übersetzt wurden.
+- **Review**: Füllt automatisch **alle** Inhalte für jedes Locale aus und generiert für eine bestimmte Datei oder eine andere angegebene Datei.
+
+Der `fill`-Befehl verarbeitet alle Ihre Locale-Content-Deklarationsdateien. Das heißt, er verarbeitet nicht Ihre Remote-Inhalte aus dem CMS. Das CMS umfasst sein eigenes Übersetzungsverwaltungssystem.
+Wenn Sie Plugins wie `@intlayer/sync-json-plugin` verwenden, wird Intlayer die JSON-Dateien in Locale-Content-Deklarationsdateien umwandeln. Das heißt, sie werden vom `fill`-Befehl verarbeitet.
+
+Die neu generierten Dateien enthalten eine `filled`-Anweisung als Dictionary-Metadaten. Diese Anweisung wird von Intlayer verwendet, um zu erkennen, ob die Datei automatisch ausgefüllt wurde oder nicht, und überspringt diese Datei, falls vorhanden, vor erneuter Übersetzung.
+
+Intlayer berücksichtigt auch die folgende Anweisung zum automatischen Ausfüllen:
+
+- Aus Ihrer `.content.{ts|js|json}` → `fill`-Anweisung
+- Aus Ihrer Konfigurationsdatei `.intlayer.config.ts` → `dictionary.fill`-Anweisung
+- Wird standardmäßig auf `true` gesetzt, ansonsten
+
+Bei Pro-Locale-Content-Deklarationsdateien wird die `true`-Anweisung durch `./{{fileName}}.fill.content.json` ersetzt. Dies ist der Fall, da eine Pro-Locale-Content-Deklarationsdatei keine zusätzlichen lokalisierten Inhalte erhalten kann. Daher wird eine neue Datei generiert, um die vorhandene Datei nicht zu überschreiben.
+
+## Standardverhalten
+
+Standardmäßig ist `fill` global auf `true` eingestellt, was bedeutet, dass Intlayer automatisch alle Content-Dateien ausfüllt und die Datei selbst bearbeitet. Dieses Verhalten kann auf verschiedene Weise angepasst werden:
+
+### Globale Konfigurationsoptionen
+
+1. **`fill: true` (Standard)** - Füllt automatisch alle Locales aus und bearbeitet die aktuelle Datei
+2. **`fill: false`** - Deaktiviert das automatische Ausfüllen für diese Content-Datei
+3. **`fill: "./relative/path/to/file"`** - Erstellt/aktualisiert die angegebene Datei, ohne die aktuelle zu bearbeiten, indem auf einen relativen Pfad verwiesen wird, der basierend auf dem Speicherort der aktuellen Datei aufgelöst wird
+4. **`fill: "/absolute/path/to/file"`** - Erstellt/aktualisiert die angegebene Datei, ohne die aktuelle zu bearbeiten, indem auf einen relativen Pfad verwiesen wird, der basierend auf dem Speicherort des Basisverzeichnisses aufgelöst wird (Feld `baseDir` in der Konfigurationsdatei `.intlayer.config.ts`)
+5. **`fill: "C:\\absolute\path\to\file"`** - Erstellt/aktualisiert die angegebene Datei, ohne die aktuelle zu bearbeiten, indem auf einen absoluten Pfad verwiesen wird, der basierend auf Ihrem Betriebssystem aufgelöst wird
+6. **`fill: { [key in Locales]?: string }`** - Erstellt/aktualisiert die angegebene Datei für jede Locale
+
+### v7 Behavior Changes
+
+In v7 hat sich das Verhalten des `fill`-Befehls aktualisiert:
+
+- **`fill: true`** - Schreibt die aktuelle Datei mit gefülltem Inhalt für alle Locales um
+- **`fill: "path/to/file"`** - Füllt die angegebene Datei, ohne die aktuelle Datei zu ändern
+- **`fill: false`** - Deaktiviert Auto-Fill vollständig
+
+Bei Verwendung einer Path-Option zum Schreiben in eine andere Datei funktioniert der Fill-Mechanismus über eine _Master-Slave_-Beziehung zwischen Content-Declaration-Dateien. Die Hauptdatei (Master) dient als Single Source of Truth, und wenn sie aktualisiert wird, wendet Intlayer diese Änderungen automatisch auf die abgeleiteten (gefüllten) Declaration-Dateien an, die durch den Path angegeben werden.
+
 # Übersetzungen der Deklarationsdatei für automatisches Ausfüllen von Inhalten
 
 **Deklarationsdateien für automatisches Ausfüllen von Inhalten** sind eine Möglichkeit, Ihren Entwicklungsworkflow zu beschleunigen.
@@ -88,6 +135,40 @@ Intlayer generiert automatisch die abgeleitete Deklarationsdatei unter `src/comp
 
 Anschließend werden beide Deklarationsdateien zu einem einzigen Wörterbuch zusammengeführt, das über den Standard-`useIntlayer("example")` Hook (React) / Composable (Vue) zugänglich ist.
 
+## Globale Konfiguration
+
+Sie können die globale Auto-Fill-Konfiguration in der Datei `intlayer.config.ts` konfigurieren.
+
+```ts fileName="intlayer.config.ts"
+import { type IntlayerConfig, Locales } from "intlayer";
+
+const config: IntlayerConfig = {
+  internationalization: {
+    locales: [Locales.ENGLISH, Locales.FRENCH, Locales.SPANISH],
+    defaultLocale: Locales.ENGLISH,
+    requiredLocales: [Locales.ENGLISH, Locales.FRENCH],
+  },
+  dictionary: {
+    // Fehlende Übersetzungen automatisch für alle Wörterbücher generieren
+    fill: "./{{fileName}}Filled.content.ts",
+    //
+    // fill: "/messages/{{locale}}/{{key}}/{{fileName}}.content.json",
+    //
+    // fill: true, // Fehlende Übersetzungen automatisch für alle Wörterbücher generieren wie die Verwendung von "./{{fileName}}.content.json"
+    //
+    // fill: {
+    //   en: "./{{fileName}}.en.content.json",
+    //   fr: "./{{fileName}}.fr.content.json",
+    //   es: "./{{fileName}}.es.content.json",
+    // },
+  },
+};
+
+export default config;
+```
+
+Sie können die Konfiguration pro Wörterbuch noch optimieren, indem Sie das Feld `fill` in Content-Dateien verwenden. Intlayer berücksichtigt zunächst die Pro-Wörterbuch-Konfiguration und fällt dann auf die globale Konfiguration zurück.
+
 ## Automatisch ausgefülltes Dateiformat
 
 Das empfohlene Format für automatisch ausgefüllte Deklarationsdateien ist **JSON**, da es Formatierungsbeschränkungen vermeidet. Intlayer unterstützt jedoch auch `.ts`, `.js`, `.mjs`, `.cjs` und andere Formate.

package/docs/de/benchmark/solid.md

@@ -118,6 +118,28 @@ Wir haben **vier Ladestrategien** verglichen:
 - **Scoped static**: Hält den Code organisiert (logische Trennung) ohne komplexe zusätzliche Netzwerkanfragen.
 - **Scoped dynamic**: Bester Ansatz für _Code-Splitting_ und Leistung. Minimiert den Speicherverbrauch, indem nur das geladen wird, was die aktuelle Ansicht und die aktive Locale benötigen.
 
+### Was ich gemessen habe:
+
+Ich habe dieselbe mehrsprachige App in einem echten Browser für jeden Stack ausgeführt und dann notiert, was tatsächlich übertragen wurde und wie lange es dauerte. Größen werden **nach normaler Web-Komprimierung** gemeldet, da dies näher an dem liegt, was Benutzer herunterladen, als an rohen Quellzählungen.
+
+- **Internationalization-Bibliotheksgröße**: Nach dem Bundling, Tree-Shaking und Minifizierung ist die Größe der i18n-Bibliothek die Größe der Provider + Hooks/Primitives-Code in einer leeren Komponente. Sie beinhaltet nicht das Laden von Übersetzungsdateien. Sie antwortet darauf, wie teuer die Bibliothek ist, bevor Ihr Inhalt ins Spiel kommt.
+
+- **JavaScript pro Seite**: Für jede Benchmark-Route, wie viel Skript der Browser bei diesem Besuch abruft, gemittelt über die Seiten in der Suite (und über Sprachen, wenn der Bericht sie zusammenfasst). Schwere Seiten sind langsame Seiten.
+
+- **Leakage von anderen Sprachen**: Es ist der Inhalt derselben Seite, aber in einer anderen Sprache, die versehentlich auf der überprüften Seite geladen würde. Dieser Inhalt ist unnötig und sollte vermieden werden. (z. B. Inhalt der Seite `/fr/about` im Bundle `/en/about`)
+
+- **Leakage von anderen Routes**: Die gleiche Idee für **andere Bildschirme** in der App: ob ihr Text mitlädt, wenn Sie nur eine Seite öffnen. (z. B. Inhalt der Seite `/en/about` im Bundle `/en/contact`). Eine hohe Punktzahl deutet auf schwache Aufteilung oder zu breite Bundles hin.
+
+- **Durchschnittliche Komponenten-Bundle-Größe**: Häufige UI-Elemente werden **einzeln** gemessen, anstatt sich in einer großen App-Nummer zu verstecken. Es zeigt, ob die Internationalisierung alltägliche Komponenten stillschweigend aufbläht. Wenn beispielsweise Ihre Komponente neu gerendert wird, lädt sie alle diese Daten aus dem Speicher. Das Anhängen eines großen JSON an eine Komponente ist wie das Verbinden mit einem großen Speicher von ungenutzten Daten, die die Leistung Ihrer Komponenten verlangsamen.
+
+- **Responsivität beim Sprachenwechsel**: Ich wechsle die Sprache mit dem eigenen Steuerelement der App und messe, wie lange es dauert, bis die Seite deutlich gewechselt hat, was ein Besucher bemerken würde, nicht ein Lab-Micro-Schritt.
+
+- **Rendering-Arbeit nach einem Sprachenwechsel**: Eine engere Nachverfolgung: wie viel Aufwand die Schnittstelle brauchte, um für die neue Sprache neu zu zeichnen, sobald der Wechsel im Fluss ist. Nützlich, wenn sich die „gefühlte" Zeit und die Framework-Kosten unterscheiden.
+
+- **Anfängliche Seitenladezeit**: Von der Navigation bis der Browser die Seite für die getesteten Szenarien als vollständig geladen betrachtet. Gut für den Vergleich von Cold Starts.
+
+- **Hydration-Zeit**: Wenn die App es offenlegt, wie lange der Client damit verbringt, Server-HTML in etwas umzuwandeln, das Sie tatsächlich anklicken können. Ein Bindestrich in den Tabellen bedeutet, dass diese Implementierung in diesem Benchmark keine zuverlässige Hydration-Zahl lieferte.
+
 ## GitHub-Sterne
 
 GitHub-Sterne sind ein starker Indikator für die Popularität eines Projekts, das Vertrauen der Community und die langfristige Relevanz. Sie sind zwar kein direktes Maß für die technische Qualität, spiegeln jedoch wider, wie viele Entwickler das Projekt nützlich finden, seinen Fortschritt verfolgen und es wahrscheinlich übernehmen werden. Um den Wert eines Projekts einzuschätzen, helfen Sterne dabei, die Traktion verschiedener Alternativen zu vergleichen und Einblicke in das Wachstum des Ökosystems zu gewinnen.

package/docs/de/benchmark/svelte.md

@@ -116,6 +116,28 @@ Wir haben **vier Ladestrategien** verglichen:
 - **Scoped static**: Hält den Code organisiert (logische Trennung) ohne komplexe zusätzliche Netzwerkanfragen.
 - **Scoped dynamic**: Bester Ansatz für _Code-Splitting_ und Leistung. Minimiert den Speicherverbrauch, indem nur das geladen wird, was die aktuelle Ansicht und die aktive Locale benötigen.
 
+### Was ich gemessen habe:
+
+Ich habe dieselbe mehrsprachige App in einem echten Browser für jeden Stack ausgeführt und dann notiert, was tatsächlich auf der Leitung angezeigt wurde und wie lange es dauerte. Die Größen werden **nach normaler Webkomprimierung** angegeben, da dies näher daran liegt, was Benutzer herunterladen, als rohe Quellzählungen.
+
+- **Größe der Internationalisierungsbibliothek**: Nach dem Bundeln, Tree-Shaking und der Minifizierung ist die Größe der i18n-Bibliothek die Größe des Providers + Stores-Code in einer leeren Komponente. Sie beinhaltet nicht das Laden von Übersetzungsdateien. Sie beantwortet die Frage, wie teuer die Bibliothek ist, bevor Ihr Inhalt ins Spiel kommt.
+
+- **JavaScript pro Seite**: Für jede Benchmark-Route, wie viel Skript der Browser bei diesem Besuch abruft, gemittelt über die Seiten in der Suite (und über Sprachen, in denen der Bericht diese zusammenfasst). Schwere Seiten sind langsame Seiten.
+
+- **Speicherleck aus anderen Sprachen**: Es ist der Inhalt derselben Seite in einer anderen Sprache, der versehentlich auf die audited Seite geladen würde. Dieser Inhalt ist unnötig und sollte vermieden werden. (z. B. Inhalt der Seite `/fr/about` im Bundle der Seite `/en/about`)
+
+- **Speicherleck aus anderen Routen**: Dieselbe Idee für **andere Bildschirme** in der App: ob deren Kopie mitlädt, wenn Sie nur eine Seite geöffnet haben. (z. B. Inhalt der Seite `/en/about` im Bundle der Seite `/en/contact`). Ein hoher Wert deutet auf schwaches Splitting oder über-breite Bundles hin.
+
+- **Durchschnittliche Komponentenbündelgröße**: Häufige UI-Teile werden **einzeln** gemessen, anstatt sich in einer großen App-Nummer zu verstecken. Es zeigt, ob die Internationalisierung alltägliche Komponenten unauffällig aufbläht. Wenn Ihre Komponente beispielsweise neu gerendert wird, wird sie alle diese Daten aus dem Speicher laden. Das Anhängen eines großen JSON an eine Komponente ist wie das Verbinden mit einem großen Speicher ungenutzter Daten, der die Leistung Ihrer Komponenten verlangsamt.
+
+- **Sprachschalter-Reaktionsfähigkeit**: Ich wechsle die Sprache mit dem eigenen Steuerelement der App und messe, wie lange es dauert, bis sich die Seite klar gewechselt hat, was ein Besucher bemerken würde, nicht ein Lab-Mikro-Schritt.
+
+- **Rendering-Arbeit nach einem Sprachwechsel**: Ein engerer Nachfolger: wie viel Aufwand die Benutzeroberfläche brauchte, um sich für die neue Sprache neu zu streichen, sobald der Wechsel in Gang ist. Nützlich, wenn sich die „gefühlte" Zeit und die Framework-Kosten unterscheiden.
+
+- **Anfängliche Seitenladezeit**: Von der Navigation zum Browser, der die Seite für die von mir getesteten Szenarien vollständig geladen betrachtet. Gut zum Vergleichen kalter Starts.
+
+- **Hydrationisierungszeit**: Wenn die App es offenlegt, wie lange der Client damit verbringt, Server-HTML in etwas zu verwandeln, das Sie tatsächlich anklicken können. Ein Bindestrich in den Tabellen bedeutet, dass diese Implementierung in dieser Benchmark keine zuverlässige Hydrationsfigur bereitgestellt hat.
+
 ## GitHub-Sterne
 
 GitHub-Sterne sind ein starker Indikator für die Popularität eines Projekts, das Vertrauen der Community und die langfristige Relevanz. Sie sind zwar kein direktes Maß für die technische Qualität, spiegeln jedoch wider, wie viele Entwickler das Projekt nützlich finden, seinen Fortschritt verfolgen und es wahrscheinlich übernehmen werden. Um den Wert eines Projekts einzuschätzen, helfen Sterne dabei, die Traktion verschiedener Alternativen zu vergleichen und Einblicke in das Wachstum des Ökosystems zu gewinnen.

package/docs/de/benchmark/tanstack.md

@@ -124,6 +124,28 @@ Wir haben **vier Ladestrategien** verglichen:
 - **Scoped static**: Hält den Code organisiert (logische Trennung) ohne komplexe zusätzliche Netzwerkanfragen.
 - **Scoped dynamic**: Bester Ansatz für _Code-Splitting_ und Performance. Minimiert den Speicherbedarf, indem nur das geladen wird, was der aktuelle View und die aktive Sprache benötigen.
 
+### Was ich gemessen habe:
+
+Ich habe dieselbe mehrsprachige App in einem echten Browser für jeden Stack ausgeführt, dann notiert, was tatsächlich über die Leitung ging und wie lange es dauerte. Die Größen werden **nach normaler Webekomprimierung** angegeben, da dies näher an dem liegt, was Benutzer herunterladen, als rohe Quellzählungen.
+
+- **Größe der Internationalisierungsbibliothek**: Nach Bundling, Tree-Shaking und Minifizierung ist die Größe der i18n-Bibliothek die Größe der Provider (z. B. `NextIntlClientProvider`) + Hooks (z. B. `useTranslations`) Code in einer leeren Komponente. Sie umfasst nicht das Laden von Übersetzungsdateien. Sie beantwortet die Frage, wie teuer die Bibliothek ist, bevor Ihr Inhalt ins Spiel kommt.
+
+- **JavaScript pro Seite**: Für jede Benchmark-Route, wie viel Skript der Browser bei diesem Besuch abruft, gemittelt über die Seiten in der Suite (und über Locales, wo der Bericht sie zusammenführt). Schwere Seiten sind langsame Seiten.
+
+- **Leckage aus anderen Locales**: Es ist der Inhalt derselben Seite, aber in einer anderen Sprache, der versehentlich in die geprüfte Seite geladen würde. Dieser Inhalt ist unnötig und sollte vermieden werden. (z. B. Inhalt der Seite `/fr/about` im Bundle der Seite `/en/about`)
+
+- **Leckage aus anderen Routes**: Dieselbe Idee für **andere Bildschirme** in der App: ob ihre Kopie mitkommen, wenn Sie nur eine Seite öffnen. (z. B. Inhalt der Seite `/en/about` im Bundle der Seite `/en/contact`). Ein hoher Wert deutet auf schwache Aufteilung oder zu breite Bundles hin.
+
+- **Durchschnittliche Komponentenbundel-Größe**: Häufig verwendete UI-Elemente werden **einzeln** gemessen, anstatt sie in einer riesigen App-Nummer zu verbergen. Es zeigt, ob die Internationalisierung alltägliche Komponenten stillschweigend aufbläht. Wenn Ihre Komponente beispielsweise neu gerendert wird, werden alle diese Daten aus dem Speicher geladen. Das Anhängen einer riesigen JSON an eine Komponente ist wie das Verbinden mit einem großen Speicher ungenutzter Daten, die die Leistung Ihrer Komponenten verlangsamen.
+
+- **Responsivität des Sprachwechsels**: Ich wechsle die Sprache mit der eigenen Kontrolle der App und messe, wie lange es dauert, bis die Seite eindeutig gewechselt hat, was ein Besucher bemerken würde, nicht ein Lab-Mikro-Schritt.
+
+- **Rendering-Arbeit nach einem Sprachwechsel**: Eine engere Folgefrage: wie viel Aufwand die Schnittstelle aufgewandt hat, um für die neue Sprache neu zu zeichnen, sobald der Wechsel im Gange ist. Nützlich, wenn die „gefühlte" Zeit und die Framework-Kosten auseinandergehen.
+
+- **Anfängliche Seitenladezeit**: Von der Navigation bis zur Annahme der vollständig geladenen Seite durch den Browser für die getesteten Szenarien. Gut zum Vergleichen von Kaltstart.
+
+- **Hydrationsdauer**: Wenn die App sie offenlegt, wie lange der Client damit verbringt, Server-HTML in etwas Klickbares umzuwandeln. Ein Bindestrich in den Tabellen bedeutet, dass diese Implementierung in diesem Benchmark keine zuverlässige Hydrationszahl bereitgestellt hat.
+
 ## GitHub-Sterne
 
 GitHub-Sterne sind ein starker Indikator für die Popularität eines Projekts, das Vertrauen der Community und die langfristige Relevanz. Sie sind zwar kein direktes Maß für die technische Qualität, spiegeln jedoch wider, wie viele Entwickler das Projekt nützlich finden, seinen Fortschritt verfolgen und es wahrscheinlich übernehmen werden. Um den Wert eines Projekts einzuschätzen, helfen Sterne dabei, die Traktion verschiedener Alternativen zu vergleichen und Einblicke in das Wachstum des Ökosystems zu gewinnen.

package/docs/de/cli/ci.md

@@ -140,6 +140,28 @@ steps:
     run: npx intlayer ci fill
 ```
 
+## Gerüstete GitHub Actions
+
+Wenn Sie `intlayer init` ausführen, erkennt Intlayer Ihren Paketmanager (npm, yarn, pnpm oder bun) und erstellt zwei GitHub Actions-Workflows unter `.github/workflows/` mit Befehlen, die diesem Paketmanager entsprechen:
+
+- **`intlayer-fill.yml`** — Bei jedem Pull Request werden die Wörterbücher erstellt und `intlayer fill --git-diff --mode complete` ausgeführt, um fehlende Übersetzungen für die geänderten Wörterbücher zu generieren, und dann wird das Ergebnis auf den PR-Branch committed.
+- **`intlayer-test.yml`** — Bei jedem Pull Request werden die Wörterbücher erstellt und `intlayer test` ausgeführt, wobei die Prüfung fehlschlägt, wenn erforderliche Lokalisierungen fehlende Übersetzungen haben.
+
+Vorhandene Workflow-Dateien werden niemals überschrieben. Um das Scaffolding vollständig zu überspringen, führen Sie aus:
+
+```bash
+npx intlayer init --no-github-actions
+```
+
+### AI-Zugriff für den Fill-Workflow bereitstellen
+
+Die gerüstete `intlayer-fill.yml` erfordert AI-Zugriff. Es stehen zwei Optionen zur Verfügung (konfiguriert im `env`-Block des Workflows):
+
+1. **Ihr eigener AI-Provider-Schlüssel** — Fügen Sie ein `AI_API_KEY`-Secret in Ihren Repository-Einstellungen hinzu (Settings → Secrets and variables → Actions). Der Workflow leitet ihn über `--provider`, `--model` und `--api-key` weiter.
+2. **Intlayer CMS-Zugangsschlüssel** — Fügen Sie `INTLAYER_CLIENT_ID` und `INTLAYER_CLIENT_SECRET`-Secrets hinzu und verbinden Sie sie mit Ihrem `intlayer.config` `editor`-Abschnitt. CMS-Zugangsschlüssel gewähren AI-Zugriff über das Intlayer-Backend.
+
+Der `intlayer-test.yml`-Workflow erfordert keinen AI-Zugriff.
+
 ## Fehlerbehandlung
 
 - Wenn `INTLAYER_PROJECT_CREDENTIALS` nicht gesetzt ist, beendet sich der Befehl mit einem Fehler.

package/docs/de/cli/fill.md

@@ -47,6 +47,14 @@ Wichtige Punkte:
 - Erhält bestehende Übersetzungen, indem sie nicht überschrieben werden.
 - Verarbeitet Dateien, Chunks und Locales parallel mithilfe eines Warteschlangensystems, um die Geschwindigkeit zu erhöhen.
 
+## Wichtige Punkte:
+
+- Teilt große JSON-Dateien in Chunks auf, um innerhalb der Kontextfenster-Limits des AI-Modells zu bleiben.
+- Wiederholt die Übersetzung, wenn das Ausgabeformat falsch ist.
+- Berücksichtigt anwendungs- und dateispezifische Kontexte für verbesserte Übersetzungsgenauigkeit.
+- Bewahrt bestehende Übersetzungen, indem sie nicht überschrieben werden.
+- Verarbeitet Dateien, Chunks und Locales parallel mit einem Queue-System, um die Geschwindigkeit zu erhöhen.
+
 ## Aliase:
 
 - `npx intlayer dictionaries fill`

package/docs/de/cli/init.md

@@ -109,6 +109,26 @@ bun x intlayer init --project-root ./my-project
 
 Dies initialisiert Intlayer im angegebenen Verzeichnis.
 
+### Initialisierung ohne .gitignore zu aktualisieren:
+
+```bash packageManager="npm"
+npx intlayer init --no-gitignore
+```
+
+```bash packageManager="yarn"
+yarn intlayer init --no-gitignore
+```
+
+```bash packageManager="pnpm"
+pnpm intlayer init --no-gitignore
+```
+
+```bash packageManager="bun"
+bun x intlayer init --no-gitignore
+```
+
+Dies richtet alle Konfigurationsdateien ein, ohne Ihre `.gitignore` zu ändern.
+
 ## Beispielausgabe:
 
 ```bash

package/docs/de/compat/i18n-js.md

@@ -0,0 +1,44 @@
+---
+createdAt: 2026-06-13
+updatedAt: 2026-06-13
+title: "Migration von i18n-js zu Intlayer"
+description: "Erfahren Sie, wie Sie Ihre Anwendung von i18n-js zu Intlayer mithilfe des Compat-Adapters migrieren."
+keywords:
+  - i18n-js
+  - intlayer
+  - migration
+  - compat
+slugs:
+  - doc
+  - compatibility
+  - i18n-js
+history:
+  - version: 9.0.0
+    date: 2026-06-13
+    changes: "Verlauf initialisiert"
+author: aymericzip
+---
+
+# Migration von i18n-js zu Intlayer
+
+Der Übergang von der `i18n-js`-Bibliothek zu Intlayer ist eine hochoptimierte Migration, die darauf ausgelegt ist, umfangreiche Übersetzungskonfigurationen in Intlayers strukturiertes Dateiauflösungssystem auszulagern.
+
+## Was zu tun ist
+
+Führen Sie den folgenden Setup-Befehl in Ihrem Repository aus:
+
+```bash
+npx intlayer init
+```
+
+Wenn `intlayer.config.ts` vorbereitet ist, können Sie Intlayers Alias zu Ihrer Bundler-Konfiguration hinzufügen, sodass alle Imports von `i18n-js` auf das Compat-Paket `@intlayer/i18n-js` abzielen.
+
+## Was im Hintergrund geschieht
+
+`i18n-js` greift auf Namespaces über Ausdrücke wie `i18n.t('scope.key', {name})` zusammen mit Locale-Fallbacks und spezifischen Plural-Zuordnungen zu.
+
+Im Hintergrund:
+
+- **Interpolation:** Der Compat-Adapter analysiert problemlos `%{name}`-Zuordnungen in Ihren angestrebten Laufzeit-Wörterbuch-Wert.
+- **Pluralisierung:** Ersetzt `one/other`-Unterschlüssel und ordnet sie den leistungsstarken zugrunde liegenden Plural-Mechanismen von Intlayer zu (`Intl.PluralRules`), wodurch manuelle Zuordnungen abstrahiert werden.
+- **Locales:** Anstatt monolithische Sprach-Payloads beim Start zu laden, werden Wörterbücher optimal basierend auf dem aktuellen Kontext bereitgestellt, der über die native Intlayer-Konfiguration eingerichtet wird.

package/docs/de/compat/i18next.md

@@ -0,0 +1,59 @@
+---
+createdAt: 2026-06-13
+updatedAt: 2026-06-13
+title: "Migration von i18next zu Intlayer"
+description: "Erfahren Sie, wie Sie Ihre Vanilla JS/TS-Anwendung von i18next zu Intlayer mithilfe des Compat-Adapters migrieren."
+keywords:
+  - i18next
+  - vanilla
+  - javascript
+  - typescript
+  - intlayer
+  - migration
+  - compat
+slugs:
+  - doc
+  - compatibility
+  - i18next
+history:
+  - version: 9.0.0
+    date: 2026-06-13
+    changes: "Verlauf initialisiert"
+author: aymericzip
+---
+
+# Migration von i18next zu Intlayer
+
+Für ein detailliertes Schritt-für-Schritt-Tutorial lesen Sie bitte unsere vollständige [i18next Migrationsanleitung](../migration_from_i18next_to_intlayer.md).
+
+Intlayer repliziert die wichtigsten Laufzeiteigenschaften von `i18next` perfekt. Durch die Verwendung des Compat-Pakets können Ihre Vanilla-Anwendungen oder internen Module die vertraute Syntax weiterhin nutzen.
+
+## Was zu tun ist
+
+Um zu beginnen, initialisieren Sie Intlayer in Ihrem Projekt:
+
+```bash
+npx intlayer init
+```
+
+Wenn Sie Vite verwenden, fügen Sie das Intlayer-Plugin hinzu, um Imports zu `@intlayer/i18next` weiterzuleiten:
+
+```typescript fileName="vite.config.ts"
+import { defineConfig } from "vite";
+import { i18nextVitePlugin } from "@intlayer/i18next/plugin";
+
+export default defineConfig({
+  plugins: [i18nextVitePlugin()],
+});
+```
+
+## Was im Hintergrund geschieht
+
+Das `i18nextVitePlugin` aliasiert `i18next`-Imports zu `@intlayer/i18next` und vermeidet so Bundle-Aufblähung durch JSON-Datei-Einschlüsse.
+
+Im Hintergrund:
+
+- **Instanzkonfiguration:** `createInstance` analysiert und wendet Namespace-Fallbacks korrekt an und nutzt dabei Intlayers Kompilierungs-Pipeline für den Wörterbuchabruf.
+- **Interpolation:** Native Unterstützung für `{{name}}`-Ersetzungen und rekursives `$t(key)`-Verschachteln.
+- **Kontext & Plurale:** Identifiziert und löst Suffix-Formate wie `key_male` und `key_one`/`key_other` auf, die gegen Standard-`Intl.PluralRules` ausgewertet werden.
+- **Rückgabeobjekte:** Der Modus `returnObjects: true` extrahiert sicher Bäume aus Intlayer-Wörterbüchern.

package/docs/de/compat/index.md

@@ -0,0 +1,51 @@
+---
+createdAt: 2026-06-13
+updatedAt: 2026-06-13
+title: "Intlayer Compat Adapter"
+description: "Migrieren Sie Ihre bestehende i18n-Lösung mit null Reibung zu Intlayer mithilfe von Compat-Adaptern."
+keywords:
+  - compat
+  - migration
+  - Internationalisierung
+  - i18n
+  - Intlayer
+slugs:
+  - doc
+  - compatibility
+history:
+  - version: 9.0.0
+    date: 2026-06-13
+    changes: "Verlauf initialisiert"
+author: aymericzip
+---
+
+# Intlayer Compat Adapter
+
+Die Migration einer großen Anwendung zu einer neuen Internationalisierungsbibliothek kann entmutigend sein. Um diesen Übergang zu erleichtern, bietet Intlayer **Compat-Adapter** für die beliebtesten i18n-Bibliotheken im Ökosystem.
+
+Diese Adapter-Pakete stellen die **exakt gleiche öffentliche API** wie Ihre bestehenden i18n-Bibliotheken bereit, delegieren jedoch die gesamte Übersetzungsarbeit zur Laufzeit an Intlayer.
+
+## Funktionsweise
+
+Wenn Sie einen Compat-Adapter verwenden, müssen Sie die Imports Ihrer Anwendung nicht umschreiben oder ändern, wie Sie Ihre Übersetzungs-Hooks und -Komponenten verwenden. Stattdessen aliasieren Intlayers Bundler-Plugins automatisch Ihre bestehenden Imports auf die Intlayer Compat-Pakete.
+
+Zum Beispiel ersetzt ein Entwickler `import { useTranslation } from 'react-i18next'` durch `import { useTranslation } from '@intlayer/react-i18next'` (dies geschieht automatisch über das Bundler-Plugin), und die Anwendung funktioniert weiterhin, wobei Übersetzungen nun aus Intlayer-Wörterbüchern bereitgestellt werden. Schlüssel werden auch gegen Ihre Intlayer-Wörterbücher typisiert!
+
+## Verfügbare Compat-Adapter
+
+Wählen Sie Ihre bestehende Bibliothek unten aus, um zu sehen, wie Sie nahtlos migrieren können:
+
+- [Vue I18n](./vue-i18n.md)
+- [Transloco](./transloco.md)
+- [React Intl](./react-intl.md)
+- [Svelte I18n](./svelte-i18n.md)
+- [React i18next](./react-i18next.md)
+- [Polyglot.js](./polyglot.md)
+- [NuxtJS I18n](./nuxtjs-i18n.md)
+- [NGX Translate](./ngx-translate.md)
+- [Next Translate](./next-translate.md)
+- [Next Intl](./next-intl.md)
+- [Next i18next](./next-i18next.md)
+- [i18next](./i18next.md)
+- [Lingui](./lingui.md)
+- [I18n-js](./i18n-js.md)

package/docs/de/compat/lingui.md

@@ -0,0 +1,44 @@
+---
+createdAt: 2026-06-13
+updatedAt: 2026-06-13
+title: "Migration von Lingui zu Intlayer"
+description: "Erfahren Sie, wie Sie Ihre Anwendung von Lingui zu Intlayer mithilfe des Compat-Adapters migrieren."
+keywords:
+  - lingui
+  - intlayer
+  - migration
+  - compat
+slugs:
+  - doc
+  - compatibility
+  - lingui
+history:
+  - version: 9.0.0
+    date: 2026-06-13
+    changes: "Verlauf initialisiert"
+author: aymericzip
+---
+
+# Migration von Lingui zu Intlayer
+
+Wenn Ihr Projekt derzeit auf Linguis makrobasierter Kompilierung basiert, ermöglicht Ihnen die Migration zu Intlayer, Ihre leistungsstarken Makro-Workflows beizubehalten und sie nativ mit Intlayers JSON-Kompilierungsstrategie zu unterstützen.
+
+## Was zu tun ist
+
+Um zu beginnen, initialisieren Sie Intlayer in Ihrem Projekt:
+
+```bash
+npx intlayer init
+```
+
+Dies erstellt Ihre `intlayer.config.ts`. Stellen Sie sicher, dass Sie `@lingui/babel-plugin-lingui-macro` / `@lingui/swc-plugin` in Ihrem Build-Schritt behalten, damit es _vor_ dem Intlayer-Compiler ausgeführt wird. Verwenden Sie dann den Bundler-Plugin-Alias, um `@lingui/core` und `@lingui/react` zu `@intlayer/lingui` weiterzuleiten.
+
+## Was im Hintergrund geschieht
+
+Lingui verwendet Makros (wie `` t`Hello ${name}` `` und `<Trans>`), die in Laufzeitaufrufe wie `i18n._(id, values)` kompiliert werden.
+
+Im Hintergrund:
+
+- **Makros:** Sie kompilieren genau wie zuvor, ohne Unterbrechung in Ihrer Quellsyntax.
+- **Laufzeitübersetzung:** Das aliasierte `i18n._()` verwendet Intlayer-Wörterbücher. Sowohl explizit benannte IDs als auch Hash-IDs werden mithilfe der `.po`-Sync-Plugins von Intlayer vollständig zugeordnet, um Schlüssel sicher zu aggregieren und zu bereinigen.
+- **ICU-Fähigkeiten:** Die Unterstützung für Pluralisierung, Auswahl und ICU-Varianten bleibt dank des einheitlichen ICU-Parsers von Intlayer robust und gewährleistet identische Rendering-Ausgaben.

package/docs/de/compat/next-i18next.md

@@ -0,0 +1,57 @@
+---
+createdAt: 2026-06-13
+updatedAt: 2026-06-13
+title: "Migration von next-i18next zu Intlayer"
+description: "Erfahren Sie, wie Sie Ihre Next.js-Anwendung von next-i18next zu Intlayer mithilfe des Compat-Adapters migrieren."
+keywords:
+  - next-i18next
+  - nextjs
+  - intlayer
+  - migration
+  - compat
+slugs:
+  - doc
+  - compatibility
+  - next-i18next
+history:
+  - version: 9.0.0
+    date: 2026-06-13
+    changes: "Verlauf initialisiert"
+author: aymericzip
+---
+
+# Migration von next-i18next zu Intlayer
+
+Für ein vollständiges und detailliertes Schritt-für-Schritt-Tutorial lesen Sie bitte unsere vollständige [next-i18next Migrationsanleitung](../migration_from_next-i18next_to_intlayer.md).
+
+Intlayer behandelt alle Next.js Pages Router- und App Router-Implementierungen transparent. Die Verwendung des Adapters ermöglicht Ihnen die Migration Ihrer `next-i18next`-Implementierung ohne Code-Umschreiben.
+
+## Was zu tun ist
+
+Um zu beginnen, führen Sie aus:
+
+```bash
+npx intlayer init
+```
+
+Dies erstellt die erforderliche Intlayer-Setup-Datei. Um im Hintergrund zu Intlayer zu wechseln, aktualisieren Sie Ihre `next.config.ts`:
+
+```typescript fileName="next.config.ts"
+import type { NextConfig } from "next";
+import { createNextI18nPlugin } from "@intlayer/next-i18next/plugin";
+
+const withIntlayer = createNextI18nPlugin();
+
+const nextConfig: NextConfig = {};
+
+export default withIntlayer(nextConfig);
+```
+
+## Was im Hintergrund geschieht
+
+Das `createNextI18nPlugin` kombiniert das native Verhalten von Next.js mit dem Kern-`next-intlayer`-Plugin und injiziert alle erforderlichen Webpack/Turbopack-Aliase für `next-i18next`, `react-i18next` und `i18next`.
+
+Im Hintergrund:
+
+- **`serverSideTranslations` & `appWithTranslation`:** Sie fungieren nun als Wrapper für Intlayers interne Loader und umgehen die umfangreiche statische JSON-Injektion.
+- **Client-Hooks:** Delegiert sofort an `@intlayer/react-i18next` und behält alle Formatierungs-, Plural- und verschachtelte Namespace-Funktionen bei.

package/docs/de/compat/next-intl.md

@@ -0,0 +1,59 @@
+---
+createdAt: 2026-06-13
+updatedAt: 2026-06-13
+title: "Migration von next-intl zu Intlayer"
+description: "Erfahren Sie, wie Sie Ihre Next.js-Anwendung von next-intl zu Intlayer mithilfe des Compat-Adapters migrieren."
+keywords:
+  - next-intl
+  - nextjs
+  - intlayer
+  - migration
+  - compat
+slugs:
+  - doc
+  - compatibility
+  - next-intl
+history:
+  - version: 9.0.0
+    date: 2026-06-13
+    changes: "Verlauf initialisiert"
+author: aymericzip
+---
+
+# Migration von next-intl zu Intlayer
+
+Für ein vollständiges und detailliertes Schritt-für-Schritt-Tutorial lesen Sie bitte unsere vollständige [next-intl Migrationsanleitung](../migration_from_next-intl_to_intlayer.md).
+
+Die Migration von `next-intl` zu Intlayer ermöglicht es Ihnen, Ihr Anwendungsrouting und Ihre Syntax vollständig ungestört beizubehalten.
+
+## Was zu tun ist
+
+Führen Sie den folgenden Befehl in Ihrem Repository aus:
+
+```bash
+npx intlayer init
+```
+
+Dadurch wird eine `intlayer.config.ts` erstellt. Verwenden Sie in Ihrer `next.config.ts` den Plugin-Wrapper, um die `next-intl`-Aliase nahtlos zu `@intlayer/next-intl` weiterzuleiten.
+
+```typescript fileName="next.config.ts"
+import type { NextConfig } from "next";
+import { createNextIntlPlugin } from "@intlayer/next-intl/plugin";
+
+const withIntlayer = createNextIntlPlugin();
+
+const nextConfig: NextConfig = {};
+
+export default withIntlayer(nextConfig);
+```
+
+## Was im Hintergrund geschieht
+
+Der Bundler-Wrapper ersetzt Übersetzungen, **lässt die `next-intl/navigation`-Funktionen jedoch intakt** (z.B. `Link`, `redirect`, `usePathname`).
+
+Im Hintergrund:
+
+- **ICU-Laufzeit:** Plurale (`=0`, `one`, `other`), select/selectordinal, `#`-Argumente und formatierte Argumente (`{ts, date, long}`) werden korrekt mit dem gemeinsamen `resolveMessage(..., 'icu')`-Resolver ausgeführt.
+- **`useTranslations()` & `getTranslations()`:** Die einfachen Scope-Aufrufe extrahieren das erste Schlüsselsegment als korrekten Wörterbuch-Bezeichner. Verschachtelte Namespaces werden elegant in Wörterbuchpfade und Präfixe aufgeteilt.
+- **Rich Formatting:** Sowohl `t.rich()` als auch `t.markup()` sind vollständig nativ implementiert und konvertieren HTML-ähnliche Knoten in gerenderte React-Abschnitte.
+- **`useFormatter`:** `relativeTime`, `list`, `dateTimeRange` und benannte Formate aus der Konfiguration überbrücken zu den nativen `Intl`-Formatierern des Kerns.

package/docs/de/compat/next-translate.md

@@ -0,0 +1,45 @@
+---
+createdAt: 2026-06-13
+updatedAt: 2026-06-13
+title: "Migration von Next Translate zu Intlayer"
+description: "Erfahren Sie, wie Sie Ihre Next.js-Anwendung von next-translate zu Intlayer mithilfe des Compat-Adapters migrieren."
+keywords:
+  - next-translate
+  - nextjs
+  - intlayer
+  - migration
+  - compat
+slugs:
+  - doc
+  - compatibility
+  - next-translate
+history:
+  - version: 9.0.0
+    date: 2026-06-13
+    changes: "Verlauf initialisiert"
+author: aymericzip
+---
+
+# Migration von Next Translate zu Intlayer
+
+Die Migration von `next-translate` zu Intlayer ist ein nahezu direkter Ersatz, der Ihre bestehende Syntax und Tags beibehält.
+
+## Was zu tun ist
+
+Initialisieren Sie Intlayer in Ihrem Projekt:
+
+```bash
+npx intlayer init
+```
+
+Die CLI richtet Ihre Konfiguration ein. Anschließend können Sie das Intlayer-Plugin in Ihrer `next.config.ts` anwenden, das Build-Zeit-Subpfad-Aliase injiziert und `next-translate/useTranslation` auf `@intlayer/next-translate` abbildet.
+
+## Was im Hintergrund geschieht
+
+`next-translate` stellt Hooks wie `useTranslation('ns')`, `t('ns:key.path')` und die `<Trans>`-Komponente bereit.
+
+Im Hintergrund:
+
+- **Interpolation & Plurale:** Es basiert eng auf dem `react-i18next`-Adapter-Verhalten. `{{var}}`-Platzhalter und Pluralisierung, die aus Suffixen wie `key_0`, `key_one` und `key_other` zugeordnet werden, werden dynamisch behandelt.
+- **`<Trans>`-Komponente:** Direkt unterstützt für HTML-ähnliches Tag-Parsing neben einem arraybasierten `components`-Prop.
+- **Namespaces:** Subpfad-Aliasing stellt sicher, dass Ihr `useTranslation` auf die korrekten internen Wörterbuch-Namespaces verweist, ohne manuelle Änderungen.