@intlayer/docs 8.9.4-canary.0 → 8.9.5

package/docs/fr/benchmark/solid.md

@@ -0,0 +1,155 @@
+---
+createdAt: 2026-04-20
+updatedAt: 2026-04-21
+title: La meilleure solution i18n pour Solid en 2026 - Rapport de Benchmark
+description: Comparez les bibliothèques d'internationalisation (i18n) pour Solid comme solid-primitives, solid-i18next et Intlayer. Rapport de performance détaillé sur la taille du bundle, les fuites et la réactivité.
+keywords:
+  - benchmark
+  - i18n
+  - intl
+  - solid
+  - performance
+  - 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: "Initialisation du benchmark"
+---
+
+# Bibliothèques i18n Solid — Rapport de Benchmark 2026
+
+Cette page est un rapport de benchmark pour les solutions i18n sur Solid.
+
+## Table des Matières
+
+<Toc/>
+
+## Benchmark Interactif
+
+<I18nBenchmark framework="vite-solid" vertical/>
+
+## Référence des résultats :
+
+<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
+
+Voir le dépôt complet du benchmark [ici](https://github.com/intlayer-org/benchmark-i18n/tree/main).
+
+## Introduction
+
+Les solutions d'internationalisation figurent parmi les dépendances les plus lourdes d'une application Solid. Le risque principal est d'embarquer du contenu inutile : les traductions d'autres pages et d'autres locales dans le bundle d'une seule route.
+
+À mesure que votre application grandit, ce problème peut rapidement faire exploser la quantité de JavaScript envoyée au client et ralentir la navigation.
+
+En pratique, pour les implémentations les moins optimisées, une page internationalisée peut finir par être plusieurs fois plus lourde que la version sans i18n.
+
+L'autre impact concerne l'expérience développeur (DX) : la façon dont vous déclarez le contenu, les types, l'organisation des namespaces, le chargement dynamique et la réactivité lors du changement de langue.
+
+## TL;DR
+
+- **Intlayer** : Choix recommandé pour les applications Solid professionnelles nécessitant des fonctionnalités avancées et une optimisation poussée (v8.7.12).
+- **@solid-primitives/i18n** : Excellente alternative légère pour les projets simples, bien qu'il manque de fonctionnalités avancées comme le lazy loading.
+- **solid-i18next** : Option standard mais lourde (~4.7× Intlayer) avec les mêmes inconvénients que React i18next.
+- **Paraglide** : Approche innovante mais DX complexe et problèmes de tree-shaking dans certaines configurations.
+
+## Testez votre application
+
+Pour repérer rapidement les problèmes de fuite i18n, j'ai mis en place un scanner gratuit disponible [ici](https://intlayer.org/i18n-seo-scanner).
+
+<iframe src="https://intlayer.org/i18n-seo-scanner" width="100%" height="600px" style="border:none;"/>
+
+## Le problème
+
+Deux leviers sont essentiels pour limiter le coût d'une application multilingue :
+
+- Découper le contenu par page / namespace afin de ne pas charger des dictionnaires entiers quand on n'en a pas besoin
+- Charger la bonne locale dynamiquement, uniquement quand nécessaire
+
+Comprendre les limitations techniques de ces approches :
+
+**Chargement dynamique**
+
+Sans chargement dynamique, la plupart des solutions gardent les messages en mémoire dès le premier rendu, ce qui ajoute un surcoût important pour les applications ayant beaucoup de routes et de langues.
+
+Avec le chargement dynamique, vous acceptez un compromis : moins de JS initial, mais parfois une requête supplémentaire lors du changement de langue.
+
+**Découpage du contenu (Splitting)**
+
+Les syntaxes basées sur `t('a.b.c')` sont très pratiques mais encouragent souvent la conservation de gros objets JSON au runtime. Ce modèle rend le tree-shaking difficile à moins que la bibliothèque ne propose une réelle stratégie de découpage par page.
+
+## Méthodologie
+
+Pour ce benchmark, nous avons comparé les bibliothèques suivantes :
+
+- `Base App` (Pas de bibliothèque i18n)
+- `solid-intlayer` (v8.7.12)
+- `@solid-primitives/i18n` (v2.2.1)
+- `solid-i18next` (v17.0.2)
+- `@inlang/paraglide-js` (v2.17.0)
+
+Le framework utilisé est `Solid` avec une application multilingue de **10 pages** et **10 langues**.
+
+Nous avons comparé **quatre stratégies de chargement** :
+
+| Stratégie                | Sans namespaces (global)                          | Avec namespaces (scoped)                                             |
+| :----------------------- | :------------------------------------------------ | :------------------------------------------------------------------- |
+| **Chargement statique**  | **Static** : Tout en mémoire au démarrage.        | **Scoped static** : Divisé par namespace ; tout chargé au démarrage. |
+| **Chargement dynamique** | **Dynamic** : Chargement à la demande par locale. | **Scoped dynamic** : Chargement granulaire par namespace et locale.  |
+
+## Résumé des stratégies
+
+- **Static** : Simple ; pas de latence réseau après le chargement initial. Inconvénient : taille de bundle importante.
+- **Dynamic** : Réduit le poids initial (lazy-loading). Idéal lorsque vous avez de nombreuses locales.
+- **Scoped static** : Organise bien le code (séparation logique) sans requêtes réseau supplémentaires complexes.
+- **Scoped dynamic** : Meilleure approche pour le _code splitting_ et la performance. Minimise la mémoire en ne chargeant que ce dont la vue actuelle et la locale active ont besoin.
+
+## Résultats détaillés
+
+### 1 — Solutions à éviter
+
+> Aucune solution claire à éviter dans l'écosystème Solid.
+
+### 2 — Solutions acceptables
+
+**(solid-i18next)** (`solid-i18next@17.0.2`) :
+
+`solid-i18next` est probablement l'option la plus populaire car elle fut l'une des premières à servir les besoins i18n des applications JS. Elle dispose également d'un large éventail de plugins communautaires pour des problèmes spécifiques.
+
+Le paquet est lourd (~14.6 Ko, soit environ 4.7× `solid-intlayer`).
+
+Pourtant, elle partage les mêmes inconvénients majeurs que les stacks basées sur `t('a.b.c')` : les optimisations sont possibles mais très gourmandes en temps, et les gros projets risquent de mauvaises pratiques (namespaces + chargement dynamique + types).
+
+**(@solid-primitives/i18n)** (`@solid-primitives/i18n@2.2.1`) :
+
+Solid primitive est extrêmement léger et efficace. Je recommande cette solution pour les petits projets, mais elle peut rapidement manquer de fonctionnalités pour des solutions professionnelles incluant la gestion des cookies, la redirection proxy, les formateurs, etc.
+Elle manque également de lazy loading et de découpage des namespaces pour l'optimisation de la taille des pages.
+
+**(Paraglide)** (`@inlang/paraglide-js@2.17.0`) :
+
+`Paraglide` propose une approche innovante et bien pensée. Pourtant, dans ce benchmark, le tree-shaking dont leur entreprise fait la publicité n'a pas fonctionné pour mon implémentation. Le workflow et la DX sont également plus complexes d'autres options.
+Personnellement, je n'aime pas devoir régénérer des fichiers JS avant chaque push, ce qui crée un risque constant de conflit de fusion via les PRs.
+Enfin, par rapport à d'autres solutions, Paraglide n'utilise pas de store (ex: Solid signal) pour récupérer la locale actuelle afin de rendre le contenu. Pour chaque nœud analysé, il demandera la locale au localStorage / cookie etc. Cela conduit à l'exécution d'une logique inutile qui impacte la réactivité des composants.
+
+### 3 — Recommandations
+
+**(Intlayer)** (`solid-intlayer@8.7.12`) :
+
+Je ne jugerai pas personnellement `solid-intlayer` par souci d'objectivité, puisqu'il s'agit de ma propre solution.
+
+### Note personnelle
+
+Cette note est personnelle et n'affecte pas les résultats du benchmark. Pourtant, dans le monde de l'i18n, on voit souvent un consensus autour d'un pattern comme `const t = useTranslation('xx')` + `<>{t('xx.xx')}</>` pour le contenu traduit.
+
+Dans les applications Solid, injecter une fonction en tant que `JSX.Element` est, à mon avis, un anti-pattern. Cela ajoute également une complexité évitable et un surcoût d'exécution JavaScript (même s'il est à peine perceptible).

package/docs/fr/benchmark/svelte.md

@@ -0,0 +1,148 @@
+---
+createdAt: 2026-04-20
+updatedAt: 2026-04-21
+title: La meilleure solution i18n pour Svelte en 2026 - Rapport de Benchmark
+description: Comparez les bibliothèques d'internationalisation (i18n) pour Svelte comme svelte-i18n, Paraglide et Intlayer. Rapport de performance détaillé sur la taille du bundle, les fuites et la réactivité.
+keywords:
+  - benchmark
+  - i18n
+  - intl
+  - svelte
+  - performance
+  - 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: "Initialisation du benchmark"
+---
+
+# Bibliothèques i18n Svelte — Rapport de Benchmark 2026
+
+Cette page est un rapport de benchmark pour les solutions i18n sur Svelte.
+
+## Table des Matières
+
+<Toc/>
+
+## Benchmark Interactif
+
+<I18nBenchmark framework="vite-svelte" vertical/>
+
+## Référence des résultats :
+
+<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
+
+Voir le dépôt complet du benchmark [ici](https://github.com/intlayer-org/benchmark-i18n/tree/main).
+
+## Introduction
+
+Les solutions d'internationalisation figurent parmi les dépendances les plus lourdes d'une application Svelte. Le risque principal est d'embarquer du contenu inutile : les traductions d'autres pages et d'autres locales dans le bundle d'une seule route.
+
+À mesure que votre application grandit, ce problème peut rapidement faire exploser la quantité de JavaScript envoyée au client et ralentir la navigation.
+
+En pratique, pour les implémentations les moins optimisées, une page internationalisée peut finir par être plusieurs fois plus lourde que la version sans i18n.
+
+L'autre impact concerne l'expérience développeur (DX) : la façon dont vous déclarez le contenu, les types, l'organisation des namespaces, le chargement dynamique et la réactivité lors du changement de langue.
+
+## TL;DR
+
+- **Intlayer** : Le choix le plus performant (v8.7.12) avec l'empreinte la plus faible.
+- **Paraglide** : Candidat sérieux pour le tree-shaking mais possède une expérience développeur plus complexe et un surcoût de réactivité.
+- **svelte-i18n** : Complet et standard pour Svelte, mais transporte un poids de bundle beaucoup plus important (~7× Intlayer).
+
+## Testez votre application
+
+Pour repérer rapidement les problèmes de fuite i18n, j'ai mis en place un scanner gratuit disponible [ici](https://intlayer.org/i18n-seo-scanner).
+
+<iframe src="https://intlayer.org/i18n-seo-scanner" width="100%" height="600px" style="border:none;"/>
+
+## Le problème
+
+Deux leviers sont essentiels pour limiter le coût d'une application multilingue :
+
+- Découper le contenu par page / namespace afin de ne pas charger des dictionnaires entiers quand on n'en a pas besoin
+- Charger la bonne locale dynamiquement, uniquement quand nécessaire
+
+Comprendre les limitations techniques de ces approches :
+
+**Chargement dynamique**
+
+Sans chargement dynamique, la plupart des solutions gardent les messages en mémoire dès le premier rendu, ce qui ajoute un surcoût important pour les applications ayant beaucoup de routes et de langues.
+
+Avec le chargement dynamique, vous acceptez un compromis : moins de JS initial, mais parfois une requête supplémentaire lors du changement de langue.
+
+**Découpage du contenu (Splitting)**
+
+Les syntaxes basées sur `t('a.b.c')` sont très pratiques mais encouragent souvent la conservation de gros objets JSON au runtime. Ce modèle rend le tree-shaking difficile à moins que la bibliothèque ne propose une réelle stratégie de découpage par page.
+
+## Méthodologie
+
+Pour ce benchmark, nous avons comparé les bibliothèques suivantes :
+
+- `Base App` (Pas de bibliothèque i18n)
+- `svelte-intlayer` (v8.7.12)
+- `svelte-i18n` (v4.0.1)
+- `@inlang/paraglide-js` (v2.17.0)
+
+Le framework utilisé est `Svelte` avec une application multilingue de **10 pages** et **10 langues**.
+
+Nous avons comparé **quatre stratégies de chargement** :
+
+| Stratégie                | Sans namespaces (global)                          | Avec namespaces (scoped)                                             |
+| :----------------------- | :------------------------------------------------ | :------------------------------------------------------------------- |
+| **Chargement statique**  | **Static** : Tout en mémoire au démarrage.        | **Scoped static** : Divisé par namespace ; tout chargé au démarrage. |
+| **Chargement dynamique** | **Dynamic** : Chargement à la demande par locale. | **Scoped dynamic** : Chargement granulaire par namespace et locale.  |
+
+## Résumé des stratégies
+
+- **Static** : Simple ; pas de latence réseau après le chargement initial. Inconvénient : taille de bundle importante.
+- **Dynamic** : Réduit le poids initial (lazy-loading). Idéal lorsque vous avez de nombreuses locales.
+- **Scoped static** : Organise bien le code (séparation logique) sans requêtes réseau supplémentaires complexes.
+- **Scoped dynamic** : Meilleure approche pour le _code splitting_ et la performance. Minimise la mémoire en ne chargeant que ce dont la vue actuelle et la locale active ont besoin.
+
+## Résultats détaillés
+
+### 1 — Solutions à éviter
+
+> Aucune solution claire à éviter dans l'écosystème Svelte.
+
+### 2 — Solutions acceptables
+
+**(Paraglide)** (`@inlang/paraglide-js@2.17.0`) :
+
+`Paraglide` propose une approche innovante et bien pensée. Dans le contexte d'une application Vite + Svelte, le tree-shaking dont leur entreprise fait la publicité fonctionne comme prévu, ce qui est excellent.
+Mais dans le cas de React + TanStack Start, le tree-shaking n'a pas fonctionné comme prévu, de même pour Next.js. Cela dit, l'usage de Paraglide dans un projet Svelte et TanStack Start mériterait d'être vérifié de près.
+Le workflow et la DX sont également plus complexes qu'avec d'autres options.
+Personnellement, je n'aime pas devoir régénérer des fichiers JS avant chaque push, ce qui crée un risque constant de conflit de fusion via les PRs. L'outil semble également plus axé sur Vite que sur Next.js.
+Enfin, par rapport à d'autres solutions, Paraglide n'utilise pas de store (ex: Svelte store) pour récupérer la locale actuelle afin de rendre le contenu. Pour chaque nœud analysé, il demandera la locale au localStorage / cookie etc. Cela conduit à l'exécution d'une logique inutile qui impacte la réactivité des composants.
+
+> Note sur paraglide : cette solution injecte du code dans votre base de code pour les imports, par conséquent, la métrique 'lib size' dans le rapport de benchmark est presque de 0. La génération de code est une bonne chose, car la fonction utilisée n'inclura que la logique nécessaire (préfixe partout vs pas de préfixe, cookie vs stockage, etc.). En comparaison, Intlayer effectue ce filtrage via des injections de variables d'environnement pendant le build pour forcer le bundler à tree-shaker le contenu en fonction de la logique. Grâce à cela, paraglide et intlayer finissent par être des solutions 6 à 10 fois plus légères qu'i18next ou next-intl.
+
+**(svelte-i18n)** (`svelte-i18n@3.4.0`) :
+
+Cette solution répond à tous les besoins i18n dans un projet Svelte. Mais comme c'est le cas pour i18next ou d'autres solutions majeures, elle est un peu lourde (~15.9 Ko, soit environ 7× `svelte-intlayer`).
+
+### 3 — Recommandations
+
+**(Intlayer)** (`svelte-intlayer@8.7.12`) :
+
+Je ne jugerai pas personnellement `svelte-intlayer` par souci d'objectivité, puisqu'il s'agit de ma propre solution.
+
+### Note personnelle
+
+Cette note est personnelle et n'affecte pas les résultats du benchmark. Pourtant, dans le monde de l'i18n, on voit souvent un consensus autour d'un pattern comme `const t = useTranslation('xx')` + `<>{t('xx.xx')}</>` pour le contenu traduit.
+
+Dans les applications Svelte, injecter une fonction en tant que `Slot` est, à mon avis, un anti-pattern. Cela ajoute également une complexité évitable et un surcoût d'exécution JavaScript (même s'il est à peine perceptible).

package/docs/fr/benchmark/tanstack.md

@@ -57,6 +57,13 @@ En pratique, pour les implémentations les moins optimisées, une page internati
 
 L'autre impact concerne l'expérience développeur (DX) : la façon dont vous déclarez le contenu, les types, l'organisation des namespaces, le chargement dynamique et la réactivité lors du changement de langue.
 
+## TL;DR
+
+- **Intlayer** : Fournit la meilleure performance et la plus petite taille de bundle (v8.7.12) pour TanStack Start.
+- **react-i18next** & **use-intl** : Alternatives matures avec de grands écosystèmes, mais nettement plus lourdes et complexes à optimiser.
+- **Paraglide** : Idée innovante de tree-shaking qui ne fonctionne pas en pratique. DX complexe et surcoût de réactivité dans TanStack Start.
+- **À éviter** : **General Translation (GT)** et **Lingo.dev** en raison de graves problèmes de performance, des limites de quota AI et du verrouillage propriétaire (vendor lock-in).
+
 ## Testez votre application
 
 Pour repérer rapidement les problèmes de fuite i18n, j'ai mis en place un scanner gratuit disponible [ici](https://intlayer.org/i18n-seo-scanner).
@@ -87,12 +94,12 @@ Les syntaxes basées sur `const t = useTranslation()` + `t('a.b.c')` sont très
 Pour ce benchmark, nous avons comparé les bibliothèques suivantes :
 
 - `Base App` (Pas de bibliothèque i18n)
-- `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 @@ L'idée derrière `Wuchale` est intéressante mais ce n'est pas encore une solut
 
 `Paraglide` propose une approche innovante et bien pensée. Pourtant, dans ce benchmark, le tree-shaking dont leur entreprise fait la publicité n'a pas fonctionné pour mon implémentation Next.js ou pour TanStack Start. Le workflow et la DX sont également plus complexes d'autres options. Personnellement, je ne suis pas fan de devoir régénérer des fichiers JS avant chaque push, ce qui crée un risque constant de conflit de fusion pour les développeurs via les PRs.
 
-**(Tolgee)** (`tolgee@7.0.0`) :
+> Note sur paraglide : cette solution injecte du code dans votre base de code pour les imports, par conséquent, la métrique 'lib size' dans le rapport de benchmark est presque de 0. La génération de code est une bonne chose, car la fonction utilisée n'inclura que la logique nécessaire (préfixe partout vs pas de préfixe, cookie vs stockage, etc.). En comparaison, Intlayer effectue ce filtrage via des injections de variables d'environnement dans le build pour forcer le bundler à tree-shaker le contenu en fonction de la logique. Grâce à cela, paraglide et intlayer finissent par être des solutions 6 à 10 fois plus légères qu'i18next ou next-intl.
+
+**(Tolgee)** (`@tolgee/react@7.0.0`) :
 
 `Tolgee` traite bon nombre des problèmes mentionnés plus haut. Je l'ai trouvé plus difficile à prendre en main que d'autres outils aux approches similaires. Il n'offre pas de sécurité de type, ce qui rend également beaucoup plus difficile la détection des clés manquantes à la compilation. J'ai dû wrapper les APIs de Tolgee avec les miennes pour ajouter la détection des clés manquantes.
 

package/docs/fr/benchmark/vue.md

@@ -0,0 +1,160 @@
+---
+createdAt: 2026-04-20
+updatedAt: 2026-04-21
+title: La meilleure solution i18n pour Vue en 2026 - Rapport de Benchmark
+description: Comparez les bibliothèques d'internationalisation (i18n) pour Vue comme vue-i18n, fluent-vue et Intlayer. Rapport de performance détaillé sur la taille du bundle, les fuites et la réactivité.
+keywords:
+  - benchmark
+  - i18n
+  - intl
+  - vue
+  - performance
+  - 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: "Initialisation du benchmark"
+---
+
+# Bibliothèques i18n Vue — Rapport de Benchmark 2026
+
+Cette page est un rapport de benchmark pour les solutions i18n sur Vue.
+
+## Table des Matières
+
+<Toc/>
+
+## Benchmark Interactif
+
+<I18nBenchmark framework="vite-vue" vertical/>
+
+## Référence des résultats :
+
+<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
+
+Voir le dépôt complet du benchmark [ici](https://github.com/intlayer-org/benchmark-i18n/tree/main).
+
+## Introduction
+
+Les solutions d'internationalisation figurent parmi les dépendances les plus lourdes d'une application Vue. Le risque principal est d'embarquer du contenu inutile : les traductions d'autres pages et d'autres locales dans le bundle d'une seule route.
+
+À mesure que votre application grandit, ce problème peut rapidement faire exploser la quantité de JavaScript envoyée au client et ralentir la navigation.
+
+En pratique, pour les implémentations les moins optimisées, une page internationalisée peut finir par être plusieurs fois plus lourde que la version sans i18n.
+
+L'autre impact concerne l'expérience développeur (DX) : la façon dont vous déclarez le contenu, les types, l'organisation des namespaces, le chargement dynamique et la réactivité lors du changement de langue.
+
+## TL;DR
+
+- **Intlayer** : La solution la plus légère (v8.7.12) avec découpage (scoping) et chargement dynamique natifs.
+- **vue-i18n** : Le standard de l'industrie avec un riche écosystème, mais peut être nettement plus lourd et difficile à optimiser pour le code-splitting dans les grandes applications.
+- **fluent-vue** : Organisation innovante des messages mais manque de sécurité de type et s'avère extrêmement lourd.
+
+## Testez votre application
+
+Pour repérer rapidement les problèmes de fuite i18n, j'ai mis en place un scanner gratuit disponible [ici](https://intlayer.org/i18n-seo-scanner).
+
+<iframe src="https://intlayer.org/i18n-seo-scanner" width="100%" height="600px" style="border:none;"/>
+
+## Le problème
+
+Deux leviers sont essentiels pour limiter le coût d'une application multilingue :
+
+- Découper le contenu par page / namespace afin de ne pas charger des dictionnaires entiers quand on n'en a pas besoin
+- Charger la bonne locale dynamiquement, uniquement quand nécessaire
+
+Comprendre les limitations techniques de ces approches :
+
+**Chargement dynamique**
+
+Sans chargement dynamique, la plupart des solutions gardent les messages en mémoire dès le premier rendu, ce qui ajoute un surcoût important pour les applications ayant beaucoup de routes et de langues.
+
+Avec le chargement dynamique, vous acceptez un compromis : moins de JS initial, mais parfois une requête supplémentaire lors du changement de langue.
+
+**Découpage du contenu (Splitting)**
+
+Les syntaxes basées sur `const { t } = useI18n()` + `t('a.b.c')` sont très pratiques mais encouragent souvent la conservation de gros objets JSON au runtime. Ce modèle rend le tree-shaking difficile à moins que la bibliothèque ne propose une réelle stratégie de découpage par page.
+
+## Méthodologie
+
+Pour ce benchmark, nous avons comparé les bibliothèques suivantes :
+
+- `Base App` (Pas de bibliothèque i18n)
+- `vue-intlayer` (v8.7.12)
+- `vue-i18n` (v11.4.0)
+- `fluent-vue` (v3.8.2)
+
+Le framework utilisé est `Vue` avec une application multilingue de **10 pages** et **10 langues**.
+
+Nous avons comparé **quatre stratégies de chargement** :
+
+| Stratégie                | Sans namespaces (global)                          | Avec namespaces (scoped)                                             |
+| :----------------------- | :------------------------------------------------ | :------------------------------------------------------------------- |
+| **Chargement statique**  | **Static** : Tout en mémoire au démarrage.        | **Scoped static** : Divisé par namespace ; tout chargé au démarrage. |
+| **Chargement dynamique** | **Dynamic** : Chargement à la demande par locale. | **Scoped dynamic** : Chargement granulaire par namespace et locale.  |
+
+## Résumé des stratégies
+
+- **Static** : Simple ; pas de latence réseau après le chargement initial. Inconvénient : taille de bundle importante.
+- **Dynamic** : Réduit le poids initial (lazy-loading). Idéal lorsque vous avez de nombreuses locales.
+- **Scoped static** : Organise bien le code (séparation logique) sans requêtes réseau supplémentaires complexes.
+- **Scoped dynamic** : Meilleure approche pour le _code splitting_ et la performance. Minimise la mémoire en ne chargeant que ce dont la vue actuelle et la locale active ont besoin.
+
+### Ce que j'ai mesuré :
+
+J'ai fait tourner la même application multilingue dans un vrai navigateur pour chaque stack, puis j'ai noté ce qui passait réellement sur le réseau et combien de temps cela prenait. Les tailles sont indiquées **après compression web normale**, car c'est plus proche de ce que les gens téléchargent réellement.
+
+- **Taille de la bibliothèque d'internationalisation** : Après bundling, tree-shaking et minification, la taille de la bibliothèque i18n est la taille du code des providers + composables dans un composant vide. Cela n'inclut pas le chargement des fichiers de traduction. Cela montre à quel point la bibliothèque est "coûteuse" avant même que votre contenu n'entre en jeu.
+
+- **JavaScript par page** : Pour chaque route du benchmark, quelle quantité de scripts le navigateur récupère pour cette visite, en moyenne sur les pages du test (et sur les locales). Les pages lourdes sont des pages lentes.
+
+- **Fuite des autres locales (Leakage)** : C'est le contenu de la même page mais dans une autre langue qui serait chargé par erreur dans la page auditée. Ce contenu est inutile et doit être évité (ex: contenu de la page `/fr/about` dans le bundle de la page `/en/about`).
+
+- **Fuite des autres routes** : Même idée pour les **autres écrans** de l'application : si leurs textes sont embarqués alors que vous n'avez ouvert qu'une seule page (ex: contenu de la page `/en/about` dans le bundle de la page `/en/contact`). Un score élevé indique un faible découpage ou des bundles trop larges.
+
+- **Taille moyenne du bundle d'un composant** : Les éléments UI communs sont mesurés **un par un**, au lieu d'être cachés dans un seul chiffre global d'application. Cela montre si l'internationalisation gonfle discrètement les composants du quotidien. Par exemple, si votre composant se re-rend, il chargera toutes ces données depuis la mémoire. Attacher un JSON géant à n'importe quel composant revient à connecter un grand entrepôt de données inutilisées qui ralentira les performances de vos composants.
+
+- **Réactivité du changement de langue** : Je change la langue via le contrôle de l'application et je mesure le temps nécessaire pour que la page ait clairement basculé, ce qu'un visiteur remarquerait.
+
+- **Travail de rendu après un changement de langue** : Un indicateur plus précis : quel effort l'interface a fourni pour se redessiner dans la nouvelle langue une fois le changement lancé. Utile lorsque le temps "ressenti" et le coût du framework divergent.
+
+- **Temps de chargement initial de la page** : De la navigation jusqu'au moment où le navigateur considère la page comme entièrement chargée pour les scénarios testés. Utile pour comparer les démarrages à froid.
+
+- **Temps d'hydratation (Hydration)** : Temps que le client passe à transformer le HTML du serveur en interface interactive. Un tiret dans les tableaux signifie que l'implémentation n'a pas fourni de chiffre d'hydratation fiable dans ce test.
+
+## Résultats en détail
+
+### 1 — Solutions à éviter
+
+> Aucune solution claire à éviter dans l'écosystème Vue.
+
+### 2 — Solutions acceptables
+
+**(vue-i18n)** (`vue-i18n@11.4.0`) :
+
+- **vue-i18n** est sans conteste la bibliothèque i18n la plus utilisée pour Vue, elle possède énormément de fonctionnalités et un immense écosystème. Mais sous le capot, la solution est assez lourde. Même si vue-i18n intègre le lazy loading des messages, il lui manque une fonctionnalité de découpage (scoping). Dans le cas d'une application Vue SPA classique, cela ne pose pas de problème, mais pour une application Nuxt utilisant @nuxt/i18n, cela conduit à inclure les messages de toutes les pages dans une seule. Pour une grosse application Nuxt de plus de 10 pages, cela peut devenir vraiment problématique.
+
+Le paquet est très lourd (~24.3 Ko, soit environ 9× `vue-intlayer`).
+
+**(fluent-vue)** (`fluent-vue@0.5.0`) :
+
+- **fluent-vue** propose une tentative d'innovation via le format .ftl. L'organisation des messages est excellente, plus facile pour débuter. Mais en pratique, le manque de sécurité de type augmente le risque d'erreur et peut vite devenir chronophage à déboguer. De plus, cette solution charge les messages via un plugin vite qui force le chargement de tout le contenu dans toutes les langues dans chaque page. Enfin, c'est une solution extrêmement lourde (~92.7 Ko, soit environ 34× `vue-intlayer`).
+
+### 3 — Recommandations
+
+**(Intlayer)** (`vue-intlayer@8.7.12`) :
+
+Je ne jugerai pas personnellement `vue-intlayer` par souci d'objectivité, puisqu'il s'agit de ma propre solution.

package/docs/fr/configuration.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2024-08-13
-updatedAt: 2026-04-08
+updatedAt: 2026-05-12
 title: Configuration
 description: Apprenez à configurer Intlayer pour votre application. Comprenez les différents paramètres et options disponibles pour personnaliser Intlayer selon vos besoins.
 keywords:
@@ -14,6 +14,9 @@ slugs:
   - concept
   - configuration
 history:
+  - version: 8.9.4
+    date: 2026-05-12
+    changes: "Ajout du support pour le fournisseur LM Studio"
   - version: 8.7.0
     date: 2026-04-08
     changes: "Ajout des options `prune` et `minify` à la configuration de build"
@@ -350,7 +353,7 @@ const config: IntlayerConfig = {
   ai: {
     /**
      * Fournisseur d'IA à utiliser.
-     * Options : 'openai', 'anthropic', 'mistral', 'deepseek', 'gemini', 'ollama', 'openrouter', 'alibaba', 'fireworks', 'groq', 'huggingface', 'bedrock', 'googlevertex', 'togetherai'
+     * Options : 'openai', 'anthropic', 'mistral', 'deepseek', 'gemini', 'ollama', 'openrouter', 'alibaba', 'fireworks', 'groq', 'huggingface', 'bedrock', 'googlevertex', 'togetherai', 'lmstudio'
      * Par défaut : 'openai'
      */
     provider: "openai",
@@ -919,16 +922,17 @@ Intlayer supporte plusieurs fournisseurs d'IA pour une flexibilité accrue. Les
 - **Groq**
 - **Amazon Bedrock**
 - **Together.ai**
-
-| Champ                | Description                                                                                                                                   | Type                                                                                                                                                                                                                                                                                                                                                                                           | Par défaut  | Exemple                                                       | Note                                                                                                                                                                                                              |
-| -------------------- | --------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------- | ------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| `provider`           | Le fournisseur à utiliser pour les fonctionnalités IA d'Intlayer.                                                                             | `'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'`                                                 | Les différents fournisseurs nécessitent des clés API différentes et ont des tarifs variés.                                                                                                                        |
-| `model`              | Le modèle à utiliser pour les fonctionnalités IA.                                                                                             | `string`                                                                                                                                                                                                                                                                                                                                                                                       | Aucun       | `'gpt-4o-2024-11-20'`                                         | Le modèle spécifique varie selon le fournisseur.                                                                                                                                                                  |
-| `temperature`        | Contrôle le caractère aléatoire des réponses de l'IA.                                                                                         | `number`                                                                                                                                                                                                                                                                                                                                                                                       | Aucun       | `0.1`                                                         | Température plus élevée = plus créatif et moins prévisible.                                                                                                                                                       |
-| `apiKey`             | Votre clé API pour le fournisseur sélectionné.                                                                                                | `string`                                                                                                                                                                                                                                                                                                                                                                                       | Aucun       | `process.env.OPENAI_API_KEY`                                  | Garder secret ; stocker dans les variables d'environnement.                                                                                                                                                       |
-| `applicationContext` | Contexte supplémentaire sur votre application pour aider l'IA à générer des traductions plus précises (domaine, audience, ton, terminologie). | `string`                                                                                                                                                                                                                                                                                                                                                                                       | Aucun       | `'Mon contexte d'application'`                                | Peut être utilisé pour ajouter des règles (ex: `"Vous ne devez pas transformer les urls"`).                                                                                                                       |
-| `baseURL`            | L'URL de base pour l'API IA.                                                                                                                  | `string`                                                                                                                                                                                                                                                                                                                                                                                       | Aucun       | `'https://api.openai.com/v1'` <br/> `'http://localhost:5000'` | Peut pointer vers un point de terminaison d'API IA local ou personnalisé.                                                                                                                                         |
-| `dataSerialization`  | Format de sérialisation des données pour les fonctionnalités IA.                                                                              | `'json'` &#124; <br/> `'toon'`                                                                                                                                                                                                                                                                                                                                                                 | `undefined` | `'toon'`                                                      | • `'json'`: standard, fiable ; utilise plus de tokens.<br/>• `'toon'`: moins de tokens, moins cohérent.<br/>• Des paramètres supplémentaires sont passés au modèle comme contexte (effort de raisonnement, etc.). |
+- **LM Studio**
+
+| Champ                | Description                                                                                                                                   | Type                                                                                                                                                                                                                                                                                                                                                                                                                     | Par défaut  | Exemple                                                       | Note                                                                                                                                                                                                              |
+| -------------------- | --------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ----------- | ------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `provider`           | Le fournisseur à utiliser pour les fonctionnalités IA d'Intlayer.                                                                             | `'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'`                                                 | Les différents fournisseurs nécessitent des clés API différentes et ont des tarifs variés.                                                                                                                        |
+| `model`              | Le modèle à utiliser pour les fonctionnalités IA.                                                                                             | `string`                                                                                                                                                                                                                                                                                                                                                                                                                 | Aucun       | `'gpt-4o-2024-11-20'`                                         | Le modèle spécifique varie selon le fournisseur.                                                                                                                                                                  |
+| `temperature`        | Contrôle le caractère aléatoire des réponses de l'IA.                                                                                         | `number`                                                                                                                                                                                                                                                                                                                                                                                                                 | Aucun       | `0.1`                                                         | Température plus élevée = plus créatif et moins prévisible.                                                                                                                                                       |
+| `apiKey`             | Votre clé API pour le fournisseur sélectionné.                                                                                                | `string`                                                                                                                                                                                                                                                                                                                                                                                                                 | Aucun       | `process.env.OPENAI_API_KEY`                                  | Garder secret ; stocker dans les variables d'environnement.                                                                                                                                                       |
+| `applicationContext` | Contexte supplémentaire sur votre application pour aider l'IA à générer des traductions plus précises (domaine, audience, ton, terminologie). | `string`                                                                                                                                                                                                                                                                                                                                                                                                                 | Aucun       | `'Mon contexte d'application'`                                | Peut être utilisé pour ajouter des règles (ex: `"Vous ne devez pas transformer les urls"`).                                                                                                                       |
+| `baseURL`            | L'URL de base pour l'API IA.                                                                                                                  | `string`                                                                                                                                                                                                                                                                                                                                                                                                                 | Aucun       | `'https://api.openai.com/v1'` <br/> `'http://localhost:5000'` | Peut pointer vers un point de terminaison d'API IA local ou personnalisé.                                                                                                                                         |
+| `dataSerialization`  | Format de sérialisation des données pour les fonctionnalités IA.                                                                              | `'json'` &#124; <br/> `'toon'`                                                                                                                                                                                                                                                                                                                                                                                           | `undefined` | `'toon'`                                                      | • `'json'`: standard, fiable ; utilise plus de tokens.<br/>• `'toon'`: moins de tokens, moins cohérent.<br/>• Des paramètres supplémentaires sont passés au modèle comme contexte (effort de raisonnement, etc.). |
 
 ---