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

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

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

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.

22 comentarios el “El viejo TagEditor, insuperable para la creación de definiciones de tipo de archivo

  1. Hola, Álvaro: imho, la obligación del cliente es enviarte un fichero INI o DTD cuando te envía un fichero en formato XML/SGML propietario, porque lo que explicas, aunque ciertamente admirable, es un trabajo largo y tedioso (averiguar la estructura de un fichero que puede ser muy, muy largo, y time is money ) que los clientes no están habitualmente dispuestos a pagar y para el cual algunos traductores, sin conocimientos técnicos específicos, no están (y no tienen por qué estar) capacitados.

    Si mal no recuerdo, en algún vídeo en alemán de Youtube sobre Trados 2009 explican que es innecesario tener los ficheros INI o DTD para traducir otros ficheros y que, si son imprescindibles, existe una función que te permite generarlos automáticamente a partir del propio fichero XML o SGML. Puede que sea así, puede que no. Con Trados, nunca se sabe…

    • alvaromira dice:

      Hola, Pablo. Lo que dices es una verdad como un templo. No obstante, como ya sabrás por experiencia la realidad es bien distinta, sobre todo en el caso de los clientes directos, que puedan preparan los archivos de forma no rigurosa. En algunos casos, hacer la inversión de tiempo resulta muy rentable (para trabajos grandes y clientes buenos).
      Un saludo,

      Álvaro

      • Sí, es cierto que muchos clientes no preparan los ficheros que deben traducirse adecuadamente. Pero, imagino que es también un poco por deconocimiento. Encargan que alguien que les haga un sitio Web y este tampoco les informa de los potenciales problemas que puede reresentar su localización / internacionalización / traducción posterior, ni se preocupan por ello (entiéndase, no les entregan los ficheros ini, xsd, dtd, etc. al cliente)

        Aunque tienes muchísima razón en que, si el cliente es bueno y el trabajo interesante, vale la pena el esfuerzo. En este caso, tu mismo dices que ha servido para que el cliente se concienciase de que nuestro trabajo muchas veces implica «mucho más de lo que parece» a simple vista. Un servidor ya se conformaría con que muchos clientes más se percatasen de esto…

      • alvaromira dice:

        Y qué lo digas, Pablo. Pero bueno, supongo que eso es una labor conjunta de todos y cada uno de los miembros de nuestro sector. Y también cuestión de tiempo.
        Gracias por aportar tus reflexiones.

  2. Amanda dice:

    ¡Hola Álvaro! Muchas gracias por compartir esta información con nosotros. Realmente es de gran utilidad y está super bien explicado. Un gran saludo y feliz día del traductor🙂

  3. Usuario anónimo dice:

    SDLX también lleva incluída una herramienta similar y diría que más moderna y simplificada que el TagEditor. Ahí lo dejo.

    • alvaromira dice:

      Gracias por el comentario. Totalmente cierto. Como ya comenté yo mismo en el artículo, la mayoría de las herramientas CAT potentes tienen una función parecida, pero es que a mí sencillamente ésta es la que más me gusta.
      Un saludo,

      Álvaro

  4. Aunque es cierto que el cliente debe facilitarte el trabajo para que no pierdas tiempo en tareas que no son traducir, quería preguntarte… ¿dónde has aprendido todo esto????? ¡Eres un fiera! Muchas gracias por compratirlo, con las horas que te habrá costado…
    Un saludo:
    Marta

    • alvaromira dice:

      Hola, Marta. Gracias por tu comentario y por el cumplido. La verdad es que soy bastante aficionado a la informática, siempre trato de aplicar los conocimientos de informática a la traducción y trasteando un poco los programas, leyendo, preguntando a ingenieros, observando (PUNTO CLAVE) en las empresas en las que he trabajado, etc. Te vas metiendo en una forma de solucionar problemas y al final todo tiene su lógica.
      Además, en el caso de los clientes directos, son fundamentales así que es importantísimo agilizar y optimizar el trabajo para conservarlos y garantizar su satisfacción. Por tanto, es trabajo bien invertido.

      Un saludo y a tu disposición.

      Álvaro

  5. Ja, por primera vez que leo que a alguien le gusta trabajar con TagEditor!! Qué alegría saber que también tiene sus fans!🙂

    • alvaromira dice:

      Gracias por el comentario. De todo hay por ahí. Para mí, cuando se trata de una traducción sencillita de HTML, TagEditor sigue siendo el número uno, su QA Check funciona estupendamente, etc. Un saludo.

  6. Almudena dice:

    Yo también soy gran fan de TagEditor y muchas veces me ha salvado algún proyecto. Además, tiene otra posibilidad muy útil con un plug-in para lenguajes marcados. Igual la conoces, dentro de Plug-ins, el Snippet Mark-up plugin. Allí y mediante expresiones regulares, también puedes proteger las etiquetas que con el .ini no hayan quedado protegidas y ahorrar un montón de tiempo. Por ejemplo, algo de este tipo te protege cualquier etiqueta de inicio: ]*[^/]>.
    Si alguna vez lo pruebas, ya me contarás🙂

    • alvaromira dice:

      Hola, Almudena. EStupenda aportación, ¡qué función tan interesante! No la había conocido. Para delimitar textos que tienen una secuancia determinada casi siempre he visto como solución el uso de extracción de cadenas con expresiones regular vía php o Visual Basic. No obstante, es genial tu aportación. Ahora mismo la estudio a fondo.
      Gracias por participar.

      • Almudena dice:

        Hola de nuevo, Álvaro, veo que la expresión regular que escribí no ha salido publicada correctamente pues algunos caracteres se han transformado, de modo que tal cual sale no te valdrá. Si de todas maneras necesitas estas definiciones para los plug-ins te las puedo pasar. Ya me contarás tus avances y ojalá podamos intercambiar info al respecto (es todo un mundo).
        Un saludo.

      • alvaromira dice:

        Hola, Almudena. Ya me parecía a mí un poco rara esa expresión regular. Es que WP convierte muchas cosas que podrían ser emoticones, entidades, etc. Si quieres, pásame todas las definiciones que tengas y las compartimos con el resto de lectores, que seguro que te lo agradecerán.

        Con respecto a mis avances, estoy leyendo un par de libros sobre expresiones regulares. Cuando acabe seguramente escribiré un artículo básico.
        Un saludo y gracias por tu colaboración.

  7. ¡Hola! Soy una estudiante de Traducción e Interpretación de la Universidad del País Vasco y he estado siguiendo vuestros blogs fielmente durante los últimos meses. Hoy he decidido dar el paso de crear el mío propio y este es el enlace: http://www.olatztranslatesandinterprets.com/
    Estaría muy agradecida y me ayudarías a difundirlo y que compartamos nuestras cosas de aquí en adelante.🙂
    ¡¡¡Muchas gracias y hasta pronto!!!

  8. […] – El viejo TagEditor, insuperable para la creación de definiciones de tipo de archivo, por Álvaro Mira, autor del blog (Nunca) sobran las palabras. […]

  9. ana dice:

    hola, Álvaro. Muchas gracias por llevar este blog que encuentro siempre muy útil. Tengo una consulta con la que quizá puedas ayudarme. Me han enviado un archivo xml con el correspondiente .ini y el análisis. Sin embargo cuando yo realizo el análisis me da una gran diferencia en el nro de palabras “no match”. Además veo que en el análisis que me envía la empresa dice: “Settings file used:..” y en cambio en el mío no. Sabes como lograr que el análisis tenga en cuenta ese archivo?
    Muchas gracias!! Ana

    • alvaromira dice:

      Hola, Ana:
      Utiliza el archivo .ini que tienes para convertir el xml en un ttx con TagEditor y, a continuación, analiza el ttx generado en lugar del xml.
      El resultado debería ser el mismo entonces si se han utilizado las mismas TM para el análisis.
      Un saludo,

      Álvaro

  10. Leandro Rodriguez dice:

    hola una consulta, estoy buscando un programa para poder abrir 2 archivos y entender que dicen para poder modificarlos. abrir los abro pero no se entiende nada lo que no es el programa apropiado. los archivos tienen extensiones INI y TBML si hay algun programador o alguien que me pueda ayudar estaria muy agradecido saludos.

    • alvaromira dice:

      Perdón por la tardanza, Leandro. Ambos son formatos basadas en texto (no conocía TBML, pero le he echado un vistazo), así que deberías poder abrirlos con notepad or Notepad++.
      Un saludo,

      Alvaro

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s