h1

¿Cuántos traductores necesito?

25 de mayo de 2014

Hace poco terminé en Coursera el curso Operations management, de la Universidad de Pennsylvania. Es una introducción a la gestión de cadenas de producción, materia de la que he oído hablar poco (poquísimo) a los traductores, pese a que nuestra profesión, con toda su imprevisibilidad y todos sus vaivenes, se presta bastante al uso de las técnicas de análisis, planificación y supervisión que se explican en el curso.

Para ilustrar la utilidad de estos estudios en el mundo de la traducción se me ha ocurrido utilizar algunas de las fórmulas de los módulos 1 y 2 a una situación hipotética muy habitual en las agencias de traducción: un cliente remite una propuesta y la agencia tiene que hacer un presupuesto. En casi todos los casos, la partida más importante de ese presupuesto la compondrán los salarios: ¿cuántos traductores voy a necesitar para traducir todo esto y durante cuánto tiempo? Los requisitos del cliente determinarán el nivel de demanda (el ritmo al que habrá que producir páginas traducidas para cumplir el plazo establecido) y la capacidad de los traductores determinará el costo laboral (la cantidad de tiempo que necesito para traducir cada página). Con esos dos datos, es fácil calcular cuántos traductores necesitará la agencia para terminar a tiempo.

En este vídeo se explican los cálculos en una hoja de Microsoft Excel. La ventaja de usar Excel es que, una vez tengamos todas las variables del proyecto a la vista, será mucho más fácil modificarlas para calcular imprevistos, requisitos o plazos modificados y demás variaciones.

[Se recomienda ver a pantalla completa.]

Este es el primer vídeo que hago. He usado un software libre que se llama CamStudio y que me ha gustado bastante. Me gustaría que alguien con experiencia en estas lides me recomendara alguna herramienta sencilla para edición de vídeo (recortar pequeños errores, ajustar inicio y fin, poner títulos y subtítulos, etc.). Cualquier sugerencia será más que bienvenida. También agradezco los comentarios sobre el contenido, ya que no soy precisamente experto en gestión de proyectos de traducción.

Anuncios
h1

Artículos sobre scripts con texto de derecha a izquierda

5 de mayo de 2013

Richard Ishida, encargado de las actividades de internacionalización del Consorcio World Wide Web (W3C) acaba de publicar cuatro artículos nuevos sobre la forma de trabajar con texto de derecha a izquierda (árabe, hebreo, urdu y demás) en un entorno de programación web, o sea, básicamente texto simple y lenguajes de etiquetas, con información actualizada sobre el nuevo estándar HTML5. (Esta noticia me llegó por un retweet del consorcio Unicode.)

Los artículos de Ishida son particularmente importantes para quienes trabajamos con scripts y lenguajes de derecha a izquierda porque explican con una claridad meridiana cómo funciona el texto Unicode y qué cabe esperar de los programas con los que trabajamos. En mi opinión, el artículo más relevante es este, que trata del algoritmo bidireccional y el comportamiento del texto mezclado. Digo que es el más relevante porque es el que explica los conceptos básicos. Si uno quiere entender por qué un determinado editor de texto o aplicación se comporta de cierta manera cuando escribimos en árabe entre etiquetas HTML o XML, hay que saber primero lo que está ocurriendo entre bastidores y cómo puede haber implementado el programador el algoritmo en ese contexto específico. En otras palabras, explica por qué cuando estamos mezclando texto latino con texto árabe (o hebreo, o urdu, o etc.), de repente algún elemento parece “saltar” a un lugar que no le corresponde.

El artículo requiere una atenta lectura, pero una vez digerido, puede salvar la vida de más de un lingüista o programador desesperado.

(Hay que advertir aquí que lo que describe Ishida es el estándar, es decir, la situación ideal tal como la concibieron los ingenieros del W3C y Unicode. Cuando un programador crea un editor o un procesador de texto, se le presupone la intención de aplicar ese estándar en toda su extensión. Lamentablemente, a veces no es así, y es posible que un determinado editor o procesador de texto tenga un comportamiento imprevisible debido a una implementación deficiente o incompleta.)

 

h1

Convertir TEI con Python

19 de abril de 2013

Hace unos días, un colega que está trabajando en un algoritmo de alineación geométrica me pidió un vocabulario básico inglés-español. Él trabaja normalmente con árabe e inglés y quería probar sus prototipos con español, para ver cómo se comparan los resultados de esos pares de idiomas.

(La alineación geométrica es un método de alineación de segmentos bilingües que no se basa en la longitud relativa de los segmentos ni en la frecuencia de las palabras conocidas, sino en inferencias geométricas basadas en la posición de las palabras dentro del texto. Es particularmente útil en el caso del árabe porque la puntuación y la segmentación, escollos habituales para la alineación de textos árabes con textos en otras lenguas, tienen una importancia relativa.)

Me puse a buscar diccionarios bilingües gratuitos por la red y me topé con FreeDict.org. Este sitio tiene una cantidad enorme de diccionarios bilingües de tipo “BBB”, o sea, “Bad But Big” (malos, pero grandes), justamente lo que mi amigo necesitaba. No hacía falta que la lista fuese muy precisa, pero sí que contuviera muchísimas palabras.

El diccionario inglés-español que encontré era un auténtico desastre: las entradas con más de una palabra están truncadas (las inglesas) o pegadas unas a otras (las españolas), señal evidente de que quien lo creó lo hizo con herramientas automatizadas y, fiel al principio BBB, no se preocupó en absoluto de comprobar el resultado. Quizá ni siquiera sabía español (en realidad no hace falta).

Los archivos descargables de FreeDict.org están en formato TEI (Text Encoding Initiative). El consorcio TEI es el creador y custodio del formato que lleva su nombre, dedicado a la representación de textos en formato digital. TEI es un lenguage SGML bastante sencillo con muchísimas aplicaciones prácticas.

Yo nunca había manejado este formato. Tengo scripts para leer HTML y XML (sobre todo para TMX), pero no para TEI. Por fortuna, una búsqueda rápida me llevó a esta página web de Mike Giarlo en la que afirma que leer TEI con Python “está chupado” (literalmente dice, en inglés, que es “simple as pie”). Y tiene razón.

La librería ideal para conseguirlo se llama BeautifulSoup, interesante nombre que procede de un poema de Lewis Carroll. Quien tenga curiosidad puede leerlo en el capítulo X de Alicia en el país de las maravillas (Lewis Carroll). Esta librería es, ¿cómo decirlo?, una bendición. No tardé ni media hora en aprender a usarla y escribir el script que me devolvió el diccionario entero, en el formato requerido (término-tabulador-término) y sin errores. El único tropiezo, muy breve, fue la forma de importar la librería, puesto que el código de la página de Mike Giarlo está un poco desfasado.

El script está aquí. Es muy elemental, pero ilustra el uso de la librería para esta estructura de datos concreta. Espero que sea útil.

h1

El CAT del futuro

16 de marzo de 2013

En 2010, Philipp Koehn y Jean Senellart explicaron dos maneras eficientes de complementar la traducción automática estadística con las memorias de traducción, o viceversa (véase este documento). En la primera, cada segmento que coincidiera en un 70% o más con otro segmento de la memoria de traducción (lo que se conoce como fuzzy match), se aislarían las partes no coincidentes. A continuación, se utilizaría el sistema de traducción automática para traducir esas partes faltantes. En sus ensayos, Koehn y Senellart concluyeron que este método mejoraba los resultados, en promedio, a partir de un 80% de coincidencia (o fuzziness).

 El segundo método consistía en convertir las coincidencias de la memoria de traducción en reglas gramaticales jerárquicas que se aplicarían a todos los casos similares (véase el apartado 4 del mismo documento). Estas “macrorreglas” son más eficientes que las normas gramaticales abstractas porque no hace falta determinar el valor gramatical y sintáctico de cada componente. Funcionan como moldes en los que se pueden encajar elementos traducibles. Con este método, los resultados mejoraban en todos los casos, a partir de un 70% de coincidencia.

Este documento no es más que uno de los muchos estudios académicos que, en los últimos dos años, han puesto de relieve la cercanía metodológica y conceptual de las memorias de traducción y los traductores automáticos. Como explican los autores en el prólogo, las dos tecnologías han madurado durante veinte años, pero han seguido caminos divergentes. Parece que en esta década ha llegado el momento de hermanarlas.

Tres años después de la fecha de publicación de ese documento, hay ya varios proyectos de traducción automática a gran escala que se apoyan en las memorias de traducción y en el uso parcial de reglas y “macrorreglas”. Entre los más destacados están CASMACAT y MATECAT, financiados por las instituciones europeas e impulsados por un consorcio de universidades y entidades del mismo continente, con participación destacada de la Universidad de Edimburgo.

 El objetivo de MATECAT es crear una interfaz para traductores que combine las dos tecnologías de forma práctica e inteligente para solucionar uno de los principales escollos que presenta la traducción automática estadística, a saber, la imposibilidad de ajustar o modificar con facilidad los modelos lingüísticos (en otras palabras, los traductores automáticos actuales siempre cometen los mismos errores). Por ello, se pretende conseguir que el sistema aprenda sobre la marcha y utilice la traducción interactiva de sus usuarios para perfeccionar las propuestas de traducción.

Más interesante aún es CASMACAT, en el que, por cierto, participa la Universidad de Valencia: se trata de un análisis cognitivo del comportamiento de los traductores que usan sistemas de traducción automática. En este proyecto, se registran los movimientos de los ojos y las pulsaciones de teclas de los usuarios para definir tipos y estilos de traductores. Con la información recabada se construirán interfaces con tres elementos totalmente nuevos: la traducción predictiva, que presenta alternativas para corregir el texto propuesto basándose en la temática del documento, la modalidad de traducción y la estructura sintáctica de la frase (una especie de super aide mémoire); la edición interactiva, que añade información relevante a la traducción automática, equivalente a la que se suele ver en las memorias de traducción, como el reconocimiento automático de terminología, elementos intraducibles y demás; y la capacidad de aprendizaje, con la que se consigue que las traducciones que propone el sistema tengan en cuenta las correcciones que ya ha hecho antes el traductor humano.

En la actualidad, las principales empresas fabricantes de software de traducción asistida por ordenador han integrado la traducción automática, si bien de manera muy primitiva, en sus herramientas comerciales. Tengo la impresión de que estos proyectos institucionales son la cara visible de toda una corriente de investigación que, en los próximos meses o años, va a dar como resultado una nueva generación de herramientas en la que estas dos tecnologías van a dejar de evolucionar por separado. Si eso sucede, se plantearán muchos interrogantes (muchos más que ahora) sobre el componente principal e imprescindible de todas estas tecnologías, a saber, los textos traducidos por traductores humanos, sin los cuales es imposible hacerlos funcionar.

Por otra parte, si, como es de esperar, se generaliza la postedición y va desapareciendo la traducción tradicional en casi todos los contextos no literarios, cabe preguntarse por los cambios cualitativos y cuantitativos que esto puede provocar en los futuros textos traducidos. Si cambiamos los métodos, sería ingenuo suponer que el producto resultante será el mismo. ¿Algún estudio de estilometría al respecto?

h1

Los traductores programadores

5 de marzo de 2013

Estos días he estado leyendo el nuevo número de la revista Tradumàtica, dedicado a la traducción automática y la postedición (gracias por el aviso, @MinaTraduce).

Es muy interesante ver cómo la traducción automática está cambiando ya las funciones y los perfiles de quienes traducimos. Me han interesado en particular, por la cercanía a mi propia experiencia, el artículo de Torrejón y Rico sobre las aptitudes del posteditor y el de Guerberof, Depraetere y O’Brien sobre lo que sabemos y lo que nos gustaría saber de la traducción automática y la postedición.

La demanda de profesionales informáticos con conocimientos de procesamiento del lenguaje natural se ha disparado. La cantidad de universidades que ofrecen estudios de este tipo, también. Al mismo tiempo, en conversaciones con estudiantes y graduados recientes he podido confirmar que la transición de traductor a posteditor también ha empezado, y viene con fuerza: son muchos los jóvenes que ya han participado en proyectos de este tipo, y las ofertas de trabajo para postedición son cada vez más frecuentes. También empieza a haber ofertas de cursos de postedición, en general organizados por asociaciones y academias privadas.

 Cabe preguntarse si hay un mercado de profesionales híbridos, es decir, de traductores con estudios de informática o de informáticos con experiencia en traducción y buenos conocimientos de lingüística. No me refiero a los traductores que, como bien apunta Rubén de la Fuente en el editorial de Tradumàtica, deben participar activamente en la construcción del sistema como beta testers y consultores, es decir, como futuros usuarios finales. Tampoco a los traductores “que saben informática”, es decir, a esos imprescindibles gurús que dedican horas y horas a desentrañar los misterios del software especializado (es decir, a analizar a fondo las interfaces de usuario) y a publicar sus conclusiones en foros, listas de correo, blogs y demás. Lo que me pregunto es si hay demanda de profesionales que sean tanto traductores como programadores.

 La experiencia demuestra que, al emprender un proyecto que implique la creación de un sistema estadísticos de traducción automática, es muy práctico tener alguien en el equipo del proyecto que sepa, por un lado, lo que espera y necesita la máquina para funcionar y, por el otro, lo que espera y necesita el usuario para hacer su trabajo. Esa persona no tiene por qué ser un informático, pero sí tiene que tener una idea cabal de cómo funcionan ciertos procesos y tecnologías tales como la tokenización, la alineación de palabras, la indización y muchas otras. Tampoco tiene que ser un traductor en sentido estricto, pero debe tener un dominio suficiente del par de idiomas como para saber si el corpus bilingüe tiene el contenido y la calidad necesarios, si conviene separar afijos antes de alinear o si hay que procesar determinados elementos de la frase de destino como los ordinales, las mayúsculas o las fechas.

Un especialista de este tipo puede no solo detectar, sino también diagnosticar, problemas como los que describo en este post (en ese caso se trata de una retraducción a un tercer idioma; la solución sería procesar los sinónimos ponderando mejor el contexto, o traducir sin idioma intermedio), y puede contribuir a que los proyectos de traducción automática se ejecuten con eficiencia y tengan buena recepción de los usuarios.

 En sistemas de uso general que ofrecen cientos de combinaciones de idiomas, como Bing y Google, no parece viable contratar especialistas para cada par de idiomas. Para hacernos una idea, en este momento el traductor de Bing ofrece 41 idiomas que, tomados por pares, darían más de 1600 combinaciones. (Por si alguien está pensando que en esa cuenta hay redundancia porque inglés-español es lo mismo que español-inglés, aclaro que los modelos lingüísticos, por lo menos los que genera Moses, no son reversibles: hay que crear dos sistemas diferentes.)

 Ahora bien, los estudios académicos demuestran que la traducción automática combinada con la postedición puede ser muy eficiente en proyectos controlados y limitados, con un modelo lingüístico construido especialmente para la ocasión y un grupo de revisores o posteditores familiarizado con esos materiales. En esos casos, la presencia en el equipo de un especialista que conozca bien tanto la parte informática como la lingüística ahorrará tiempo y esfuerzo.

 Me gustaría saber si hay alguna facultad de traducción que ofrezca ya estudios de informática aplicada dentro de su plan de estudios habitual. Sé que hay unas cuantas que tienen esos estudios a nivel de postgrado, pero también me consta que los estudiantes que los cursan tienen serias lagunas en cuestiones fundamentales, tales como el cálculo, la estadística, la programación básica (scripting) y orientada a objetos (Java, C#), los algoritmos y las estructuras de datos. Esas carencias obligan a simplificar la materia, o a estudiar por cuenta propia para subsanarlas.

 Si, como parece, los traductores, los posteditores y los terminólogos vamos a depender cada vez más de los sistemas informáticos, hasta el punto de, probablemente, dejar de traducir desde cero en un futuro bastante próximo (hay quien ya trabaja así sistemáticamente), conviene empezar a ampliar los horizontes más allá de las interfaces de usuario y pensar, a efectos profesionales, en las posibilidades que ofrece toda la labor lingüística-informática que se desarrolla entre bambalinas. Esa labor nos está facilitando el trabajo, pero también podría llegar a arrebatárnoslo, o a relegarnos a un papel secundario en el proceso de traducción.

h1

Alineaciones de urgencia

6 de febrero de 2013

Ya son muchos los colegas que me preguntan cómo alinear un documento con su traducción, ya sea para crear un texto bilingüe o para una memoria de traducción. Puedo hablar de dos aplicaciones web con servicio de alineación gratuito: YouAlign y Wordfast Aligner (incluido en Wordfast Anywhere).

Para ambos hay que crear una cuenta antes de empezar. YouAlign pide más datos personales que Wordfast y pide confirmación del registro por correo. Wordfast solo necesita el nombre y la contraseña para empezar. Los dos programas aceptan los formatos de documento más frecuentes.

En YouAlign hay que elegir los dos archivos y los idiomas correspondientes. La lista de idiomas disponibles es bastante impresionante. Además, hay tres opciones para purgar segmentos vacíos, repetidos y demás. El límite de tamaño es de 1 Mb.

En Wordfast, se entra al alineador desde un menú del programa de memoria de traducción (Tools > Align your documents). Una vez ahí, se puede arrastrar y soltar (drag and drop) los dos documentos a la ventana del navegador. La aplicación detecta automáticamente los idiomas y propone una dirección (idioma A a idioma B o viceversa). El usuario solo tiene que confirmar esa preselección, o modificarla si procede. Una importante restricción de Wordfast es que uno de los dos idiomas debe ser el inglés. No hay indicación de límite de tamaño.

YouAlign genera dos enlaces para bajar los documentos alineados. Uno es un bitexto HTML (formato habitual de LogiTerm/AlignFactory) y el otro un archivo TMX.

Wordfast envía por correo electrónico un archivo zip con a) un archivo TMX, b) un archivo TXT para Wordfast (formato de memoria de traducción clásico) y c) un archivo Excel que, además de la alineación, da puntuaciones para cada segmento alineado.

Probé los dos alineadores con un documento inglés/español en formato MS Word 2003 de un organismo internacional. Estaba bien estructurado pero tenía alguna que otra trampita.

En cuanto al contenido, las dos aplicaciones generaron resultados más que satisfactorios, si bien YouAlign perdió un poco menos de texto que Wordfast, mientras que este último capeó las trampitas con más gracia.

En cuanto a la parte técnica, es decir, los archivos TMX, el de Wordfast es claramente superior. El TMX de YouAlign no supera ninguno de los verificadores de sintaxis XML que tengo instalados porque está codificado en UTF-16 pero tiene contenido UTF-8. Por ese mismo motivo, el archivo ocupa casi el doble que el de Wordfast (que está en UTF-8). Además, la estructura que genera la aplicación de Wordfast es más rica y más completa desde el punto de vista programático: incluye la declaración DOCTYPE y más metadatos para los segmentos alineados. Lo único que no me gusta es que se toma la libertad de elegir la variante regional del idioma (en este caso, EN-US y ES-ES), mientras que YouAlign, con un criterio lógico y más conservador, usa los códigos genéricos (EN y ES).

La alineación automática de árabe y español es casi siempre lamentable. Aun así, si tengo tiempo de hacer pruebas las publicaré aquí.

h1

n-gramas y triángulos de idiomas

27 de diciembre de 2012

He aquí una sencilla demostración de cómo la alineación de n-gramas y el uso del inglés como idioma de referencia pueden echar a perder resultados muy concretos de un sistema de traducción automática basado en las estadísticas.

En el traductor de Google, se seleccionan el español como idioma de origen y el árabe como idioma de destino.

En primer lugar, se escribe:

 el niño no tiene padrino

El resultado en árabe, al 27 de diciembre del 2012, es el siguiente:

 الطفل ليس لديه الراعي

(El niño no tiene cuidador.) Parece un resultado aceptable y lógico para un sistema de traducción automática. Ahora bien, si ponemos “padrinos” en plural, el resultado cambia inmediatamente y se convierte en:

 الطفل ليس لديه مقدمي

(El niño no tiene… ¿precedencias, preparativos?) Esto ya no es aceptable, ni mucho menos lógico. ¿Qué hace ahí esa ya final? La respuesta se puede obtener escribiendo un punto final en la frase, justo después de “padrinos”. El resultado cambia una vez más y ahora dice:

الطفل ليس لديه مقدمي مشروع القرار.

(El niño no tiene patrocinadores del proyecto de resolución.) En este aparente sinsentido está la clave de lo que pasó antes. He aquí varios datos útiles para entender:

  •  Una de las palabras que se usan en inglés para el concepto de “padrino” y “apadrinar” es “sponsor”.
  • El sistema de traducción automática de Google hace un uso intensivo de los textos de las Naciones Unidas.
  • En los textos de las Naciones Unidas, los países patrocinadores de las resoluciones de la Asamblea General (los que las preparan y las presentan para su aprobación) se denominan “sponsors”. En árabe, la expresión elegida es “muqaddimu/i mashru al-qarar”.
  • El traductor de Google utiliza el inglés como idioma intermedio para traducir la mayoría de los pares de idiomas.

Sabiendo esto, uno puede inferir varias cosas.

En primer lugar, parece lógico que, en los textos en español, la forma singular “padrino” sea más frecuente que “padrinos” en plural, y que la primera esté más vinculada al ambiente familiar o mafioso (equivalente al “godfather” inglés) y la segunda al empresarial o del empleo (“sponsor”).

En segundo lugar, como hay tantas resoluciones y el texto normalizado de las Naciones Unidas se repite tantas veces, es muy probable que en el modelo lingüístico haya muchísimos n-gramas ingleses con la palabra “sponsor” alineados con “muqaddimi mashru al-qarar”. Hay que aclarar que es muy poco frecuente que haya un solo patrocinador de una resolución, lo cual significa que, desde un punto de vista estadístico, estas expresiones son predominantemente plurales.

Estos dos hechos explicarían, a mi modo de ver, el primer cambio de resultado del sistema de traducción automática. Falta por explicar por qué en ese resultado la expresión árabe queda truncada (“muqaddimi”) y por qué al escribir el punto obtenemos el desafortunado término completo. Mi opinión es que, al alinear los n-gramas, el sistema toma un número equivalente de tokens y corta el término donde cree que termina. Cuando se añade un token adicional que no ofrece ninguna información adicional de contexto (un punto o una coma), sino que reproduce, en español, la forma de la expresión equivalente en inglés, las estadísticas se decantan con claridad por “sponsors” en el idioma intermedio (inglés) y fuerzan la presencia del término árabe completo, añadiendo un n-grama más al resultado. Por el contrario, si lo que se agrega aporta algo de contexto o se aparta de la formulación estándar, la ponderación estadística se modifica y el resultado se orienta hacia otros derroteros textuales más acertados (experiméntese, por ejemplo, añadiendo “ni” o “pero”).

Se agradecen las observaciones y los comentarios.