@intlayer/docs 8.12.5-canary.0 → 9.0.0-canary.10

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/doc-review.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2024-08-11
-updatedAt: 2025-11-22
+updatedAt: 2026-06-17
 title: Dokument überprüfen
 description: Erfahren Sie, wie Sie Dokumentationsdateien auf Qualität, Konsistenz und Vollständigkeit in verschiedenen Sprachversionen überprüfen.
 keywords:
@@ -15,6 +15,10 @@ slugs:
   - concept
   - cli
   - doc-review
+history:
+  - version: 9.0.0
+    date: 2026-06-17
+    changes: "Option --log hinzufügen"
 author: aymericzip
 ---
 
@@ -55,8 +59,110 @@ Für die meisten Anwendungsfälle,
 
 ## Argumente:
 
-Der Befehl `doc review` akzeptiert dieselben Argumente wie `doc translate`, sodass Sie bestimmte Dokumentationsdateien überprüfen und Qualitätsprüfungen anwenden können.
+**Optionen für die Dateiliste:**
 
-Wenn Sie eine der Git-Optionen aktiviert haben, überprüft der Befehl nur die Teile der Dateien, die geändert werden. Das Skript verarbeitet die Datei in Abschnitten (Chunks) und überprüft jeden Abschnitt. Wenn in einem Abschnitt keine Änderungen vorhanden sind, überspringt das Skript diesen, um den Überprüfungsprozess zu beschleunigen und die Kosten für die AI-Provider-API zu begrenzen.
+- **`--doc-pattern [docPattern...]`**: Glob-Muster, um Dokumentationsdateien zur Überprüfung auszuwählen.
 
-Für eine vollständige Liste der Argumente siehe die [Dokumentation zum Befehl „Translate Document“](https://github.com/aymericzip/intlayer/blob/main/docs/docs/de/cli/doc-translate.md).
+  > Beispiel: `npx intlayer doc review --doc-pattern "docs/**/*.md" "src/**/*.mdx"`
+
+- **`--excluded-glob-pattern [excludedGlobPattern...]`**: Glob-Muster, die von der Überprüfung ausgeschlossen werden sollen.
+
+  > Beispiel: `npx intlayer doc review --excluded-glob-pattern "docs/internal/**"`
+
+- **`--skip-if-modified-before [skipIfModifiedBefore]`**: Überspringe die Datei, wenn sie vor dem angegebenen Zeitpunkt geändert wurde.
+  - Kann eine absolute Zeit wie "2025-12-05" sein (String oder Date)
+  - Kann eine relative Zeit in ms sein `1 * 60 * 60 * 1000` (1 Stunde)
+  - Diese Option prüft die Aktualisierungszeit der Datei mit der Methode `fs.stat`. Daher kann sie durch Git oder andere Tools, die die Datei ändern, beeinflusst werden.
+
+  > Beispiel: `npx intlayer doc review --skip-if-modified-before "2025-12-05"`
+
+- **`--skip-if-modified-after [skipIfModifiedAfter]`**: Überspringe die Datei, wenn sie innerhalb des angegebenen Zeitraums geändert wurde.
+  - Kann eine absolute Zeit wie "2025-12-05" sein (String oder Date)
+  - Kann eine relative Zeit in ms sein `1 * 60 * 60 * 1000` (1 Stunde)
+  - Diese Option prüft die Aktualisierungszeit der Datei mit der Methode `fs.stat`. Daher kann sie durch Git oder andere Tools, die die Datei ändern, beeinflusst werden.
+
+  > Beispiel: `npx intlayer doc review --skip-if-modified-after "2025-12-05"`
+
+- **`--skip-if-exists`**: Überspringe die Datei, wenn sie bereits existiert.
+
+  > Beispiel: `npx intlayer doc review --skip-if-exists`
+
+**Überprüfungsmodus-Optionen:**
+
+- **`--log`**: Nur-Protokollierungsmodus. Nicht mit KI übersetzen; stattdessen die Blöcke, die Aufmerksamkeit erfordern (mit Zeilennummern und Inhalt), für die Basis- und Ziel-Locales protokollieren, um einem anderen Agenten bei der Generierung der Übersetzungen zu helfen.
+
+  > Beispiel: `npx intlayer doc review --log`
+
+**Optionen für die Ausgabe der Einträge:**
+
+- **`--locales [locales...]`**: Ziel-Lokalisierungen, für die die Dokumentation überprüft werden soll.
+
+  > Beispiel: `npx intlayer doc review --locales fr es de`
+
+- **`--base-locale [baseLocale]`**: Quell-Lokalisierung (Basisdokument), mit der verglichen werden soll.
+
+  > Beispiel: `npx intlayer doc review --base-locale en`
+
+**Optionen zur Dateiverarbeitung:**
+
+- **`--nb-simultaneous-file-processed [nbSimultaneousFileProcessed]`**: Anzahl der Dateien, die gleichzeitig für die Überprüfung verarbeitet werden.
+
+  > Beispiel: `npx intlayer doc review --nb-simultaneous-file-processed 5`
+
+**KI-Optionen:**
+
+- **`--model [model]`**: Das für die Überprüfung zu verwendende KI-Modell (z. B. `gpt-3.5-turbo`).
+- **`--provider [provider]`**: Der für die Überprüfung zu verwendende KI-Anbieter.
+- **`--temperature [temperature]`**: Temperatureinstellung für das KI-Modell.
+- **`--api-key [apiKey]`**: Eigener API-Schlüssel für den KI-Dienst.
+- **`--application-context [applicationContext]`**: Zusätzlicher Kontext für die KI-Überprüfung.
+- **`--data-serialization [dataSerialization]`**: Das Datenserialisierungsformat für die KI-Funktionen von Intlayer. Optionen: `json` (Standard, zuverlässig), `toon` (weniger Token, weniger konsistent).
+- **`--custom-prompt [prompt]`**: Passen Sie den Basis-Prompt an, der für die Überprüfung verwendet wird. (Hinweis: Für die meisten Anwendungsfälle wird stattdessen die Option `--custom-instructions` empfohlen, da sie eine bessere Kontrolle bietet.)
+
+  > Beispiel: `npx intlayer doc review --model deepseek-chat --provider deepseek --temperature 0.5 --api-key sk-1234567890 --application-context "Meine Anwendung ist ein Katzenladen"`
+
+**Optionen für Umgebungsvariablen:**
+
+- **`--env`**: Geben Sie die Umgebung an (z. B. `development`, `production`).
+- **`--env-file [envFile]`**: Geben Sie eine benutzerdefinierte Umgebungsdatei an, aus der Variablen geladen werden.
+- **`--base-dir`**: Geben Sie das Basisverzeichnis für das Projekt an.
+- **`--no-cache`**: Deaktivieren Sie den Cache.
+
+  > Beispiel: `npx intlayer doc review --base-dir ./docs --env-file .env.production.local`
+
+**Protokollierungsoptionen:**
+
+- **`--verbose`**: Aktiviert ausführliche Protokollierung zur Fehlerbehebung. (Standardmäßig über CLI auf true gesetzt)
+
+  > Beispiel: `npx intlayer doc review --verbose`
+
+**Optionen für benutzerdefinierte Anweisungen:**
+
+- **`--custom-instructions [customInstructions]`**: Benutzerdefinierte Anweisungen, die dem Prompt hinzugefügt werden. Nützlich, um spezifische Regeln bezüglich Formatierung, URL-Übersetzung usw. anzuwenden.
+
+  > Beispiel: `npx intlayer doc review --custom-instructions "URLs nicht übersetzen und das Markdown-Format beibehalten"`
+
+  > Beispiel: `npx intlayer doc review --custom-instructions "$(cat ./instructions.md)"`
+
+**Git-Optionen:**
+
+- **`--git-diff`**: Nur auf Dateien anwenden, die Änderungen vom Basis-Branch (Standard `origin/main`) zum aktuellen Branch (Standard: `HEAD`) enthalten.
+- **`--git-diff-base`**: Basis-Referenz für den Git-Diff angeben (Standard `origin/main`).
+- **`--git-diff-current`**: Aktuelle Referenz für den Git-Diff angeben (Standard: `HEAD`).
+- **`--uncommitted`**: Uncommittete Änderungen einbeziehen.
+- **`--unpushed`**: Nicht gepushte Änderungen einbeziehen.
+- **`--untracked`**: Nicht verfolgte Dateien einbeziehen.
+
+  > Beispiel: `npx intlayer doc review --git-diff --git-diff-base origin/main --git-diff-current HEAD`
+
+  > Beispiel: `npx intlayer doc review --uncommitted --unpushed --untracked`
+
+> Beachten Sie, dass der Ausgabepfad der Datei durch Ersetzen der folgenden Muster bestimmt wird:
+>
+> - `/{{baseLocale}}/` durch `/{{locale}}/` (Unix)
+> - `\{{baseLocale}}\` durch `\{{locale}}\` (Windows)
+> - `_{{baseLocale}}.` durch `_{{locale}}.`
+> - `{{baseLocale}}_` durch `{{locale}}_`
+> - `.{{baseLocaleName}}.` durch `.{{localeName}}.`
+>
+> Wenn das Muster nicht gefunden wird, wird die Ausgabedatei die Endung `.{{locale}}` erhalten. `./my/file.md` wird überprüft und für die französische Locale zu `./my/file.fr.md` aktualisiert.

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/index.md

@@ -17,7 +17,7 @@ slugs:
   - concept
   - cli
 history:
-  - version: 8.13.0
+  - version: 9.0.0
     date: 2026-06-11
     changes: "Befehl scan hinzugefügt"
   - version: 8.6.4

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/cli/scan.md

@@ -18,7 +18,7 @@ slugs:
   - cli
   - scan
 history:
-  - version: 8.13.0
+  - version: 9.0.0
     date: 2026-06-11
     changes: "Befehl scan hinzugefügt"
 author: aymericzip

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.