Traducción de Angular: ngx-translate frente a traducción automática (2026)
Angular ofrece dos enfoques de i18n — un framework integrado de tiempo de compilación y una popular librería de tiempo de ejecución — además de la opción de traducción automática basada en el DOM, que no requiere ningún cambio de código. Así funciona cada uno, cuándo encaja y cómo elegir.
Los dos enfoques de i18n integrados en Angular
Angular tiene su propio framework de i18n, @angular/localize, que usa archivos XLIFF y traducción en tiempo de compilación. La característica clave: ejecutas una build independiente por locale. Cada idioma produce su propio bundle optimizado con las traducciones incorporadas en tiempo de compilación — el rendimiento en tiempo de ejecución más rápido posible, porque no hay búsqueda de traducciones en el navegador.
La alternativa de terceros más popular es @ngx-translate/core, que funciona en tiempo de ejecución. Distribuyes un único bundle y cargas los archivos JSON de cada locale al iniciar. Los usuarios que cambian de idioma reciben las nuevas cadenas sin recargar la página.
| Enfoque | Cuándo se aplican las traducciones | Bundles por idioma |
|---|---|---|
@angular/localize | Tiempo de compilación | Uno por locale |
@ngx-translate/core | Tiempo de ejecución (inicio) | Un bundle compartido |
| Traducción automática | Tiempo de ejecución (DOM) | Un bundle compartido |
Desplázate horizontalmente para ver todas las columnas.
ngx-translate en la práctica
@ngx-translate/core es la librería de i18n para Angular más utilizada fuera del framework integrado. El patrón central consta de tres piezas:
- →TranslateModule — se importa en cada módulo de Angular (o componente independiente) que necesita traducciones. Proporciona el pipe y la directiva.
- →TranslateService — se inyecta en los componentes que necesitan cambiar de idioma de forma programática o acceder a las traducciones en TypeScript.
- →pipe translate — se usa en las plantillas:
{{ "HELLO" | translate }}. Reactivo: se actualiza automáticamente cuando cambia el idioma activo. - →HttpLoader — el loader predeterminado obtiene
/assets/i18n/fr.jsonal cambiar de idioma. Mantienes un archivo JSON por locale.
El ecosistema es maduro: los paquetes de la comunidad gestionan plurales al estilo ICU, módulos de traducción con carga diferida y renderizado del lado del servidor. La mayoría de los equipos de Angular que iniciaron proyectos antes de Angular 13 usan ngx-translate.
El coste del i18n de Angular
Ambos enfoques integrados conllevan una carga de mantenimiento que es fácil de subestimar al comienzo de un proyecto.
@angular/localize: una build de CI por locale
Una build independiente por idioma es rápida para los visitantes pero costosa en CI. Con 5 idiomas, el tiempo de build y el almacenamiento de artefactos se multiplican por casi cinco. Con 10 o más idiomas — un objetivo habitual para productos globales — la matriz se convierte en un problema real de infraestructura: pipelines más largos, más almacenamiento, despliegue más complejo.
ngx-translate: archivos JSON de locale que mantener
Cada cadena de la app necesita una clave en cada archivo JSON de locale. A medida que la app crece, mantener los archivos sincronizados se convierte en una fuente de errores: las claves ausentes fallan de forma silenciosa, las traducciones obsoletas se publican sin avisar, y la gestión de claves con seguridad de tipos requiere herramientas adicionales.
Ambos: los archivos de traducción son un objetivo cambiante
El copy de la interfaz cambia con frecuencia durante el desarrollo del producto. Cada cambio de texto implica actualizar archivos XLIFF o JSON, volver a extraer claves y coordinarse con traductores o con un sistema de gestión de traducciones. Para equipos sin un flujo de localización dedicado, esta carga se acumula rápidamente.
Cuándo las herramientas de i18n de Angular son la mejor opción
El stack de i18n integrado en Angular destaca genuinamente en contextos específicos:
- →Apps empresariales con un equipo de localización dedicado. Si cuentas con traductores profesionales, un TMS y un flujo de revisión, la extracción XLIFF se integra directamente en esos procesos.
- →Cumplimiento normativo que exige traducciones aprobadas por humanos. Las apps financieras, legales o médicas que no pueden publicar copy sin revisar se benefician del paso explícito de aprobación de traducciones que exigen los flujos XLIFF.
- →Uso intensivo del formato de mensajes ICU.Las reglas de plural y selección (por ejemplo, “{count, plural, one {1 result} other {# results}}”) son ciudadanos de primera clase en
@angular/localizey están bien soportadas en ngx-translate con un plugin ICU. - →Se requiere optimización en tiempo de compilación por locale. Si el tamaño del bundle es crítico y cada mercado tiene contenido genuinamente distinto (no solo cadenas traducidas), las builds por locale permiten hacer tree-shaking del código específico de cada locale que no se usa.
Cuándo gana la traducción automática
La traducción automática basada en el DOM — añadir una etiqueta de script a la página que aloja la app Angular — evita por completo el pipeline de traducción. Hay escenarios claros en los que esta es la mejor opción:
- →Una app Angular existente que añade soporte multilingüe sin reconstruirse. Una app en funcionamiento sin inversión previa en i18n puede volverse multilingüe hoy mismo sin tocar un solo componente.
- →Equipos de startup sin ingenieros de i18n. Configurar ngx-translate o
@angular/localizecorrectamente lleva tiempo. Una etiqueta de script puede reducir el trabajo de integración, aunque el tiempo de configuración varía según la app. - →Dashboards de SaaS con una interfaz que cambia rápidamente. Cuando el copy de la interfaz cambia cada semana, mantener archivos de traducción se convierte en un trabajo a tiempo completo. La traducción automática se mantiene al día con el DOM sin ninguna actualización de archivos.
- →El tiempo de salida al mercado importa. Llegar a usuarios de francés, alemán, español y japonés en un día — no en un trimestre — es una ventaja competitiva real para muchos productos.
Cómo funciona Lingvit con Angular
Lingvit se añade a una app Angular mediante una única etiqueta de script en src/index.html, antes de la etiqueta de cierre </body>.
La detección de cambios de Angular actualiza el DOM a medida que los componentes se vuelven a renderizar. Lingvit usa un MutationObserver para detectar esas mutaciones del DOM y traducir el contenido nuevo a medida que aparece — esto funciona correctamente tanto con la detección de cambios basada en zone.js como con la reactividad basada en signals más reciente, introducida en Angular 16+.
Componentes independientes de Angular 15+
Funciona sin modificaciones. Los componentes independientes renderizan sobre el mismo DOM; MutationObserver captura todas las actualizaciones, independientemente de si la app usa NgModule o arquitectura de componentes independientes.
Angular Universal / SSR
El renderizado del lado del servidor es compatible. La etiqueta de script se añade a la plantilla HTML renderizada por el servidor. Tras la hidratación, MutationObserver gestiona cualquier actualización del DOM en el cliente procedente del router o de los re-renderizados de componentes de Angular.
Patrón NgModule anterior
Las apps en Angular 12 y anteriores que usan NgModules funcionan de forma idéntica. La etiqueta de script actúa a nivel de la página que la aloja — no depende de la versión de Angular ni del sistema de módulos dentro de la app.
Comparación de configuración
| Paso | @angular/localize | ngx-translate | Lingvit |
|---|---|---|---|
| Instalación | ng add @angular/localize | Instalar el paquete, configurar TranslateModule | — |
| Marcar cadenas | Añadir el atributo i18n a cada elemento | Envolver cada cadena con el pipe translate | — |
| Archivos de traducción | Extraer XLIFF, completar por locale | Escribir JSON por locale | — |
| Pipeline de CI | Matriz de build por locale | Build única | Build única |
| Añadir idiomas | Nueva build por locale | Nuevo archivo JSON | Interruptor en el panel |
| Etiqueta de script en index.html | No necesaria | No necesaria | Una etiqueta antes de </body> |
Desplázate horizontalmente para ver todas las columnas.
Preguntas frecuentes
- ¿Funciona Lingvit con Angular SSR / Angular Universal?
- Sí. Añade la etiqueta de script de Lingvit a la plantilla HTML servida por el servidor (normalmente src/index.html o la plantilla del servidor Express). El widget se inicializa después de que Angular hidrata la página en el cliente, y MutationObserver gestiona las actualizaciones del DOM posteriores procedentes del router y de los re-renderizados de componentes de Angular.
- ¿Funciona con los componentes de Angular Material?
- Sí. Angular Material renderiza elementos DOM estándar — MatButton, MatInput, MatTable y el resto de componentes producen HTML normal que MutationObserver observa. Los tooltips y overlays que se adjuntan al body del documento también se capturan.
- ¿Qué ocurre con los monorepos Nx con varias apps Angular?
- Cada app Angular de un monorepo Nx es un desplegable independiente con su propio index.html. Añade la etiqueta de script de Lingvit al index.html de cada app por separado. Puedes usar el mismo proyecto de Lingvit para apps en el mismo dominio, o proyectos separados por app — el panel te permite gestionar ambas configuraciones.
Guías relacionadas
Añade idiomas a tu app Angular
Funciona con Angular 15+, Angular Material y Angular Universal. Una sola etiqueta de script.