@intlayer/docs 9.5.5 → 9.5.7

package/blog/es/next-intl_vs_intlayer-next-intl.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2026-09-13
-updatedAt: 2026-09-13
+updatedAt: 2026-09-22
 title: "next-intl vs @intlayer/next-intl: Misma API, Diferentes Bundle"
 description: Qué cambia cuando las importaciones de next-intl de una aplicación Next.js se sirven mediante el adaptador de compatibilidad @intlayer/next-intl. Tamaño de bundle, fugas, tamaño de componentes e hidratación medidos en el mismo código, más lo que el adaptador mantiene, ignora y no puede reemplazar.
 keywords:
@@ -26,6 +26,8 @@ author: aymericzip
 
 # next-intl VS @intlayer/next-intl | Misma API, Diferentes Bundle
 
+![next-intl VS Intlayer](https://github.com/aymericzip/intlayer/blob/main/docs/assets/i18next-next-intl-intlayer.webp?raw=true)
+
 `@intlayer/next-intl` es un adaptador de compatibilidad: expone la API de `next-intl` (`useTranslations`, `getTranslations`, `useLocale`, `t.rich()`, plurales ICU, `NextIntlClientProvider`...) y la sirve desde diccionarios compilados por Intlayer. El código de la aplicación no cambia. El bundle sí.
 
 Este artículo compara los dos en la misma aplicación Next.js, construida una vez con `next-intl` y otra con el adaptador. Los números provienen de [Benchmark Bloom](https://github.com/intlayer-org/benchmark-bloom), una suite open-source que registra lo que el navegador realmente descarga. Si quieres la comparación de `next-intl` vs Intlayer como librerías, lee [next-intl vs Intlayer](https://intlayer.org/blog/next-intl-vs-intlayer). Este es sobre lo que cambia el adaptador cuando mantienes tus componentes como están.
@@ -109,6 +111,10 @@ Para cada compilación, la suite registra:
 
 ### Resultados en Next.js
 
+Selecciona las métricas y las bibliotecas que te interesen:
+
+<I18nBenchmark framework="nextjs" vertical/>
+
 | Setup                     | Strategy       | Lib size (gz) | Page JS avg (gz) | Locale leak | Page leak | Component avg (gz) | E2E reactivity |   Hydration |
 | ------------------------- | -------------- | ------------: | ---------------: | ----------: | --------: | -----------------: | -------------: | ----------: |
 | **base** (no i18n)        | -              |        0.0 KB |         141.0 KB |        0.0% |      0.0% |             0.9 KB |        13.4 ms |     11.8 ms |
@@ -129,6 +135,15 @@ Para cada compilación, la suite registra:
 - **La hidratación es 2 ms más rápida** (12.8 vs 14.7 ms): no hay un objeto de mensaje que deserializar de la carga útil de RSC antes de que React pueda hidratarse.
 - **El adaptador no es el runtime nativo.** `next-intlayer` se ubica en **141.3 KB**, +0.3 KB sobre la aplicación base, con un runtime de 5.5 KB. El adaptador lleva la superficie de la API de `next-intl` (`useFormatter`, `t.rich`, el resolutor de ICU) sobre el núcleo de Intlayer, por lo que consume 8.0 KB y +6 KB por página. Es el puente, no el destino.
 
+<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`. Su adaptador, `@intlayer/use-intl`, sigue el mismo diseño con un plugin de Vite (`@intlayer/use-intl/plugin`).
@@ -152,11 +167,24 @@ Para cada compilación, la suite registra:
 - **El cambio de locale es más rápido.** Las configuraciones optimizadas de `use-intl` tardan **13-21 ms** en actualizar `html[lang]`; el adaptador tarda **4-9 ms**. Menos componentes se re-renderizan, y nada se vuelve a seleccionar de un árbol de mensajes.
 - **`static` mantiene cada locale.** La fila `static` del adaptador muestra 49.7% de fuga de locale, lo mismo que Intlayer nativo en modo `static`: todos los locales se empaquetan, solo se incluyen los diccionarios de la página. Una línea de configuración (`importMode: 'dynamic'`) lo elimina.
 
+<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é los números cambian
 
+![The Intlayer compiler extracts content from components](https://github.com/aymericzip/intlayer/blob/main/docs/assets/compiler.webp?raw=true)
+
 Nada en el componente cambió, por lo que las ganancias provienen completamente de lo que `useTranslations` está vinculado.
 
-**Con `next-intl`**, el binding es el provider. `NextIntlClientProvider` recibe todo el objeto `messages` para la locale; cada `useTranslations("about")` lee desde él. El bundler ve un componente importando un hook que lee un contexto, y no puede saber que solo se usa la rama `about`. Las rutas de abajo comparten el mismo objeto de mensajes, por lo que la columna page-leak lee ~90% hasta que dividas el archivo tú mismo.
+**Con `next-intl`**, el binding es el provider. `NextIntlClientProvider` recibe todo el objeto `messages` para la locale; cada `useTranslations("about")` lee desde él. El bundler ve un componente importando un hook que lee un contexto, y no puede saber que solo se usa la rama `about`. Las rutas de abajo comparten el mismo objeto de mensajes, por lo que la columna page-leak lee ~90% hasta que dividas el archivo tú mismo, y 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
 .
@@ -280,25 +308,106 @@ export default withIntlayer(nextConfig);
 
 ## Límites a conocer antes de comenzar
 
-- **La configuración de enrutamiento se traslada a `intlayer.config.ts`.** `createNavigation(routing)` y `createMiddleware(routing)` mantienen su firma pero ignoran el argumento: las locales, la locale predeterminada y la estrategia de prefijo provienen de la configuración `routing` de Intlayer. Si utilizas `pathnames` localizadas de `next-intl` (`/about` → `/a-propos`), el adaptador no las interpola; el `routing.rewrite` de Intlayer cubre ese caso pero es un cambio separado.
-- **`useTranslations()` sin namespace no está vinculado.** El paso de optimización necesita un namespace estático para saber qué diccionario importar. Una llamada sin argumentos sigue funcionando, a través de un registro en tiempo de ejecución que referencia cada diccionario, que es exactamente la fuga que intentabas eliminar. Pasa el namespace.
-- **El adaptador no es gratuito.** 8.0 KB de runtime versus 5.5 KB para `next-intlayer`, y +6-7 KB por página sobre la compilación nativa. Cubre la superficie de la API de `next-intl`. Si llegas al punto donde cada componente ha sido movido a `useIntlayer`, abandona el adaptador.
-- **`messages`, `timeZone`, `now` en el proveedor son ignorados.** Los formateadores están respaldados por `Intl` nativo y solo la locale influye en su salida; si dependes de una zona horaria forzada o un `now` fijo para fechas estables en hidratación, manéjalo en el sitio de la llamada.
+<AccordionGroup>
+<Accordion header="La configuración de enrutamiento se traslada a intlayer.config.ts">
+
+`createNavigation(routing)` y `createMiddleware(routing)` mantienen su firma pero ignoran el argumento: los idiomas, el idioma predeterminado y la estrategia de prefijo provienen de la configuración `routing` de Intlayer. Si utilizas los `pathnames` localizados de `next-intl` (`/about` a `/a-propos`), el adaptador no los interpola; `routing.rewrite` de Intlayer cubre ese caso pero es un cambio separado.
+
+</Accordion>
+<Accordion header="useTranslations() sin namespace no está vinculado">
+
+El paso de optimización necesita un namespace estático para saber qué diccionario importar. Una llamada sin namespace sigue funcionando a través de un registro de runtime que referencia cada diccionario, lo cual es exactamente la fuga que intentabas eliminar. Pasa el namespace.
+
+</Accordion>
+<Accordion header="El adaptador no es gratuito">
+
+8.0 KB de runtime frente a 5.5 KB de `next-intlayer`, y +6-7 KB por página sobre la compilación nativa. Paga por la superficie de la API de `next-intl`. Si llegas al punto en que cada componente se ha migrado a `useIntlayer`, elimina el adaptador.
+
+</Accordion>
+<Accordion header="messages, timeZone y now en el provider son ignorados">
+
+Los formateadores están respaldados por la API nativa `Intl` y solo el idioma influye en su salida. Si dependes de una zona horaria forzada o un `now` fijo para fechas estables en hidratación, manéjalo en el punto de llamada. Consulta [formateo de fechas, horas y números](https://intlayer.org/es/blog/date-time-number-formatting-locales).
+
+</Accordion>
+</AccordionGroup>
 
 ## ¿Cuándo usar cuál?
 
-- **Mantente en `next-intl`** si tu aplicación es pequeña, tu bundle no es una preocupación, y tu equipo se siente cómodo siendo propietario de los namespaces y `pick()` por página.
-- **Usa `@intlayer/next-intl`** si estás en `next-intl` hoy y quieres las ganancias de bundle, leakage e hidratación, claves tipadas y las herramientas CLI / CMS sin una reescritura. Este es el punto de entrada recomendado para cualquier codebase existente de `next-intl`.
-- **Ve nativo (`next-intlayer`)** para nuevos proyectos, o una vez que el adapter ha hecho su trabajo. Es el más ligero de los tres (5.5 KB, +0.3 KB por página) y desbloquea componentes de servidor síncronos, archivos `.content.ts` por componente y el conjunto completo de características.
+<AccordionGroup>
+<Accordion header="Quédate en next-intl">
+
+Tu aplicación es pequeña, el tamaño del bundle no es una preocupación y tu equipo se siente cómodo gestionando namespaces y `pick()` por página.
+
+</Accordion>
+<Accordion header="Usa @intlayer/next-intl">
+
+Hoy usas `next-intl` y quieres las ventajas de bundle, reducción de fugas e hidratación rápida, claves tipadas y las herramientas de CLI / CMS sin una reescritura. Este es el punto de entrada recomendado para cualquier base de código `next-intl` existente.
+
+</Accordion>
+<Accordion header="Pasa a nativo (next-intlayer)">
+
+Para nuevos proyectos, o una vez que el adaptador haya cumplido su función. Es el más ligero de los tres (5.5 KB, +0.3 KB por página) y desbloquea componentes de servidor síncronos, archivos `.content.ts` por componente y el conjunto completo de características. Comienza con [Intlayer con Next.js](https://intlayer.org/es/doc/environment/nextjs).
+
+</Accordion>
+</AccordionGroup>
+
+## Preguntas frecuentes
+
+<FAQ>
+
+<Question title="¿El código de mi aplicación realmente se mantiene intacto?">
+
+En Next.js, sí para los componentes: la compilación del benchmark solo modificó `next.config.ts` e `intlayer.config.ts`. `getRequestConfig` en `src/i18n.ts`, la prop `messages` en el provider y las llamadas `pick()` por página se convierten en código muerto que puedes eliminar después.
+
+</Question>
+
+<Question title="¿Qué ocurre con los mensajes ICU?">
+
+Siguen funcionando. `t("key", { count })`, `t.rich()`, `t.markup()`, `select`, `selectordinal`, `#` y `{ts, date, long}` son resueltos por el intérprete ICU de Intlayer. Consulta [formato de mensaje ICU](https://intlayer.org/es/blog/icu-message-format).
+
+</Question>
+
+<Question title="¿Por qué el adaptador es más pesado que next-intlayer nativo?">
+
+Transporta la superficie de la API de `next-intl` sobre el núcleo de Intlayer: `useFormatter`, `t.rich`, el intérprete ICU, los helpers de navegación. Eso representa 8.0 KB frente a 5.5 KB, y +6 KB por página. Es el puente, no el destino final.
+
+</Question>
+
+<Question title="¿Puedo migrar componente por componente?">
+
+Sí. Cualquier componente puede cambiar de `useTranslations("about")` a `useIntlayer("about")` con un archivo `.content.ts` coubicado. Los diccionarios JSON y `.content.ts` coexisten y se combinan, por lo que no hay interrupciones.
+
+</Question>
+
+<Question title="¿Funcionan las rutas (pathnames) localizadas?">
+
+No a través de los `pathnames` de `next-intl`: el adaptador los acepta para tipado pero no los interpola. Utiliza en su lugar `routing.rewrite` de Intlayer, que emite los literales localizados en el registro de tipos.
+
+</Question>
+
+</FAQ>
 
 ## Comparaciones relacionadas
 
-- [next-intl vs Intlayer](https://intlayer.org/blog/next-intl-vs-intlayer) (las librerías, el mismo benchmark)
-- [i18next vs @intlayer/i18next](https://intlayer.org/blog/i18next-vs-intlayer-i18next) (la misma serie de adaptadores)
-- [Lingui vs @intlayer/lingui](https://intlayer.org/blog/lingui-vs-intlayer-lingui) (misma serie de adaptadores)
-- [vue-i18n vs @intlayer/vue-i18n](https://intlayer.org/blog/vue-i18n-vs-intlayer-vue-i18n) (misma serie de adaptadores)
-- [Guía de migración: next-intl a Intlayer](https://intlayer.org/doc/migration/next-intl)
-- [Referencia del adaptador de compatibilidad: next-intl](https://intlayer.org/doc/compatibility/next-intl)
+Misma serie de adaptadores:
+
+- [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)
+- [vue-i18n vs @intlayer/vue-i18n](https://intlayer.org/es/blog/vue-i18n-vs-intlayer-vue-i18n)
+
+Las bibliotecas comparadas directamente:
+
+- [next-intl vs Intlayer](https://intlayer.org/es/blog/next-intl-vs-intlayer), mismo benchmark
+- [next-i18next vs next-intl vs Intlayer](https://intlayer.org/es/blog/next-i18next-vs-next-intl-vs-intlayer)
+- [Is next-intl outdated?](https://intlayer.org/es/blog/is-next-intl-outdated)
+
+Documentación de referencia:
+
+- [Compat adapter: next-intl](https://intlayer.org/es/doc/compatibility/next-intl)
+- [Guía de migración: next-intl a Intlayer](https://intlayer.org/es/doc/migration/next-intl)
+- [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)
+- [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
 

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/transform_existing_vite_react_app_using_compiler.md

@@ -284,7 +284,9 @@ const pathList = [
   { path: "/about", changefreq: "monthly", priority: 0.7 },
 ];
 
-const sitemapXml = generateSitemap(pathList, { siteUrl: SITE_URL });
+const sitemapXml = generateSitemap(pathList, {
+  siteUrl: "https://example.com",
+});
 fs.writeFileSync(path.join(__dirname, "public", "sitemap.xml"), sitemapXml);
 
 const getAllMultilingualUrls = (urls) =>
@@ -297,7 +299,7 @@ const robotsTxt = [
   "Allow: /",
   ...disallowedPaths.map((path) => `Disallow: ${path}`),
   "",
-  `Sitemap: ${SITE_URL}/sitemap.xml`,
+  `Sitemap: https://example.com/sitemap.xml`,
 ].join("\n");
 
 fs.writeFileSync(path.join(__dirname, "public", "robots.txt"), robotsTxt);