Tutorial: ¿Cómo descargar y alinear los Diarios Oficiales de la Unión Europea? (actualización)

La descarga de los Diarios Oficiales de la Unión Europea (que ya comentamos anteriormente aquí) ha cambiado. Ahora, para obtener una versión alineada con estos útiles documentos utilizando petraREV es preciso seguir estos pasos:

1. Navega hasta la página donde se encuentran los diarios:

https://data.europa.eu/data/datasets/official-journals-of-the-european-union-2021?locale=en

2. Busca el idioma que desees (por ejemplo, ES para español y EN para inglés).

3. Para descargar los archivos, elige la opción Download que aparece junto a cada idioma y aparecerá un pequeño menú con dos opciones. Elige downloadURL para descargar un archivo txt con una lista con todos los archivos.

4. Abre el archivo con un editor de texto y reemplaza todas las ocurrencias de «","» por tabuladores y pégalo en un documento de texto.

5. Crea una tabla utilizando los tabuladores como separadores. Solo nos interesa la última columna, en la que aparecen cosas como:

http://publications.europa.eu/resource/cellar/35908f2f-5089-11eb-b59f-01aa75ed71a1.0006.02/zip

6. Pega esta columna en un documento de texto y ahora sustituye la marca de párrafo por « | wget». Debería quedar una única línea muy larga similar a la siguiente:

wget http://publications.europa.eu/resource/cellar/35908f2f-5089-11eb-b59f-01aa75ed71a1.0006.02/zip | wget http://publications.europa.eu/resource/cellar/10986470-5153-11eb-b59f-01aa75ed71a1.0006.02/zip | ...

7. Abre una terminal y dirígete a la ubicación donde deseas guardar los archivos. Pega esta línea y ejecútala. Comenzarán a descargarse los archivos.

8. Cuando la descarga haya terminado, descomprime los archivos. Es posible que la extensión de los archivos no sea la correcta, así que puede renombrar los archivos para cambiarla. Para ello, la manera más fácil suele ser eliminar primero todos los puntos de los nombres de los archivos y luego utilizar el patrón Número + .zip para definir el nombre de todos los archivos.

9. Cuando estén descomprimidos todos los archivos, borra los archivos .zip y los archivos .tif. En general, solo deben quedar archivos con formato xml.

10. Repite el proceso anterior para el otro idioma que quieres alinear. Al final, debes tener una carpeta con todos los archivos del idioma de origen y otra con todos los archivos del idioma de destino.

11. Una vez que todos los archivos se encuentren en una carpeta, abre petraRev y elige Herramientas → Revisar. En la pantalla de revisión, borra todas las operaciones con Marcar todo → Quitar. Ahora, escribe Alinear lotes de archivos y haz doble clic en esta operación para añadirla a la lista de operaciones.

12. Haz doble clic ahora en esta operación para configurar esta operación. Solo tienes que indicar dónde se encuentran la carpeta con los archivos de origen y la carpeta con los archivos de destino. Si lo deseas, también puedes indicar dónde quieres que se guarden los archivos alineados.

13. Haz clic en Revisar y, después de una breve espera, se alinearán los archivos y se cargarán en la herramienta. Puedes hacer clic en Archivo → Exportar para exportar la traducción al archivo que desees.

El archivo resultante será completamente funcional, pero para agilizar las búsquedas, puede ser interesante eliminar todas las repeticiones y, en lugar de exportarlo directamente, emplear la operación Dividir traducción para obtener archivos más pequeños. Por ejemplo, si se divide en 20 archivos, los archivos tendrán unos 10 MB de tamaño, lo cual es bastante razonable.

Y, si tienes alguna duda, no dudes en compartirla en los comentarios.

Tutorial: Cómo descargar la traducción completa de Ubuntu

Al participar en la traducción un texto, poder consultar la traducción ya realizada es de vital importancia, ya que no solo nos aseguraremos que somos coherentes con la terminología ya utilizada, sino que además nos podremos avanzar más rápido al no tener que repetir las búsquedas de terminología que otros traductores ya han llevado a cabo.

Para descargar la traducción completa de Ubuntu, podemos consultar la documentación de sobre traducciones de Ubuntu, donde se nos indica que hay que seguir estos pasos:

1. Abrir la página principal de la traducción de la distribución. Por ejemplo, en el caso de Ubuntu 18.04 (Eoan Ermine) sería:
   https://translations.launchpad.net/ubuntu/eoan/
2. Elegir la opción See all language packs.
3. Descargar los paquetes completo y delta más recientes.

El archivo descargado tendrá un volumen considerable, ya que incluye todos los idiomas. Si solo nos interesa un idioma concreto, basta con descomprimirlo y eliminar todos los demás idiomas.

Para realizar las búsquedas, podemos utilizar cualquier herramienta que nos permita realizar búsquedas de texto. También podemos utilizar la página de búsqueda en traducciones de OpenTranslation o descargar petraREV, una herramienta que nos permite cargar archivos .po y realizar búsquedas avanzadas.

Búsquedas avanzadas en petraREV

Descuartizando las búsquedas

¿Habéis tenido que hacer alguna vez una traducción Frankenstein? Es decir, una traducción en la que todo el texto ya figura en la memoria de traducción del cliente y basta con unir fragmentos de aquí y allá para que el texto final conserve el estilo de la traducción ya existente.

Por cómodas que puedan parecer estas traducciones, dado que la memoria de traducción resuelve la mayoría de los problemas, en ocasiones requieren más tiempo que una traducción a partir de cero a causa de la cantidad de búsquedas que hay que hacer. Si la terminología que utiliza la memoria no coincide con la que solemos utilizar, es fácil que tomemos decisiones de terminología y estilo que luego habrá que deshacer cuando nos demos cuenta de que el cliente, por ejemplo, tiene una opinión diferente sobre cómo traducir Failed to..., lo que nos obliga a volver atrás y cambiar decenas de segmentos, dejándonos con la duda de que se nos haya pasado por alto algún caso.

La solución está en buscar todo lo que pueda plantearnos alguna duda, lo que lamentablemente reduce la productividad. En concreto, cuando hay que que traducir términos o estructuras sintácticas compuestas por bastantes palabras, aún así es fácil quedarse con la duda de si, aunque hayamos encontrado la traducción de cada elemento por separado, no habrá una traducción que combine varios elementos de una manera diferente a la que hemos supuesto. Otro caso que puede ralentizar la traducción en este tipo de traducciones es cuando tenemos que traducir una enumeración que en la memoria de traducción aparece dividida en segmentos diferentes.

Para resolver este problema hemos incluido una nueva función en petraREV: la búsqueda seccionada, que «descuartiza» el texto en palabras y luego busca las combinaciones de la mayor longitud posible. Por ilustrarlo con un ejemplo, imaginemos que buscamos en la memoria de traducción el siguiente texto:

 The user must open the Delete data screen from the lower menu bar.

Para realizar esta búsqueda, basta con acceder a la ventana de búsqueda (Control + F o Edición → Buscar) y marcar la casilla de verificación Búsqueda seccionada. Los resultados que obtendríamos serían:

Vemos que la búsqueda muestra dos segmentos muy relevantes para el texto buscado. De un solo vistazo, podemos ver que uno tiene una estructura muy similar, mientras que uno de los términos que faltan aparece en otro segmento. Además, podemos tener la seguridad de que la palabra lower no aparece en ningún segmento de la memoria de traducción en la que hemos realizado la búsqueda. Una gran cantidad de información muy resumida que nos permitirá darnos por satisfechos con la traducción sin perder el tiempo en búsquedas innecesarias, con la importante ventaja de que esta búsqueda apenas tarda más que una búsqueda ordinaria.

Al ser una nueva función, nos gustaría particularmente recibir cualquier comentario sobre ella. ¿Os parece útil? ¿Encontráis que tiene algún defecto o podría mejorarse para que fuera más cómoda? Para cualquier duda, no dudéis en poneros en contacto con nosotros.

petraREV: Versión 2.4

Acabamos de publicar la versión 2.4 de petraREV, la herramienta gratuita para revisar traducciones. Además de la ampliación de sus diccionarios las habituales mejoras y correcciones de errores, esta versión incluye un nuevo tipo de búsqueda: la búsqueda seccionada. 

Aunque próximamente dedicaremos una entrada del blog a explicar cómo se utiliza esta función, sirve para buscar las diferentes palabras que contiene un texto, con la ventaja de ser muy rápida y buscar un elevado número de combinaciones.

También hemos añadido un nuevo icono que permite acceder rápidamente la configuración, lo que resulta ideal especialmente cuando para cambiar el pretratamiento del texto. Es decir, podemos definir que se eliminen ciertos segmentos, se reemplace un texto por otro o se quiten las etiquetas sin tener que repetir estas operaciones una y otra vez.

Para probarla, solo tienes que descargarla desde la página de OpenTranslation.

Esperamos que esta nueva versión resulte útil y, para cualquier comentario, no dudéis en escribirnos.

petraREV: Llega la versión 2.3

Tras algo más de un año sin ninguna actualización, hoy acabamos de publicar la nueva versión de petraREV., que se puede descargar gratis de http://www.opentranslation.es/petrarev/descarga.htm.

Se trata de una actualización más que recomendable, dado que mejora la aplicación prácticamente en todos los aspectos, aunque tal vez la novedad más importante sea la mejora de la compatibilidad con los archivos de SDL Trados y memoQ. También es la primera versión que va más allá de la combinación de idiomas inglés→español y permite definir nuestra combinación entre los idiomas disponibles. Próximamente iremos desglosando algunas de las novedades más destacadas de esta versión.

Como siempre, nos encantaría conocer vuestra opinión sobre esta nueva versión. ¿Cuál es la función que más os ha llamado la atención? ¿Hay alguna novedad que aún echáis en falta? Para cualquier comentario, no dudéis en escribir un comentario en este blog o escribirnos directamente a nuestra dirección de correo.

petraSearch: ¡Nueva versión con un flamante modo gramatical!

La principal novedad de la versión 1.1 de petraSearch es el nuevo modo gramatical, que nos permite buscar no solo cadenas de texto, sino también secuencias de palabras con una sintaxis intuitiva y cómoda.

Para ilustrarlo con el texto de ejemplo que incluye la nueva versión de petraSearch, imaginemos que queremos saber los adjetivos que utilizó Bécquer para el sustantivo «voz» en su famosa obra «El monte de las ánimas». Solo tenemos que activar el modo gramatical pulsando el botón «G» y escribir en el cuadro de búsqueda:

voz -a%

Nos aparecerán todas las veces que aparece el sustantivo «voz» seguido de un adjetivo y, además, también veremos al final una lista con todos estos adjetivos ordenados por frecuencia:

Aparte de su utilidad para realizar estudios de estilo, esta función también resulta muy práctica cuando estamos redactando un texto y no conseguimos encontrar una palabra concreta. Por ejemplo, ¿queremos añadir un adverbio al verbo «creer» y no encontramos el que nos guste? Solo hay que activar el modo gramatical, escribir «creer -r%» y veremos una lista de los adverbios que se utilizan en los textos que nos interesan. En este sentido, esta función viene a ofrecer un diccionario de colocaciones, solo que dinámico y específico de los textos que decidamos.

Pero, ¿cómo funciona esta sintaxis? Tan solo tenemos que escribir las palabras que queremos buscar separándolas por espacios. Si en un lugar de una palabra concreta queremos especificar una categoría gramatical, basta con escribir un guión seguido de una letra para identificar la categoría en cuestión:

-v (verbo), -n (nombre), -a (adjetivo), -r (adverbio), -s (preposición), -d (determinante), etc.

Para ver la lista completa de categorías gramaticales, puedes consultar la descripción completa en la ayuda de petraREV.

Si no indicamos que queremos buscar una palabra literalmente, se buscarán todas sus posibles formas. Por ejemplo, para «decir», se buscará «digo», «dices», «dices», «decimos», etc. Para indicar que queremos buscar una única forma de una palabra, hay que precederla con un signo igual. Por ejemplo:

=dije

Busca únicamente aquellos casos en los que aparece la palabra «dije». Por tanto, es importante escribir la forma canónica de una palabra cuando queramos buscar todas sus posibles formas. Es decir, infinitivo para los verbos, singular para los nombres, etc.

Cuando queramos aceptar cualquier palabra, solo hay que escribir un punto. Por ejemplo:

noche . -a

Admite tanto «noche tan bonita» como «noche más hermosa».

Por último, cuando queramos realizar un análisis rápido de frecuencia solo tenemos que añadir un % a la palabra que nos interesa. Por ejemplo:

noche . -a%

Realiza un análisis de la frecuencia con la que aparecen los adjetivos según este patrón, pero:

noche .% -a

Realiza un análisis de la frecuencia de las palabras que aparecen entre «noche» y un adjetivo.

Dado que es la primera vez que incorporamos esta función, nos encantaría saber qué os parece y si se os ocurren mejoras que podrían mejorar su utilidad. ¡Esperamos vuestros comentarios!

petraREV: Cómo crear una planificación de archivos a partir de un recuento

Aparte de las funciones para revisar traducciones, petraREV también incluye varias opciones para facilitar el trabajo de traducción. Por ejemplo, al traducir un proyecto, particularmente si se trata de uno extenso o con muchos archivos, es muy útil saber en todo momento en qué punto del proyecto estamos, es decir, cuánto hemos traducido o revisado ya y cuánto nos queda todavía pendiente. Todos los programas de traducción incorporan funciones que nos ofrecen esta información, pero con frecuencia cometen errores o son demasiado lentos. Por ejemplo, muchas veces los problemas con las penalizaciones hacen que lo que debería aparecer como texto 100% traducido se contabilice como texto al 99%, lo que puede darnos algún susto. Además, las planificaciones también son útiles para repartir el trabajo entre varios traductores o programarnos el tiempo que vamos a dedicar al proyecto.

Pero, ¿qué es una planificación? Se trata sencillamente de una hoja de cálculo donde aparece junto al nombre de cada archivo el número de palabras de cada tipo que tiene. Por ejemplo, el siguiente corresponde al recuento de un proyecto ficticio:

Gracias a las funciones de las hojas de cálculo, podemos hacemos un montón de operaciones con el recuento, como por ejemplo, dar prioridad a los archivos más pequeños o a lo más grandes y, sobre todo, asegurarnos rápidamente de que el volumen del trabajo que estamos a punto de comenzar coincide con el que nos han asignado.

Crear un recuento de este tipo con petraREV es muy fácil, basta con abrir la aplicación o, si no la hemos descargado todavía, conseguirla de manera gratuita de http://www.opentranslation.es/petrarev/descarga.htm.

Una vez abierta, basta con elegir Herramientas → Gestión de proyectos o, si preferimos usar el teclado, pulsar Control + O. Aparecerá el siguiente cuadro de diálogo:

Ahora debemos elegir en el cuadro de texto Archivo de recuento la ruta donde está el archivo con el recuento que hemos creado con nuestro programa de traducción asistida. Si queremos guardar el recuento, también tendremos que elegir en el cuadro de texto Archivo de plan, la ruta donde queremos que lo guarde.

Una vez especificada esta información, solo queda hacer clic en Convertir y habremos generado una completa planificación.

Una última nota, aparte de guardar el plan donde le hemos indicado, también se mostrará siempre el recuento en pantalla, de una manera similar a la siguiente:

Si preferimos este formato o tenemos cualquier problema al generar el archivo, también podemos copiar y pegar esta tabla, ya sea en una hoja de cálculo o en un procesador de textos.

Por el momento, solo se admiten esta función solo es compatible con los recuentos de algunas herramientas, pero si necesitáis algún formato en concreto, podéis escribirnos para contarnos los formatos que necesitáis.

Ya disponible la biblioteca Java del etiquetador morfosintático petraTAG

Hace ya bastante tiempo que está disponible la aplicación petraTAG, que además de permitir realizar el etiquetado morfosintáctico de cualquier texto en español, también incluye numerosas herramientas para analizar los resultados del etiquetado, pero... ¿qué ocurre cuando queremos integrar un etiquetado eficaz en nuestra propia aplicación?

Para facilitar la integración del motor de etiquetado de petraTAG en cualquier proyecto, acabamos de lanzar en nuestra web la primera versión abierta del motor de etiquetado. Para descargarla, solo tenemos que dirigirnos a la página de la API de la ayuda en línea de petraTAG y descargar el archivo petraTAG-API1.0.zip, que contiene la biblioteca y todos los archivos necesarios para etiquetar un texto en español o inglés.

Vamos a ver cómo utilizar esta biblioteca con un ejemplo muy sencillo que desarrollaremos en Netbeans. Para crear el proyecto, solo tenemos que elegir File → New Project. En el cuadro de diálogo que aparecerá, elegimos Java → Java Application. Un nuevo cuadro de diálogo nos pedirá que elijamos el nombre del proyecto y la carpeta donde se guardará. En nuestro caso, vamos a elegir como nombre del proyecto petraTAGdemo.

Ahora tenemos que vincular nuestra biblioteca así que, en el árbol del proyecto que aparece a la izquierda, nos situamos encima del proyecto que acabamos de crear y elegimos Properties. Nos vamos ahora a la categoría Libraries y agregamos los dos archivos jar que contiene el zip: Utiles.jar y petraTAG.jar.

¡Ya queda muy poco! Solo tenemos que copiar la carpeta languages que hemos descargado anteriormente en el directorio raíz del proyecto que hemos creado y podremos comenzar a crear a escribir el código de nuestra aplicación. Para comprobar que funciona, podemos escribir lo siguiente:

package petratagdemo;

import petratag.TaggedSentence;
import petratag.Language;

public class PetraTAGdemo {

    public static void main(String[] args) {
        Language language=new Language();       
        language.init("ES");
       
        String text="Este texto es un ejemplo.";
        TaggedSentence sentence=new TaggedSentence();
        sentence.tag(text, language);
       
        for (int n=1;n<=sentence.length;n++) {
            System.out.println(sentence.tokens[n]+" - "+sentence.lemmas[n]+" - "+sentence.posTags[n]);
        }
    }
}

Si lo ejecutamos, deberíamos obtener el siguiente resultado:

- Loaded 271681 dictionary entries and 60 locutions.
Este - este - dd0ms0
texto - texto - ncms000
es - ser - vsip3s0
un - uno - di0ms0
ejemplo - ejemplo - ncms000
. - . - Fp

Pero, ¿cómo funciona? Vamos a ver paso a paso este pequeño programa para ver cómo se etiqueta el texto.

Comencemos con:

        Language language=new Language();       
        language.init("ES");

Para etiquetar un texto, debemos definir un idioma que creamos aquí con la primera línea. La segunda línea carga los datos necesarios para un idioma concreto. Actualmente, solo están disponible el español y el inglés, pero sería fácil crear otros idiomas. Solo es necesario cargar un idioma una vez y, si no queremos etiquetar en varios idiomas, basta con definir un objeto Language, por lo que es habitual definirlo como objeto estático para toda nuestra clase.

        String text="Este texto es un ejemplo.";
        TaggedSentence sentence=new TaggedSentence();
        sentence.tag(text, language);

El objeto que contendrá los datos del etiquetado es TaggedSentence y para etiquetar el texto, solo tenemos que llamar al método tag, indicando el idioma y el texto que queremos etiquetar.

        for (int n=1;n<=sentence.length;n++) {
            System.out.println(sentence.tokens[n]+" - "+sentence.lemmas[n]+" - "+sentence.posTags[n]);
        }

Al etiquetar el texto, se han rellenado automáticamente tres matrices que incluyen todos los datos que necesitamos: los tokens (o palabras), los lemas y las etiquetas morfosintáticas, que siguen la convención establecida en el etiquetario del proyecto. Con este bucle, recorremos todos sus valores.

Aparte del etiquetado, la biblioteca incluye muchas funciones que aumentan su utilidad. No obstante, hemos optado por elegir un ejemplo sencillo que explique claramente los elementos básicos del etiquetado. Para más información, podéis consultar la página informativa sobre la clase. Próximamente, comentaremos algunas posibilidades más y, si tenéis cualquier duda, será para nosotros un placer responder a cualquier pregunta.

petraTAG: ¿Cómo extraer los diálogos de un texto?

Tras varios meses ocupados en otros proyectos, ¡ha llegado la hora de retomar petraTAG! Tenemos previstas muchas novedades muy interesantes pero, para amenizar la espera, hemos pensado que ya era hora de lanzar una nueva versión de petraTAG, así que ya podéis descargarla desde la página web de petraTAG.

Dado que actualmente estamos desarrollando diversas nuevas características, es un momento ideal para hacernos llegar vuestras ideas y sugerencias, así que no dudéis en publicar aquí un comentario o enviarnos un mensaje directamente a la dirección de la sección de contacto de nuestra página principal.

Una de las funciones que hemos mejorado es el análisis de los diálogos. La mejor manera de ilustra esta función es mediante un ejemplo, como el siguiente texto extraído de «Los cinco y el tesoro de la isla» de Enid Blyton:

Mamá movió la cabeza.
—¡Qué estupendo ponerme otra vez los shorts! —dijo Ana, bailando de contenta—. Ya estoy cansada del uniforme del colegio. Tengo enormes ganas de ir con shorts o en traje de baño y ponerme a jugar con los chicos.

En el texto anterior, hemos diferenciado mediante colores el texto clasificándolo en tres tipos:

1. Texto normal (en azul)

2. Diálogos (en verde)

3. Acotaciones de diálogos (en morado)

petraTAG puede hacer un recuento de las palabras de un texto que corresponden a cada categoría. Además, extrae los interlocutores y los ordena según el número de veces que se les cita.

Para utilizar esta función, hay que cargar y etiquetar un texto, para lo que basta con elegir Archivo → Cargar archivo. El texto se importará y se etiquetará automáticamente, para lo que es necesario esperar un poco. Cuando aparezcan las estadísticas de etiquetado, hay que elegir Herramientas → Extraer diálogos y en unos segundos obtendremos los resultados. Por ejemplo, para el libro «Los cinco y el tesoro de la isla» que antes comentábamos, obtenemos lo siguiente:

Así podemos confirmar por ejemplo, con las estadísticas en la mano, que Dick era el protagonista menos relevante. También vemos que gran parte del texto son diálogos, algo habitual en la literatura juvenil. También vemos que se indica el interlocutor en la mayoría de las ocasiones.

Para compararlas, podemos ver estas estadísticas para «Crepúsculo» de Stephanie Meyer y «También esto pasará» de Milena Busquets.

Crepúsculo (Stephanie Meyer)

También esto pasará (Milena Busquets)

Conforme vamos avanzando hacia la literatura «seria», es fácil observar que el porcentaje del total que corresponde a los diálogos es cada vez menor. Curiosamente, las acotaciones aumentan en «Crepúsculo», pero disminuyen muy pronunciadamente en «También esto pasará». Por último, también salta a la vista que en estos dos últimos libros el porcentaje de casos en los que se marca el interlocutor es muy inferior. Aún más, si tenemos en cuenta que estos dos libros se han escrito en primera persona y, por tanto, el interlocutor viene implícito con el tiempo verbal (dije, grité, susurré...). De no ser así, el porcentaje sería muy inferior.

Si tenéis alguna idea sobre cómo aplicar esta función a vuestro proyecto, no dudéis en ponernos en contacto con nosotros.

Tutorial: ¿Cómo descargar y alinear los Diarios Oficiales de la Unión Europea?

Hace no mucho, descubrí en la web un recurso que considero que puede ser tremendamente interesante para muchos traductores: los Diarios Oficiales de la Unión Europea. Al tratarse de documentos oficiales, están disponibles en varios idiomas y, por si fuera poco, la propia página ofrece la posibilidad de alinear automáticamente los textos en hasta tres idiomas, por lo que buscar un término en inglés y encontrar su equivalente en español es pan comido. Además, dada la amplia diversidad de temas tratados en el derecho europeo, es fácil encontrar términos de prácticamente todas las disciplinas. Aunque tal vez la opción que encontremos no sea óptima, al menos puede darnos una posibilidad sobre la continuar nuestras búsquedas. Para realizar la búsqueda, solo tenemos que utilizar la página o, directamente, podemos escribir en Google:

"término que queremos buscar" site:eur-lex.europa.eu

Si bien estas búsquedas en línea son muy útiles, también habrá casos en los que sea preferible realizar las búsquedas con herramientas de escritorio como, por ejemplo, la simpar herramienta gratuita de búsqueda petraSearch de OpenTranslation. Tal vez sea porque queremos comparar las frecuencias con las que ocurren varias posibilidades o quizás porque queremos realizar las búsquedas sin conexión a internet.

Sea como sea, el sitio nos permite descargar estos documentos y, una vez en nuestro disco duro, podremos alinearlos cómodamente con la última versión de petraRev. Los pasos que debemos seguir son muy sencillos:

1. Navega hasta la dirección donde se encuentran los diarios.

http://data.europa.eu/euodp/en/data/dataset?q=official+journals+of+the+european+union&organization=publ&ext_boolean=exact&sort=modified_date+desc

2. Descarga la versión correspondiente al español y al inglés.

3. Elimina, si los hay, los archivos .doc y .tif. Si hay archivos .zip, descomprímelos y elimínalos luego.

4. Copia todos los archivos a una sola carpeta con:

find "carpetaOrigen" -type f -exec mv {} "carpetaDestino" \;

5. Una vez que todos los archivos se encuentren en una carpeta, abre petraRev y elige Herramientas → Revisar. En la pantalla de revisión, borra todas las operaciones con Marcar todo → Quitar. Ahora, escribe Alinear lotes de archivos y haz doble clic en esta operación para añadirla a la lista de operaciones.

6. Haz doble clic ahora en esta operación para configurar esta operación. Solo tienes que indicar dónde se encuentran la carpeta con los archivos de origen y la carpeta con los archivos de destino. Si lo deseas, también puedes indicar dónde quieres que se guarden los archivos alineados.

7. Haz clic en Revisar y, después de una breve espera, se alinearán los archivos y se cargarán en la herramienta. Puedes hacer clic en Archivo → Exportar para exportar la traducción al archivo que desees.

Así, conseguirás tener una base de datos fenomenal donde buscar términos particularmente complicados o para los que quieras conocer una traducción oficial.

¡Un último consejo! Si alineas todos los archivos correspondientes a un año, el archivo de salida será bastante grande (entre 100 y 200 MB), por lo que puedes reducirlo, sin perder información, seleccionando Herramientas → Edición. En la pestaña Reemplazar, elige la opción Eliminar por... Repetidos y haz clic en Eliminar. Eso sí, tendrás que tener paciencia porque es fácil que el número de segmentos que deberá comprobar supere los dos millones, por lo que es fácil que tengas que esperar algo más de media hora, para conseguir los resultados. Afortunadamente, se trata de un proceso que solo hay que hacer una vez y podrás disfrutar de sus frutos durante mucho tiempo.

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.

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:

https://translations.launchpad.net/ubuntu/xenial/

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?

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.

¡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!

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.

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»

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.

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.

El demonio está en las mayúsculas

Al escribir cualquier aplicación de procesamiento del lenguaje natural, aspectos que suelen pasarse por alto en un principio acaban demostrando tener una importancia crucial. Como por ejemplo, los espacios, que con frecuencia se ignoran prácticamente, al figurar en los habituales tokens y, sin embargo, son con frecuencia la causa de cierto errores de errores muy difíciles de rastrear. O las mayúsculas, de las que bien podríamos decir que carecen de importancia hasta que se convierten en lo único importante.

Por ejemplo, en petraREV recientemente hemos tenido que replantear nuestro sistema de buscar y copiar términos para tratar de manera más inteligente el uso de las mayúsculas y minúsculas.

En principio, la estrategia que se seguía era buscar cualquier resultado, independientemente del uso de mayúsculas y minúsculas. Por ejemplo, imaginemos que buscamos el término «setup» y encontramos el siguiente resultado:

1. Setup → Configuración

La mayúscula con la que comienza el término encontrado carece en este caso de poca importancia, ya que es preferible probablemente ver este resultado, a pesar de que no sea una coincidencia perfecta, que no ver ninguno.

Esta estrategia, si bien es agradablemente general, resulta poco precisa. Por ejemplo, imaginemos que encontramos dos resultados:

1. Setup → Configuración

2. setup → configuración

En este caso, parece evidente que el resultado más interesante es el segundo, ya que no solo coincide el texto, sino también el uso de mayúsculas y minúsculas. Por tanto, resulta más útil cambiar la estrategia a buscar cualquier resultado, independientemente del uso de mayúsculas y minúsculas, pero dando prioridad a los casos en los que también coinciden mayúsculas y minúsculas.

A pesar de ser una mejora, sigue habiendo casos en los que esta estrategia no funciona de manera óptima. Por ejemplo, imaginemos que obtenemos los siguientes resultados:

 

1. Setup → instalación

2. setup → configuración

Si bien el segundo resultado sigue siendo más interesante, el primero también puede tener interés, ya que es el síntoma de una posible incoherencia terminológica que habría que estudiar. ¿Hay motivos para traducir «setup» como «instalación» o como «configuración»? ¿Cuál es la opción que se ha utilizado con mayor frecuencia en casos anteriores? ¿Es posible que haya conflictos con otros términos, como «configuration»? En cualquier caso, parece conveniente informar de esta incoherencia al usuario.

Por tanto, nuestra estrategia inicial deberá evolucionar a buscar cualquier resultado, independientemente del uso de mayúsculas y minúsculas, pero dando prioridad a los casos en los que también coinciden mayúsculas y minúsculas, pudiendo descartarse los casos en los que la única diferencia entre las opciones presentadas es el uso de mayúsculas, pero no aquellos en los que hay diferencias de caracteres.

Y si alguien piensa que estas matizaciones no son más que cuestiones teóricas sin utilidad práctica, se equivoca. La precisión de nuestro método hará que al usuario se le ofrezcan más o menos opciones, lo que incide directamente sobre el tiempo que dedica a consultar la terminología. Por tanto, menos y mejores opciones se traducen directamente en menos tiempo y más productividad. Tal como siempre se ha dicho, el demonio está en los detalles o, al menos en este caso, en las mayúsculas.

petraTAG: Llega la extensión .ttxt

El tiempo que transcurre desde que surge la idea de introducir una novedad en este proyecto hasta que el cambio termina de materializarse es tremendamente variable. Hay ideas que surgen y a los pocos días, si no a las pocas horas, ya están listas para probarlas, pero también hay ideas que van pasando una y otra vez de la lista de tareas de un año a la del año siguiente.

A diferencia de lo que se podría pensar, esta variabilidad no depende ni de la utilidad de una novedad ni de la dificultad que implica ponerla en práctica. Hay ideas que no son nada fáciles y, además, su utilidad es bastante limitada, pero sin embargo se ponen en marcha rápidamente, porque resultan muy atractivas y, en ocasiones, su propia dificultad constituye un estímulo para ponerse manos a la obra.

La novedad que abordaremos en esta entrada, sin duda, pertenece al grupo de cambios que se han aplazado una y otra vez. Prácticamente desde el principio, resultó evidente que etiquetar un texto cada vez que se cargaba era muy poco eficiente. El proceso de etiquetado es bastante lento, especialmente cuando se trata de textos muy extensos, por lo que esperar a que se realizase este proceso era tedioso y, además, tenía fácil solución: bastaba con ofrecer la posibilidad de guardar el texto con el etiquetado para que la próxima vez que se cargase el texto, tuviéramos ya el etiquetado listo desde el principio.

Precisamente esta función es la que cumple la nueva extensión que admite ahora petraTAG, la extensión .ttxt. Los archivos con esta extensión contienen ya el etiquetado del texto, por lo que se cargan en apenas un par de segundos. Para guardar un texto con este formato, basta con cargarlo, aguardar pacientemente a que finalice el etiquetado para, a continuación, seleccionar Archivo → Exportar y, tras seleccionar la ruta del archivo y el tipo de exportación Texto etiquetado, hacer clic en Exportar.  Para introducir este cambio, se han pulido también varios aspectos del funcionamiento interno de petraTAG, que ahora es más eficiente.

Aparte de la comodidad inmediata que aporta esta nueva función, también abre varias posibilidades interesantes. Por ejemplo, al ser posible guardar el etiquetado de un texto, podría ser interesante incluir un corrector de etiquetado que permitiera corregir los errores de etiquetado mediante un sistema similar a los cuadros de diálogo de corrección ortográfica que suelen incluir los procesadores de texto. Una nueva función que, tal vez, pronto incluirá petraTAG.