¿El momento de cambiar de herramientas?

No podemos cerrar el estudio sin examinar las propuestas de la industria de la traducción: la especificación XLIFF y sus herramientas. ¿Está el software libre a la altura? Por Juan Rafael Fernández García.

Historial de versiones
Revisión 0.2	2007-03-01	jrf
Corrijo un par de despistes en la cabecera.
Revisión 0.1	2007-03-01	jrf
Primera versión CC 2.0 del artículo de Linux Magazine.

De la salvaje segunda entrega nos quedan varias heridas abiertas. Una eran las insuficiencias del formato PO, ese arcaico formato de la era pre-XML. ¿Existe alguna alternativa libre, alguna solución hacia la que correr?

I. El verano en que creímos tener una respuesta

El verano de 2005 fue especial para el mundo de la traducción libre: por un lado Tim Foster había anunciado el 21 de junio la disponibilidad en abierto de las legendarias (llevábamos años esperándolas) herramientas internas de Sun, las Open Language Tools (hablaremos de ella más adelante), que nos iban a permitir trabajar al fin en el formato XLIFF; también teníamos Transolution, y los filtros de Fredrik Corneliusson y de Rodolfo Raya... En su ingenuidad, un servidor montó su ponencia en los Encuentros de Software Libre de Dijon[1] sobre la tesis de que era el momento de adoptar masivamente el formato y las herramientas XLIFF para traducir los documentos de nuestros programas y nuestros recursos.

¿Qué ha pasado mientras tanto? Para comprenderlo hay que empezar analizando el nuevo formato.

II. La especificación XLIFF

La FAQ de XLIFF en OASIS define el XML Localisation Interchange File Format, XLIFF, como una especificación (no es todavía un estándar OASIS, pero en su momento será un estándar bendecido por la poderosa industria de la localización) para el intercambio sin pérdida de datos de localización y de la información relacionada con ellos[2]. Por tanto se trata de un formato para almacenar cadenas de texto extraídas de un fichero original que se desea traducir, y permite incorporar información adicional sobre el documento original (como el esqueleto de su formato, que se utilizará para generar el fichero traducido en el mismo formato) y el proceso de traducción.

Los documentos XLIFF suelen tener la extensión .xlf, o .xlz si están comprimidos. Es trivial generar un documento XLIFF porque existen conversores de formato adecuados. Como experimento vamos a crear un fichero .xlz a partir del .html de una versión provisional del documento que estamos escribiendo. Utilizamos los OLT XLIFF Filters; sólo hemos tenido que arrastrar y soltar el fichero texto_fuente.html sobre la ventana del conversor (figura 1). El resultado es texto_fuente.html.xlz, un paquete ZIP comprimido con tres ficheros: workflow.properties, skeleton.skl (con la información que permitirá recuperar el formato original) y content.xlf[3], que es el que nos interesa. Lo examinamos con un editor de texto (figura 2): se trata de una plantilla XLIFF 1.0. Para empezar apreciamos un error en la conversión: a pesar de que nuestro fichero fuente, html 4.0 correcto (revisado con tidy), indicaba que se trata de un texto en castellano (lang=``es''), el filtro decide que el texto de partida de la traducción tiene que ser el inglés de Estados Unidos (en-US).

Iniciando el paralelismo con el sistema Gettext/PO que hemos analizado en las anteriores entregas y al que queríamos llegar, nos encontraríamos en el momento de la creación de la plantilla POT. Y ahora sería el momento de traducir las cadenas de texto. Utilizamos (en un momento hablaremos de los editores XLIFF) el OLT Translation Editor. Creamos un proyecto de traducción del castellano al inglés (figura 3), cargamos el fichero .xlz y comenzamos a trabajar (figura 4, con la presentación en forma de dos paneles enfrentados verticalmente y las correspondencias en la base). Si ahora guardamos el trabajo y volvemos a examinar texto_fuente.html.xlz veremos que el único que ha cambiado es content.xlf (esto no es del todo exacto: si hemos guardado la que llama la Mini-TM también se habrá creado en ~/.xliffeditor). Veamos más de cerca qué se ha generado

 <trans-unit id="a1" translate="yes" reformat="yes" xml:space="default">
   <source>El ciclo de la traducción</source>
   <target xml:lang="en-US" state="auto-translated:translated">
     The Translation Cycle
   </target>
   <count-group name="word count">
     <count count-type="word count" unit="word">5</count>
   </count-group>
   <note priority="1">Este es el título</note>
   </trans-unit>
 
   <trans-unit id="a2" translate="yes" reformat="yes" xml:space="default">
   <source>La traducción del software libre</source>
   <target xml:lang="en-US" state="user:rejected">Free Software Translation</target>
   <count-group name="word count">
    <count count-type="word count" unit="word">5</count>
   </count-group>
 </trans-unit>
 
 <trans-unit id="a3" translate="yes" reformat="yes" xml:space="default">
   <source>El ciclo de la traducción</source>
   <target xml:lang="en-US" state="user:approved">The Translation Cycle</target>
   <count-group name="word count">
     <count count-type="word count" unit="word">5</count>
   </count-group>
 </trans-unit>

Examinemos el fragmento; es evidente que ya no es realista esperar que se pueda trabajar en la traducción con un editor de texto normal, como se podía hacer con un fichero PO, por desagradable que fuera la experiencia: es necesario un editor de XML o mejor un editor creado expresamente para trabajar con XLIFF. El «código fuente XML» debe ocultarse al traductor (y las marcas XML deben protegerse como se protegía el código fuente de un programa). Hemos traducido tres segmentos (oraciones: el filtro de conversión ha segmentado el original por oraciones), que se convierten en «unidades de traducción», trans-units, con identificadores únicos (a1, a2, a3). Encontramos la clásica oposición entre cadena original y cadena traducida (ahora como segmento fuente, source, frente a segmento destino, target). Pero la información proporcionada es mucho más amplia: por un lado el número de palabras de cada segmento; por otro, información de uso de la memoria de traducción (vemos que el fragmento a1 ha recibido su traducción del fragmento a3), con la marca state="auto-translated:translated" (también se incluirían datos de un glosario si se hubiera utilizado); información de contexto (y comentarios...); y finalmente, mucho más importante y novedosa, de revisión: el estado de aprobada o rechazada (state="user:approved" o state="user:rejected") de la traducción del segmento por un posible segundo agente en el proceso (¡al fin espacio para un revisor!).

¿Qué pretende aportar XLIFF? ¿A qué problemas responde? La FAQ de XLIFF enumera una serie de problemas que hacía necesaria la creación del formato

Si nos fijamos en los anteriores argumentos en favor de la necesidad de XLIFF nos daremos cuenta de que el formato ocupa el mismo nicho ecológico que el formato PO. Vendría a ser la versión XML y contemporánea de lo que pretendía ser PO desde el comienzo. Salvo que el formato PO no se ha utilizado por la industria de la localización, y salvo los problemas del sistema (ver la segunda entrega, en Linux Magazine 20), que no vamos a repetir.

Ahora estamos en condiciones de comprender el problema que se presenta a los desarrolladores y traductores del mundo del software libre ante la idea de cambiar de PO a XLIFF: es verdad, posiblemente sea un formato superior, pero... ¿están el sistema de extracción de cadenas y generación de los ficheros .xlf, están las herramientas especializadas de traducción y el conversor de vuelta al formato original en una fase tan madura y tan comprobada como la del sistema Gettext/PO?

III. Examen de los filtros XLIFF

Empezaremos hablando de las XLIFF PO Tools, del ¿australiano? Asgeir Frimannsson. Xliff-tools es un conjunto de utilidades para la conversión entre los formatos PO y XLIFF. Se trataría de po2xliff (el conversor de PO a XLIFF), xliff2po (conversor inverso de XLIFF a PO), xliffinit (inicializa un fichero XLIFF para una lengua específica) y xliffmerge (fusiona un fichero XLIFF traducido con una plantilla XLIFF actualizada).

El flujo de trabajo sería el esquematizado en la figura 5. Dos problemas hacen que debamos seguir buscando: por un lado Frimannsson ha comunicado que después de junio de 2005 abandonó el mantenimiento de los filtros; en segundo lugar el itinerario Fuente -> PO -> plantilla XLIFF -> XLIFF traducido -> PO -> Destino no parece el óptimo: ¿qué sentido tiene la presencia doble de PO y XLIFF en el flujo de trabajo? Si sus funciones son paralelas no deberían aparecer simultáneamente en el mismo proceso, ¿verdad?

Similares, y también parte del «Proyecto de herramientas XLIFF», son las xliff-tools-java, de Rodolfo M. Raya. Aporta dos conversores: po2xliff.sh y xliff2po. ¿Por qué interesa esta interoperabilidad entre PO y XLIFF? Ahora caemos: ¡para lograr la unificación de bases de datos de traducciones, de memorias de traducción y de glosarios! ¡para permitir la interoperabilidad entre proyectos con distinto origen! Espero que el lector paciente empiece a adivinar a dónde queremos llegar en este largo y tortuoso razonamiento, que ha ocupado -no sé si lo sabe- casi cuatro años.

Pero ahora estamos presentando conversores. Otro filtro es XliffRoundTrip. Afirma automatizar el camino de ida y vuelta entre cualquier fichero XML y XLIFF. Consiste en una aplicación en java y dos archivos XS. El primero, xml2xliff.xsl, transforma XML en XLIFF. El segundo, xliff2xml.xsl, reconvierte el XLIFF en el XML traducido.

También hemos encontrado file2xliff4j, de Airin, Sonny Zubia y Weldon Whipple, en estado alfa según su página en Sourceforge. Al parecer utiliza un proceso OpenOffice abierto con la orden soffice -headless -norestore -accept="socket,port=8100;urp" y por tanto utiliza los filtros de OpenOffice. Requiere una numerosa lista de bibliotecas java, entre otras JOOConverter, que convierte los documentos de Word, Excel, PowerPoint y RTF a ODT y después convierte el documento ODT a XLIFF).

Mucho más maduros parecen los OLT XLIFF Filters, también en java, complementarios del OLT Translation Editor. La lista de ficheros que puede convertir es importante: HTML, Docbook SGML, JSP, XML (filtro genérico -- requiere un fichero de configuración para cada tipo de XML), OpenOffice.org y Open Document Format (sxw, sxc, sxi y odw, odc, odi), texto plano, PO (gettext), Msg/tmsg (catgets), ficheros .properties y ResourceBundle de java, archivos de recursos .DTD de Mozilla.

Tampoco debemos olvidar que el Translate ToolKit complementario de Pootle incluye po2xliff.py y xliff2po.py[4]. Volveremos sobre esto porque hay aquí una clave que nos había pasado desapercibida.

IV. El editor XLIFF Transolution

Transolution[5] (anunciado como EvilTrans en marzo de 2005) se presenta como una suite de traducción de fuente abierta que consiste en un editor XLIFF, un motor de memorias de traducción (a cargo de Fredrik Estreen) y unos filtros XLIFF.

El editor XLIFF está desarrollado en python y con las bibliotecas gtk y glade por Fredrik Corneliusson. A pesar de sus prometedores primeros pasos, de su licencia GPL y de la cercanía que proporciona el uso de las bibliotecas y widgets con los que el usuario está familiarizado, ha vuelto a ocurrir la tragedia del desarrollador independiente: el 28 de enero de 2006 Fredrik Corneliusson anunció que el desarrollo de Transolution quedaba suspendido porque había cambiado de empleo y la nueva ocupación no le dejaba tiempo para continuar con su desarrollo. Y sí, vamos a insistir por si ha pasado desapercibido, la pérdida de un editor XLIFF GPL es una tragedia.

¿Cómo funciona? Después de descomprimir el paquete con la aplicación se activa el bit de ejecutable de xliffeditor.py y se lanza la aplicación. La figura 6 es una captura del editor tras abrir nuestro fichero de prueba.

V. El Open-Language Tools Translation Editor

En este caso sí que se trata de un proyecto vivo ¡y con todo el poder de Sun detrás! La versión 1.2.6 es de 8 septiembre 2006[6]. La licencia es la semi-libre Common Development and Distribution License (CDDL) de Sun, versión 1.0, con todas las implicaciones de requerir la máquina virtual java de Sun 1.5. Realmente no es nada satisfactorio que el único editor de XLIFF vivo de código abierto tenga esta dudosa licencia.

La herramienta de Tim Foster está muy bien documentada, y se glosa también (figura 7) el proceso de traducción por medio de XLIFF. Ya la hemos mostrado en uso, y no tenemos más que fijarnos en la potencia de la interfaz para añadir marcas (traducido, revisado y aprobado...) El primeramente llamado OLP STE (ha sido durante años una herramienta interna de Sun) incluye varias características avanzadas: permite importar y exportar memorias de traducción en formato TMX, e incluye un formato interno de memoria de traducción, Mini-TM, con el que se pueden fusionar memorias de distintos proyectos; está concebido para la creación de bases de datos de traducciones. El resultado, por supuesto, es el fichero traducido (figura 8) en el formato original (y nuevas entradas en la base de datos de traducciones y en la memoria de traducción).

VI. ¿Desencanto? ¿Qué desencanto?

Sin embargo desde el verano de 2005 la situación ha cambiado. No se puede decir que los traductores de software y documentación libres se hayan pasado en masa al mundo de XLIFF. Hay voces que rechazan su adopción por pesado, complejo e innecesario. Asgeir Frimannsson ha abandonado sus filtros. Fredrik Corneliusson ha suspendido el desarrollo de Transolution. Pero es que hay más. El 26 de julio de 2005 Rodolfo M. Raya envió a la lista xliff-tools@lists.freedesktop.org el resultado de un experimento. Simplemente había descargado los cuatro ejemplos de documentos XLIFF disponibles en el sitio de OASIS[7] y había intentado abrirlos con los distintos editores. En la tabla 1 podemos leer el resultado que obtenía.

Advirtamos para el lector no avisado que Raya hace la comparación examinando también software no libre y que es el desarrollador principal (espero no equivocarme aquí) del editor Heartsome. He realizado la misma prueba con las versiones actuales del editor OLT (1.2.6) y Transolution (0.4b5): los resultados son idénticos a los de Raya. Y es sorprendente, porque en nuestro ejemplo anterior el funcionamiento de los dos editores había sido impecable. Claro: el editor OLT no tiene problemas para leer un XLIFF generado por los filtros OLT.

¿Qué significa este resultado? Para hacerse una idea recordemos que XLIFF es un formato complicado, pero pensado específicamente para la compatibilidad («para el intercambio sin pérdida de datos» que decía la definición de la especificación). Es aceptable que un editor vaya añadiendo detalles en su cumplimiento del futuro estándar (un documento puede contener una carga de información compleja, pero el reconocimiento o no de unos determinados elementos y atributos es opcional); lo que no es de recibo es que trabaje con una versión modificada y propia de la especificación, y no sea capaz de abrir ni siquiera los ejemplos XLIFF más simples.

¿Quiere esto decir que la opción XLIFF ha fracasado? ¿Que, a pesar de que en abstracto XLIFF sea un formato superior técnicamente, en la práctica no está justificado el esfuerzo de migración ni las herramientas disponibles son adecuadas?

VII. PO y XLIFF ¿frente a frente?

El 16 de febrero de 2005 Bruno Haible, al que ya conocemos como responsable actual de gettext, enviaba la siguiente reflexión a la lista xliff-tools@lists.freedesktop.org:

«El formato XLIFF, con todos sus elementos específicos, está obviamente destinado a los traductores profesionales y al flujo de trabajo dentro de las empresas. El formato PO, por otro lado, fue concebido para un flujo de trabajo simple, consistente únicamente en un desarrollador y un traductor (...) Esto es enteramente suficiente para el 95% de los proyectos de fuente abierta (...) Para el restante 5% de proyectos, los mayores, como OpenOffice, GNOME, etc., ciertas necesidades específicas (por ejemplo flujos de trabajo más complicados, o la desambiguación de los mensajes de la interfaz gráfica de usuario por el contexto) no son cubiertas por los archivos y las herramientas PO».

Hay textos que son iluminadores en su claridad. Por un lado Haible no queda satisfecho tras el reconocimiento de necesidades no satisfechas por su sistema: hemos visto cómo las últimas versiones de gettextt permiten proporcionar información de contexto. Pero además creo que toca los conceptos clave de la cuestión: profesionalización de la traducción, flujo de trabajo, escala.

¿Puede el software libre dejar pasar el tren de la profesionalización? ¿Puede ignorar las exigencias, no sólo de continuidad (un traductor voluntario puede abandonar una traducción si lo desea, no está obligado más que por su compromiso moral) y de coordinación de equipos (¿hay muchas empresas en el mundo capaz de generar el número de líneas de código o de documentación que se generan en el mundo FOSS?), sino de calidad (corrección ortotipográfica, completud del flujo de trabajo de asignación de tareas, traducción, revisiones, actualizaciones, pero sobre todo validez terminológica y semántica de la traducción)? Y además, ¿tiene sentido continuar como un reducto aislado en el mar de la localización, alejados de los llamados traductores profesionales y de las técnicas y tecnologías aprendidas en las Escuelas de Traductores? Es verdad, una aplicación sola es normalmente cosa de un equipo reducido, pero esa aplicación será parte de un proyecto mayor, sea GNU, Gnome, KDE... y la terminología y las traducciones de ese proyecto global deben ser coherentes, y ese proyecto se mantendrá y actualizará periódicamente o morirá.

¿Estamos en un callejón sin salida? Vamos a recuperar un fragmento de las especificaciones funcionales del proyecto WordForge:

«En la actualidad el formato Gettext/PO es la base de toda la localización del mundo FOSS. No obstante XLIFF es un estándar emergente. Por consiguiente el conjunto de herramientas hará abstracción del uso de PO o de XLIFF, de manera que puedan utilizarse indistintamente. Esta abstracción permitirá que los herramientas sigan siendo útiles a los que trabajan en la localización si continúan usando PO, pero también permitirá la migración al más rico formato XLIFF.

Los archivos de los diferentes proyectos FOSS que van a traducirse se convertirán a PO o a XLIFF usando filtros de conversión de entrada. Seguidamente los ficheros se envían a pootle. Una vez traducidos y revisados, se vuelven a convertir al formato original usando filtros de conversión de salida (...)

Además pootle puede utilizar glosarios TBX y memorias de traducción TMX para mejorar el contenido de los ficheros PO o XLIFF que se presentan a los traductores y revisores, facilitando así el trabajo del traductor y asegurando la calidad de las traducciones. La calidad se garantiza mediante varias comprobaciones(...)»

Vaya vaya, va a resultar que la tecnología TMX, TBX, XLIFF, está integrada y abstraída en pootle (al menos como proyecto en sus especificaciones). ¿Alguien había hablado de desencanto? Ahora comprendemos que tanto el esquema de la figura 5 como el de la figura 7 son válidos: en el primer caso se trata del proceso de migración y de creación inicial de la base de datos de traducciones; en el segundo del trabajo directo con XLIFF. Quizás las herramientas no estén terminadas pero el camino parece estar claro.

VIII. Y en el próximo número...

Nos falta hablar de dos cosas. Por un lado, extraer conclusiones de nuestra panorámica de herramientas y formatos, cinco entregas de datos sin tomar decisiones y hacer propuestas no nos parece aceptable. Por otro examinar el flujo de trabajo de los equipos de traducción al castellano. Que el bosque de los detalles no nos haga olvidar que el objetivo inmediato de esta serie de artículos era lograr la incorporación de voluntarios a los equipos de traducción.

Imágenes

Figura 1: El filtro de las Open-Language Tools en acción.

Figura 2: El documento XLIFF creado.

Figura 3: Creación de un proyecto en el OLT XLIFF Translation Editor.

Figura 4: Uso del OLT Transeditor.

Figura 5: Flujo de trabajo con xliff-po-tools.

Figura 6: Transolution.

Figura 7: Proceso de traducción con XLIFF.

Figura 8: Momento de la generación del fichero traducido.

Notas

[2] El Borrador final de la versión 1.0 es de finales de mayo de 2001; el 20 de mayo de 2003 se aprobó ya en OASIS la versión 1.1 de XLIFF; el periodo de revisión pública del Borrador de la especificación 1.2 finalizó el 12 de septiembre de 2006.
OASIS (http://www.oasis-open.org/who/) es la Organization for the Advancement of Structured Information Standards, un consorcio internacional de empresas y organismos que trabaja para «el desarrollo, la convergencia y la adopción de estándares de comercio electrónico». La FAQ de XLIFF en Oasis: http://www.oasis-open.org/committees/xliff/faq.php. Sobre el Borrador de la especificación 1.2, http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xliff (o la forma abreviada http://www.xliff.org/). Para la historia y los antecedentes de XLIFF, ver http://www.opentag.com/xliff.htm.

[3] Según la documentación del Editor de traducción del OLT, «el fichero .xlz contiene todos los segmentos fuente del fichero original y todas las correspondencias (matches) halladas para cada uno de estos segmentos en la base de datos de traducciones. Contiene también el formato del fichero fuente original para que el fichero .xlz traducido pueda ser reconvertido a su formato original».

Tabla 1: Estudio de Rodolfo Raya de los editores XLIFF (julio de 2005)
Editor	Ejemplo 1	Ejemplo 2	Ejemplo 3	Ejemplo 4
Heartsome XLIFF Editor 5.0-8	OK	OK	OK	OK
Open Language Tools RC 1.1	No lo abre	No lo abre	No lo abre	No lo abre
Transolution Alpha	OK	OK	OK	OK
Trados 7.0	No funciona	OK	OK	No funciona
SDLX	OK	OK	OK	OK

La traducción del software libre (IV)