“Con mala escoba mal se barre”:
los problemas de la localización de productos informáticos no internacionalizados

By Itziar Bernaola, Ana Isabel Morales e Irune Payros,
Traductoras - Intérpretes,
Universidad del País Vasco, Spain

Itziar Bernaola	itziar.bernaola@ehu.es
Irune Payros	irune.payros@ehu.es
Ana I. Morales	anaisabel.morales@ehu.es
	ana_isa_morales@yahoo.com

Get the List of 4,400+ Translation Agencies Now!
No Recurring Membership Fees!

Resumen

En este artículo estudiamos los graves problemas a los que se enfrenta la traductora-localizadora¹ a la hora de traducir-localizar un producto informático mal internacionalizado. Tras definir los conceptos claves de internacionalización y localización, se hace un repaso de los mencionados problemas, haciendo uso de ejemplos reales. Se proponen tres posibles orígenes de los problemas: (1) un diseño rígido que responde a las características de una lengua concreta y no tiene en cuenta que las lenguas tienen estructuras diferentes, además de privar a la traductora del contexto, imprescindible para su trabajo; (2) la deficiente calidad de la lengua original utilizada, que trae como consecuencia textos de difícil comprensión, incoherencia terminológica y fraseológica, polisemia y sinonimia innecesarias etc.; y (3) un diseño del interfaz inadecuado y rígido, que no permite a la traductora-localizadora adaptar sus elementos a las necesidades concretas del idioma de destino.

Abstract

This paper explores some of the problems translator-localizers face when trying to translate-localize software that has not been properly internationalized. After defining the key concepts of internationalization and localization, the paper goes on to discuss, with the aid of real examples, the main causes for those problems: (1) a rigid software design that does not account for the different structures of the languages involved in the localization process, and deprives translators-localizers from the contextual information essential to their work; (2) the poor quality of the source language, resulting in obscure texts, terminological and phraseological incoherence, unnecessary polysemia and synonymia etc.; and (3) an inadequate interface design, whose inflexibility does not allow the translator-localizer to adapt the interface elements to the particular needs of the target language.

Situación 1: diálogo sabroso

A: Por favor, tradúzcame esta lista. Son los meses del año.

Situación 2: perla publicada en Internet

Asteartea, 15 de ekaina de 2006²

Introducción

Cuando el material de trabajo al que se enfrenta la traductora no es un texto corriente sino una aplicación informática, la tarea a realizar no es una traducción, sino la localización del producto. Por supuesto, esa labor incluirá la traducción de cadenas de texto, pero la localización implica mucho más que la mera traducción: consiste en adaptar el producto informático a las características y necesidades de la lengua y la cultura de destino.

Sin embargo, para que la traductora³ pueda realizar su trabajo correctamente, es decir, para que pueda localizar el producto, es imprescindible que quienes lo diseñaron, es decir, las informáticas, tengan en cuenta en la fase de diseño la labor que más tarde deberá realizar aquella, y, para ello, es necesario que internacionalicen previamente el producto en cuestión.

A decir verdad, si bien los términos internacionalización y localización surgieron en el ámbito del software, estos conceptos pueden aplicarse en cualquier ámbito. Antes de entrar en materia, vamos a explicar más detalladamente, y con la ayuda de ejemplos, en qué consisten estos dos procesos.⁴

Consiste en diseñar y fabricar un producto "neutro" fácilmente adaptable a las estructuras particulares de cada lugar (una de estas adaptaciones es la del idioma, pero no es la única, ni mucho menos). Para que un producto pueda ser utilizable en más de una lengua o cultura, es necesario que la diseñadora no lo vincule a las particularidades de un determinado lugar. Por ejemplo, no lo podrá diseñar de acuerdo con las estructuras de una lengua determinada: la configuración del producto habrá de ser genérica, independiente de cualquier idioma. Un producto bien internacionalizado tendrá una única configuración básica, que será fácilmente adaptable a las estructuras de diversas culturas y lenguas.

Para ofrecer una perspectiva más amplia que la meramente lingüística, veamos un ejemplo de Ulrich Henes (Henes 2002) relativo a la fabricación de automóviles. Cuando se diseña un vehículo se definen únicamente sus características básicas, es decir, los rasgos comunes que mantendrá en las diversas versiones de todos los lugares en que se comercialice. Dicho de otro modo: aunque el vehículo se diseñe en Alemania, si los fabricantes desean comercializarlo también en Gran Bretaña, habrán de tener en cuenta que deben dejar abierta la posibilidad de situar el volante y el resto de instrumentos en la parte derecha. Es decir, no podrán diseñar una estructura rígida dependiente de las características que el producto tendrá en Alemania. La base de la internacionalización, por tanto, es tener en cuenta las necesidades de todos los clientes potenciales desde el principio del proceso. Si se diseña un producto rígido, que responde únicamente a las necesidades de un determinado lugar, será difícil, y a veces imposible, adaptarlo a otras características distintas. En consecuencia, el producto quedará fuera de algunos mercados, o, en el mejor de los casos, se necesitará un gasto extra para poder hacer adaptaciones a posteriori (mas bien "remiendos") a ese objeto rígidamente diseñado, con lo que la producción se alargará y encarecerá.

Consiste en la adaptación de un producto a las características locales, para poder ofrecer a los clientes de cada cultura o idioma productos que no les resulten extraños o incómodos, es decir, para que sean tales como si hubieran sido creados en su propia cultura o idioma. Continuando con el ejemplo de Henes (Henes 2002), significaría colocar el volante a la derecha en el automóvil que se va a comercializar en el Reino Unido, o, por ejemplo, fabricar un vehículo que cumpla con la legislación vigente en un país determinado sobre las emisiones de CO₂ a la atmósfera.

En el caso de los productos informáticos, la localización exige, entre otras cosas, la traducción de cadenas de texto, la adaptación de los formatos de fecha, la adecuación de la longitud de las cajas de texto, la distribución de las imágenes en los lugares adecuados o la selección de las imágenes y colores apropiados a cada lugar (los tabúes y los símbolos varían de una cultura a otra; el color que en una cultura representa el luto puede significar alegría en otra), cambio de orden de los elementos etc.⁵

Es importante comprender que la internacionalización de los productos informáticos implica que el código fuente ha de programarse independientemente del idioma, lo que significa que no contendrá palabras, sino caracteres "comodín", a los que después, en la fase de localización, se les asignarán valores determinados, es decir, serán sustituidos por las palabras correspondientes de cada idioma concreto.

Veamos un ejemplo de lo que no debe hacerse.⁶ Una aplicación informática se ha diseñado tomando como punto de partida el castellano y la estructura de la fórmula para expresar la dirección postal en un formulario se ha definido así:

Si quisiéramos localizar este programa para su uso en Gran Bretaña, por ejemplo, la traductora tendría que tener en cuenta que tal fórmula no es correcta para expresar la dirección en inglés, ya que generaría resultados del tipo:

Para corregir esa estructura agramatical, la traductora debería modificar el orden de los campos. El problema es que eso no está siempre a su alcance: si el orden de los campos se ha diseñado de forma inamovible en la fase de diseño de la aplicación, la traductora únicamente podrá traducir los datos que figurarán en cada uno de los campos (en este caso calle=Street), pero la estructura que se genere será forzosamente incorrecta, ya que lo que el usuario verá en la pantalla será *Street Oxford.

Por tanto, para poder localizar los productos, es imprescindible que previamente sean internacionalizados. La localización, en realidad, comienza cuando el proceso de desarrollo del producto está terminado. Es cierto que ambas tareas, la de diseño y la de localización, pueden ir realizándose de forma paralela, pero para que se haga con éxito la gestión del proyecto ha de ser excelente y extremadamente detallada (Ottmann 2003). Ni que decir tiene que esa situación está muy lejos de la experiencia cotidiana de la mayoría de las traductoras.

Resulta evidente, pues, que un producto mal internacionalizado (o no internacionalizado en absoluto) acarreará verdaderos dolores de cabeza a la traductora. Se enfrentará a grandes obstáculos (a veces insuperables) para realizar su trabajo, y su labor tendrá un enorme coste en tiempo y energía, teniendo en cuenta, además, que por lo general el resultado dejará mucho que desear. Ottmann (Ottmann 2003) ha cuantificado las consecuencias de esos fallos de diseño en lo que se refiere a la traducción-localización:

• La traductora invierte el %10 de su tiempo en aclarar lo que no comprende del texto original.
• El %80 de los problemas que encuentra y de las consultas que ha de realizar la traductora se debe a contradicciones o imprecisiones terminológicas del original.

En este artículo nos ocuparemos de los problemas de la localización de productos informáticos, y trataremos de exponer los principales fallos de internacionalización que se cometen, en lo relativo a la lengua, en la fase de diseño de las aplicaciones. Como podrá verse, en general estos problemas se derivan de una concepción naïve del lenguaje humano y de las lenguas naturales. En el artículo proponemos una clasificación de los problemas mencionados, ilustrándolos con ejemplos reales tomados de algunos proyectos de traducción y adaptación de aplicaciones elaborados por el Servicio de Traducción de la Universidad del País Vasco.

Antes de continuar, hemos de subrayar el hecho de que con extremada frecuencia las aplicaciones informáticas se le entregan a la traductora en forma de meros listados de ítems en los cuales no pueden utilizarse memorias de traducción (así ha ocurrido la mayoría de las veces en la experiencia de quienes firman este trabajo). Dicho de otro modo: la traductora no traduce pantallas, sino listados de palabras, grupos de palabras o frases clasificadas por orden alfabético (los contenidos de bases de datos, en realidad). El rastreo necesario para saber en qué pantalla aparecerá cada ítem y combinado con qué otros elementos (es decir, la búsqueda del contexto) costará muchos sudores a la traductora, además de revelarse del todo imposible en numerosas ocasiones. En efecto, hay que recordar que estos productos suelen tener unas dimensiones gigantescas, de tal forma que la traductora se puede enfrentar a volúmenes de trabajo como 14.600 etiquetas, formadas de una o más palabras (por ejemplo, profesor asociado, validar, sí, al, del, asignatura); más de 4.300 mensajes (por ejemplo, El profesor ya tiene asignado un horario); unos 3.443.000 contenidos de tablas (contenidos correspondientes a los menús desplegables); los textos de las ayudas a las usuarias (es decir, los contenidos que aparecen al pulsar el botón de "ayuda" en el programa), los manuales de uso...

En términos generales, son tres los tipos de defectos que generan infinidad de problemas a la traductora:

1. Estructuración de los textos a traducir

Como hemos mencionado, los materiales a traducir suelen estar organizados en bases de datos. Eso significa, en primer lugar, que la traductora se verá privada de un elemento imprescindible para su trabajo, como es el contexto. Pero además, cuando el producto no está internacionalizado, existen determinados fallos estructurales en la organización de la información que hacen imposible una traducción de calidad.

1.1.- Polisemia y propagación de los términos: en ocasiones, y fruto de decisiones arbitrarias, los ítems tienen una sola entrada o registro en la base de datos, aunque después vayan a estar presentes en más de un lugar dentro de la aplicación: el término en cuestión se toma de su registro y se propaga a todos los lugares del programa en que deba aparecer. En otras palabras: si en un lugar de la aplicación aparece la palabra "banco" con el significado de 'asiento' y en otro con el significado de 'institución financiera', en la base de datos el término no figurará más que una sola vez, y la aplicación lo tomará de ahí para llevarlo a todos los lugares del programa en que deba figurar. No ha de olvidarse, por otro lado, que la traductora se enfrenta a un listado de ítems, y por tanto, en principio ignora si cada uno aparecerá en la aplicación con uno, dos o más significados. De entre los miles de ejemplos que podríamos presentar, escogeremos el de un término harto corriente en el medio universitario: la palabra "curso" tiene en vasco al menos tres traducciones, dependiendo de su significado (año académico: "curso 2005-2006"/nivel de estudios: "primer curso"/periodo de formación: "curso de francés"), y eso restringiéndonos a su uso en el contexto académico.

Cualquier persona con una mínima conciencia lingüística se dará cuenta inmediatamente del problema: por mucho que en la lengua escogida como idioma de inicio un sólo término exprese dos o más significados, eso no tiene por qué ocurrir en el idioma de destino. En consecuencia, la traductora deberá seguir el rastro al término pantalla por pantalla, para ver a qué lugares se ha propagado, deberá comprobar si en cada caso la traducción es la correcta, y en aquellos en que no lo es, tendrá que intentar arreglar el desaguisado con "remiendos" en una fase de post-edición, eso sí, avisando de ello previamente a las diseñadoras del programa (para que le permitan conservar una traducción en unos casos y otra en otros). Cuando la aplicación es de reducidas dimensiones quizá sea posible llevar a cabo este trabajoso proceso, pero cuando el programa es gigantesco la traductora no podrá controlar a cuántos lugares se ha propagado cada cadena de texto.

cuando esta estructura se alimente con los ítems contenidos en la base de datos en castellano, la frase generada aparecerá correctamente en la pantalla:

Pero, sin embargo, en vasco cuando la misma fórmula:

se alimente con los ítems en vasco almacenados en la base de datos, el sistema generará la frase siguiente:

La solución no sería traducir febrero: otsail, porque en tal caso se generarían resultados como:

Convocatoria: febrero

Deialdia: *otsail⁹

Continuando con los problemas creados por un diseño ligado a determinada tipología lingüística, hemos de mencionar los que surgen cuando ciertas características morfológicas particulares son tratadas como "universales". En castellano la morfología del sustantivo presenta marcas diferenciadas de género y número, mientras que el vasco carece de moción de género en el sintagma nominal (aunque sí lo presenta en algunas formas verbales), y la marca de número se aglutina con el sufijo de caso. Así las cosas, la traductora se verá en una difícil situación cuando se enfrente a la traducción de:

Académicos

Académicas

En efecto, en vasco tendríamos la misma traducción para ambas formas (ya que no hay género), pero, puesto que el programa obliga a la univocidad (es decir, no acepta que un ítem de origen tenga dos traducciones en la lengua de destino y viceversa), en el caso de que tradujésemos ambas etiquetas de la misma manera, el programa borraría automáticamente una de ellas junto con su traducción. Por consiguiente, cuando la etiqueta "salvada" tenga que combinarse con otras en las pantallas, se producirán, inevitablemente, errores de concordancia (por ejemplo, "méritos académicos", "*instituciones académicos").

La rigidez del programa obliga a la traductora a realizar auténticas piruetas, pues las decisiones arbitrarias (en el sentido técnico de la palabra, es decir, tomadas según la conveniencia) adoptadas desde la perspectiva de un determinado idioma, suponen un enorme desgaste y una gran pérdida de tiempo para quien traduce. Volviendo a nuestros ejemplos, la traductora puede encontrarse con que las diseñadoras han establecido una diferencia léxica arbitraria para distinguir dos conceptos. En nuestro caso, para expresar la idea de que una asignatura puede ser de las que exigen asistencia al aula o, por el contrario, puede cursarse a distancia, han seleccionado la palabra tipo (tipo: presencial/no presencial). Por otra parte, para expresar la diferencia entre asignaturas obligatorias, optativas etc., han optado por la palabra clase (clase: obligatoria/optativa...). Así pues, la traductora encontrará entradas como éstas en su listado:

A primera vista, cualquier vascohablante diría que la traducción más corriente para ambas etiquetas es mota. Ahora bien, recordemos que la estructura del programa impide asignar la misma traducción a dos etiquetas distintas. La traductora deberá armarse de su lupa de investigadora y tratar de averiguar qué idea se oculta realmente bajo cada una de estas designaciones (en su listado sólo ve los ítems "tipo" y "clase", no sabe nada más), y, no sólo eso: habrá de descubrir cuáles son las "respuestas" posibles a cada una de estas etiquetas (o sea, cuáles son los posibles "tipos" y "clases" de asignaturas). Una vez hecho esto, deberá tomar una decisión arbitraria para diferenciar también en vasco estas dos etiquetas, y tendrá que apuntar detalladamente en su cuaderno secreto de traductora cómo ha traducido (y por qué) cada una de ellas. Y es que las decisiones que adopte para ellas repercutirán en todas las demás etiquetas que contengan esos términos.

2. Calidad lingüística

Para una correcta localización del software, es fundamental que el texto original presente una calidad lingüística cuidada. Es preciso aclarar, antes de nada, que con el término calidad no nos referimos aquí a la elegancia de estilo o a las filigranas expresivas; lo que queremos decir es que a la hora de redactar el texto original deben evitarse las imprecisiones, errores, textos ininteligibles o incoherencias (entendidas como falta de homogeneidad en el texto). Y es que estos defectos acarrean infinitas consultas e investigaciones por parte de la traductora, hasta el punto de que a veces la traducción de una sola etiqueta puede llevarle numerosas horas e incluso días. Veamos algunos ejemplos de los principales problemas derivados del uso de una lengua no controlada en el texto de origen:

Ciertamente debe de ser difícil llegar a escribir algo así, pero este ejemplo -que haría ruborizarse al mismísimo André Breton con su "cadáver exquisito"- es real como la vida misma.

Tras vanas consultas en diccionarios y glosarios, y cuando la traductora había optado por hacer quinielas entre "Confederación Orgánica de Facilitadores, Responsables y Observadores Sociópatas", "Compañía Ominosa de Fraudes, Robos, Ofensas y Similares" o vaya usted a saber qué, por fin se hizo la luz: la palabra estaba mal escrita. En realidad la etiqueta debía decir Cobros, con "b" y en minúsculas.

їHay que comunicarle al departamento que una se va a conectar con él? Pero, en ese caso, debería ser al departamento, їno? їTengo que "informar el departamento"? (їEs un departamento informe?) їQué es "informar"? їQué es "conectar"?

їQué son las "descripciones de los idiomas"? їHay que describir los idiomas? Por ejemplo: "Vasco. Idioma del País Vasco. Su sistema vocálico consta de cinco vocales. En cuanto a las consonantes...". Por supuesto, no es eso lo que el mensaje quiere comunicar, sino que si se desea registrar otro idioma en el sistema, tendrá que especificarse cuál es ese idioma en el lugar apropiado del programa. Sin embargo, la traductora tendrá que hacer muchas pesquisas para poder desentrañar el misterio y hacer una traducción adecuada.

Si no se utiliza una terminología homogénea, si en el idioma de inicio no se utiliza siempre el mismo término para expresar el mismo concepto, esto puede causar confusiones y malentendidos, pues la traductora (o la usuaria) no sabrá si se han empleado términos distintos para indicar cosas diferentes o si simplemente en la fase de diseño cada programadora ha utilizado su propia terminología. Si la traductora cree que esa variedad terminológica está motivada, puede llegar a realizar traducciones forzadas y extrañas en un esfuerzo por reflejar las supuesta diferencia semántica, cuando en realidad no hay tal. Nos encontramos, pues, ante el problema de la sinonimia inmotivada, es decir, el llamar a cada cosa de más de una manera sin que haya razón para ello.

Lo mismo sucede cuando se usa la polisemia arbitraria, es decir, la polisemia resultante de una terminología no controlada. Por ejemplo, en un programa se utilizó la siguiente fórmula

con diferentes significados en diferentes puntos de la aplicación:

• En un caso para expresar el tipo de autorización (alumna, profesora...) con la que la usuaria entraba en el programa (dependiendo de su tipo de autorización tendría acceso a unos módulos y no a otros)

En castellano el texto será siempre el mismo para ambos significados, pero si la traductora ha traducido ese forma de acceso como erabiltzaile mota (literal: 'tipo de usuaria') en la suposición de que ése era su único significado en la aplicación, esta traducción no será válida para las pantallas en que la expresión tenga el otro significado. Además, como cada etiqueta tiene una sola entrada en la base de datos, por mucho que sea polisémica, para cuando la traductora se dé cuenta del desastre ya no podrá corregir todas las ocurrencias de la traducción errónea, salvo que esté dispuesta a arriesgar su cordura.

Es claro, pues, que la labor terminológica es de gran importancia en este aspecto. De acuerdo con Angelika Ottmann (Ottmann 2003) deberían tomarse en cuenta los siguientes extremos:

1. Antes de comenzar el proyecto habría que especificar y establecer la terminología en la lengua de inicio. Lo mismo habrá que hacer con las abreviaturas, puesto que el uso de abreviaturas heterogéneas puede acarrear problemas no sólo para la traductora, sino para las mismas usuarias de la aplicación. Esta tarea la deberán realizar las responsables lingüísticas (terminólogas o redactoras técnicas). El segundo paso, también previo al diseño del programa, sería determinar el término que se utilizará en el idioma de destino para cada concepto. Esta labor la realizarán las terminólogas y traductoras de la lengua de destino (un equipo bilingüe de responsables lingüísticas podría realizar ambas tareas).
2. La terminología ha de ser constantemente controlada, para verificar que se utiliza correctamente (o sea, para garantizar que se mantiene la terminología establecida al principio) en todas las fases del diseño y en todos los puntos del programa (i.e., a lo largo del tiempo y entre todos los miembros del equipo de diseño).
3. Para evitar errores ortográficos o variantes ortográficas de los términos, la terminología establecida habrá de almacenarse en una base de datos controlada y limitada, para que todas las programadoras tomen de ella todos los términos de forma automática (sin necesidad de tener que escribirlos cada vez que los necesiten). De no hacerlo así, pueden darse casos como los siguientes:

4. En la base de datos se harán los menores cambios posibles, pues estos proyectos suelen ser de gran tamaño y es muy difícil -y, por tanto, muy caro- controlar todos los cambios y la incidencia de estos en la totalidad. En cualquier caso, puede suceder que a lo largo del proyecto sea necesario efectuar alguna modificación, sea porque es necesario añadir un nuevo término, porque algún otro estaba mal definido etc. En tal caso, la modificación habrá de hacerse de forma centralizada y controlada en la lengua de inicio, y comunicárselo de inmediato a las traductoras. Un ejemplo ilustrará qué es lo que sucede cuando no se procede así.

El problema de la coherencia fraseológica es parecido al expuesto con relación a la terminología. La expresión ha de ser clara y de fácil compresión (Ўen atención también a las usuarias de la lengua original!). Un mismo concepto debe expresarse siempre de la misma manera en todos los mensajes y expresiones: antes de comenzar a diseñar el programa hay que especificar al máximo el lenguaje controlado que se utilizará en la aplicación, cada programadora o partícipe del proyecto no puede utilizar los términos y la fraseología que le parezcan (Bernaola, Morales, Payros 2003). De no hacerlo así, tanto las traductoras como las usuarias de la lengua de origen encontrarán variantes que no producirán sino confusión:

Si la lengua de origen está controlada, la traductora podrá beneficiarse de las ventajas de la memoria de traducción (con todos los riesgos, eso sí, de traducir sin contexto), pero si se hace uso de variantes arbitrarias como las que pueden leerse más arriba, la TM no le servirá de nada.

En las interfases de las aplicaciones informáticas a menudo se expresan oraciones enteras mediante elipsis de una sola palabra. Si recordamos que la traductora no ve sino una lista, entenderemos fácilmente los problemas de ambigüedad y polisemia causados por esto. Para ilustrarlo con un ejemplo, supongamos que en un lugar de la aplicación se ha utilizado la etiqueta Preinscripción (S/N) para resumir la siguiente pregunta: їHa realizado el alumno la preinscripción? Sí/No'. La traductora, teniendo esto en cuenta, ha proporcionado la siguiente traducción:

El problema es que en otro lugar de la aplicación la misma etiqueta Preinscripción figura con otro significado: aparece junto a un icono para indicar que si pulsamos ese botón el sistema nos llevará a la pantalla en la que se hace la preinscripción. Por lo tanto, en este segundo caso, la etiqueta es una elipsis de la frase 'Ir a la pantalla de preinscripción', y la traducción propuesta por la traductora no sería adecuada.

La traductora deberá saber, pues, con exactitud como se utilizará la etiqueta, para determinar cuál es la traducción que se ajusta mejor a su significado. Como hemos señalado, cuando la aplicación es de proporciones gigantescas el control de la propagación de una etiqueta es una tarea extremadamente difícil, casi imposible. En cualquier caso, el programa tampoco permitirá que la traductora dé más de una correspondencia en la lengua de destino a una misma etiqueta...

2.5.- Etiquetas y cadenas de texto desprovistas de sentido

Hemos dicho ya que, debido a la estructura del programa, la traductora se ve obligada a traducir un listado de ítems sin ningún contexto. Lo que ignora es que con frecuencia el programa combina algunos de estos ítems para formar unidades más grande (por ejemplo, combinando la etiqueta fecha de inicio, la etiqueta y y la etiqueta fecha de finalización se puede generar la etiqueta fecha de inicio y fecha de finalización). De este pequeño detalle se dará cuenta al navegar por las pantallas y, para su terror y desesperación, advertirá también otra cosa que le erizará los cabellos: que muchas veces las etiquetas no se combinan para formar unidades "autónomas" sino unidades dependientes de otras superiores, es decir, trozos de oración. Un ejemplo mostrará lo que queremos decir:

La traductora ha encontrado en su lista estas etiquetas (mezcladas con otras muchas y no en este orden, sino en orden alfabético), y las ha traducido como aparece en la columna de la derecha, aunque, a decir verdad, algunas le han parecido totalmente carentes de sentido:

Combinando estas unidades en ese orden, en castellano se genera una oración impecable, que, efectivamente, encontramos en una de las pantallas del programa: ¹⁰

Este procedimiento refleja una burda intuición de la recursividad del lenguaje natural, es decir, la capacidad de generar infinitas oraciones combinando un número limitado de elementos, pero, por decirlo de una manera suave, es absolutamente naïve suponer que las combinaciones se realizan de modo paralelo (en el mismo orden y aplicando las mismas reglas morfosintácticas) en todos los idiomas. No hay más que ver la monstruosa e incomprensible oración que se genera en vasco:

Resulta evidente que es imposible traducir así, pues el resultado carece de sentido. Nuevamente, la única solución sería que programadoras y traductoras colaborasen para cambiar el diseño del programa.

Siguiendo con la cuestión de la combinación de elementos, cuando se diseñan estos programas a menudo se hace uso de variables (campos del tipo %1%), es decir, de símbolos a los que se les asignan después diversos valores. Esto es particularmente frecuente en los mensajes y avisos. El sistema rellena estos campos variables con sus datos, dependiendo del mensaje o aviso que deba componerse en cada caso:

1. El profesor %1% ya tiene asignada una clase para el %2% de %3%

2. No existe la vía de acceso %1% %2%

Este tipo de estructuras presentan dos problemas principales:

1. El profesor Pedro Etxebarria ya tiene asignada una clase para el cuatro de marzo

La traductora tendrá los contenidos del campo %3% traducidos, probablemente, de la siguiente forma: urtarrila, otsaila, martxoa, apirila...

Si ha interpretado la oración en el sentido indicado por el ejemplo de arriba, la traducirá de la manera siguiente con las variables (cambiando el orden de los campos, para expresar la fecha con el formato correcto en vasco):

%1% irakasleak badu eskola ordu bat zehaztuta %3%ren %2%(e)rako

Por tanto, la oración completa se generará de modo automático como sigue:

Pedro Etxebarria irakasleak badu eskola ordua zehaztuta martxoaren 4(e)rako

Pero їqué sucede si la traductora ha errado en sus suposiciones y los contenidos de los campos variables son totalmente diferentes, por ejemplo tales como para generar la siguiente frase?:

2. El profesor ayudante ya tiene asignada una clase para el grupo-prácticas de Francés

3. Problemas ligados al diseño de la interfase

No nos cansaremos de decir que para poder hacer su trabajo correctamente, la traductora precisa saber con exactitud en qué lugar de la aplicación aparecerá cada cadena de texto o cada elemento, por un lado para saber con seguridad el significado de cada ítem (ya hemos visto en las secciones anteriores los problemas derivados de traducir sin contexto) y, por otro, para identificar los cambios formales que es necesario hacer en la interfase. Por consiguiente, la traductora debería tener la posibilidad de ver las ventanas, menús desplegables, cajas de texto, imágenes animadas, mensajes etc. Por ejemplo, dependiendo de la longitud de los textos, con frecuencia será necesario ampliar o reducir los espacios donde se insertan, o cambiar los tipos de letra u otros rasgos tipográficos, desplazar elementos etc., de acuerdo con las convenciones y exigencias de la lengua y cultura de destino.

En las aplicaciones que no han sido internacionalizadas, durante todo el proceso se toma como referencia la lengua según la cual se ha configurado el programa, incluyendo el diseño de la interfase que verán las usuarias. Así, a la hora de distribuir el espacio en las pantallas, se tienen en cuenta las necesidades de la lengua de referencia, sin prever en qué forma incidirá esto en la versión traducida, de tal modo que la traductora encontrará que a veces le sobra espacio (un mal menor) y otras, por el contrario, le falta. Igualmente, en ocasiones se generarán cajas de texto de aspecto extraño, en las que al texto le precede un enorme espacio vacío, mientras que la parte final del texto se sale de los límites de la caja o queda cortada por excederlos.

Por motivos de espacio, a veces se utilizan abreviaturas en la lengua de origen. Cada idioma tiene sus convenciones sobre la forma y el uso de abreviaturas, de lo que se sigue que cuando un programa está diseñado siguiendo la estructura y normas de un idioma determinado (en nuestro caso, del castellano) las abreviaturas suponen otro quebradero de cabeza para las traductoras, particularmente teniendo en cuenta que el vasco es una lengua declinada y sufijada, y, que, por tanto, gran parte de la información semántica y gramatical se concentra al final de palabra. Véanse algunas de las abreviaturas usadas en español en la aplicación en cuestión:

Profesor	Prof.
Asignaturas	Asig.
Docencia	Docenc.

En castellano estas abreviaturas pueden ser útiles para introducir información de manera breve y clara en espacios limitados, particularmente cuando las usuarias conocen la materia de que se trata y pueden identificar con facilidad a qué textos corresponden. En vasco, sin embargo, nos encontramos con que palabras como irakaslea (profesora), asignatura (irakasgaia) y docencia (irakaslana) tienen la misma raíz. їCómo reducirlas al número de caracteres impuesto por la abreviatura castellana, de modo inteligible y útil para la usuaria?

A éste hay que sumarle otros problemas relacionados con las abreviaturas. En efecto, el que una cadena de texto sea larga en un idioma no significa que haya de serlo también en el otro, o, dicho de otro modo, el hecho de que en uno sea necesario recurrir a la abreviatura no significa que haya que hacerlo también en el otro.

En castellano hay una gran diferencia en el número de caracteres de estas dos formas, pero їy en vasco? La forma no abreviada del equivalente a 'departamento' es saila; їqué forma tendrá la traductora que inventarse para la abreviatura? їSail.? No parece que tenga mucho sentido, sobre todo porque la forma reducida y la normal tienen el mismo número de caracteres. Entonces їqué? їsa? їQuizá sai?¹¹

Lo más propio en este caso sería, por supuesto, no recurrir a la abreviatura en vasco, puesto que, además de no ser necesario, no se ahorrarían caracteres (en tanto queramos usar una abreviatura identificable para la usuaria). No obstante eso será imposible, por los motivos expuestos más arriba (la regla de oro de la traducción de esta aplicación era "una etiqueta: una correspondencia y sólo una"). Así pues, la traductora tendrá que dejar de lado el sentido común y continuar siguiendo servilmente los dictados de la versión de origen.

Si bien es cierto que en ocasiones las abreviaturas son un recurso adecuado para reducir el número de caracteres, a veces se utilizan sin ningún sentido ni regularidad (incluso llega a parecer que sólo obedecen al afán por teclear más rápido). Veamos los siguientes ejemplos:

F. ren. usu.

S. Profesor

їQué significan estas etiquetas? En estos casos es muy difícil saber a qué corresponden las formas abreviadas, y, por tanto, traducirlas. Sea como fuere, hay que decir que las dificultades de comprensión no afectan únicamente a las traductoras, sino también, con toda probabilidad, a las usuarias, lo que producirá problemas en el uso de la aplicación. Por lo tanto, las diseñadoras deberían reflexionar sobre si tiene realmente ventajas insertar un texto largo en un espacio reducido si a cambio de ello se termina confundiendo a las usuarias, y deberían considerar si no sería más conveniente adaptar el programa a las necesidades de las usuarias y no al revés.

En este artículo hemos tratado de mostrar el tremendo problema que presenta para la traductora la localización de un producto no internacionalizado. Por otra parte, por arduos que sean los esfuerzos invertidos en la tarea, el resultado será siempre de pobre calidad y tendrá un elevadísimo coste en tiempo y trabajo, además de afectar muy negativamente a la moral de la traductora. Y es que, como decía el título de este trabajo con un humor ligeramente amargo, si la escoba es mala, difícilmente se podrá mantener limpia la casa.

- La primera conclusión, pues, es evidente: es necesario fabricar buenas escobas. En estos tiempos de globalización, y, particularmente, en sociedades bilingües como la vasca, es inaceptable que las empresas diseñadoras de productos informáticos se mantengan al margen de las exigencias de internacionalización y localización, y más aún cuando proclaman a los cuatro vientos, como a menudo sucede, el carácter bilingüe o multilingüe de sus productos. Una conocida empresa vasca que ha diseñado un programa que se diría ingeniado para torturar traductoras denomina con orgullo "multidioma" a una aplicación rígida e inadaptable hasta las lágrimas. La experiencia nos ha enseñado (y cualquiera puede verlo, con sólo navegar un poco por la red) que en el País Vasco la mayor parte de las empresas informáticas adolecen de una ignorancia supina en este ámbito.

En la mayoría de los casos parten de una equivocada concepción atomista de las lenguas naturales, según la cual una lengua está constituida por una lista de elementos aislados, el contexto está absolutamente ausente y todos los idiomas son paralelos en estructura y léxico, eso sí, tomando siempre como referencia una determinada lengua que sería el centro del universo y que, casualmente, es la de la programadora. Como hemos expuesto a lo largo del artículo, por un lado es absolutamente necesario que la configuración básica del producto sea independiente de la estructura de cualquier idioma. Por otro, en lo que se refiere al idioma que se utilice en la aplicación, es un requisito básico que las diseñadoras utilicen un lenguaje controlado. Insistimos en que eso no tiene nada que ver con tópicos estúpidos del tipo "las personas de ciencias escriben muy mal, mejor harían en leer a los clásicos". Al hablar de lenguaje controlado nos referimos a un subconjunto del lenguaje natural al que se le han aplicado determinadas restricciones en la sintaxis y el léxico, con el fin de evitar ambigüedades, incoherencias, imprecisiones y variantes arbitrarias. En caso de ser necesario hacer alguna modificación en ese conjunto de términos y expresiones bien definidas, esos cambios deberían ser objeto de un control estricto y comunicárselos inmediatamente a las traductoras para que ellas controlen la repercusión de dichas alteraciones en su versión.

- La segunda conclusión tiene que ver con quien compra la escoba, sobre todo cuando lo hace con el dinero de toda la comunidad: antes de acudir al mercado, es necesario ponerse bien al día en cuestión de escobas. Y es que, si es cierto que numerosas especialistas de la informática desconocen la internacionalización y la localización, qué podemos decir de ciertas autoridades de las administraciones públicas del País Vasco. Lamentablemente, en los concursos públicos convocados para el diseño de productos informáticos específicos para nuestras instituciones, son contadas las veces (en realidad, sería más exacto decir jamás) en que se establece como requisito que las empresas licitadoras tengan experiencia y preparación en el terreno de la internacionalización y localización. Normalmente se adquiere un producto totalmente monolingüe (en el mejor de los casos, una base de datos, en el que se ha dejado un casillero libre al lado de cada ítem de la lengua original, para que la traductora escriba su correspondencia en la lengua de destino), para después dejar ese producto mortífero en manos de las traductoras, con una absoluta tranquilidad de conciencia, por cierto. Es entonces cuando comienza el calvario de la traductora, el gasto de toneladas de energía, trabajo y tiempo, y la desesperación de saber que, haga lo que haga, el resultado final será inevitablemente malo. No obstante, como ciudadanas, es tiempo de que preguntemos si es realmente lícito que el dinero público se gaste de esta manera en productos de mala calidad. Es del todo necesario que las instituciones, particularmente las públicas, tomen conciencia del problema y establezcan políticas generales en este campo, para exigir el cumplimiento de una serie de requisitos a las empresas que se encargan del diseño de productos bilingües (o multilingües), como corresponde a una sociedad bilingüe como la nuestra.

- La tercera conclusión se refiere a quien debe adecuar/localizar la escoba en su trabajo, es decir, a la traductora. Una y otra vez hemos insistido en el tremendo sufrimiento que esta situación produce al equipo de traducción, y no hemos exagerado ni un ápice. Sin embargo, para poner fin a esta situación no podemos limitarnos a denunciarla. Debemos estar dispuestas a hacer tres cosas: