viernes, 11 de septiembre de 2009

Internacionalización (I). Problemas.

La internacionalización, también llamada i18n, según la Wikipedia puede definirse como "el proceso de diseñar software de manera tal que pueda adaptarse a diferentes idiomas y regiones sin la necesidad de realizar cambios de ingeniería ni en el código". Se trata de un concepto muy amplio que abarca desde ser capaz de modificar dinámicamente los mensajes mostrados al usuario (por defecto, suelen estar en inglés) hasta mostrar la interfaz construida de derecha a izquierda como ocurre en los países árabes, pasando por tener en cuenta las costumbres regionales a la hora de presentar los iconos, por ejemplo.
Como dijimos al hablar de los criterios de selección de plataformas, la i18n es uno de los fundamentales sobre en todo países o regiones con diversidad lingüística en donde se dispone de varios idiomas oficiales. Si éste es el caso, una vez seleccionadas las herramientas que se pondrán a disposición de los usuarios, resulta imprescindible probarlas concienzudamente en los idiomas requeridos, haciendo especial hincapié en los problemas de internacionalización más comunes y que, a modo de resumen, son los siguientes:

  1. Mensajes de la interfaz de usuario: lo habitual es que los mensajes mostrados en la interfaz de usuario estén contenidos en ficheros de texto, tal y como ocurre en Moodle (paquetes de idiomas) y en Sakai (ficheros de properties). Sin embargo, puede ocurrir que nos encontremos con alguna herramienta en la que aparecen en inglés independientemente del idioma seleccionado. Esto, generalmente, se debe a alguno de los dos siguientes errores de i18n:
    • El mensaje en cuestión es incluido "tal cual" en el código fuente: en este caso, habrá que editar el código fuente y parametrizarlo adecuadamente, incluyendo el mensaje problemático y su correspondiente traducción en un paquete de idioma (caso de Moodle) o en un fichero de properties (caso de Sakai)

    • El mensaje está el fichero de recursos en inglés pero no en el del idioma seleccionado: la solución es muy sencilla y consiste en incluir la traducción del mensaje en el fichero del idioma seleccionado.


  2. Las listas de nombres (por ejemplo, alumnos) no se ordenan correctamente: desgraciadamente, éste es uno de los problemas más comunes. Se debe a las diferencias en el esquema de codificación esperado por la plataforma. Por este motivo, se recomienda utilizar UTF-8, juego de caracteres que contiene todos los símbolos de nuestro entorno.

  3. Formato de los calendarios: el día considerado como comienzo de la semana varía de unos países a otros. Por ejemplo, en España se considera que la semana comienza en Lunes mientras que en los países de habla sajona, convierten al domingo en su primer día semanal.
    En esta misma línea conviene revisar el formato de fechas, ya que algunas aplicaciones fallar con formatos de fechas diferentes del que tienen por defecto. La solución pasa por parametrizar el formato de las fechas y, en caso de no ser posible, por hacer una conversión del formato del usuario al formato con el que trabaja la herramienta.

  4. Formato de los números:hay que tener cuidado con la separación entre la parte entera y la parte decimal. Mientras que en España se emplea la coma como separador, en los países sajones se utiliza el punto. La solución es formatear los números en función del idioma seleccionado o bien incluyéndolo como un parámetro más de la instalación.

  5. Información de estado: este tipo de información debe ser independiente del idioma. Si no lo fuera, podría ocurrir, por ejemplo, que un mensaje de un foro apareciera en la carpeta de mensajes "Received" cuando se está visualizando en inglés pero no lo hiciera en la carpeta "Recibidos" al verlo en español. La solución suele ser almacenar en base de datos un código de estado y mostrar por pantalla una descripción del mismo consultando los ficheros de properties o los paquetes de idiomas correspondientes.

  6. Aplicaciones que están internacionalizadas pero toman el idioma del navegador o del servidor de aplicaciones y no permiten al usuario modificarlo dinámicamente: como ejemplo, algunas aplicaciones de Sakai basadas en Spring (algunas páginas de Samigo, por ejemplo) usan el idioma del Tomcat. E internet está lleno de formularios web que toman el del navegador (contribución de Daniel Merino Echeverría).


En la próxima entrada aprenderemos a comprobar el estado de la internacionalización en Sakai y en Moodle. Nos vemos la semana que viene.

1 comentario:

  1. Hola, David. Te falta añadir un problemilla más a todos estos: las aplicaciones que están internacionalizadas pero toman el idioma del navegador o del servidor de aplicaciones y no permiten al usuario modificarlo dinámicamente.

    Como ejemplo, algunas aplicaciones de Sakai basadas en Spring (algunas páginas de Samigo, por ejemplo) usan el idioma del Tomcat. E internet está lleno de formularios web que toman el del navegador.

    Salu2

    ResponderEliminar