Cómo traducir archivos DITA sin conversión XLIFF

¿Está buscando una manera de traducir sus archivos DITA sin el dolor de cabeza constante de las conversiones manuales a XLIFF? Si ese es el caso, estás en el lugar correcto. DITA (Darwin Information Typing Architecture) ya es el estándar de oro en eficiencia y reutilización de contenido, pero muchos equipos de contenido técnico aún se encuentran atrapados en un ciclo frustrante: el bucle de conversión XLIFF.

Si su flujo de trabajo de traducción actual implica exportar archivos DITA a XLIFF, enviar esos archivos a una agencia y luego volver a importarlos manualmente a su sistema, es probable que esté perdiendo más que solo tiempo. Podría estar poniendo en riesgo la integridad de la documentación que tanto le costó crear.

En este artículo, hablaremos sobre las dificultades técnicas de la conversión manual, los costos ocultos de gestionar deltas y por qué el soporte nativo de DITA es un cambio radical para los equipos de documentación modernos. Cuando termine de leer este artículo, estará listo para comenzar a optimizar sus flujos de trabajo de traducción DITA y avanzar hacia un proceso que sea más rápido, más confiable y significativamente más rentable. ¡Vamos directo al grano!

El impuesto XLIFF sobre la documentación técnica

XLIFF (XML Localization Interchange File Format) es un estándar excelente para muchas cosas, pero para los usuarios de DITA, a menudo actúa como un intermediario que complica más de lo que simplifica. A menudo nos referimos a esto como el impuesto XLIFF: el costo oculto de tiempo, dinero y trabajo manual necesarios para que el formato funcione. He aquí por qué este proceso de conversión manual podría costarle a su equipo más de lo que cree.

1. El desglose de la reutilización de contenido: referencias de conexión y referencias de clave

El verdadero genio de DITA reside en su capacidad de referenciar contenidos de múltiples temas. Cuando se convierte un archivo DITA a XLIFF, estas relaciones sofisticadas a menudo se eliminan o se rompen por completo. En un archivo XLIFF estándar, una referencia de contenido (conref) podría aparecer simplemente como una cadena de texto estática.

Esto crea un problema financiero importante: usted podría terminar pagando para traducir la misma nota de advertencia o procedimiento de seguridad varias veces porque la herramienta de conversión no la reconoció como una única entidad reutilizable. Peor aún, cuando vuelvas a importar ese texto, puedes descubrir que tus referencias de contenido global han sido sobrescritas por texto codificado, lo que efectivamente destruye tu arquitectura modular y hace que las actualizaciones futuras sean una pesadilla.

2. Corrupción de etiquetas y errores de validación

Los archivos DITA se rigen por DTD (definiciones de tipo de documento) estrictas o esquemas XML. Cada vez que su contenido pasa de un formato .dita a .xliff, y viceversa, corre el riesgo de crear lo que llamamos sopa de etiquetas.

Sólo hace falta que un traductor que no esté familiarizado con la estructura DITA elimine accidentalmente un atributo obligatorio o coloque incorrectamente una etiqueta de cierre. Un solo soporte faltante o un atributo mal ubicado durante ese viaje de ida y vuelta puede arruinar toda la construcción de DITA-OT. Todos hemos estado allí: es viernes por la tarde y estás intentando lanzar una versión, pero en lugar de eso, tus ingenieros de soporte están buscando entre miles de líneas de código para encontrar un solo error de validación.

3. La pesadilla de la gestión del Delta

Los flujos de trabajo manuales de XLIFF a menudo obligan a los escritores a dejar de ser creadores y comenzar a ser administradores de archivos. Para ahorrar en costos de traducción, los escritores a menudo intentan identificar manualmente los deltas (solo los archivos que han cambiado desde la última actualización). Este proceso es notoriamente difícil por tres razones:

• Es propenso a errores: la falta de un solo tema actualizado puede generar documentación desincronizada que confunda a sus clientes.
• Es técnicamente agotador: tu equipo termina pasando horas comparando versiones en lugar de escribir contenido nuevo y útil.
• Falta de contexto: si un pequeño cambio en un tema afecta el significado de un tema relacionado, una selección delta manual probablemente lo pasará por alto.

Más allá de la etiqueta: la importancia de la protección de atributos

Uno de los aspectos más pasados ​​por alto en la lucha de DITA a XLIFF es la gestión de los atributos XML. DITA se basa en gran medida en atributos para la creación de perfiles y el filtrado, como el producto, la plataforma y la audiencia. Estas son las herramientas que le permiten publicar diferentes versiones de un manual desde la misma fuente.

Cuando utiliza un flujo de trabajo DITA nativo, estos atributos están protegidos de forma predeterminada. En MotaWord, nuestro sistema reconoce que un atributo de producto es una pieza de metadatos que nunca debe traducirse. En una conversión XLIFF estándar, estos atributos a menudo se eliminan (lo que interrumpe la publicación condicional) o se exponen al traductor. Si un traductor ve pro_version y lo traduce al español como version_profesional, su lógica de procesamiento condicional ya no funcionará.

Por qué Traducir=No es un salvavidas

El atributo translate="no" es una herramienta vital para los escritores técnicos que necesitan mantener fragmentos de código, instrucciones de línea de comandos o nombres de marcas específicas consistentes en todos los idiomas. Un analizador DITA nativo respeta este atributo a nivel de motor. En las conversiones manuales de XLIFF, estos filtros utilizados para crear el archivo XLIFF con frecuencia ignoran estas instrucciones, lo que genera ciclos de posedición costosos y molestos para corregir el contenido sobretraducido.

La brecha del contexto: por qué los traductores tienen dificultades con XLIFF

La traducción es más que simplemente intercambiar palabras: se trata de comprender el contexto. Cuando un tema DITA se convierte en un archivo XLIFF plano, el traductor a menudo ve una lista de cadenas aisladas. Pierden la vista del Mapa que da estructura al proyecto. No pueden ver que un título particular pertenece a una sección específica dentro de una tarea más amplia.

Al utilizar la traducción nativa DITA, el traductor trabaja dentro de un sistema que realmente entiende la jerarquía DITA. Esto proporciona varios beneficios para la calidad de su documentación:

• Proporciona mayor claridad: el traductor sabe si una palabra es un paso, un resultado o un prerrequisito.
• Garantiza una terminología coherente: el sistema se asegura de que un término utilizado en una descripción corta coincida con el mismo término en el cuerpo del tema.
• Mantiene la integridad visual: el flujo lógico de información permanece intacto, lo que es especialmente crítico cuando se producen manuales técnicos complejos para hardware o software.

Una mejor manera: Traducción nativa DITA con MotaWord

Creemos que los redactores técnicos deberían poder centrarse en el contenido, no en luchar con formatos de archivos. Es por eso que hemos trabajado para eliminar el intermediario XLIFF a través de un enfoque nativo.

Comparación del flujo de trabajo

El flujo de trabajo manual de XLIFF

• Requiere horas de exportación y filtrado de archivos.
• Conlleva un alto riesgo de aplanar las referencias de contenido.
• A menudo da como resultado metadatos corruptos o traducidos accidentalmente.
• Requiere un control de calidad manual extenso después de importar los archivos.
• Se generaron costos ocultos debido al trabajo manual y cadenas duplicadas.

El flujo de trabajo nativo DITA con MotaWord

• Toma minutos a través de una carga directa de sus archivos.
• Mantiene la integridad de su referencia 100 por ciento protegida.
• Bloquea o ignora automáticamente los metadatos para mantenerlos seguros.
• Entrega archivos listos para compilar desde el momento en que los descargas.
• Utiliza la memoria de traducción para garantizar que solo pagues por contenido nuevo.

Sube tus archivos .dita y .ditamap sin procesar

En lugar de realizar exportaciones complejas, puede simplemente cargar sus archivos DITA sin procesar o todo su proyecto Ditamap. Nuestra plataforma está construida para analizar la estructura DITA de forma nativa. Comprende la diferencia entre un título, un cuerpo y una descripción corta, lo que garantiza que sus metadatos permanezcan intactos y que su estructura se mantenga sólida.

Automatización en lugar de diferenciación manual

Debido a que MotaWord utiliza una memoria de traducción integrada, ya no necesita perder tiempo averiguando qué archivos cambiaron. Puedes cargar el proyecto completo y dejar que el sistema haga el trabajo pesado:

• Nuestro sistema compara todo su Ditamap con sus traducciones anteriores.
• Identifica cadenas nuevas o modificadas en segundos.
• Usted solo paga por las palabras nuevas, lo que le brinda los beneficios de costo de los deltas sin ninguno de los dolores de cabeza manuales.

La economía de la documentación lista para construir

El verdadero costo oculto de la conversión a XLIFF se encuentra en el ciclo de publicación final. En un flujo de trabajo manual, recibir los archivos traducidos es solo la mitad del camino. Todavía tienes que volver a importar todo a tu CCMS (Sistema de gestión de contenido de componentes), ejecutar una compilación de prueba utilizando DITA Open Toolkit y depurar los inevitables errores XML.

Esta fase de control de calidad de localización puede llevar días o incluso semanas del tiempo del escritor. La compatibilidad nativa con DITA garantiza que los archivos que descargue estén listos para usar. Como la estructura nunca fue desmontada para encajar en un contenedor XLIFF, no es necesario reconstruirla. Puede pasar de una traducción finalizada a un sitio PDF o HTML publicado con solo unos pocos clics.

Preguntas frecuentes

1. ¿Cómo traducir archivos DITA sin romper las referencias?

Las plataformas de traducción DITA nativas como MotaWord procesan los archivos en su estructura XML original. Al evitar la conversión a XLIFF, el sistema mantiene los punteros a sus referencias de contenido (conrefs) y referencias de clave (keyrefs). Esto garantiza que los objetos reutilizables se manejen correctamente sin estar codificados en el texto traducido.

2. ¿Cuál es el mejor flujo de trabajo de traducción DITA para equipos pequeños?

El flujo de trabajo más eficiente para equipos pequeños es un enfoque directo a DITA. En lugar de invertir en middleware costoso o gastar horas en exportaciones manuales de XLIFF, los equipos pequeños deberían usar una plataforma que acepte archivos .dita y .ditamap directamente. Esto reduce la sobrecarga técnica y elimina la necesidad de un ingeniero de localización dedicado.

3. ¿MotaWord admite DTD DITA especializados?

Sí. Dado que DITA permite la especialización (la creación de tipos de elementos personalizados), nuestro analizador nativo está diseñado para respetar el esquema XML subyacente. Sus etiquetas y atributos personalizados están protegidos y excluidos del recuento de palabras a menos que contengan contenido traducible.

4. DITA vs XLIFF para traducción: ¿cuál es mejor?

Si bien XLIFF es un excelente formato de intercambio para cadenas de software generales, DITA es superior para la documentación estructurada porque contiene más contexto con respecto a la reutilización de contenido. Traducir DITA de forma nativa casi siempre es mejor porque evita los errores de ida y vuelta que son comunes al convertir entre dos formatos de archivos diferentes.

5. ¿Puedo utilizar la traducción DITA nativa con mi CCMS existente?

Absolutamente. La mayoría de los sistemas de gestión de contenido de componentes, como IXIASOFT, Heretto o Oxygen Content Fusion, le permiten exportar paquetes DITA sin procesar. Puede cargar estos paquetes directamente en MotaWord y luego volver a cargar los resultados traducidos en su CCMS sin ningún paso de conversión intermedio.

6. ¿Cómo reducir los costos de traducción DITA utilizando memorias de traducción?

Al cargar todo su Ditamap en una plataforma nativa, el sistema utiliza la memoria de traducción (TM) para identificar coincidencias exactas con sus proyectos anteriores. Solo se le facturará el texto nuevo o modificado, lo que reduce significativamente los costos en proyectos de documentación técnica a largo plazo.

7. ¿Cómo manejar la localización de imágenes DITA y hrefs?

Cuando carga su proyecto DITA de forma nativa, el sistema reconoce las etiquetas de imagen y enlace. Puede especificar si desea que las rutas a estas imágenes se actualicen en carpetas localizadas (por ejemplo, cambiando una ruta de /images/en/ a /images/es/) o se mantengan exactamente como están. Esto garantiza que sus enlaces nunca se rompan en la versión traducida.

Detener la conversión y comenzar a sincronizar con MotaWord

Si su flujo de trabajo de traducción actual se siente como un obstáculo manual que detiene su impulso, es probable que sea momento de alejarse de la conversión XLIFF y avanzar hacia un flujo de trabajo DITA nativo. Al eliminar esos pasos manuales, reduce el riesgo de errores de documentación y acelera significativamente sus ciclos de lanzamiento globales.

Su experiencia debe centrarse en crear contenido excelente, no en gestionar exportaciones de archivos. ¿Estás listo para ver cuánto tiempo y esfuerzo puedes ahorrar en tu próximo proyecto? Puede obtener una cotización instantánea en MotaWord cargando sus archivos .dita hoy.

OYTUN TEZ - Director de Tecnología (CTO) en MotaWord

Especialista en estudios de traducción con una tesis sobre traducción automática, tecnólogo en general y obsesionado con los flujos de traducción inteligentes y fluidos.