Cuando hay que adaptar un programa para que se pueda utilizar en varios países, lo primero en lo que piensa uno es en las traducciones. Sin embargo, traducir un programa a otro idioma no es más que el primer paso.
La gente que estudia la adaptación del software y del hardware para que se pueda utilizar en varias partes del mundo distingue entre dos conceptos. El primero es la internacionalización, que consiste en modificar el sistema (software, hardware, …) para que sea posible adaptarlo a otro país, otro idioma, otra cultura… El segundo paso es la localización, que consiste en tomar un sistema y adaptarlo a un país, idioma y cultura concretos.
Como los que se dedican a ese tema utilizan las palabras “internacionalización” y “localización” muy a menudo, las han abreviado, llamando a la primera i18n y a la segunda l10n. Estos jeroglíficos son fáciles de recordar si se observa que la palabra “internacionalización” empieza por la letra “i”, le siguen 18 letras, y termina por la letra “n”, (“i”-18-“n”) y que la palabra “localización” empieza por la “l”, le siguen 10 letras, y termina también en “n” (“l”-10-“n”). Anda que son listillos…
Si uno quiere que un programa quede bien localizado, antes tiene que estar bien internacionalizado. Lo mínimo es que se pueda traducir; para ello existe un montón de sistemas, entre los cuales mi favorito es GNU Gettext. Con Gettext, el programador tiene que marcar las cadenas de texto que el usuario va a ver; después, con un conjunto de herramientas especiales esas cadenas se pueden extraer, y luego los traductores pueden trabajar sobre esas cadenas, traducirlas y hacer que el programa pueda utilizar esas traducciones sin tener que recompilarlo. Existen herramientas para editar traducciones, actualizar traducciones para adaptarlas a nuevas versiones de los programas, gestionar traducciones que proceden de muchas fuentes, etc.
Pero la traducción del software no es lo único que se ha de tener en cuenta. Por ejemplo, el programa debería aceptar (y tratar correctamente) caracteres propios de idiomas distintos del inglés. Hasta no hace mucho, muchos programas no podían tragar la eñe, y ahora se les pide que traguen la eñe (ñ), el sigma (Σ), el alef (א), unos cuantos caracteres árabes como ش, ت o ﺿ, e incluso unos cuantos caracteres coreanos (y, lamentablemente, acabo de ver que no tengo instalado un tipo de letra coreano). Para esto, el programa debe utilizar correctamente Unicode, un conjunto de especificaciones para la codificación y empleo de los alfabetos de los lenguajes de todo el mundo. Hay un montón de idiomas y un montón de reglas, pero afortunadamente, es relativamente fácil hacerlo… pero antes hay que saber que todo eso existe.
Lo que separa a la gente no es sólo el idioma. Otra cosa que se ha de tener en cuenta al internacionalizar un programa es que en distintas partes del mundo se utilizan distintos estándares. Por ejemplo, los estadounidenses pagan y cobran en dólares, miden en pulgadas, pesan en libras e imprimen en papel de tamaño “legal” o “letter”, mientras que los españoles pagamos y cobramos en euros, medimos en metros y centímetros, pesamos en kilogramos e imprimimos en papel de tamaño DIN A4. Además, cuando te dan un precio, los estadounidenses ponen el símbolo del dólar antes del número ($400) y los españoles ponemos el símbolo del euro después del número (400 €). Ellos usan un punto para separar los decimales y una coma para separar los miles (4,394,394.93), y nosotros al revés (4.394.394,93). Y ellos escriben las fechas poniendo el día entre el mes y el año (03-24-1999) y nosotros ponemos el mes entre el día y el año (24-03-1999).
Por si esto parecía poco, los japoneses dan las fechas diciendo primero el año, luego el mes y finalmente el día (1999-03-24), y los indios (de la India) no escriben los números separando los dígitos de tres en tres, sino de dos en dos a partir del cuarto (4,39,4394.93).
Todas esas diferencias, y muchas más, se han de tener en cuenta al internacionalizar un programa. Afortunadamente, los sistemas operativos proporcionan funciones para formatear correctamente los números y las fechas, y los sistemas de impresión saben qué tipo de papel han de ofrecer al usuario según el país en el que se encuentre. Igual que antes, no es difícil; sólo es necesario saber que todo esto existe.
Pero aún hay más. Si su programa trata datos de usuarios, tendrá que tener en cuenta que en cada país los datos que ha de solicitar son distintos. Por ejemplo, en los Estados Unidos tienen un solo apellido, mientras que en España tenemos dos apellidos (el primero del padre y de la madre, respectivamente). En Portugal también tienen dos apellidos, pero son el segundo de la madre y del padre, respectivamente (además, el segundo apellido es el que se utiliza para ordenar listas o cuando se abrevia el nombre). En Rusia, además de nombre y apellido tienen patronímico. Los nativos de Java no tienen apellido. Los húngaros dicen el apellido antes que el nombre.
Y esto para empezar: en muchos países no se utilizan códigos postales (o no se utilizan fuera de algunas ciudades, como en Irlanda), las direcciones se escriben de forma muy diferente dependiendo del país, las madres pueden no tener apellidos de soltera…
Por eso es recomendable que dejen a los usuarios bastante libertad para proporcionar su información, si pretenden que puedan acceder usuarios de todo el mundo: hay tantas variantes, que preverlas todas es muy complicado.
Y hasta aquí mi “pequeño” artículo de hoy. Espero que estén tan maravillados como yo por todas las formas de complicarse la vida que puede inventar el ser humano. Si les ha gustado el tema y quieren que escriba más sobre él, en mi wishlist de Amazon hay un libro sobre internacionalización; ustedes me lo compran, yo me lo leo y escribo.
Si cuela, cuela.