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.