Internacionalización en ASP.NET MVC

Cuando hacemos una aplicación, puede darse la situación de que conozcamos el segmento de usuarios que la utilizará y el idioma en el que habla. Pero puede ser que nuestra aplicación sea de propósito general, con posibilidad de tener acceso por parte de usuarios de distintas países y con distintos lenguajes.

Para afrontar esta situación ASP.NET MVC nos ofrecer varias facilidades, haciendo la tarea relativamente sencilla.

Lo primero que debemos hacer es modificar el Web.Config de nuestra aplicación, de modo que pueda obtener la configuración de cultura del cliente que accede a nuestra aplicación.
Bajo las etiquetas configuration -> system.web agregaremos la siguiente línea de configuración:

Configuración de cultura en Web.Config
Configuración de cultura en Web.Config

Esta línea habilitará al framework para que tome la cultura del cliente, definiendo así el lenguaje en el que se mostrará el contenido de la aplicación.

Como segundo punto, debemos crear los archivos de recursos. Estos serán los que almacenen el contenido traducido para cada lenguaje (o cultura particular) que nuestra aplicación tenga que soportar. Para agregarlos buscamos la opción “Archivo de recursos” al agregar un nuevo elemento:

Archivo de recursos
Opción para agregar nuevo archivo de recursos

Hay distintas alternativas sobre donde ubicar estos archivos, dependiendo de la arquitectura y tamaño de la aplicación. Podemos crear una carpeta Resources, donde ir incluyendo los distintos archivos de recursos que manejaremos dentro del mismo proyecto Web, o crear nuevo proyecto de tipo “Biblioteca de clases” y allí agregar los archivos de recursos.
Para pequeñas aplicaciones o casos particulares (como lo es este ejemplo) es preferible mantenerlos en el mismo proyecto Web. Para aplicaciones más grandes, donde necesitamos tener una mayor separación de los distintos elementos y donde los archivos de recursos serán numerosos, organizarlos en un nuevo proyecto puede ser lo más conveniente (y mantenible).

Otra cuestión a considerar es la cantidad contenido que tendrá cada archivo. Es recomendable tener separado archivos por distintos ámbitos que maneje la aplicación, siendo la cantidad de elementos que tenga cada uno equilibrada pensando en su mantenibilidad. Ni un solo archivo con todo el contenido, ni muchos archivos con solo unos pocos elementos.

Siguiendo con el ejemplo creamos el archivo Shared.resx, el cual usaremos para el contenido de prueba para este ejemplo.
La estructura de estos archivos es muy sencilla: solo debemos especificar un nombre (al cual se hará referencia posteriormente), el contenido y opcionalmente un comentario.

Contenido recursos
Recursos agregados en español

Un punto a tener en cuenta es que para poder acceder a estos archivos debemos modificar el acceso por defecto que es Internal a Public. Es un detalle menor, pero puede generar varios dolores de cabeza.

Ahora que ya tenemos nuestro archivo de recursos creado con el contenido, debemos referenciarlo desde la vista en cuestión. Para ello reemplazamos el contenido estático por el nombre definido en el archivo de recursos:

Recursos Vista
Recursos aplicados en la vista

Si corremos nuestra aplicación ahora no veremos ningún cambio, ya que estamos colocando los mismos nombres que estaban puestos anteriomente. Lo que debemos hacer ahora es agregar los archivos de recursos para las otras culturas a las que le daremos soporte.
El mecanismo de resolución del framework para decidir que archivo de recurso utilizar es bastante sencillo:

  • Como primer punto busca una coincidencia en la cultura completa del usuario, como puede ser es-ar. Si hay coincidencia, usa ese archivo.
  • Si no hubo coincidencias, busca solo por el lenguaje. Siguiendo en el ejemplo anterior, si no encontró resultados para es-ar busca coincidencias solo para es.
  • Si tampoco hubo coincidencias, busca el archivo de recursos que no tiene especificado lenguaje.

Este mecanismo nos trae grandes ventajas como desarrolladores. En primer término poder crear archivos generales para un lenguaje sin tener que repetir contenido para distintas culturas. Si bien hay diferencias entre los distintos países que hablamos español en américa latina, no parece necesario al menos al principio hacer una diferenciación de este tipo. A su vez, podemos definir un idioma por defecto en nuestra aplicación, el cual será visible para aquellos usuarios cuya configuración de idioma no haya encontrado coincidencias (en este ejemplo sería el archivo Shared.resx en español).

Ahora agreguemos un nuevo idioma, por ejemplo el inglés. Para ello debemos crear junto con el archivo anterior uno nuevo, denominado Shared.en.resx.
Lo que referenciamos en negrita (en este caso en) es la referencia cultural que queremos que coincida. Para este caso será como dijimos para los hablantes de inglés, sin referenciar culturas particulares. En caso de querer hacerlo, cambiamos en por en-us.

ArchivoRecursoIngles
Archivo de recursos en inglés

Como se ve en la imagen, debemos mantener los mismos nombres en los distintos archivos de recurso. Lo bueno de este mecanismo es que para agregar un nuevo idioma o cultura, solo debemos agregar el/los archivos de recursos correspondientes. Las vistas que los utilizan ya hacen referencias a los mismos, por lo que ese trabajo ya está hecho.

Ahora corremos la aplicación, con dos navegadores (Chrome configurado en español y Firefox en inglés). Vemos que sin tener que hacer ningún trabajo adicional, ya tenemos la aplicación en diferentes idiomas:

DiferenciasIdioma
Aplicación en diferentes idiomas

El trabajo de base ya está hecho. Solo queda agregar los idiomas necesarios y el contenido correspondiente.

Esta tarea siempre es más fácil realizarla al mismo tiempo que se inicia el proyecto, o con poco avance. Sin embargo, es totalmente viable realizarlo en aplicaciones que ya están en funcionamiento. Requerirá el trabajo adicional de verificar todas las vistas existentes y realizar las modificaciones correspondientes.

Otro punto a tener en cuenta es la variación en el tamaño para un mismo contenido en diferentes idiomas, además del sentido de escritura que estos tengan. Son aspectos puntuales, pero que puede ser necesarios tener en cuenta.

Esto es todo por este post. En algunos post a futuro veremos otros puntos adicionales asociados a la internacionalización.

Anuncios

7 comentarios en “Internacionalización en ASP.NET MVC

  1. Excelente, es la misma manera como lo hago en WebForms, pero en MVC cómo hago para validar entradas de usuario, como fechas, numeros con decimales, etc…. para las diferentes culturas?

    Me gusta

    • Gracias por tu comentario Oscar.
      La verdad que no tuve la oportunidad de trabajar con un caso práctico de internacionalización que incluya validaciones en las entradas de usuario.
      Prometo un post próximamente explicando como realizarlo.

      Me gusta

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