Una localización bien hecha (o casi)

La localización es una de esas cosas que parecen un simple ajuste de configuración en tu IDE y que acaban convirtiéndose en una conversación de seis meses con desconocidos sobre el género de los sustantivos.

Para un pequeño estudio, también es una de las mejores inversiones que podemos hacer. Una aplicación para aprender a teclear, un planificador de jardines o una herramienta para llevar un seguimiento de las migrañas resultan igual de útiles en Lisboa que en Londres, y la gente tiende a confiar mucho más en una aplicación que se comunica con ellos en su propio idioma. El problema es que hacerlo bien supone mucho más trabajo de lo que parece a primera vista.

Nuestra configuración

En primer lugar, lanzamos la aplicación en inglés y, a lo largo de su ciclo de vida, vamos añadiendo más idiomas. Cada traducción se revisa en su contexto comparándola con capturas de pantalla de la interfaz real, y corregimos cualquier error antes de su lanzamiento.

El paso de la revisión en contexto es el que la mayoría de los equipos se saltan, y es ahí donde surgen la mayoría de los problemas. Una traducción puede ser perfectamente correcta en una hoja de cálculo y, aun así, resultar errónea en pantalla: el texto de un botón que es correcto, pero que ocupa el doble de espacio del que tiene disponible; una palabra que significa lo correcto en general, pero lo incorrecto junto a un icono concreto. Por eso generamos capturas de pantalla de cada pantalla en cada idioma y las revisamos una por una.

Además, redactamos el texto en inglés pensando en la traducción. Frases cortas, sin expresiones idiomáticas ni bromas basadas en juegos de palabras. Las secuencias que requieren contexto —¿“Clear” es aquí un verbo o un adjetivo?— van acompañadas de una nota para el traductor. Esto hace que el inglés resulte un poco más sencillo, y creemos que es mejor así.

Las partes que no saltan a la vista

Los formatos de fecha y número son más importantes que el texto traducido. Las formas plurales varían según el idioma de una manera que los angloparlantes suelen subestimar (algunos idiomas tienen hasta seis). Los diseños de derecha a izquierda no son un simple truco de CSS: influyen en cómo se dibuja cada flecha, cada botón de retroceso y cada indicador de progreso.

Otras cuantas cosas más a las que hemos aprendido a prestar atención:

• Expansión de texto. Las etiquetas en alemán y finés pueden ser mucho más largas que las de inglés, por lo que los diseños deben tener espacio suficiente para ampliarse o ajustar el texto de forma adecuada.
• Unidades. Una previsión de pesca que indique la velocidad del viento en una unidad desconocida no solo resulta extraña, sino que además es inútil.
• Fichas de las tiendas. La aplicación es solo la mitad del trabajo: las descripciones, las capturas de pantalla y los pies de foto también deben traducirse, por separado para cada tienda.
• Teclados. Para un programa de aprendizaje de mecanografía, la localización no se limita a las palabras, sino que abarca también las distribuciones, los caracteres y la forma en que la gente escribe realmente en ese idioma.

En qué nos equivocamos

Todos hemos cometido cada uno de estos errores al menos una vez. El más costoso fue considerar la localización como un paso final: crear toda la interfaz en inglés y descubrir después que la mitad de las pantallas no funcionaban correctamente en idiomas con más palabras. Corregir los diseños a posteriori supuso rediseñar pantallas que ya habíamos dado por terminadas.

La concesión que ahora aceptamos es que los primeros lanzamientos sean más lentos: una nueva función no se da por terminada hasta que funcione en todos los idiomas que admite la aplicación. Nuestra lista de comprobación empieza ahora con las correcciones de estos errores, por lo que los cometemos con menos frecuencia. «Casi correcto, la mayoría de las veces» es la versión más honesta del título.