Destrezas de localización para traductores/requisitos de preparación para la localización para clientes

Localización:

“Adaptar el software a un país en concreto. Eso incluye la traducción a la lengua nativa del país, tanto de los menús y de los mensajes del programa, como de los cambios en la interfaz de usuario para que todo se corresponda con los diferentes  alfabetos y culturas (www.yourdictionary.com/localization).

El archiconocido término “localización” puede desalentar a cualquier traductor interesado en trabajar en este campo. Es indudable que hay destrezas especiales necesarias para el proceso de localización, pero, ¿por dónde empezar?

El propósito de este artículo es hacer una aproximación a algunas de las destrezas básicas que los traductores necesitan para completar la labor de localización. También detallar los requisitos de preparación para la localización que los clientes pueden realizar para asegurar que la localización de su producto o de su documentación sea la correcta. Como se verá, la localización no es necesariamente tarea de un solo traductor (o localizador en este caso). Más bien suele ser responsabilidad de todas las partes implicadas en el desarrollo del producto original, así como de los gestores de proyectos que han intervenido en el proceso de localización por ambas partes. Si durante el proceso de desarrollo de un producto se tienen en cuenta unos requisitos básicos para la localización, más tarde se producirá un efecto dominó beneficioso que afectará a toda la cadena de trabajo. Un producto bien globalizado será más fácil de localizar, sobre todo porque es menos propenso a provocar problemas técnicos durante el proceso de localización.

 Además, un contenido bien estructurado es más fácil de traducir.
 

Destrezas de localización para traductores
Los traductores son, a la vez, expertos en lengua y en la materia de que se trate. Además, a veces también tienen que ponerse en el lugar del revisor o del maquetador. El conocimiento de todas estas destrezas le serán útiles cuando necesite aplicarlas en el proceso de localización. Dado que el campo de la localización es tan complejo no tengo espacio aquí nada más que para mencionar un par de aspectos técnicos clave para la localización que ayudarán a mejorar los niveles de conocimientos técnicos y la capacidad de markéting. En este artículo, cada vez que utilice el término “localización” me refiero a localización de software. Este término normalmente incluye la interfaz de usuario y la documentación (asistencia e información para el usuario, ayuda, etc.).
 

HTML

Muchos traductores o empresas de traducciones conocen ya de sobra el HTML, pero otros muchos nunca han trabajdo con este tipo de documentos. Conocer y entender cómo funciona el HTML es fundamental para la localización. También la capacidad de resolver las situaciones problemáticas cuando surjan es algo que los clientes empiezan a valorar cada vez más. Ser capaz de proporcionar ese servicio de traducción es un valor añadido a su capacidad como traductor.

Aunque esto no quiere decir que todos los localizadores tengan que ser necesariamente programadores de páginas web. Pero los localizadores sí que deberían tener un conocimiento general sobre los lenguajes de marcas. Afortunadamente son bastante fáciles de aprender. Como localizador Ud. debería:
 

• Saber suficiente HTML como para reconocer las etiquetas en un documento HTML.
• La mayoría de las etiquetas HTML constan de una etiqueta de inicio y una etiqueta de cierre y se organizan en niveles o capas (imagínense una cebolla pelada). Aunque es posible que esto no sea así. El HTML no es tan preciso como debería y a veces funciona aunque falten etiquetas.
• Acordar con el cliente qué contenido entre etiquetas quiere localizar.
• Saber reconocer el lenguaje de programación script, por ejemplo el Javascript o las hojas de estilo en cascada incrustadas (las hojas de estilo en cascada (CSS según sus siglas en inglés) son un formato de datos que se utilizan para separa el estilo de la estructura en las páginas web), en los archivos HTML. Una vez identificado será más fácil preguntarle al cliente qué partes hay que localizar. También puede haber contenido que hay que traducir dentro del Javascript y es posible que haya que editar el CSS para lenguas de Asia Oriental por los tipos de fuente y los cambios de tamaño.
• Invertir en un buen editor de HTML. Eso es muy importante.
• WYSIWYG (Lo que ves es lo que tienes); la pesadilla de cualquier editor de páginas web. Hay bastantes editores profesionales, como por ejemplo Macromedia's HomeSite, que permiten editar el código HTML sin insertar otros formatos no deseados.
• Las herramientas de traducción se crearon para ayudar a identificar el contenido traducible en el HTML. Las herramientas de TAO (Traducción Asistida por Ordenador) bloquean las etiquetas y otros códigos HTML que no hay que tocar. Por supuesto esto facilita mucho la tarea de traducir HTML.

Es bastante fácil acercarse al HTML. Hay muchos libros en el mercado que explican cómo funciona todo. Yo misma tengo alguno. Para aquellos que tienen ya un conocimiento básico del HTMl pero necesitan más información, los libros de la editorial O’Reilly pueden ser de gran ayuda. También hay una gran cantidad de tutoriales online que son excelentes (y gratis), así como sitios web que facilitan listas de etiquetas HTML (una lista limitada) y consejos sobre cómo crear uno mismo sitios web. También los organismos públicos ofrecen muchos cursos de programación HTML básica.

XML

El XML, por su flexibilidad, es una excelente opción para editar contenido que haya que localizar. El XML no puede reemplazar al HTML, pero sí puede utilizarse como vehículo para crear contenido que sirva, al mismo tiempo, para web, para documentación impresa y para otros formatos. La diferencia entre los dos es el lenguaje de marcas. El HTML aplica un lenguaje de marcas estructural (por ejemplo <b> para negrita, <p> para párrafo, <h2> para segundo nivel de encabezado, etc.), pero el XML aplica un lenguaje de marcas semántico (como por ejemplo, <emphasis> (énfasis), <article> (artículo), <product-name> (nombre de producto), etc.). Los elementos del XML se escriben completos, no abreviados, así que no puede haber confusión sobre a qué se refieren. Al igual que los documentos HTML, los documentos XML no incluyen información de formatos, ya que toda esa información se incluye en un archivo aparte (un XSL o un CSS). El XML es un lenguaje extensible, esto es, que los elementos se pueden crear sobre la marcha, cuando sea necesario. El formato se puede cambiar para adaptarlo a los diferentes países. Por ejemplo, si una etiqueta <emphasis> contuviera un texto, en el XSL se diría exactamente qué formato tendría el texto contenido. Esto significa que la negrita se podría aplicar cuando el texto estuviera en inglés o que no se especifica ningún formato para un texto en japonés.

Aquí menciono algunos conceptos básicos sobre el XML.

Los traductores deberían:

• Entender cómo se estructura el XML:
• La estructura del XML es más clara que la del HTML, por eso resulta más fácil reconocer el contenido que hay que traducir.
• La información de formato no debería estar en el archivo XML. Si la estructura es correcta, sólo será necesario modificar una vez la información de formato que corresponde a un determinado conjunto de archivos.
• Es fundamental devolverle al cliente siempre archivos XML válidos. Hay herramientas de validación disponibles en el mercado que son tan fáciles de encontrar como los editores XML.
• Saber que las herramientas de traducción se crearon para ayudar a identificar el contenido traducible en el XML. Al igual que con el HTML, las herramientas de TAO bloquean las etiquetas y otros códigos XML que no hay que tocar, haciendo que traducir XML sea mucho más fácil.

Juegos de caracteres

Todos alguna vez hemos visto que algunas páginas web muestran caracteres extraños o cuadraditos donde deberían verse signos diacríticos. A veces también los signos diactríticos aparecen reemplazados por caracteres japoneses. Esto ocurre cuando el ordenador utiliza un juego de caracteres equivocado. Para prever problemas y entender por qué las cosas funcionan como lo hacen, es conveniente saber algo sobre cómo funcionan los juegos de caracteres.

En un principio cada carácter tiene asignado un número en una lista de códigos. Ese sería un buen sistema si en todo el mundo se utilizaran los mismos caracteres. El problema es que hay cientos, si no miles, de páginas de códigos que utilizan los mismos números para diferentes caracteres. Como los ordenadores sólo interpretan código numérica, es necesario especificar qué lista de códigos se debe utilizar para leer un texto.

En este ejemplo, la página HTML busca una lista de códigos en concreto:

<HTML>
<HEAD>
<META content= "text/html;charset=1 252^">

Si cambiáramos este número por el número de la lista de códigos para el hebreo (1255), muchos de los caracteres del documento se convertirían en caracteres hebreos de acuerdo con los números asignados por el sistema para cada carácter. El ordenador sólo hace lo que se le dice. Aunque hay una solución para este lío.

El Unicode.
 

Unicode

La idea del Unicode es, en vez de utilizar miles de listas de códigos diferentes para todas las lenguas del mundo, establecer solamente una lista de códigos para todas las lenguas. Esta debería incluir todos los caracteres utilizados por todas las lenguas escritas de mundo, lo que podría implicar más de un millón de caracteres. El Unicode incluye alfabetos, caracteres ideográficos y símbolos. La idea es que estos caracteres pueden mezclarse de todas las maneras posibles porque están todos incluidos en la misma lista de códigos (veáse https://home.unicode.org/).

Aquí hay algunos conceptos básicos. El traductor debería:
 

• Entender cómo se puede especificar si un documento es Unicode o si utiliza la lista de códigos ANSI. Eso es fácil de detectar; sólo hay que mirar justo al principio del documento que contiene el código fuente. Si un documento es Unicode, tanto UTF-8, UTF-16 o UTF-32, estará reflejado ahí.
• Unicode utiliza la misma lista de códigos para todas las lenguas.
• Unicode es un sistema estándar acordado. Visite la página Unicode.org para más información.

La página web de Unicode es una buena fuente de información y también hay algunas publicaciones que tratan el tema del Unicode. En resumen, este tema podría ser susceptible de escribir un artículo entero sobre él. Saber algo sobre los juegos de caracteres y su funcionamiento puede ayudar mucho a prever posibles problemas y a ayudar a los clientes cuando estos surjan.
 

Herramientas de traducción
También conocidas como herramientas de TAO ayudan a agilizar el trabajo y a incrementar la productividad. Como con cualquier otra herramienta, es necesario un período de aprendizaje que normalmente alcanza su grado máximo a las 3 de la mañana, cuando el plazo de entrega se acaba 5 horas después. Cada herramienta de traducción tiene interfaces y funciones ligeramente diferentes, pero todas hacen más o menos lo mismo. Ahí va una pequeña lista de destrezas necesarias para utilizar las herramientas de traducción.

• Entender cómo gestionar una memoria de traducción (TM). Las memorias de traducción almacenan el texto origen y el meta según se traduce, establece pares para cada segmento, frase o párrafo y luego los guarda para futuros usos.
• Como localizador, Ud. es el experto en lengua. Puede que los clientes dependan de Ud. para actualizar segmentos o terminología en la memoria o para asegurarse de que la información está al día.
• Entender cómo funcionan las opciones que se usan para unir diferentes memorias. Es posible que necesite introducir los datos de una TM en otra.
• Saber crear una base de datos terminológica bien estructurada. La base de datos terminológica puede crearse para uso personal o ser creada con la intención de entregársela al cliente. En ambos casos hay campos estándar para crear estas bases de datos que puede que sea necesario utilizar.

• El término “herramientas de traducción” se refiere a un amplio grupo de herramientas que se usan para traducir y editar texto. Por eso es necesario saber cómo funcionan las herramientas juntas y la mejor manera de utilizarlas dentro de la rutina de trabajo. Cada localizador tiene un método de trabajo ligeramente diferente de los demás y el proceso puede alterarse según el tipo de texto o el proyecto.
• El término “traducción automática” se refiere a un proceso de traducción completamente automático, es decir, completamente realizado por el ordenador. Normalmente el valor de estos programas depende de cómo hayan sido diseñados; los buenos programas están diseñados para trabajar en combinación con los traductores humanos.
• Entender el cómputo de pálabras y el proceso de análisis. Los clientes habrán hecho ya un cómputo de palabras antes de entregar el documento al traductor. Para evitar sorpresas, también el traductor debe poder hacer esa tarea.
• Saber localizar archivos con etiquetas utilizando herramientas de traducción. También es importante saber bloquear determinados elementos o etiquetas. Si Ud. conoce bien este proceso, los clientes confiarán en su experiencia.
   

La capacidad de trabajar con herramientas de traducción de manera eficaz lleva su tiempo. Y los resultados se ven mejor cuando ya se lleva un tiempo trabajando con una herramienta en particular y ya han surgido y se han resuelto algunos problemas. La clave de estas herramientas es comprender cómo funcionan. Como con cualquier otro nuevo elemento de software, el tiempo es el mejor aliado. Si está interesado en aprender, hay varias opciones posibles incluyendo la formación que ofrece el propio fabricante del producto, talleres, programas de traducción, "publicaciones" y grupos y foros online. Cuando domine el proceso ya será capaz de prever sobre la marcha problemas potenciales que puedan surgir.

El primer paso hacia el aprendizaje del proceso de localización es conocer los puntos principales y los detalles más frecuentes de los formatos de archivos, la codificación y las herramientas. Las destrezas reseñadas en este artículo son simplemente la punta del iceberg. Hay muchos elementos muy complejos e importantes alrededor del campo de la localización y entender sus fundamentos ayudará a desarrollar estas destrezas a largo plazo.
 

Requisitos de preparación para la localización para los clientes
Normalmente nos centramos en lo que los traductores deben saber para sobrevivir y tener éxito en la industria de la localización, pero eso no abarca todo el espectro. Un producto completamente localizado no depende solamente de la labor de organización del gestor del proyecto de localización y de la labor de traducción y adaptación del localizador. El éxito en la localización de un producto reposa en los hombros de cada persona que ha desarrollado, gestionado y, por último, localizado ese producto. Por eso, en vez de delegar toda la responsabilidad de la localización al final de la cadena (en el traductor freelance o el localizador), hay ciertas cosas que deberían estar resueltas mucho antes de que empiece la localización para facilitar la labor del localizador. De esa manera los localizadores son más productivos y diversifican menos su labor por culpa de asuntos que se apartan de su trabajo. A largo plazo esto significa que el esfuerzo total de localización sea más barato y más eficiente.

En la actualidad el proceso de localización parece llevarse a cabo en dos fases (veáse el Gráfico 1). Por una parte está el desarrollo del producto para el mercado angloparlante y por otra, el producto localizado. El proceso para cada uno de estos productos es muy diferente. Son necesarios algunos pasos antes y durante la localización para que esta finalmente resulte correctamente. Por ejemplo, imagine lo que pasaría si fallara alguna de estas cosas: que el producto no hubiera sido probado correctamente, que un juego de caracteres diferente no funcionara para ese producto, que el contenido tuviera que estar adaptado al país meta, que las herramientas de traducción no funcionaran con los archivos de origen, etc. No resulta difícil darse cuenta de que esto podría convertirse en una pesadilla. Todos los gestores de proyecto han tenido que lidiar alguna vez con un proyecto de ese estilo y es sorprendente lo rápido que se aprende la lección sobre lo que los cliente debían haber previsto mucho tiempo atrás. Todo esto prueba que un pequeño esfuerzo de globalización puede, más tarde, cundir mucho. Es fácil darse cuenta, casi siempre demasiado tarde, de que debería haberse invertido más tiempo en hacer algo de planificación en un principio.

Requisitos de preparación para la localización
Con “requisitos de preparación para la localización” nos referimos al proceso de globalización que lleva a cabo el cliente. La siguiente lista de requisitos es larga, pero creo que es importante mencionar aquí algunos de ellos que den una idea del tipo de cosas que hay que tener en cuenta.
 

Contenido traducible / coherencia y simplicidad
El sector informático y de nuevas tecnologías está repleto de jerga, latiguillos y argot que hemos acabamos usando todos los días. Aunque esto sea aceptable para las conversaciones cotidianas o para los e-mails, puede causar un esfuerzo adicional en lo que respecta a la localización. Es necesario hacer un esfuerzo por utilizar un inglés estándar desde el primer momento en que un producto empieza a desarrollarse o documentarse. Un ejemplo interesante de un término que se usa actualmente en documentación puede verse en el Gráfico 2.

Puede que el significado de este término pueda parecerle evidente a algunos, pero no a todos:

“Breadcrumbing” (lit. “tirar miguitas de pan”)

Sust. Elemento de navegación que muestra una lista de los lugares que ha visitado una persona o la ruta que ha seguido.

Origen: La palabra actual tiene su origen en el cuento de Hansel Y Gretel que tiraron miguitas de pan para más tarde poder encontrar el camino para salir del bosque. Este elemento es común en sitios web cuyo contenido se organiza jerárquicamente o como una secuencia de páginas. Yahoo (www.yahoo.com) puede que sea el ejempo más conocido.
 

Puede que un localizador de Europa Occidental lo entendiera fácilmente (es más probable que el receptor meta comparta la referencia cultural al famoso cuento), pero tal elemento de jerga sería completamente ajeno a un localizador de Asia Oriental. El tiempo y el esfuerzo necesarios para traducir este término a la lengua y al contexto del país meta serán serían considerables (tiempo de documentación, preguntas a los gestores de proyecto y toma de decisiones sobre el término, etc.). Incluso si toda la terminología que se usa para un producto tuviera un significado claro, surgirían otros problemas como la falta de coherencia en la terminología entre las interfaces de usuario y los archivos de ayuda. Esta es otra fuente de problemas y malentendidos que costarán tiempo y dinero. Además, cualquier problema, tanto en el inglés, como en el producto localizado tendrá efectos nefastos en la experiencia que el usuario tenga de ese producto, lo que dañará potencialmente al producto o el nombre de la empresa.

¿Cómo se crean o editan los archivos?

Aparte del contenido traducible hay muchos aspectos a tener en cuenta que también pueden surgir como resultado del tipo de archivos que se usan para la localización. Podría parecer que guardar un documento en Word como HTML ahorra tiempo, pero, más tarde, cuando hay que traducir o editar ese documento, acaba por no merecer la pena. En ese documento HTML se inserta mucho formato extra, lo que hace que detectar el texto que hay que traducir se convierta en una tarea similar a buscar una aguja en un pajar. Si se va a localizar un archivo HTML, este debe crearse utilizando un editor de HTML que no inserte etiquetas innecesarias.

Muchos editores WYSIWYG introducen texto extra en un documento HTML, pero hay en el mercado editores más básicos que no lo hacen. Además, cuanto más limpio esté el documento origen, menos errores surgirán durante o después del proceso de localización.

El contenido de los documentos HTML suele ser bastante sencillo, aunque pueden surgir problemas cuando se ha introducido programación en lenguaje script en el archivo y no se ha implementado de manera correcta. Si se usa Javascript en un archivo HTML (cosa bastante frecuente) puede que haya texto localizable incrustado en el texto del Javascript. Aunque la sección donde está el Javascript está marcada claramente, no es siempre tan fácil para el localizador entresacar el texto localizable de las líneas de Javascript. La mejor opción en este caso es suministrar un archivo *.js que esté vinculado a los archivos HTML. En ese archivo el texto localizable estará separado de las instrucciones del lenguaje script. De esa manera la localización resulta más fácil y hay menos posibilidades de cometer errores.

Por el mismo motivo, si el archivo CSS está incrustado en un grupo de documentos HTML en vez de aparecer en un archivo separado, puede que haya que modificar la información sobre las fuentes. De hecho, para las lenguas de Asia Oriental hay que cambiar esta información en cada uno de los archivos y no en un sólo lugar. De nuevo, el tiempo que se invierte en hacer esos cambios de fuentes estaría mejor invertido si se hubiera utilizado en la localización del contenido.

Contenido XML

Este tipo de contenidos ayudan bastante a la hora de realizar la localización. Gracias a la naturaleza extensible del XML, los elementos que representan el contenido pueden crearse y utilizarse para introducir diferentes atributos según la lengua del archivo. Por ejemplo, cualquier estructura de XML que se cree para una legua origen debería incluir elementos que sean necesarios también para la lengua meta. Es común que un producto que se venda a todo el mundo tenga diferentes características dependiendo de los diferentes contextos. El XML permite identificar contenido extra que puede ser eliminado o modificado según sea necesario en cada caso, pero manteniendo un único documento origen. Por ejemplo, si un país necesita documentación extra sobre una característica específica del producto, se puede crear un elemento extra para esos contenidos. Ese contenido puede bloquearse o desbloquearse según la lengua meta lo necesite o no.
 

Feedback

Todos los asuntos tratados sobre la calidad y la coherencia de la documentación de origen pueden parecer cosas de sentido común. Incluso, desde la perspectiva del localizador o gestor de proyecto, pueden parecer obvias.

Pero es sorprendente ver el gran número de errores o de malas decisiones que se siguen repitiendo y que, muchas de las veces, implican cambios importantes; errores que, después, pueden parecer más que obvios.

Para evitar estos y otros posibles errores en el futuro, debe establecerse una cadena de feedback entre todas las partes implicadas en el proyecto de localización. Todos los problemas aquí descritos no sólo son caros de resolver una y otra vez, también implican la pérdida de un tiempo que resulta muy valioso para el localizador. Si el localizador puede concentrarse completamente en su tarea, el resultado será un producto mejor localizado.
 

Colaboración

Para resolver estos asuntos desde el inicio del desarrollo del producto es fundamental establecer un sistema de feedback. Ese feedback debe establecerse entre todos los eslabones de la cadena de trabajo. Los localizadores deben comunicarse con los gestores de proyecto y los gestores con los clientes. Cuando se complete el proyecto es recomendable que todas las partes compartan las cosas buenas y malas del proyecto y las dificultades que han surgido en el proceso. Sólo así el proceso comenzará a mejorar.

En un mundo ideal, las empresas de localización trabajarían en colaboración con sus clientes. Esa colaboración beneficia a los clientes, ya que les ayuda a producir un software y una documentación preparada para todos los países del mundo. Y, con la experiencia que los localizadores pueden aportar, los proyectos resultarían más baratos y, a largo plazo, más fáciles de localizar. Por la misma razón, los gestores de los proyectos de localización no deberían proporcionar este tipo de información sin contar con la experiencia y el feedback de los localizadores freelance. En ese caso, la localización más que ser un problema o un arreglo de última hora, será simplemente el último paso del proceso de crear un producto global.

Sólo los problemas tratados aquí, cuando surgen en un proyecto real, hacen que la localización sea una tarea cara y caótica. Un proyecto que en un principio era inocente y bien intencionado puede costar al final demasiado tiempo y energía. Con localizadores y gestores de proyecto conscientes de su tarea, que puedan aplicar soluciones anteriores a nuevos proyectos y clientes que entiendan el valor de una buena planificación de la localización, al final se obtendrán beneficios para todos.

Notas:

1. Por ejemplo, el Kent State University Institute for Applied Linguistics y el New York University Department of Foreign Languages and Translation ofrecen cursos sobre traducción técnica, gestión de proyectos y herramientas de traducción.
2. A Practical Guide to Localization de Bert Esselink; The Handbook of Terminology Management de Sue Ellen Wright y Gerhard Budin;

XML Internationalization and Localization de Yves Savourel; y Beyond Borders: Web Globalization Strategies de John Yunker. Toda esta bibliografía incluye capítulos o artículos sobre herramientas de traducción.

Otros recursos

Dr. International. 2002. Developing International Software, Second Edition. Redmond: Microsoft Press.

Esselink, Bert. 2000. A Practical

Guide to Localization: For Translators, Engineers, and Project Managers. Amsterdam: John Benjamin.

Graham, Tony. 2000. Unicode: A Primer. Hoboken: John Wiley & Sons.

Savourel, Yves. 2001. XML Inter-nationalization and Localization. Indianápolis: Sams.

TechWeb Encyclopedia (https://www.informationweek.com/).

The Unicode Home Page (https://home.unicode.org/).

Wright, Sue Ellen y Gerhard Budin. 2001. The Handbook of Terminology Management: Application-Oriented Terminology Management. Amsterdam: John Benjamins.

Wright, Sue Ellen y Gerhard Budin. 1997. The Handbook of Terminology Management: Basic Aspects of Terminology Management. Amsterdam: John Benjamin.

Yunker, John. 2002. Beyond Borders: Web Globalization Strategies. Indianapolis: New Riders Publishing.