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.



lunes, 7 de diciembre de 2015

Herramientas de búsqueda de textos en archivos: la navaja suiza de cualquier traductor

Si tuviera que elegir una única aplicación para redactar una traducción, excluyendo por supuesto las que incluye cualquier sistema operativo, curiosamente la aplicación que elegiría no sería una aplicación específicamente diseñada para la traducción, pues escogería una aplicación que me permitiese hacer búsquedas en un conjunto de archivos de texto.

En los años que llevo traduciendo, este tipo de herramientas ha demostrado ser las más versátiles y, aunque el trabajo me obliga a pasar de una herramienta de traducción a otra y a recurrir a todo tipo de diccionarios, esta pequeña pero útil herramienta ha demostrado ser de las más útiles y versátiles.

En principio, parecería que la función que ofrecen estas herramientas debería proporcionarla cualquier sistema de memorias de traducción, pero desgraciadamente no es así. El problema es que las memorias de traducción parecen estar diseñadas principalmente para encontrar el segmento más similar al que estás buscando. Por ejemplo, si buscas el segmento «The monitor displays a yellow screen.» te mostrarán con suerte segmentos como «The monitor displays a red screen.» y hay que reconocer que hacen un buen trabajo en este sentido.

El problema radica en que cuando no buscas un segmento, sino un término sino una expresión utilizan el mismo algoritmo y, en este caso, los resultados no son tan buenos por diversos motivos:

La búsqueda no resulta tan precisa. Al buscar términos cortos puede interesarnos emplear opciones como «Coincidir mayúsculas y minúsculas» o «Coincidir palabras completas» que las memorias de traducción no incluyen.
No es posible establecer un orden de prioridades. Con frecuencia, disponemos de varios materiales con diversos niveles de prioridad. Por ejemplo, una memoria de traducción puede estar aprobada por el cliente y la otra puede ser una memoria de menor fiabilidad, pero más completa. Los algoritmos de las memorias de traducción suelen priorizar los resultados únicamente por grado de concordancia, lo que puede hacer que se nos pasen por alto resultados que tienen una mayor prioridad.
Solo admiten un documentos bilingües. Es fácil convertir cualquier documento bilingüe en una memoria de traducción, pero con frecuencia disponemos de otros tipos de materiales como, por ejemplo, consultas al cliente o textos monolingües, lo que obliga a realizar búsquedas en varias herramientas, con la consiguiente pérdida de tiempo.

En general,  ordenar los materiales en carpetas por prioridad y realizar búsquedas con una herramienta de búsqueda de texto suele ser el método más eficaz y eficiente de consultar la referencia de una traducción. Durante muchos años he utilizado una herramienta para este fin, pero dado que se trata de una herramienta desarrollado para un sistema operativo concreto su aplicación es limitada. Además, en ciertas ocasiones es fácil pensar que una herramienta diseñada específicamente para la traducción podría ser más útil.

De esta manera, ha surgido la idea de potenciar esta herramienta, aunque para ello hay que comenzar construyendo un prototipo capaz de ofrecer la funcionalidad básica. Con este fin ha surgido OpenTextSearch, que en estos momentos es poco más que proyecto de fin de semana. Aún así, ya es capaz de buscar en carpetas y presentar los resultados de una manera suficientemente clara, como podéis ver en la siguiente captura:



No obstante, esto es solo el principio. Conforme el proyecto avance, podremos incorporarle cada vez características más interesantes que harán que el trabajo de cualquier traductor sea más cómodo y productivo. Si quieres participar con ideas o te interesa probar la versión alfa, ¡no dudes en ponerte en contacto con nosotros»

lunes, 2 de noviembre de 2015

petraREV: Tirando del hilo de la madeja de las repeticiones

Muchos novelistas han comentado alguna vez que uno de los aspectos más apasionantes de escribir una historia es descubrir como se desarrolla, lo que muchas veces resulta una sorpresa para ellos mismos, a pesar del evidente control que tienen sobre ella. Al programar a veces ocurre algo parecido. Comienzas a escribir un método y, conforme vas tecleando aparecen de forma mágica el programa comienza a adquirir como por arte de magia funciones en que no eran las que tenías pensadas cuando te sentaste a escribir el código.

Algo parecido me ha ocurrido con la última función que he incorporado a petraREV y que tuvo su origen en una idea muy sencilla: la comprobación de coherencia, una de las primeras funciones de esta herramienta. Esta función es una de las más prácticas y, desde hace mucho, funciona de manera muy estable. No obstante, cuando revisaba con petraREV archivos en los que sabía que había muchas repeticiones y petraREV me decía escuetamente que no había ningún problema, no me sentía satisfecho con esta respuesta. ¿Había muchas repeticiones y todas estaban bien o, por algún motivo, no había problemas porque sencillamente no había repeticiones? Ningún número de la línea de resultados me informaba de ello, así que me decidí a incluir un pequeño número que me informara sencillamente del número de repeticiones que sí que habían coincidido.

Mi idea era incluir este número directamente en la rutina de comprobación de coherencia. Bastaba probablemente con dar visibilidad a algún cálculo interno para lograr la información que necesitaba. No obstante, al releer la rutina me di cuenta de que el dato que buscaba no era tan obvio y, ahora que me detenía a pensar en ello, me daba cuenta de que ni siquiera sabía exactamente lo que quería. ¿Importaban solo las repeticiones globales o era preferible desglosarlas por archivos? ¿Tal vez era una oportunidad para estudiar la distribución de repeticiones por archivos?

Con todas estas consideraciones, era evidente que no bastaba con añadir un pequeño número al informe, así que comencé a escribir una nueva función, la número 84, para analizar las repeticiones. Decidí que la manera más completa de mostrar la información era indicar el número de segmentos que no se repiten en ningún otro sitio, las repeticiones dentro del propio archivo y las de los otros archivos. Tras unas cuantas líneas obtuve los datos deseados, pero la información mostrada en una tabla parecía poco intuitiva. Leer que un archivo tiene 17 segmentos nuevos, 5 repeticiones internas y 3 repeticiones externas no permite extraer ninguna conclusión rápida. Es posible convertir estas cifras al porcentajes, es decir, 68%, 20% y 12% respectivamente, pero sigue habiendo que detenerse unos momentos a analizar estos datos.

Por tanto, decidí construir un nuevo objeto gráfico que mostrase estos datos como porcentajes de una barra en varios colores. A la derecha, las palabras nuevas, luego las repeticiones internas y por último las externas. El resultado era mucho mejor, pero seguía sin aclararse una incógnita sobre esas repeticiones externas. ¿Estaban distribuidas en muchos archivos o en pocos? Y, aún más importantes, ¿había problemas de coherencia en estas repeticiones o no?

No parecía que el gráfico o la tabla pudiera incluir esta información sin convertirlo en un galimatías, así que le añadí a la función una opción de mostrar detalles de la repeticiones en los que, para cada archivo, se mostraría el número de segmentos repetidos que había y también los problemas de coherencia que planteaban. El objeto gráfico para crear barras de colores estaba ya creado así que decidí utilizarlo para mostrar una comparación entre los segmentos coincidentes y los no coincidentes. En este caso, los colores por defecto del gráfico no parecían adecuados (ni el azul oscuro ni el azul oscuro indican dónde está el problema), así que modifiqué la biblioteca gráfica para mostrar unos verde y rojo mucho más reveladores (¿a que en este caso ya no hace falta que diga qué color indica el error?).

Ahora podía ver claramente el efecto sobre los demás archivos que tenían las repeticiones de un archivo, pero ver una columna de barras del mismo ancho podía inducir a error, porque sugería que todos los archivos eran igualmente similares al que se estaba analizando. ¿No sería preferible que el ancho de la barra fuera proporcional al número de segmentos repetidos presentes? Y, puestos a pedir, ¿no deberían aparecer en primer lugar los archivos en los que el número de repeticiones era mayor? Dicho y hecho, aunque para ello tuve que modificar una vez más el objeto gráfico y presentar los datos de otra manera, aparte de crear una nueva opción de configuración para que las rutas se pudieran reducir a la mínima longitud necesaria.

El resultado podéis verlo debajo y creo que ilustra de manera bastante directa cómo se reparten los segmentos repetidos de un conjunto de segmentos, pero desde luego si os resulta críptico os agradecería enormemente que me pusieseis los pies en la tierra:


Desde luego no pienso que la rutina esté completamente terminada. A fin de cuentas, falta traducirla al inglés y documentarla, aparte de que algunas mejoras siguen rondando mi cabeza. Por ejemplo, tal vez los archivos deberían aparecer ordenados por número de segmentos repetidos en lugar de por el orden en que se cargaron. Igualmente, tal vez la longitud de la barra que distingue entre repeticiones coincidentes y no coincidentes debería ser proporcional para todos los archivos (ahora es proporcional para cada archivo). Y desde luego, los números deberían aparecer alineados a la derecha. Aún así, son ya mejoras que no tengo tan claras. Siempre que hay que plantearse si una idea constituye una oportunidad o una distracción y ya no lo tengo tan claro sobre estas nuevas ideas.

A fin de cuentas, lo que empezó siendo un pequeño número, se ha convertido en una nueva función, un nuevo objeto gráfico estadístico y hasta una nueva opción de configuración que tal vez pronto afecte a gran parte de los resultados que presenta petraREV y, desde luego, cuando comencé a programar no tenía ni idea que iba a descubrir esta historia.

domingo, 30 de agosto de 2015

petraTAG: Nueva versión con listas, por ejemplo, de rubios, morenos y calvos

Acabamos de lanzar la nueva versión de petraTAG, que puedes descargar de manera completamente gratuita desde http://www.opentranslation.es/petratag/instalacion.htm.

Esta versión incluye dos grandes novedades. La primera, ya comentada en este blog, es la posibilidad de guardar textos etiquetados, por lo que si sueles trabajar con los mismos textos, solo tendrás que etiquetarlos una vez, guardarlos y ¡ya está! Cada vez que los cargues, se cargarán también las etiquetas, por lo que no tendrás que desperdiciar el tiempo en etiquetarlos.

La segunda novedad consiste en la incorporación de una función de listas de lemas al asistente de secuencias. Por ejemplo, imagina que quieres estudiar el uso de determinados adjetivos en un texto. Antes hubieras tenido que buscar cada adjetivo y sumar manualmente los resultados, pero ahora puedes buscar de una vez todos los adjetivos que quieras y obtener automáticamente los resultados.

Pero probablemente sea verlo con un ejemplo práctico, así que vamos a ver cómo utilizan autores de diferentes países los adjetivos de color del pelo «moreno»,  «rubio» y «calvo». Nuestra tesis, un poco extravagante, es que los autores norteamericanos tienden a utilizar más el «rubio» y los latinos el «moreno».

Para ello, basta con abrir la pantalla de búsqueda, elegir la pestaña «Buscar secuencia» y hacer clic en el botón «Buscar». En el asistente que aparecerá veremos tres botones con puntos suspensivos, como vemos en la siguiente ilustración:

Estos botones permiten acceder a la pantalla de listas, donde podemos elegir la lista que nos interese. La principal utilidad de esta lista es ofrecernos un lugar cómodo donde almacenar listas, especialmente cuando sean listas que utilizamos con frecuencia o son particularmente listas. Las listas predeterminadas son las siguientes:

Para los fines de nuestro estudio, elegimos la lista «calvo,moreno,rubio» haciendo doble clic en ella. Volveremos al asistente para secuencias, donde deberemos elegir que la palabra buscada sea un nombre, de manera que quede de la siguiente manera:


¡OJO! No es necesario utilizar la pantalla de listas para indicar una lista. También podemos indicar todos los elementos que nos interesan sencillamente separándolos con una coma sin espacio. Por ejemplo, podemos escribir «calvo,moreno,rubio», «rojo,verde,azul», «alegre,contento,enfadado,triste» o lo que queramos. La pantalla de lista solo es una manera cómoda de reutilizar las listas.

¡Ya queda muy poco! Eligiendo «Aceptar» volveremos a la pantalla de búsqueda. Para que sea más fácil interpretar los resultados, elegimos que se nos muestre la distribución y que sea del lema 0 (es decir, la palabra que estamos buscando). El resultado, debe ser el siguiente:

¡Ya solo queda comenzar a cargar textos y poner a prueba nuestra tesis! Nosotros hemos encontrado lo siguiente:

Matilde Asensi - El origen perdido (5 morenos, 4 rubios, 4 calvos)
Rosa Montero - La hija del caníbal (8 morenos, 5 rubios, 4 calvos)

Stephanie Meyer - Crepúsculo (3 morenos, 11 rubios, 1 calvo)
E. L. James - Cincuenta sombras de Grey (2 morenos, 30 rubios, 0 calvos)

¡Y los resultados sorprendentemente parecen avalar nuestra tesis! ¿Pero y si hubiéramos considerado también las tonalidades pelirroja y castaña? Además, los libros que hemos elegido son bastante recientes, ¿habrá crecido o disminuido la presencia de rubios en la literatura con el tiempo? ¿Predominarán en la literatura romántica o en el terror? Ahora con petraTAG realizar cualquiera de estos estudios, o incluso uno que realmente merezca la pena, es más fácil que nunca.

Si tienes cualquier duda respecto al uso de esta función, no dudes en escribirnos y estaremos encantados de ayudarte.