Globalisation
Une application capable de présenter à ses utilisateurs des informations adaptées à des conventions culturelles régionales est considérée comme globalisée : Elle peut être configurée pour interagir avec des utilisateurs de différentes régions en prenant en compte leurs spécificités culturelles. Par exemple, une application mondialisée affiche les messages d'erreur, les données générées et les éléments de l'interface dans la langue demandée. La devise et les formats de date et d'heure sont adaptés en fonction de la région de l'utilisateur. L'utilisateur d'une région spécifique visualise les données dans la langue ou le format utilisé dans cette région. La globalisation s'effectue en deux étapes : l'internationalisation (adaptation d'un composant d'application pour un support multiculturel) et la localisation (traduction et implémentation d'une convention régionale spécifique).
Historiquement, la création d'applications internationalisées a généralement été l'apanage des grandes entreprises concevant des systèmes complexes. Toutefois, face à l'essor que connaissent l'informatique répartie et l'utilisation d'Internet, les développeurs d'applications se trouvent contraints d'internationaliser un plus grand nombre d'applications. Dans cette optique, les techniques d'internationalisation doivent être rendues beaucoup plus accessibles aux développeurs d'applications.
L'internationalisation d'une application dépend de deux variables: le fuseau horaire et l'environnement local. Le fuseau horaire détermine comment l'heure locale doit être calculée par rapport à une heure standard telle que l'heure GMT (Greenwich Mean Time). L'environnement local correspond à une série d'informations sur la langue, la devise et les conventions de présentation de données telles que les dates. Un fuseau horaire peut recouvrir plusieurs environnements locaux, et un environnement local peut recouvrir plusieurs fuseaux horaires. Le fuseau horaire et l'environnement local permettent donc de déterminer la date, l'heure, la monnaie et la langue employées par les utilisateurs d'une région particulière.
Par convention, des paramètres régionaux déterminés sont indiqués avec une paire de codes (pour la langue et la zone) que différentes normes établissent. La norme ISO-639 régit le code de langue, celle ISO-3166 le code régional. Pour la notation, les deux codes sont généralement associés avec un trait de soulignement (_) : par exemple, en_US pour l'anglais des Etats-Unis. Dans le code Java™, l'environnement local est défini et extrait à l'aide de la classe java.util.Locale.
Première étape : Localisation des chaînes de l'interface
Dans une application non internationalisée, l'interface utilisateur est écrite dans le code de l'application sans modification possible. Lorsqu'une interface utilisateur est internationalisée, une couche d'abstraction est ajoutée à la conception de l'application. Elle permet de localiser l'application pour chaque environnement local que l'application doit prendre en charge.
Dans une application localisée, l'environnement local détermine le catalogue de messages duquel l'application extrait les chaînes de messages. Au lieu d'imprimer ou d'afficher un message d'erreur, l'application internationalisée représente les messages d'erreur à l'aide d'informations linguistiques neutres ; dans le cas le plus simple, chaque condition d'erreur correspond à une clé. Pour imprimer ou afficher un message d'erreur utilisable, l'application recherche cette clé dans un catalogue de messages. Chaque catalogue de messages correspond à une liste de clés avec les chaînes qui leur sont associées. Différents catalogues de messages fournissent les chaînes pour les différentes langues prises en charge. L'application recherche la clé dans le catalogue approprié, extrait le message d'erreur correspondant dans la langue souhaitée, puis l'imprime ou l'affiche pour l'utilisateur.
La localisation a bien d'autres utilisations que la traduction des messages d'erreur. Par exemple, en utilisant les clés représentant chaque élément dans une interface graphique et en fournissant les catalogues de messages appropriés, l'interface utilisateur (boutons, menus, etc.) peut prendre en charge plusieurs langues. La prise en charge de langues supplémentaires nécessite que vous fournissiez les catalogues de messages pour ces langues ; dans la plupart des cas, l'application ne requiert pas d'autre modification.
Le package de texte localisable est un ensemble de classes et d'interfaces Java pouvant être utilisées pour localiser facilement les chaînes des applications réparties. Vous pouvez stocker des catalogues de chaînes traduites de manière centralisée pour les mettre à jour efficacement.
Défis posés par l'internationalisation des applications réparties
Avec l'avènement des modèles informatiques métier Internet, les applications comprennent de plus en plus des clients et des serveurs fonctionnant dans des régions géographiques différentes. Ces différences posent les défis suivants lorsqu'il s'agit de concevoir une infrastructure client-serveur solide :
- Les clients et les serveurs peuvent fonctionner sur des ordinateurs dotés d'architectures endian ou de pages de codes différentes.
Clients et serveurs peuvent résider sur des ordinateurs dotés d'architectures endian différentes : le client peut résider sur une UC little endian alors que le code serveur est exécuté sur une UC big endian. Un client devra peut-être appeler une méthode métier sur un serveur exécuté avec une page de codes différente de celle utilisée par le client.
Une architecture client-serveur doit définir des règles précises de suivi et de conversion pour l'endian et les pages de codes. La plateforme Java a pratiquement éliminé ces problèmes d'une seule façon en déléguant la tâche à sa JVM (Java Virtual Machine), qui code toutes les données des chaînes au format UCS-2 et externalise tout au format big-endian. La JVM utilise une série de programmes propres à chaque plateforme comme interface avec la plateforme native. Ces programmes effectuent les conversions de page de codes nécessaires entre UCS-2 et la page de codes native d'une plateforme.
- Les clients et les serveurs peuvent fonctionner sur des ordinateurs dotés de paramètres régionaux différents
Les processus client et serveur peuvent utiliser des paramètres régionaux différents. Par exemple, un client espagnol peut appeler une méthode métier sur un objet résidant sur un serveur anglais américain. De par leur nature, certaines méthodes métier sont fonction des paramètres régionaux. Par exemple, avec une méthode métier qui renvoie une liste de chaînes triée, le client espagnol attend que celle-ci ne soit pas triée selon l'ordre de classement du serveur anglais mais selon celui du serveur espagnol. Etant donné que les procédures de récupération et de tri des données s'exécutent sur le serveur, l'environnement local du client doit être disponible pour effectuer un tri légitime.
La même remarque est applicable lorsque le serveur doit renvoyer des chaînes contenant une date, une heure, une devise, des messages d'exception, etc. qui sont formatés en fonction des attentes culturelles du client.
- Les clients et les serveurs peuvent résider dans des fuseaux horaires différents
Les processus client et serveur peuvent s'exécuter dans des fuseaux horaires différents. Actuellement, toute la documentation et toutes les ressources d'internationalisation portent principalement sur la page de codes et les questions liées à l'environnement local. La question des fuseaux horaires n'est généralement pas traitée bien que les méthodes métier puissent être sensibles au fuseau horaire et à l'environnement local.
Par exemple, supposons qu'un fournisseur demande que des commandes reçues avant 14 h soient traitées avant 17 h le même jour. Les heures données sont bien sûr conformes au fuseau horaire du serveur qui traite la commande. Il est important de connaître le fuseau horaire du poste client pour transmettre aux clients des autres fuseaux horaires l'heure à laquelle la commande sera traitée le même jour.
D'autres opérations sensibles au fuseau horaire comprennent les messages d'horodatage journalisés sur un serveur et l'accès aux ressources figurant dans des fichiers ou des bases de données. L'heure d'été complique la question des fuseaux horaires.
Java EE (Java Platform, Enterprise Edition) contient un support pour les composants d'application exécutés sur des ordinateurs dont l'architecture endian et les pages de codes sont différentes. Cette norme ne contient aucun support dédié pour les composants d'application exécutés sur des ordinateurs dont les paramètres régionaux ou les fuseaux horaires sont différents.
- Elle est importune car elle requiert l'ajout d'un ou plusieurs paramètres à toutes les méthodes de bean figurant dans la chaîne d'appels des méthodes sensibles à l'environnement local ou au fuseau horaire.
- Elle est en elle-même génératrice d'erreurs.
- Elle est impraticable dans les applications qui n'acceptent aucune modification, par exemple les applications existantes.
Le service d'internationalisation résout les problèmes liés aux différences de paramètres régionaux et de fuseaux horaires en évitant les limitations présentées par les techniques conventionnelles. Il gère systématiquement la distribution des contextes d'internationalisation sur les différents composants des applications EJB, y compris les applications client, les beans enterprise et les servlets.Pour plus d'informations, voir Présentation de la tâche : Internationalisation des composants d'application (service d'internationalisation).