Hoy en día, con el fenómeno de la globalización, los desarrolladores tenemos la necesidad de adaptar nuestras aplicaciones a clientes de distintos países y regiones. Esto implica soportar tanto su idioma, como sus características locales, es decir, la localización de una aplicación.
Traducción y localización, dos conceptos distintos
Para conseguir que un usuario esté satisfecho con nuestro desarrollo, se necesita que se hayan realizado correctamente las labores de traducción y localización.
La traducción hace referencia al proceso de mostrar las palabras y las frases visibles de la aplicación, en el idioma del usuario. Si tienes interés en conocer cómo crear aplicaciones multilingües, te invito a visitar el artículo que publicamos hace poco sobre este tema.
La localización es un concepto más sutil, ya que hace referencia a adaptar el desarrollo a las particularidades regionales de cada usuario. Un ejemplo sencillo, en el que se aprecia claramente la necesidad de localizar una aplicación, es el formato de las fechas en los distintos países. En España de manera general se usa el formato dd/mm/yyyy para representarla. Por ejemplo el 2/3/2017 representaría el 2 de marzo de 2017. Sin embargo en Estados Unidos el formato que emplean para las fechas es mm/dd/yyyy, por lo que la fecha anterior se representaría como 3/2/2017. Es decir, la misma representación puede significar fechas completamente distintas según quien la lea.
Lo mismo ocurre con otros formatos, como las monedas o los números.
Los problemas que intenta resolver la localización
El mayor problema asociado a la localización, sucede cuando se trabaja en un ambiente internacional. Esto se debe a que los distintos socios van a generar y cargar datos procedentes de otros socios, los cuales tienen distinta localización. Entonces, si no estamos avisados, nos encontramos ante la paradoja de utilizar los datos tal cual, a sabiendas de que pueden haber sido generados con otra localización, o intentar adivinar la localización con la cual se crearon.
Si bien podría parecer que este problema solo se circunscribe a las fechas, el mismo vuelve a aparecer cuando utilizamos, por ejemplo, cantidades monetarias. Analizando la localización más en profundidad, se llega a la conclusión de que esta obliga a conocer la simbología y paletas de colores usuales de cada región, lo cual complica mucho el trabajo.
En este artículo nos vamos a centrar en la localización de una aplicación, utilizando como ejemplos la gestión de las fechas, los números y las monedas.
Localizando una aplicación que muestra números, monedas y fechas
Como ejemplo de estudio, te voy a enseñar a desarrollar una aplicación que utilice números, monedas y fechas en los formatos regionales de Estados Unidos y de España. La elección de este ejemplo no es aleatoria:
- En los números decimales, hay regiones que utilizan como separador decimal la coma y otros el punto. Los separadores de miles suelen invertirse también.
- En las fechas, nos encontramos con multitud de formatos tanto para una misma región, como entre varias regiones.
- En el caso de las monedas, cada país tiene una moneda propia y además el símbolo se puede colocar en diferentes lugares (en España el € se coloca después de la cifra y en EEUU el $ delante, por ejemplo).
Para poder desarrollar una buena localización, es necesario trabajar con datos cuya representación no sea dependiente de la plataforma. Por ejemplo, los números reales se guardan como el valor de la mantisa y el exponente, sin embargo, si el número lo tenemos en una cadena de caracteres, como por ejemplo "123,5", la localización automática no va a funcionar.
Un pequeño ejemplo de localización
El siguiente código, muestra un pequeño ejemplo del resultado que obtenemos al utilizar la localización:
DateTime fecha = new DateTime(2010,10,30);
double cantidad = 1.75;
double coste = 2354.24;
var a = CultureInfo.CurrentCulture;
Console.WriteLine("El día {0} compré {1}kg de oro por {2:C}",fecha.ToShortDateString(),cantidad,coste);
Console.WriteLine("En dólares: {0}", (coste*1.1).ToString("C",CultureInfo.CreateSpecificCulture("en-US")));
Thread.CurrentThread.CurrentCulture = new CultureInfo("en-US");
Thread.CurrentThread.CurrentUICulture = new CultureInfo("en-US");
Console.WriteLine("El día {0} compré {1}kg de oro por {2:C}", fecha.ToShortDateString(), cantidad, coste);
El resultado de la ejecución del código anterior es el siguiente:
Como se puede apreciar, la primera línea utiliza el formato de España. Por ello la primera pareja de números de la fecha, hace referencia al día, y aparecen tanto el separador decimal, como el de las unidades de mil y el símbolo del euro.
En la siguiente línea, indico que quiero que me muestre una cantidad con formato de moneda, pero utilizando el estilo de Estados Unidos. Esto hace que cambie el símbolo de la moneda y su posición, así como el uso de la coma y el punto en la cantidad.
Justo a continuación lo que he hecho es cambiar el idioma de la aplicación con Thread.CurrentThread.CurrentCulture (para el código) y con Thread.CurrentThread.CurrentUICulture (para la interfaz de usuario), esto hace que se aplique la localización de Estados Unidos. Como resultado puedes ver que cambian: el formato de la fecha, siendo la primera pareja de números el mes, la coma decimal, el separador de las unidades de millar y el símbolo de la moneda.
Para conseguir que el símbolo del euro (€) me saliera por pantalla, he necesitado cambiar la codificación de la terminal (CMD o PowerShell) a UTF-8. Si no haces esto, lo más probable es que te salga un símbolo de interrogación en su lugar. El siguiente GIF animado muestra cómo cambiar el codepage de una línea de comandos:
Cultura actual y cultura actual de la interfaz de usuario
Es interesante notar la diferencia entre CurrentCulture y CurrentUICulture, ya que usamos ambos en el fragmento anterior.
Mientras que el primero se refiere a la cultura utilizada para el proceso actual, el segundo se refiere a las operaciones que tienen que ver con la interfaz de usuario, como por ejemplo recuperar cadenas de idioma de un archivo de recursos (como vimos en el anterior artículo).
Un ejemplo para ayudar a entender mejor la diferencia, ya que la documentación no lo deja muy claro, sería lo que hacemos muchos usuarios avanzados del sistema operativo: usamos el S.O. en inglés pero queremos que los formatos se muestren en nuestro idioma nativo (español en mi caso).
En este ejemplo el CurrentCulture sería el de nuestro formato regional (es-ES) y el formato automático de fechas, números, etc... se haría usando los ajustes de esa región. El CurrentUICulture sería, sin embargo, en-US ya que queremos que la interfaz de usuario sea en inglés, y por lo tanto la aplicación va a buscar las cadenas de este idioma.
Unidades de medida
Todavía hay más cosas a tener en cuenta y que son más difíciles de resolver que lo que hemos visto. De hecho en nuestro mismo ejemplo podríamos haber afinado más la adaptación cultural y mostrar el peso del oro en libras, ya que los estadounidenses no entienden bien las medidas en el sistema internacional y a los usuarios de esta nacionalidad les resultará más fácil si se lo convertimos.
En otros tipos de unidades de medida la cosa es aún más complicada. Por ejemplo, en unidades de volumen el sistema internacional utiliza litros o centímetros cúbicos, pero los anglosajones utilizan galones si bien los americanos solo para líquidos y los británicos tanto para líquidos como para otras medidas de volumen "secas". Y la pinta americana no es igual a la británica ya que una se basa en el galón y la otra en el galón imperial...
Extremadamente complicado. Este tipo de casos requieren un estudio específico de las necesidades de nuestra aplicación y aplicar conversiones manuales para todo ello.
En resumen
Como puedes ver, la localización junto con la traducción es necesaria si quieres conseguir público internacional para tu producto. La traducción es más o menos directa y sencilla, pero la localización puede llegar a complicarse mucho y la plataforma nos ayuda solo hasta cierto punto.
Espero que este artículo te haya servido para conocer sus diferencias, así como para aprender a implementar los casos más comunes.
Puedes descargarte el pequeño ejemplo que hago más arriba desde aquí (ZIP - 3,88KB).
Crédito de la foto de cabecera: Andreas-photography / CC BY-NC