Por Susana Domínguez, Jefa de proyectos en Nóvalo.

Se denomina software a todos los componentes intangibles de un ordenador, es decir, al conjunto de programas y procedimientos necesarios para hacer posible la realización de una tarea específica, en contraposición a los componentes físicos del sistema (hardware).

Cuando hablamos de «localización de software» nos referimos a la traducción y adaptación de programas informáticos a la lengua y cultura de cada país. Normalmente un proyecto de localización completo abarca los siguientes componentes: el propio software, las ayudas en línea y la documentación que acompaña al software.

No obstante en esta entrada del blog me centraré de forma específica en la traducción del software en sí, que debería ser la primera fase de un proyecto de localización completo.

De forma general, podemos decir que la traducción de software es aquella que abarca la traducción de todos los elementos de la interfaz gráfica de usuario de una aplicación de software, como cuadros de diálogo, menús, y mensajes de estado o de error que se muestran en la pantalla.

Existen dos métodos a la hora de enfrentarse a la traducción de software: trabajar con archivos de recursos no compilados (archivos originales escritos en el lenguaje de programación) o directamente con los archivos de programa compilados (archivos binarios). En el primer caso se podrá utilizar un editor de texto, un editor de recursos o una herramienta de traducción asistida y en el segundo se utilizará un editor de recursos o una herramienta de localización de software.

Veamos a continuación las ventajas y desventajas de trabajar con un método u otro:

Archivos de recursos o código fuente

Ventajas

Desventajas

-No hace falta un editor especial -No es fácil mantener la visión de conjunto
-No se necesitan herramientas caras de localización -No se puede ver el aspecto de la interfaz traducida
-Tras la traducción hay que compilar los archivos y enlazarlos para crear una aplicación completa de calidad -Riesgo de modificar código fuente importante
-Dificultad para reconstruir información contextual del archivo original

Archivos binarios

Ventajas

Desventajas

-Opción WYSIWYG (What You See Is What You Get) de los programas de localización de software -Necesidad de editores o herramientas especiales
-Información contextual de los archivos binarios
-Evita cambios accidentales del código fuente
-Mayor facilidad para redimensionar opciones en lugar de usar abreviaturas

Os dejo a continuación algunas capturas de ejemplo:

novalo_blog_traduccion_software1
novalo_blog_traduccion_software3

novalo_blog_traduccion_software2

De acuerdo con esto parece mucho más sencillo y económico trabajar con archivos binarios pero, por desgracia, no es el método más habitual, especialmente si el software es todavía una versión beta o no definitiva.

En el caso de los archivos de recursos, el texto traducible está integrado en el código y suele aparecer entre comillas. Las herramientas TAO cuentan con filtros estándares que procesan el texto traducible; sin embargo, aún así es importante conocer la siguiente información:

-Las cadenas de texto traducible aparecen entre comillas. Se debe evitar el uso de comillas dentro de las cadenas. Si es absolutamente necesario se deben usar comillas dobles.

Ej.: «Haga clic en «»Aceptar»» para continuar»

-No añadir ni eliminar las comillas iniciales ni finales.

-No añadir ni eliminar espacios al principio ni al final de las cadenas.

-No usar el carácter & en las traducciones ya que dicho carácter se utiliza para indicar las teclas de acceso rápido. Si es absolutamente necesario se utilizará de forma duplicada (&&).

-Si existen cadenas con formatos de fecha, hora o números, por ejemplo mm/dd/yyyy hh:mm AM/PM (que se muestra por ejemplo 01/24/2014 10.00 PM) y es necesario modificarlas en el idioma de destino, se debe consultar al programador antes de modificarlas en el archivo de recursos puesto que es posible que el software recupere esa información del sistema operativo.

-Por lo general nunca se deben traducir nombres ni extensiones de archivos.

-Respetar las líneas de comentarios añadidas por el programador (pueden contener información contextual útil, pueden indicar restricciones de caracteres o si una determinada cadena no debe traducirse, etc.).

-Respetar códigos de control como por ejemplo \n (salto de línea); \r (retorno de carro) o \t (tabulación).

Independientemente del método que se utilice para la traducción de software, los elementos localizables son los datos que forman la interfaz de usuario. Podemos distinguir:

Cuadros de diálogo: ventanas o pantallas para cambiar opciones o ajustes. Pueden contener pestañas, campos, casillas, listas, etc.

Menús: listas desplegables para seleccionar comandos y opciones, o para acceder a cuadros de diálogo. Incluyen barras de menús, opciones de menús o menús contextuales.

Cadenas: mensajes de error, mensajes de estado, preguntas y tooltips (o descripciones emergentes) que se utilizan en la aplicación.

Suele ser la parte más complicada debido a que las cadenas no contienen información contextual. Además aquí nos encontramos con las variables cuyo valor cambiará durante la ejecución del programa. Su comprensión y colocación en la traducción es muy importante. Algunos ejemplos son:

Variable Valor sustituido
%s Cadena alfanumérica
%d Número decimal
%p Número de página
%u Carácter Unicode
%ld Entero decimal largo
%x Entero en formato hexadecimal
%g Valor flotante en coma

A veces son fáciles de entender («El documento %s contiene %d palabras») y otras es realmente complicado («%s a %s»).

Además, al traducir por ejemplo de inglés a español nos encontramos el problema del género.

Teclas de acceso rápido: las teclas de acceso rápido son combinaciones de teclas que permiten acceder a funciones de menús y submenús. Se muestran en la aplicación mediante una letra subrayada (por ejemplo: Abrir) y en los archivos de software veremos el símbolo & delante de la letra en cuestión (&Abrir). Al pulsar dicha tecla en combinación con la tecla Alt se activará un determinado comando. La asignación de una tecla de acceso rápido debe ser única dentro de un mismo menú, submenú o cuadro de diálogo para permitir una correcta funcionalidad. Además se prefiere el uso de determinadas letras (usar el primer carácter de la palabra o el más cercano al inicio de la palabra, no usar caracteres acentuados o evitar caracteres con trazado descendente, etc.). También se debe ser coherente con las teclas de acceso rápido utilizadas en el sistema operativo de destino.

Atajos de teclado: son también combinaciones de teclado que permiten acceder a funciones de menús y submenús. Muchos comandos se activarán al pulsar la tecla Ctrl junto con una tecla de función o una letra. Cuando son combinaciones de la tecla Ctrl con una tecla de función (por ejemplo Ctrl+F12) no se deben cambiar en el software localizado. Si son combinaciones de la tecla Ctrl con una letra, número o símbolo pueden localizarse aunque es mejor mantener las de la versión original porque a menudo son comunes con otras aplicaciones. Hay que tener en cuenta también que algunas teclas del teclado se localizan en muchos idiomas europeos y que la asignación de un atajo de teclado debe ser única dentro de la aplicación.

Elementos gráficos: pueden ser mapas de bits, iconos o cursores, por ejemplo. En Microsoft Word encontramos localizados en español los iconos de negrita, cursiva y subrayado.

novalo_blog_estilos_fuente

 Por otro lado podemos hablar de unas pautas generales en la traducción de software:

-Creatividad: evitar traducciones literales, intentar comprender la función de cada opción.

-Coherencia en la terminología, estilo y gramática utilizados en todos los elementos del software.

-Coherencia con la terminología del sistema operativo de destino cuando se haga referencia a él.

-Coherencia entre menús u opciones y cuadros de diálogo relacionados.

-Evitar el uso de la primera persona del singular o plural (yo o nosotros) en los mensajes.

-Intentar usar el modo imperativo para facilitar la comprensión.

-Uso de mayúsculas y minúsculas estándares del idioma.

-Adaptación del lenguaje para satisfacer las convenciones locales.

Por supuesto existen muchas más directrices pero podemos hacernos una mejor idea si consultamos diferentes guías de estilo de localización de software. Las guías de estilo tratan, entre otras, cuestiones como el modo de dirigirse al usuario, la sintaxis, el uso de pronombres posesivos, tiempos verbales, puntuación, uso de mayúsculas y minúsculas, acrónimos, terminología, marcas comerciales, restricción de caracteres, etc.

Si os apetece ampliar la información podéis consultar las completas guías de estilo de Microsoft para distintos idiomas. Se pueden descargar desde este sitio web.

Por último quisiera destacar las principales dificultades que se nos presentan al traducir software:

-Falta de contexto

-Significado de variables y cómo ubicarlas en la traducción

-Restricción de caracteres

-Problema con el género y número al traducir del inglés a otros idiomas

-Uso de nombre o infinitivo en algunas opciones. Por ejemplo «Search» podría ser una opción o menú (y lo traduciríamos con el infinitivo «Buscar») o podría ser el nombre del cuadro de diálogo «Búsqueda».

-Uso de infinitivo o imperativo en algunas cadenas en las que se puede confundir si es una instrucción para el usuario, una opción, una descripción emergente, etc.

-Distinguir elementos no traducibles como palabras en mayúsculas (MODIFY), unidas con guiones bajos (file_format) o apocopadas (DevUnit).

Por todo esto es evidente que este tipo de traducciones la consulta de dudas sea uno de los procesos más importantes.

Espero que con esta entrada del blog hayáis podido entender en qué consiste la traducción de software y los elementos implicados. Por supuesto este tema daría para un libro pero espero que al menos algunos de los conceptos más importantes hayan quedado claros.

Si tenéis más curiosidad os recomiendo la lectura del libro «A Practical Guide to Localization» de Bert Esselink, que he consultado para escribir esta entrada.

Un saludo a todos y hasta la próxima.