@intlayer/docs 9.5.6 → 9.5.7

package/blog/es/vue-i18n_vs_intlayer.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2024-08-11
-updatedAt: 2025-08-23
+updatedAt: 2026-09-22
 title: vue-i18n vs Intlayer
 description: Comparación entre vue-i18n e Intlayer para la internacionalización (i18n) en aplicaciones Vue/Nuxt
 keywords:
@@ -20,6 +20,8 @@ author: aymericzip
 
 # vue-i18n VS Intlayer | Internacionalización (i18n) en Vue
 
+![Vue i18n library ecosystem](https://github.com/aymericzip/intlayer/blob/main/docs/assets/cloud_i18n_logo.webp?raw=true)
+
 Esta guía compara dos opciones populares de i18n para **Vue 3** (y **Nuxt**): **vue-i18n** e **Intlayer**.
 Nos enfocamos en las herramientas modernas de Vue (Vite, Composition API) y evaluamos:
 
@@ -31,6 +33,8 @@ Nos enfocamos en las herramientas modernas de Vue (Vite, Composition API) y eval
 6. **Experiencia del desarrollador (DX), herramientas y mantenimiento**
 7. **SEO y escalabilidad para proyectos grandes**
 
+<TOC/>
+
 > **resumen**: Ambos pueden localizar aplicaciones Vue. Si deseas **contenido con alcance por componente**, **tipos estrictos en TypeScript**, **verificaciones de claves faltantes en tiempo de compilación**, **diccionarios optimizados por tree-shaking**, y **helpers integrados para router/SEO** además de **Editor Visual y traducciones asistidas por IA**, **Intlayer** es la opción más completa y moderna.
 
 ## Posicionamiento a alto nivel
@@ -38,6 +42,30 @@ Nos enfocamos en las herramientas modernas de Vue (Vite, Composition API) y eval
 - **vue-i18n** - La biblioteca de i18n por excelencia para Vue. Formateo flexible de mensajes (estilo ICU), bloques SFC `<i18n>` para mensajes locales y un gran ecosistema. La seguridad y el mantenimiento a gran escala dependen principalmente de ti.
 - **Intlayer** - Modelo de contenido centrado en componentes para Vue/Vite/Nuxt con **tipado estricto en TS**, **verificaciones en tiempo de compilación**, **tree-shaking**, **helpers para router y SEO**, **Editor Visual/CMS** opcional y **traducciones asistidas por IA**.
 
+## Lo que cuesta en tiempo de compilación
+
+Antes de las tablas de características, la parte medida. [Benchmark Bloom](https://github.com/intlayer-org/benchmark-bloom) compila la misma aplicación Vite + Vue 3 (10 páginas, 10 idiomas) con cada biblioteca y registra lo que descarga el navegador:
+
+<I18nBenchmark framework="vite-vue" vertical/>
+
+| Setup                | Lib size (gz) | Page JS avg (gz) | Page leak | Component avg (gz) |
+| -------------------- | ------------: | ---------------: | --------: | -----------------: |
+| **base** (no i18n)   |        0.0 KB |          41.3 KB |         - |             1.1 KB |
+| `vue-i18n`           |       24.3 KB |         134.9 KB |     90.0% |           196.0 KB |
+| `@intlayer/vue-i18n` |        7.9 KB |          47.0 KB |      0.0% |             8.4 KB |
+| **`vue-intlayer`**   |    **3.9 KB** |      **57.1 KB** |  **0.0%** |         **7.7 KB** |
+
+El runtime de `vue-i18n` por sí solo pesa **6 veces** el de Intlayer, cada página transporta un **90% de cadenas de páginas ajenas**, y un componente compilado de forma aislada arrastra **196 KB** porque `useI18n()` lo vincula al árbol global de mensajes. La prueba completa, con tiempos de reactividad y carga de página, se encuentra en el [benchmark vue-i18n vs Intlayer](https://intlayer.org/es/blog/vue-i18n-vs-intlayer-benchmark).
+
+<ClickToOpenIframe
+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;"
+/>
+
+> Tabla completa en el [informe de benchmark de Vue](https://intlayer.org/es/doc/benchmark/vue).
+
 ## Comparación de características lado a lado (enfocado en Vue)
 
 | Característica                                   | **Intlayer**                                                                      | **vue-i18n**                                                                                    |
@@ -63,59 +91,74 @@ Nos enfocamos en las herramientas modernas de Vue (Vite, Composition API) y eval
 
 ## Comparación en profundidad
 
-### 1) Arquitectura y escalabilidad
+<AccordionGroup>
+<Accordion header="1) Arquitectura y escalabilidad">
 
-- **vue-i18n**: Las configuraciones comunes usan **catálogos centralizados** por idioma (opcionalmente divididos en archivos/espacios de nombres). Los bloques `<i18n>` en SFC permiten mensajes locales, pero los equipos a menudo vuelven a catálogos compartidos a medida que los proyectos crecen.
+- **vue-i18n**: Las configuraciones comunes usan **catálogos centralizados** por idioma (opcionalmente divididos en archivos/espacios de nombres). Los bloques `<i18n>` en SFC permiten mensajes locales, pero los equipos a menudo vuelven a catálogos compartidos a medida que los proyectos crecen. Consulta [i18n por componente frente a centralizado](https://intlayer.org/es/blog/per-component-vs-centralized-i18n).
 - **Intlayer**: Promueve **diccionarios por componente** almacenados junto al componente al que sirven. Esto reduce conflictos entre equipos, mantiene el contenido accesible y limita naturalmente la deriva/las claves no usadas.
 
 **Por qué es importante:** En aplicaciones Vue grandes o sistemas de diseño, el **contenido modular** escala mejor que los catálogos monolíticos.
 
-### 2) TypeScript y seguridad
+</Accordion>
+<Accordion header="2) TypeScript y seguridad">
 
 - **vue-i18n**: Buen soporte para TS; la **tipificación estricta de claves** generalmente requiere esquemas/generics personalizados y convenciones cuidadosas.
 - **Intlayer**: **Genera tipos estrictos** a partir de tu contenido, proporcionando **autocompletado en el IDE** y **errores en tiempo de compilación** por errores tipográficos o claves faltantes.
 
 **Por qué es importante:** La tipificación fuerte detecta problemas **antes** de la ejecución.
 
-### 3) Manejo de traducciones faltantes
+</Accordion>
+<Accordion header="3) Manejo de traducciones faltantes">
 
-- **vue-i18n**: Advertencias y soluciones alternativas en **tiempo de ejecución** (por ejemplo, usar idioma o clave de reserva).
-- **Intlayer**: Detección en **tiempo de compilación** con advertencias/errores a través de idiomas y claves.
+- **vue-i18n**: Advertencias y soluciones alternativas en **tiempo de ejecución** (por ejemplo, usar idioma o clave de reserva). Consulta [detección de traducciones faltantes](https://intlayer.org/es/blog/detecting-missing-translations).
+- **Intlayer**: Detección en **tiempo de compilación** con advertencias/errores a través de idiomas y claves., más `npx intlayer test` en CI.
 
 **Por qué es importante:** La aplicación de reglas en tiempo de compilación mantiene la interfaz de producción limpia y consistente.
 
-### 4) Estrategia de rutas y URLs (Vue Router/Nuxt)
+</Accordion>
+<Accordion header="4) Estrategia de rutas y URLs (Vue Router/Nuxt)">
 
-- **Ambos** pueden trabajar con rutas localizadas.
+- **Ambos** pueden trabajar con rutas localizadas. Consulta la [guía de hreflang](https://intlayer.org/es/blog/hreflang-guide-multilingual-seo).
 - **Intlayer** proporciona ayudas para **generar rutas localizadas**, **gestionar prefijos de locales** y emitir **`<link rel="alternate" hreflang>`** para SEO. Con Nuxt, complementa el enrutamiento del framework.
 
 **Por qué es importante:** Menos capas personalizadas y un **SEO más limpio** entre locales.
 
-### 5) Rendimiento y comportamiento de carga
+</Accordion>
+<Accordion header="5) Rendimiento y comportamiento de carga">
 
-- **vue-i18n**: Soporta mensajes de locales asíncronos; evitar la sobrecarga de paquetes depende de ti (divide los catálogos con cuidado).
+- **vue-i18n**: Soporta mensajes de locales asíncronos; evitar la sobrecarga de paquetes depende de ti (divide los catálogos con cuidado). El benchmark anterior pone números a esto: 134.9 KB frente a 57.1 KB por página.
 - **Intlayer**: Realiza **tree-shaking** en la compilación y **carga perezosa por diccionario/locale**. El contenido no usado no se incluye.
 
 **Por qué es importante:** Paquetes más pequeños y un inicio más rápido para aplicaciones Vue multilingües.
 
-### 6) Experiencia del desarrollador y herramientas
+</Accordion>
+<Accordion header="6) Experiencia del desarrollador y herramientas">
 
 - **vue-i18n**: Documentación y comunidad maduras; normalmente dependerás de **plataformas de localización externas** para los flujos editoriales.
-- **Intlayer**: Incluye un **Editor Visual gratuito**, un **CMS** opcional (compatible con Git o externalizado), una **extensión para VSCode**, utilidades **CLI/CI**, y **traducciones asistidas por IA** usando tus propias claves de proveedor.
+- **Intlayer**: Incluye un **Editor Visual gratuito**, un **CMS** opcional (compatible con Git o externalizado), una **extensión para VSCode**, utilidades **CLI/CI**, y **traducciones asistidas por IA** usando tus propias claves de proveedor., un **servidor MCP**
 
 **Por qué importa:** Menores costos operativos y un ciclo de desarrollo–contenido más corto.
 
-### 7) SEO, SSR y SSG
+</Accordion>
+<Accordion header="7) SEO, SSR y SSG">
 
-- **Ambos** funcionan con Vue SSR y Nuxt.
+- **Ambos** funcionan con Vue SSR y Nuxt. Consulta [internacionalización y SEO](https://intlayer.org/es/blog/SEO-and-i18n).
 - **Intlayer**: Añade **ayudas SEO** (sitemaps/metadata/`hreflang`) que son independientes del framework y funcionan bien con las compilaciones de Vue/Nuxt.
 
 **Por qué importa:** SEO internacional sin configuraciones personalizadas.
 
+</Accordion>
+</AccordionGroup>
+
 ## ¿Por qué Intlayer? (Problema y enfoque)
 
+![Centralized catalogs versus per-component dictionaries](https://github.com/aymericzip/intlayer/blob/main/docs/assets/project_stucture_18n_vs_intlayer.png?raw=true)
+
 La mayoría de los stacks i18n (incluyendo **vue-i18n**) comienzan desde **catálogos centralizados**:
 
+<Tabs defaultTab="per-locale" group="catalog">
+<Tab label="Un archivo por idioma" value="per-locale">
+
 ```bash
 .
 ├── locales
@@ -127,7 +170,8 @@ La mayoría de los stacks i18n (incluyendo **vue-i18n**) comienzan desde **catá
         └── MyComponent.vue
 ```
 
-O con carpetas por idioma:
+</Tab>
+<Tab label="Una carpeta por idioma" value="per-folder">
 
 ```bash
 .
@@ -146,6 +190,34 @@ O con carpetas por idioma:
         └── MyComponent.vue
 ```
 
+</Tab>
+</Tabs>
+
+Esa carpeta sigue creciendo, un namespace por funcionalidad, en cada idioma:
+
+```txt
+locales
+├── EN
+│   ├── blog.json
+│   ├── about.json
+│   ├── auth.json
+│   ├── blog.json
+│   ├── cart.json
+│   ├── categories.json
+│   ├── contact.json
+│   ├── dashboard.json
+│   ├── errors.json
+│   ├── faq.json
+│   ├── footer.json
+│   ├── form.json
+│   ├── home.json
+│   ├── language.json
+│   ├── navbar.json
+│   ├── ... 65 files
+│   └── validation.json
+└── ES
+```
+
 Esto a menudo ralentiza el desarrollo a medida que las aplicaciones crecen:
 
 1. **Para un nuevo componente** creas/editas catálogos remotos, configuras espacios de nombres y traduces (a menudo mediante copiar/pegar manual desde herramientas de IA).
@@ -161,7 +233,33 @@ Esto a menudo ralentiza el desarrollo a medida que las aplicaciones crecen:
         └── MyComponent.vue
 ```
 
-**Declaración de contenido** (por componente):
+<Tabs defaultTab="intlayer" group="techno">
+<Tab label="vue-i18n" value="vue-i18n">
+
+```json fileName="./locales/en.json"
+{
+  "componentExample": {
+    "greeting": "Hello World"
+  }
+}
+```
+
+```vue fileName="./components/MyComponent.vue"
+<script setup lang="ts">
+import { useI18n } from "vue-i18n";
+
+const { t } = useI18n();
+</script>
+
+<template>
+  <span>{{ t("componentExample.greeting") }}</span>
+</template>
+```
+
+Cada archivo de idioma debe editarse a mano, y la clave es una simple cadena de texto: una errata se muestra como `componentExample.greting` en producción.
+
+</Tab>
+<Tab label="Intlayer" value="intlayer">
 
 ```ts fileName="./components/MyComponent/myComponent.content.ts"
 import { t, type Dictionary } from "intlayer";
@@ -171,8 +269,8 @@ const componentExampleContent = {
   content: {
     greeting: t({
       en: "Hello World",
-      es: "Hola Mundo",
       fr: "Bonjour le monde",
+      es: "Hola Mundo",
     }),
   },
 } satisfies Dictionary;
@@ -180,11 +278,10 @@ const componentExampleContent = {
 export default componentExampleContent;
 ```
 
-**Uso en Vue** (API de composición):
-
 ```vue fileName="./components/MyComponent/MyComponent.vue"
 <script setup lang="ts">
-import { useIntlayer } from "vue-intlayer"; // Integración con Vue
+import { useIntlayer } from "vue-intlayer"; // Vue integration
+
 const { greeting } = useIntlayer("component-example");
 </script>
 
@@ -193,6 +290,11 @@ const { greeting } = useIntlayer("component-example");
 </template>
 ```
 
+Todos los idiomas se encuentran en un único archivo tipado junto al componente.
+
+</Tab>
+</Tabs>
+
 Este enfoque:
 
 - **Acelera el desarrollo** (declara una vez; el IDE/IA autocompleta).
@@ -220,22 +322,71 @@ Este enfoque:
 
 ## ¿Cuándo elegir cuál?
 
-- **Elige vue-i18n** si quieres el **enfoque estándar de Vue**, te sientes cómodo gestionando catálogos/espacios de nombres tú mismo, y tu aplicación es de **tamaño pequeño a mediano** (o ya dependes de Nuxt i18n).
-- **Elige Intlayer** si valoras el **contenido con alcance por componente**, **TypeScript estricto**, **garantías en tiempo de compilación**, **tree-shaking**, y herramientas integradas para enrutamiento/SEO/editor-especialmente para **códigos grandes y modulares en Vue/Nuxt**.
+<AccordionGroup>
+<Accordion header="Elegir vue-i18n">
+
+Deseas el **enfoque estándar de Vue**, te sientes cómodo gestionando catálogos y namespaces tú mismo, y tu aplicación es de **tamaño pequeño a mediano** (o ya dependes de Nuxt i18n). Los bloques SFC `<i18n>` y `setLocaleMessage()` en runtime son características que Intlayer deliberadamente no replica.
+
+</Accordion>
+<Accordion header="Elegir Intlayer">
+
+Valoras el **contenido acotado al componente**, **TypeScript estricto**, **garantías en tiempo de compilación**, **tree-shaking** y herramientas completas para enrutamiento, SEO y edición, especialmente para **bases de código modulares grandes en Vue/Nuxt** y sistemas de diseño. Comienza con [Intlayer con Vue](https://intlayer.org/es/doc/environment/vite-and-vue) o [con Nuxt](https://intlayer.org/es/doc/environment/nuxt-and-vue).
+
+</Accordion>
+<Accordion header="Elegir @intlayer/vue-i18n">
+
+Estás en `vue-i18n` hoy y quieres las ganancias de bundle sin editar ningún archivo `.vue`. El [adaptador de compatibilidad](https://intlayer.org/es/doc/compatibility/vue-i18n) mantiene `createI18n`, `useI18n`, `t()`, `d()`, `n()`, `$t` y `v-t`, y los sirve desde diccionarios compilados. Medido lado a lado en [vue-i18n vs @intlayer/vue-i18n](https://intlayer.org/es/blog/vue-i18n-vs-intlayer-vue-i18n).
+
+</Accordion>
+</AccordionGroup>
 
 ## Interoperabilidad con vue-i18n
 
 `intlayer` también puede ayudarte a gestionar tus namespaces de `vue-i18n`.
 
-Usando `intlayer`, puedes declarar tu contenido en el formato de tu librería i18n favorita, e intlayer generará tus namespaces en la ubicación de tu elección (ejemplo: `/messages/{{locale}}/{{namespace}}.json`).
+Usando `intlayer`, puedes declarar tu contenido en el formato de tu librería i18n favorita, e intlayer generará tus namespaces en la ubicación de tu elección (ejemplo: `/messages/{{locale}}/{{namespace}}.json`). Consulta la [documentación de compatibilidad con vue-i18n](https://intlayer.org/es/doc/compatibility/vue-i18n) y el [adaptador Nuxt i18n](https://intlayer.org/es/doc/compatibility/nuxtjs-i18n).
+
+## Preguntas frecuentes
+
+<FAQ>
+
+<Question title="¿Es Intlayer un sustituto de vue-i18n o una capa superior?">
+
+Ambos, según cómo lo adoptes. `vue-intlayer` es un runtime nativo con su propio composable `useIntlayer()`. `@intlayer/vue-i18n` es un adaptador de compatibilidad que mantiene la API de `vue-i18n` y cambia a qué está vinculada, para que puedas migrar sin tocar componentes y avanzar archivo por archivo después.
+
+</Question>
+
+<Question title="¿Qué ocurre con mis bloques SFC <i18n>?">
+
+El adaptador no los lee. Mueve esos mensajes a tu JSON de idioma, o a un archivo `.content.ts` junto al componente, que es la misma idea con tipos generados. Es la única función de `vue-i18n` que no se traslada.
 
-## Notas prácticas para la migración (vue-i18n → Intlayer)
+</Question>
 
-- **Comience por función**: Mueva una ruta/vista/componente a la vez a los diccionarios locales de Intlayer.
-- **Puente durante la migración**: Mantenga los catálogos de vue-i18n en paralelo; reemplace gradualmente las búsquedas.
-- **Active verificaciones estrictas**: Permita que la detección en tiempo de compilación identifique temprano claves/idiomas faltantes.
-- **Adopte los ayudantes de router/SEO**: Estandarice la detección de idioma y las etiquetas `hreflang`.
-- **Mida los paquetes**: Espere **reducciones en el tamaño del paquete** a medida que se excluye contenido no utilizado.
+<Question title="¿Funciona Intlayer con Nuxt?">
+
+Sí. [Intlayer con Nuxt](https://intlayer.org/es/doc/environment/nuxt-and-vue) cubre enrutamiento multilingüe, middleware de detección de idioma y generación de sitemaps. Si utilizas `@nuxtjs/i18n`, el [adaptador de compatibilidad Nuxt i18n](https://intlayer.org/es/doc/compatibility/nuxtjs-i18n) es la ruta de migración.
+
+</Question>
+
+<Question title="¿Puedo mantener mis locales/{locale}.json como fuente de verdad?">
+
+Sí. El [plugin de sincronización JSON](https://intlayer.org/es/doc/compatibility/vue-i18n) los lee con el dialecto de `vue-i18n` (`{name}`, `{0}`, plurales en tubería `"car | cars"`) y vuelve a escribir las traducciones cuando la CLI o el CMS los actualiza.
+
+</Question>
+
+<Question title="¿Funciona ICU con Intlayer en Vue?">
+
+El soporte nativo para ICU está en desarrollo. El adaptador `@intlayer/vue-i18n` resuelve la sintaxis de mensajes propia de `vue-i18n`, incluidos los plurales en barra vertical y la interpolación nombrada y de listas. Para el modelo de pluralización de Intlayer, consulta el [contenido de enumeración](https://intlayer.org/es/doc/concept/content/enumeration).
+
+</Question>
+
+</FAQ>
+
+## GitHub STARs
+
+Las estrellas de GitHub son un fuerte indicador de la popularidad de un proyecto, la confianza de la comunidad y la relevancia a largo plazo. Si bien no son una medida directa de la calidad técnica, reflejan cuántos desarrolladores encuentran útil el proyecto, siguen su progreso y es probable que lo adopten. Para estimar el valor de un proyecto, las estrellas ayudan a comparar la tracción entre alternativas y brindan información sobre el crecimiento del ecosistema.
+
+[![Star History Chart](https://api.star-history.com/chart?repos=intlify%2Fvue-i18n%2Caymericzip%2Fintlayer&type=date&legend=top-left)](https://star-history.com/#intlify/vue-i18n&aymericzip/intlayer)
 
 ## Conclusión
 
@@ -244,4 +395,15 @@ Tanto **vue-i18n** como **Intlayer** localizan bien las aplicaciones Vue. La dif
 - Con **Intlayer**, el **contenido modular**, **TS estricto**, **seguridad en tiempo de compilación**, **paquetes optimizados por árbol de dependencias** y las **herramientas para router/SEO/editor** vienen **listos para usar**.
 - Si tu equipo prioriza la **mantenibilidad y velocidad** en una aplicación Vue/Nuxt multilingüe y basada en componentes, Intlayer ofrece la experiencia **más completa** hoy en día.
 
-Consulta el documento ['¿Por qué Intlayer?'](https://intlayer.org/doc/why) para más detalles.
+## Lecturas adicionales
+
+- [vue-i18n vs Intlayer benchmark](https://intlayer.org/es/blog/vue-i18n-vs-intlayer-benchmark), la prueba medida detrás de la tabla anterior
+- [vue-i18n vs @intlayer/vue-i18n](https://intlayer.org/es/blog/vue-i18n-vs-intlayer-vue-i18n), el adaptador en la misma aplicación
+- [Is vue-i18n outdated?](https://intlayer.org/es/blog/is-vue-i18n-outdated)
+- [How to pick a Vue i18n library](https://intlayer.org/es/blog/how-to-pick-vue-i18n-library)
+- [Using Intlayer with vue-i18n](https://intlayer.org/es/blog/intlayer-with-vue-i18n)
+- [Vue benchmark report](https://intlayer.org/es/doc/benchmark/vue)
+- [Migration guide: vue-i18n to Intlayer](https://intlayer.org/es/doc/migration/vue-i18n)
+- [Bundle optimization](https://intlayer.org/es/doc/concept/bundle-optimization) and [the Intlayer compiler](https://intlayer.org/es/doc/compiler)
+
+Refer to ['Why Intlayer?' doc](https://intlayer.org/es/doc/why) for more details.

package/blog/fr/i18next_vs_intlayer-i18next.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2026-09-13
-updatedAt: 2026-09-13
+updatedAt: 2026-09-22
 title: "i18next vs @intlayer/i18next : Même API, Bundle Différent"
 description: Ce qui change lorsqu'une application React ou Next.js conserve ses appels à i18next, react-i18next et next-i18next mais les exécute via les adaptateurs @intlayer/i18next. JavaScript par page, taille des composants, fuite de chaînes et hydratation mesurés sur le même code, ainsi que ce que les adaptateurs conservent, ignorent et ne peuvent pas remplacer.
 keywords:
@@ -28,6 +28,8 @@ author: aymericzip
 
 # i18next VS @intlayer/i18next | Même API, Bundle Différent
 
+![i18next VS Intlayer](https://github.com/aymericzip/intlayer/blob/main/docs/assets/i18next-next-intl-intlayer.webp?raw=true)
+
 `@intlayer/i18next`, `@intlayer/react-i18next` et `@intlayer/next-i18next` sont des adaptateurs de compatibilité. Ils exposent l'API `i18next` que votre code utilise déjà (`useTranslation`, `t()`, `<Trans>`, `i18n.changeLanguage()`, `getFixedT`, `serverSideTranslations`...) et la distribuent à partir de dictionnaires compilés par Intlayer. Les composants ne changent pas. Le runtime sous-jacent, lui, change.
 
 Cet article mesure ce remplacement sur la même application Next.js, construite une fois avec `next-i18next` et une fois avec `@intlayer/next-i18next`. Les chiffres proviennent de [Benchmark Bloom](https://github.com/intlayer-org/benchmark-bloom). Pour comparer `i18next` et Intlayer en tant que bibliothèques distinctes, consultez [i18next vs Intlayer](https://intlayer.org/fr/blog/i18next-vs-intlayer). Celui-ci se concentre sur ce que l'adaptateur transforme lorsque vous conservez votre code tel quel.
@@ -109,6 +111,10 @@ Pour chaque build, la suite enregistre :
 
 ### Résultats sur Next.js
 
+Sélectionnez les métriques et les bibliothèques qui vous intéressent :
+
+<I18nBenchmark framework="nextjs" vertical/>
+
 | Configuration                | Stratégie      | Taille lib (gz) | JS page moy (gz) | Fuite locale | Fuite page | Composant moy (gz) | Réactivité E2E | Hydratation |
 | ---------------------------- | -------------- | --------------: | ---------------: | -----------: | ---------: | -----------------: | -------------: | ----------: |
 | **base** (sans i18n)         | -              |          0.0 Ko |         141.0 Ko |         0.0% |       0.0% |             0.9 Ko |        13.4 ms |     11.8 ms |
@@ -129,10 +135,21 @@ Pour chaque build, la suite enregistre :
 - **Hydratation et basculement plus rapides.** L'hydratation passe de 15.6 ms à **11.3 ms** (et de 27.7 ms dans la configuration `dynamic`, où l'appel backend se situe sur le chemin critique). Le basculement de locale passe de 15-16 ms à **11-12 ms**.
 - **L'adaptateur n'est pas le runtime natif.** `next-intlayer` atteint **141.3 Ko**, soit +0.3 Ko par rapport à l'application de base. L'adaptateur supporte la surface d'API de `i18next` (dialecte d'interpolation, résolution des pluriels et contextes, analyse des balises `<Trans>`) en surcouche du cœur d'Intlayer : 9.4 Ko et +9.4 Ko par page par rapport au natif. Il constitue une passerelle, non une fin en soi.
 
+<ClickToOpenIframe
+src="https://intlayer.org/markdown?url=https%3A%2F%2Fraw.githubusercontent.com%2Fintlayer-org%2Fbenchmark-i18n%2Fmain%2Freport%2Fscripts%2Fsummarize-nextjs.md"
+width="100%"
+height="600px"
+style="border:none;"
+/>
+
+> Tableau complet, chaque bibliothèque et chaque stratégie, dans le [rapport de benchmark Next.js](https://intlayer.org/fr/doc/benchmark/nextjs).
+
 > L'adaptateur `react-i18next` sur Vite / TanStack Start n'a pas été inclus dans ce cycle de test. La référence pour `react-i18next` sur TanStack Start se trouve dans [i18next vs Intlayer](https://intlayer.org/fr/blog/i18next-vs-intlayer) : 127-184 Ko par page et 123-185 ms de temps de basculement de locale quand le backend est différé.
 
 ## Pourquoi ces écarts de métriques
 
+![The Intlayer compiler extracts content from components](https://github.com/aymericzip/intlayer/blob/main/docs/assets/compiler.webp?raw=true)
+
 Rien n'a changé dans le dossier `components/` : les gains proviennent donc exclusivement de la cible à laquelle `useTranslation` est relié.
 
 **Avec `i18next`**, la liaison s'établit avec l'instance globale. Tout ce qui y a été chargé (toutes les locales en `static`, l'ensemble du namespace de la locale active en `dynamic`) est accessible depuis chaque composant appelant `useTranslation()`. Le bundler ne peut pas découper plus finement que ce que l'instance retient, et le runtime ne peut pas anticiper les clés demandées au rendu.
@@ -149,6 +166,10 @@ Rien n'a changé dans le dossier `components/` : les gains proviennent donc excl
     └── About.tsx                     # useTranslation(); t("about.title")
 ```
 
+Tout ce que l'instance contient est expédié sur chaque page, et le gaspillage croît sur deux axes, les pages et les locales :
+
+![Theoretical content leakage by architecture](https://github.com/aymericzip/intlayer/blob/main/docs/assets/theorical_content_leakage.webp?raw=true)
+
 **Avec `@intlayer/next-i18next`**, la liaison s'opère directement avec le dictionnaire. `syncJSON` convertit chaque fichier de namespace en dictionnaire ; la passe d'optimisation transmet au composant le dictionnaire correspondant sous forme d'un import que le bundler peut tracer et séparer par page et par locale.
 
 ```bash
@@ -297,26 +318,112 @@ export default defineConfig({
 
 ## Limites à connaître avant de démarrer
 
-- **Backends et détecteurs sont inertes.** `i18n.use(HttpBackend)` exécute le `init` du plugin et rien de plus. Si votre application dépendait de traductions rapatriées depuis un CMS au moment de la requête, ce flux n'existe plus ; utilisez le CMS d'Intlayer ou les commandes `intlayer pull` / `push`.
-- **`resources` est ignoré, non fusionné.** Contrairement à certains adaptateurs, `@intlayer/i18next` n'utilise pas `resources` inliné comme solution de repli. Chaque clé doit exister dans les dictionnaires synchronisés, ce que valide `intlayer test`.
-- **L'App Router nécessite la retouche du provider.** Un seul fichier, présenté ci-dessus. Le Pages Router avec `appWithTranslation` ne nécessite aucun ajustement.
-- **`next-i18next.config.js` n'est pas lu.** `localePath`, `fallbackLng`, `reloadOnPrerender` et équivalents n'ont pas d'effet direct ; les locales et le repli sont gérés dans `intlayer.config.ts`.
-- **L'adaptateur a un coût résiduel.** 9.4 Ko de runtime et +9.4 Ko par page par rapport à `next-intlayer`. Lorsque tous vos composants seront passés à `useIntlayer`, retirez-le.
+<AccordionGroup>
+<Accordion header="Les backends et détecteurs sont inertes">
+
+`i18n.use(HttpBackend)` appelle l'init du plugin et rien d'autre. Si votre application dépendait de la récupération de traductions depuis un CMS au runtime, ce flux disparaît ; utilisez le [CMS d'Intlayer](https://intlayer.org/fr/doc/concept/cms) ou les commandes `intlayer pull` / `push` à la place. La détection de locale devient la configuration de routage d'Intlayer (préfixe d'URL, cookie, en-tête).
+
+</Accordion>
+<Accordion header="resources est ignoré, pas fusionné">
+
+Contrairement à certains autres adaptateurs, `@intlayer/i18next` n'utilise pas les `resources` inline comme solution de repli. Chaque clé doit exister dans les dictionnaires synchronisés, ce que vérifie `intlayer test`.
+
+</Accordion>
+<Accordion header="L'App Router nécessite la modification du provider">
+
+Un seul fichier, montré ci-dessus. Le Pages Router avec `appWithTranslation` ne nécessite rien.
+
+</Accordion>
+<Accordion header="next-i18next.config.js n'est pas lu">
+
+`localePath`, `fallbackLng`, `reloadOnPrerender` et autres n'ont aucun équivalent ; les locales et le fallback proviennent de `intlayer.config.ts`.
+
+</Accordion>
+<Accordion header="L'adaptateur n'est pas gratuit">
+
+9.4 KB de runtime et +9.4 KB par page par rapport à `next-intlayer`. Une fois que chaque composant a migré vers `useIntlayer`, supprimez-le.
+
+</Accordion>
+</AccordionGroup>
 
 ## Quand choisir quelle solution ?
 
-- **Restez sur `i18next`** si votre application nécessite impérativement des backends au runtime (traductions servies par un CMS à la volée), l'écosystème spécifique de plugins, ou une cible hors React non couverte par les adaptateurs.
-- **Optez pour `@intlayer/*`** si vous utilisez `react-i18next` / `next-i18next` et souhaitez récupérer 68 Ko, obtenir des composants 8x plus légers, 0% de fuite, des clés typées et des contrôles en CI sans devoir tout réécrire. C'est le point d'entrée idéal pour une codebase `i18next` existante.
-- **Passez au natif (`next-intlayer` / `react-intlayer`)** pour les nouveaux projets ou une fois l'adaptateur assimilé. C'est la formule la plus légère (5.5 Ko, +0.3 Ko par page) qui débloque les Server Components synchrones et les fichiers de contenu `.content.ts` par composant.
+<AccordionGroup>
+<Accordion header="Rester sur i18next">
+
+Votre application dépend de backends au runtime (traductions servies par un CMS au moment de la requête), de l'écosystème de plugins, ou d'une cible non-React non couverte par les adaptateurs.
+
+</Accordion>
+<Accordion header="Utiliser @intlayer/*">
+
+Vous utilisez `react-i18next` / `next-i18next` et souhaitez économiser 68 KB, avoir des composants 8x plus petits, 0% de fuite, des clés typées et des vérifications CI sans réécriture. C'est le point d'entrée pour une codebase `i18next` existante.
+
+</Accordion>
+<Accordion header="Passer en natif (next-intlayer / react-intlayer)">
+
+Pour les nouveaux projets, ou une fois que l'adaptateur a fait son travail. Il possède le runtime le plus léger (5.5 KB, +0.3 KB par page) et débloque les Server Components synchrones et les fichiers `.content.ts` par composant. Commencez avec [Intlayer avec Next.js](https://intlayer.org/fr/doc/environment/nextjs) ou [avec Vite et React](https://intlayer.org/fr/doc/environment/vite-and-react).
+
+</Accordion>
+</AccordionGroup>
+
+## FAQ
+
+<FAQ>
+
+<Question title="D'où viennent les 68 KB ?">
+
+De `resources: { en, fr, ... }`. La configuration naive de `next-i18next` importe le JSON de chaque locale dans `init()`, de sorte que chaque page transporte chaque namespace dans chaque langue : **218.5 KB** par page. L'adaptateur n'embarque jamais ce bloc ; il fournit à chaque composant le dictionnaire qu'il nomme, dans la locale active.
+
+</Question>
+
+<Question title="Mes composants <Trans> continuent-ils de fonctionner ?">
+
+Oui, avec `components`, les balises numérotées `<1>...</1>` et les `values`. De même pour `{{interpolation}}`, l'imbrication `$t(key)`, les pluriels `key_one` / `key_other` (évalués avec `Intl.PluralRules`), les suffixes de contexte et `returnObjects`.
+
+</Question>
+
+<Question title="Que faire si j'utilise un seul fichier translation.json par locale ?">
+
+Définissez `splitKeys: false` dans le plugin `syncJSON`. L'ensemble du fichier reste un dictionnaire unique et un simple appel à `useTranslation()` continue de s'y résoudre.
+
+</Question>
+
+<Question title="Est-ce la même chose que de migrer vers Intlayer ?">
+
+Non, c'est la passerelle. L'adaptateur conserve l'API `i18next` et coûte 9.4 KB de runtime ; `next-intlayer` natif coûte 5.5 KB et apporte les Server Components synchrones et les fichiers `.content.ts` colocalisés. Vous pouvez migrer composant par composant, car les dictionnaires JSON et `.content.ts` coexistent.
+
+</Question>
+
+<Question title="Les traducteurs peuvent-ils continuer à travailler comme aujourd'hui ?">
+
+Oui. `locales/{lng}/{ns}.json` reste la source de vérité : `syncJSON` le lit avec le dialecte i18next et réécrit les traductions lorsque la CLI ou le CMS les met à jour.
+
+</Question>
+
+</FAQ>
 
 ## Comparatifs associés
 
-- [i18next vs Intlayer](https://intlayer.org/fr/blog/i18next-vs-intlayer) (comparatif des bibliothèques, même benchmark)
-- [next-intl vs @intlayer/next-intl](https://intlayer.org/fr/blog/next-intl-vs-intlayer-next-intl) (même série d'adaptateurs)
-- [Lingui vs @intlayer/lingui](https://intlayer.org/fr/blog/lingui-vs-intlayer-lingui) (même série d'adaptateurs)
-- [vue-i18n vs @intlayer/vue-i18n](https://intlayer.org/fr/blog/vue-i18n-vs-intlayer-vue-i18n) (même série d'adaptateurs)
-- Guides de migration : [i18next](https://intlayer.org/fr/doc/migration/i18next), [react-i18next](https://intlayer.org/fr/doc/migration/react-i18next), [next-i18next](https://intlayer.org/fr/doc/migration/next-i18next)
-- Références des adaptateurs : [i18next](https://intlayer.org/fr/doc/compatibility/i18next), [react-i18next](https://intlayer.org/fr/doc/compatibility/react-i18next), [next-i18next](https://intlayer.org/fr/doc/compatibility/next-i18next)
+Même série d'adaptateurs :
+
+- [next-intl vs @intlayer/next-intl](https://intlayer.org/fr/blog/next-intl-vs-intlayer-next-intl)
+- [Lingui vs @intlayer/lingui](https://intlayer.org/fr/blog/lingui-vs-intlayer-lingui)
+- [vue-i18n vs @intlayer/vue-i18n](https://intlayer.org/fr/blog/vue-i18n-vs-intlayer-vue-i18n)
+
+Les bibliothèques comparées directement :
+
+- [i18next vs Intlayer](https://intlayer.org/fr/blog/i18next-vs-intlayer), same benchmark
+- [next-i18next vs next-intl vs Intlayer](https://intlayer.org/fr/blog/next-i18next-vs-next-intl-vs-intlayer)
+- [react-i18next vs react-intl vs Intlayer](https://intlayer.org/fr/blog/react-i18next-vs-react-intl-vs-intlayer)
+- [Is i18next outdated?](https://intlayer.org/fr/blog/is-i18next-outdated)
+
+Documentation de référence :
+
+- Compat adapters: [i18next](https://intlayer.org/fr/doc/compatibility/i18next), [react-i18next](https://intlayer.org/fr/doc/compatibility/react-i18next), [next-i18next](https://intlayer.org/fr/doc/compatibility/next-i18next)
+- Migration guides: [i18next](https://intlayer.org/fr/doc/migration/i18next), [react-i18next](https://intlayer.org/fr/doc/migration/react-i18next), [next-i18next](https://intlayer.org/fr/doc/migration/next-i18next)
+- [Next.js benchmark report](https://intlayer.org/fr/doc/benchmark/nextjs) and [TanStack Start benchmark report](https://intlayer.org/fr/doc/benchmark/tanstack)
+- [Bundle optimization](https://intlayer.org/fr/doc/concept/bundle-optimization) and [the Intlayer compiler](https://intlayer.org/fr/doc/compiler)
+- [Visual Editor](https://intlayer.org/fr/doc/concept/editor), [CMS](https://intlayer.org/fr/doc/concept/cms) and [AI translation](https://intlayer.org/fr/doc/concept/auto-fill)
 
 ## Conclusion