@intlayer/docs 8.9.4 → 8.9.6-canary.0

package/docs/es/dictionary/content_file.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2025-02-07
-updatedAt: 2026-01-28
+updatedAt: 2026-05-12
 title: Archivo de Contenido
 description: Aprende a personalizar las extensiones para tus archivos de declaración de contenido. Sigue esta documentación para implementar condiciones de manera eficiente en tu proyecto.
 keywords:
@@ -12,6 +12,9 @@ slugs:
   - concept
   - content
 history:
+  - version: 8.9.0
+    date: 2026-05-12
+    changes: "Añadir tipo de nodo de contenido `plural`"
   - version: 8.0.0
     date: 2026-01-28
     changes: "Añadir tipo de nodo de contenido `html`"
@@ -66,6 +69,7 @@ import { type ReactNode } from "react";
 import {
   t,
   enu,
+  plural,
   cond,
   nest,
   md,
@@ -85,6 +89,7 @@ interface Content {
   };
   multilingualContent: string;
   quantityContent: string;
+  pluralContent: string;
   conditionalContent: string;
   markdownContent: never;
   htmlContent: never;
@@ -120,6 +125,10 @@ export default {
       ">5": "Algunos coches",
       ">19": "Muchos coches",
     }),
+    pluralContent: plural({
+      one: "One car",
+      other: "{{count}} cars",
+    }),
     conditionalContent: cond({
       true: "La validación está habilitada",
       false: "La validación está deshabilitada",
@@ -174,6 +183,13 @@ export default {
         ">5": "Algunos coches",
         ">19": "Muchos coches",
       },
+      "pluralContent": {
+        "nodeType": "plural",
+        "plural": {
+          "one": "One car",
+          "other": "{{count}} cars",
+        },
+      },
     },
     "conditionalContent": {
       "nodeType": "condición",
@@ -221,6 +237,7 @@ Los nodos de contenido son los bloques de construcción del contenido del diccio
 - **Valores primitivos**: cadenas, números, booleanos, null, undefined
 - **Nodos tipados**: Tipos especiales de contenido como traducciones, condiciones, markdown, etc.
 - **Funciones**: Contenido dinámico que puede evaluarse en tiempo de ejecución [ver Obtención de Funciones](https://github.com/aymericzip/intlayer/blob/main/docs/docs/es/dictionary/function_fetching.md)
+- **Contenido Plural**: Ver Contenido Plural [Ver Contenido Plural](https://github.com/aymericzip/intlayer/blob/main/docs/docs/es/dictionary/plural.md)
 - **Contenido anidado**: Referencias a otros diccionarios
 
 #### Tipos de Contenido
@@ -539,6 +556,8 @@ multilingualContent: t({
 });
 ```
 
+> Ver [Contenido de Traducción (`t`) Doc](https://github.com/aymericzip/intlayer/blob/main/docs/docs/es/dictionary/translation.md) para más información.
+
 ### Contenido Condicional (`cond`)
 
 Contenido que cambia basado en condiciones booleanas:
@@ -552,6 +571,8 @@ conditionalContent: cond({
 });
 ```
 
+> Ver [Contenido Condicional (`cond`) Doc](https://github.com/aymericzip/intlayer/blob/main/docs/docs/es/dictionary/condition.md) para más información.
+
 ### Contenido de Enumeración (`enu`)
 
 Contenido que varía según valores enumerados:
@@ -566,6 +587,23 @@ statusContent: enu({
 });
 ```
 
+> Ver [Contenido de Enumeración (`enu`) Doc](https://github.com/aymericzip/intlayer/blob/main/docs/docs/es/dictionary/enumeration.md) para más información.
+
+### Contenido Plural (`plural`)
+
+Contenido que varía según las reglas de plural:
+
+```typescript
+import { plural } from "intlayer";
+
+pluralContent: plural({
+  one: "One car",
+  other: "{{count}} cars",
+});
+```
+
+> Ver [Contenido Plural Doc](https://github.com/aymericzip/intlayer/blob/main/docs/docs/es/dictionary/plural.md) para más información.
+
 ### Contenido de Inserción (`insert`)
 
 Contenido que puede ser insertado en otro contenido:
@@ -576,6 +614,8 @@ import { insert } from "intlayer";
 insertionContent: insert("Este texto puede ser insertado en cualquier lugar");
 ```
 
+> Ver [Contenido de Inserción (`insert`) Doc](https://github.com/aymericzip/intlayer/blob/main/docs/docs/es/dictionary/insertion.md) para más información.
+
 ### Contenido Anidado (`nest`)
 
 Referencias a otros diccionarios:
@@ -586,6 +626,8 @@ import { nest } from "intlayer";
 nestedContent: nest("about-page");
 ```
 
+> Ver [Contenido Anidado (`nest`) Doc](https://github.com/aymericzip/intlayer/blob/main/docs/docs/es/dictionary/nesting.md) para más información.
+
 ### Contenido Markdown (`md`)
 
 Contenido de texto enriquecido en formato Markdown:
@@ -598,6 +640,8 @@ markdownContent: md(
 );
 ```
 
+> Ver [Contenido Markdown (`md`) Doc](https://github.com/aymericzip/intlayer/blob/main/docs/docs/es/dictionary/markdown.md) para más información.
+
 ### Contenido HTML (`html`)
 
 Contenido HTML enriquecido que puede usar etiquetas estándar o componentes personalizados:
@@ -615,6 +659,8 @@ localizedHtmlContent: t({
 });
 ```
 
+> Ver [Contenido HTML (`html`) Doc](https://github.com/aymericzip/intlayer/blob/main/docs/docs/es/dictionary/html.md) para más información.
+
 ### Contenido según género (`gender`)
 
 Contenido que varía según el género:
@@ -629,6 +675,8 @@ genderContent: gender({
 });
 ```
 
+> Ver [Contenido según género (`gender`) Doc](https://github.com/aymericzip/intlayer/blob/main/docs/docs/es/dictionary/gender.md) para más información.
+
 ### Contenido de archivo (`file`)
 
 Referencias a archivos externos:
@@ -639,6 +687,8 @@ import { file } from "intlayer";
 fileContent: file("./path/to/content.txt");
 ```
 
+> Ver [Contenido de archivo (`file`) Doc](https://github.com/aymericzip/intlayer/blob/main/docs/docs/es/dictionary/file.md) para más información.
+
 ## Creación de archivos de contenido
 
 ### Estructura básica de un archivo de contenido

package/docs/es/plugins/sync-po.md

@@ -160,30 +160,9 @@ syncPO({
   source: ({ key, locale }) => string, // requerido
   location?: string, // etiqueta opcional, por defecto: "sync-po::path/to/source"
   priority?: number, // prioridad opcional para resolución de conflictos, por defecto: 0
-  format?: 'icu' | 'i18next' | 'vue-i18n', // opcional, solo necesario cuando tus valores msgstr usan una sintaxis de interpolación específica
 });
 ```
 
-#### `format` ('icu' | 'i18next' | 'vue-i18n')
-
-Los archivos PO son siempre archivos Gettext Portable Object — eso es fijo. Esta opción solo describe la **sintaxis de interpolación** utilizada dentro de los valores `msgstr`, para que Intlayer pueda convertirlos a su propio formato en el momento del análisis (a través de `formatDictionary`) y de vuelta al escribir la salida.
-
-- `undefined` _(por defecto)_: los valores `msgstr` se tratan como cadenas simples — sin transformación. Úsalo para la mayoría de los archivos PO.
-- `'icu'`: los valores `msgstr` utilizan la sintaxis de mensajes ICU (ej. `{count, plural, one {# item} other {# items}}`).
-- `'i18next'`: los valores `msgstr` utilizan la sintaxis de interpolación de i18next (ej. `{{variable}}`).
-- `'vue-i18n'`: los valores `msgstr` utilizan la sintaxis de Vue I18n.
-
-> La transformación se aplica mediante `formatDictionary` de `@intlayer/chokidar` al cargar, y se revierte con `formatDictionaryOutput` al escribir. Para reglas complejas como los plurales de ICU, no se garantiza la fidelidad del viaje de ida y vuelta.
-
-**Ejemplo — los archivos PO contienen interpolación al estilo i18next:**
-
-```ts
-syncPO({
-  source: ({ key, locale }) => `./locales/${locale}/${key}.po`,
-  format: "i18next",
-}),
-```
-
 ### Múltiples fuentes de PO y prioridad
 
 Puedes añadir múltiples plugins `syncPO` para sincronizar diferentes fuentes de PO. Esto es útil cuando tienes múltiples fuentes de traducción o diferentes estructuras de PO en tu proyecto.

package/docs/fr/benchmark/index.md

@@ -30,6 +30,3 @@ Les rapports détaillés et la documentation technique pour chaque framework se
 - [**Vue Benchmark Report**](https://github.com/aymericzip/intlayer/blob/main/docs/docs/en/benchmark/vue.md)
 - [**Solid Benchmark Report**](https://github.com/aymericzip/intlayer/blob/main/docs/docs/en/benchmark/solid.md)
 - [**Svelte Benchmark Report**](https://github.com/aymericzip/intlayer/blob/main/docs/docs/en/benchmark/svelte.md)
-- [**Vue Benchmark Report**](https://github.com/aymericzip/intlayer/blob/main/docs/docs/en/benchmark/vue.md)
-- [**Solid Benchmark Report**](https://github.com/aymericzip/intlayer/blob/main/docs/docs/en/benchmark/solid.md)
-- [**Svelte Benchmark Report**](https://github.com/aymericzip/intlayer/blob/main/docs/docs/en/benchmark/svelte.md)

package/docs/fr/benchmark/nextjs.md

@@ -61,6 +61,13 @@ Parce que le problème est complexe, de nombreuses solutions existent — certai
 
 Intlayer tente d'optimiser l'ensemble de ces dimensions.
 
+## TL;DR
+
+- **Intlayer** & **next-translate** : Meilleurs choix pour la performance Next.js, offrant l'empreinte la plus faible et le meilleur support du rendu statique.
+- **next-intl** : L'option la plus tendance mais lourde et complexe à optimiser pour les grandes applications.
+- **next-i18next** : Populaire et riche en plugins, mais porte un poids de bundle significatif (~3× Intlayer).
+- **À éviter** : **gt-next** et **lingo.dev** en raison de graves problèmes de performance, de verrouillage propriétaire et de bugs cassant le build.
+
 ## Testez votre application
 
 Pour mettre en lumière ces problèmes, j'ai construit un scanner gratuit que vous pouvez essayer [ici](https://intlayer.org/i18n-seo-scanner).
@@ -99,14 +106,14 @@ Enfin, `Intlayer` applique une optimisation au moment du build afin que `useIntl
 Pour ce benchmark, nous avons comparé les bibliothèques suivantes :
 
 - `Base App` (Pas de bibliothèque i18n)
-- `next-intlayer` (v8.7.5)
+- `next-intlayer` (v8.7.12)
 - `next-i18next` (v16.0.5)
 - `next-intl` (v4.9.1)
 - `@lingui/core` (v5.3.0)
 - `next-translate` (v3.1.2)
 - `next-international` (v1.3.1)
 - `@inlang/paraglide-js` (v2.15.1)
-- `tolgee` (v7.0.0)
+- `@tolgee/react` (v7.0.0)
 - `@lingo.dev/compiler` (v0.4.0)
 - `wuchale` (v0.22.11)
 - `gt-next` (v6.16.5)
@@ -161,10 +168,10 @@ Problèmes rencontrés :
 
 **(General Translation)** (`gt-next@6.16.5`) :
 
-- Pour une application de 110 Ko, `gt-react` ajoute plus de 440 Ko supplémentaires.
+- Pour une application de 110 Ko, `gt-next` ajoute plus de 440 Ko supplémentaires.
 - `Quota Exceeded, please upgrade your plan` dès le tout premier build avec General Translation.
 - Les traductions ne sont pas rendues ; j'obtiens l'erreur `Error: <T> used on the client-side outside of <GTProvider>`, ce qui semble être un bug de la bibliothèque.
-- Lors de l'implémentation de **gt-tanstack-start-react**, je suis également tombé sur un [problème](https://github.com/generaltranslation/gt/issues/1210#event-24510646961) avec la bibliothèque : `does not provide an export named 'printAST' - @formatjs/icu-messageformat-parser`, ce qui cassait l'application. Après avoir signalé ce problème, le mainteneur l'a corrigé sous 24 heures.
+- Lors de l'implémentation de **gt-next**, je suis également tombé sur un [problème](https://github.com/generaltranslation/gt/issues/1210#event-24510646961) avec la bibliothèque : `does not provide an export named 'printAST' - @formatjs/icu-messageformat-parser`, ce qui cassait l'application. Après avoir signalé ce problème, le mainteneur l'a corrigé sous 24 heures.
 - La bibliothèque bloque le rendu statique des pages Next.js.
 
 **(Lingo.dev)** (`@lingo.dev/compiler@0.4.0`) :
@@ -186,9 +193,11 @@ L'idée derrière `Wuchale` est intéressante mais pas encore viable. J'ai renco
 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 aux autres solutions, Paraglide n'utilise pas de "store" (ex: contexte React) pour récupérer la langue actuelle afin de rendre le contenu. Pour chaque nœud analysé, il demandera la langue au localStorage / cookie etc. Cela conduit à l'exécution d'une logique inutile qui impacte la réactivité des composants.
 
+> Note sur paraglide : la solution injecte du code dans votre base de code à importer, par conséquent la métrique 'taille de la lib' 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 total vs pas de préfixe, cookie vs stockage etc). En comparaison, Intlayer procède à ce filtrage via des injections de variables d'environnement dans le build pour forcer le bundler à tree-shaker le contenu selon la logique. Grâce à cela, paraglide et intlayer finissent par être des solutions 6 à 10 fois plus légères que i18next ou next-intl.
+
 ### 3 — Solutions acceptables
 
-**(Tolgee)** (`tolgee@7.0.0`) :
+**(Tolgee)** (`@tolgee/react@7.0.0`) :
 
 `Tolgee` traite bon nombre des problèmes mentionnés plus haut. Je l'ai trouvé plus difficile à adopter que des outils similaires. Il n'offre pas de sécurité de type (type safety), ce qui rend également plus difficile la détection des clés manquantes à la compilation. J'ai dû wrapper les fonctions de Tolgee avec les miennes pour ajouter la détection des clés manquantes.
 
@@ -216,7 +225,7 @@ Les formats de messages diffèrent également : `next-intl` utilise ICU MessageF
 
 `next-translate` est ma recommandation principale si vous aimez une API de style `t()`. C'est élégant via `next-translate-plugin`, chargeant les namespaces via `getStaticProps` avec un loader Webpack / Turbopack. C'est aussi l'option la plus légère ici (env. 2,5 Ko). Pour le découpage en namespaces, la définition par page ou par route dans la config est bien pensée et plus facile à maintenir que les alternatives principales comme **next-intl** ou **next-i18next**. Dans la version `3.1.2`, j'ai noté que le rendu statique ne fonctionnait pas ; Next.js se repliait sur le rendu dynamique.
 
-**(Intlayer)** (`next-intlayer@8.7.5`) :
+**(Intlayer)** (`next-intlayer@8.7.12`) :
 
 Je ne jugerai pas personnellement `next-intlayer` par souci d'objectivité, puisqu'il s'agit de ma propre solution.
 

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.