@intlayer/docs 7.3.3 → 7.3.5

package/blog/es/compiler_vs_declarative_i18n.md

@@ -2,7 +2,7 @@
 createdAt: 2025-11-24
 updatedAt: 2025-11-24
 title: Compilador vs. i18n Declarativo
-description: Explorando los compromisos arquitectónicos entre la internacionalización "mágica" basada en compiladores y la gestión explícita y declarativa de contenido.
+description: Explorando las compensaciones arquitectónicas entre la internacionalización "mágica" basada en compilador y la gestión explícita y declarativa de contenido.
 keywords:
   - Intlayer
   - Internacionalización
@@ -18,35 +18,67 @@ slugs:
   - compiler-vs-declarative-i18n
 ---
 
-# El Caso a Favor y en Contra de la i18n Basada en Compiladores
+# Argumentos a favor y en contra de la i18n basada en compilador
 
 Si has estado desarrollando aplicaciones web por más de una década, sabes que la Internacionalización (i18n) siempre ha sido un punto de fricción. A menudo es la tarea que nadie quiere hacer: extraer cadenas, gestionar archivos JSON y preocuparse por las reglas de pluralización.
 
-Recientemente, ha surgido una nueva ola de herramientas de i18n "basadas en compiladores", que prometen hacer desaparecer este dolor. La propuesta es seductora: **Simplemente escribe texto en tus componentes y deja que la herramienta de compilación se encargue del resto.** Sin claves, sin importaciones, solo magia.
+Recientemente, ha surgido una nueva ola de herramientas de i18n **"basadas en compilador"**, que prometen hacer desaparecer este dolor. La propuesta es seductora: **Simplemente escribe texto en tus componentes y deja que la herramienta de compilación se encargue del resto.** Sin claves, sin importaciones, solo magia.
 
 Pero como con todas las abstracciones en la ingeniería de software, la magia tiene un precio.
 
-En esta publicación del blog, exploraremos el cambio de bibliotecas declarativas a enfoques basados en compiladores, las deudas arquitectónicas ocultas que introducen y por qué la forma "aburrida" podría seguir siendo la mejor para aplicaciones profesionales.
+En esta publicación del blog, exploraremos el cambio de las bibliotecas declarativas a los enfoques basados en compiladores, las deudas arquitectónicas ocultas que introducen y por qué la forma "aburrida" podría seguir siendo la mejor para aplicaciones profesionales.
 
-## Una Breve Historia de la Traducción
+## Tabla de contenidos
 
-Para entender dónde estamos, tenemos que mirar hacia atrás y ver dónde empezamos.
+<TOC/>
 
-Alrededor de 2011–2012, el panorama de JavaScript era muy diferente. Los bundlers tal como los conocemos (Webpack, Vite) no existían o estaban en sus inicios. Estábamos pegando scripts directamente en el navegador. En esta era, nacieron bibliotecas como **i18next**.
+## Una breve historia de la internacionalización
 
-Resolvieron el problema de la única manera posible en ese momento: **Diccionarios en tiempo de ejecución**. Cargabas un objeto JSON masivo en memoria, y una función buscaba las claves al vuelo. Era confiable, explícito y funcionaba en todas partes.
+Para entender dónde estamos, debemos mirar hacia atrás y ver dónde comenzamos.
 
-Avanzando hasta hoy. Contamos con compiladores potentes (SWC, bundlers basados en Rust) que pueden analizar Árboles de Sintaxis Abstracta (AST) en milisegundos. Este poder dio origen a una nueva idea: _¿Por qué gestionamos las claves manualmente? ¿Por qué el compilador no puede simplemente ver el texto "Hello World" y reemplazarlo por nosotros?_
+Alrededor de 2011–2012, el panorama de JavaScript era muy diferente. Los bundlers tal como los conocemos (Webpack, Vite) no existían o estaban en sus inicios. Estábamos uniendo scripts directamente en el navegador. En esta época, nacieron bibliotecas como **i18next**.
+
+Resolvieron el problema de la única manera posible en ese momento: **Diccionarios en tiempo de ejecución**. Cargabas un objeto JSON enorme en memoria, y una función buscaba las claves sobre la marcha. Era fiable, explícito y funcionaba en todas partes.
+
+Avancemos hasta hoy. Contamos con compiladores potentes (SWC, bundlers basados en Rust) que pueden analizar Árboles de Sintaxis Abstracta (AST) en milisegundos. Este poder dio origen a una nueva idea: _¿Por qué gestionamos manualmente las claves? ¿Por qué el compilador no puede simplemente ver el texto "Hello World" y reemplazarlo por nosotros?_
 
 Así nació la i18n basada en compiladores.
 
+> **Ejemplo de i18n basado en compiladores:**
+>
+> - Paraglide (Módulos tree-shaken que compilan cada mensaje en una pequeña función ESM para que los bundlers puedan eliminar automáticamente locales y claves no usadas. Importas los mensajes como funciones en lugar de hacer búsquedas por claves de cadena.)
+> - LinguiJS (Compilador de macro a función que reescribe macros de mensajes como `<Trans>` en llamadas a funciones JS simples en tiempo de compilación. Obtienes sintaxis ICU/MessageFormat con una huella de ejecución muy pequeña.)
+> - Lingo.dev (Se enfoca en automatizar la canalización de localización inyectando contenido traducido directamente durante la compilación de tu aplicación React. Puede generar traducciones automáticamente usando IA e integrarse directamente en CI/CD.)
+> - Wuchale (Preprocesador orientado a Svelte que extrae texto en línea en archivos .svelte y lo compila en funciones de traducción sin envoltorios. Evita las claves de cadena y separa completamente la lógica de extracción de contenido del runtime principal de la aplicación.)
+> - Intlayer (Compilador / CLI de extracción que analiza tus componentes, genera diccionarios tipados y puede opcionalmente reescribir código para usar contenido explícito de Intlayer. El objetivo es usar el compilador para velocidad manteniendo un núcleo declarativo y agnóstico al framework.)
+
+> **Ejemplo de i18n declarativo:**
+>
+> - i18next / react-i18next / next-i18next (El estándar maduro de la industria que utiliza diccionarios JSON en tiempo de ejecución y un extenso ecosistema de plugins)
+> - react-intl (Parte de la biblioteca FormatJS, enfocada en la sintaxis estándar de mensajes ICU y un formateo estricto de datos)
+> - next-intl (Optimizado específicamente para Next.js con integración para el App Router y React Server Components)
+> - vue-i18n / @nuxt/i18n (La solución estándar del ecosistema Vue que ofrece bloques de traducción a nivel de componente e integración estrecha con la reactividad)
+> - svelte-i18n (Un envoltorio ligero alrededor de las stores de Svelte para traducciones reactivas en tiempo de ejecución)
+> - angular-translate (La biblioteca heredada de traducción dinámica que se basa en búsquedas de claves en tiempo de ejecución en lugar de la fusión en tiempo de compilación)
+> - angular-i18n (El enfoque nativo de Angular, adelantado en tiempo, que fusiona archivos XLIFF directamente en las plantillas durante la compilación)
+> - Tolgee (Combina código declarativo con un SDK en contexto para edición "click-to-translate" directamente en la interfaz de usuario)
+> - Intlayer (Enfoque por componente, usando archivos de declaraciones de contenido que permiten tree-shaking nativo y validación en TypeScript)
+
+## El Compilador de Intlayer
+
+Aunque **Intlayer** es una solución que fundamentalmente fomenta un **enfoque declarativo** para tu contenido, incluye un compilador para ayudar a acelerar el desarrollo o facilitar la creación rápida de prototipos.
+
+El compilador de Intlayer recorre el AST (Árbol de Sintaxis Abstracta) de tus componentes React, Vue o Svelte, así como otros archivos JavaScript/TypeScript. Su función es detectar cadenas de texto codificadas directamente y extraerlas en declaraciones dedicadas `.content`.
+
+> Para más detalles, consulta la documentación: [Documentación del Compilador Intlayer](https://github.com/aymericzip/intlayer/blob/main/docs/docs/es/compiler.md)
+
 ## El Atractivo del Compilador (El Enfoque "Mágico")
 
 Hay una razón por la cual este nuevo enfoque está en tendencia. Para un desarrollador, la experiencia se siente increíble.
 
-### 1. Velocidad y "Flujo"
+### 1. Velocidad y "Flow"
 
-Cuando estás concentrado, detenerte a pensar en un nombre de variable (`home_hero_title_v2`) rompe tu flujo. Con un enfoque basado en compilador, escribes `<p>Welcome back</p>` y sigues adelante. La fricción es cero.
+Cuando estás en la zona, detenerte a pensar en un nombre de variable semántico (`home_hero_title_v2`) rompe tu flujo. Con un enfoque de compilador, escribes `<p>Welcome back</p>` y sigues adelante. La fricción es cero.
 
 ### 2. La Misión de Rescate del Legado
 
@@ -59,79 +91,130 @@ Este es un beneficio moderno que no deberíamos pasar por alto. Los asistentes d
 - **Declarativo:** Tienes que reescribir la salida de la IA para reemplazar el texto con claves.
 - **Compilador:** Copias y pegas el código de la IA, y simplemente funciona.
 
-## La Verificación de la Realidad: Por Qué la "Magia" es Peligrosa
+## La Verificación de la Realidad: Por qué la "Magia" es Peligrosa
 
 Aunque la "magia" es atractiva, la abstracción tiene fugas. Confiar en una herramienta de compilación para entender la intención humana introduce fragilidad arquitectónica.
 
-### 1. Fragilidad Heurística (El Juego de Adivinar)
+### Fragilidad Heurística (El Juego de Adivinar)
+
+El compilador tiene que adivinar qué es contenido y qué es código. Esto conduce a casos límite donde terminas "luchando" contra la herramienta.
+
+Considera estos escenarios:
+
+- ¿Se extrae `<span className="active"></span>`? (Es una cadena, pero probablemente una clase).
+- ¿Se extrae `<span status="pending"></span>`? (Es un valor de prop).
+- ¿Se extrae `<span>{"Hello World"}</span>`? (Es una expresión JS).
+- ¿Se extrae `<span>Hello {name}. How are you?</span>`? (La interpolación es compleja).
+- ¿Se extrae `<span aria-label="Image of cat"></span>`? (Los atributos de accesibilidad necesitan traducción).
+- ¿Se extrae `<span data-testid="my-element"></span>`? (Los IDs de prueba NO deben traducirse).
+- ¿Se extrae `<MyComponent errorMessage="An error occurred" />`?
+- ¿Se extrae `<p>This is a paragraph{" "}\n containing multiple lines</p>`?
+- ¿Se extrae el resultado de la función `<p>{getStatusMessage()}</p>`?
+- ¿Se extrae `<div>{isLoading ? "The page is loading" : <MyComponent/>} </div>`?
+- ¿Se extrae un ID de producto como `<span>AX-99</span>`?
+
+Inevitablemente terminas agregando comentarios específicos (como `// ignore-translation`, o props específicos como `data-compiler-ignore="true"`) para evitar que rompa la lógica de tu aplicación.
+
+### ¿Cómo maneja Intlayer esta complejidad?
+
+Intlayer utiliza un enfoque mixto para detectar si un campo debe ser extraído para traducción, intentando minimizar los falsos positivos:
+
+1.  **Análisis AST:** Verifica el tipo de elemento (por ejemplo, distinguiendo entre un `reactNode`, una `label` o una propiedad `title`).
+2.  **Reconocimiento de patrones:** Detecta si la cadena está en mayúscula o incluye espacios, lo que sugiere que probablemente sea texto legible por humanos en lugar de un identificador de código.
 
-El compilador tiene que adivinar qué es contenido y qué es código.
+### El límite estricto de datos dinámicos
 
-- ¿Se traduce `className="active"`? Es una cadena.
-- ¿Se traduce `status="pending"`?
-- ¿Se traduce `<MyComponent errorMessage="An error occurred" />`?
-- ¿Se traduce un ID de producto como `"AX-99"`?
+La extracción del compilador se basa en el **análisis estático**. Debe ver la cadena literal en tu código para generar un ID estable.
+Si tu API devuelve una cadena de código de error como `server_error`, no puedes traducirla con un compilador porque el compilador no sabe que esa cadena existe en tiempo de compilación. Estás obligado a construir un sistema secundario "solo en tiempo de ejecución" únicamente para datos dinámicos.
 
-Inevitablemente terminas "peleando" con el compilador, añadiendo comentarios específicos (como `// ignore-translation`) para evitar que rompa la lógica de tu aplicación.
+### Falta de segmentación (chunking)
 
-### 2. El Límite Rígido de los Datos Dinámicos
+Ciertos compiladores no segmentan las traducciones por página. Si tu compilador genera un archivo JSON grande por idioma (por ejemplo, `./lang/en.json`, `./lang/fr.json`, etc.), probablemente terminarás cargando contenido de todas tus páginas para una sola página visitada. Además, cada componente que use tu contenido probablemente será hidratado con mucho más contenido del necesario, lo que puede causar problemas de rendimiento.
 
-La extracción del compilador se basa en **análisis estático**. Debe ver la cadena literal en tu código para generar un ID estable.
-Si tu API devuelve un código de error como `server_error`, no puedes traducirlo con un compilador porque este no sabe que esa cadena existe en tiempo de compilación. Te ves obligado a construir un sistema secundario "solo en tiempo de ejecución" solo para datos dinámicos.
+También tenga cuidado al cargar sus traducciones dinámicamente. Si esto no se hace, cargará contenido para todos los idiomas además del actual.
 
-### 3. "Explosión de Chunks" y Cascadas en la Red
+> Para ilustrar el problema, considere un sitio con 10 páginas y 10 idiomas (todos 100% únicos). Cargaría contenido para 99 páginas adicionales (10 × 10 - 1).
 
-Para permitir el tree-shaking, las herramientas del compilador a menudo dividen las traducciones por componente.
+### "Explosión de chunks" y cascadas de red
 
-- **La consecuencia:** Una vista de página única con 50 componentes pequeños podría desencadenar **50 solicitudes HTTP separadas** para pequeños fragmentos de traducción. Incluso con HTTP/2, esto crea una cascada de red que hace que tu aplicación se sienta lenta en comparación con cargar un único paquete de idioma optimizado.
+Para resolver el problema del chunking, algunas soluciones ofrecen chunking por componente, o incluso por clave. Sin embargo, el problema solo se resuelve parcialmente. El argumento de venta de estas soluciones suele ser decir "Tu contenido está tree-shakeado."
 
-### 4. Sobrecarga de rendimiento en tiempo de ejecución
+De hecho, si cargas contenido estáticamente, tu solución eliminará el contenido no utilizado, pero aún así terminarás con contenido de todos los idiomas cargado con tu aplicación.
 
-Para hacer que las traducciones sean reactivas (para que se actualicen instantáneamente cuando cambias de idioma), el compilador a menudo inyecta hooks de gestión de estado en _cada_ componente.
+Entonces, ¿por qué no cargarlo dinámicamente? Sí, en ese caso cargarás más contenido del necesario, pero no está exento de compromisos.
 
-- **El costo:** Si renderizas una lista de 5,000 elementos, estás inicializando 5,000 hooks `useState` y `useEffect` únicamente para el texto. Esto consume memoria y ciclos de CPU que las librerías declarativas (que típicamente usan un único proveedor de Context) ahorran.
+Cargar contenido dinámicamente aísla cada fragmento de contenido en su propio chunk, que solo se cargará cuando el componente se renderice. Esto significa que harás una solicitud HTTP por cada bloque de texto. ¿1,000 bloques de texto en tu página? → 1,000 solicitudes HTTP a tus servidores. Y para limitar el daño y optimizar el tiempo de la primera renderización de tu aplicación, necesitarás insertar múltiples límites de Suspense o Skeleton Loaders.
+
+> Nota: Incluso con Next.js y SSR, tus componentes aún se hidratarán después de la carga, por lo que las solicitudes HTTP seguirán realizándose.
+
+¿La solución? Adoptar una solución que permita declarar declaraciones de contenido con ámbito, como lo hacen `i18next`, `next-intl` o `intlayer`.
+
+> Nota: `i18next` y `next-intl` requieren que gestiones manualmente las importaciones de tus namespaces / mensajes para cada página con el fin de optimizar el tamaño de tu bundle. Deberías usar un analizador de bundles como `rollup-plugin-visualizer` (vite), `@next/bundle-analyzer` (next.js) o `webpack-bundle-analyzer` (React CRA / Angular / etc) para detectar si estás contaminando tu bundle con traducciones no usadas.
+
+### Sobrecarga de Rendimiento en Tiempo de Ejecución
+
+Para hacer que las traducciones sean reactivas (de modo que se actualicen instantáneamente cuando cambias de idioma), el compilador a menudo inyecta hooks de gestión de estado en cada componente.
+
+- **El costo:** Si renderizas una lista de 5,000 elementos, estarás inicializando 5,000 hooks `useState` y `useEffect` únicamente para el texto. React debe identificar y volver a renderizar los 5,000 consumidores simultáneamente. Esto provoca un bloqueo masivo del "Main Thread", congelando la interfaz durante el cambio. Esto consume memoria y ciclos de CPU que las librerías declarativas (que típicamente usan un único proveedor de Context) ahorran.
+
+> Ten en cuenta que el problema es similar para otros frameworks que no sean React.
 
 ## La trampa: Vendor Lock-in
 
-Este es, sin duda, el aspecto más peligroso de la i18n basada en compiladores.
+Ten cuidado al elegir una solución i18n que permita la extracción o migración de las claves de traducción.
 
-En una librería declarativa, tu código fuente contiene la intención explícita. Tú posees las claves. Si cambias de librería, solo cambias la importación.
+En el caso de una biblioteca declarativa, tu código fuente contiene explícitamente tu intención de traducción: estas son tus claves, y tú las controlas. Si deseas cambiar de biblioteca, generalmente solo necesitas actualizar la importación.
 
-En un enfoque basado en compiladores, **tu código fuente es solo texto en inglés.** La "lógica de traducción" solo existe dentro de la configuración del plugin de compilación.
-Si esa biblioteca deja de mantenerse, o si la superas, quedas atrapado. No puedes "expulsar" fácilmente porque no tienes ninguna clave de traducción en tu código fuente. Tendrías que reescribir manualmente toda tu aplicación para migrar.
+Con un enfoque de compilador, tu código fuente podría ser solo texto en inglés plano, sin rastro de lógica de traducción: todo está oculto en la configuración de la herramienta de construcción. Si ese plugin deja de mantenerse o quieres cambiar de solución, podrías quedarte atascado. No hay una forma fácil de "expulsar": no hay claves utilizables en tu código, y podrías necesitar regenerar todas tus traducciones para una nueva biblioteca.
+
+Algunas soluciones también ofrecen servicios de generación de traducciones. ¿No más créditos? No más traducciones.
+
+Los compiladores a menudo generan un hash del texto (por ejemplo, `"Hello World"` -> `x7f2a`). Tus archivos de traducción se ven como `{ "x7f2a": "Hola Mundo" }`. La trampa: si cambias de librería, la nueva librería ve `"Hello World"` y busca esa clave. No la encontrará porque tu archivo de traducción está lleno de hashes (`x7f2a`).
+
+### Bloqueo de Plataforma
+
+Al elegir un enfoque basado en compilador, te encierras en la plataforma subyacente. Por ejemplo, ciertos compiladores no están disponibles para todos los bundlers (como Vite, Turbopack o Metro). Esto puede dificultar las migraciones futuras y es posible que necesites adoptar múltiples soluciones para cubrir todas tus aplicaciones.
 
 ## El Otro Lado: Riesgos del Enfoque Declarativo
 
-Para ser justos, la forma declarativa tradicional tampoco es perfecta. Tiene su propio conjunto de "peligros".
+Para ser justos, la forma tradicional declarativa tampoco es perfecta. Tiene su propio conjunto de "peligros ocultos".
 
-1.  **Infierno de Espacios de Nombres:** A menudo tienes que gestionar manualmente qué archivos JSON cargar (`common.json`, `dashboard.json`, `footer.json`). Si olvidas uno, el usuario ve las claves sin procesar.
-2.  **Sobre-carga de Datos:** Sin una configuración cuidadosa, es muy fácil cargar accidentalmente _todas_ tus claves de traducción para _todas_ las páginas en la carga inicial, inflando el tamaño de tu paquete.
-3.  **Deriva de sincronización:** Es común que las claves permanezcan en el archivo JSON mucho después de que el componente que las usaba haya sido eliminado. Tus archivos de traducción crecen indefinidamente, llenos de "claves zombis".
+1.  **Infierno de Namespaces:** A menudo tienes que gestionar manualmente qué archivos JSON cargar (`common.json`, `dashboard.json`, `footer.json`). Si olvidas uno, el usuario verá las claves sin traducir.
+2.  **Sobrecarga de datos:** Sin una configuración cuidadosa, es muy fácil cargar accidentalmente _todas_ tus claves de traducción para _todas_ las páginas en la carga inicial, lo que hincha el tamaño de tu paquete.
+3.  **Desincronización:** Es común que las claves permanezcan en el archivo JSON mucho después de que el componente que las usaba haya sido eliminado. Tus archivos de traducción crecen indefinidamente, llenos de "claves zombis".
 
 ## El punto medio de Intlayer
 
 Aquí es donde herramientas como **Intlayer** están intentando innovar. Intlayer entiende que, aunque los compiladores son poderosos, la magia implícita es peligrosa.
 
-Intlayer ofrece un comando único **`transform`**. En lugar de hacer magia solo en el paso oculto de compilación, puede realmente **reescribir el código de tu componente**. Escanea tu texto y lo reemplaza con declaraciones explícitas de contenido en tu base de código.
+Intlayer ofrece un enfoque mixto, que te permite beneficiarte de las ventajas de ambos enfoques: gestión declarativa de contenido, también compatible con su compilador para ahorrar tiempo de desarrollo.
 
-Esto te da lo mejor de ambos mundos:
+E incluso si no usas el compilador de Intlayer, Intlayer ofrece un comando `transform` (también accesible mediante la extensión de VSCode). En lugar de hacer magia en un paso oculto de compilación, puede realmente **reescribir el código de tu componente**. Escanea tu texto y lo reemplaza con declaraciones explícitas de contenido en tu base de código.
+
+Esto te ofrece lo mejor de ambos mundos:
 
 1.  **Granularidad:** Mantienes tus traducciones cerca de tus componentes (mejorando la modularidad y el tree-shaking).
 2.  **Seguridad:** La traducción se convierte en código explícito, no en magia oculta en tiempo de compilación.
-3.  **Sin dependencia:** Dado que el código se transforma en una estructura declarativa estándar dentro de tu repositorio, no estás ocultando lógica en un plugin de webpack.
+3.  **Sin dependencia:** Dado que el código se transforma en una estructura declarativa dentro de tu repositorio, puedes fácilmente presionar tab, o usar el copilot de tu IDE, para generar tus declaraciones de contenido, no estás ocultando lógica en un plugin de webpack.
 
 ## Conclusión
 
 Entonces, ¿cuál deberías elegir?
 
-**Si eres un desarrollador junior, un fundador en solitario o estás construyendo un MVP:**  
-El enfoque basado en compiladores es una opción válida. Te permite avanzar increíblemente rápido. No necesitas preocuparte por la estructura de archivos o las claves. Simplemente construyes. La deuda técnica es un problema para el "Tú del futuro".
+**Si estás construyendo un MVP, o quieres avanzar rápidamente:**
+El enfoque basado en compilador es una opción válida. Te permite avanzar increíblemente rápido. No necesitas preocuparte por la estructura de archivos o las claves. Simplemente construyes. La deuda técnica es un problema para el "Tú del futuro".
+
+**Si eres un desarrollador junior, o no te importa la optimización:**
+Si quieres la menor gestión manual, probablemente el enfoque basado en compilador sea el mejor. No necesitarás manejar claves o archivos de traducción tú mismo; solo escribe texto y el compilador automatiza el resto. Esto reduce el esfuerzo de configuración y los errores comunes de i18n ligados a pasos manuales.
+
+**Si estás internacionalizando un proyecto existente que ya incluye miles de componentes para refactorizar:**
+Un enfoque basado en compilador puede ser una opción pragmática aquí. La fase inicial de extracción puede ahorrar semanas o meses de trabajo manual. Sin embargo, considera usar una herramienta como el comando `transform` de Intlayer, que puede extraer cadenas y convertirlas en declaraciones explícitas de contenido declarativo. Esto te brinda la velocidad de la automatización mientras mantienes la seguridad y portabilidad de un enfoque declarativo. Obtienes lo mejor de ambos mundos: una migración inicial rápida sin deuda arquitectónica a largo plazo.
 
-**Si estás construyendo una aplicación profesional, de nivel empresarial:**  
+**Si estás construyendo una Aplicación Profesional de Nivel Empresarial:**
 La magia generalmente es una mala idea. Necesitas control.
 
-- Necesitas manejar datos dinámicos desde backends.
+- Necesitas manejar datos dinámicos desde los backends.
 - Necesitas asegurar el rendimiento en dispositivos de gama baja (evitando explosiones de hooks).
-- Necesitas asegurarte de no quedar atrapado para siempre en una herramienta de construcción específica.
+- Necesitas asegurarte de no quedar atrapado para siempre en una herramienta de compilación específica.
 
-Para aplicaciones profesionales, la **Gestión Declarativa de Contenidos** (como Intlayer o bibliotecas establecidas) sigue siendo el estándar de oro. Separa tus preocupaciones, mantiene tu arquitectura limpia y garantiza que la capacidad de tu aplicación para hablar múltiples idiomas no dependa de un compilador "caja negra" que adivine tus intenciones.
+Para aplicaciones profesionales, la **Gestión Declarativa de Contenido** (como Intlayer o bibliotecas establecidas) sigue siendo el estándar de oro. Separa tus preocupaciones, mantiene tu arquitectura limpia y garantiza que la capacidad de tu aplicación para hablar múltiples idiomas no dependa de un compilador "caja negra" que adivine tus intenciones.

package/blog/fr/compiler_vs_declarative_i18n.md

@@ -18,120 +18,203 @@ slugs:
   - compiler-vs-declarative-i18n
 ---
 
-# Les arguments pour et contre l’i18n basée sur un compilateur
+# Les arguments pour et contre l'i18n basée sur un compilateur
 
-Si vous développez des applications web depuis plus d’une décennie, vous savez que l’internationalisation (i18n) a toujours été un point de friction. C’est souvent la tâche que personne ne veut faire : extraire les chaînes, gérer les fichiers JSON, et se soucier des règles de pluriel.
+Si vous développez des applications web depuis plus d'une décennie, vous savez que l'internationalisation (i18n) a toujours été un point de friction. C'est souvent la tâche que personne ne veut faire : extraire les chaînes, gérer les fichiers JSON, et se soucier des règles de pluriel.
 
-Récemment, une nouvelle vague d’outils i18n « basés sur un compilateur » a émergé, promettant de faire disparaître cette douleur. L’argument est séduisant : **Il suffit d’écrire le texte dans vos composants, et laissez l’outil de build gérer le reste.** Pas de clés, pas d’importations, juste de la magie.
+Récemment, une nouvelle vague d’**outils i18n basés sur un compilateur** a émergé, promettant de faire disparaître cette douleur. L’argument est séduisant : **Il suffit d’écrire le texte dans vos composants, et laissez l’outil de build gérer le reste.** Pas de clés, pas d’importations, juste de la magie.
 
 Mais comme pour toutes les abstractions en ingénierie logicielle, la magie a un prix.
 
-Dans cet article de blog, nous allons explorer le passage des bibliothèques déclaratives aux approches basées sur un compilateur, les dettes architecturales cachées qu’elles introduisent, et pourquoi la méthode « ennuyeuse » pourrait encore être la meilleure pour les applications professionnelles.
+Dans cet article de blog, nous allons explorer le passage des bibliothèques déclaratives aux approches basées sur un compilateur, les dettes architecturales cachées qu'elles introduisent, et pourquoi la méthode « ennuyeuse » pourrait encore être la meilleure pour les applications professionnelles.
 
-## Une brève histoire de la traduction
+## Table des matières
+
+<TOC/>
+
+## Un bref historique de l'internationalisation
 
 Pour comprendre où nous en sommes, il faut revenir à nos débuts.
 
-Vers 2011–2012, le paysage JavaScript était très différent. Les bundlers tels que nous les connaissons (Webpack, Vite) n’existaient pas ou étaient à leurs débuts. Nous collions les scripts ensemble dans le navigateur. C’est à cette époque que des bibliothèques comme **i18next** sont nées.
+Vers 2011–2012, le paysage JavaScript était très différent. Les bundlers tels que nous les connaissons aujourd’hui (Webpack, Vite) n’existaient pas ou étaient à leurs débuts. Nous collions les scripts directement dans le navigateur. C’est à cette époque que des bibliothèques comme **i18next** sont nées.
 
-Elles ont résolu le problème de la seule manière possible à l’époque : les **Dictionnaires à l’exécution**. Vous chargiez un énorme objet JSON en mémoire, et une fonction recherchait les clés à la volée. C’était fiable, explicite, et fonctionnait partout.
+Elles ont résolu le problème de la seule manière possible à l’époque : **les dictionnaires à l’exécution**. Vous chargiez un énorme objet JSON en mémoire, et une fonction recherchait les clés à la volée. C’était fiable, explicite, et fonctionnait partout.
 
 Avançons jusqu’à aujourd’hui. Nous disposons de compilateurs puissants (SWC, bundlers basés sur Rust) capables d’analyser des arbres de syntaxe abstraite (AST) en quelques millisecondes. Cette puissance a donné naissance à une nouvelle idée : _Pourquoi gérer manuellement les clés ? Pourquoi le compilateur ne pourrait-il pas simplement voir le texte "Hello World" et le remplacer pour nous ?_
 
 Ainsi est née l’i18n basée sur un compilateur.
 
-## L’Attrait du Compilateur (L’Approche "Magique")
+> **Exemple d’i18n basée sur un compilateur :**
+>
+> - Paraglide (Modules tree-shaken qui compilent chaque message en une petite fonction ESM afin que les bundlers puissent automatiquement éliminer les locales et clés inutilisées. Vous importez les messages sous forme de fonctions au lieu de faire des recherches par clé de chaîne.)
+> - LinguiJS (Compilateur macro-vers-fonction qui réécrit les macros de message comme `<Trans>` en appels de fonctions JS simples au moment de la compilation. Vous obtenez la syntaxe ICU/MessageFormat avec une empreinte runtime très réduite.)
+> - Lingo.dev (Se concentre sur l’automatisation du pipeline de localisation en injectant le contenu traduit directement lors de la compilation de votre application React. Il peut générer automatiquement des traductions via l’IA et s’intégrer directement dans le CI/CD.)
+> - Wuchale (Préprocesseur orienté Svelte qui extrait le texte en ligne dans les fichiers .svelte et le compile en fonctions de traduction sans wrapper. Il évite les clés de chaîne et sépare complètement la logique d'extraction de contenu du runtime principal de l'application.)
+> - Intlayer (Compilateur / CLI d'extraction qui analyse vos composants, génère des dictionnaires typés, et peut optionnellement réécrire le code pour utiliser explicitement le contenu Intlayer. L'objectif est d'utiliser le compilateur pour la rapidité tout en conservant un noyau déclaratif et agnostique au framework.)
+>
+> **Exemple d’i18n déclarative :**
+>
+> - i18next / react-i18next / next-i18next (La norme industrielle mature utilisant des dictionnaires JSON au runtime et un écosystème étendu de plugins)
+> - react-intl (Fait partie de la bibliothèque FormatJS, se concentrant sur la syntaxe standard des messages ICU et un formatage strict des données)
+> - next-intl (Optimisé spécifiquement pour Next.js avec intégration pour l'App Router et les React Server Components)
+> - vue-i18n / @nuxt/i18n (La solution standard de l'écosystème Vue offrant des blocs de traduction au niveau des composants et une intégration étroite de la réactivité)
+> - svelte-i18n (Un wrapper léger autour des stores Svelte pour des traductions réactives à l'exécution)
+> - angular-translate (La bibliothèque de traduction dynamique héritée reposant sur la recherche de clés à l'exécution plutôt que sur la fusion à la compilation)
+> - angular-i18n (L'approche native d'Angular, en avance sur le temps, fusionnant les fichiers XLIFF directement dans les templates lors de la compilation)
+> - Tolgee (Combine un code déclaratif avec un SDK en contexte pour une édition "click-to-translate" directement dans l'interface utilisateur)
+> - Intlayer (Approche par composant, utilisant des fichiers de déclarations de contenu permettant le tree-shaking natif et la validation TypeScript)
+
+## Le compilateur Intlayer
+
+Bien que **Intlayer** soit une solution qui encourage fondamentalement une **approche déclarative** de votre contenu, elle inclut un compilateur pour aider à accélérer le développement ou faciliter le prototypage rapide.
+
+Le compilateur Intlayer parcourt l'AST (Abstract Syntax Tree) de vos composants React, Vue ou Svelte, ainsi que d'autres fichiers JavaScript/TypeScript. Son rôle est de détecter les chaînes de caractères codées en dur et de les extraire dans des déclarations dédiées `.content`.
+
+> Pour plus de détails, consultez la documentation : [Intlayer Compiler Docs](https://github.com/aymericzip/intlayer/blob/main/docs/docs/fr/compiler.md)
+
+## L'Attrait du Compilateur (L'Approche "Magique")
 
-Il y a une raison pour laquelle cette nouvelle approche est tendance. Pour un développeur, l’expérience est incroyable.
+Il y a une raison pour laquelle cette nouvelle approche est tendance. Pour un développeur, l'expérience est incroyable.
 
 ### 1. Vitesse et "Flow"
 
-Quand vous êtes dans votre zone, vous arrêter pour réfléchir à un nom de variable (`home_hero_title_v2`) casse votre flow. Avec une approche compilateur, vous tapez `<p>Welcome back</p>` et continuez. La friction est nulle.
+Quand vous êtes dans votre zone, vous arrêter pour réfléchir à un nom de variable sémantique (`home_hero_title_v2`) casse votre flow. Avec une approche compilateur, vous tapez `<p>Welcome back</p>` et continuez. La friction est nulle.
 
 ### 2. La Mission de Sauvetage du Legacy
 
-Imaginez hériter d’une énorme base de code avec 5 000 composants et aucune traduction. Adapter cela avec un système manuel basé sur des clés est un cauchemar qui dure des mois. Un outil basé sur un compilateur agit comme une stratégie de sauvetage, extrayant instantanément des milliers de chaînes sans que vous ayez besoin de toucher un seul fichier manuellement.
+Imaginez hériter d'une immense base de code avec 5 000 composants et aucune traduction. Adapter cela avec un système manuel basé sur des clés est un cauchemar qui dure des mois. Un outil basé sur un compilateur agit comme une stratégie de sauvetage, extrayant instantanément des milliers de chaînes sans que vous ayez besoin de toucher un seul fichier manuellement.
 
-### 3. L’Ère de l’IA
+### 3. L'ère de l'IA
 
-C’est un avantage moderne qu’il ne faut pas négliger. Les assistants de codage IA (comme Copilot ou ChatGPT) génèrent naturellement du JSX/HTML standard. Ils ne connaissent pas votre schéma spécifique de clés de traduction.
+C'est un avantage moderne qu'il ne faut pas négliger. Les assistants de codage IA (comme Copilot ou ChatGPT) génèrent naturellement du JSX/HTML standard. Ils ne connaissent pas votre schéma spécifique de clés de traduction.
 
-- **Déclaratif :** Vous devez réécrire la sortie de l’IA pour remplacer le texte par des clés.
-- **Compilateur :** Vous copiez-collez le code de l’IA, et ça fonctionne tout simplement.
+- **Déclaratif :** Vous devez réécrire la sortie de l'IA pour remplacer le texte par des clés.
+- **Compilateur :** Vous copiez-collez le code de l'IA, et ça fonctionne simplement.
 
-## La Réalité : Pourquoi la "Magie" est Dangereuse
+## Le Réalisme : Pourquoi la "Magie" est Dangereuse
 
-Bien que la "magie" soit séduisante, l’abstraction fuit. Compter sur un outil de build pour comprendre l’intention humaine introduit une fragilité architecturale.
+Bien que la "magie" soit séduisante, l'abstraction présente des fuites. Compter sur un outil de build pour comprendre l'intention humaine introduit une fragilité architecturale.
 
-### 1. Fragilité Heuristique (Le Jeu de Deviner)
+### Fragilité heuristique (Le jeu de devinettes)
 
-Le compilateur doit deviner ce qui est contenu et ce qui est code.
+Le compilateur doit deviner ce qui est contenu et ce qui est code. Cela conduit à des cas limites où vous vous retrouvez à "lutter" contre l'outil.
 
-- Est-ce que `className="active"` est traduit ? C’est une chaîne de caractères.
-- Est-ce que `status="pending"` est traduit ?
-- Est-ce que `<MyComponent errorMessage="An error occurred" />` est traduit ?
-- Est-ce qu’un identifiant produit comme `"AX-99"` est traduit ?
+Considérez ces scénarios :
 
-Vous finissez inévitablement par « lutter » contre le compilateur, en ajoutant des commentaires spécifiques (comme `// ignore-translation`) pour l’empêcher de casser la logique de votre application.
+- Est-ce que `<span className="active"></span>` est extrait ? (C'est une chaîne, mais probablement une classe).
+- Est-ce que `<span status="pending"></span>` est extrait ? (C'est une valeur de prop).
+- Est-ce que `<span>{"Hello World"}</span>` est extrait ? (C'est une expression JS).
+- Est-ce que `<span>Hello {name}. How are you?</span>` est extrait ? (L'interpolation est complexe).
+- Est-ce que `<span aria-label="Image of cat"></span>` est extrait ? (Les attributs d'accessibilité nécessitent une traduction).
+- Est-ce que `<span data-testid="my-element"></span>` est extrait ? (Les IDs de test NE DOIVENT PAS être traduits).
+- Est-ce que `<MyComponent errorMessage="An error occurred" />` est extrait ?
+- Est-ce que `<p>This is a paragraph{" "}\n containing multiple lines</p>` est extrait ?
+- Est-ce que le résultat de la fonction `<p>{getStatusMessage()}</p>` est extrait ?
+- Est-ce que `<div>{isLoading ? "The page is loading" : <MyComponent/>} </div>` est extrait ?
+- Est-ce qu’un ID produit comme `<span>AX-99</span>` est extrait ?
 
-### 2. La limite stricte des données dynamiques
+Vous finissez inévitablement par ajouter des commentaires spécifiques (comme `// ignore-translation`, ou des props spécifiques comme `data-compiler-ignore="true"`) pour éviter que cela ne casse la logique de votre application.
+
+### Comment Intlayer gère-t-il cette complexité ?
+
+Intlayer utilise une approche mixte pour détecter si un champ doit être extrait pour traduction, en tentant de minimiser les faux positifs :
+
+1.  **Analyse AST :** Il vérifie le type d’élément (par exemple, en distinguant entre un `reactNode`, un `label` ou une prop `title`).
+2.  **Reconnaissance de motifs :** Il détecte si la chaîne est en majuscule ou contient des espaces, ce qui suggère qu’il s’agit probablement d’un texte lisible par un humain plutôt que d’un identifiant de code.
+
+### La limite stricte des données dynamiques
 
 L’extraction par le compilateur repose sur une **analyse statique**. Il doit voir la chaîne littérale dans votre code pour générer un ID stable.
-Si votre API renvoie une chaîne de code d’erreur comme `server_error`, vous ne pouvez pas la traduire avec un compilateur car celui-ci ne connaît pas cette chaîne au moment de la compilation. Vous êtes obligé de construire un système secondaire « runtime-only » uniquement pour les données dynamiques.
+Si votre API renvoie une chaîne de code d'erreur comme `server_error`, vous ne pouvez pas la traduire avec un compilateur car ce dernier ne sait pas que cette chaîne existe au moment de la compilation. Vous êtes obligé de créer un système secondaire "runtime-only" uniquement pour les données dynamiques.
+
+### Manque de découpage en chunks
+
+Certains compilateurs ne découpent pas les traductions par page. Si votre compilateur génère un gros fichier JSON par langue (par exemple, `./lang/en.json`, `./lang/fr.json`, etc.), vous risquez de charger le contenu de toutes vos pages pour une seule page visitée. De plus, chaque composant utilisant votre contenu sera probablement hydraté avec beaucoup plus de contenu que nécessaire, ce qui peut entraîner des problèmes de performance.
+
+Faites également attention à charger vos traductions de manière dynamique. Si cela n'est pas fait, vous chargerez le contenu de toutes les langues en plus de celle en cours.
 
-### 3. « Explosion des chunks » et cascades réseau
+> Pour illustrer le problème, considérez un site avec 10 pages et 10 langues (toutes 100 % uniques). Vous chargeriez le contenu de 99 pages supplémentaires (10 × 10 - 1).
 
-Pour permettre le tree-shaking, les outils de compilation divisent souvent les traductions par composant.
+### « Explosion de chunks » et cascades réseau
 
-- **La conséquence :** Une seule vue de page avec 50 petits composants peut déclencher **50 requêtes HTTP distinctes** pour de petits fragments de traduction. Même avec HTTP/2, cela crée un effet de cascade réseau qui rend votre application lente comparée au chargement d’un seul bundle de langue optimisé.
+Pour résoudre le problème du chunking, certaines solutions proposent un découpage par composant, voire par clé. Pourtant, le problème n'est que partiellement résolu. L'argument de vente de ces solutions est souvent de dire « Votre contenu est tree-shaké ».
 
-### 4. Surcharge des performances à l’exécution
+En effet, si vous chargez le contenu statiquement, votre solution éliminera le contenu inutilisé, mais vous finirez quand même avec le contenu de toutes les langues chargé avec votre application.
 
-Pour rendre les traductions réactives (afin qu’elles se mettent à jour instantanément lorsque vous changez de langue), le compilateur injecte souvent des hooks de gestion d’état dans _chaque_ composant.
+Alors pourquoi ne pas le charger dynamiquement ? Oui, dans ce cas, vous chargerez plus de contenu que nécessaire, mais ce n'est pas sans compromis.
 
-- **Le Coût :** Si vous affichez une liste de 5 000 éléments, vous initialisez 5 000 hooks `useState` et `useEffect` uniquement pour le texte. Cela consomme de la mémoire et des cycles CPU que les bibliothèques déclaratives (qui utilisent généralement un seul fournisseur Context) économisent.
+Le chargement dynamique du contenu isole chaque morceau de contenu dans son propre chunk, qui ne sera chargé que lorsque le composant est rendu. Cela signifie que vous ferez une requête HTTP par bloc de texte. 1 000 blocs de texte sur votre page ? → 1 000 requêtes HTTP vers vos serveurs. Et pour limiter les dégâts et optimiser le temps de rendu initial de votre application, vous devrez insérer plusieurs frontières de Suspense ou des Skeleton Loaders.
 
-## Le Piège : Le Verrouillage Fournisseur
+> Note : Même avec Next.js et le SSR, vos composants seront toujours hydratés après le chargement, donc les requêtes HTTP seront toujours effectuées.
 
-C'est sans doute l'aspect le plus dangereux de l'i18n basée sur un compilateur.
+La solution ? Adopter une solution qui permet de déclarer des contenus à portée locale, comme le font `i18next`, `next-intl` ou `intlayer`.
 
-Dans une bibliothèque déclarative, votre code source contient une intention explicite. Vous possédez les clés. Si vous changez de bibliothèque, vous changez simplement l'import.
+> Note : `i18next` et `next-intl` exigent que vous gériez manuellement l'importation de vos namespaces / messages pour chaque page afin d'optimiser la taille de votre bundle. Vous devriez utiliser un analyseur de bundle comme `rollup-plugin-visualizer` (vite), `@next/bundle-analyzer` (next.js), ou `webpack-bundle-analyzer` (React CRA / Angular / etc) pour détecter si vous polluez votre bundle avec des traductions inutilisées.
 
-Dans une approche basée sur un compilateur, **votre code source n'est que du texte en anglais.** La "logique de traduction" n'existe que dans la configuration du plugin de build.
-Si cette bibliothèque cesse d’être maintenue, ou si vous la dépassez, vous êtes bloqué. Vous ne pouvez pas facilement « éjecter » car vous n’avez aucune clé de traduction dans votre code source. Vous devriez réécrire manuellement toute votre application pour migrer.
+### Surcharge de performance à l'exécution
 
-## L’autre côté : risques de l’approche déclarative
+Pour rendre les traductions réactives (afin qu'elles se mettent à jour instantanément lorsque vous changez de langue), le compilateur injecte souvent des hooks de gestion d'état dans chaque composant.
+
+- **Le coût :** Si vous affichez une liste de 5 000 éléments, vous initialisez 5 000 hooks `useState` et `useEffect` uniquement pour le texte. React doit identifier et re-render tous les 5 000 consommateurs simultanément. Cela provoque un blocage massif du "Main Thread", gelant l'interface utilisateur pendant le changement. Cela consomme de la mémoire et des cycles CPU que les bibliothèques déclaratives (qui utilisent généralement un seul fournisseur Context) économisent.
+
+> Notez que le problème est similaire pour d'autres frameworks que React.
+
+## Le piège : l'enfermement fournisseur
+
+Faites attention à choisir une solution i18n qui permet l'extraction ou la migration des clés de traduction.
+
+Dans le cas d'une bibliothèque déclarative, votre code source contient explicitement votre intention de traduction : ce sont vos clés, et vous les contrôlez. Si vous souhaitez changer de bibliothèque, il vous suffit généralement de mettre à jour l'import.
+
+Avec une approche compilateur, votre code source peut être simplement du texte en anglais, sans aucune trace de logique de traduction : tout est caché dans la configuration de l'outil de build. Si ce plugin n'est plus maintenu ou si vous souhaitez changer de solution, vous pourriez être bloqué. Il n'y a pas de moyen simple de "détacher" : il n'y a pas de clés utilisables dans votre code, et vous pourriez devoir régénérer toutes vos traductions pour une nouvelle bibliothèque.
+
+Certaines solutions proposent également des services de génération de traduction. Plus de crédits ? Plus de traductions.
+
+Les compilateurs hachent souvent le texte (par exemple, `"Hello World"` -> `x7f2a`). Vos fichiers de traduction ressemblent à `{ "x7f2a": "Hola Mundo" }`. Le piège : si vous changez de bibliothèque, la nouvelle bibliothèque voit `"Hello World"` et cherche cette clé. Elle ne la trouvera pas car votre fichier de traduction est rempli de hachages (`x7f2a`).
+
+### Verrouillage de plateforme
+
+En choisissant une approche basée sur un compilateur, vous vous enfermez dans la plateforme sous-jacente. Par exemple, certains compilateurs ne sont pas disponibles pour tous les bundlers (comme Vite, Turbopack ou Metro). Cela peut rendre les migrations futures difficiles, et vous pourriez avoir besoin d'adopter plusieurs solutions pour couvrir toutes vos applications.
+
+## L'autre côté : risques de l'approche déclarative
 
 Pour être juste, la méthode déclarative traditionnelle n’est pas parfaite non plus. Elle a ses propres « pièges ».
 
-1.  **L’enfer des namespaces :** Vous devez souvent gérer manuellement quels fichiers JSON charger (`common.json`, `dashboard.json`, `footer.json`). Si vous en oubliez un, l’utilisateur voit les clés brutes.
-2.  **Surcharge de requêtes :** Sans une configuration soigneuse, il est très facile de charger accidentellement _toutes_ vos clés de traduction pour _toutes_ les pages dès le chargement initial, ce qui alourdit la taille de votre bundle.
-3.  **Dérive de synchronisation :** Il est courant que des clés restent dans le fichier JSON bien après que le composant qui les utilise ait été supprimé. Vos fichiers de traduction grossissent indéfiniment, remplis de « clés zombies ».
+1.  **L’enfer des namespaces :** Vous devez souvent gérer manuellement quels fichiers JSON charger (`common.json`, `dashboard.json`, `footer.json`). Si vous en oubliez un, l’utilisateur voit des clés brutes.
+2.  **Surcharge de récupération :** Sans une configuration soigneuse, il est très facile de charger accidentellement _toutes_ vos clés de traduction pour _toutes_ les pages lors du chargement initial, ce qui alourdit la taille de votre bundle.
+3.  **Dérive de synchronisation :** Il est courant que des clés restent dans le fichier JSON longtemps après que le composant qui les utilisait ait été supprimé. Vos fichiers de traduction grossissent indéfiniment, remplis de "clés zombies".
 
-## Le juste milieu avec Intlayer
+## Le juste milieu d'Intlayer
 
-C’est là que des outils comme **Intlayer** cherchent à innover. Intlayer comprend que, bien que les compilateurs soient puissants, la magie implicite est dangereuse.
+C'est là que des outils comme **Intlayer** cherchent à innover. Intlayer comprend que, bien que les compilateurs soient puissants, la magie implicite est dangereuse.
 
-Intlayer propose une commande unique **`transform`**. Au lieu de faire simplement de la magie dans une étape de build cachée, elle peut en réalité **réécrire votre code de composant**. Elle analyse votre texte et le remplace par des déclarations de contenu explicites dans votre base de code.
+Intlayer propose une approche mixte, vous permettant de bénéficier des avantages des deux approches : une gestion déclarative du contenu, également compatible avec son compilateur pour gagner du temps de développement.
+
+Et même si vous n'utilisez pas le compilateur Intlayer, Intlayer propose une commande `transform` (également accessible via l'extension VSCode). Au lieu de faire simplement de la magie lors de l'étape de build cachée, elle peut en fait **réécrire le code de vos composants**. Elle analyse votre texte et le remplace par des déclarations de contenu explicites dans votre base de code.
 
 Cela vous offre le meilleur des deux mondes :
 
 1.  **Granularité :** Vous gardez vos traductions proches de vos composants (améliorant la modularité et le tree-shaking).
-2.  **Sécurité :** La traduction devient un code explicite, et non une magie cachée au moment de la compilation.
-3.  **Pas de verrouillage :** Puisque le code est transformé en une structure déclarative standard dans votre dépôt, vous ne cachez pas la logique dans un plugin webpack.
+2.  **Sécurité :** La traduction devient un code explicite, et non une magie cachée au moment du build.
+3.  **Pas de verrouillage :** Puisque le code est transformé en une structure déclarative dans votre dépôt, vous pouvez facilement appuyer sur tab, ou utiliser le copilot de votre IDE, pour générer vos déclarations de contenu, vous ne cachez pas la logique dans un plugin webpack.
 
 ## Conclusion
 
 Alors, que devriez-vous choisir ?
 
-**Si vous êtes un développeur junior, un fondateur solo, ou que vous construisez un MVP :**
-L'approche basée sur le compilateur est un choix valide. Elle vous permet d'avancer extrêmement vite. Vous n'avez pas besoin de vous soucier des structures de fichiers ou des clés. Vous construisez simplement. La dette technique est un problème pour le "Vous du futur".
+**Si vous construisez un MVP, ou souhaitez avancer rapidement :**  
+L'approche basée sur le compilateur est un choix valable. Elle vous permet d'avancer incroyablement vite. Vous n'avez pas besoin de vous soucier des structures de fichiers ou des clés. Vous construisez simplement. La dette technique sera un problème pour le "Vous du futur".
+
+**Si vous êtes un développeur junior, ou que l'optimisation ne vous importe pas :**  
+Si vous souhaitez la gestion la plus simple possible, une approche basée sur le compilateur est probablement la meilleure. Vous n'aurez pas besoin de gérer vous-même les clés ou les fichiers de traduction — écrivez simplement le texte, et le compilateur automatise le reste. Cela réduit l'effort d'installation et les erreurs courantes liées à l'i18n manuelle.
+
+**Si vous internationalisez un projet existant qui comprend déjà des milliers de composants à refactoriser :**  
+Une approche basée sur un compilateur peut être un choix pragmatique ici. La phase d'extraction initiale peut vous faire gagner des semaines ou des mois de travail manuel. Cependant, envisagez d'utiliser un outil comme la commande `transform` d'Intlayer, qui peut extraire des chaînes et les convertir en déclarations de contenu déclaratives explicites. Cela vous offre la rapidité de l'automatisation tout en conservant la sécurité et la portabilité d'une approche déclarative. Vous obtenez le meilleur des deux mondes : une migration initiale rapide sans dette architecturale à long terme.
 
-**Si vous construisez une application professionnelle de niveau entreprise :**
+**Si vous développez une application professionnelle de niveau entreprise :**
 La magie est généralement une mauvaise idée. Vous avez besoin de contrôle.
 
 - Vous devez gérer des données dynamiques provenant des backends.
-- Vous devez garantir la performance sur des appareils peu puissants (en évitant les explosions de hooks).
+- Vous devez garantir la performance sur des appareils bas de gamme (en évitant les explosions de hooks).
 - Vous devez vous assurer de ne pas être enfermé à jamais dans un outil de build spécifique.
 
 Pour les applications professionnelles, la **Gestion de Contenu Déclarative** (comme Intlayer ou des bibliothèques établies) reste la référence. Elle sépare vos préoccupations, maintient votre architecture propre, et garantit que la capacité de votre application à parler plusieurs langues ne dépend pas d'un compilateur "boîte noire" devinant vos intentions.