La verdad está ahí fuera

¿Recordáis esta mítica frase de la serie Expediente-X (X-Files)? Pues la verdad es que la semana pasada, tras revisar traducciones de mis alumnos del curso de localización de Imperial College y también otros tantos textos como parte de mi trabajo como revisor en SDL Spain, me acordé de ella. ¿El motivo? Ahora mismo me explico, para que de esta forma entendáis el motivo de la actual reflexión.La verdad está ahí fuera

En multitud de ocasiones, los traductores tenemos que traducir documentación, manuales de usuario y guías de uso o referencia rápida de muchos tipos de productos diferentes. Supongo que no será una novedad para ninguno de vosotros el comentar nada acerca de traducciones de material de referencia para productos que van desde dispositivos de TI como, por ejemplo, routers, puertas de enlace o impresoras, a maquina pesada como, por ejemplo, fresadoras o grúas, pasando por los clásicos manuales de taller para coches o motos. Es en realidad parte del pan nuestro de cada día.

El quid de la cuestión es que a menudo, parece que hay veces que la necesidad de traducir rápidamente y producir el máximo posible cada hora, nos hace comportarnos de forma acrítica, en el modo de piloto automático, cual máquina de escribir de bilingüe. A medida que revisaba (en este caso, se trataba de una traducción de un manual del usuario para un programa de software libre que utilizamos en el curso de Imperial), me daba cuenta que de los algunos de los traductores habían comenzado a traducir y que, a pesar de que se habían documentado bien en materia terminológica, no se habían molestado en dedicar unos minutos a pensar en lo que realmente estaban describiendo con sus traducciones. Fue entonces cuando caí en la frase de “la verdad está ahí fuera”. En la mayoría de los casos, invertir cierto tiempo en ir más allá de las palabras de un texto y acercarnos o asomarnos a la realidad de los productos, aplicaciones o herramientas sobre las que traducimos como parte del proceso de documentación es la única forma que nos permite estar realmente capacitados para traducir adecuadamente, con conocimiento de causa. De lo contrario, si terminamos por centrarnos únicamente en las palabras incluidas en la factura del pedido de traducción, existe el peligro de que acabemos poder intimar tanto con el texto que, como una relación platónica, acabemos por idealizarlo, viéndolo conforme a nuestros propios deseos, de forma que podemos terminar amoldándolo innecesaria y erróneamente conforme a nuestras necesidades. Desde mi punto de vista, la mejor medicina para luchar contra esta deformación de traductor en continua carrera contrarreloj es interrumpir de vez en cuando el propio proceso, respirar, acercarnos a la realidad del producto sobre el que traduzcamos y comprobar que realmente lo traducido obedece a la lógica y la realidad del propio producto, y no a nuestros deseos o imaginaciones acerca de la herramienta, dispositivo o aplicación debería hacer.

En el caso concreto de la guía para el programa de software libre que he comentado, la mayoría de los fallos que me llevaron a esta reflexión estaban relacionados con el hecho de que los traductores habían ido poco a poco desarrollando cada uno su propia versión de la aplicación de software a partir de interpretaciones de los puntos más complejos de la documentación, en los que la calidad lingüística del texto de origen dejaba además bastante que desear. Si se hubiesen tomado la molestia de documentarse, preguntar sobre la aplicación para haberla interiorizado, se habrían ahorrado grandes dosis de subjetivismo en partes de la guía donde no había lugar para tantas interpretaciones.

Esta situación que comento se ve incluso con más claridad en el caso de la traducción audiovisual, de videojuegos o de adaptación de scripts. En estos casos, es absolutamente necesario despegarse un poco de la relación puramente textual y asomarse a la realidad y al contexto de los encargos en cuestión para no perder de vista la finalidad y el entorno en que los textos cobrarán vida. De no hacerlo así, al final el resultado de nuestro trabajo terminará pareciéndose más a una mala película de ciencia ficción que al fiel relato histórico* que habitualmente se nos exige en nuestro trabajo.

Bueno, eso es todo, espero que esta reflexión nos ayude a estar en alerta para la próxima. No lo olvidéis, la verdad está fuera esperando, debemos aprovecharnos de ello para ofrecer siempre un trabajo de máxima calidad (y hacer así más fácil y rápida la labor de los revisores).

Un saludo a todos,

Álvaro

Anuncios

Introducción a SDL Trados Studio 2009: pasos básicos para traducir textos

Hola a todos:

Como de costumbre tengo que pedir disculpas por la inactividad. De nuevo, mucho trabajo (y variado), una mudanza, la llegada del verano, etc. La verdad es que no tengo excusa, debería intentar escribir más, pero el tiempo no estira.

A través de esta entrada del blog, tengo la intención de ofrecer un breve tutorial de iniciación a la traducción en SDL Trados Studio 2009. A lo largo de los últimos meses he comprobado que muchos profesionales del sector han adquirido el paquete de software, pero no se lanzan a utilizar la herramienta por inseguridades o miedo a que su productividad o rendimiento diario se vea afectado, o sencillamente por desconocimiento de la misma.

Bueno, como es normal, la curva de aprendizaje al principio siempre es más pronunciada pero, una vez superadas las primeras dificultades, os puedo asegurar que esta herramienta proporciona muchas ventajas, a pesar de que todavía tiene que mejorar en muchos aspectos (por ejemplo, en breve se incorporará el corrector gramatical tipo SDL-X para español).

En el siguiente vídeo de introducción y pasos básicos de traducción en SDL Trados Studio 2009 presento la forma más sencilla de traducir un documento una vez se ha recibido el material habitual para la traducción: el texto a traducir y el material de referencia (sólo TM en este caso). Como ya he dicho, se trata de los pasos fundamentales; se podrían configurar muchas más cositas, que espero ir cubriendo poco a poco, pero, para empezar sólo vamos a ver cómo abrir el documento, traducirlo con una TM y guardar el texto traducido en el formato original. No obstante, si alguien quiere hacer preguntas, estoy abierto a sugerencias para ir grabando vídeos sobre este software que en teoría está destinado a sustituir a Trados y SDL-X, haciéndose de esa forma con la mayor cuota de mercado en el ámbito de las herramientas de traducción asistida.

No me enrollo más, para ver el vídeo sólo hay que hacer clic en la siguiente imagen (recomiendo utilizar Internet Explorer, porque parece que en Firefox hay problemas para ver el vídeo):

 

Introducción a Studio

 

Espero que os resulte útil y os anime a comenzar a utilizar la herramienta.

Un saludo,

Álvaro

Recomendación musical: Given to Fly, de Perl Jam. Los clásicos nunca mueren.

Exportar cadenas de Passolo para crear glosarios de opciones de software

Hola a todos y disculpas por la falta de actividad reciente:

Bueno, en esta ocasión os presento una solución para crear una referencia terminológica con las opciones de software de un proyecto de localización en que las cadenas de software se traducen en Passolo y la documentación se traduce con otra herramienta como, por ejemplo, Trados, SDL-X, Déjà Vu o Multitrans (situación muy común, por otra parte). En realidad, escribo esta entrada en el blog porque no hace mucho se me presentó un escenario muy parecido (un compañero de trabajo me comentó el problema y esta fue mi solución), así que he pensado que puede que haya otras personas que se enfrenten a un problema similar y a las que esta solución les vendría bien.

Pongámonos un poco en situación real: nos llega un encargo de software de 5.000 palabras que debemos traducir en Passolo y, por otra parte, la documentación correspondiente al software, cuyo recuento es de 17.000 palabras. La fecha de entrega es ajustada (¡qué raro!) y hay que repartir el trabajo de la documentación entre tres traductores que no tienen ni manejan Passolo. ¿Qué hacemos? Pues lo más sencillo, desde mi punto de vista, es proporcionarles las cadenas de software traducidas en un formato que puedan consultar como, por ejemplo, una hoja .xls de Excel, un archivo bilingüe dividido en columnas en MS Word o en .html o, aún mejor, ofrecerles un glosario o una memoria de traducción que contenga exclusivamente las opciones de software traducidas en Passolo. De esta forma, se garantiza que los tres traductores pueden utilizar las opciones de software correctas para traducir la documentación en la herramienta que deseen.

Y, ¿cómo conseguimos generar la referencia terminológica en los tipos de archivo mencionados anteriormente desde Passolo?

En primer lugar, lo que tenemos que hacer es asegurarnos de que todo el software está traducido en Passolo (en los ejemplos que ofrezco a continuación no lo está, puesto que en la barra de progreso no marca 100%, sino una cifra inferior, pero para ilustrar el proceso nos vale de todas formas).

En segundo lugar, seguimos la ruta (en el menú principal) String List > Report y, en el cuadro de diálogo que aparece, seleccionamos String List (en la lista desplegable) y pulsamos el botón Start. Finalmente sólo tendremos que guardar el archivo generado.

Para que quede más claro, aquí os paso un vídeo de 1 minuto de duración sobre cómo exportar las cadenas de software de Passolo a una tabla en HTML (de ahí luego se podría corta-pegar a cualquier parte). Enlace al vídeo (haz clic en la imagen):

Exportar de Passolo a HTML

Exportar de Passolo a HTML

No obstante, para mí resulta mucho más cómodo utilizar el procedimiento que se muestra este otro vídeo y que nos permite exportar a XML, para posteriormente importar ese XML con todos los datos a Excel. Enlace al vídeo (haz clic en la imagen):

Exportar de Passolo a Excel via XML

Exportar de Passolo a Excel via XML

Supongo que a la mayoría este tipo de archivos de referencia en Excel os resultará muy familiar. De hecho, es la opción que en numerosas ocasiones escogen los ingenieros porque, de ser necesario, pueden utilizar una hoja con las traducciones para revertir el proceso (es decir, se sobrescribe el XML original con el Excel y se carga el código traducido).

Eso es todo. Espero que os resulte útil. Si alguien tiene dudas o alguna sugerencia, que me escriba.

Un saludo,

Álvaro

Recomendación musical: un grupo español que conocí hace poco, L.A.; la canción en cuestión, Crystal Clear.

Reflexiones acerca del testing

A lo largo del último mes, he dedicado casi el 95% de mis horas de trabajo a realizar testings de diversas aplicaciones de una importantísima empresa de desarrollo de aplicaciones de software de diseño. Por ello, me ha parecido que comentar una serie de aspectos era una buena excusa para volver a retomar el blog.

En primer lugar, definamos qué es el testing dentro del proceso de localización. El testing es la última etapa del control de calidad de la localización de software y consiste en llevar a cabo una serie de procedimientos que permiten verificar y garantizar la calidad, operabilidad, usabilidad y adecuación del producto final para su lanzamiento a los distintos mercados. A efectos prácticos, en la mayoría de los casos podemos distinguir tres tipos distintos (y complementarios) de testing: el funcional, el estético y el lingüístico (en realidad existe una gran variabilidad en este sentido, y cada cual acaba por nombrar y organizar cada tipo o fase como le parece).

En segundo, lugar, y en todos los tipos, el testing se realiza en dos fases:

1)      Análisis (testing propiamente dicho): primera fase, en la que se trata de examinar a fondo la aplicación informática en cuestión, ya sea mediante la ayuda de una serie de pasos o casos (test cases) elaborados por los desarrolladores para verificar todas las cadenas[1], o bien de forma libre (ad-hoc), de manera que el tester (persona encargada de realizar el testing) tiene potestad para moverse por toda la aplicación en busca de errores o defectos. A medida que se detectan errores (que suelen denominarse bugs, haciendo uso del término informático para fallos en la programación de una aplicación), el tester debe informar de ellos. Esto se hace habitualmente a través de un programa o sistema de registro y seguimiento de bugs (como por ejemplo, Bugzilla), en el que se introduce toda la información correspondiente (si el bug es funcional, lingüístico o estético, qué pasos hay que llevar a cabo para generar o acceder a él, instrucciones sobre cómo arreglarlo, gravedad, captura de pantalla de referencia para visualizarlo, etc.).

2)      Regresión: en esta segunda fase, el tester debe asegurarse de que todos los errores de los que se ha informado se han corregido. Para ello, los ingenieros informáticos le proporcionan sucesivas versiones actualizadas del software (denominadas builds en términos informáticos) y el tester sigue los pasos especificados en el sistema de registro y seguimiento de bugs para garantizar que todo está solucionado antes de publicar la versión final de la aplicación.

Aunque el proceso puede parecer sencillo, es muy importante realizar todo con el mayor nivel de detalle posible, proporcionando las instrucciones de forma clara y concisa a fin de garantizar que el flujo de comunicación con los ingenieros es el adecuado. Ha de tenerse en cuenta que, en circunstancias normales, el testing de una aplicación se realiza a escala internacional, por lo que muchos idiomas participan en él, de forma que si no se aplica el mayor rigor a todo el proceso, puede acabar por convertirse en una masa de trabajo verdaderamente inmanejable.

Hechas estas aclaraciones, me gustaría comentar que en el caso de los localizadores, las tareas que se nos asignan suelen ser aquellas correspondientes a los tipos de testing lingüístico y estético (no obstante, si se detectan bugs funcionales que incidan sobre la funcionalidad o usabilidad del software, se debe informar de ello), aunque en función de los conocimientos de programación y de la propia aplicación también se pueden recibir encargos de carácter funcional. Esto significa que, en la mayoría de los casos, el responsable del testing lingüístico debería tener en cuenta los siguientes puntos:

  • El objetivo primordial es el de asegurarse que desde la perspectiva lingüística el software queda lo más correcto posible (sin fallos orto-tipográficos ni gramaticales). En este aspecto es importante comprobar que la aplicación está bien traducida en cuanto a la concordancia de número y género en listas desplegables, botones de radio, texto generado dinámicamente, gestión de variables, mensajes de la barra de estado, etc. Por ejemplo, debemos tratar de evitar que aparezcan mensajes del tipo “1 mensajes recibidos” (para ello se suele utilizar el clásico truco de los dos puntos, es decir, traducir como “Mensajes recibidos: 1”) o que en una lista desplegable correspondiente a la opción Estado, lo opción None se traduzca como Ninguno (es probable que durante el proceso de traducción no hubiese suficiente información contextual para decidir qué género escoger). Al principio he comentado que el software debe quedar lo más correcto posible porque en muchos casos la solución óptima requeriría que se rediseñase el código fuente de la aplicación y, en la mayoría de los casos, los ingenieros son muy reacios a ese tipo de cambios de tanto calado cuando la aplicación ya está en una fase tan avanzada (suelen esgrimir como razón que sólo se trata de un aspecto estético, que al fin y al cabo el programa funciona bien).
  • Teclas de acceso rápido (hotkeys) y atajos de teclado (shortcuts): es importante comprobar que en los distintos menús y cuadros de diálogo no hay hotkeys duplicadas. Además, en español se debe evitar que las hotkeys correspondan a vocales acentuadas (teóricamente también deben evitarse las letras con trazos hacia abajo como g, p o y, pero en la mayoría de los casos es necesario utilizarlas para evitar la duplicación). Por cuanto respecta a los atajos de teclado, es absolutamente necesario comprobar no sólo que están localizados (Mayús en lugar de Shift, etc.­), sino que funcionan y abren los cuadros de diálogo apropiados (un caso que a veces falla es cuando se asigna un atajo como Ctrl + ñ).
  • Aspectos referentes al local (entandamos local como “A collection of rules and data specific to a language and a geographic area”): en este sentido es necesario comprobar, entre otras cosas, que las fechas (tanto las que se muestran fijas en la interfaz como las generadas dinámicamente para nombres de archivos, fechas de modificación, etc.) utilizan un formato propio del español, que la moneda utilizada es el euro y que los números utilizan los separadores correctos para decimales y unidades de millar (coma y punto respectivamente[2]).
  • Seguimiento y vigencia de los glosarios, listas terminológicas y guías de estilo en contexto: durante el testing se tiene la oportunidad de ver la traducción del software en su contexto real. Esto ofrece la posibilidad de constatar que todo el software sigue las directrices de estilo determinadas por el cliente, al tiempo que permite comprobar que la aplicación de la terminología se ha llevado a cabo de forma consistente y coherente no sólo de forma interna (con respecto a la propia aplicación), sino también de forma externa (con respecto a la versión del sistema operativo en que se ejecute).
  • Alineación y desbordamiento (truncation): se debe comprobar que todo el texto está correctamente alineado (por ejemplo, que todas las casillas de verificación del mismo nivel jerárquico tienen idéntica alineación). Por otra parte, es necesario asegurarse de que todas las opciones de software (ya sean menús desplegables, texto descriptivo, de casillas de verificación, etc.) se ven completas, de forma que no haya texto que desborda el espacio que le ha sido asignado, es decir, que no haya lo que comúnmente se denomina “texto truncado”.

Ejemplo de texto truncado

  • Puntuación­: una correcta, y sobre todo consistente, puntuación ayuda no sólo a diferenciar las distintas opciones dentro de la aplicación, si no que facilita la lectura. Por ello, es necesario comprobar que la puntuación en mensajes de error, información sobre herramientas (tooltip), opciones de software de un mismo cuadro de diálogo o panel es consistente.
  • Adecuación de las traducciones a la parte de la interfaz de usuario donde aparecen: si es importante asegurarse de que todo está lingüística y gramaticalmente correcto, también lo es garantizar que se ha utilizado la forma adecuada en cada parte de la interfaz de usuario. Así, el infinitivo se utiliza en la gran mayoría (siempre hay excepciones) de los casos para botones, elementos de menú y casillas de verificación (aquellas opciones que desencadenan una acción), mientras que se suelen utilizar otro tipo de construcciones (imperativo o texto de corrido) para el resto de cadenas como, por ejemplo, mensajes de error, información sobre herramientas, mensajes de la barra de estado y otros mensajes de diversa naturaleza mostrados en la interfaz.

Creo que, a grandes rasgos, estas son las comprobaciones básicas que siempre se han de tener en cuenta (al menos son las que yo trato de no olvidar). Existen algunas más, pero ya muchas veces dependen de las instrucciones del cliente, del tiempo del que se dispone o incluso de la propia naturaleza de la aplicación.

Un testing realizado de forma concienzuda puede no sólo mejorar de forma sustancial la calidad lingüística y estética de un producto (los aspectos en los que el traductor y localizador puede incidir de forma directa), sino que es esencial para detectar errores graves o muy obvios que pueden perjudicar seriamente no sólo la calidad del producto, sino que pueden dañar la reputación del cliente que ha desarrollado la aplicación.

Espero que esta reflexión os haya resultado interesante. Si alguien quiere aportar algún punto que se me haya pasado ahora al escribir o desee completarlo, soy todo oídos.

Un saludo,

Álvaro

PD: si os interesa el testing, os recomiendo echar  un vistazo al último número de Multilingual y, por otra parte, al blog Algo más que traducir para cononcer la opinión al respecto de un especialista en localización de videojuegos.

Recomendación musical: Heaven can wait, de Charlotte Gainsbourg con Beck


[1] Este tipo de casos (test cases) se compilan en una guía o mapa de testing que el tester debe seguir y cumplimentar a medida que avanza en la tarea.

[2] La polémica acerca de los separadores en los números ha sido ampliamente debatido en diversas publicaciones. A modo de introducción, recomendamos consultar en primer lugar la referencia de la RAE con respecto a la separación en números.


Cambios y nueva imagen

Saludos:

Finalmente hoy he subido la actualización de mi sitio web. Entre unas cosas y otras, me ha llevado muchísimo tiempo completar la nueva versión en Flash y, de hecho, todavía hay mejoras que hacerle y cotenidos que ir añadiéndole.

Bueno, lo dicho, que ya podéis visitar: www.alvaromira.es.

Por supuesto, quedo abierto a vuestras sugerencias y comentarios, porque seguro que vais a ver un montón de cosas que no veo yo.

Bueno, un saludo a todos.

Álvaro Mira

Becas para el Instituo Cervantes

Saludos a todos. Escribo unas líneas rápidas por si alguien está interesado en las becas que ha sacado el Instituto InstitutoCervantesCervantes. No son una maravilla desde el punto de vista económico, pero pueden resultar interesantes para estudiantes que vayan a licenciarse en breve o para aquellos que deseen cambiar de aires.

Eso es todo. Aquí os paso el enlace: http://www.boe.es/boe/dias/2009/11/06/pdfs/BOE-A-2009-17633.pdf .

Ya me va quedando menos para terminar mi nueva web. Prometo volver a escribir con normalidad cuando esté lista y subida a Internet.

Sin más, me despido por el momento.

Álvaro

Inactividad por trabajo en nueva web

Saludos a todos:

Muchas gracias por el gran número de visitas recientes. Desafortunadamente estoy muy ocupado, y el tiempo que tengo después del trabajo lo estoy dedicando a trabajar en mi nueva web (es lo malo de hacerlo todo uno mismo, que consume mucho tiempo).

Os enseño una capturilla, para que os hagáis una idea:

Proceso de creación de mi nueva web

Proceso de creación de mi nueva web

Va ir en Flash, puesto que hace poco que he terminado un curso de ActionScript, por lo que me siento lo suficientemente seguro como para aventurarme con la interactividad y los efectos visuales de Flash. Para los que os guste el diseño, os recomiendo leer rápidamente este post, http://janmi.com/mostrar-acentos-en-flash/, gracias al que he acabado por solucionar los problemas de carga de las variables externa de texto con acentos.

Prometo hacer un esfuerzo por escribir en cuanto termine la nueva web y la publique.

Hasta entonces, os agradezco el interés.

Gracias,

Álvaro

Recomendación musical: Stereophonics sacan nuevo single, Innocent.  Ya puedes escucharlo en Youtube.