Preparación de nuevos tipos de archivos con herramientas CAT (con JSON de ejemplo)

Hola a todos:

En los últimos meses me he venido encontrando un formato de archivo que no había recibido antes para preparar para traducción. Se trata de JSON (JavaScript Object Notation). JSON se utiliza principalmente como una alternativa a XML para transferir e intercambiar datos de forma sencilla. Además es también bastante común el encontrarse este tipo de datos como información integrada (embedded) dentro de otros tipos de archivo (por ejemplo, dentro de archivos JavaScript).

La cuestión es que en este post adjunto el tipo de archivo JSON que he preparado para SDL Trados Studio. No obstante, en este caso lo que me parece interesante es el comentar el proceso para aprender a crear (conceptualmente, con independencia de la herramienta CAT usada para traducir) cualquier definición de tipo de archivo.

Lo primero que hay que hacer al encontrarnos con un nuevo tipo de archivo es documentarnos. En el caso de JSON (y de la mayoría de archivos ligados a la programación web), Wikipedia (http://en.wikipedia.org/wiki/JSON) y w3schools (http://www.w3schools.com/json/) son siempre una buena opción. Tras documentarnos sobre las características formales el tipo de archivo es importante hacerse con unas copias y ejemplos (a ser posible, reales y del cliente para el que trabajemos) para comprobar que siempre vamos a trabajar con la estructura correcta. En el caso de JSON, según la definición estándar, la sintaxis se estructura en torno a pares de valores entrecomillados (comillas dobles) y separados por dos puntos. Por ejemplo:

“nombre” : “Alvaro”, donde “nombre” es el campo y “Alvaro” es el valor.

Dado que JSON se emplea a menudo como alternativa a XML, es interesante ver la analogía con la sintaxis de éste último, <nombre>Alvaro</nombre>.

Esta estructura (“elemento” : “valor traducible”) es la base sobre la que se crean otras más complejas como se puede observar en los diversos archivos de ejemplos, en los que hay diferentes niveles anidados y matrices con información. Pero, ¿es esto realmente importante?

Estructura Json

En realidad, no es algo decisivo. A efectos de traducción, lo interesante es que hemos identificado que la información que se desea traducir es únicamente el valor entrecomillado que hay tras los dos puntos en cada par de valores. Por tanto, al crear nuestro tipo de archivo, conceptualmente hay que pensar algo como “sólo quiero traducir todo lo que haya entre dos puntos, comillas dobles de apertura y las comillas dobles de cierre” (:”TODO ESTO SERIA TRADUCIBLE, PERO NO MAS”).

Una vez hemos llegado a este punto, lo que hay que hacer es trasladar esa idea a la herramienta que utilicemos a fin de que al procesar los archivos únicamente se extraiga como texto traducible lo deseado.

Seleccionar tipo de definición de archivo

En el caso de la definición de archivo JSON que he preparado para SDL Trados Studio, partí de la base de usar expresiones regulares porque me siento bastante cómodo con ellas (y porque era la opción más viable que había). Una vez hecho eso, la cuestión fue plasmar “sólo quiero traducir todo lo que haya entre dos puntos, comillas dobles de apertura y las comillas dobles de cierre” en una expresión regular. Este podría ser un desglose del razonamiento

1. “elemento” : “valor traducible” –> Estructura general
2. : “valor traducible” –> Estructura traducible (incluyendo espacios)
3. : “cualquiertexto” –> Estructura traducible (incluyendo espacios)
4. : “–> Expresión de inicio de segmento
5. Cualquiertexto –> Texto traducible
6. ” –> Expresión de fin de segmento

Tras desmembrar la idea, ya solo es cuestión de escribir la expresión regular en el lugar adecuado en la herramienta CAT (Studio en mi caso). De todas formas, nunca está de más hacer unas cuantas pruebas en herramientas que permitan hacer búsquedas con expresiones regulares como, por ejemplo, Notepad ++. En el caso de JSON, la expresión completa para pruebas sería :\s*?».*?» (descripción de la expresión regular: dos puntos seguidos no obligatoriamente por 1 o más espacios en blanco, comillas dobles, cualquier combinación de números, letras y espacios en blanco y finalmente otras comillas dobles).

Pruebas

Tras hacer todas las comprobaciones que se deseen y configurar la regla general de extracción del texto traducible en el archivo podemos definir otros parámetros (entre otros la extensión de archivo predeterminada para la definición que en la que yo os ofrezco es .json) adicionales como la gestión de elementos internos, etc. En mi definición, aunque no tenga mucho sentido he puesto, por si las moscas, que se traten como elementos no traducibles todas las posibles etiquetas (por si alguien integra html dentro de JSON).

Creo que eso es todo. Me parece que con esta breve explicación cualquiera que se ponga a pensar un rato podrá hacer frente a nuevos tipos de archivo como JSON y prepararlos para traducirlos con CAT en lugar de manualmente.

Archivo de ejemplo 4 preparado

Y ya que estamos, además la definición de JSON para Studio, también os dejo la de los archivos .rc de Windows que, aunque parezca mentira (¡a estas alturas de la vida!), hace poco me llegó un archivo rc para traducir. Aquí va pues la definición de tipo de archivo RC.

Con eso me despido. Espero que algunos os animéis con archivos “raros” a partir de ahora.

Un saludo,

Álvaro

Recomendación musical: Miracle un tema un poco antiguo de los Foo Figthers que escuché de fondo en Camden mientras paseaba con mi mujer y se me ha quedado en el coco.

Anuncio publicitario

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.