¿Es tu aplicación internacionalizable?
Sí, claro: tengo todos los literales en cadenas de recursos, muestro las fechas según la referencia cultural del usuario, utilizo string.Compare para compar 2 cadenas,... Incluso tengo en cuenta el uso horario cuando un usuario introduce una fecha y trabajo con caracteres unicode para admitir idiomas asiaticos. Ves como es internacionalizable. Ah, y por supuesto, tengo en cuenta las diferentes monedas y sus tipos de cambio.
Pues NOOO....
Veamos, cumple con los requisitos mínimos para serlo. Pero eso no quiere decir que esté preparada para desplegarla en cualquier sitio del mundo.
La referencia cultural va más alla de las simples normas de formateo de fechas y números. Se debe tener en cuenta la legislación de cada país e incluso las costumbres de diferentes zonas. Es decir, dentro de la lógica de nuestra aplicación, deberemos incluir reglas de negocio que varían dependiendo del pais.
Veamos un ejemplo: Actualmente estamos montando un sistema que automatiza la creación de usuarios en el directorio activo cada vez que se da de alta un empleado en el departamento de RRHH.
Vale, cuando creo el empleado le digo el nombre, apellidos, dni, oficina en la que trabaja (y por tanto el país, región,...)
Simplificando un poco, el sistema toma la inicial del nombre y el primer apellido y compone el identificador del usuario de windows. Comprobamos que no tenemos un usuario con ese identificador y lo creamos y asignamos un buzón de correo.
Pero... este sistema no funciona en todos los paises.
Pues NOOO....
Veamos, cumple con los requisitos mínimos para serlo. Pero eso no quiere decir que esté preparada para desplegarla en cualquier sitio del mundo.
La referencia cultural va más alla de las simples normas de formateo de fechas y números. Se debe tener en cuenta la legislación de cada país e incluso las costumbres de diferentes zonas. Es decir, dentro de la lógica de nuestra aplicación, deberemos incluir reglas de negocio que varían dependiendo del pais.
Veamos un ejemplo: Actualmente estamos montando un sistema que automatiza la creación de usuarios en el directorio activo cada vez que se da de alta un empleado en el departamento de RRHH.
Vale, cuando creo el empleado le digo el nombre, apellidos, dni, oficina en la que trabaja (y por tanto el país, región,...)
Simplificando un poco, el sistema toma la inicial del nombre y el primer apellido y compone el identificador del usuario de windows. Comprobamos que no tenemos un usuario con ese identificador y lo creamos y asignamos un buzón de correo.
Pero... este sistema no funciona en todos los paises.
- En China, por ejemplo, existen muy pocos apellidos distintos y, además, son muy cortos. Con la regla anterior resultará que tendremos muchos repetidos. Para ellos debemos utilizar un contador. Si por ejemplo el usuario nos sale WLIN y ya existe, pues le ponemos WLIN01, etc.
- En USA, cuando una mujer se casa, adopta el apellido del marido. Ale, a reacer el dni (uy espera, quen USA no existe nuestro concepto de dni ¿no habrás utilizado el campo dni como identificador de un usuario, verdad?). Así que quizá cuando hace login en nuestra web y presentamos el típico saludo bienvenido/a s/sra xxxx, previamente el dpto de RRHH nos tiene que notificar el cambio de estado civil.
- Otro ejemplo más, este más peculiar: en una determinada región de la India (pero no en todo el país), el apellido de los hijos es el nombre del padre. Pero si a una usuaria le pones en su cta. de correo el nombre de un señor (su padre) puede llevar a confusión al que reciba un correo de esta persona.
Pues eso, que solo con cumplir con las recomendaciones de desarrollo nuestra aplicación no está preparada para desplegarse internacionalmente.
saludos
Miguel
Comentarios