Globalización
Una aplicación que puede presentar información a los usuarios según las convenciones culturales regionales se dice que está globalizada: la aplicación se puede configurar para interactuar con usuarios de distintas localidades respetando las convenciones culturales. En una aplicación globalizada, el usuario de una región ve los mensajes de error, la salida y los elementos de la interfaz en el idioma solicitado. Los formatos de fecha y hora, así como la moneda, se presentan según corresponda a los usuarios de la región especificada. Un usuario de otra región verá la salida en el idioma o formato convencional de su región. La globalización consta de dos fases: internacionalización (que permite que un componente de aplicación utilice el soporte multicultural) y localización (que traduce e implementa una convención regional específica).
Históricamente, la creación de aplicaciones globalizadas ha estado restringida a grandes corporaciones con sistemas complejos. No obstante, dado el aumento de sistemas distribuidos y el uso de Internet, los desarrolladores de aplicaciones se han visto obligados a globalizar una variedad más amplia de aplicaciones. Esta tendencia requiere que las técnicas de globalización se hagan más accesibles para los desarrolladores de aplicaciones.
La internacionalización de una aplicación está controlada por dos variables, el huso horario y el entorno local. El huso horario indica cómo se calcula la hora local a partir del desplazamiento de la hora media de Greenwich. El entorno local es una recopilación de información sobre el idioma, la moneda y las convenciones para presentar información, por ejemplo, la fecha. Un huso horario puede cubrir varios entornos locales, y un entorno local pueden incluir varios husos horarios. Con el huso horario y el entorno local, se puede determinar la fecha, la hora, la moneda y el idioma de los usuarios de una región específica.
Según una convención, un entorno local determinado se especifica mediante un par de códigos (correspondientes al idioma y a la región) regidos por distintos estándares. El estándar ISO-639 rige el código de idioma, mientras que el estándar ISO-3166 determina el código regional. En la notación, ambos códigos suelen aparecer unidos por un carácter de subrayado (_), por ejemplo: es_ES corresponde al español de España. En el código Java™, los entornos locales se establecen y se recuperan mediante la clase java.util.Locale.
Primer paso: localización de series de interfaz
En una aplicación no globalizada, la interfaz de usuario está escrita en el código de la aplicación, sin posibilidad de modificación. La internacionalización de una interfaz de usuario añade una capa de abstracción al diseño de una aplicación. La capa de abstracción adicional permite localizar la aplicación para cada entorno local que debe estar soportado en la aplicación.
En una aplicación localizada, el entorno local determina el catálogo de mensajes del que recupera las series de mensajes la aplicación. En lugar de imprimir un mensaje de error, la aplicación representa el mensaje de error con información en un lenguaje neutro; en el caso más sencillo, cada condición de error se corresponde con una clave. Para imprimir un mensaje de error utilizable, la aplicación busca la clave en un catálogo de mensajes. Cada catálogo de mensajes es una lista de claves con series asociadas. Los distintos catálogos de mensajes proporcionan series para cada uno de los idiomas soportados. La aplicación busca la clave en el catálogo adecuado, recupera el mensaje de error correspondiente en el idioma solicitado e imprime la serie para el usuario.
La localización del texto tiene un uso más amplio que la simple traducción de mensajes de error. Por ejemplo, se pueden utilizar claves para representar cada uno de los elementos de una GUI (interfaz gráfica de usuario) y proporcionar los catálogos de mensajes adecuados para que la GUI (los botones, los menús, etc.) pueda dar soporte a varios idiomas. Para ampliar el soporte a otros idiomas, deberá proporcionar catálogos de mensajes de esos idiomas; en muchos casos, la aplicación no necesita más modificación.
El paquete de texto localizable es un conjunto de clases Java e interfaces que se puede utilizar para localizar fácilmente las series en aplicaciones distribuidas. Los catálogos de series específicas del idioma se pueden almacenar centralmente, para que se puedan mantener correctamente.
Desafío de la globalización en las aplicaciones distribuidas
Con el advenimiento de modelos computacionales de negocios basados en Internet, es cada vez más frecuente que las aplicaciones consistan en clientes y servidores que operan en distintas regiones geográficas. Estas diferencias aportan los retos siguientes a la tarea del diseño de una infraestructura cliente-servidor acertada:
- Los clientes y los servidores pueden ejecutarse en sistemas que tengan arquitecturas endian o juegos de códigos diferentes
Los clientes y servidores pueden encontrarse en sistemas que tengan arquitecturas endian distintas: un cliente puede encontrarse en una CPU little-endian, mientras que el código del servidor se ejecuta en otra big-endian. Un cliente puede desear llamar a un método business en un servidor que se ejecuta en un juego de códigos distinto del cliente.
La infraestructura cliente-servidor debe definir un seguimiento preciso del juego de códigos y arquitectura endian, así como de las reglas de conversión. La plataforma Java casi ha eliminado estos problemas de una sola forma, basándose en su Máquina Virtual Java (JVM), que codifica todos los datos de series en formato UCS-2 y lo envía todo al exterior en formato big-endian. La JVM utiliza un conjunto de programas específicos de cada plataforma como interfaz con la plataforma nativa. Estos programas llevan a cabo cualquier conversión de juego de códigos necesaria entre el juego de códigos nativo y UCS-2 de una plataforma.
- Los clientes y los servidores pueden ejecutarse en sistemas que tengan valores de entorno local diferentes
Los procesos cliente y servidor pueden utilizar valores de entorno local diferentes. Por ejemplo, un cliente en español puede llamar a un método business sobre un objeto que se encuentre en un servidor en inglés americano. Algunos métodos business son sensibles al entorno local por naturaleza; por ejemplo, dado un método business que devuelve una lista ordenada de series, el cliente español espera que la lista esté ordenada según el orden de clasificación español, no según el orden en inglés del servidor. Como la recuperación de datos y los procedimientos de clasificación se ejecutan en el servidor, el entorno local del cliente debe estar disponible para realizar una clasificación correcta.
Se aplica una consideración similar a instancias en las que el servidor tiene que devolver series que contienen fechas, horas, moneda, mensajes de excepciones, y demás, con el formato correspondiente a las expectativas culturales del cliente.
- Los clientes y los servidores pueden residir en zonas horarias diferentes
Los procesos cliente y servidor pueden ejecutarse en zonas horarias diferentes. Hasta la fecha, toda la bibliografía y recursos de internacionalización se concentran principalmente en temas relativos al entorno local y los juegos de códigos. Por lo general se ha ignorado el tema de la zona horaria, incluso aunque los métodos business pueden ser sensibles tanto a la zona horaria como al entorno local.
Por ejemplo, supongamos que un proveedor hace un reclamación de que los "pedidos recibidos antes de las 14:00 se procesen antes de las 17:00 del mismo día. Las horas dadas, por supuesto, se refieren a la zona horaria del servidor que procesa el pedido. Es importante saber la zona horaria del cliente para proporcionar a los clientes de otras zonas horarias las horas correctas para el proceso en el mismo día.
Otras operaciones que se ven afectadas por la zona horaria son la indicación de la hora en los mensajes que se anotan cronológicamente en un servidor, y el acceso a archivos o recursos de bases de datos. El concepto del ahorro de energía para aprovechamiento de la luz solar complica aún más el tema de la zona horaria.
La plataforma Java Platform, Enterprise Edition (Java EE) proporciona soporte para componentes de aplicación que se ejecutan en sistemas con distinta arquitectura endian y distintos juegos de códigos. No proporciona soporte dedicado para componentes de aplicación que se ejecutan en sistemas con distintos entornos locales o zonas horarias.
- Es intrusivo, pues requiere que se añada uno o más parámetros a todos los métodos bean de la cadena de llamadas en los métodos sensibles a la configuración de entorno local y zona horaria.
- Es propenso a errores de forma inherente.
- No se puede realizar en aplicaciones que no den soporte a la modificación, como aplicaciones heredadas.
El servicio de internacionalización trata de los desafíos que plantean la discrepancia en los entornos locales y los husos horarios sin tener las limitaciones de las técnicas convencionales. El servicio gestiona sistemáticamente la distribución de los contextos de internacionalización a través de los diversos componentes de las aplicaciones EJB, incluyendo aplicaciones cliente, enterprise beans y servlets. Para obtener más información, consulte Visión general de la tarea: Internacionalización de componentes de aplicaciones (servicio de internacionalización).