El viejo TagEditor, insuperable para la creación de definiciones de tipo de archivo

Hola a todos.

Este mes escribo para hablar sobre una de las funciones favoritas de un programa denostado por mucha gente debido a su edad, TagEditor (la última versión salió en 2005, y se actualizó con la última versión de la suite de trabajo de 2007 de SDL International). Bueno, en realidad me dispongo a comentar esta función porque he tenido que recurrir a ella en diversas ocasiones para crear definiciones de tipo de archivo cuando los archivos de trabajo que he recibido no las tenían y se me planteaban multitud de problemas. Me explico con un ejemplo práctico (y real) para poder hacerme entender con más facilidad.

Hace unas semanas recibí de un cliente un lote de archivos que conformaban un sitio web que venían generados a partir de un conocido y popular CMS (Content Management System). En concreto, los archivos que contenían el texto traducible habían sido exportados a formato .html por la empresa de gestión web del cliente, lo que en un principio me pareció comodísimo: ¡qué mejor que un volcado completo para traducirlo! Nada más lejos de la realidad. Me puse a examinar los archivos y comprobé (tras intentar lanzar el sitio web en local) que en realidad los archivos no eran HTML propiamente dicho, sino que eran archivos codificados totalmente como XML, desde la declaración de la primera línea hasta el resto de la estructura conformada por innumerables etiquetas personalizadas (que es, por otra parte, la ventaja de trabajar con XML).

Estructura de XML con extensión .html

La cuestión es que cuando fui a preparar mi proyecto de trabajo con mi herramienta CAT, ésta reconoció los archivos como .html, y como texto para traducir en el editor me salían, obviamente, un montón de cosas que no debían ser texto traducible. Esto se debe a que la definición del tipo de archivo de HTML habitual de las herramientas CAT es cerrada, es decir, sólo incluye los elementos y atributos oficiales de HTML. Os pongo una captura de un archivo sencillísimo que había pero que ilustra bien el problema (de 8 segmentos, 5 en realidad no eran traducibles):

Texto traducible sin definición de tipo de archivo personalizada

A fin de remediar el problema hice lo siguiente: en primer lugar, cambié la extensión de todos los archivos de .html a .xml (eran más de 1.000 archivos, así que utilicé un comando de Windows), de manera que la extensión de los archivos coincidiese con su contenido y estructura real, de forma que la herramienta CAT los procesara como XML; en segundo lugar, dado que los archivos .xml exportados del CMS del cliente contenían diversos elementos (mezcla de elementos habituales en HTML y de elementos y atributos XML personalizados) decidí recurrir a TagEditor para crear una definición de tipo de archivo nueva que incluyese todos los elementos y atributos presentes en el sitio web para así poder especificar de qué tipo eran cada uno y si su contenido era traducible (puesto que no había recibido ningún kit de localización preparado con su .ini ni nada por el estilo).

Varias herramientas te permiten crear y personalizar tipos de archivos, pero a mí me gusta personalmente TagEditor por su flexibilidad y porque los archivos para la definición se pueden añadir en lotes gigantes sin que se corte. Para crear una definición de tipo de archivo en TagEditor:

1 – Abrimos TagEditor.

2 – Seguimos la ruta Tools > Tag Settings > New.

3 – En el primer panel del asistente, tras dar un nombre a la definición, seleccionamos (en el caso de XML) New Settings for XML.

4 – En el siguiente paso, el más importante, dado que en mi caso no tenía ni dtd, ni xsd ni ini (por eso tenía que crearla yo), seleccionamos Import y añadimos todos los archivos del proyecto.

5 – Tras confirmar el aspecto de los elementos y atributos, llegamos al paso donde se define cómo se gestiona el contenido de cada etiqueta. Por ejemplo, en mi caso, tras consultar con el cliente se determinó que el contenido de etiquetas XML personalizadas como, entre otras, target, uuid o link no se traducían; por tanto, mi cometido consistió en protegerlas, es decir, establecerlas como no traducibles. Para ello, por ejemplo, seleccioné la etiqueta uuid, pinché en Properties y, dentro del cuadro de diálogo abierto, únicamente tuve que definir el tipo de contenido, tipo de etiqueta y, por último, determinar que el contenido debía ser no traducible [Not translatable (protected content)].

Definición de etiqueta xml uuid

Ya os podéis imaginar el resto del trabajo: analizar todas las etiquetas para identificar las no traducibles, así como definir también los atributos (por ejemplo, dentro del elemento content, el atributo lang debía ser traducible mientras que el atributo name no).

Para finiquitar la tarea de definición de tipo de archivo, en el asistente de TagEditor definimos cómo queremos convertir las entidades XML y añadimos las personalizadas (si las hay) y, en última instancia, guardar nuestra nueva y flamante definición de tipo de archivo (.ini), que usaremos con nuestra herramienta CAT (creamos un nuevo tipo de archivo e importamos este archivo .ini).

Este tipo de tareas de ingeniería de localización puede resultar bastante tedioso y hay que tener mucho cuidado al analizar todos los elementos. No obstante, se obtienen dos ventajas fundamentales:

–         Se evita perder tiempo traduciendo texto que no se debe y que además se incluye incorrectamente en el recuento (con los problemas que ello conlleva).

–         Se delimitan bien posibles problemas futuros. Al identificar qué se traduce y examinar la estructura de los archivos se suelen hallar problemas de falta de internacionalización, etc. Todo ello contribuye a anticipar posibles problemas al procesar los archivos traducidos y solucionarlos de antemano.

En mi caso concreto, además contribuyó a que el cliente fuese consciente de lo complejo que puede resultar algo tan “sencillo” (o eso pensaban ellos) como traducir el texto de un sitio web. Al crear la definición del tipo de archivo puse de relieve mi valor añadido como profesional y, al mismo tiempo, me curé en salud porque, tras utilizar el archivo .ini creado, el texto a traducir resultaba mucho más user friendly. De hecho, retomando el ejemplo de la captura del principio, la cosa quedó así (solamente se mostraban los 3 segmentos realmente traducibles, las referencias y llamadas a otros archivos quedaban excluidas):

Texto traducible con definición de tipo de archivo

El quid de toda esta exposición radica en algo que a título personal me pareció realmente paradójico: para gestionar y preparar una traducción de contenidos creados en los dos últimos años me acabó resultando mucho más práctico usar una herramienta antigua y fiable como TagEditor, que me brindaba más versatilidad que las funciones equivalentes de otras herramientas CAT más modernas… ¡Qué cosas! No sé, quizá sea que como empecé a trabajar con herramientas CAT con TagEditor le guardo un aprecio especial, a modo del primer amor.

Supongo que es posible que el procedimiento de creación de definiciones de tipo de archivo que he descrito (en el ejemplo, para archivos XML) resulte complejo, sin embargo, os animo a hacer pruebas en casa con vuestros propios archivos (empezar por XML es siempre lo más sencillo) porque controlar este tipo de operaciones te da muchísima soltura y seguridad para proyectos y clientes complejos.

Eso es todo. Perdón por la extensión, que se me ha ido la pinza escribiendo. Sólo espero que os sirva a algunos de vosotros para tareas diarias.

Un saludo,

Álvaro

Recomendación musical: unos clásicos como Green Day nos regalan un nuevo tema «Oh, Love» de su nuevo disco titulado Uno, que forma parte de una trilogía.