@intlayer/docs 8.9.4 → 8.9.6-canary.0

package/docs/de/benchmark/solid.md

@@ -0,0 +1,155 @@
+---
+createdAt: 2026-04-20
+updatedAt: 2026-04-21
+title: Beste i18n-Lösung für Solid im Jahr 2026 – Benchmark-Bericht
+description: Vergleichen Sie Solid-Internationalisierungsbibliotheken (i18n) wie solid-primitives, solid-i18next und Intlayer. Detaillierter Leistungsbericht zu Bundle-Größe, Leakage und Reaktivität.
+keywords:
+  - benchmark
+  - i18n
+  - intl
+  - solid
+  - leistung
+  - intlayer
+slugs:
+  - doc
+  - benchmark
+  - solid
+author: Aymeric PINEAU
+applicationTemplate: https://github.com/intlayer-org/benchmark-i18n-solid-template
+history:
+  - version: 8.7.12
+    date: 2026-01-06
+    changes: "Benchmark-Initialisierung"
+---
+
+# Solid i18n-Bibliotheken — Benchmark-Bericht 2026
+
+Diese Seite ist ein Benchmark-Bericht für i18n-Lösungen in Solid.
+
+## Inhaltsverzeichnis
+
+<Toc/>
+
+## Interaktiver Benchmark
+
+<I18nBenchmark framework="vite-solid" vertical/>
+
+## Ergebnisreferenz:
+
+<iframe 
+  src="https://intlayer.org/markdown?url=https%3A%2F%2Fraw.githubusercontent.com%2Fintlayer-org%2Fbenchmark-i18n%2Fmain%2Freport%2Fscripts%2Fsummarize-vite_solid.md" 
+  width="100%" 
+  height="600px"
+  style="border:none;">
+</iframe>
+
+> https://intlayer.org/markdown?url=https%3A%2F%2Fraw.githubusercontent.com%2Fintlayer-org%2Fbenchmark-i18n%2Fmain%2Freport%2Fscripts%2Fsummarize-vite_solid.md
+
+Das vollständige Benchmark-Repository finden Sie [hier](https://github.com/intlayer-org/benchmark-i18n/tree/main).
+
+## Einleitung
+
+Internationalisierungslösungen gehören zu den schwersten Abhängigkeiten in einer Solid-App. Das Hauptrisiko besteht darin, unnötige Inhalte zu versenden: Übersetzungen für andere Seiten und andere Sprachen im Bundle einer einzigen Route.
+
+Wenn Ihre App wächst, kann dieses Problem die an den Client gesendeten JavaScript-Mengen schnell explodieren lassen und die Navigation verlangsamen.
+
+In der Praxis kann eine internationalisierte Seite bei am wenigsten optimierten Implementierungen am Ende mehrmals schwerer sein als die Version ohne i18n.
+
+Die andere Auswirkung betrifft die Entwicklererfahrung (DX): Wie Sie Inhalte deklarieren, Typen, Namespace-Organisation, dynamisches Laden und Reaktivität bei Sprachwechseln.
+
+## TL;DR
+
+- **Intlayer**: Empfohlene Wahl für professionelle Solid-Anwendungen, die erweiterte Funktionen und Optimierung benötigen (v8.7.12).
+- **@solid-primitives/i18n**: Exzellente leichtgewichtige Alternative für einfache Projekte, obwohl es an erweiterten Funktionen wie Lazy-Loading mangelt.
+- **solid-i18next**: Standardmäßige, aber schwere Option (~4,7x Intlayer) mit den gleichen Nachteilen wie React i18next.
+- **Paraglide**: Innovativer Ansatz, aber komplexe DX und Tree-Shaking-Probleme in einigen Setups.
+
+## Testen Sie Ihre App
+
+Um i18n-Leakage-Probleme schnell zu erkennen, habe ich einen kostenlosen Scanner eingerichtet, der [hier](https://intlayer.org/i18n-seo-scanner) verfügbar ist.
+
+<iframe src="https://intlayer.org/i18n-seo-scanner" width="100%" height="600px" style="border:none;"/>
+
+## Das Problem
+
+Zwei Hebel sind wesentlich, um die Kosten einer mehrsprachigen App zu begrenzen:
+
+- Inhalte nach Seite / Namespace aufteilen, damit Sie keine ganzen Wörterbücher laden, wenn Sie sie nicht benötigen.
+- Das richtige Gebietsschema (Locale) dynamisch laden, nur wenn es benötigt wird.
+
+Verständnis der technischen Einschränkungen dieser Ansätze:
+
+**Dynamisches Laden**
+
+Ohne dynamisches Laden halten die meisten Lösungen Nachrichten ab dem ersten Rendern im Speicher, was für Apps mit vielen Routen und Locales einen erheblichen Overhead bedeutet.
+
+Mit dynamischem Laden akzeptieren Sie einen Kompromiss: weniger initiales JS, aber manchmal eine zusätzliche Anfrage beim Sprachwechsel.
+
+**Inhaltsaufteilung (Splitting)**
+
+Syntaxen, die um `t('a.b.c')` herum aufgebaut sind, sind sehr bequem, fördern aber oft das Beibehalten großer JSON-Objekte zur Laufzeit. Dieses Modell erschwert Tree-Shaking, es sei denn, die Bibliothek bietet eine echte Aufteilungsstrategie pro Seite.
+
+## Methodik
+
+Für diesen Benchmark haben wir die folgenden Bibliotheken verglichen:
+
+- `Base App` (Keine i18n-Bibliothek)
+- `solid-intlayer` (v8.7.12)
+- `@solid-primitives/i18n` (v2.2.1)
+- `solid-i18next` (v17.0.2)
+- `@inlang/paraglide-js` (v2.17.0)
+
+Das Framework ist `Solid` mit einer mehrsprachigen App aus **10 Seiten** und **10 Sprachen**.
+
+Wir haben **vier Ladestrategien** verglichen:
+
+| Strategie             | Ohne Namespaces (global)                   | Mit Namespaces (scoped)                                               |
+| :-------------------- | :----------------------------------------- | :-------------------------------------------------------------------- |
+| **Statisches Laden**  | **Static**: Alles beim Start im Speicher.  | **Scoped static**: Nach Namespace getrennt; alles beim Start geladen. |
+| **Dynamisches Laden** | **Dynamic**: Laden nach Bedarf pro Locale. | **Scoped dynamic**: Granulares Laden pro Namespace und Locale.        |
+
+## Zusammenfassung der Strategien
+
+- **Static**: Einfach; keine Netzwerklatenz nach dem ersten Laden. Nachteil: große Bundle-Größe.
+- **Dynamic**: Reduziert das Anfangsgewicht (Lazy-Loading). Ideal, wenn Sie viele Locales haben.
+- **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.
+
+## Ergebnisse im Detail
+
+### 1 — Zu vermeidende Lösungen
+
+> Im Solid-Ökosystem gibt es keine eindeutig zu vermeidenden Lösungen.
+
+### 2 — Akzeptable Lösungen
+
+**(solid-i18next)** (`solid-i18next@17.0.2`):
+
+`solid-i18next` ist wahrscheinlich die beliebteste Option, da sie eine der ersten war, die die i18n-Anforderungen von JavaScript-Apps erfüllte. Sie verfügt außerdem über ein breites Set an Community-Plugins für spezifische Probleme.
+
+Das Paket ist schwer (~14,6 KB, was etwa das 4,7-fache von `solid-intlayer` ist).
+
+Trotzdem teilt es die gleichen großen Nachteile wie Stacks, die auf `t('a.b.c')` aufbauen: Optimierungen sind möglich, aber sehr zeitaufwendig, und große Projekte riskieren schlechte Praktiken (Namespaces + dynamisches Laden + Typen).
+
+**(@solid-primitives/i18n)** (`@solid-primitives/i18n@2.2.1`):
+
+Solid Primitive ist extrem leicht und effizient. Ich empfehle diese Lösung für leichte Projekte, aber es kann schnell an Funktionen für professionelle Lösungen fehlen, einschließlich Cookie-Management, Proxy-Redirection, Formatierer usw.
+Es fehlen auch Lazy-Loading und Scoping-Namespaces für die Optimierung der Seitengröße.
+
+**(Paraglide)** (`@inlang/paraglide-js@2.17.0`):
+
+`Paraglide` bietet einen innovativen, gut durchdachten Ansatz. Dennoch funktionierte in diesem Benchmark das von der Firma beworbene Tree-Shaking für meine Implementierung nicht. Der Workflow und die DX sind ebenfalls komplexer als bei anderen Optionen.
+Persönlich gefällt mir nicht, dass JS-Dateien vor jedem Push neu generiert werden müssen, was ein ständiges Risiko für Merge-Konflikte bei PRs darstellt.
+Schließlich verwendet Paraglide im Vergleich zu anderen Lösungen keinen Store (z. B. Solid Signal), um das aktuelle Gebietsschema zum Rendern des Inhalts abzurufen. Für jeden geparsten Knoten wird das Gebietsschema aus dem localStorage / Cookie usw. angefordert. Dies führt zur Ausführung unnötiger Logik, die sich auf die Reaktivität der Komponenten auswirkt.
+
+### 3 — Empfehlungen
+
+**(Intlayer)** (`solid-intlayer@8.7.12`):
+
+Ich werde `solid-intlayer` aus Gründen der Objektivität nicht persönlich beurteilen, da es meine eigene Lösung ist.
+
+### Persönliche Anmerkung
+
+Diese Anmerkung ist persönlich und beeinflusst die Benchmark-Ergebnisse nicht. Dennoch sieht man in der i18n-Welt oft einen Konsens um ein Muster wie `const t = useTranslation('xx')` + `<>{t('xx.xx')}</>` für übersetzte Inhalte.
+
+In Solid-Apps ist das Injizieren einer Funktion als `JSX.Element` meiner Meinung nach ein Anti-Pattern. Es fügt außerdem vermeidbare Komplexität und JavaScript-Ausführungs-Overhead hinzu (auch wenn dieser kaum merklich ist).

package/docs/de/benchmark/svelte.md

@@ -0,0 +1,148 @@
+---
+createdAt: 2026-04-20
+updatedAt: 2026-04-21
+title: Beste i18n-Lösung für Svelte im Jahr 2026 – Benchmark-Bericht
+description: Vergleichen Sie Svelte-Internationalisierungsbibliotheken (i18n) wie svelte-i18n, Paraglide und Intlayer. Detaillierter Leistungsbericht zu Bundle-Größe, Leakage und Reaktivität.
+keywords:
+  - benchmark
+  - i18n
+  - intl
+  - svelte
+  - leistung
+  - intlayer
+slugs:
+  - doc
+  - benchmark
+  - svelte
+author: Aymeric PINEAU
+applicationTemplate: https://github.com/intlayer-org/benchmark-i18n-svelte-template
+history:
+  - version: 8.7.12
+    date: 2026-01-06
+    changes: "Benchmark-Initialisierung"
+---
+
+# Svelte i18n-Bibliotheken — Benchmark-Bericht 2026
+
+Diese Seite ist ein Benchmark-Bericht für i18n-Lösungen in Svelte.
+
+## Inhaltsverzeichnis
+
+<Toc/>
+
+## Interaktiver Benchmark
+
+<I18nBenchmark framework="vite-svelte" vertical/>
+
+## Ergebnisreferenz:
+
+<iframe 
+  src="https://intlayer.org/markdown?url=https%3A%2F%2Fraw.githubusercontent.com%2Fintlayer-org%2Fbenchmark-i18n%2Fmain%2Freport%2Fscripts%2Fsummarize-vite_svelte.md" 
+  width="100%" 
+  height="600px"
+  style="border:none;">
+</iframe>
+
+> https://intlayer.org/markdown?url=https%3A%2F%2Fraw.githubusercontent.com%2Fintlayer-org%2Fbenchmark-i18n%2Fmain%2Freport%2Fscripts%2Fsummarize-vite_svelte.md
+
+Das vollständige Benchmark-Repository finden Sie [hier](https://github.com/intlayer-org/benchmark-i18n/tree/main).
+
+## Einleitung
+
+Internationalisierungslösungen gehören zu den schwersten Abhängigkeiten in einer Svelte-App. Das Hauptrisiko besteht darin, unnötige Inhalte zu versenden: Übersetzungen für andere Seiten und andere Sprachen im Bundle einer einzigen Route.
+
+Wenn Ihre App wächst, kann dieses Problem die an den Client gesendeten JavaScript-Mengen schnell explodieren lassen und die Navigation verlangsamen.
+
+In der Praxis kann eine internationalisierte Seite bei am wenigsten optimierten Implementierungen am Ende mehrmals schwerer sein als die Version ohne i18n.
+
+Die andere Auswirkung betrifft die Entwicklererfahrung (DX): Wie Sie Inhalte deklarieren, Typen, Namespace-Organisation, dynamisches Laden und Reaktivität bei Sprachwechseln.
+
+## TL;DR
+
+- **Intlayer**: Die leistungseffizienteste Wahl (v8.7.12) mit dem kleinsten Fußabdruck.
+- **Paraglide**: Starker Kandidat für Tree-Shaking, hat aber eine komplexere Entwicklererfahrung und Overhead bei der Reaktivität.
+- **svelte-i18n**: Umfassend und Standard für Svelte, bringt aber ein viel größeres Bundle-Gewicht mit sich (~7x Intlayer).
+
+## Testen Sie Ihre App
+
+Um i18n-Leakage-Probleme schnell zu erkennen, habe ich einen kostenlosen Scanner eingerichtet, der [hier](https://intlayer.org/i18n-seo-scanner) verfügbar ist.
+
+<iframe src="https://intlayer.org/i18n-seo-scanner" width="100%" height="600px" style="border:none;"/>
+
+## Das Problem
+
+Zwei Hebel sind wesentlich, um die Kosten einer mehrsprachigen App zu begrenzen:
+
+- Inhalte nach Seite / Namespace aufteilen, damit Sie keine ganzen Wörterbücher laden, wenn Sie sie nicht benötigen.
+- Das richtige Gebietsschema (Locale) dynamisch laden, nur wenn es benötigt wird.
+
+Verständnis der technischen Einschränkungen dieser Ansätze:
+
+**Dynamisches Laden**
+
+Ohne dynamisches Laden halten die meisten Lösungen Nachrichten ab dem ersten Rendern im Speicher, was für Apps mit vielen Routen und Locales einen erheblichen Overhead bedeutet.
+
+Mit dynamischem Laden akzeptieren Sie einen Kompromiss: weniger initiales JS, aber manchmal eine zusätzliche Anfrage beim Sprachwechsel.
+
+**Inhaltsaufteilung (Splitting)**
+
+Syntaxen, die um `t('a.b.c')` herum aufgebaut sind, sind sehr bequem, fördern aber oft das Beibehalten großer JSON-Objekte zur Laufzeit. Dieses Modell erschwert Tree-Shaking, es sei denn, die Bibliothek bietet eine echte Aufteilungsstrategie pro Seite.
+
+## Methodik
+
+Für diesen Benchmark haben wir die folgenden Bibliotheken verglichen:
+
+- `Base App` (Keine i18n-Bibliothek)
+- `svelte-intlayer` (v8.7.12)
+- `svelte-i18n` (v4.0.1)
+- `@inlang/paraglide-js` (v2.17.0)
+
+Das Framework ist `Svelte` mit einer mehrsprachigen App aus **10 Seiten** und **10 Sprachen**.
+
+Wir haben **vier Ladestrategien** verglichen:
+
+| Strategie             | Ohne Namespaces (global)                   | Mit Namespaces (scoped)                                               |
+| :-------------------- | :----------------------------------------- | :-------------------------------------------------------------------- |
+| **Statisches Laden**  | **Static**: Alles beim Start im Speicher.  | **Scoped static**: Nach Namespace getrennt; alles beim Start geladen. |
+| **Dynamisches Laden** | **Dynamic**: Laden nach Bedarf pro Locale. | **Scoped dynamic**: Granulares Laden pro Namespace und Locale.        |
+
+## Zusammenfassung der Strategien
+
+- **Static**: Einfach; keine Netzwerklatenz nach dem ersten Laden. Nachteil: große Bundle-Größe.
+- **Dynamic**: Reduziert das Anfangsgewicht (Lazy-Loading). Ideal, wenn Sie viele Locales haben.
+- **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.
+
+## Ergebnisse im Detail
+
+### 1 — Zu vermeidende Lösungen
+
+> Im Svelte-Ökosystem gibt es keine eindeutig zu vermeidenden Lösungen.
+
+### 2 — Akzeptable Lösungen
+
+**(Paraglide)** (`@inlang/paraglide-js@2.17.0`):
+
+`Paraglide` bietet einen innovativen, gut durchdachten Ansatz. Im Kontext einer Vite + Svelte App funktioniert das von der Firma beworbene Tree-Shaking wie erwartet, was großartig ist.
+Aber im Fall von React + TanStack Start funktionierte das Tree-Shaking nicht wie erwartet, ebenso wenig bei Next.js. Dennoch wäre die Verwendung von Paraglide in einem Svelte- und TanStack Start-Projekt eine genauere Überprüfung wert.
+Der Workflow und die DX sind ebenfalls komplexer als bei anderen Optionen.
+Persönlich gefällt mir nicht, dass JS-Dateien vor jedem Push neu generiert werden müssen, was ein ständiges Risiko für Merge-Konflikte bei PRs darstellt. Das Tool scheint auch mehr auf Vite als auf Next.js ausgerichtet zu sein.
+Schließlich verwendet Paraglide im Vergleich zu anderen Lösungen keinen Store (z. B. Svelte Store), um das aktuelle Gebietsschema zum Rendern des Inhalts abzurufen. Für jeden geparsten Knoten wird das Gebietsschema aus dem localStorage / Cookie usw. angefordert. Dies führt zur Ausführung unnötiger Logik, die sich auf die Reaktivität der Komponenten auswirkt.
+
+> Hinweis zu Paraglide: Die Lösung injiziert Code in Ihre Codebasis für Importe; daher ist die Metrik „lib size“ im Benchmark-Bericht fast 0. Codegenerierung ist eine gute Sache, da die verwendete Funktion nur die notwendige Logik enthält (Präfix überall vs. kein Präfix, Cookie vs. Speicher usw.). Im Vergleich dazu führt Intlayer diese Filterung über Injektionen von Umgebungsvariablen während des Builds durch, um den Bundler zu zwingen, den Inhalt je nach Logik zu tree-shaken. Dank dessen sind Paraglide und Intlayer am Ende 6- bis 10-mal leichtere Lösungen als i18next oder next-intl.
+
+**(svelte-i18n)** (`svelte-i18n@3.4.0`):
+
+Diese Lösung erfüllt alle i18n-Anforderungen in einem Svelte-Projekt. Aber wie bei i18next oder anderen großen i18n-Lösungen ist sie etwas schwer (~15,9 KB, was etwa das 7-fache von `svelte-intlayer` ist).
+
+### 3 — Empfehlungen
+
+**(Intlayer)** (`svelte-intlayer@8.7.12`):
+
+Ich werde `svelte-intlayer` aus Gründen der Objektivität nicht persönlich beurteilen, da es meine eigene Lösung ist.
+
+### Persönliche Anmerkung
+
+Diese Anmerkung ist persönlich und beeinflusst die Benchmark-Ergebnisse nicht. Dennoch sieht man in der i18n-Welt oft einen Konsens um ein Muster wie `const t = useTranslation('xx')` + `<>{t('xx.xx')}</>` für übersetzte Inhalte.
+
+In Svelte-Apps ist das Injizieren einer Funktion als `Slot` meiner Meinung nach ein Anti-Pattern. Es fügt außerdem vermeidbare Komplexität und JavaScript-Ausführungs-Overhead hinzu (auch wenn dieser kaum merklich ist).

package/docs/de/benchmark/tanstack.md

@@ -57,6 +57,13 @@ In der Praxis kann eine internationalisierte Seite bei den am wenigsten optimier
 
 Ein weiterer Aspekt ist die Developer Experience (DX): Wie deklarieren Sie Inhalte, Typen, Namespace-Organisation, dynamisches Laden und Reaktivität bei Sprachwechseln.
 
+## TL;DR
+
+- **Intlayer**: Bietet die beste Performance und die kleinste Bundle-Größe (v8.7.12) für TanStack Start.
+- **react-i18next** & **use-intl**: Ausgereifte Alternativen mit großen Ökosystemen, aber deutlich schwerer und komplexer zu optimieren.
+- **Paraglide**: Innovative Tree-shaking-Idee, die in der Praxis nicht funktioniert. Komplexe DX und Reaktivitäts-Overhead in TanStack Start.
+- **Vermeiden**: **General Translation (GT)** und **Lingo.dev** aufgrund schwerwiegender Performance-Probleme, AI-Quota-Limits und Vendor-Lock-in.
+
 ## Testen Sie Ihre App
 
 Um i18n-Leakage-Probleme schnell zu erkennen, habe ich einen kostenlosen Scanner eingerichtet, den Sie [hier](https://intlayer.org/i18n-seo-scanner) finden.
@@ -87,12 +94,12 @@ Syntaxansätze um `const t = useTranslation()` + `t('a.b.c')` sind sehr bequem,
 Für diesen Benchmark haben wir die folgenden Bibliotheken verglichen:
 
 - `Base App` (Ohne i18n-Bibliothek)
-- `react-intlayer` (v8.7.5-canary.0)
+- `react-intlayer` (v8.7.12)
 - `react-i18next` (v17.0.2)
 - `use-intl` (v4.9.1)
 - `@lingui/core` (v5.3.0)
 - `@inlang/paraglide-js` (v2.15.1)
-- `tolgee` (v7.0.0)
+- `@tolgee/react` (v7.0.0)
 - `react-intl` (v10.1.1)
 - `wuchale` (v0.22.11)
 - `gt-react` (vlatest)
@@ -150,7 +157,9 @@ Die Idee hinter `Wuchale` ist interessant, aber noch keine tragfähige Lösung.
 
 `Paraglide` bietet einen innovativen, gut durchdachten Ansatz. Dennoch funktionierte in diesem Benchmark das beworbene Tree-shaking weder für meine Next.js-Implementierung noch für TanStack Start. Der Workflow und die DX sind zudem komplexer als bei anderen Optionen. Persönlich bin ich kein Fan davon, JS-Dateien vor jedem Push neu generieren zu müssen, was ständige Risiken für Merge-Konflikte in PRs birgt.
 
-**(Tolgee)** (`tolgee@7.0.0`):
+> Hinweis zu paraglide: Diese Lösung injiziert Code für Importe in Ihre Codebasis, weshalb die Metrik 'lib size' im Benchmark-Bericht fast 0 beträgt. Code-Generierung ist gut, da die verwendete Funktion nur die notwendige Logik enthält (Präfix überall vs. kein Präfix, Cookie vs. Speicher usw.). Im Vergleich dazu führt Intlayer diese Filterung durch Injektion von Umgebungsvariablen im Build durch, um den Bundler zu zwingen, den Inhalt je nach Logik per Tree-shaking zu bereinigen. Dank dessen sind paraglide und intlayer am Ende 6 bis 10 Mal leichtere Lösungen als i18next oder next-intl.
+
+**(Tolgee)** (`@tolgee/react@7.0.0`):
 
 `Tolgee` adressiert viele der oben genannten Probleme. Ich fand den Einstieg schwieriger als bei anderen Tools mit ähnlichen Ansätzen. Es bietet keine Typsicherheit, was es zudem sehr schwer macht, fehlende Schlüssel zur Kompilierzeit zu finden. Ich musste die Tolgee-APIs mit eigenen Funktionen umhüllen, um eine Erkennung fehlender Schlüssel hinzuzufügen.
 

package/docs/de/benchmark/vue.md

@@ -0,0 +1,160 @@
+---
+createdAt: 2026-04-20
+updatedAt: 2026-04-21
+title: Beste i18n-Lösung für Vue im Jahr 2026 – Benchmark-Bericht
+description: Vergleichen Sie Vue-Internationalisierungsbibliotheken (i18n) wie vue-i18n, fluent-vue und Intlayer. Detaillierter Leistungsbericht zu Bundle-Größe, Leakage und Reaktivität.
+keywords:
+  - benchmark
+  - i18n
+  - intl
+  - vue
+  - leistung
+  - intlayer
+slugs:
+  - doc
+  - benchmark
+  - vue
+author: Aymeric PINEAU
+applicationTemplate: https://github.com/intlayer-org/benchmark-i18n-vue-template
+history:
+  - version: 8.7.12
+    date: 2026-01-06
+    changes: "Benchmark-Initialisierung"
+---
+
+# Vue i18n-Bibliotheken — Benchmark-Bericht 2026
+
+Diese Seite ist ein Benchmark-Bericht für i18n-Lösungen in Vue.
+
+## Inhaltsverzeichnis
+
+<Toc/>
+
+## Interaktiver Benchmark
+
+<I18nBenchmark framework="vite-vue" vertical/>
+
+## Ergebnisreferenz:
+
+<iframe 
+  src="https://intlayer.org/markdown?url=https%3A%2F%2Fraw.githubusercontent.com%2Fintlayer-org%2Fbenchmark-i18n%2Fmain%2Freport%2Fscripts%2Fsummarize-vite_vue.md" 
+  width="100%" 
+  height="600px"
+  style="border:none;">
+</iframe>
+
+> https://intlayer.org/markdown?url=https%3A%2F%2Fraw.githubusercontent.com%2Fintlayer-org%2Fbenchmark-i18n%2Fmain%2Freport%2Fscripts%2Fsummarize-vite_vue.md
+
+Das vollständige Benchmark-Repository finden Sie [hier](https://github.com/intlayer-org/benchmark-i18n/tree/main).
+
+## Einleitung
+
+Internationalisierungslösungen gehören zu den schwersten Abhängigkeiten in einer Vue-App. Das Hauptrisiko besteht darin, unnötige Inhalte zu versenden: Übersetzungen für andere Seiten und andere Sprachen im Bundle einer einzigen Route.
+
+Wenn Ihre App wächst, kann dieses Problem die an den Client gesendeten JavaScript-Mengen schnell explodieren lassen und die Navigation verlangsamen.
+
+In der Praxis kann eine internationalisierte Seite bei am wenigsten optimierten Implementierungen am Ende mehrmals schwerer sein als die Version ohne i18n.
+
+Die andere Auswirkung betrifft die Entwicklererfahrung (DX): Wie Sie Inhalte deklarieren, Typen, Namespace-Organisation, dynamisches Laden und Reaktivität bei Sprachwechseln.
+
+## TL;DR
+
+- **Intlayer**: Die leichteste Lösung (v8.7.12) mit nativem Scoping und dynamischem Laden.
+- **vue-i18n**: Der Industriestandard mit einem reichen Ökosystem, kann aber in großen Anwendungen deutlich schwerer und schwieriger für Code-Splitting zu optimieren sein.
+- **fluent-vue**: Innovative Nachrichtenorganisation, aber es mangelt an Typsicherheit und es erweist sich als extrem schwere Lösung.
+
+## Testen Sie Ihre App
+
+Um i18n-Leakage-Probleme schnell zu erkennen, habe ich einen kostenlosen Scanner eingerichtet, der [hier](https://intlayer.org/i18n-seo-scanner) verfügbar ist.
+
+<iframe src="https://intlayer.org/i18n-seo-scanner" width="100%" height="600px" style="border:none;"/>
+
+## Das Problem
+
+Zwei Hebel sind wesentlich, um die Kosten einer mehrsprachigen App zu begrenzen:
+
+- Inhalte nach Seite / Namespace aufteilen, damit Sie keine ganzen Wörterbücher laden, wenn Sie sie nicht benötigen.
+- Das richtige Gebietsschema (Locale) dynamisch laden, nur wenn es benötigt wird.
+
+Verständnis der technischen Einschränkungen dieser Ansätze:
+
+**Dynamisches Laden**
+
+Ohne dynamisches Laden halten die meisten Lösungen Nachrichten ab dem ersten Rendern im Speicher, was für Apps mit vielen Routen und Locales einen erheblichen Overhead bedeutet.
+
+Mit dynamischem Laden akzeptieren Sie einen Kompromiss: weniger initiales JS, aber manchmal eine zusätzliche Anfrage beim Sprachwechsel.
+
+**Inhaltsaufteilung (Splitting)**
+
+Syntaxen, die um `const { t } = useI18n()` + `t('a.b.c')` herum aufgebaut sind, sind sehr bequem, fördern aber oft das Beibehalten großer JSON-Objekte zur Laufzeit. Dieses Modell erschwert Tree-Shaking, es sei denn, die Bibliothek bietet eine echte Aufteilungsstrategie pro Seite.
+
+## Methodik
+
+Für diesen Benchmark haben wir die folgenden Bibliotheken verglichen:
+
+- `Base App` (Keine i18n-Bibliothek)
+- `vue-intlayer` (v8.7.12)
+- `vue-i18n` (v11.4.0)
+- `fluent-vue` (v3.8.2)
+
+Das Framework ist `Vue` mit einer mehrsprachigen App aus **10 Seiten** und **10 Sprachen**.
+
+Wir haben **vier Ladestrategien** verglichen:
+
+| Strategie             | Ohne Namespaces (global)                   | Mit Namespaces (scoped)                                               |
+| :-------------------- | :----------------------------------------- | :-------------------------------------------------------------------- |
+| **Statisches Laden**  | **Static**: Alles beim Start im Speicher.  | **Scoped static**: Nach Namespace getrennt; alles beim Start geladen. |
+| **Dynamisches Laden** | **Dynamic**: Laden nach Bedarf pro Locale. | **Scoped dynamic**: Granulares Laden pro Namespace und Locale.        |
+
+## Zusammenfassung der Strategien
+
+- **Static**: Einfach; keine Netzwerklatenz nach dem ersten Laden. Nachteil: große Bundle-Größe.
+- **Dynamic**: Reduziert das Anfangsgewicht (Lazy-Loading). Ideal, wenn Sie viele Locales haben.
+- **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 über die Leitung ging und wie lange die Dinge dauerten. Die Größen werden **nach normaler Webkomprimierung** angegeben, da dies näher an dem liegt, was die Leute tatsächlich herunterladen.
+
+- **Größe der Internationalisierungsbibliothek**: Nach dem Bundling, Tree-Shaking und der Minifizierung ist die Größe der i18n-Bibliothek die Größe des Codes für Provider + Composables in einer leeren Komponente. Das Laden von Übersetzungsdateien ist nicht enthalten. Dies zeigt, wie teuer die Bibliothek ist, bevor Ihre Inhalte ins Spiel kommen.
+
+- **JavaScript pro Seite**: Wie viel Skript der Browser für diesen Besuch bei jeder Benchmark-Route abruft, gemittelt über die Seiten im Test (und über die Locales). Schwere Seiten sind langsame Seiten.
+
+- **Leakage aus anderen Locales**: Dies betrifft den 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`).
+
+- **Leakage von anderen Routen**: Dieselbe Idee für **andere Bildschirme** in der App: ob deren Texte mitgeliefert werden, wenn Sie nur eine Seite geöffnet haben (z. B. Inhalt der Seite `/en/about` im Bundle der Seite `/en/contact`). Eine hohe Punktzahl deutet auf schwaches Splitting oder zu breite Bundles hin.
+
+- **Durchschnittliche Komponenten-Bundle-Größe**: Gängige UI-Elemente werden **einzeln** gemessen, anstatt sich in einer riesigen App-Zahl zu verstecken. Es zeigt, ob die Internationalisierung alltägliche Komponenten heimlich aufbläht. Wenn Ihre Komponente beispielsweise neu gerendert wird, lädt sie all diese Daten aus dem Speicher. Das Anhängen eines riesigen JSON an eine beliebige Komponente ist wie das Anschließen eines großen Speichers ungenutzter Daten, der die Leistung Ihrer Komponenten verlangsamt.
+
+- **Reaktionsfähigkeit bei Sprachwechseln**: Ich wechsle die Sprache über das eigene Steuerelement der App und messe die Zeit, bis die Seite eindeutig umgeschaltet hat – was ein Besucher bemerken würde.
+
+- **Rendering-Arbeit nach einem Sprachwechsel**: Ein detaillierterer Check: Wie viel Aufwand das Interface betrieben hat, um für die neue Sprache neu zu zeichnen, sobald der Wechsel läuft. Nützlich, wenn die „gefühlte“ Zeit und die Framework-Kosten auseinanderklaffen.
+
+- **Erste Seitenladezeit**: Von der Navigation bis zum Zeitpunkt, an dem der Browser die Seite für die von mir getesteten Szenarien als vollständig geladen betrachtet. Gut zum Vergleich von Kaltstarts.
+
+- **Hydrierungszeit (Hydration)**: Die Zeit, die der Client benötigt, um Server-HTML in ein interaktives Interface zu verwandeln. Ein Bindestrich in den Tabellen bedeutet, dass diese Implementierung in diesem Benchmark keine zuverlässigen Hydrierungsdaten geliefert hat.
+
+## Ergebnisse im Detail
+
+### 1 — Zu vermeidende Lösungen
+
+> Im Vue-Ökosystem gibt es keine eindeutig zu vermeidenden Lösungen.
+
+### 2 — Akzeptable Lösungen
+
+**(vue-i18n)** (`vue-i18n@11.4.0`):
+
+- **vue-i18n** ist unbestritten die am häufigsten verwendete i18n-Bibliothek für Vue, sie hat viele Funktionen und ein riesiges Ökosystem. Aber unter der Haube ist die Lösung ziemlich schwer. Selbst wenn vue-i18n Lazy-Loading für Nachrichten integriert, fehlt eine Scoping-Funktion. Bei einer klassischen Vue-SPA-App gibt es kein Problem, aber für eine Nuxt-App, die @nuxt/i18n verwendet, führt dies dazu, dass die Nachrichten aller Seiten in einer einzigen enthalten sind. Für eine große Nuxt-App mit mehr als 10 Seiten kann dies wirklich problematisch werden.
+
+Das Paket ist sehr schwer (~24,3 KB, was etwa das 9-fache von `vue-intlayer` ist).
+
+**(fluent-vue)** (`fluent-vue@0.5.0`):
+
+- **fluent-vue** bietet einen Innovationsversuch durch das .ftl-Format. Die Nachrichtenorganisation ist großartig und der Einstieg einfacher. In der Praxis erhöht jedoch der Mangel an Typsicherheit das Fehlerrisiko und das Debuggen kann schnell zeitaufwendig werden. Darüber hinaus lädt diese Lösung die Nachrichten über ein Vite-Plugin, das das Laden aller Inhalte in allen Sprachen in jede Seite erzwingt. Zusätzlich ist dies eine extrem schwere Lösung (~92,7 KB, was etwa das 34-fache von `vue-intlayer` ist).
+
+### 3 — Empfehlungen
+
+**(Intlayer)** (`vue-intlayer@8.7.12`):
+
+Ich werde `vue-intlayer` aus Gründen der Objektivität nicht persönlich beurteilen, da es meine eigene Lösung ist.

package/docs/de/configuration.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2024-08-13
-updatedAt: 2026-04-08
+updatedAt: 2026-05-12
 title: Konfiguration (Configuration)
 description: Erfahren Sie, wie Sie Intlayer für Ihre Anwendung konfigurieren. Verstehen Sie die verschiedenen Einstellungen und Optionen, um Intlayer an Ihre Bedürfnisse anzupassen.
 keywords:
@@ -14,6 +14,9 @@ slugs:
   - concept
   - configuration
 history:
+  - version: 8.9.4
+    date: 2026-05-12
+    changes: "Unterstützung für LM Studio-Anbieter hinzugefügt"
   - version: 8.7.0
     date: 2026-04-08
     changes: "Optionen `prune` und `minify` zur Build-Konfiguration hinzugefügt"
@@ -350,7 +353,7 @@ const config: IntlayerConfig = {
   ai: {
     /**
      * Zu verwendender KI-Anbieter.
-     * Optionen: 'openai', 'anthropic', 'mistral', 'deepseek', 'gemini', 'ollama', 'openrouter', 'alibaba', 'fireworks', 'groq', 'huggingface', 'bedrock', 'googlevertex', 'togetherai'
+     * Optionen: 'openai', 'anthropic', 'mistral', 'deepseek', 'gemini', 'ollama', 'openrouter', 'alibaba', 'fireworks', 'groq', 'huggingface', 'bedrock', 'googlevertex', 'togetherai', 'lmstudio'
      * Standard: 'openai'
      */
     provider: "openai",
@@ -919,16 +922,17 @@ Intlayer unterstützt mehrere KI-Anbieter für maximale Flexibilität. Derzeit u
 - **Groq**
 - **Amazon Bedrock**
 - **Together.ai**
-
-| Feld                 | Beschreibung                                                                                                                                     | Typ                                                                                                                                                                                                                                                                                                                                                                                            | Standard    | Beispiel                                                      | Hinweis                                                                                                                                                                                                           |
-| -------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------- | ------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| `provider`           | Der für Intlayer KI-Funktionen zu verwendende Anbieter.                                                                                          | `'openai'` &#124; <br/> `'anthropic'` &#124; <br/> `'mistral'` &#124; <br/> `'deepseek'` &#124; <br/> `'gemini'` &#124; <br/> `'ollama'` &#124; <br/> `'openrouter'` &#124; <br/> `'alibaba'` &#124; <br/> `'fireworks'` &#124; <br/> `'groq'` &#124; <br/> `'huggingface'` &#124; <br/> `'bedrock'` &#124; <br/> `'googleaistudio'` &#124; <br/> `'googlevertex'` &#124; <br/> `'togetherai'` | `undefined` | `'anthropic'`                                                 | Verschiedene Anbieter erfordern unterschiedliche API-Schlüssel und haben unterschiedliche Preismodelle.                                                                                                           |
-| `model`              | Das für die KI-Funktionen zu verwendende Modell.                                                                                                 | `string`                                                                                                                                                                                                                                                                                                                                                                                       | Keines      | `'gpt-4o-2024-11-20'`                                         | Das spezifische Modell variiert je nach Anbieter.                                                                                                                                                                 |
-| `temperature`        | Steuert den Zufallsfaktor der KI-Antworten.                                                                                                      | `number`                                                                                                                                                                                                                                                                                                                                                                                       | Keines      | `0.1`                                                         | Höhere Temperatur = kreativer und weniger vorhersehbar.                                                                                                                                                           |
-| `apiKey`             | Ihr API-Schlüssel für den ausgewählten Anbieter.                                                                                                 | `string`                                                                                                                                                                                                                                                                                                                                                                                       | Keines      | `process.env.OPENAI_API_KEY`                                  | Geheim halten; in Umgebungsvariablen speichern.                                                                                                                                                                   |
-| `applicationContext` | Zusätzlicher Kontext über Ihre Anwendung, um der KI zu helfen, genauere Übersetzungen zu generieren (Domain, Zielgruppe, Tonfall, Terminologie). | `string`                                                                                                                                                                                                                                                                                                                                                                                       | Keines      | `'Mein Anwendungskontext'`                                    | Kann verwendet werden, um Regeln hinzuzufügen (z. B.: `"URLs dürfen nicht verändert werden"`).                                                                                                                    |
-| `baseURL`            | Die Basis-URL für die KI-API.                                                                                                                    | `string`                                                                                                                                                                                                                                                                                                                                                                                       | Keines      | `'https://api.openai.com/v1'` <br/> `'http://localhost:5000'` | Kann auf einen lokalen oder benutzerdefinierten KI-API-Endpunkt zeigen.                                                                                                                                           |
-| `dataSerialization`  | Datenserialisierungsformat für die KI-Funktionen.                                                                                                | `'json'` &#124; <br/> `'toon'`                                                                                                                                                                                                                                                                                                                                                                 | `undefined` | `'toon'`                                                      | • `'json'`: Standard, zuverlässig; verbraucht mehr Tokens.<br/>• `'toon'`: Weniger Tokens, weniger konsistent.<br/>• Zusätzliche Parameter werden an das Modell als Kontext übergeben (Abstraktionsaufwand etc.). |
+- **LM Studio**
+
+| Feld                 | Beschreibung                                                                                                                                     | Typ                                                                                                                                                                                                                                                                                                                                                                                                                      | Standard    | Beispiel                                                      | Hinweis                                                                                                                                                                                                           |
+| -------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ----------- | ------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `provider`           | Der für Intlayer KI-Funktionen zu verwendende Anbieter.                                                                                          | `'openai'` &#124; <br/> `'anthropic'` &#124; <br/> `'mistral'` &#124; <br/> `'deepseek'` &#124; <br/> `'gemini'` &#124; <br/> `'ollama'` &#124; <br/> `'openrouter'` &#124; <br/> `'alibaba'` &#124; <br/> `'fireworks'` &#124; <br/> `'groq'` &#124; <br/> `'huggingface'` &#124; <br/> `'bedrock'` &#124; <br/> `'googleaistudio'` &#124; <br/> `'googlevertex'` &#124; <br/> `'togetherai'` &#124; <br/> `'lmstudio'` | `undefined` | `'anthropic'`                                                 | Verschiedene Anbieter erfordern unterschiedliche API-Schlüssel und haben unterschiedliche Preismodelle.                                                                                                           |
+| `model`              | Das für die KI-Funktionen zu verwendende Modell.                                                                                                 | `string`                                                                                                                                                                                                                                                                                                                                                                                                                 | Keines      | `'gpt-4o-2024-11-20'`                                         | Das spezifische Modell variiert je nach Anbieter.                                                                                                                                                                 |
+| `temperature`        | Steuert den Zufallsfaktor der KI-Antworten.                                                                                                      | `number`                                                                                                                                                                                                                                                                                                                                                                                                                 | Keines      | `0.1`                                                         | Höhere Temperatur = kreativer und weniger vorhersehbar.                                                                                                                                                           |
+| `apiKey`             | Ihr API-Schlüssel für den ausgewählten Anbieter.                                                                                                 | `string`                                                                                                                                                                                                                                                                                                                                                                                                                 | Keines      | `process.env.OPENAI_API_KEY`                                  | Geheim halten; in Umgebungsvariablen speichern.                                                                                                                                                                   |
+| `applicationContext` | Zusätzlicher Kontext über Ihre Anwendung, um der KI zu helfen, genauere Übersetzungen zu generieren (Domain, Zielgruppe, Tonfall, Terminologie). | `string`                                                                                                                                                                                                                                                                                                                                                                                                                 | Keines      | `'Mein Anwendungskontext'`                                    | Kann verwendet werden, um Regeln hinzuzufügen (z. B.: `"URLs dürfen nicht verändert werden"`).                                                                                                                    |
+| `baseURL`            | Die Basis-URL für die KI-API.                                                                                                                    | `string`                                                                                                                                                                                                                                                                                                                                                                                                                 | Keines      | `'https://api.openai.com/v1'` <br/> `'http://localhost:5000'` | Kann auf einen lokalen oder benutzerdefinierten KI-API-Endpunkt zeigen.                                                                                                                                           |
+| `dataSerialization`  | Datenserialisierungsformat für die KI-Funktionen.                                                                                                | `'json'` &#124; <br/> `'toon'`                                                                                                                                                                                                                                                                                                                                                                                           | `undefined` | `'toon'`                                                      | • `'json'`: Standard, zuverlässig; verbraucht mehr Tokens.<br/>• `'toon'`: Weniger Tokens, weniger konsistent.<br/>• Zusätzliche Parameter werden an das Modell als Kontext übergeben (Abstraktionsaufwand etc.). |
 
 ---