@intlayer/docs 9.5.6 → 9.5.8

package/blog/es/next-intl_vs_intlayer.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2026-09-13
-updatedAt: 2026-09-13
+updatedAt: 2026-09-22
 title: "next-intl vs Intlayer: Benchmark y Comparación 2026"
 description: Tamaño del bundle, fuga de contenido, reactividad del cambio de idioma y experiencia del desarrollador medidos en Next.js y TanStack Start. ¿Qué librería i18n deberías elegir en 2026?
 keywords:
@@ -24,6 +24,8 @@ author: aymericzip
 
 # next-intl VS Intlayer | Benchmark de Internacionalización (i18n) en Next.js
 
+![next-intl VS Intlayer](https://github.com/aymericzip/intlayer/blob/main/docs/assets/i18next-next-intl-intlayer.webp?raw=true)
+
 `next-intl` es la librería i18n más popular para Next.js. Intlayer es una alternativa basada en compilador y con alcance de componente. Ambas localizan una aplicación App Router. La pregunta es qué costo tiene cada una una vez que la aplicación se construye.
 
 Este artículo no es un tutorial. Es una comparación respaldada por números de [Benchmark Bloom](https://github.com/intlayer-org/benchmark-bloom), un conjunto de benchmarks de código abierto que construye la misma aplicación con cada librería y mide qué descarga y ejecuta realmente el navegador.
@@ -96,6 +98,10 @@ Para cada compilación, el conjunto registra:
 
 ### Resultados en Next.js (App Router)
 
+Elija las métricas y las bibliotecas que le interesan:
+
+<I18nBenchmark framework="nextjs" vertical/>
+
 | Library                        | Strategy       | Lib size (gz) | Page JS avg (gz) | Locale leak | Page leak | Component avg (gz) | E2E reactivity | Hydration |
 | ------------------------------ | -------------- | ------------: | ---------------: | ----------: | --------: | -----------------: | -------------: | --------: |
 | **base** (sin i18n)            | -              |        0.0 KB |         141.0 KB |        0.0% |      0.0% |             0.9 KB |        13.4 ms |   11.8 ms |
@@ -116,6 +122,15 @@ Para cada compilación, el conjunto registra:
 - **Tamaño del componente.** Un componente que llama a `useTranslations()` se compila a 21.8 KB en promedio; el mismo componente con `useIntlayer()` se compila a 6.9 KB. En la configuración `scoped-static` los componentes de `next-intl` saltan a 80.1 KB porque cada uno incluye su catálogo de namespace.
 - **Reactividad e hidratación** están en el mismo rango para ambas librerías en Next.js (15-18 ms). Ninguna es un cuello de botella aquí.
 
+<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;"
+/>
+
+> Tabla completa, cada biblioteca y cada estrategia, en el [informe de benchmark de Next.js](https://intlayer.org/es/doc/benchmark/nextjs).
+
 ### Resultados en TanStack Start (`use-intl`)
 
 `use-intl` es el núcleo agnóstico del framework de `next-intl`. Misma API, mismo formato de mensajes. Compararlo contra `intlayer` en TanStack Start elimina las partes específicas de Next.js de la ecuación.
@@ -139,8 +154,19 @@ Para cada compilación, el conjunto registra:
 - **El tamaño del componente es donde se muestra la arquitectura**: 76-87 KB por componente con `use-intl` versus 6-8 KB con Intlayer. `useTranslations()` vincula cada componente al árbol global de mensajes; `useIntlayer()` lo vincula a su propio diccionario.
 - **El cambio de idioma** es 2x-4x más rápido con Intlayer (3 ms vs 7-21 ms).
 
+<ClickToOpenIframe
+src="https://intlayer.org/markdown?url=https%3A%2F%2Fraw.githubusercontent.com%2Fintlayer-org%2Fbenchmark-i18n%2Fmain%2Freport%2Fscripts%2Fsummarize-tanstack.md"
+width="100%"
+height="600px"
+style="border:none;"
+/>
+
+> Tabla completa en el [informe de benchmark de TanStack Start](https://intlayer.org/es/doc/benchmark/tanstack).
+
 ## ¿Por qué la diferencia? Catálogos centralizados vs. diccionarios compilados
 
+![Centralized catalogs versus per-component dictionaries](https://github.com/aymericzip/intlayer/blob/main/docs/assets/project_stucture_18n_vs_intlayer.png?raw=true)
+
 `next-intl` sigue el modelo clásico: un JSON por idioma, cargado en `getRequestConfig`, enviado a un `NextIntlClientProvider`, leído a través de `t("namespace.key")`.
 
 ```bash
@@ -162,6 +188,10 @@ Para cada compilación, el conjunto registra:
 
 El tiempo de ejecución no puede saber qué claves utilizará una página, por lo que la opción segura predeterminada es enviar el catálogo completo. Optimizar significa **que tú** dividas el catálogo en namespaces, **que tú** decidas qué namespaces necesita cada página, y **que tú** mantengas ese mapeo sincronizado mientras los componentes se mueven. La fila `scoped-dynamic` del benchmark es la recompensa por ese trabajo, y la mayoría de los equipos nunca llegan a ese punto.
 
+El costo de no llegar a ese punto crece en dos ejes al mismo tiempo, páginas y locales:
+
+![Theoretical content leakage by architecture](https://github.com/aymericzip/intlayer/blob/main/docs/assets/theorical_content_leakage.webp?raw=true)
+
 Intlayer invierte la responsabilidad. El contenido se declara junto al componente:
 
 ```bash
@@ -189,7 +219,8 @@ En tiempo de compilación, el compilador (`@intlayer/swc` / `@intlayer/babel`) v
 
 ### Componente cliente
 
-**next-intl**
+<Tabs defaultTab="intlayer" group="techno">
+<Tab label="next-intl" value="next-intl">
 
 ```json fileName="messages/en.json"
 {
@@ -224,7 +255,8 @@ export const Counter = () => {
 
 > Recuerda incluir el namespace `counter` en los mensajes pasados a `NextIntlClientProvider` en cada página que renderiza este componente.
 
-**Intlayer**
+</Tab>
+<Tab label="Intlayer" value="intlayer">
 
 ```ts fileName="src/components/Counter/index.content.ts"
 import { t, type Dictionary } from "intlayer";
@@ -266,11 +298,14 @@ export const Counter = () => {
 
 No hay nada que registrar en la página: el componente trae su propio contenido.
 
+</Tab>
+</Tabs>
 ### Componente de servidor sincrónico
 
 Las piezas del design-system (navbar, footer, cards) suelen ser componentes de servidor renderizados como hijos de componentes cliente, por lo que no pueden ser `async`.
 
-**next-intl**
+<Tabs defaultTab="intlayer" group="techno">
+<Tab label="next-intl" value="next-intl">
 
 ```tsx fileName="src/components/ServerCounter.tsx"
 type ServerCounterProps = {
@@ -288,7 +323,8 @@ export const ServerCounter = ({ t, formattedCount }: ServerCounterProps) => (
 
 La página tiene que `await getTranslations("counter")` y `await getFormatter()`, luego pasar los resultados como props. El componente ya no es autónomo.
 
-**Intlayer**
+</Tab>
+<Tab label="Intlayer" value="intlayer">
 
 ```tsx fileName="src/components/ServerCounter.tsx"
 import { useIntlayer } from "next-intlayer/server";
@@ -307,9 +343,12 @@ export const ServerCounter = ({ count }: { count: number }) => {
 };
 ```
 
+</Tab>
+</Tabs>
 ### Metadatos
 
-**next-intl**
+<Tabs defaultTab="intlayer" group="techno">
+<Tab label="next-intl" value="next-intl">
 
 ```tsx fileName="src/app/[locale]/about/page.tsx"
 import type { Metadata } from "next";
@@ -343,7 +382,8 @@ export const generateMetadata = async ({
 };
 ```
 
-**Intlayer**
+</Tab>
+<Tab label="Intlayer" value="intlayer">
 
 ```tsx fileName="src/app/[locale]/about/page.tsx"
 import { getIntlayer, getMultilingualUrls } from "intlayer";
@@ -367,6 +407,9 @@ export const generateMetadata = async ({
 };
 ```
 
+</Tab>
+</Tabs>
+
 ## Mantener la API de next-intl, obtener la salida de Intlayer
 
 No tienes que reescribir componentes para obtener los números de benchmark anteriores. `@intlayer/next-intl` es un adaptador listo para usar: mantiene `useTranslations`, `getTranslations`, `useFormatter`, `t.rich()`, plurales ICU y los helpers de `next-intl/navigation`, y los sirve desde diccionarios de Intlayer compilados por el compilador de Intlayer.
@@ -388,17 +431,84 @@ Consulte la [guía de migración de next-intl](https://intlayer.org/doc/es/migra
 
 ## ¿Cuándo elegir cuál?
 
-- **Elige next-intl** si quieres el estándar del ecosistema para Next.js, dependes de ICU MessageFormat, tu app es pequeña a mediana, o te integras con una plataforma de traducción (Crowdin, Phrase, Lokalise...) que espera JSON centralizado. Presupuesta el tiempo para namespaces de catálogos y selecciona mensajes por página si el rendimiento importa.
-- **Elige Intlayer** si quieres **contenido con scope de componente**, **TypeScript estricto**, **errores de missing-key en tiempo de build**, **tree-shaking y lazy loading sin esfuerzo**, componentes de servidor síncronos, y herramientas editoriales integradas (Visual Editor, CMS, traducción con IA, servidor MCP). Especialmente relevante para codebases grandes y modulares y design systems.
-- **Elige `@intlayer/next-intl`** si ya estás en `next-intl` y quieres las ganancias de bundle sin una reescritura.
+<AccordionGroup>
+<Accordion header="Elegir next-intl">
+
+Desea el estándar del ecosistema para Next.js, depende de ICU MessageFormat, su aplicación es pequeña o mediana, o se integra con una plataforma de traducción (Crowdin, Phrase, Lokalise...) que espera JSON centralizado. Dedique tiempo a estructurar catálogos por namespace y seleccionar mensajes con `pick()` por página si el rendimiento importa.
+
+</Accordion>
+<Accordion header="Elegir Intlayer">
+
+Desea **contenido con ámbito por componente**, **TypeScript estricto**, **errores de claves faltantes en tiempo de compilación**, **tree-shaking y lazy loading sin esfuerzo**, componentes de servidor sincrónicos y herramientas editoriales integradas ([Editor Visual](https://intlayer.org/es/doc/concept/editor), [CMS](https://intlayer.org/es/doc/concept/cms), [traducción automática con IA](https://intlayer.org/es/doc/concept/auto-fill), [servidor MCP](https://intlayer.org/es/doc/mcp-server)). Especialmente relevante para bases de código modulares y grandes sistemas de diseño.
+
+</Accordion>
+<Accordion header="Elegir @intlayer/next-intl">
+
+Ya utiliza `next-intl` y desea las ganancias de tamaño de paquete sin una reescritura completa. El [adaptador de compatibilidad](https://intlayer.org/es/doc/compatibility/next-intl) conserva sus importaciones y su archivo `messages/{locale}.json` como fuente de verdad. Medido lado a lado en [next-intl vs @intlayer/next-intl](https://intlayer.org/es/blog/next-intl-vs-intlayer-next-intl).
+
+</Accordion>
+</AccordionGroup>
+
+## Preguntas frecuentes
+
+<FAQ>
+
+<Question title="¿Es next-intl más lento que Intlayer?">
+
+No en tiempo de renderizado. La diferencia está en lo que se envía: `next-intl` cuesta **+12.6 KB gzip** de tiempo de ejecución en cada página y, en las configuraciones más comunes, envía ~90% de cadenas de páginas extranjeras con cada página. El cambio de idioma y la hidratación son comparables en Next.js (15-18 ms); en TanStack Start, `use-intl` toma 7-21 ms frente a 3-4 ms de Intlayer.
+
+</Question>
+
+<Question title="¿Puedo lograr 0% de fuga con next-intl?">
+
+Sí, con la configuración `scoped-dynamic`: divida `messages/{locale}.json` en un namespace por ruta, luego use `pick(messages, [...])` en cada página y mantenga esa asignación correcta a medida que los componentes cambian. Las filas `scoped-*` del benchmark son exactamente ese trabajo. Intlayer logra 0% sin eso porque el compilador delimita el contenido por componente. Consulte [optimización de paquetes](https://intlayer.org/es/doc/concept/bundle-optimization).
+
+</Question>
+
+<Question title="¿Tengo que reescribir mis componentes para migrar?">
+
+No. `@intlayer/next-intl` mantiene `useTranslations`, `getTranslations`, `useFormatter`, `t.rich()`, los plurales ICU y los helpers de navegación, y los sirve desde diccionarios compilados. Una sola línea de plugin en `next.config.ts`. Paso a paso en la [guía de migración de next-intl](https://intlayer.org/es/doc/migration/next-intl).
+
+</Question>
+
+<Question title="¿Admite Intlayer ICU MessageFormat?">
+
+El soporte de ICU está en desarrollo en la API nativa. Los adaptadores de compatibilidad (`@intlayer/next-intl`, `@intlayer/use-intl`) sí ejecutan ICU: plurales, `select`, `selectordinal`, `#` y `{ts, date, long}` pasan por el solucionador ICU de Intlayer. Lea [formato de mensaje ICU](https://intlayer.org/es/blog/icu-message-format) para más detalles.
+
+</Question>
+
+<Question title="¿Puedo conservar mis archivos messages/{locale}.json?">
+
+Sí. El [plugin de sincronización JSON](https://intlayer.org/es/doc/compatibility/next-intl) los lee, divide sus claves de nivel superior en diccionarios y escribe las traducciones en los mismos archivos cuando la CLI o el CMS los actualiza. El flujo de trabajo de sus traductores no cambia.
+
+</Question>
+
+</FAQ>
 
 ## Comparaciones relacionadas
 
-- [i18next vs Intlayer](https://intlayer.org/blog/i18next-vs-intlayer) (mismo benchmark)
-- [Lingui vs Intlayer](https://intlayer.org/blog/lingui-vs-intlayer) (mismo benchmark)
-- [vue-i18n vs Intlayer benchmark](https://intlayer.org/blog/vue-i18n-vs-intlayer-benchmark) (mismo benchmark)
-- [next-i18next vs next-intl vs Intlayer](https://intlayer.org/blog/next-i18next-vs-next-intl-vs-intlayer)
-- [¿Está next-intl obsoleto?](https://intlayer.org/blog/is-next-intl-outdated)
+Mismo benchmark, otras bibliotecas:
+
+- [i18next vs Intlayer](https://intlayer.org/es/blog/i18next-vs-intlayer)
+- [Lingui vs Intlayer](https://intlayer.org/es/blog/lingui-vs-intlayer)
+- [vue-i18n vs Intlayer benchmark](https://intlayer.org/es/blog/vue-i18n-vs-intlayer-benchmark)
+- [next-i18next vs next-intl vs Intlayer](https://intlayer.org/es/blog/next-i18next-vs-next-intl-vs-intlayer)
+- [react-i18next vs react-intl vs Intlayer](https://intlayer.org/es/blog/react-i18next-vs-react-intl-vs-intlayer)
+
+Profundizando en next-intl:
+
+- [next-intl vs @intlayer/next-intl](https://intlayer.org/es/blog/next-intl-vs-intlayer-next-intl), el adaptador medido en la misma aplicación
+- [Is next-intl outdated?](https://intlayer.org/es/blog/is-next-intl-outdated)
+- [Using Intlayer with next-intl](https://intlayer.org/es/blog/intlayer-with-next-intl)
+- [How to internationalize a Next.js app with next-intl](https://intlayer.org/es/blog/nextjs-internationalization-using-next-intl)
+
+Documentos de referencia:
+
+- [Informe de benchmark de Next.js](https://intlayer.org/es/doc/benchmark/nextjs) e [informe de benchmark de TanStack Start](https://intlayer.org/es/doc/benchmark/tanstack)
+- [Adaptador de compatibilidad: next-intl](https://intlayer.org/es/doc/compatibility/next-intl) y [guía de migración](https://intlayer.org/es/doc/migration/next-intl)
+- [Optimización de paquetes](https://intlayer.org/es/doc/concept/bundle-optimization) y [el compilador de Intlayer](https://intlayer.org/es/doc/compiler)
+- [i18n por componente vs centralizada](https://intlayer.org/es/blog/per-component-vs-centralized-i18n)
+- [i18n basada en compilador vs declarativa](https://intlayer.org/es/blog/compiler-vs-declarative-i18n)
 
 ## GitHub STARs
 

package/blog/es/vue-i18n_vs_intlayer-vue-i18n.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2026-09-13
-updatedAt: 2026-09-13
+updatedAt: 2026-09-22
 title: "vue-i18n vs @intlayer/vue-i18n: Misma API, Bundle Diferente"
 description: Qué cambia cuando una aplicación Vue 3 mantiene sus llamadas vue-i18n pero las sirve a través del adaptador de compatibilidad @intlayer/vue-i18n. JavaScript por página, tamaño en tiempo de ejecución, tamaño de componente y fugas medidas en el mismo código Vite + Vue, además de lo que el adaptador mantiene, ignora y no puede reemplazar.
 keywords:
@@ -25,6 +25,8 @@ author: aymericzip
 
 # vue-i18n VS @intlayer/vue-i18n | Misma API, Bundle Diferente
 
+![Vue i18n library ecosystem](https://github.com/aymericzip/intlayer/blob/main/docs/assets/cloud_i18n_logo.webp?raw=true)
+
 `@intlayer/vue-i18n` es un adaptador de compatibilidad: expone la API de `vue-i18n` (`createI18n`, `useI18n`, `t()`, `d()`, `n()`, `$t`, `v-t`, `i18n.global.locale`...) y la sirve desde diccionarios compilados por Intlayer. Tus archivos `.vue` no cambian. Lo que `t("footer.github")` está vinculado sí lo hace.
 
 Este artículo mide ese cambio en la misma aplicación Vite + Vue 3, construida una vez con `vue-i18n` y otra con el adaptador. Los números provienen de [Benchmark Bloom](https://github.com/intlayer-org/benchmark-bloom). Para comparar `vue-i18n` e Intlayer como librerías, lee [vue-i18n vs Intlayer](https://intlayer.org/blog/vue-i18n-vs-intlayer) y el [benchmark de vue-i18n vs Intlayer](https://intlayer.org/blog/vue-i18n-vs-intlayer-benchmark). Este trata sobre qué cambia el adaptador cuando mantienes tus componentes como están.
@@ -105,6 +107,10 @@ Para cada compilación, el suite registra:
 
 ### Resultados en Vite + Vue 3
 
+Selecciona las métricas y las bibliotecas que te interesen:
+
+<I18nBenchmark framework="vite-vue" vertical/>
+
 | Setup                    | Strategy | Lib size (gz) | Lib size (min) | Page JS avg (gz) | Locale leak | Page leak | Component avg (gz) | E2E reactivity |  Page load |
 | ------------------------ | -------- | ------------: | -------------: | ---------------: | ----------: | --------: | -----------------: | -------------: | ---------: |
 | **base** (no i18n)       | -        |        0.0 KB |         0.0 KB |          41.3 KB |        0.0% |         - |             1.1 KB |         1.8 ms |    10.8 ms |
@@ -124,11 +130,24 @@ Para cada compilación, el suite registra:
 - **Reactividad y carga de página.** El cambio de locale es económico para ambos (1.5-2.8 ms); el sistema de reactividad de Vue lo hace posible una vez que los mensajes están en memoria. La carga de página va de 13.6 ms a **9.3 ms**, en línea con 88 KB menos de JavaScript para analizar.
 - **Acerca de las filas nativas.** `vue-intlayer` en esta ejecución agrupó cada locale en modo `static` y llegó a 57.1 KB con un runtime de 3.9 KB; los diccionarios sincronizados del adaptador llevaban menos strings de locales extranjeros, de ahí la cifra más baja por página. El runtime nativo sigue siendo el más ligero de los tres, y su modelo `.content.ts` es donde los bloques `<i18n>` de SFC encuentran su equivalente.
 
+<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, cada biblioteca y cada estrategia, en el [informe de benchmark de Vue](https://intlayer.org/es/doc/benchmark/vue).
+
 ## Por qué se mueven los números
 
+![The Intlayer compiler extracts content from components](https://github.com/aymericzip/intlayer/blob/main/docs/assets/compiler.webp?raw=true)
+
 Nada en `src/components/` cambió, así que las ganancias provienen de a qué está vinculado `useI18n`.
 
-**Con `vue-i18n`**, el binding es la instancia global. `createI18n({ messages: { en, fr, ... } })` es una importación que contiene todo; cada componente que llama a `useI18n()` puede acceder a todo, por lo que el bundler no puede dividir por debajo de la instancia. Optimizar significa que _tú_ divides `en.json` por ruta, llamas a `setLocaleMessage()` en un router guard, y mantienes el mapa ruta-a-archivo correcto a medida que los componentes se mueven.
+**Con `vue-i18n`**, el binding es la instancia global. `createI18n({ messages: { en, fr, ... } })` es una importación que contiene todo; cada componente que llama a `useI18n()` puede acceder a todo, por lo que el bundler no puede dividir por debajo de la instancia. Optimizar significa que _tú_ divides `en.json` por ruta, llamas a `setLocaleMessage()` en un router guard, y mantienes el mapa ruta-a-archivo correcto a medida que los componentes se mueven. El desperdicio crece en dos ejes a la vez, páginas e idiomas:
+
+![Theoretical content leakage by architecture](https://github.com/aymericzip/intlayer/blob/main/docs/assets/theorical_content_leakage.webp?raw=true)
 
 ```bash
 .
@@ -258,26 +277,107 @@ export const i18n = createI18n({ locale: "en" });
 
 ## Limitaciones que debes conocer antes de empezar
 
-- **Los bloques SFC `<i18n>` no se leen.** Si tus mensajes viven dentro de componentes, necesitan moverse a los archivos de locale (o a `.content.ts`, que es la misma idea pero con tipos).
-- **La carga de mensajes en tiempo de ejecución se ha eliminado.** `setLocaleMessage()` y `mergeLocaleMessage()` advierten y devuelven. Las traducciones obtenidas de un CMS en tiempo de ejecución necesitan el CMS de Intlayer, o los comandos `intlayer pull` / `push`.
-- **`messages` es un fallback, no gratis.** Mantener los imports de JSON en `createI18n()` mantiene los 75 KB en el bundle. Elimínalos una vez que `intlayer test` pase.
-- **El adaptador no es el runtime nativo.** 7.9 KB contra 3.9 KB para `vue-intlayer`. Una vez que cada componente haya migrado a `useIntlayer`, puedes eliminarlo.
+<AccordionGroup>
+<Accordion header="Los bloques SFC <i18n> no se leen">
+
+Si tus mensajes residen dentro de los componentes, deben trasladarse a los archivos de idioma o a un `.content.ts`, que es la misma idea con tipos generados.
+
+</Accordion>
+<Accordion header="La carga de mensajes en runtime desaparece">
+
+`setLocaleMessage()` y `mergeLocaleMessage()` muestran una advertencia y retornan. Las traducciones obtenidas de un CMS en runtime requieren el [CMS de Intlayer](https://intlayer.org/es/doc/concept/cms) o los comandos `intlayer pull` / `push`.
+
+</Accordion>
+<Accordion header="messages es un fallback, no gratuito">
+
+Mantener los imports JSON en `createI18n()` conserva los 75 KB en el bundle. Elimínalos una vez que `intlayer test` pase exitosamente.
+
+</Accordion>
+<Accordion header="El adaptador no es el runtime nativo">
+
+7.9 KB frente a 3.9 KB de `vue-intlayer`. Una vez que todos los componentes hayan pasado a `useIntlayer`, elimínalo.
+
+</Accordion>
+</AccordionGroup>
 
 ## ¿Cuándo usar cuál?
 
-- **Mantente en `vue-i18n`** si tu aplicación depende de bloques SFC `<i18n>`, de flujos de `setLocaleMessage()` en runtime, o si 90 KB por página no es una preocupación para tu audiencia.
-- **Usa `@intlayer/vue-i18n`** si estás en `vue-i18n` y deseas los 88 KB, los componentes 23x más pequeños, 0% de fuga de página, claves tipadas y verificaciones de CI sin editar un archivo `.vue`. Este es el punto de entrada para una codebase `vue-i18n` existente.
-- **Ve nativo (`vue-intlayer`)** para nuevos proyectos, o una vez que el adaptador haya cumplido su función. Tiene el runtime más ligero (3.9 KB) y el modelo `.content.ts` por componente que reemplaza los bloques `<i18n>` con contenido tipado.
+<AccordionGroup>
+<Accordion header="Quédate en vue-i18n">
+
+Tu aplicación depende de los bloques SFC `<i18n>`, de flujos de `setLocaleMessage()` en runtime, o 90 KB por página no es una preocupación para tu audiencia.
+
+</Accordion>
+<Accordion header="Usa @intlayer/vue-i18n">
+
+Estás en `vue-i18n` y quieres los 88 KB, componentes 23 veces más pequeños, 0% de fuga de páginas, claves tipadas y comprobaciones de CI sin editar un archivo `.vue`. Este es el punto de entrada para una base de código `vue-i18n` existente.
+
+</Accordion>
+<Accordion header="Pasa a nativo (vue-intlayer)">
+
+Para nuevos proyectos, o una vez que el adaptador haya cumplido su función. Tiene el runtime más ligero (3.9 KB) y el modelo `.content.ts` por componente que reemplaza los bloques `<i18n>` con contenido tipado. 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>
+</AccordionGroup>
+
+## Preguntas frecuentes
+
+<FAQ>
+
+<Question title="¿Tengo que editar mis archivos .vue?">
+
+No. La compilación del benchmark solo modificó `vite.config.ts`, `intlayer.config.ts` y una línea en `src/i18n.ts`, la importación de `messages`. Cada llamada a `useI18n()`, `$t`, `v-t` y la Options API se mantuvo como estaba.
+
+</Question>
+
+<Question title="¿Por qué el tamaño del componente es 23 veces menor?">
+
+Porque `useI18n()` deja de acceder a la instancia global. `createI18n({ messages })` contiene todos los mensajes de cada idioma, por lo que un componente compilado aisladamente arrastra 196 KB. Con el adaptador solo accede a su propio diccionario: 8.4 KB.
+
+</Question>
+
+<Question title="¿Qué sucede con el formateo de d() y n()?">
+
+Se conserva. Se respetan `datetimeFormats` y `numberFormats` pasados a `createI18n()`, respaldados por la API nativa `Intl`. Consulta [formateo de fechas, horas y números](https://intlayer.org/es/blog/date-time-number-formatting-locales).
+
+</Question>
+
+<Question title="¿Funciona con Nuxt?">
+
+`@intlayer/vue-i18n` está diseñado para Vite + Vue. Para `@nuxtjs/i18n`, usa el [adaptador de compatibilidad Nuxt i18n](https://intlayer.org/es/doc/compatibility/nuxtjs-i18n) y consulta [Intlayer con Nuxt](https://intlayer.org/es/doc/environment/nuxt-and-vue) para la configuración nativa.
+
+</Question>
+
+<Question title="¿Puedo migrar componente por componente?">
+
+Sí. Cualquier componente puede cambiar de `useI18n()` a `useIntlayer("footer")` con un archivo de contenido ubicado al lado. Los diccionarios JSON y `.content.ts` coexisten y se combinan.
+
+</Question>
+
+</FAQ>
 
 ## Comparaciones relacionadas
 
-- [vue-i18n vs Intlayer](https://intlayer.org/blog/vue-i18n-vs-intlayer) (características y DX)
-- [vue-i18n vs Intlayer benchmark](https://intlayer.org/blog/vue-i18n-vs-intlayer-benchmark) (las librerías, mismo benchmark)
-- [next-intl vs @intlayer/next-intl](https://intlayer.org/blog/next-intl-vs-intlayer-next-intl) (misma serie de adaptadores)
-- [i18next vs @intlayer/i18next](https://intlayer.org/blog/i18next-vs-intlayer-i18next) (misma serie de adaptadores)
-- [Lingui vs @intlayer/lingui](https://intlayer.org/blog/lingui-vs-intlayer-lingui) (misma serie de adaptadores)
-- [Guía de migración: vue-i18n a Intlayer](https://intlayer.org/doc/migration/vue-i18n)
-- [Referencia del adaptador de compatibilidad: vue-i18n](https://intlayer.org/doc/compatibility/vue-i18n), [Nuxt i18n](https://intlayer.org/doc/compatibility/nuxtjs-i18n)
+Misma serie de adaptadores:
+
+- [next-intl vs @intlayer/next-intl](https://intlayer.org/es/blog/next-intl-vs-intlayer-next-intl)
+- [i18next vs @intlayer/i18next](https://intlayer.org/es/blog/i18next-vs-intlayer-i18next)
+- [Lingui vs @intlayer/lingui](https://intlayer.org/es/blog/lingui-vs-intlayer-lingui)
+
+Las bibliotecas comparadas directamente:
+
+- [vue-i18n vs Intlayer](https://intlayer.org/es/blog/vue-i18n-vs-intlayer), características y DX
+- [vue-i18n vs Intlayer benchmark](https://intlayer.org/es/blog/vue-i18n-vs-intlayer-benchmark)
+- [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)
+
+Documentación de referencia:
+
+- [Compat adapter: vue-i18n](https://intlayer.org/es/doc/compatibility/vue-i18n) and [Nuxt i18n](https://intlayer.org/es/doc/compatibility/nuxtjs-i18n)
+- [Guía de migración: vue-i18n a Intlayer](https://intlayer.org/es/doc/migration/vue-i18n)
+- [Informe de benchmark de Vue](https://intlayer.org/es/doc/benchmark/vue)
+- [Optimización del bundle](https://intlayer.org/es/doc/concept/bundle-optimization) y [el compilador Intlayer](https://intlayer.org/es/doc/compiler)
+- [Visual Editor](https://intlayer.org/es/doc/concept/editor), [CMS](https://intlayer.org/es/doc/concept/cms) y [traducción por IA](https://intlayer.org/es/doc/concept/auto-fill)
 
 ## Conclusión
 
@@ -285,4 +385,4 @@ export const i18n = createI18n({ locale: "en" });
 
 Todos los datos sin procesar, las aplicaciones de prueba y los scripts están en el [repositorio Benchmark Bloom](https://github.com/intlayer-org/benchmark-bloom). Ejecútalo tú mismo.
 
-Consulta la [documentación 'Why Intlayer?'](https://intlayer.org/doc/why) para más detalles.
+Consulta la [documentación 'Why Intlayer?'](https://intlayer.org/es/doc/why) para más detalles.