Localización y aplicaciones multi idiomas

Localización y desarrollo de aplicaciones multi idiomas.

Son pocas las empresas que desarrollan productos de software con la visión de un posible mercado más allá del propio.

Generalmente se desarrolla pensando en clientes locales, que hablan el mismo idioma que nosotros hablamos, y se tiende a desestimar posibles clientes fuera de nuestras fronteras.

Esto nos lleva a realizar código que necesitará, en un futuro, gran cantidad de re trabajo para poder ser adaptado a diferentes culturas o idiomas.

Es común, en desarrollos que carecen de esta perspectiva, incluir dentro del código, dentro de la lógica de la aplicación, cadenas de texto que representen los mensajes, menús, etiquetas, etc., utilizados para conformar la interfaz del usuario.

Este mal concepto. Este error, nos puede costar mucho, tanto en tiempo como en dinero en el momento que tengamos que portar nuestro desarrollo, de un idioma a otro, o incluso, de un cliente a otro, aunque estos hablen el mismo idioma.

Dentro de todo proceso de desarrollo de software, más o menos avanzado, o mejor dicho, más o menos maduro, existen ciertos pasos que siempre están presentes. Desde el desarrollo que podríamos hacer desde casa, hasta el que se pudiera realizar en una mega empresa, todos estos necesitan de un contacto con el cliente para conocer los requerimientos del sistema, etapas de desarrollo, etapas de pruebas, entre otras, hasta la salida final del producto. Estas etapas representan un costo en tiempo y por consiguiente, un costo en dinero.

Debido a esto, tanto para una empresa pequeña como para una empresa multinacional, el haber creado una aplicación sin una correcta visión de futuro, puede incurrir en más tiempo y más dinero. Para entender esto, supongamos que hemos terminado una aplicación para un cliente específico. Este, habla nuestro idioma, por lo que caímos en el error de haber creado interfaces directamente relacionadas con el idioma y la cultura del mismo. Con el tiempo, el producto gana popularidad, y por cuestiones de mercado, nos vemos en la necesidad de ofrecer el mismo producto pero, en este caso, fuera del país de origen, en un mercado tan distinto en idioma como en cultura. Es indudable que para poder llegar a buen puerto, será necesario volver a abrir el código de la aplicación, y movernos por el, línea a línea, buscando aquellas cadenas de texto que resultaban específicas para el producto en el idioma original. Mas aún, deberemos preocuparnos de las entradas del usuario, esto debido a que el manejo de cierta información, como fechas, valores monetarios, entre otros, cambia de cultura en cultura, por lo que podríamos obtener comportamientos extraños en nuestra aplicación si un usuario ingresa una fecha en el formato mm/dd/aaaa cuando nosotros esperábamos dd/mm/aaaa (ver tabla 1).

Todo esto, requiere pasar nuevamente por los procesos que nos llevaron a desarrollar la aplicación en primera instancia. Nuevamente, desarrolladores codificando y arreglando errores; nuevamente, nuestro código, pasando por etapas de pruebas. Hasta que, finalmente, pueda llegar al cliente. Por supuesto, esto, una vez más, tomó tiempo y dinero. Algo que, actualmente, no podemos darnos el lujo de malgastar.

País

Formato

Estados Unidos

Irlanda

Rusia

Corea

mm/dd/aaaa

dd/mm/aaaa

dd.mm.aaaa

aaaa-mm-dd

Tabla 1. Solo algunos de los tantos formatos.

 

Localizar

En de la idea de localización, podemos encontrar diferentes conceptos.

Conceptos tales como, culturas, el cual hace referencia al idioma y al medio. Esto es, los caracteres involucrados en la escritura de un idioma, y los formatos relacionados al lugar o país especificado. (ver tabla 2).

 

Ámbito

Estándar

Código de idiomas (en, fr, etc.)

Código de países (us, ca, ar, etc.)

ISO 639-1

ISO 3166

Tabla 2. Normas estándar que describen el comportamiento de las culturas.

Como el de localización propiamente dicho. Y esto es, como hemos estado dando algunas pistas antes, separar el código de los recursos relacionados a la aplicación. Esto es, que lo que vemos, no este atado al código desarrollado. Que, por ejemplo, los textos de nuestro menú, estén en un archivo separado, el cual, al ser modificado, no impacte directamente sobre el código realizado.

Por supuesto, los menús no es lo único que podemos localizar. En definitiva, cuando queremos hacer una aplicación lo mas localizable posible, para que se amolde a los cambios de culturas, deberíamos saber que recursos deben ser localizados, esto es, cualquier recurso que pudiera sufrir alteraciones al momento de mover nuestro desarrollo a otras culturas. (ver tabla 3) 

Tipos

Elementos

Contenidos estáticos

Contenidos dinámicos

Contenidos gráficos

Otros

Menús, textos de controles, etc.

Bases de datos, XML, etc.

Imágenes, iconos

Nombre de archivos, cadenas de conexión.

Tabla 3. Ítems para tener en cuenta al momento de localizar una aplicación.

¿Cuándo comenzar?

Con esta idea ya en nuestra cabeza, la pregunta que nos invade es: – ¿Cuándo debemos comenzar a localizar nuestra aplicación? La respuesta es simple: – Antes que cualquier cosa. En definitiva, antes de comenzar con el desarrollo de cualquier línea de código. Esto simplemente porque el código a realizar se nutrirá de los recursos localizados.

Microsoft .Net y localización.

El Framework.Net de Microsoft, trae consigo, las herramientas necesarias para que la tarea de localización de recursos para nuestra aplicación sea simple y rápida.

Dentro del Framework.Net encontramos dos espacios de nombres útiles para esta actividad. El primero; System.Resouces, el cual nos permite manipular archivos de recursos. Estos archivos son archivos en formato XML, los cuales tienen la capacidad de almacenar aquellos recursos (cadenas de texto, imágenes, etc.) de los que dependerá nuestro programa. El segundo; System.Globalization, espacio de nombre que nos otorga los métodos para manipular todo lo referente al idioma y la cultura de la aplicación, por ejemplo, formatos de fechas, formatos monetarios, entre otros.

Archivos de recursos.

Es importante aclarar que existen diferencias en la manera en que estos archivos se manipulan dentro de una aplicación Web, o una aplicación Windows.

A pesar de que, en el contexto general, los archivos de recursos se comportan de la misma forma para los dos ámbitos, Windows y Web, el desarrollador Web es el que obtiene mayores beneficios debido a las herramientas que tiene a su disposición.

Separando el código de la interfaz

Para poder separar completamente nuestro código de aquella información que se mostrará en la interfaz del usuario, como primer paso deberemos agregar un archivo de recursos al proyecto. En el caso de desarrollos Web, este archivo deberá estar localizado dentro de la carpeta App_GlobalResources o App_LocalResources dependiendo del alcance del mismo.

Visual Studio nos muestra una grilla con una combinación de llave/valor para almacenar los distintos recursos de nuestra aplicación.

Una vez hayamos conseguido ingresar una lista de recursos, solo necesitamos asignar, a nuestros controles, los valores que cada uno de ellos deberá mostrar.

Con ASP.net tenemos dos alternativas, la primera, usando la propiedad “expresión” del control en cuestión. Esta propiedad nos otorga la posibilidad de generar un enlace con cualquiera de las propiedades del control seleccionado, por ejemplo, “Text”, y una fuente de datos especifica. En este caso, un recurso de nuestro archivo de recursos. Otra ventaja, es que si usamos herramientas tales como Visual Studio 2005, este trabajo lo podemos realizar sin una línea de código, todo de manera visual.

Solo es necesario colocar el nombre del archivo de recursos, y Visual Studio nos desplegara una lista de todos los recursos que pueden ser asignados a la propiedad seleccionada.

Una vez aplicada la propiedad, podremos notar como, nuestro control, automáticamente toma el valor asignado.

Nuestra segunda alternativa se basa en código. Nuevamente, los desarrolladores Web llevan la de ganar con las prestaciones de Visual Studio 2005, ya que, al crear nuevos archivos de recursos, automáticamente se genera una clase compartida para poder recolectar los recursos disponibles, clase que es adicionada al espacio de nombre Resources.

protected void Page_Load(object sender, EventArgs e)
    {
        this.Button2.Text = Resources.Resource.BotonAceptar;
    }

En este caso, un control del tipo botón obtiene el valor para la propiedad “text” desde los recursos previamente creados. Para entender mejor el funcionamiento de esta clase, debemos destacar que, “Resources”, hace referencia al espacio de nombres del FrameWork.net, “Resource”, es el nombre que, en el momento de creación, le asignamos a nuestro archivo de recursos, y, finalmente, “BotonAceptar” es la llave del recurso específico del cual queremos obtener su valor.

Dos botones, dos formas para hacer uso de los recursos de la aplicación.

La pequeña diferencia con los desarrolladores Windows, radica en que Visual Studio no genera automáticamente esta clase, y el acceso a los recursos debe hacerse mediante el uso del objeto ResourceManager, objeto que el mismo FrameWork.net y Visual Studio hacen uso para poder trabajar con estos archivos.

Para encapsular la funcionalidad del objeto ResourceManager, deberemos generar una clase, la cual nos retornará los recursos solicitados.

    public class ResourceMan
    {
        public string GetResource(string Key)
        { 
            ResourceManager _rm = new 
                 ResourceManager("WinApplication.Resource", 
                 Assembly.GetExecutingAssembly()); 
            return _rm.GetString(Key); 
        } 
    }

Debemos prestar especial atención al primer parámetro utilizado para instanciar el objeto ResourceManager. En este caso, “WinApplication” hace referencia al espacio de nombre general de nuestra aplicación, y “Resource” al nombre del archivo de recursos.

Idiomas y recursos

Una vez separados los textos, mensajes, imágenes, y demás de nuestro código, estamos en posición de pensar en el desarrollo de aplicaciones multi idiomas.

Antes de que ASP.net viera la luz, crear una aplicación Web que soportara múltiples idiomas representaba una tarea colosal. La cual podía llegar a convertirse en una verdadera misión imposible a medida que el tamaño de la misma crecía. Esto, básicamente, debido a que la solución más rápida, o por lo menos, la más conocida para dar solución a este problema, era tener sitios Web alternos, uno para cada idioma. El problema estaba en que mientras mayor era el número de páginas Web que poseía el sitio, más traducciones se debían hacer. Y afrontar cambios en un idioma, representaba cambiar los demás, lo que nos lleva al problema citado al principio. Tiempo y dinero.

Aunque los archivos de recursos no traducen automáticamente nuestro sitio Web, o aplicación Windows, la separación de código del texto, nos da una alternativa, que desde ya, nos reduce trabajo, tiempo y por ende, dinero. Aun deberemos traducir nuestros recursos a diferentes idiomas, pero, la diferencia esta en podremos usar la misma pagina, o el mismo formulario Windows para todos los idiomas que vayamos a implementar.

El primer paso, es crear un archivo de recursos alterno, para un idioma especifico. Este debe contemplar una notación específica, para que el FrameWork.net pueda distinguir entre uno y otro.

Nuestro primer archivo de recursos, Resource.resx, podemos considerarlo como una base o como un archivo neutro. El cual no pertenece a ningún idioma en especial, esto quiere decir que, si quisiéramos “transformar” nuestra aplicación a un idioma que no poseemos, el FrameWork.net usará este archivo para mostrar los recursos que necesitemos. Esto, por supuesto, es una gran ventaja, ya que nos evita posibles errores en el código, y a su vez, nos da la posibilidad de no tener que traducir o modificar un archivo completamente a otro idioma. Pensemos que, dentro de un archivo de recursos podríamos almacenar el logotipo de nuestra empresa, el cual, no necesita ser traducido a diferentes idiomas, por más que el sitio Web, muestre textos en alguna otra lengua.

En todo caso, los nuevos idiomas deberán considerar la siguiente notación; [NombreRecurso].[Cultura-País].resx. Por ejemplo, si nuestro archivo neutro se llama Resource.resx, entonces, un nuevo archivo para el idioma Ingles, y que este, sea de Estados Unidos quedaría de la forma: Resource.en-US.resx

Para que los cambios entre idiomas tengan efecto, es necesario que en todos los archivos de recursos, independientemente del idioma, la llave posea el mismo nombre para el mismo recurso traducido.

Si bien estos pasos nos garantizan tener el contenido traducido, no hacen que nuestra aplicación muestra los cambios. Para ello es necesario agregar algo de código a lo ya planteado.

Thread.CurrentThread.CurrentUICulture = new System.Globalization.CultureInfo("en-US");

Esta simple línea modifica el hilo actual de ejecución, y asigna una cultura para la interfaz del usuario, especifica para el idioma Ingles. Con esta línea, el FrameWork.net automáticamente buscara el archivo de recursos correspondiente a la cultura seleccionada y traerá de él los recursos requeridos.

Conclusiones

Un planteamiento temprano en la necesidad de separar el código de los recursos en el desarrollo de nuestras aplicaciones, nos preparará para afrontar posibles cambios de interfaz sin tener que afectar el núcleo del programa. Esto nos garantiza que el producto seguirá funcionando correctamente, ahorrándonos tiempo y dinero. Además, que dentro del concepto .Net, nos acerca a posibilidades, como la creación de aplicaciones con soporte multi idioma, de una manera fácil.


One Comment on “Localización y aplicaciones multi idiomas”

  1. leandro dice:

     
    Hola, muy bueno el articulo sobre resources, tendrias algun ejemplo que me puedas guiar?
     
    Yo lo estoy haciendo en vb.net,
     
    Me podrias explicar la linea del Thread? en el vb.net aparece que no la reconoce
     
    ¿que imports usas?
     
    Saludos y Gracias


Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s