Es muy posible que, durante los estudios de programación y durante los primeros años de “vida profesional” de un programador, nunca se piense “a lo grande” y nunca nos venga a la cabeza la posibilidad de que lo que estamos programando pueda llegar a utilizarse más allá de nuestras fronteras.

Y puede pasar. De hecho, pasa. A nosotros nos ha pasado.

Antes de seguir adelante contando nuestra experiencia, nos gustaría definir lo que es internacionalización y lo que es localización.

Según el W3C, la localización del software es la adaptación de un producto a un mercado internacional concreto. Esta adaptación comprende las traducciones al idioma correspondiente o la configuración de la moneda y zona horaria locales, entre otras cosas. En nuestra experiencia, esta es la parte “fácil”.

Sin embargo, la internacionalización es la parte más “complicada” (si no se tiene en cuenta desde el minuto cero). La internacionalización se refiere a todas las estructuras internas que va a tener nuestro software para poder hacer “fácil” la localización. Hablamos de estructuras de datos que soporten cualquier zona horaria o cajas de texto configurables para mostrar diferentes separadores de decimales a la hora de mostrar un precio o la posibilidad de mostrar el símbolo de la moneda tanto a la derecha como a la izquierda (¿a que esto no lo habíais pensado?).

La internacionalización también incluye la toma de decisiones muy importantes sobre cómo se van a guardar los datos que pueden cambiar en diferentes localizaciones. Por ejemplo, hay monedas que tienen una, dos o tres posiciones decimales, por lo que es importante guardar los precios expresados en base mil, por ejemplo (luego ya se dividirá en base al número de decimales de la moneda). Y luego están las fechas y las horas, las cuales es conveniente guardar siempre en formato UTC para luego ser “traducidas” a la zona horaria correspondiente.

Nosotros hemos aprendido todo esto por el camino difícil.  Cuando surgió la necesidad, tuvimos que internacionalizar nuestro software cuando ya llevaba años funcionando sin problemas dentro de nuestras fronteras, sin tan siquiera sospechar que llegaría un momento en el que tendría que “sacarse el pasaporte”. Y no ha sido fácil, pero ha sido posible.

Nuestro principal quebradero de cabeza han sido las fechas y las horas: podréis imaginar que tener la información correcta de la fecha y hora de los miles de eventos que ofrecemos a diario es un punto crítico en nuestro sistema. En concreto, para resolver este problema, ha sido necesaria la colaboración entre varios equipos (desde Base de Datos hasta los equipos de frontales pasando por los servicios intermedios) porque, tal y como hemos comentado antes, ha habido que tomar la decisión de elegir un formato de referencia. En nuestro caso, hemos elegido guardar todas las fechas y horas en UTC, lo cual os recomendamos, y convertirlas al formato preferido del cliente justo antes de mostrarlas en la interfaz gráfica. En este sentido, .Net ofrece unas estructuras muy bien planteadas que hacen esta conversión totalmente transparente al programador.

Ahora, en nuestros nuevos desarrollos, tenemos en cuenta que nuestro software puede ejecutarse en cualquier parte del mundo y hemos incluido la internacionalización como uno de los puntos en el proceso de diseño:

  • se identifican todos los datos que cambian según dónde se ejecuten las aplicaciones: fechas, horas, monedas (y, por supuesto, su correspondiente formato)
  • se eligen los formatos de referencia de todos los datos implicados (y se confirma con el resto de equipos afectados)
  • se eligen estructuras de datos adecuadas

La conclusión es clara: es mejor tener en cuenta todo lo hablado en este artículo que tener que programar dos veces. Y vosotros ¿habéis tenido alguna experiencia similar? ¿Tenéis en cuenta la internacionalización en vuestros procesos de diseño software?

Os dejamos la guía de Microsoft para la internacionalización de aplicaciones .Net, para nosotros fue una buena fuente de información y un buen punto de partida.