Cómo Traducir Archivos XLIFF (Drupal, Symfony, Angular, iOS)
Un desarrollador de Drupal publicó en Stack Overflow la semana pasada una historia que se repite miles de veces al año en equipos de localización empresariales. Su equipo exportó un archivo XLIFF de 40 MB de su sitio Drupal. Lo abrió en un editor de texto, pegó fragmentos en Google Translate, volvió a ensamblar el archivo, lo importó de nuevo a Drupal, y la mitad de las páginas se negaron a renderizar porque las cadenas traducidas contenían XML malformado, caracteres escapados en lugares incorrectos y etiquetas <g> rotas donde el formato en línea había sido destruido.
XLIFF es el estándar de localización empresarial por una razón. Se basa en XML, es independiente de la herramienta y admite los metadatos enriquecidos que necesitan los proyectos de traducción serios: estados de traducción, traducciones alternativas, notas entre traductores y desarrolladores, y marcado en línea estructurado. Pero su misma flexibilidad hace que sea fácil de corromper, y las herramientas que manejan los archivos .po de forma segura a menudo fallan con XLIFF.
Esta guía explica qué hace que XLIFF sea distinto, por qué los enfoques de traducción genéricos lo rompen y la forma correcta de traducir archivos XLIFF para Drupal, Symfony, Angular e iOS, las cuatro plataformas donde XLIFF es más comúnmente utilizado en 2026.
Qué es XLIFF (y por qué lo usan los equipos empresariales)
XLIFF significa XML Localization Interchange File Format. Es un estándar de OASIS diseñado específicamente para mover contenido de traducción entre herramientas: sistemas de gestión de contenido, bases de datos de memoria de traducción, herramientas CAT y plataformas de localización. A diferencia de los archivos .po de Gettext (que almacenan pares clave-valor planos) o los archivos de localización JSON (que se anidan arbitrariamente), XLIFF es un documento XML estructurado con un esquema estandarizado.
XLIFF 1.2 vs XLIFF 2.0
Existen dos versiones en circulación, y no son totalmente compatibles.
XLIFF 1.2 es la versión más antigua y ampliamente desplegada. Utiliza elementos <trans-unit> para envolver contenido traducible, con hijos <source> y <target>. El formato en línea utiliza etiquetas emparejadas <g>, <x> y <bpt> / <ept>. La herramienta de gestión de traducción de Drupal y muchas plataformas más antiguas todavía exportan 1.2.
XLIFF 2.0 es la revisión de 2014, más simple y limpia. Utiliza <unit> y <segment> con <source> y <target>. El marcado en línea utiliza <pc> (código emparejado) y <ph> (marcador de posición). El componente de traducción de Symfony y las exportaciones modernas de iOS por defecto usan 2.0.
Una herramienta de traducción que maneja 1.2 no maneja automáticamente 2.0. Los vocabularios de etiquetas son diferentes, y las reglas de escape difieren ligeramente. Siempre verifica qué versión exporta tu plataforma antes de elegir un flujo de traducción.
La anatomía de una unidad XLIFF
Una unidad trans-unit mínima de XLIFF 1.2 se ve así:
<trans-unit id="msg_welcome" datatype="plaintext">
<source>Welcome, <g id="1">%name%</g>!</source>
<target state="needs-translation">Welcome, <g id="1">%name%</g>!</target>
<note>Displayed on the homepage after login</note>
</trans-unit>
La etiqueta <g id="1"> envuelve una variable de marcador de posición. El atributo state le dice a la plataforma que esta cadena necesita traducción. La etiqueta <note> es una pista para el desarrollador. Un traductor que entienda XLIFF debería producir:
<target state="translated">¡Bienvenido, <g id="1">%name%</g>!</target>
Un traductor que trata el archivo como texto plano podría producir cualquiera de estas variantes rotas:
<target>¡Bienvenido, <g id="1">%nombre%</g>!</target>
<target>¡Bienvenido, <g id="1">%name%</g>!</target>
<target>¡Bienvenido, %name%!</target>
Cada una de estas rompe la importación de manera diferente. La primera renombra la variable. La segunda escapa el XML. La tercera elimina completamente la etiqueta de formato.
Soluciones Inadecuadas (Por qué no puedes simplemente traducir XML)
La mayoría de los equipos comienzan con los mismos tres enfoques y pierden varios días antes de rendirse.
Alimentar XLIFF a una IA Genérica
Copia el archivo, pégalo en Claude o ChatGPT, pide una traducción. El modelo generalmente hace un trabajo razonable con el texto, pero trata las etiquetas XLIFF de manera inconsistente. A veces preserva las etiquetas <g>, a veces traduce el atributo id, a veces las elimina por completo. La validación falla. Tu importación arroja errores de análisis de XML.
Usar una herramienta CAT sin soporte para XLIFF
Herramientas como Poedit están diseñadas para el formato .po. Pueden abrir XLIFF, pero lo tratan como un contenedor de texto genérico. Las etiquetas en línea no están bloqueadas. Los marcadores de posición no están protegidos. Obtienes una traducción que se ve bien en el editor, pero que falla la validación del esquema al importar.
Escribir un script personalizado
Tu equipo escribe un script en Node o Python que analiza XLIFF con xml2js, extrae las cadenas de origen, llama a Google Translate y vuelve a escribir los destinos. Funciona para el 90% de las cadenas. El otro 10% —cadenas con formato anidado, grupos plurales o caracteres especiales— se rompen de formas que solo aparecen después de haberlo lanzado.
El mismo modo de fallo "formato flexible se encuentra con traductor ingenuo" afecta a los archivos JSON de i18next y .po de Gettext. Nuestra guía sobre cómo traducir archivos JSON de i18next para React y Next.js y nuestra publicación sobre cómo traducir archivos .po sin romper variables de código cubren los problemas paralelos para esos formatos.
La forma correcta: Procesamiento de XLIFF consciente de la sintaxis
Un flujo de traducción XLIFF adecuado sigue los mismos principios que nuestro motor PO, adaptado para XML.
Parsear, no usar expresiones regulares
Trata XLIFF como un documento estructurado. Analízalo con un analizador XML real, construye un árbol y recorre los elementos <trans-unit> (o <unit> para 2.0). Intentar hacer coincidir el contenido de origen y destino con expresiones regulares es el camino rápido hacia archivos corruptos.
Bloquear etiquetas en línea antes de la traducción
Cada <g>, <x>, <bpt>, <ept>, <ph>, <pc> dentro de un <source> debe ser preservado por posición y atributo id. Reemplázalos con marcadores de posición numéricos antes de enviar el texto al LLM, luego reinserta las etiquetas originales con sus atributos después de que regrese la traducción.
Respetar la máquina de estados
Las unidades XLIFF tienen atributos de estado: new, needs-translation, translated, reviewed, final, signed-off. Un flujo de trabajo solo debe traducir unidades en estado new o needs-translation, y establecer el estado de salida en translated (no final – un revisor aún debe verificar).
Preservar la estructura más allá de las unidades de traducción
Los archivos XLIFF contienen encabezados, metadatos, atributos a nivel de archivo, notas y traducciones alternativas (<alt-trans>). Estos deben permanecer inalterados durante el viaje de ida y vuelta. Eliminarlos o reordenarlos rompe la compatibilidad de ida y vuelta con la plataforma de origen.
Validar antes de la entrega
Antes de devolver el XLIFF traducido, valida contra el esquema. XLIFF 1.2 tiene un XSD oficial. XLIFF 2.0 tiene el suyo propio. Una herramienta que no puede autovalidarse es una herramienta que te enviará archivos rotos.
Notas específicas de la plataforma
Cada plataforma principal que usa XLIFF tiene peculiaridades que vale la pena conocer.
Drupal
La herramienta de gestión de traducción (TMGMT) de Drupal exporta XLIFF 1.2. Los tipos de contenido incluyen nodos (páginas, artículos), términos de taxonomía y configuración. TMGMT envuelve cada campo traducible en una <trans-unit> separada con un formato de ID específico de Drupal (fieldname:delta:format).
Advertencia: Drupal almacena información de formato de texto (HTML filtrado, HTML completo, texto plano) junto con el contenido. La traducción debe preservar el marcado HTML cuando el formato lo permite, y convertir a texto plano cuando el formato no lo permite. Tu flujo de trabajo necesita ser consciente de cada campo.
Symfony
El componente de traducción de Symfony usa XLIFF 2.0 por defecto (desde Symfony 4). Las cadenas residen en translations/messages.xx.xliff. Symfony soporta el formato de mensajes ICU dentro de XLIFF, lo que significa que una sola unidad puede contener estructuras {count, plural, one {...} other {...}}.
Advertencia: Las categorías plurales de ICU dentro de XLIFF necesitan doble protección. Las etiquetas XML permanecen intactas, Y las palabras clave de ICU (plural, one, other, =0) no deben ser traducidas. Muchas herramientas XLIFF manejan una capa pero no ambas.
Angular i18n
Angular exporta XLIFF 1.2 o 2.0 a través del comando ng extract-i18n. Los archivos contienen cadenas de plantilla de componentes, con etiquetas <x> que representan expresiones e interpolaciones de Angular como {{ count }}.
Advertencia: Angular utiliza colisiones de hash id en cadenas de origen idénticas. Una traducción debe mantener los IDs de unidad exactamente, o Angular no podrá hacer coincidir en la importación. Renombrar atributos id durante el procesamiento provoca un fallo instantáneo.
iOS (Exportación de Xcode)
Xcode exporta XLIFF 1.2 para la localización de aplicaciones a través de Product > Export Localizations. Las cadenas provienen de Localizable.strings, entradas de Info.plist, storyboards y XIBs. Las reglas de plural de iOS residen en archivos .stringsdict exportados como trans-units adicionales.
Advertencia: Las cadenas de storyboard de iOS hacen referencia a IDs de elementos de la interfaz de usuario. Estos no deben ser alterados. Además, Xcode requiere que el atributo target-language coincida exactamente con su formato de configuración regional esperado (es, no es-ES, en algunos contextos) o ignora silenciosamente la importación.
Traducción de XLIFF con SimplePoTranslate
SimplePoTranslate soporta XLIFF en los planes Pro y Lifetime. El flujo de trabajo es el mismo que para los archivos .po.
1. Exporta tu XLIFF
Desde tu plataforma de origen, exporta uno o más archivos .xliff. Para Drupal, usa la acción de exportación de TMGMT. Para Symfony, busca translations/messages.en.xliff. Para Angular, ejecuta ng extract-i18n --format=xlf2. Para Xcode, usa la exportación de Localización.
2. Sube a SimplePoTranslate
Arrastra el archivo al panel. La plataforma detecta automáticamente la versión de XLIFF (1.2 o 2.0), analiza la estructura e identifica las unidades traducibles. Elige tu idioma de destino y el tono.
3. Traducción consciente de la sintaxis
Las etiquetas en línea, los parámetros de ICU, los marcadores de posición y los IDs de unidad se bloquean antes de la traducción. El motor de IA subyacente solo ve texto limpio con contexto. El texto traducido se reinserta en la estructura original exacta, los estados se actualizan y el archivo se valida contra el esquema XLIFF antes de la entrega.
4. Descargar e importar
Descarga el XLIFF traducido (además de los equivalentes .po, .json y .php si necesitas compatibilidad multiplataforma). Importa a tu plataforma de origen. Valida renderizando algunas páginas o vistas traducidas antes de implementarlas.
# Angular example
ng extract-i18n --format=xlf2 --output-path=src/locale
# upload src/locale/messages.xlf to SimplePoTranslate
# download messages.es.xlf
# reference in angular.json i18n configuration
ng build --localize
5. Integrar en CI
Una vez que confíes en el flujo de trabajo, automatízalo. Exporta XLIFF en cada lanzamiento, envíalo a través de la API, descarga los archivos traducidos, haz commit al repositorio, despliega. Este es el mismo patrón compatible con CI que muchas agencias utilizan para la traducción de archivos .po de WordPress; consulta nuestra publicación sobre traducción en la nube sin sitios rotos para conocer el patrón arquitectónico.
Recopilando todo
XLIFF es la herramienta adecuada para un trabajo de localización serio: estructurado, independiente de la herramienta y lo suficientemente rico como para transportar metadatos del proyecto entre sistemas. Pero su estructura XML también es frágil. Cada etiqueta, atributo y valor de estado tiene un peso semántico, y un traductor que no entienda XLIFF como formato corromperá tu archivo de maneras que pueden no aparecer hasta que la importación falle o un usuario informe de una interfaz de usuario rota.
El enfoque seguro es consciente de la sintaxis: analiza el XML, bloquea los elementos estructurales, traduce solo las superficies de texto con contexto, valida contra el esquema antes de la entrega. Esto es válido tanto si estás distribuyendo un sitio Drupal, una API de Symfony, una SPA de Angular o una aplicación iOS. La plataforma difiere, pero la disciplina XLIFF no.
¿Listo para traducir archivos XLIFF para Drupal, Symfony, Angular o iOS sin etiquetas rotas? Prueba SimplePoTranslate gratis - no se requiere tarjeta de crédito. Sube
.xliff, descarga traducciones seguras, importa a tu plataforma.