lunes, 15 de diciembre de 2008

Amor y odio entre traductores y LSP

Tenía esta entrada a medias desde agosto, pero, como antes ha salido el tema de los traductores y las agencias, he pensado acabarla.

El otro día estaba perdiendo el tiempo documentándome y me encontré con una especie de decálogo del buen gestor de proyectos (PM). Buscando, he encontrado otros enlaces muy interesantes sobre la relación entre LSPs (agencias) y traductores.

Yndigo: The misunderstood translation project manager (varios enlaces)
Masked Translator: Translation Agency Spam

En mi empresa soy un PM para clientes finales, pero también para intermediarios (otros LSP más grandes), así que esto me toca muy de cerca. Leo algunas de las malas prácticas y no me queda más remedio que sonrojarme porque me veo muy identificado, pero con otras estoy totalmente de acuerdo, porque me pasa a mí también. Cuando participo en una de estas malas prácticas, es más por impotencia frente al cliente que por falta de capacidad.

Por ejemplo, los correos masivos con destinatarios ocultos. Si se trata de información de un cliente para tener en cuenta para el futuro, me parece bien. Pero al cliente que se acuerda de mí un par de veces al mes para ofrecerme basura, al final acabo ignorándolo. Total, cuando le escribo para confirmarle nuestra disponibilidad, me sale con que ya se lo ha dado a otro. Es como el cuento de Pedro y el lobo, que al final nadie le contesta y se lo come el cliente.

La relación entre el traductor y la LSP es, en el 90% de los casos, de amor-odio. Tú no me gustas, yo no te gusto, pero nos necesitamos el uno al otro, así que vamos a llevarnos bien. Como dice mi santa madre, los amigos se eligen, pero la familia no. Corolario de un servidor: las relaciones laborales tampoco se eligen.

Lo que no quita que muchas LSP deberían mejorar su política de RRHH. O, al menos, tener una. Las LSP son el intermediario entre el cliente final y el traductor: y ser intermediario significa filtrar las exigencias, en ocasiones absurdas, de los señores clientes. A un PM no le gusta que le toque las narices un cliente, por lo que debería intentar no tocárselas a un proveedor.

Claro que todo esto es más fácil decirlo que hacerlo cuando tienes al cliente resoplándote en el cogote; más rápido, mejor, más barato. En el trabajo, como en la vida, hay que llegar a compromisos e intentar hacerlo cada día un poco mejor. Basándonos en el decálogo de The Masked Translator, por ejemplo.

domingo, 14 de diciembre de 2008

Mover montañas y mover personas (tecnificación y RRHH)

Los gurús de la autoría de texto inventaron el XML para poder intercambiar datos de cualquier formato con facilidad. Los gurús de la traducción inventaron el XLIFF para poder intercambiar datos multilingües fácilmente. Y luego llega esta santa industria y usa formatos privativos para el intercambio de texto (Word - DOC) y para la traducción (Trados - TTX). ¡Olé, morena!

A menudo quiero emplear la herramienta x con el trabajo y, pero resulta que pocos traductores usan esa herramienta. El método más sencillo y tradicional es convertir los documentos a un formato estándar "pivot". En teoría, el estándar es el XLIFF, pero en la práctica es el TTX de Trados. Por ejemplo, un cliente insiste en usar SDLx, pero nos hace falta usar las funciones avanzadas de Swordfish, por lo que tenemos que pasar por Trados. Esto conlleva posibles peligros: las conversiones no son siempre perfectas y a menudo hay problemas a última hora.

Básicamente, hay dos métodos para vincular el trabajo X con la herramienta y:
  1. modelo "push", nadar contra corriente: encajar el trabajo X en la herramienta Y
  2. modelo "pull", nadar con la corriente: encajar la herramienta Y en el trabajo X
La opción 1 es posible mediante conversiones. Decides que quieres usar una herramienta siempre y que todo pase por ahí. Lo que ahorras por usar una herramienta, lo puedes perder con el tiempo que supone convertir los datos y los quebraderos de cabeza de una conversión fallida.

La opción 2 es posible mediante una mejor política de RRHH. Por ejemplo, SDL mantiene una lista de proveedores que a) tienen su software X en la versión Y, pero también b) tienen certificado su conocimiento de la herramienta. Así, puedes buscar gente con una herramienta específica y con conocimientos demostrables.

Por ejemplo, el software libre basa su modelo de negocio en la personalización, el soporte y la formación. Así, me parece positivo que SDL apueste por el soporte y la formación, aunque espero que su formación sea mejor que su soporte, que parece de chiste. Creo que sería rentable para un desarrollador rebajar el precio de su software y apostar por estas iniciativas como fuente principal de ingresos.

Es más sencillo el método 1, pero a largo plazo es preferible tirar del método 2. Es decir, es más fácil que Mahoma vaya a la montaña (el proveedor se ajusta al programa) que no que la montaña vaya a Mahoma (el programa se ajusta al proveedor).

Para ello, las empresas de traducción deben dejar de invertir tanto en modernización tecnológica y poner más recursos (= alguno) en reclutamiento y manutención de su personal externo. Pero esto, más que ciencia ficción, es pura fantasía.

lunes, 17 de noviembre de 2008

Llegamos a la convergencia (II)

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

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

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

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

sábado, 8 de noviembre de 2008

Llegamos a la convergencia (I)

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

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

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

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

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

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

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

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

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

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

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

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

lunes, 11 de agosto de 2008

Estándares de traducción

El mundo de la traducción no es ajeno al del resto de la informática. En teoría, un estándar de officio en documentación podría ser el OpenDocument usado por OpenOffice, o un contenedor XML cualquiera, o incluso un PDF, que ya tiene certificación ISO. Sin embargo, parafraseando a Damon Knight, un estándar es lo que digo yo (que para eso mando) que es un estándar. Así, si Microsoft utiliza por defecto el formato DOC en su suite ofimática, y todo el mundo usa MS Office, el estándar de facto es el DOC. Bueno, ahora el Open Office XML.
Algo parecido pasa con la traducción. El equivalente de Oasis es el cómite Oscar de LISA, que se encarga de preparar y promover estándares relacionados con la TAO (traducción asistida por ordenador). Así, tenemos el muy conocido estándar TMX para el intercambio de memorias de traducción, pero también otros para el intercambio de bases de datos terminológicas (TBX), reglas de segmentación (SRX) y otros. Oasis también se encarga de definir el formato de intercambio de datos de traducción, es decir, el archivo bilingüe sobre el que vamos a trabajar: el ignorado XLIFF.
Todo esto es muy bonito, pero la mayoría de profesionales que trabajan con herramientas TAO habrán oído hablar de TMX, como mucho. La mayoría sabe lo justo y necesario para trabajar con su herramienta favorita (o impuesta por el mercado). Si un traductor trabaja con Trados, entonces sabe que las TM están en formato Trados, los bilingües en formato TagEditor y los glosarios Multiterm... Bueno, la mayoría no sabe ni siquiera que Multiterm viene incluido gratis junto a Trados.
El problema es que al final manda quien más puede: los estándares de facto son los formatos con los que trabaja Trados de forma nativa. A pesar de todos sus males, Open Office XML es un formato "abierto" con el que cualquier software puede ser compatible si se lo propone. Sin embargo, los formatos nativos de Trados son privativos, es decir, son propiedad de Trados y sólo ellos saben cómo funcionan. Al final, cualquier software TAO que quiera tener presencia en el mercado debe desarrollar compatibilidad con tales formatos, pero no necesariamente con los estándares de officio.
¿Quién le hace el trabajo sucio a los desarrolladores de herramientas TAO? ¿Quién se encarga de obligar al pobre traductor autónomo a utilizar una herramienta en lugar de otra? Al cliente final, en general, le importa poco con qué herramientas trabajes, lo que le importa es que el producto salga bueno y barato. Son los departamentos de traducción y las LSP (agencias) quienes presionan para que se utilice un software y no otro. No con mala intención, sino que se pierde mucho tiempo de gestión si, en un trabajo dado, cada traductor utiliza su propia herramienta y entrega los archivos traducidos (no bilingües) y la memoria en formato TMX. El gestor a menudo necesita hacer controles de calidad y demás ritos arcanos para que las cosas salgan como tienen que salir, y las tiene que hacer en su software. Es más fácil que un traductor se amolde a cómo trabaja una agencia que que una agencia se amolde a cómo trabajan todos sus proveedores. De ahí que se tienda a una herramienta única para ahorrar costes. Como dicen los informáticos, "no es un fallo, es una función".

domingo, 17 de febrero de 2008

Programas de pago y traducción gratuita

Acabo de leer una noticia curiosa sobre la traducción gratuita y Google. Recuerdo una anécdota que me contó mi jefe sobre una megaempresa de software que no tenía presupuesto para traducir un documento técnico relacionado con su software. Los usuarios de cierto país, hartos de esperar, tomaron el PDF (disponible públicamente), lo tradujeron y lo rehicieron a la perfección, maquetación incluida. Desde entonces, al jefe de localización de esta corporación se le cae la cara de vergüenza, ya que su superior espera que los usuarios se encarguen de toda la traducción haciendo desaparecer casi por completo el presupuesto de localización. ¿Por qué he de pagar por algo que puedo tener gratis?, se pregunta el buen hombre. Lo mismo podrían decir los usuarios de su software: ¿por qué pagar por un software que puedo descargar gratuitamente desde la mula? Pues la misma gracia nos hace a los traductores su ocurrencia.
En España tenemos un dicho muy bestia, que viene muy bien al caso y que reproduzco aquí MUY suavizado: "O compartimos todos, o tiramos la señora de afecto amigable al río".

domingo, 6 de enero de 2008

La estafa del DRM (I)

Leo en MobileRead que una librería ha cerrado. Esta noticia, en principio, no tendría mucha chicha. Cierra una librería, pero todavía quedan muchas donde comprar libros en papel. Lo que pasa es que vendían libros electrónicos, no físicos, y han dejado tirados a todos sus clientes con nocturnidad y alevosía.
Recapitulemos.
Los ebooks, como cualquier otra tecnología digital de medios (música, pelis, videojuegos, etc), están protegidos con anti copia. En el modelo tradicional de soportes físicos (CDs de Audio, DVDs y ciertas plataformas de juego), esto no suponía demasiado problema. Tenemos derecho a nuestra copia privada y para eso hay gente ahí fuera que, de forma más o menos desinteresada, nos proporciona la tecnología necesaria para hacer copias de seguridad. Una tras otro, las barreras impuestas al uso legítimo de nuestras compras han ido cayendo para beneficio del consumidor.
Pero entonces llegó la banda ancha y el soporte físico ya no tenía mucho sentido. Nos venden DVDs, preferimos divx o xvid. Nos venden CDs de Audio, nos quedamos con mp3 u ogg. Mientras los fabricantes meten a los estudios en una guerra sin sentido (perdonad el oxímoron) por la supremacía de un formato de Alta Definición, los usuarios optamos por el H.264. Las compañías estaban perdiendo beneficios, y eso no es aceptable.
Pero entonces, ah, no contábamos con su astusia. Llega Apple, Amazon, Microsoft o Sony y nos la clava hasta el fondo. Se sacan de la manga el DRM, la "gestión de contenidos digitales". Básicamente, cuando compras una canción o un episodio, no los compras, los licencias para ciertos usos y durante cierto tiempo.
Pongamos un libro como ejemplo. Me compro el Sony Reader, una verdadera maravilla de hardware. A través de Sony Connect (software propietario, feo, inútil y sólo para Windows), me conecto a la tienda virtual y autorizo a mi PC y a mi Reader para que puedan leer (desencriptar) los libros que pago. Sólo los dispositivos autorizados (5 como máximo) podrán leer mis libros. El caso es que pago por un libro, me lo descargo a mi PC y lo transfiero a mi Reader. El archivo está físicamente en mi poder, hasta que gana la entropía y hay pérdida de datos. No hay problema, vuelvo a autorizar los dispositivos necesarios y me descargo los libros gratuitamente tantas veces y durante tanto tiempo como quiera. En teoría no hay límite, hasta que cierra la tienda. Bueno, alguien puede decir que esto puede pasar con una tienda pequeña, pero no con una megacorporación como Sony. Pues no, porque Sony no son hermanitas de la caridad y no va a continuar un negocio que no da dinero. De hecho, esto es exactamente lo que pasará en un par de meses con la parte de Sony Connect dedicada a la música. Resultado: usuarios / clientes estafados.
Como esto está quedando demasiado largo, lo dejo aquí por el momento y otro día cuento mis ideas para un futuro sostenible de gestión de contenidos digitales.

jueves, 3 de enero de 2008

Google Desktop al rescate

La semana pasada estaba preparando un documento y, a punto de terminarlo, lo guardé en un formato incorrecto que lo hacía del todo inservible. Había pasado horas trabajando con un TXT en Microsoft Word y, al hacer un sencillo cambio y no guardarlo como DOC, me quedé con un archivo inútil.

Creía haber guardado minutos antes una versión en TXT en alguna parte de la red, así que lancé mi fiel Google Desktop por si sonaba la flauta. Lamentablemente, no era el caso, pero Google me tenía reservada una sorpresa: una versión anterior guardada automáticamente en la caché del indexador.

Se trata de una función que desconocía hasta entonces y sí está documentada. Concretamente, Google dice:

Control de versiones de archivos
Google Desktop crea copias (instantáneas) en caché de tus archivos y de otros elementos cada vez que los modificas, y almacena estas copias en el disco duro de tu equipo. Esta función permite usar Desktop para encontrar versiones anteriores de los archivos o localizar los archivos que se han eliminado por error.

En mi Ubuntu ahora mismo estoy usando Tracker, principalmente porque es software libre y Google Desktop no, pero habrá que sopesar los pros y los contras más a fondo. Total, uso la versión propietaria de Flash en lugar de la libre (Gnash) y el controlador oficial de Nvidia. Una cosa es apoyar el software libre y otra hacer el panoli.

Recuerdo cuando en 2002 hice una presentación en Documentación sobre las características "ocultas" de Google. Cuando le comenté a mis compañeros que iba a hablar de Google, me decían que vaya cara que tenía, hablando de algo que no tenía misterio alguno. Por aquel entonces sólo era un buscador, pero las opciones avanzadas de búsqueda (y su utilidad para el traductor) dieron para unos buenos 30 minutos, y porque había que irse, que si no... Al acabar, más de uno y más de dos me felicitó, como si hubiera descubierto la cuadratura del círculo. Total, como nadie se lee los manuales...