lunes, 17 de noviembre de 2008

Llegamos a la convergencia (II)

En la oficina usamos preferentemente SDLx, pero también Trados, cuando el trabajo lo requiere. SDLx en teoría trabaja con su propio módulo de MT, AutoTrans, pero se vende por separado y hace años que está descatalogado. No pude encontrar más datos: SDLx sigue siendo minoritario y no despierta interés como para que sus fans investiguen cómo hacer que se comunique con un sistema de MT. Y SDL se centra más en desarrollar Trados que en su propio software original: cuestión de nombre de marca, supongo.

Trados en teoría (y van dos) es compatible con dos herramientas de MT, Logos y Systran. Tenemos unas cuantas licencias de Systran, pero están muertas de risa porque la única manera documentada de utilizar Systran como motor de MT es desde su propia interfaz que, sinceramente, da pena. Parece pensada más bien para secretarios con idiomas y "dominio" de Office que para un traductor hecho y derecho. Me imagino que se puede trabajar con Systran dentro de Trados+Word (sé que se puede con Wordfast, mediante su barra de herramientas), pero como yo le tengo alergia al Word, hace unos meses me puse a investigar si había alguna posibilidad de trabajar dentro de Trados TagEditor. Y resulta que en el manual de Trados te explica con pelos y señales cómo trabajar con Systran... Sólo que no funciona. Al parecer las cabezas pensantes de Systran eliminaron la compatibilidad con Trados en su última versión, la 6. Ríase usted de Microsoft cuando hace lo imposible para que su software no hable con los de los demás.
El método, que funciona parcialmente con la versión 5 de Systran, es el siguiente. Después de analizar los archivos traducibles mediante Workbench, se exportan los segmentos desconocidos (opción "Export Unknown Segments", en la misma ventana de análisis), a un RTF "formato Systran", con pares de segmentos bilingües (similar a un RTF traducido con Word+Trados). Se pasa el RTF por Systran con los diccionarios que queramos y el RTF resultante se limpia en la TM. Los segmentos con traducción de MT quedan marcados en la TM como tales y se ofrecen con una penalización x (por defecto, 15%). Cuando nos aparece ese segmento dentro de TagEditor, lo posteditamos debidamente y, al subirse a la TM, pierde la penalización y pasa a ser un segmento como cualquier otro.
Ésta es la teoría, pero no funciona del todo. O a mí se me escapa algún detalle tonto. El caso es que el RTF "formato Systran" no lo acaba de entender Systran y traduce tanto la parte donde va el texto origen como la frase el texto destino (si la traducción fuera inglés-español, nos dejaría sólo segmentos español-español), lo que nos da un RTF imposible de limpiar en la TM. Si al final no se trata de un típico EBKC, la solución sería crear una macro para preprocesar el RTF con expresiones regulares que protejan/oculten la parte con el texto origen.
Ya es un método bastante complejo de por sí como para encima añadir el paso adicional de ejecutar una macro sobre el RTF antes de abrirlo en Systran. Además de tener que pagar a alguien para que programe la macro porque no sabes hacer expresiones regulares (tengo que aprender, lo sé...).

Sin embargo, ahora ha aparecido un método extremadamente sencillo para tener MT dentro de TagEditor sin tener que hacer todos estas cabriolas. Actualizarse al SDL Trados 2007 Suite que acaba de salir. El método es muy sencillo: cuando Workbench no encuentra coincidencias para un segmento, le pide al servidor de SDL la frase y ésta aparece traducida en el documento, para que la posteditemos debidamente.
Yo soy de los que piensa que lo más fácil no tiene por qué ser lo mejor, y tengo muchas reservas respecto a este método. Sí, no requiere intervención del usuario, pero:
  1. Te toca tragar con las condiciones de SDL. Si el año que viene deciden hacer el servicio de pago, a soltar la mosca. Si quieres trabajar con otro servicio web de MT de traducción automática como Google, Systran o ProMT, no puedes. Y dudo mucho que se pongan a firmar acuerdos con la competencia: a SDL le va más eso de eliminar la competencia a golpe de talonario, a lo Microsoft.
  2. Dependes de Internet de principio a fin de la traducción. Si el servidor de SDL está colapsado, no puedes trabajar. Si no tienes conexión, no puedes trabajar.
  3. No tienes control terminológico. No puedes decirle al servidor de SDL que use este glosario en lugar del suyo. Sí, obviamente puedes tener un glosario Multiterm activado y usarlo al posteditar, pero es mejor prevenir que curar.
Como tampoco quiero ser injusto, aviso que ahora mismo SDL está de oferta de lanzamiento, con un 10% de descuento para empresas y para autónomos. Quien no quiera calentarse la cabeza, ya sabe.

En la próxima entrada, hablaré de la solución que considero más flexible y potente: Swordfish.

sábado, 8 de noviembre de 2008

Llegamos a la convergencia (I)

Por lo que respecta al software para traducción, cuando hablamos de "convergencia", podemos referirnos a la convergencia en traducción automática. Así, el modelo híbrido de traducción automática tiene un poco de RBMT y un poco de SMT. Es a lo que apunta uno de los dinosaurios en este campo, los franceses de Systran. Hasta hace un par de añitos, eran los reyes indiscutibles de la automatización. No es que fueran los mejores, es que eran los únicos. Pero luego llegó gente como LanguageWeaver y Google Translate, que le han hecho mucho daño. Pero allí siguen ellos tan panchos; mientras sean los únicos europeos que pintan algo en la MT, serán los únicos que considere la Comisión Europea para sus necesidades (y luego nuestros políticos critican los mercados proteccionistas).

Pero no me refiero a la convergencia entre modelos de MT. Me refiero a lo que da nombre a esta página, la convergencia entre sistemas de traducción de máquina y traducción asistida. Cuando bauticé este bitácora, como medio para investigar un tema que no me llamaba mucho, pero con el que el jefe no paraba de incordiar, me pareció que todavía quedaba lejos un futuro en el que traductor y máquina se entendieran con eficiencia, pero durante el mes pasado (un añito ha pasado desde el gran cambio) me he dado cuenta de que el futuro ya está aquí. Ya hay sistemas suficientemente productivos como para ser necesario su uso inmediato en una cadena de producción, sin importar lo pequeña que sea la empresa, aunque sea unipersonal (es decir, autónomo). Adaptarse o desaparecer.

Comenzaré por los sistemas que he estudiado y menos me atraen, o al menos, que menos se adaptan a las necesidades de la empresa donde trabajo.

Atril Déjà Vu
Los chicos de Atril se lo curran bastante con estrategias no monopolistas, escuchando a sus clientes y manteniendo una interfaz muy agradable y personalizable, de la que SDLx es un calco evidente, con todas las ventajas que ello conlleva si te encanta la interfaz de SDLx. En dos puntos no tiene rival: su sistema de filtrado (ocultación) por tipo de segmento (sin traducir, sin confirmar, coincidencias parciales, etc) para una revisión selectiva, y la capacidad de exportación a archivos RTF bilingües en dos columnas que se pueden editar tranquilamente y, oh maravilla de las maravillas, importar de vuelta a Déjà Vu con los cambios del revisor, que puede trabajar con tan solo un software editor de texto enriquecido.

No es traducción automática en sentido estricto, pues se nutre de intervención humana. Este método, conocido como EBMT, combina o ensambla terminología y fraseología definidas por el usuario, ya sea de forma manual o semiautomática con intervención humana. Luego el usuario o posteditor "encola" las partes que ofrece el software con los nexos adecuados. En el ejemplo siguiente (sacado de la documentación de Swordfish, un software que me reservo para el final), el posteditor se encarga de marcar estas palabras en negrita como términos válidos para el autoensamblaje:

El gato es negro
El gato es blanco (el término "gato" se traduce solo)
El perro es negro (el término "negro" se traduce solo)
El perro es blanco

Las palabras con significado se traducen solas y en este ejemplo ni siquiera hace falta "encolarlas" con un artículo o un verbo, ya que el programa toma "El gato es negro" de la TM y aplica los términos "perro" y "blanco" del glosario. Cuando haya variaciones gramaticales (el caso más habitual), la intervención del posteditor será necesaria, pues se trata de un programa TAO más que de un sistema de MT.

Si se pasa el tiempo suficiente "alimentando" el sistema, los resultados pueden ser muy buenos en campos y con tipos de texto concretos. Pero es difícil convencer a los traductores de que pasen tiempo allanando el terreno a los que vienen después. No nos damos cuenta de que los que venimos después podemos ser nosotros mismos. En fin, opción descartada por tener un FUD superior a los beneficios a corto plazo en eficiencia.

Alchemy Publisher
Este software sólo tiene unos pocos meses y viene de Alchemy, los irlandeses que nos trajeron Alchemy Catalyst, el software estándar para la localización de software. Publisher se centra en los formatos de archivo de documentación, con una interfaz clavada a la de Catalyst. La gracia de los programas de Alchemy es que se puede traducir el archivo con el diseño original. Es decir, es el único software WYSIWYG de su categoría. Esto podrá ser bueno o malo, ya que el formato puede distraer al traductor, que tiene que centrarse en el contenido (texto) que en el continente (formato), pero esto ya es otro debate. Personalmente, pienso que ayuda más que molesta, pero aquí entra de nuevo el factor FUD de no querer cambiar lo que se conoce.
Publisher además es muy útil si se mantiene un control de versiones de los documentos. Es decir, si se dispone de la edición multilingüe de la anterior versión del documento. Publisher es único en la medida en que puede mantener el formato de la anterior versión, en lugar de tener que recrearlo con cada cambio de versión. Mi opinión personal es bastante cauta (FUD): lo creeré cuando lo vea en un caso real (no de estudio). De todas formas, a menudo el cliente no quiere proporcionar la versión anterior, pero sí se dispone de la TM, un caso obvio de pescadilla que se muerde la cola: se le da más importancia a la TM que a la versión anterior del documento porque, hasta la llegada de Publisher, la TM es vital, pero la versión anterior sólo es opcional. Ya veremos dentro de unos años, quizá consigan cambiar los hábitos del mercado.

Pero a lo que iba: que yo sepa, han sido los primeros en ver el potencial de la Google Translate API. Cuando la TM (o la versión anterior del documento) no proporciona una coincidencia válida, se le da a un botoncito y el programa le pide la traducción a Google. Sencillo y efectivo. El problema es el descontrol terminológico de una solución SMT no personalizable (a Google no se le puede pedir que use nuestros glosarios), pero para ciertos tipos de documentos esto se puede corregir sin excesivo esfuerzo.

El inconveniente de Publisher es que no es un estándar (de nuevo, la pescadilla: no se usa porque no es un estándar y no es un estándar porque no se usa). Comprar las licencias dentro de un departamento de traducción de una gran empresa seguro que es muy productivo, pero que una LSP consiga que sus externos usen este software es otro cantar. Algunos aceptarán si se les promete clases de formación, descuentos en la compra (los dos negociables con Alchemy por parte del LSP) y, sobre todo, la promesa de enviarles mucho trabajo para rentabilizar el esfuerzo de adquirir la nueva herramienta. Y luego llega el gran debate: ¿deben bajar los precios los autónomos que utilicen una solución de MT+TM con eficiencia probada? Ahí no me meto, será el propio mercado quien hable en los próximos meses.

Por hoy ya está bien, en los próximos días hablaré de las posibilidades de convergencia con Trados y con Swordfish.