@intlayer/docs 9.5.7 → 9.5.9-canary.0

package/blog/es/is_intlayer_lighter_than_paraglide.md

@@ -0,0 +1,284 @@
+---
+createdAt: 2026-09-23
+updatedAt: 2026-09-23
+title: ¿Es Intlayer más ligero que Paraglide?
+description: Paraglide parece casi gratuito en los benchmarks de i18n porque su código se genera en tu repositorio. Aquí te mostramos a dónde va realmente ese peso, por qué la resolución de locale por nodo tiene un coste y cómo la carga dinámica de Intlayer envía un solo idioma en lugar de todos.
+keywords:
+  - Paraglide
+  - Intlayer
+  - Internacionalización
+  - i18n
+  - Bundle size
+  - Tree shaking
+  - Benchmark
+  - Blog
+slugs:
+  - blog
+  - is-intlayer-lighter-than-paraglide
+author: aymericzip
+---
+
+# ¿Es Intlayer más ligero que Paraglide?
+
+Sí.
+
+`Paraglide` tiene una sólida reputación por ser la solución de i18n más ligera del mercado, y a primera vista el [benchmark](https://intlayer.org/es/doc/benchmark/tanstack) coincide: el tamaño de su biblioteca es cercano a cero. Pero un tamaño de biblioteca de cero no significa que se envíen cero bytes. Significa que los bytes residen en un lugar donde la métrica no mira.
+
+<TOC/>
+
+## Puntos clave
+
+**El tamaño de la biblioteca está oculto, no eliminado:**
+
+Paraglide genera su runtime y funciones de mensajes dentro de tu codebase. Ese código se envía al navegador, pero se contabiliza como _tu_ código, no como el de la biblioteca.
+
+**Prescindir de un provider no es una ganancia gratuita:**
+
+Cada llamada a `m.my_key()` resuelve el locale por su cuenta, leyendo la cookie o el storage en cada nodo renderizado, en lugar de leerlo una sola vez desde un contexto.
+
+**Sin carga dinámica:**
+
+Paraglide importa todos los idiomas de un mensaje dentro del bundle de tu cliente. Intlayer con `importMode: 'dynamic'` o `'fetch'` carga únicamente el idioma que se está renderizando.
+
+**El tree shaking no está garantizado:**
+
+En algunos de nuestros benchmarks, el tree shaking anunciado por Paraglide no surtió efecto. Comprueba tu propio bundle.
+
+## ¿A dónde va el peso de Paraglide?
+
+En los informes de benchmark, la métrica "tamaño de la biblioteca" mide el provider y los hooks de cada biblioteca de i18n en un componente vacío, antes de agregar cualquier contenido.
+
+| Biblioteca (TanStack Start)   | Tamaño lib (gz) | Tamaño lib (min) |
+| ----------------------------- | --------------- | ---------------- |
+| `@inlang/paraglide-js@2.15.1` | 1.8 KB          | 4.5 KB           |
+| `react-intlayer@9.5.1`        | 5.0 KB          | 15.2 KB          |
+
+Visto de forma aislada, Paraglide gana. Pero Paraglide es un compilador: lee tus archivos `messages/*.json` y escribe una carpeta `paraglide/` en tu repositorio, la cual contiene un archivo `runtime.js` (detección de locale, estrategias de cookies y storage, localización de URLs) y una función de JavaScript por cada mensaje.
+
+```bash
+src/paraglide/
+├── runtime.js      # detección de locale, estrategias, helpers de URL
+├── server.js
+├── messages.js     # reexporta cada mensaje
+└── messages/
+    ├── _index.js
+    ├── en.js
+    └── fr.js
+```
+
+Debido a que este código se encuentra en tu carpeta `src/` y lo importas mediante una ruta relativa, el bundler lo atribuye a tu aplicación y no a un paquete en `node_modules`. La columna del tamaño de la biblioteca muestra casi nada, mientras que la misma lógica se sigue enviando en el bundle de tu página.
+
+Generar código no es una mala idea en sí misma: el runtime generado solo incluye la lógica que tu configuración necesita (estrategia de prefijo, cookie frente a local storage, etc.). Intlayer alcanza el mismo resultado de forma diferente, inyectando variables de entorno en tiempo de compilación para que el bundler elimine las ramas que tu configuración no utiliza. Ambos enfoques terminan siendo de 3 a 10 veces más ligeros que `i18next` o `next-intl`.
+
+Por lo tanto, la comparación justa no es el tamaño de la biblioteca. Es **el JavaScript que realmente se envía por página**.
+
+## Peso por página, medido
+
+Aplicación TanStack Start, 10 páginas, medido en las rutas `en` y `fr`, comprimido con gzip:
+
+| Configuración                      | JS pág prom (gz) | Sobre la base | Fuga de locale | Fuga de otras páginas |
+| ---------------------------------- | ---------------- | ------------- | -------------- | --------------------- |
+| Base (sin i18n)                    | 111.0 KB         | -             | 0.0%           | 0.0%                  |
+| `paraglide` (cualquier estrategia) | 125.1 KB         | +14.1 KB      | 49.7%          | 0.0%                  |
+| `intlayer` (`importMode: static`)  | 125.8 KB         | +14.8 KB      | 50.0%          | 0.0%                  |
+| `intlayer` (`importMode: dynamic`) | **118.6 KB**     | **+7.6 KB**   | **0.0%**       | **0.0%**              |
+
+Next.js 16 App Router, misma aplicación:
+
+| Configuración    | JS pág prom (gz) | Sobre la base |
+| ---------------- | ---------------- | ------------- |
+| Base (sin i18n)  | 141.0 KB         | -             |
+| `paraglide-next` | 155.3 KB         | +14.3 KB      |
+| `next-intlayer`  | **141.3 KB**     | **+0.3 KB**   |
+
+<I18nBenchmark framework="tanstack" vertical/>
+
+> Datos completos en el [informe de benchmark de TanStack Start](https://intlayer.org/es/doc/benchmark/tanstack) y en el [informe de benchmark de Next.js](https://intlayer.org/es/doc/benchmark/nextjs). Cada bundle se puede inspeccionar en el [repositorio del benchmark](https://github.com/intlayer-org/benchmark-i18n).
+
+Dos conclusiones destacan con claridad:
+
+- En modo `static`, Intlayer envía prácticamente el mismo contenido que Paraglide (125.8 KB frente a 125.1 KB). Esto es lo esperado: ambos incluyen todos los idiomas de los mensajes que utiliza una página.
+- Paraglide permanece en 125.1 KB independientemente de la estrategia, porque carece de un modo dinámico. Cada línea en la tabla anterior equivale a la opción estática.
+
+## Sin Provider: una buena idea que no lo es
+
+Paraglide no requiere provider. Importas un mensaje y lo ejecutas:
+
+```tsx fileName="Hero.tsx"
+import { m } from "../paraglide/messages.js";
+
+export const Hero = () => (
+  <section>
+    <h1>{m.hero_title()}</h1>
+    <p>{m.hero_description()}</p>
+    <button>{m.hero_cta()}</button>
+  </section>
+);
+```
+
+Sin contexto, sin wrapper, sin hook. Parece más sencillo. Sin embargo, el locale tiene que provenir de algún lugar. Cada función de mensaje generada se parece a esto (simplificado):
+
+```js fileName="paraglide/messages/_index.js"
+export const hero_title = (inputs = {}, options = {}) => {
+  const locale = options.locale ?? getLocale(); // se resuelve en cada llamada
+
+  if (locale === "en") return en.hero_title(inputs);
+  if (locale === "fr") return fr.hero_title(inputs);
+  // ...una rama por idioma
+};
+```
+
+Y `getLocale()` recorre las estrategias configuradas (cookie, local storage, URL, locale base) para determinar el locale activo. De modo que cada nodo de texto que renderizas (`<>{m.my_key()}</>`) ejecuta su propia resolución de locale, lo que incluye leer `document.cookie` en el navegador. Una página con 200 cadenas traducidas resuelve el locale 200 veces por renderizado, y nuevamente en cada re-renderizado.
+
+Una biblioteca basada en un provider lee el locale **una sola vez**, lo almacena en un contexto (o en una señal, o en un store), y cada nodo lee un valor que ya está en memoria. El provider cuesta unos pocos cientos de bytes. Omitirlo cuesta ciclos de CPU en cada renderizado, lo cual se refleja en el benchmark: los tiempos de carga de página y de cambio de idioma de Paraglide quedan sistemáticamente por detrás de Intlayer en TanStack Start (22.1 ms frente a 14.6 ms en carga de página, 4.3 ms frente a 3.2 ms en reactividad E2E).
+
+## Experiencia de desarrollo
+
+La fuente de verdad de Paraglide es JSON, pero nunca importas el JSON directamente. Importas el archivo `.js` generado:
+
+<Tabs defaultTab="intlayer" group="techno">
+  <Tab label="Paraglide" value="paraglide">
+
+```json fileName="messages/en.json"
+{
+  "hero_title": "Ship your app in every language"
+}
+```
+
+```json fileName="messages/es.json"
+{
+  "hero_title": "Publica tu app en todos los idiomas"
+}
+```
+
+```tsx fileName="Hero.tsx"
+// Solo existe después de que el compilador lo regenere desde el JSON
+import { m } from "../paraglide/messages.js";
+
+export const Hero = () => <h1>{m.hero_title()}</h1>;
+```
+
+  </Tab>
+  <Tab label="Intlayer" value="intlayer">
+
+```ts fileName="Hero.content.ts"
+import { t, type Dictionary } from "intlayer";
+
+export default {
+  key: "hero",
+  content: {
+    title: t({
+      es: "Publica tu app en todos los idiomas",
+      en: "Ship your app in every language",
+    }),
+  },
+} satisfies Dictionary;
+```
+
+```tsx fileName="Hero.tsx"
+import { useIntlayer } from "react-intlayer";
+
+export const Hero = () => {
+  const { title } = useIntlayer("hero");
+
+  return <h1>{title}</h1>;
+};
+```
+
+  </Tab>
+</Tabs>
+
+Ese ciclo de trabajo tiene un coste:
+
+- Cada cambio en un archivo JSON requiere una regeneración antes de que la importación se resuelva o los tipos se actualicen.
+- La carpeta generada `paraglide/` o bien se incluye en el control de versiones, lo que genera conflictos de merge en archivos generados en cada PR que toque textos, o bien se ignora en git, lo que exige un paso de generación previo a cada verificación de tipos, test y tarea de CI.
+- Cada cadena de texto se convierte en una llamada a función. Las constantes pasan a ser `m.key()` por todas partes, incluso donde un valor plano sería suficiente.
+
+## Tree Shaking: revisa tu bundle
+
+La principal promesa de Paraglide es que los mensajes no utilizados se eliminan mediante tree shaking, dado que cada mensaje representa una exportación independiente. En el benchmark de Svelte + Vite, funciona tal como se describe.
+
+En otros entornos, no fue así. En nuestras pruebas con [Next.js](https://intlayer.org/es/doc/benchmark/nextjs), las páginas de Paraglide pesan 14 KB más que la aplicación base, mientras que `next-intlayer` solo añade 0.3 KB. Pruebas anteriores en TanStack Start demostraron que mensajes de otras páginas también terminaban incorporándose en el bundle de la ruta.
+
+El tree shaking depende de tu bundler (Turbopack, Rolldown, Rollup), de la forma en que se importan los mensajes (`import { m }` frente a `import * as m`) y del análisis de efectos secundarios. Si eliges Paraglide por su tamaño, abre tu visualizador de bundle y comprueba que se cumpla en tu aplicación.
+
+## Sin carga dinámica
+
+Este es el límite estructural. Paraglide no dispone de un mecanismo para cargar un solo idioma a la vez: cada función de mensaje importa de manera estática la implementación de cada idioma, por lo que todos los idiomas acaban en el bundle de tu cliente.
+
+Con 2 idiomas, se desperdicia la mitad de los datos de traducción, lo cual coincide con el ~50% de fuga de locale medido anteriormente. Con 10 idiomas, el 90%. Con 30 idiomas, el 97%.
+
+Pasar a una carga dinámica tampoco solucionaría el problema: al tener una función por mensaje, cargar cada función de forma diferida implicaría miles de peticiones individuales.
+
+Intlayer te permite elegir la estrategia, ya sea de forma global o por diccionario:
+
+```ts fileName="intlayer.config.ts"
+import { Locales, type IntlayerConfig } from "intlayer";
+
+const config: IntlayerConfig = {
+  internationalization: {
+    locales: [Locales.ENGLISH, Locales.FRENCH, Locales.SPANISH],
+    defaultLocale: Locales.ENGLISH,
+  },
+  dictionary: {
+    importMode: "dynamic", // 'static' | 'dynamic' | 'fetch'
+  },
+};
+
+export default config;
+```
+
+| `importMode` | Qué se envía al cliente                                     | vs. Paraglide                        |
+| ------------ | ----------------------------------------------------------- | ------------------------------------ |
+| `static`     | Todos los idiomas de los diccionarios que usa la página     | Teóricamente el mismo contenido      |
+| `dynamic`    | Solo el idioma actual, cargado bajo demanda por diccionario | **N veces más ligero** con N idiomas |
+| `fetch`      | Solo el idioma actual, obtenido desde la Live Sync API      | **N veces más ligero** con N idiomas |
+
+Mediante la [transformación en compilación](https://intlayer.org/es/doc/concept/bundle-optimization) y el modo `importMode: 'static'`, Intlayer carga, en teoría, exactamente el mismo contenido que Paraglide. Con `'dynamic'` o `'fetch'`, carga únicamente lo que requiere el idioma actual: para una aplicación en N idiomas, la carga de traducción es N veces menor que la de Paraglide.
+
+## Dónde sigue encajando Paraglide
+
+<AccordionGroup>
+<Accordion header="Svelte + Vite con pocos idiomas">
+
+Si tu stack es Svelte con Vite y manejas dos o tres idiomas, el tree shaking funciona como se anuncia y la sobrecarga de idiomas se mantiene baja.
+
+</Accordion>
+<Accordion header="Flujo de trabajo existente con inlang">
+
+Si tu equipo ya utiliza el ecosistema inlang (Fink, Sherlock, plugins de formato de mensajes), Paraglide se integra con él de forma nativa.
+
+</Accordion>
+</AccordionGroup>
+
+## Pruébalo en tu aplicación
+
+Comprueba el tamaño y las fugas de locale de tu aplicación en producción con el [i18n SEO Scanner](https://intlayer.org/i18n-seo-scanner) gratuito:
+
+<ClickToOpenIframe src="https://intlayer.org/i18n-seo-scanner" width="100%" height="600px" style="border:none;"/>
+
+Para configurar Intlayer:
+
+```bash packageManager="npm"
+npx intlayer init --interactive
+```
+
+```bash packageManager="pnpm"
+pnpm dlx intlayer init --interactive
+```
+
+```bash packageManager="yarn"
+yarn dlx intlayer init --interactive
+```
+
+```bash packageManager="bun"
+bunx intlayer init --interactive
+```
+
+## Lecturas complementarias
+
+- [Benchmark de i18n en TanStack Start](https://intlayer.org/es/doc/benchmark/tanstack)
+- [Benchmark de i18n en Next.js](https://intlayer.org/es/doc/benchmark/nextjs)
+- [Optimización de bundles e `importMode`](https://intlayer.org/es/doc/concept/bundle-optimization)
+- [Cómo elegir una biblioteca de i18n para React](https://intlayer.org/es/blog/how-to-pick-react-i18n-library)
+- [Los argumentos a favor y en contra de la i18n basada en compiladores](https://intlayer.org/es/blog/compiler-vs-declarative-i18n)

package/blog/fr/is_intlayer_lighter_than_paraglide.md

@@ -0,0 +1,284 @@
+---
+createdAt: 2026-09-23
+updatedAt: 2026-09-23
+title: Intlayer est-il plus léger que Paraglide ?
+description: Paraglide semble presque gratuit dans les benchmarks i18n car son code est généré dans votre repo. Voici où se trouve réellement ce poids, pourquoi les lectures de locale par nœud vous coûtent des ressources, et comment le chargement dynamique d'Intlayer n'envoie qu'une seule locale au lieu de toutes.
+keywords:
+  - Paraglide
+  - Intlayer
+  - Internationalisation
+  - i18n
+  - Bundle size
+  - Tree shaking
+  - Benchmark
+  - Blog
+slugs:
+  - blog
+  - is-intlayer-lighter-than-paraglide
+author: aymericzip
+---
+
+# Intlayer est-il plus léger que Paraglide ?
+
+Oui.
+
+`Paraglide` a la réputation d'être la solution i18n la plus légère du marché, et à première vue le [benchmark](https://intlayer.org/fr/doc/benchmark/tanstack) semble le confirmer : la taille de sa bibliothèque est proche de zéro. Mais une taille de bibliothèque égale à zéro ne signifie pas zéro octet envoyé au client. Cela signifie simplement que les octets se trouvent à un endroit que cette métrique n'analyse pas.
+
+<TOC/>
+
+## Points clés à retenir
+
+**La taille de la bibliothèque est cachée, pas éliminée :**
+
+Paraglide génère son runtime et ses fonctions de messages directement dans votre codebase. Ce code est bel et bien envoyé au navigateur, mais il est comptabilisé comme étant _votre_ code, et non celui de la bibliothèque.
+
+**L'absence de provider n'est pas un gain gratuit :**
+
+Chaque appel `m.my_key()` résout la locale de manière autonome, en lisant le cookie ou le storage pour chaque nœud rendu, au lieu de la lire une seule fois depuis un contexte.
+
+**Aucun chargement dynamique :**
+
+Paraglide importe chaque locale d'un message dans votre bundle client. Intlayer, avec `importMode: 'dynamic'` ou `'fetch'`, ne charge que la locale actuellement affichée.
+
+**Le tree shaking n'est pas garanti :**
+
+Dans certains de nos benchmarks, le tree shaking annoncé par Paraglide n'a pas fonctionné. Vérifiez vos propres bundles.
+
+## Où passe le poids de Paraglide ?
+
+Dans les rapports de benchmark, la métrique « taille de la bibliothèque » mesure le provider et les hooks de chaque bibliothèque i18n dans un composant vide, avant l'ajout de tout contenu.
+
+| Bibliothèque (TanStack Start) | Taille lib (gz) | Taille lib (min) |
+| ----------------------------- | --------------- | ---------------- |
+| `@inlang/paraglide-js@2.15.1` | 1.8 KB          | 4.5 KB           |
+| `react-intlayer@9.5.1`        | 5.0 KB          | 15.2 KB          |
+
+Isolé de tout contexte, Paraglide semble gagner. Mais Paraglide est un compilateur : il lit vos fichiers `messages/*.json` et écrit un dossier `paraglide/` dans votre dépôt, contenant un fichier `runtime.js` (détection de locale, stratégies de cookies et de storage, localisation des URLs) ainsi qu'une fonction JavaScript par message.
+
+```bash
+src/paraglide/
+├── runtime.js      # détection de locale, stratégies, helpers d'URL
+├── server.js
+├── messages.js     # réexporte chaque message
+└── messages/
+    ├── _index.js
+    ├── en.js
+    └── fr.js
+```
+
+Puisque ce code réside dans votre dossier `src/` et que vous l'importez avec un chemin relatif, le bundler l'attribue à votre application, et non à un package tiers dans `node_modules`. La colonne de taille de bibliothèque n'affiche donc presque rien, alors que la même logique est toujours envoyée dans le bundle de votre page.
+
+Générer du code n'est pas une mauvaise idée en soi : le runtime généré n'inclut que la logique requise par votre configuration (stratégie de préfixe, cookie vs. local storage, etc.). Intlayer parvient au même résultat différemment, en injectant des variables d'environnement au moment du build afin que le bundler élimine les branches non utilisées par votre configuration. Les deux approches s'avèrent de 3 à 10 fois plus légères qu'`i18next` ou `next-intl`.
+
+La comparaison équitable ne repose donc pas sur la taille de la bibliothèque. Elle repose sur **le JavaScript réellement envoyé par page**.
+
+## Poids par page, mesuré
+
+Application TanStack Start, 10 pages, mesuré sur les routes `en` et `fr`, compressé avec gzip :
+
+| Configuration                      | JS page moy (gz) | Au-dessus de la base | Fuite de locale | Fuite autres pages |
+| ---------------------------------- | ---------------- | -------------------- | --------------- | ------------------ |
+| Base (sans i18n)                   | 111.0 KB         | -                    | 0.0%            | 0.0%               |
+| `paraglide` (toutes stratégies)    | 125.1 KB         | +14.1 KB             | 49.7%           | 0.0%               |
+| `intlayer` (`importMode: static`)  | 125.8 KB         | +14.8 KB             | 50.0%           | 0.0%               |
+| `intlayer` (`importMode: dynamic`) | **118.6 KB**     | **+7.6 KB**          | **0.0%**        | **0.0%**           |
+
+Next.js 16 App Router, même application :
+
+| Configuration    | JS page moy (gz) | Au-dessus de la base |
+| ---------------- | ---------------- | -------------------- |
+| Base (sans i18n) | 141.0 KB         | -                    |
+| `paraglide-next` | 155.3 KB         | +14.3 KB             |
+| `next-intlayer`  | **141.3 KB**     | **+0.3 KB**          |
+
+<I18nBenchmark framework="tanstack" vertical/>
+
+> Données complètes dans le [rapport de benchmark TanStack Start](https://intlayer.org/fr/doc/benchmark/tanstack) et le [rapport de benchmark Next.js](https://intlayer.org/fr/doc/benchmark/nextjs). Chaque bundle peut être inspecté dans le [dépôt du benchmark](https://github.com/intlayer-org/benchmark-i18n).
+
+Deux constats majeurs s'imposent :
+
+- En mode `static`, Intlayer envoie pratiquement le même contenu que Paraglide (125.8 KB contre 125.1 KB). C'est attendu : les deux incluent chaque locale des messages utilisés par une page.
+- Paraglide reste à 125.1 KB quelle que soit la stratégie, car il ne propose aucun mode dynamique. Chaque ligne du tableau ci-dessus correspond à la version statique.
+
+## L'absence de Provider : une fausse bonne idée
+
+Paraglide n'utilise aucun provider. Vous importez un message et vous l'appelez :
+
+```tsx fileName="Hero.tsx"
+import { m } from "../paraglide/messages.js";
+
+export const Hero = () => (
+  <section>
+    <h1>{m.hero_title()}</h1>
+    <p>{m.hero_description()}</p>
+    <button>{m.hero_cta()}</button>
+  </section>
+);
+```
+
+Pas de contexte, pas de wrapper, pas de hook. Cela semble plus simple. Pourtant, la locale doit bien être obtenue quelque part. Chaque fonction de message générée ressemble approximativement à ceci (version simplifiée) :
+
+```js fileName="paraglide/messages/_index.js"
+export const hero_title = (inputs = {}, options = {}) => {
+  const locale = options.locale ?? getLocale(); // résolu à chaque appel
+
+  if (locale === "en") return en.hero_title(inputs);
+  if (locale === "fr") return fr.hero_title(inputs);
+  // ...une branche par locale
+};
+```
+
+Et `getLocale()` parcourt l'ensemble des stratégies configurées (cookie, local storage, URL, locale de base) pour trouver la locale active. Chaque nœud de texte affiché (`<>{m.my_key()}</>`) exécute sa propre résolution de locale, ce qui implique de lire `document.cookie` dans le navigateur. Une page avec 200 chaînes traduites résout la locale 200 fois par rendu, puis à nouveau à chaque nouveau rendu.
+
+Une bibliothèque reposant sur un provider lit la locale **une seule fois**, la stocke dans un contexte (ou un signal, ou un store), et chaque nœud lit une valeur déjà présente en mémoire. Le provider coûte quelques centaines d'octets. S'en passer coûte des cycles CPU à chaque rendu, et les résultats du benchmark le montrent bien : les temps de chargement de page et de changement de langue de Paraglide sont systématiquement en retrait par rapport à Intlayer sur TanStack Start (22.1 ms contre 14.6 ms pour le chargement de page, 4.3 ms contre 3.2 ms pour la réactivité E2E).
+
+## Expérience Développeur
+
+La source de vérité de Paraglide repose sur des fichiers JSON, mais vous n'importez jamais ces JSON directement. Vous importez le fichier `.js` généré :
+
+<Tabs defaultTab="intlayer" group="techno">
+  <Tab label="Paraglide" value="paraglide">
+
+```json fileName="messages/en.json"
+{
+  "hero_title": "Ship your app in every language"
+}
+```
+
+```json fileName="messages/fr.json"
+{
+  "hero_title": "Publiez votre app dans toutes les langues"
+}
+```
+
+```tsx fileName="Hero.tsx"
+// Existe uniquement après régénération par le compilateur à partir du JSON
+import { m } from "../paraglide/messages.js";
+
+export const Hero = () => <h1>{m.hero_title()}</h1>;
+```
+
+  </Tab>
+  <Tab label="Intlayer" value="intlayer">
+
+```ts fileName="Hero.content.ts"
+import { t, type Dictionary } from "intlayer";
+
+export default {
+  key: "hero",
+  content: {
+    title: t({
+      fr: "Publiez votre app dans toutes les langues",
+      en: "Ship your app in every language",
+    }),
+  },
+} satisfies Dictionary;
+```
+
+```tsx fileName="Hero.tsx"
+import { useIntlayer } from "react-intlayer";
+
+export const Hero = () => {
+  const { title } = useIntlayer("hero");
+
+  return <h1>{title}</h1>;
+};
+```
+
+  </Tab>
+</Tabs>
+
+Cette boucle de travail a un coût :
+
+- Chaque modification apportée à un fichier JSON nécessite une régénération avant que l'importation ne soit résolue ou que les types ne soient mis à jour.
+- Le dossier généré `paraglide/` doit soit être commité, ce qui crée des conflits de fusion sur les fichiers générés à chaque PR modifiant du texte, soit être ignoré, ce qui impose une étape de génération avant chaque vérification de types, test ou job de CI.
+- Chaque chaîne devient un appel de fonction. Les constantes se transforment partout en `m.key()`, y compris là où une simple valeur suffirait.
+
+## Tree Shaking : vérifiez votre bundle
+
+La promesse principale de Paraglide est d'éliminer les messages non utilisés via le tree shaking, puisque chaque message est son propre export. Dans le benchmark Svelte + Vite, cela fonctionne comme prévu.
+
+Dans d'autres environnements, ce n'est pas le cas. Dans notre test sur [Next.js](https://intlayer.org/fr/doc/benchmark/nextjs), les pages Paraglide pèsent 14 KB de plus que l'application de base, là où `next-intlayer` n'ajoute que 0.3 KB. Des tests précédents sur TanStack Start ont également montré que des messages d'autres pages se retrouvaient inclus dans le bundle de la route.
+
+Le tree shaking dépend fortement de votre bundler (Turbopack, Rolldown, Rollup), de la manière dont les messages sont importés (`import { m }` vs. `import * as m`), et de l'analyse des effets de bord. Si vous choisissez Paraglide pour sa taille, ouvrez votre visualiseur de bundle et vérifiez son comportement réel dans votre application.
+
+## Pas de chargement dynamique
+
+Il s'agit d'une limite structurelle. Paraglide ne permet pas de charger une seule locale à la fois : chaque fonction de message importe statiquement l'implémentation de chaque langue, de sorte que toutes les langues finissent dans votre bundle client.
+
+Avec 2 langues, cela représente la moitié de votre payload de traduction gaspillée, ce qui correspond aux ~50% de fuite de locale mesurés plus haut. Avec 10 langues, c'est 90% de gaspillage. Avec 30 langues, 97%.
+
+Passer à un chargement dynamique ne résoudrait rien : avec une fonction par message, charger chaque fonction à la demande impliquerait des milliers de requêtes réseau.
+
+Intlayer vous laisse choisir, globalement ou par dictionnaire :
+
+```ts fileName="intlayer.config.ts"
+import { Locales, type IntlayerConfig } from "intlayer";
+
+const config: IntlayerConfig = {
+  internationalization: {
+    locales: [Locales.ENGLISH, Locales.FRENCH, Locales.SPANISH],
+    defaultLocale: Locales.ENGLISH,
+  },
+  dictionary: {
+    importMode: "dynamic", // 'static' | 'dynamic' | 'fetch'
+  },
+};
+
+export default config;
+```
+
+| `importMode` | Ce qui est envoyé au client                               | vs. Paraglide                        |
+| ------------ | --------------------------------------------------------- | ------------------------------------ |
+| `static`     | Toutes les locales des dictionnaires utilisés             | Contenu théoriquement identique      |
+| `dynamic`    | Seulement la locale active, chargée à la demande          | **N fois plus léger** avec N langues |
+| `fetch`      | Seulement la locale active, récupérée via l'API Live Sync | **N fois plus léger** avec N langues |
+
+Grâce à la [transformation au build](https://intlayer.org/fr/doc/concept/bundle-optimization) et `importMode: 'static'`, Intlayer charge, en théorie, exactement le même contenu que Paraglide. Avec `'dynamic'` ou `'fetch'`, il ne charge que ce dont la locale actuelle a besoin : pour une application disponible en N langues, le payload de traduction est divisé par N par rapport à Paraglide.
+
+## Quand Paraglide reste-t-il pertinent ?
+
+<AccordionGroup>
+<Accordion header="Svelte + Vite avec peu de langues">
+
+Si votre stack repose sur Svelte avec Vite et que vous ne gérez que deux ou trois langues, le tree shaking fonctionne comme prévu et la surcharge liée aux langues reste minime.
+
+</Accordion>
+<Accordion header="Workflow inlang existant">
+
+Si votre équipe utilise déjà l'écosystème inlang (Fink, Sherlock, plugins de format de message), Paraglide s'y intègre nativement.
+
+</Accordion>
+</AccordionGroup>
+
+## Testez sur votre application
+
+Mesurez le payload et les fuites de locales de votre application en production avec l'[i18n SEO Scanner](https://intlayer.org/i18n-seo-scanner) gratuit :
+
+<ClickToOpenIframe src="https://intlayer.org/i18n-seo-scanner" width="100%" height="600px" style="border:none;"/>
+
+Pour installer Intlayer :
+
+```bash packageManager="npm"
+npx intlayer init --interactive
+```
+
+```bash packageManager="pnpm"
+pnpm dlx intlayer init --interactive
+```
+
+```bash packageManager="yarn"
+yarn dlx intlayer init --interactive
+```
+
+```bash packageManager="bun"
+bunx intlayer init --interactive
+```
+
+## Pour aller plus loin
+
+- [Benchmark i18n TanStack Start](https://intlayer.org/fr/doc/benchmark/tanstack)
+- [Benchmark i18n Next.js](https://intlayer.org/fr/doc/benchmark/nextjs)
+- [Optimisation de bundle et `importMode`](https://intlayer.org/fr/doc/concept/bundle-optimization)
+- [Comment choisir une bibliothèque i18n pour React](https://intlayer.org/fr/blog/how-to-pick-react-i18n-library)
+- [Pourquoi choisir une internationalisation basée sur un compilateur](https://intlayer.org/fr/blog/compiler-vs-declarative-i18n)