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?

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.

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

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).

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).