Visualización de archivos TMX en formato tabla

Hola a todos:

Ya no sé si pedir perdón por la falta de inactividad o directamente anunciar que echo la persiana y despedirme, la verdad, :P. En los últimos meses he estado tan liado que no he podido dedicar nada al blog en términos de producción de contenidos (pero sí he continuado respondiendo preguntas y echando una mano por privado). Aunque no puedo prometer que esto vaya a cambiar, el otro día necesitaba hacer un par de cositas con una memoria de traducción (TM) en tmx y creo que esto podría resultar práctico a cualquiera, así que lo tomaré como excusa para escribir un post nuevo.

El tema en cuestión es que hace unos días necesitaba mostrar el contenido de una TM en tmx de una forma visual, de manera que una persona sin conocimientos técnicos fuese capaz de interpretar y analizar sin problemas y rápidamente el contenido disponible en este tipo de formato bilingüe, que habitualmente tiene un aspecto parecido a esto.

Para conseguirlo, se me ocurrió utilizar unas reglas de transformación (xslt) para que, tras aplicar unos cambios sencillos, al abrir el archivo de la TM se abra directamente en el navegador de Internet predeterminado con un aspecto parecido a este.

He adjuntado a este post (TMX-XSL display) un archivo tmx de muestra y el archivo para poder visualizarlo como si fuese una página web en un navegador web (TMX_to_HTML.xsl). El procedimiento que se describe a continuación debería ser válido para prácticamente cualquier TM en TMX (de lo contrario, avisad, por favor):

1) Copiar el archivo TMX_to_HTML.xsl a la misma carpeta donde está el archivo TMX. Por ejemplo, si tenemos el archivo TMX en el escritorio (C:UsersAMADesktoptestTM.tmx) habrá que copiar el archivo de transformación al escritorio también (C:UsersAMADesktopTMX_to_HTML.xsl).

2) Cambiar la extensión del archivo tmx a xml. Por ejemplo, si el archivo tmx se llama testTM.tmx deberíamos renombrarlo a testTM.xml.

3) Abrir el archivo renombrado (por ejemplo, testTM.xml) en un editor como el Bloc de notas o Notepad++.  Añadir la siguiente línea <?xml-stylesheet type=»text/xsl» href=»TMX_to_HTML.xsl»?> justo después de la primera línea del archivo con la declaración de XML (<?xml version=»1.0″ encoding=»utf-8″?> en el ejemplo). Tras hacer el cambio, guardar el archivo. Cerrar el editor de texto.

4) Abrir el archivo TMX_to_HTML.xsl con el editor y situarse en las líneas 18 y 19. En ellas es necesario cambiar los códigos lingüísticos para el source y target (en el ejemplo, ‘en-GB’ y ‘es-ES’) por lo que tengamos en nuestra TM en formato TMX.

Para comprobar el código lingüístico de source y target, podemos abrir el archivo TMX en el editor y fijarnos en los códigos de idioma en cualquier unidad.

Para resumir, lo que hay que hacer es garantizar que los códigos de la TM en tmx y el archivo de transformación (xsl) casan. Tras actualizar el archivo TMX_to_HTML.xsl con los códigos lingüísticos correspondientes, guardamos el archivo.

5) Localizar el archivo que acabamos de guardar y abrirlo con el navegador de Internet (por ejemplo, Firefox).

Tras abrirlo, si las lenguas de tmx y xls casan como se ha explicado en el paso 4) y ambos archivos se encuentran en el mismo directorio o carpeta, el contenido de la TM en TMX debería verse como una tabla en el explorador (si la TM es gigantesca, tardará en abrir).

¿Cómo funciona esto?

Tal y como indica la Wikipedia, las XSLT o Transformaciones XSL son un estándar de la organización W3C que presenta una forma de transformar documentos XML (en el paso dos cambiamos la extensión de archivo a .xml teniendo en cuenta que tmx es un estándar basado por sí mismo en xml). En este caso, lo que hacemos es usar unas reglas XLT para crear una estructura básica de tabla en HTML y finalmente, dentro de las celdas incluir la información de texto source y target de cada una de las unidades de traducción que hay en el TM en TMX.

Para extraer cada una de esas unidades, en el documento XLS se ha especificado una regla que indica que para cada unidad de traducción o tu de la TM (<xsl:for-each select=»tmx/body/tu»>) se busquen específicamente, por una parte, el texto source (<xsl:value-of select=»tuv[@xml:lang=’en-GB’]»/> porque en-GB es la lengua de partida) y se incluya en la columna para el source y, por otra, el texto target (<xsl:value-of select=»tuv[@xml:lang=’es-ES’]»/>, porque en el ejemplo, es-ES es la lengua de destino) y se incluya en la columna para el target.

En realidad, más allá de los archivos en sí, creo que lo más importante es realmente entender cómo funciona la transformación del archivo, cómo se navega a través de la estructura de la TM en TMX para finalmente extraer y mostrar solo la información deseada (para más información sobre cómo moverse por los elementos de la TMX o de cualquier XML, recomiendo leer este tutorial de XPath de w3schools).

Ahora mismo, el proceso con estos archivos es bastante manual, pero creo que para aprender y consolidar el conocimiento y las ideas es válido. Si tengo algo tiempo, intentaré crear una pequeña aplicación para que todo sea más sencillo, pero mientras tanto, espero que la explicación y los archivos de muestra os sirvan.

Sin más, un abrazo.

¡Y espero tardar menos en escribir el próximo post!

– Archivos de ejemplo TMX-XSL display.

– Nota: los códigos lingüísticos aceptados por la mayoría de las CAT son los de Microsoft, disponibles aquí: http://msdn.microsoft.com/en-us/goglobal/bb896001.aspx

– Recomendación musical: Jimi Goodwin (el cantante de The Doves) ha publicado single en solitario, titulado Oh!Whiskey, que podéis ver en http://www.youtube.com/watch?v=HlY_fg65CVQ.

Anuncio publicitario

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.

Preparación de archivos XML con información contextual (vía XPath)

Hola a todos,

En los últimos meses he tenido que preparar bastantes archivos XML para su traducción con SDL Trados Studio. Por mi pasado como traductor, tengo siempre muy presente que cuanta más información haya sobre cada uno de los segmentos que se deben traducir, más calidad tendrá el resultado final. Y si además esa información está disponible dentro de una misma plataforma (en este caso dentro de la herramienta CAT para traducir), mejor.

En este artículo describiré rápidamente cómo aprovechar la información contextual en los XML que la tienen (algo cada vez más habitual en los archivos que se envían para traducción en forma de atributos o elementos de comentario). Para ello, utilizaremos la configuración avanzada de Studio y Xpath (para más información sobre Xpath y traducción, véase, por ejemplo, este post de multifarious).

Como ejemplo de archivo XML, tomaré el siguiente: un catálogo de libros en los que el elemento title (título) contiene un atributo llamado comment (comentario), en el que se ofrece información adicional acerca del propio título del libro. Por ejemplo, en el primer elemento, para el libro XML Developer`s Guide, hay disponible un comentario que dice “This book is also available on a CD. Translate this consistently”.

La idea es que, cuando estemos traduciendo, podamos tener acceso a esta información contextual desde la herramienta CAT en cada una de las unidades de traducción sin tener que abrir el archivo XML e ir haciendo búsquedas manuales.

Una vez hayamos creado nuestra definición de tipo de archivo personalizada para el archivo XML (el asistente hace el trabajo bastante bien, no me voy a detener a explicarlo aquí, quizá en otro post), podemos hacer uso de las opciones más avanzadas para añadir la información contextual que he comentado. Para ello, seleccionamos Tools > Options > File Types y, a continuación, nuestro tipo de archivo personalizado (en el ejemplo es ProcessComments, previamente preparado tras dejar los elementos traducibles). A continuación, accedemos a la sección Parser y seleccionamos elemento para el que queremos añadir la información contextual. Conforme al ejemplo, el elemento en cuestión es title y seleccionamos Edit.

En el siguiente panel, definiremos la regla para el elemento. Además de especificar que siempre será traducible (el título del libro), el siguiente paso será definir el tipo de etiqueta como de estructura (Structure) y dejar el whitespace como la opción predeterminada, salvo que haya algún motivo (y conocimientos suficientes) para cambiarla.

A continuación, hay que hacer clic en Edit, en la parte correspondiente a la información sobre la estructura. Acto seguido, pulsamos Add para añadir una propiedad.

En la pantalla de edición de la información, tendremos que usar como Purpose la opción Information (puesto que los comentarios son meramente informativos) y, a continuación, añadir un nombre (Name). El código y la información de identificación (identifier) se rellenarán automáticamente. Por último, llegamos a la opción más importante, Set description from content of this relative XPath. Mediante esta opción, podemos definir el elemento del archivo XML de donde se extraerá el contenido que se mostrará como información contextual para cada uno de los segmentos en los que se traduzcan elementos title.

En el caso del ejemplo, nos encontramos con la siguiente situación:

<title comment=» “This book is also available on a CD. Translate this consistently»>XML Developer`s Guide</title>.

El elemento title tiene un atributo comment. Esta estructura es de hecho, la estructura del elemento title para todo el archivo XML, así que lo que debemos hacer es enlazar el atributo comment a la opción Set description from content of this relative XPath. Para ello, debemos utilizar la regla de XPath correspondiente. Conforme a la especificación de XPath, debemos utilizar arroba y el nombre del atributo, es decir @comment. Básicamente, con esta regla de Xpath se le dice a Studio que en cada elemento title, busque dentro un atributo comment y, si existe, que muestre su contenido para la propiedad que acabamos de definir como Info Context en el ejemplo.

Por último, también podríamos alterar el formato de todo el elemento title y del contenido de Info context, pero yo particularmente no soy muy amigo de los colorines (en todo caso, recomendaría asignar algún fondo gris o de color no llamativo).

Tras aplicar la regla, al preparar archivos que casen con la definición de archivo preparada para los archivos XML de mi catálogo de libros, la información de contexto personalizada con comentarios para cada unidad de traducción estará disponible en la columna de la derecha en SDL Trados Studio. Como se muestra en las capturas siguientes, al hacer clic en la columna correspondiente en cada segmento, podemos ver los comentarios respectivos desde la herramienta CAT, sin tener que hacer búsquedas en archivos externos (copia texto de origen, abre editor de texto, abre comando de búsqueda, pega texto de origen, encuentra texto de origen y localiza comentario correspondiente).

Al tratarse este artículo de un ejemplo introductorio, el contenido del mismo puede parecer hipersimplificado para las personas con mucha experiencia en la gestión y preparación de archivos XML. Sin embargo, creo que para los que no tienen tanto bagaje,  este post puede picarles la curiosidad para empezar a jugar con las propiedades avanzadas, acercarse a Xpath, etc.

Finalmente, me gustaría aclarar que aunque en el ejemplo he usado SDL Trados Studio, realmente la dinámica de trabajo para preparar archivos de esta forma es prácticamente idéntica en cualquier herramienta CAT. La clave está realmente en aprender a aplicar las reglas de Xpath correspondiente y luego sólo es cuestión de aplicar el concepto a la herramienta CAT en cuestión. No hay más misterio.

Bueno, eso es todo. Espero que os resulte útil esta breve explicación y que os lancéis a mejorar la preparación de vuestros archivos. A medida que se practica y se va teniendo éxito, el perfil de usuario mejora, así que en, al fin y al cabo, terminas por ser capaz de ofrecer un mejor servicio.

Un abrazo y hasta la próxima.

Recomendación musical: lo último que he escuchado de Kings of Leon me gustó bastante, el single se llama supersoaker.

Cambio de rumbo profesional y apertura de Dc. Studio

Hola a todos desde las frías tierras de Zürich:

Ante todo, os ruego me perdonéis por la inactividad reciente, pero es que he estado tremendamente ocupado últimamente. ¿Motivo? Pues un cambio importante en mi vida.

Desde hace más o menos un mes sabía que iba a empezar un trabajo nuevo, así que cais no he tenido tiempo para otra cosa que no fuese preparar papeleos, despedidas, formarme, etc. El cambio en cuestión es que desde el pasado lunes 16 de abril formo parte del equipo de IT de la empresa suiza de servicios lingüísticos CLS COMMUNication, en concreto del departamento de Language Technology. A partir de ahora trabajaré en lo que más me gusta: ayudar a traductores y PjM en apuros, dar formación de herramientas y procedimientos de traducción, desarrollar herramientas y aplicaciones para mejorar el negocio, hacer consultoría y asesorar a clientes y managers, etc.

De momento me encuentro en Zürich conociendo a mis compañeros de departamento y la empresa en general, aunque en breve me trasladaré a Londres, donde seré, entre otras cosas, el IT guy de la oficina de CLS en la capital del Reino Unido.

La consecuencia directa, en cuanto al blog se refiere, es que si ya de por sí últimamente mis artículos tendían a tener un carácter técnico, creo que el camino que seguirá el blog será profundizar en todo tipo de entresijos informáticos relacionados con IT en general, programación y sobre todo con las herramientas CAT.

De hecho, para celebrar el nuevo rumbo que toma mi vida profesional, he decidido crear una nueva sección en mi web denominada Doctor Studio. Dado que en los diferentes artículos que he publicado sobre SDL Trados Studio se han generado bastantes preguntas y debates interesantes, me parece que lo mejor es que de ahora en adelante, los lectores que tengan problemas dejen sus comentarios y dudas en una misma sección centralizada, para que pueda consultarse con mayor facilidad.

Bueno, como todavía estoy bastante ocupado entre unas cosas y otras, os dejo y os invito a visitar la web de mi nueva empresa, así como, en el futuro, plantear vuestras dudas al Doctor Studio.

Un saludo desde tierras suizas.

Atentamente,

Álvaro

Recomendación musical: el pequeño de los Gallagher y los suyos (Beady Eye) sacan nuevo trabajo y su nuevo single suena bastante bien, aquí lo tenéis, Flick of a finger.

Expresiones regulares y traducción (parte III)

¡Saludos a todos y feliz Navidad!

Ya se acerca el final del año 2012, que ha tenido sus más y sus menos, un año con bastantes cambios para mí, la verdad. Para cerrarlo y asimismo poner fin a la serie sobre expresiones regulares y traducción, en el siguiente post veremos los aspectos más avanzados del uso de las regexp que complementan a los operadores básicos vistos en los artículos anteriores de esta serie. Sin más dilación, vamos allá.

Ya sabemos cómo encontrar caracteres literales individuales, así como usar comodines para localizar tipos genéricos de caracteres, ahora es el momento de aprender a gestionar la repetición y el número de caracteres que queremos buscar. Como en los artículos anteriores, veamos una tabla de referencia con los patrones y metacaracteres de búsqueda correspondientes.

Patrones y metacaracteres para gestión de repeticiones

+ (signo más): al incluir el signo más tras una expresión regular, se encuentran uno o más caracteres de dicha regexp. Por ejemplo, mientras que [0-9] sirve para encontrar un número cualquiera entre 0 y 9, [0-9]+ sirve para encontrar uno o más números consecutivos. * (asterisco): se usa exactamente igual que el anterior, solo que el asterisco sirve para encontrar cero o más repeticiones del carácter o rango de caracteres buscados con la regexp escrita. ? (signo de interrogación): se utiliza de forma parecida a los anteriores, con la salvedad de que ? sirve para encontrar cero o una repetición del carácter o rango de caracteres buscados. {x} (corchetes): al crear un expresión regular seguida de corchetes con una cifra, especificamos el número exacto de ocurrencias de la regexp en cuestión que queremos encontrar. Por ejemplo, si ponemos “ {2}”, como resultado encontraremos todos los dobles espacios, pero únicamente los dobles (si hay tres espacios seguidos, no funcionará). {x,y} (corchetes): cuando en un corchete usamos dos cifras separadas por una coma, estamos indicando un número mínimo (x) y máximo (y) de repeticiones que deseamos localizar. {x,} (corchetes): al usar únicamente una cifra y una coma dentro del corchetes, especificamos el mínimo de repeticiones que se deben encontrar. Por ejemplo, si ponemos “ {2,}”, como resultado encontraremos todos los dobles espacios, espacios triples, cuádruples, etc.

Como podéis imaginar, al poder controlar con mucha más precisión la cantidad de caracteres que se recuperan para un intervalo o un único tipo de caracteres, tenemos mucha más potencia a nuestra disposición. Por ejemplo, si retomamos el ejemplo de la localización de números del artículo anterior, ahora podemos ver que dicha expresión podía mejorarse mucho. Así, en lugar de buscar \d\.\d (dígito, punto, dígito), ahora podríamos hacer algo como esto: \d+\.\d+ (uno o más dígitos, punto, uno más dígitos), o incluso precisarlo más con una regexp como \d+,\d{3}\.\d+ (uno o más dígitos – coma- tres dígitos – punto – uno o más dígitos) para buscar números con unidades de millar y decimales en formato de inglés británicos.

Una vez se conocen todos los operadores es cuestión de lo más complicado, es decir, exactamente lo que se comentó en el primer artículo de esta serie: definir bien qué queremos buscar (y eventualmente reemplazar) para así poder crear un patrón o expresión regular que lo represente exactamente.

Las subexpresiones

Tras ver todos los operadores, ahora me gustaría introducir otro concepto, el de las subexpresiones. Se trata sencillamente de usar paréntesis (como en matemáticas) para agrupar búsquedas y tratarlas como un único elemento. Por ejemplo, si en un texto se quieren buscar todos los años que empiecen por 18 o 19, podríamos usar la siguiente búsqueda: (18|19)\d{2}. De esta forma, buscaríamos en primer lugar 18 o 19 (¿se me olvidó mencionar que las regexp también permiten usar la barra vertical | como un operador booleano OR?) y, a continuación, exactamente dos dígitos cualquiera.Esta es en realidad una súper simplificación de todo lo que ofrecen las subexpresiones (siguiendo con el símil de la matemáticas, recordad los infinitos elementos anidados con paréntesis en las clases de álgebra), pero creo que suficiente para dejar claro cómo separar partes significativas de las regexp que creemos.

Bueno, creo que con esta introducción a los operadores para gestión de número de ocurrencias y las subexpresiones podemos dar por conceptualmente concluido este post (¡además se acaba el año 2012 y todavía tenemos muchas cosas que hacer!). Al combinar las nociones de los artículos anteriores y de este, prácticamente cualquier profesional que trabaje como traductor o localizador (en el sentido de la producción lingüística, que no de la preparación de archivos) podría ser capaz de crear expresiones complejas para crear controles de calidad personalizados, hacer búsquedas, filtrar el contenido de archivos, etc. Como ya he dicho anteriormente, el dominio de las expresiones regulares es cuestión de práctica, de cometer errores, de consultar regexp creadas por otros, comprenderlas y crecer desde ellas. Por ello, no puedo sino animaros a continuar practicando y usando las regexp en vuestro día a día para consolidar vuestros conocimientos.

No obstante, dado que en el sector de la traducción y la localización habitualmente las expresiones regulares se suelen utilizar también para la creación de definiciones de tipos de archivos y filtros personalizados para la extracción de cadenas de archivos y la preparación de archivos de traducción y localización, no puedo dar por zanjado este tema sin mencionar que obviamente quedarían por tocar temas como la anidación avanzada, uso de referencias a ocurrencias anteriores (backreferences), uso de operadores con alcance mínimo (lazy) o máximo (greedy), pseudo-variables, conversión entre mayúscula y minúscula, búsqueda contextual (hacia atrás/delante), uso de sentencias condicionales, etc. Se trata de conceptos bastante avanzados para los que en la mayoría de casos se requieren ciertas nociones de programación (para no perderse con las analogías, las referencias a lenguajes de programación, etc.). Por ello, y porque además me veo incapacitado para explicarlo todo con la seguridad y rigor necesarios (porque algunos conceptos no los tengo 100% manejados y cometo fallos), para los que queráis seguir avanzando con las expresiones regulares me gustaría recomendaros tres títulos: Mastering RegExp (O’Relly), Regular Expressions Cookbook (O’Relly) y Teach Yourself Regular Expressions In 10 Minutes (Ben Forta). Son parte del material bibliográfico con el que he ido aprendido y mejorando mi uso de las expresiones regulares. Por otra parte, también hay mucho material en la red.

Con esta última nota bibliográfica llegamos al fin (al menos de momento) de la serie de artículos sobre expresiones regulares. Espero que os hayan resultado útiles y a que muchos os hayan animado a comenzar a utilizarlas. En serio, cuando uno se acostumbra a emplearlas a diario, acabo mejorando como profesional. Asimismo, con este post, llegamos también al fin del año 2012. Espero que a todos el 2013 os depare lo mejor.

Nos leemos en la blogosfera. ¡Feliz año nuevo!

Atentamente,

Álvaro

Recomendación musical: para terminar el año musical, un tema(zo) del disco del último mes que más me ha sorprendido (sobre todo por la juventud de su autor): Two Fingers de Jake Bugg.

Expresiones regulares y traducción (parte II)

Hola y saludos otoñales (casi invernales) a todos (los del hemisferio norte, en el sur, al revés):

En el anterior post de esta serie sobre expresiones regulares vimos la introducción general y el uso de los operadores básicos (caracteres literales, punto, corchetes, guión y acento circunflejo).

En esta segunda parte de la serie vamos a centrarnos en los caracteres con un significado especial más allá del propio literal: los metacaracateres. Los metacaracteres sirven para identificar o encontrar patrones de texto o formato que, de otra manera, resultaría bien imposible, bien muy complejo. En una implementación general de la sintaxis de las expresiones regulares nos encontramos con la siguiente selección de metacaracteres habituales, que presento en un cuadro para que pueda usarse como referencia rápida.

Metacaracteres de búsqueda

– \ (barra invertida): la barra invertida sirve para anular (o “escapar” en términos informáticos) un metacaracter de forma que se utilice como un carácter literal. Por ejemplo, si hacemos una búsqueda por \\n (como veremos a continuación, \n es un metacaracter para un salto de línea manual) estaremos indicando que en lugar de buscar un salto de línea se busque el carácter de barra invertida seguido del carácter n (práctica habitual en programación para suprimir, por ejemplo, los saltos de línea y cambiarlos a otra cosa). – \f (barra invertida y f): sirve para identificar o buscar los caracteres de salto de página en formato electrónico (se trata de un carácter que manda la instrucción a la impresora). – \n (barra invertida y n): sirve para encontrar un carácter de salto de línea en un documento (de hecho, \n es la forma de insertar una línea nueva en muchos lenguajes de programación como C o C++). – \r (barra invertida y r): sirve para encontrar un carácter de retorno de carro (cuando se pulsa la tecla Intro para pasar la siguiente línea, como cuando se empujaba la palanca de cambio de línea en una máquina de escribir antigua). – \t (barra invertida y t): sirve para encontrar un carácter de tabulación horizontal (el que se inserta al pulsar la tecla Tab del teclado). – \v (barra invertida y v): sirve para encontrar un carácter de tabulación vertical (en ASCII tiene asignado el 11). – [\b] (corchete apertura, barra invertida, b y corchete de cierre): permite identificar un carácter de retroceso en un texto. – \d (barra invertida y d): se trata de uno de los metacaracteres más útiles y usados. Permite buscar cualquier dígito, es decir, es lo mismo que escribir [0-9] para usar un intervalo, tal y como vimos en el post anterior. Por ejemplo, al buscar \d euros en un editor compatible con regexp clásicas (por ejemplo, EditPad Lite), encontraríamos en un texto tanto 5 euros como 7 euros. – \D (barra invertida y D mayúscula): sirve para justamente lo contrario a lo anterior, es decir, para buscar todo lo que no sean dígitos. Se trata por tanto, del equivalente a [^0-9]. – \w (barra invertida y w): otro de los metacaracteres más utilizados ya que permite localizar cualquier carácter alfanumérico (en mayúscula o minúscula) y el guión bajo. Por tanto, es igual al patrón [a-zA-Z0-9_]. Por ejemplo, con la búsqueda [Cc][Rr]\w encontraríamos tanto CR7 como crocs. – \W (barra invertida y W mayúscula): sirve para lo contrario a lo anterior, es decir, encontrar un carácter no alfanumérico ni un guión bajo; sería el equivalente a [^a-zA-Z0-9_]. Se puede utilizar para buscar caracteres de formato (párrafo, saltos, etc.) u otros como #. – \s (barra invertida y s): sirve para encontrar cualquier tipo de carácter de espacio en blanco. Es por tanto equivalente a [\f\n\r\t\v]. Por ejemplo, al buscar por \s en el texto Uno y dos, el texto que se identificaría serían los espacios en blanco (Unoydos). – \S (barra invertida y S mayúscula) lo contrario a lo anterior, es decir, lo mismo que [^\f\n\r\t\v]. Nos permite encontrar un carácter del tipo de todo lo que es «visible» al ojo humano en un texto. – \b (barra invertida y b): este metacaracter es muy útil porque sirve para marcar una posición de un carácter dentro de una palabra. Habitualmente se usa para buscar caracteres al principio. Por ejemplo: al buscar por \barm se encontrarían las palabras armadura y arma, pero no harmónica puesto que el patrón de búsqueda arm no está al principio de palabra en el último caso. Aunque se usa especialmente para marcar el inicio de una palabra, \b también sirve para marcar el final; por ejemplo, la búsqueda ato\b serviría para encontrar pazguato, pero no atornillar. Por último, si se combina el uso para inicio y final de palabra, lo que obtenemos es el equivalente a la búsqueda de palabra completa; por ejemplo, \bagua\b encontrará agua pero no aguantar. Por su uso, este es un metacaracter marcador de posición dentro de una palabra. – \B (barra invertida y B mayúscula): sirve para no encontrar un carácter en los límites de una palabra. Se usa, por ejemplo, para localizar guiones de separación en palabras en inglés (no hay espacios a los lados) con regexp como \B-\B, con las que se obtendrían resultados como task–related. – ^ (acento circunflejo): fuera de un corchete, el acento circunflejo sirve para marcar el inicio de una cadena completa. Ojo, hemos dicho cadena, no palabra. En términos habituales, esto significaría comienzo de una frase en una nueva línea. Por ejemplo, ^\w nos serviría para localizar el primer carácter alfanumérico de una frase o cadena. En algunas implementaciones se suele ver \A en lugar de ^. – $ (símbolo del dólar): sirve para lo mismo que el metacaracter anterior, solo que en este caso se encuentra el final de una cadena. Por ejemplo, :$  nos permitiría encontrar todas las cadenas que terminen en dos puntos. En algunas implementaciones se suele ver \Z en lugar de $.

Como podemos intuir, la combinación de estos metacaracteres con los patrones de búsquedas tratados en el primer artículo de esta serie sobre expresiones regulares multiplica las prestaciones de las que disponemos. A modo de ejemplo práctico en el mundo de la traducción, podemos ver la combinación de caracteres literales y comodines (metacaracteres) en la creación de reglas de control de calidad o QA en la mayoría de las herramientas CAT del mercado. Habitualmente, las funciones de QA operan de la siguiente manera:

1) Se busca la aparición (o ausencia) de un patrón determinado en el texto de origen y

2) Se compara el resultado del primer paso para verificar la existencia (o no existencia) de dicho patrón en el texto de destino.

En concreto y para verlo con más claridad, vamos a definir una regla que busque los números con punto como separador de decimales en el texto de origen y que en el texto de origen NO tengan como separador de decimales una coma.

a) Expresión regular para el texto de origen: \d\.\d.

– Explicación: expresión formada por cualquier número (\d), punto (como punto es un metacaracter por sí mismo, lo escapamos con la barra invertida) y de nuevo cualquier número.

– Resultado: se encontraría, por ejemplo, 10.1, 512,684.58, 4.6.

b) Expresión regular para el texto de destino: [^\d,\d].

– Explicación: expresión formada por cualquier número (\d), coma y de nuevo cualquier número.

– Resultado: se encontraría, por ejemplo, 10,1, 512.684,58, 4,6.

Como se observa, en realidad lo que se hace es decirle al programa mediante una expresión regular lo siguiente “si en un segmento de origen encuentras un número, un punto y otro número y en el segmento de destino correspondiente hay un número separado de otro por algo que no sea una coma, genera un error de QA para que lo compruebe». En concreto, en este caso vemos como en el número 512.684,58 se habría producido un falso positivo (¡el tema de los falsos positivos daría para otro post!), puesto que aquí el punto separa las unidades de millar, no los decimales. En el resto de casos, no habría habido ningún problema.

Expresión regular para función de QA en SDLX

Esta última explicación y ejemplo es uno de los casos más habituales de uso de las expresiones regulares. No obstante, existen muchos más escenarios como, entre otros, el filtrado de cadenas en el editor de traducción, la extracción de cadenas en la ingeniería de traducción con patrones complejos, etc. La verdad es que una vez se dominan bien todos los operadores básicos, cada cual es capaz de idear aplicaciones de lo más variopintas en su trabajo y su día a día.

En este segundo artículo de la serie sobre regexp hemos tratado los metacaracteres como complementos indispensables para los operadores de regexp básicos a fin de buscar y encontrar patrones textuales más sofisticados. Pero, ¿no sirven todos estos metacaracteres vistos para localizar caracteres individuales? En el ejemplo [^\d,\d], ¿no se resaltaban con la búsqueda únicamente el número anterior (\d) y posterior al separador de decimales (,\d)? ¿Qué pasa si queremos buscar más números o caracteres y combinar en una búsqueda patrones más grandes en que se repitan caracteres, espacios en blanco, etc.?

Obviamente, todo eso se pensó al diseñar las expresiones regulares, así que nosotros lo veremos en el siguiente post de esta serie, donde trataremos la búsqueda y creación de repeticiones de caracteres y búsquedas, los cuantificadores, las subexpresiones y muchas más cosas con las que podremos aprovechar toda la potencia que nos brindan las regexp.

Mientras tanto, como en el caso anterior, a practicar con lo ya aprendido, ¿de acuerdo?

Nos leemos en más o menos un mes. Ah, y como siempre, perdonad que me enrolle tanto y termine por escribir post larguísimos. Un saludo a todos,

Álvaro

Recomendación musical: tras casi dos años de espera si no me equivoco, mis apreciados Stereophonics vuelven a la carga con nuevo material y sello discográfico propio. Aquí va el single titulado In A Moment.

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.

Aplicación de formato en SDL Trados Studio

Saludos a todos. Espero que hayáis pasado todos un verano (en el hemisferio norte, para los de otras latitudes más meridionales, no os quitéis el abrigo) estupendo.

Hace ya bastantes meses, hubo una lectora de (Nunca) Sobran las palabras que me planteó una serie de dificultades que le surgían a la hora de aplicar los diferentes tipo de formato de un texto (negrita, cursiva, superíndice, etc.) en una traducción cuyos segmentos presentaban un grado de complejidad relativamente elevado precisamente en términos de etiquetas y marcas de formato. Pasado un tiempo, al impartir un curso, me di cuenta de que, de nuevo, la aplicación del formato en el texto de destino representaba un problema para los usuarios no avanzados, que tendían a obviarlo (con los problemas que ello conlleva), o bien, a aplicar únicamente negritas, cursivas y subrayados, dejando de lado el resto de etiquetas que marcaban el cambio de fuente, etc.

A fin de aclarar un poco la situación para unos y otros, así como refrescar un poco las ideas de los usuarios habituales de SDL Trados Studio, he grabado un breve video sobre las tres formas principales de aplicar formato en esta herramienta. Son las siguientes:

1. Aplicación tipo formating painting de SDL-X o comando Copiar formato de MS Word: se trata de una función parecida a la clásica de SDL-X, que te permite replicar el formato del texto de origen en el destino utilizando el ratón para calcar el formato.

2. Utilización del método abreviado Ctrl+, (coma): al pulsar esta combinación de teclas se abre una lista con todos los posibles formatos que podemos aplicar a cualquier parte del texto de destino.

3. Utilización de la función QuickPlace: se trata de prácticamente lo mismo que el método anterior, pero con la diferencia de que QuickPlace es un panel que se queda abierto y varía dinámicamente en función del segmento activo.

En el VÍDEO podéis ver un ejemplo de aplicación, así como la solución por la que muchos traductores optamos cuando hay muchas marcas de formato y etiquetas en un texto: copiar el texto de origen tal cual y sobrescribirlo con la traducción, respetando la posición de los indicadores de formato y las etiquetas de apertura y cierre.

Bueno, como en el verano del sur de España el calor se nota bastante, creo que con este artículo más ligero que en otros casos, pero mucho más refrescante y práctico en que otras ocasiones nos podemos dar por satisfechos, ¿no?

Espero que a todos los que tengáis dificultades o no conocieseis todas las alternativas para aplicar el formato, estas breves notas y el vídeo complementario os resulten útiles.

Sin más, un caluroso saludo.

Atentamente,

Álvaro

Recomendación musical: “Runaways”, single de lo nuevo de The Killers, que saldrá en otoño. No llega al nivel de Hot Fuss, pero se puede escuchar, que no es poco en estos tiempos.

Cambio de variedad lingüística (locale) y dirección de una TM

Saludos a todos, estimad@s lector@s:

Os cuento. En las últimas semanas he estado ejerciendo como formador y asesor de procesos y herramientas de traducción asistida por ordenador (TAO, o CAT por las siglas en inglés) para una empresa de traducción. Cuando hemos visto la gestión de memorias de traducción (TM por las siglas en inglés), me han planteado dudas sobre cómo cambiar la combinación de idiomas, usar las TM en ambas direcciones, etc.
Esta serie de preguntas enlazan con otras consultas privadas que he recibido a través de este blog-consultorio, en las que se me planteaban problemas similares. Bueno, pues atajemos los dos problemas principales a los que he respondido en esta materia: cómo cambiar la variedad de un idioma (locale o language flavour en el mundillo de la localización [L10N]) y cómo invertir la combinación lingüística de una TM (para pasar, por ejemplo, la combinación inglés-español a español-inglés).

Para mostrar cómo solucionar estas dos cuestiones concretas he grabado un par de vídeos en los que utilizo, por una parte, memorias en formato .tmx (por ser interoperables en varias plataformas) y, por otra, Wordfast Classic (versión 6) como herramienta de trabajo para la inversión lingüística, al tratarse de una herramienta que puede descargarse gratuitamente (además, dos de las personas que me plantearon la duda sobre el cambio de locale trabajaban con Wordfast). No obstante, tras los comentarios recibidos, el uso de Olifant también se presenta como una alternativa muy interesante (esta última frase se ha añadido para mejorar el post con el feedback de los lectores).

Cambio de locales en una TM

En L10N, el concepto de locale tiende (recalco lo de tiende, puesto que en realidad engloba muchas más cosas) a identificarse automáticamente con la variedad específica de un idioma. Por ejemplo, en el caso del inglés, este se divide en diferentes locales específicos identificados con códigos informáticos como ‘en-gb’ para inglés de Reino Unido, ‘en-us’ para inglés de EE. UU., ‘en-au’ para inglés de Australia, etc. La cuestión radica en que en ocasiones y por diferentes motivos se necesita cambiar una TM para que los locales se adapten al de un archivo que hemos recibido para traducir. En el ejemplo que se muestra en el vídeo hay que pasar una memoria en .tmx de inglés de EE. UU. y español de España a inglés de Reino Unido y español de México.
En el mercado hay muchas herramientas de TAO que te permiten elegir el locale concreto al importar desde formatos como .tmx (en este sentido el asistente de TM de Déjà Vu X2 es realmente práctico y el módulo de gestión de TM de SDL Trados Studio ofrece gran flexibilidad al importar memorias en .tmx). No obstante, al hacer los cambios manualmente con un editor de texto plano aprendemos un procedimiento que podemos emplear con independencia de la plataforma que usemos (algo realmente práctico cuando trabajas gestionando proyectos de diversa índole).
Bueno, aquí va el vídeo del tutorial sobre el cambio de locales en una TM en .tmx:

Inversión de los idiomas de una TM

En ocasiones, y especialmente cuando se trabaja, por ejemplo, en una oficina en la que se traduce con una combinación lingüística en ambas direcciones (traducción directa e inversa de inglés y español, por ejemplo) resulta interesante utilizar como referencia una misma TM y adaptar su sentido (directo o inverso) en función de las necesidades. Me ha parecido sorprendente que, tras echar un vistazo a varias plataformas de TAO potentes, no he encontrado nada tan práctico y rápido como la solución que puede ofrecer Wordfast: abres una TM en .tmx, pulsas en un par de botones para invertir el sentido de la combinación lingüística y, a continuación, exportas la nueva TM. Todo en menos de un minuto. En el resto de herramientas habitualmente hay que seleccionar muchos más parámetros, hacer ajustes, etc. Total, que acabas perdiendo bastante tiempo para algo que debería ser cuestión de minutos.
En el ejemplo que se muestra en el vídeo a continuación se utiliza la TM en .tmx con los nuevos locales creada en el apartado anterior para invertir el sentido de inglés de Reino Unido a español de México a español de México a inglés de Reino Unido.
Aquí va el vídeo:

Bueno, espero que os resulten prácticos este par de procedimientos rápidos y gratuitos, sobre todo a aquellos que no sólo traducís y gestionáis sino que además hacéis de ingenieros lingüísticos sobre la marcha.
Un saludo,

Álvaro

Recomendación musical: Kelly Jones de Stereophonics con el padrino del mod Paul Weller y Ronnie Wood de los Rolling Stones que se juntan para homenajear a los Beatles con Don’t let me down.

Silencio, se rueda: introducción básica a la subtitulación

Hace unos días, a través de mi correo electrónico-barra-consultorio (ojo, lo digo sin acritud, es un placer recibir consultas), se pusieron en contacto conmigo un par de personas para preguntarme acerca del subtitulado. Aunque no soy un experto consagrado en la materia, sí es cierto que siempre me ha llamado la atención y me ha gustado. Además, he recibido formación y subtitulado tanto profesionalmente como por puro ocio en mi tiempo libre (ahora con tantas series y cortos sueltos en la Red, de vez en cuando todo el mundo hace sus pruebas).

El asunto es que estas personas pidieron consejo sobre cómo empezar, tanto desde el punto de vista de pautas operativas básicas de subtitulado como en materia de herramientas de software para subtitular. Finalmente, he decidido dar la respuesta en voz alta a través del blog. En esta entrada incluyo también unas notas bibliográficas por si alguien quiere echar un vistazo, aunque algunas de las pautas que apunto las recuerdo de mis primeros encuentros con el subtitulado allá en el año 2003 en Londres.

En cuanto al software, me pareció que como la cuestión era iniciarse, lo mejor era recurrir a un programa gratuito que ofrezca funciones básicas de subtitulado, de ahí que recomiende Subtitle Workshop en lugar de herramientas profesionales como WinCAPS. En Internet existe gran cantidad de documentación sobre Subtitle Workshop (además de la propia ayuda del programa), pero, en pocas palabras, se trata de una aplicación que te permite cargar un vídeo y hacer manualmente el spotting insertando los subtítulos con teclas de método abreviado para, finalmente, introducir el texto en cada subtítulo. De forma predeterminada Subtitle Workshop no ofrece un sistema de comprobación de caracteres por línea ni duración de los subtítulos en pantalla parecido al de los sistemas de pago, pero me parece que para empezar es una herramienta adecuada, porque los procesos principales se asimilan con mucha facilidad. No obstante, como se puede observar en los comentarios de esta entrada, otros profesionales como David Diéguez recomiendan usar otras herramientas como, por ejemplo, VisualSubSync Mod.

Por cuanto respecta a las pautas de subtitulado, como he dicho arriba no soy un erudito en la materia, así que, además de a mi propia experiencia y conocimientos, he recurrido a las referencias disponibles al final para hacer una recopilación de 10 indicaciones o consejos acerca del subtitulado que los principiantes pueden tener en cuenta como punto de partida. Por otra parte, os invito a leer alguna de las miles de obras de referencia disponibles en el mercado. Cualquiera de las publicaciones específicas de Jorge Díaz Cintas al respecto sería una buena opción. Hechas estas aclaraciones, aquí va la respuesta en voz alta a la consulta sobre las pautas básicas de subtitulado:

1 El subtitulador es el encargo de la segmentación (spotting) y la traducción de los subtítulos, que deben reflejar el ritmo de la película. La entrada y salida de subtítulos debe sincronizarse, en medida de lo posible, con la propia voz. No obstante, el subtítulo debe aparecer 0,25 segundos después de escucharse la voz en pantalla. Entre subtítulo y subtítulo, debe haber al menos cuatro fotogramas de separación para que se perciba el cambio. Finalmente, los subtítulos no deben permanecer en pantalla más de 2 segundos tras finalizar la voz.

2 Los subtítulos deben reflejar toda la información escrita en las imágenes (avisos, carteles, etc.) que puedan aportar matices al significado global transmitido por el conjunto de imagen y diálogo. Asimismo, en los propios subtítulos debe tratar de plasmarse la información cultural que resulte relevante para la compresión del mensaje transmitido en el film.

3 Los subtítulos deben coincidir con los cambios de plano o escena, así como los cambios temáticos significativos en pantalla. Las voces en off (personajes que no se ven en pantalla) también se subtitulan y, para diferenciarlas, deben marcarse con el formato de texto en cursiva.

3 Deben utilizarse estructuras sintácticas sencillas, y los subtítulos deben conformar estructuras gramaticales completas. En un subtítulo, no se deben separar las palabras, se debe tratar de separar las líneas del subtítulo coincidiendo con comas y puntos, o bien, por las conjunciones. El final de un subtítulo debe marcarse con punto.

4 Un subtítulo completo de dos líneas con entre 14 y 16 palabras no puede permanecer en pantalla más de 6 segundos. En el caso de los subtítulos completos de una línea con entre 7 y 8 palabras pueden y deben permanecer un máximo de 3,5 segundos. En el caso de los subtítulos de una sola palabra, deben permanecer en pantalla un mínimo de 1,5 segundos.

5 El máximo de líneas por subtítulo es 2. El número de caracteres por línea no debería superar los 35. En cuanto a color y fuente del texto, se recomiendan fuentes Serifs como Arial en un color blanco hueso (que no sea #fff). La alineación del texto será centrada, salvo en los diálogos, en los que el texto (incluido el guión de apertura) se alineará a la izquierda.

6 Es mejor un subtítulo con dos líneas cortas de tamaño proporcional que uno con una línea larga. En caso de usar dos líneas no proporcionales, la superior debe ser más corta que la inferior. Cuando hay un diálogo entre personajes, cada línea corresponde a un personaje y además, éstas comenzarán con un guión y un espacio para marcar el inicio del diálogo.

7 Salvo en circunstancias extraordinarias, el bloque de subtítulos debe colocarse centrado en la parte inferior de la pantalla, con una separación de 1/12 del tamaño total de la pantalla con respecto a la parte inferior

8 Debe evitarse la repetición de nombres y elementos comunes que puedan interpretarse sin que deban ser siempre subtitulados. Cuando sea posible, para ahorrar espacio, deben usar siglas y acrónimos, así que los pronombres siempre que sea posible.

9 En el caso de subtítulos correspondientes a monólogos largos, la continuación del subtítulo se marca con tres puntos suspensivos al final del mismo y tres puntos suspensivos al comienzo del siguiente. En este punto, hay subtituladores que sostienen que la ausencia de punto ya marca que el texto sigue, por lo que no consideran necesario invertir los caracteres en puntos suspensivos.

10 Literalidad en palabras fácilmente reconocibles. En el caso de nombres propios como puntos geográficos o nombres de personas e incluso en el caso de palabras extremadamente similares en la lengua de partida y llegada, se recomienda encarecidamente subtitular de forma literal, puesto que al reconocerse la forma, el espectador espera una determinada traducción que, de no encontrarse, resulta en una sensación de error.

Bueno, como ya he dicho, esta recopilación cubre nociones muy básicas y el subtitulado tiene mucho más intríngulis. La formación, la consulta y la práctica (me temo que en ese orden) hacen al maestro, así que si os animo a todos los que no hayáis hecho nunca subtitulado a probar y, a los que tenéis experiencia, a compartir con el resto todo lo que consideréis imprescindible que se me haya escapado.

Un saludo a todos.

Atentamente,

Álvaro

– Recomendación musical: The Wombats, Moving to New York. De los temas que te animan para arrancar el día.

Referencias bibliográficas

– Díaz Cintas J, Teoría y práctica de la subtitulación: inglés / español, Barcelona, Ariel, 2003.

– Karamitroglou Fotios, A Proposed Set of Subtitling Standards in Europe (1998). Available at: http://translationjournal.net/journal/04stndrd.htm

– CESyA, Buenas Prácticas. Available at: http://www.cesya.es/es/normativa/buenas_practicas
– ESIST European Association for Studies in Screen Translation, Code of Good Subtitling Practice (1998). Available at: http://www.esist.org/ESIST%20Subtitling%20code_files/Code%20of%20Good%20Subtitling%20Practice_en.pdf