lunes, 5 de diciembre de 2016

Modelos de lenguaje y R


A fin de seguir avanzando, en OpenTranslation estamos poniendo a punto nuestros sistemas para comenzar a utilizar modelos del lenguaje. Estos modelos del lenguaje han sido ampliamente utilizados en el procesamiento del lenguaje natural y creo que la mejor manera de entender sus aplicaciones es mediante un ejemplo:

Imaginemos que estamos creando un sistema de reconocimiento de voz y nuestro sistema es incapaz de distinguir entre las siguientes dos opciones:

wreck a nice beach
recognise speech

Aunque a primera vista tal vez no lo parezca, ambas opciones se pronuncian de manera muy similar en inglés. Es evidente que, en caso de que se le plantee la duda (y es posible, pensemos por ejemplo si escucha estas palabras en un ambiente muy ruidoso), un humano no tiene problemas en darse cuenta de que la opción correcta es la segunda «recognise speech» (reconocer la voz), ya que la primera «wreck a nice beach» (destrozar una bonita playa), no tiene mucho sentido.

El problema está en que los ordenadores no vienen de serie con el sentido común incluido, así que tenemos que encontrar una manera de que elijan entre una y otra opción.

Un método muy interesante es crear un modelo del lenguaje, analizando una gran cantidad de texto y expresándolo en forma de un conjunto de bigramas (pares de palabras) y sus respectivas frecuencias. Por ejemplo:

de la    891
lo que    610
en el    540
de que    528
a la    455
en la    449
[...]

Lo interesante de este modelo es que, con estos datos, podemos calcular la probabilidad de que una determinada cadena de texto se dé en el idioma o no. En el caso anterior, es obvio que «recognise speech» que es un término muy frecuente, tendrá una probabilidad muy superior a «wreck a nice beach», que es una combinación un tanto extraña. Por tanto, el sistema podrá distinguir cuál es la opción correcta.

Este método no solo puede aplicarse al reconocimiento de voz, sino también a cualquier situación en la que la probabilidad de una determinada secuencia de palabras nos ayude a elegir una opción sobre otra como, por ejemplo, ocurre también en la corrección ortográfica de palabras.

Dado que este método nos obliga a calcular la colección de palabras y sus frecuencias, estamos añadiendo a petraREV una función que, dado un texto, nos permite crear un modelo del lenguaje utilizado en él.

Para ilustrar su utilidad, hemos pensado que sería interesante comparar los modelos obtenidos a partir de diversos libros famosos y, para crear rápidamente los gráficos, hemos decidido utilizar R. Para que podáis repetir este proceso con cualquier otros datos, vamos a ver brevemente los comandos que hay que utilizar.

Para empezar, hay que instalar R, lo que puede hacerse fácilmente utilizando el Centro de Software de Ubuntu.

Una vez instalado, basta con que abramos la consola y escribamos:

R

¡Ojo! Es imprescindible escribir esta R en mayúsculas, si la escribimos en minúsculas nos aparecerá un mensaje de error.

A continuación, le indicamos a R la carpeta donde están nuestros datos:

> setwd('/media/.../Corpus')

Y ya podemos leer los datos:
> data=read.table('corpus.txt')

Para ver que los datos se han cargado correctamente, basta con escribir:

> data

En nuestro caso, son los siguientes:

García_Marquez,_Gabriel_-_Del_amor_y_otros_demonios    21608    48527
Asensi,_Matilde_-_El_origen_perdido    65321    188696
Montero,_Rosa_-_Bella_y_oscura    26877    64046
Sloan,_Robin_-_El_Sr_Penumbra_y_su_libreria_24_horas_abierta    33938    93863
Meyer,_Stephanie_-_Eclipse    57804    192167

La primera columna indica el título de libros, la segunda el número de bigramas y la última el número de tokens, así que definiremos estas variables:

> name=data[,1]
> bigrams=data[,2]
> tokens=data[,2]

¡Y ya podemos crear un gráfico con estos datos! Basta con escribir:

> plot(tokens,bigrams)

¡Realmente fácil! ¿Verdad?

El único problema es que no sabemos a qué libro corresponde cada punto. Afortunadamente es muy fácil solucionar este problema. Para ello, necesitaremos el paquete calibrate, así que si no lo tenemos, podemos instalarlo con:

> install.packages("calibrate")

Ahora calibramos los datos:

> library(calibrate)

Y por último indicamos que queremos que en cada punto nos aparezca el nombre del libro al que corresponde.

> textxy(tokens,bigrams,name)

Como necesito este formato en formato .png escribo los siguientes comandos:

> png('grafico.png')
> plot(tokens,bigrams)
> textxy(tokens,bigrams,name)
> dev.off()

Y ahora sí que sí, tenemos este bonito gráfico:

Sin duda es interesante pero, dado que estamos comparando libros con un número de palabras muy diferente, no es fácil obtener conclusiones. Próximamente, veremos cómo resolver este problema.


martes, 12 de abril de 2016

Xenial Xerus: una traducción muy especial al español

¡Ya puedes participar en la traducción de Ubuntu al español! Solo tienes que visitar la siguiente página:


Tras un sencillo proceso podrás comenzar a proponer tus traducciones o, si te unes al equipo de revisores, revisar las que hayan aportado otros usuarios.


Como ya sabrás, la próxima versión de Ubuntu es muy espcial, ya que se trata de una versión a largo plazo, por lo que será la que domine en los escritorios con Linux en los siguientes años. A menos de 9 días para que se lance... ¿quieres ayudar a que sea la mejor que se ha lanzado hasta el momento?



lunes, 4 de abril de 2016

petraREV: Las incidencias

Si ha habido una constante en mi puesto de trabajo desde que comencé a traducir ha sido el pequeño trozo de papel que siempre hay al teclado de mi ordenador con su correspondiente bolígrafo. Si miras el escritorio de cualquier traductor, sobre todo si se dedica a la localización, con frecuencia encontrarás una herramienta similar, tal vez sea un folio rigurosamente blanco, tal vez un papel para reciclar o tal vez, si eres especialmente ordenado, un cuaderno. Al parecer, mientras traducimos siempre hay cosas para las que somos incapaces de encontrar una solución que nos convenza, por lo que lo escribimos con la esperanza de que cuando estemos más despejados podamos despejar la duda.

Muchas veces se diría que no hace falta nada más que escribir nuestra duda para que se resuelva. Parece que, al formularla en palabras, aunque solo sean dos, nuestra cabeza empieza a dar vueltas buscando una solución hasta que la encuentra, por la que con frecuencia al terminar la traducción, sin que haya hecho falta estudiar punto por punto todas nuestras dudas, las hemos resuelto.

Lamentablemente no siempre es así. A veces terminamos la traducción y el problema que nos planteaba sigue ahí, lo que nos obliga a tomar una decisión final. Con frecuencia, descubriremos que no somos capaces de resolver por nosotros mismos las dudas, lo que nos obligará a redactar una consultas al cliente.

Las consultas al cliente son una cuestión espinosa: a los traductores casi nunca les gusta enviarlas y a los clientes casi nunca les gusta recibirlas, pero hay ocasiones donde son inevitables. Por ejemplo, no encontrar una referencia (como el título de una publicación o una opción de software) obliga de manera inexcusable a consultar al cliente acerca del criterio que quiere seguir.

El proceso de consulta al cliente suele estar definido con precisión, ya que prácticamente todas las agencias de traducción dispone de una plantilla para registrarlas. No obstante, no siempre se registran adecuadamente y con frecuencia acaban en el trocito de papel del traductor que espera que, antes de que termine su traductor, averigüe algo que haga innecesaria la consulta.

En OpenTranslation hemos pensado varias veces en crear una herramienta que facilitase el registro de incidencias, pero nuestros prototipos han tenido escaso éxito, probablemente por el mismo motivo que tampoco lo tienen las plantillas de dudas. A nadie le gusta rellenar un extenso formulario (muchas veces con cerca de diez campos) para una duda que al final ni siquiera se enviará. Aunque se trate de datos sencillos (como la fecha, el nombre del archivo o el texto de origen), supone una pérdida de valioso tiempo y, además, interrumpe el flujo de traducción.

Parte del encanto de anotar una duda en un papel es su inmediatez. Basta con escribir un par de palabras para que al día siguiente sepamos rápidamente lo que nos motivó a escribirla. A partir de esta idea, hemos diseñado una nueva herramienta para gestionar las incidencias, término que hemos elegido para llamar a los motivos por los que solemos anotar algo en el papel.

La novedad es que el proceso es extremadamente rápido. Abrimos un cuadro de diálogo, pulsamos un botón y con solo escribir las pocas palabras que necesitamos hemos terminado. El resto de los datos se toman de forma automática. Si lo deseamos, podemos indicar la naturaleza exacta de la incidencia, entre las siguientes:
  • Duda de traducción
  • Referencia no encontrada
  • Solicitud de aclaración
  • Error en el texto de origen
  • Nota para revisión
No obstante, ni siquiera es necesario, ya que la opción por defecto «Duda de traducción» es suficientemente genérica como para abarcar cualquier motivo que nos dude a apuntarla.

Por supuesto, si nuestra herramienta se limitase a registrar las palabras, no nos sería mucho más útil que un trozo de papel pero, gracias a la magia de la informática, petraREV es capaz de combinar la escasa información que le hemos indicado para crear un informe completo.

Por ejemplo, sin contexto, podemos generar el siguiente informe:


No es muy completo, pero no está mal. Sin embargo, si lo combinamos con una traducción, resulta mucho más útil.





Con esta base, crear un informe que pueda enviarse directamente al cliente es cuestión de segundos. ¡Y si tenemos algo que comentar al revisor, la lista de notas para el revisor nos ayudará a asegurarnos de que no se nos olvida nada!

Estas son las funciones que hay por el momento. Actualmente trabajamos en que resulte mucho más útil sin sacrificar comodidad. Dentro de poco podremos cambiar el estado, realizar búsquedas y filtrar nuestras dudas.

¿Tenéis vosotros también un trozo de papel al lado de tu teclado? ¿Creéis que las categorías que hemos creado son suficientes o faltan? ¿Qué funciones os gustaría que tuviera esta nueva herramienta? Estamos esperando conocer vuestras ideas para que la próxima versión de petraREV sea mejor que nunca.

lunes, 11 de enero de 2016

¡Llega la nueva aplicación de OpenTranslation, petraSearch!

A principios de diciembre ya comentamos que estábamos trabajando en una nueva aplicación para buscar texto en archivos que, a partir de hoy, es posible descargar de manera totalmente gratuita desde http://www.opentranslation.es/petrasearch/.


El funcionamiento de petraSearch es extremadamente sencillo: basta con escribir el texto que queremos buscar en el primer cuadro de texto, la ubicación donde queremos buscarla en el segundo y pulsar Search. Tras unos segundos, aparecerán los resultados.

También hay un cuadro de diálogo de configuración donde podemos cambiar el tamaño del texto de los resultados o elegir que se muestre un resumen después de los resultados.

Al igual que ocurre con  todos nuestros nuevos proyectos, estamos deseando mimarlo, por lo que cualquier sugerencia que hagáis, bien a través de este blog o escribiendo a la dirección normal de OpenTranslation será más que bienvenida. ¡Esperamos vuestros comentarios!

viernes, 8 de enero de 2016

petraREV: Nuevo año, nuevas reglas gramaticales

La función de comprobación de reglas gramaticales es una de las primeras que incluyó petraREV y apenas ha cambiado con el paso de los años. En un principio, estaba pensada para que el usuario pudiera crear sus propias reglas gramaticales adaptadas a los proyectos que trabajaba. Por ejemplo, esta función le permitía vetar el uso de verbos en segunda persona en un proyecto y permitirlos en otro.

La realidad terminó siendo muy distinta. Tras un cierto esfuerzo inicial en el que se crearon unas cuantas reglas gramaticales prácticas de aplicación general, estas reglas se fosilizaron y, durante la última década, el archivo que define las reglas se ha mantenido prácticamente tal como se creó.

Tampoco es de extrañar que apenas hayan cambiado estas reglas. Para editarlas hay que conocer la notación gramatical que emplean estas reglas y, por si fuera poco, es preciso editar el archivo a mano en un editor de texto o, lo que es todavía peor, crearlas a partir de cero. Hay que tener en cuenta que, cuando se comenzó a crear petraREV, se dio más importancia al número de funciones que se incorporaban que a la facilidad con la que podía configurarse. A fin de cuentas, si a un usuario normal, no le resultaba excesivamente fácil crear o modificar estas reglas, no parecía tener mucho sentido dedicar el esfuerzo a ofrecerle una posibilidad que, de todas maneras, rara vez utilizaría.

Por este motivo, el editor de reglas gramaticales ha estado largo tiempo en la lista de tareas pendientes hasta que finalmente, hemos decidido prestarle la atención que requería, principalmente porque hemos visto que para determinados tipos de texto, es conveniente modificar o (por lo menos) eliminar con facilidad algunas reglas, por lo que queríamos ofrecer al usuario una manera elegante y cómoda de hacerlo.

El plan inicial era sencillamente crear un editor específicamente creado para editar estas reglas. No obstante, algo fallaba en esta idea. A los usuarios no suele gustarles la proliferación de cuadros de diálogo y crear uno más, de un uso tan limitado, no parecía lo más adecuado. Tal vez en esta sensación de que este editor era un tanto innecesario radique la causa por la que durante tanto tiempo no se ha hecho.

Tras reflexionar durante bastante tiempo, hemos encontrado finalmente una solución satisfactoria. Efectivamente, no era necesario un cuadro de diálogo más, porque ya hay un cuadro de diálogo que cumple una función bastante similar: el editor de la memoria de revisión. Aunque su función sea ligeramente diferente, en realidad el objetivo es el mismo, comprobar una serie de reglas y el hecho de que unas se basen en condiciones gramaticales y otras únicamente en la aparición o no de un texto concreto no es tan relevante. De hecho, ofrece la posibilidad de crear reglas gramaticales específicas para un proyecto, sin tener que almacenar la información en dos archivos diferentes.

Por tanto, una vez que hemos tenido las ideas claras, ha sido sorprendentemente fácil actualizar el formato de la memoria de revisión. El único cambio visible es la incorporación de un cuadro combinado que permite elegir si una determinada condición es de texto o gramatical.






Claro que, como suele ocurrir con las actualizaciones, este cambio, nos ha sugerido muchas modificaciones. Por ejemplo, el formato XML de la memoria de revisión nos resulta ahora un tanto obsoleto y debería traducirse al inglés. Por otra parte, la función de comprobación de reglas gramaticales ha dejado de tener sentido y tal vez sería conveniente declararla obsoleta. Además, si realmente queremos facilitar la creación de reglas gramaticales, habría que incluir el asistente para editar estas condiciones... y es que ya se sabe, cuando te pones a renovar, sabes cuando empiezas, pero no cuando acabas.