Prise en charge de la globalisation

Magasins types

Les magasins type vous offrent une base pour créer votre magasin. Tous les magasins types montrent comment créer et gérer un site globalisé.

Les magasins types permettent aux clients de sélectionner la langue dans laquelle ils souhaitent afficher le site. La liste s'affiche dans une liste située dans le cadre gauche dans l'ensemble du site. Les clients peuvent naviguer dans le site, dans la langue de leur choix.

Les magasins types utilisent le modèle unique pour tous les magasins et le modèle de programmation des langues. Chaque langue prise en charge possède son propre fichier de propriétés, lequel contient le texte et les messages traduits pour cette langue. Toutes les archives du magasin contiennent : publishNLS.properties et publishNLS_en_US.properties. Ils sont utilisés dans l'assistant de publication.

Dans un fichier de propriétés, un certain nombre d'éléments de la page est traduit :

Texte

Contenu d'une page de texte.

Etiquettes

Libellés de zones du formulaire.

Messages

Messages d'erreur, d'état et de confirmation.

Texte de remplacement

Pour les images, les applets Java et autres objets imbriqués.

Regroupement de ressources

Dans le contexte des instructions, le paramètre régional est utilisé pour extraire l'objet Java de propriétés storetext, qui obtient ses valeurs du fichier storetext_locale.properties situé dans le répertoire approprié spécifique au paramètre régional. Le modèle accède ensuite à chacune des propriétés selon les besoins, au moyen de la méthode getString() de l'objet ResourceBundle.

Identification du jeu de caractères

Le jeu de caractères dans lequel le texte est affiché dans un navigateur est défini dans le fichier de propriétés à l'aide de la propriété ENCODESTATEMENT. Par exemple, le fichier storetext_en_US.properties contient l'instruction :

ENCODESTATEMENT = text/html; charset=ISO_8859-1

Etant donné que le codage est défini dans le fichier de propriétés et non pas dans le modèle JSP, le jeu de caractères peut varier pour chaque langue. Le codage de caractères par défaut pour le WebSphere Application Server se situe dans l'emplacement suivant :

• WAS_installdir\bin\wsinstance\propdefaults\encoding.properties

Le codage de caractères de la page JSP généré est défini à l'aide de l'instruction suivante dans le modèle JSP :

<%response.setContentType(storetext.getString("ENCODESTATEMENT"));%>

pour JTSL :

<c:set property="contentType"
target="${pageContext.response}">
<fmt:message key="ENCODESTATEMENT" bundle="${storeText}" />
</c:set>

Remarque : Lorsque setLocal est appelé à l'aide de :

(<fmt:setLocale value="${CommandContext.locale}" />)

le codage de caractères par défaut est sélectionné à partir du WebSphere Application Server. JSTL sélectionne le dernier ensemble de codage de caractères comme codage renvoyé qui sera envoyé au navigateur Web. Dans la plupart des cas, cela ne posera de problème à personne. Ce ne sera un problème que lors du traitement avec des langues bidi où il peut y avoir plusieurs codages de caractères ISO par paramètre régional.

En phase d'exécution, chaque page JSP (JavaServer Page) comprend le fichier EnvironmentSetup.jsp ou EnvironmentSetup.jspf. Le contexte de commande est extrait de ce fichier.

Affichage des images traduites

L'environnement local et la langue sont extraits lors de l'exécution pour déterminer le dossier dans lequel rechercher le fichier image. Le modèle peut rechercher le fichier ConsumerDirect\ language_Locale\go_button.gif, où la variable language_Locale est remplacée par le format d'affichage issu du contexte de l'instruction. Par exemple, la page qui en résulte affiche l'image : ConsumerDirect\en_US\images\colors\color1\go_button.gif.

Affichage de contenu de catalogue

Le catalogue contient plusieurs traductions, une pour chaque environnement local pris en charge. Lors de l'exécution, le contexte de commande est envoyé via un bean de données pour déterminer la traduction à extraire de la base de données et à afficher sur la page.

Regroupements de ressources et fichiers de propriétés

Les regroupements de ressources et les fichiers de propriétés vous permettent de gérer des collections d'objets Java spécifiques à un paramètre régional pour vos pages JSP (JavaServer Pages). Lorsque la page a besoin d'une ressource spécifique à l'environnement local, telle qu'un libellé de zone de formulaire, un message d'interface utilisateur graphique ou une valeur pour un menu déroulant, elle peut la charger à partir du regroupement de ressources ou du fichier de propriétés pour l'environnement local sélectionné, et permettre ainsi au client d'afficher la page dans sa propre langue. De cette façon, vous pouvez créer des modèles JSP qui sont tout à fait indépendants de l'environnement local du client en isolant toutes les informations spécifiques à l'environnement local dans les regroupements de ressources ou les fichiers de propriétés.

Bien que les regroupements de ressources et les fichiers de propriétés permettent d'effectuer des fonctions similaires, la méthode employée pour exécuter ces fonctions dans ces environnements n'est pas tout à fait la même. La table suivante présente quelques-unes des différences importantes entre les regroupements de ressources et les fichiers de propriétés :

Fichiers de propriétés	Regroupements de ressources
Fichiers texte	Format compilé
Légère dégradation des performances	Légère amélioration des performances
Si un fichier de propriétés est modifié, WebSphere Application Server doit être redémarré pour que les modifications soient visibles.	Si un regroupement de ressources est modifié, il doit être recompilé et WebSphere Application Server doit être redémarré pour que les modifications soient visibles.
Spécifique à la langue et à l'environnement local. Un fichier doit exister pour chaque environnement local. Vous devez exécuter native2ascii sur les caractères non ISO-8859-1.	Spécifique à la langue et à l'environnement local. Un fichier doit exister pour chaque environnement local. Vous devez exécuter native2ascii sur les caractères non ISO-8859-1.

Pour voir un exemple illustrant l'utilisation de fichiers de propriétés dans un site globalisé pour plusieurs pays, reportez-vous aux magasins types.

Stockage et transfert de données

Un magasin peut afficher des pages dans plusieurs langues, même lorsque les langues utilisent différents jeux de caractères. Pour ce faire, les données sont stockées dans la base de données HCL Commerce dans un format universel peuvent être appliqué à un grand nombre de langues. Etant donné que tous les navigateurs Web ne prennent pas en charge les mêmes jeux de caractères, lorsque des données sont demandées par une page JavaServer Page, elles sont converties dans un jeu de caractères approprié.

Vous trouverez ci-après une description du transfert des données entre la base de données et le navigateur.

1. Les données texte sont stockées dans la base de données HCL Commerce à l'aide du codage Unicode UTF-8 ou UCS-2.
2. Les pilotes JDBC chargent les données à partir de la base de données en les convertissant du codage Unicode UTF-8 au codage Unicode 16 bits natif de Java.
3. Les fichiers JSP génèrent une sortie pour les données en utilisant le codage 16 bits de Java.
4. WebSphere Application Server convertit la sortie du fichier JSP du codage Unicode 16 bits dans le codage cible. Le codage peut être spécifié dans le fichier JSP ou dans un fichier de propriétés. Par exemple, pour spécifier le codage Shift-JIS pour une page affichée en japonais :
   • Fichier JSP <%@ page contentType="text/html; charset=Shift-JIS"%>.
   • Fichier de propriétés ENCODESTATEMENT = text/html; charset=Shift-JIS Le codage de caractères du fichier JSP généré est défini à l'aide de l'instruction suivante dans le modèle JSP : <%response.setContentType(fashionflowtext.getString ("ENCODESTATEMENT")); %>
   • JSTL : <c:set property="contentType" target="${pageContext.response}"> <fmt:message key="ENCODESTATEMENT" bundle="${storeText}" /> </c:set>

   Etant donné que tous les navigateurs ne peuvent pas comprendre tous les algorithmes de codage, il est recommandé de spécifier les algorithmes de codage les plus connus, tels que UTF-8 et Shift-JIS.

5. Les données converties sont renvoyées au navigateur.
6. Le navigateur interprète la réponse HTTP en fonction du codage spécifié dans l'en-tête.

   

Vous trouverez ci-après une description du transfert des données entre le navigateur et la base de données.

1. Des données sont entrées dans le navigateur. Des données multilingues peuvent être saisies à l'aide d'un éditeur de méthode d'entrée.
2. HCL Commerce convertit les données provenant du navigateur en codage Java 16 bits à l'aide de la méthode setCharacterEncoding(). Chaque LANGUAGE_ID de la table LANGUAGE est mappé sur une valeur de codage à l'aide de la colonne ENCODING. Cette valeur est utilisée pour interpréter les données provenant du navigateur.
3. Les données sont envoyées à la base de données où elles sont converties du codage 16 bits de Java au codage UTF-8, lequel correspond à la façon dont les données sont stockées dans la base de données, comme illustré dans le diagramme suivant :

   

Entrée de données multilingues

Si le navigateur prend en charge le codage Unicode, vous pouvez afficher plusieurs simultanément dans un navigateur. Toutefois, il se peut que votre système d'exploitation ne dispose pas des caractères dont vous avez besoin pour saisir du texte dans certaines langues. Pour y parvenir, vous devez utiliser un éditeur de méthode d'entrée. Il s'agit d'un composant logiciel qui convertit les activations de touches en saisie de texte qui ne peut pas être entré directement. Les éditeurs de méthode d'entrée sont normalement utilisés pour saisir du texte pour les langues dont les caractères sont trop nombreux pour un clavier standard, telles que le japonais, le chinois, le coréen, le thaï et l'hindi. Un éditeur de méthode d'entrée courant est Microsoft Global Input Method Editor (IME), disponible sur le site Web de Microsoft. Global IME est approprié à la fois pour permettre aux clients de saisir des données sur les pages du magasin et pour permettre aux administrateurs de saisir des données dans HCL Commerce Accelerator et dans la console d'administration.

Si vous choisissez de ne pas utiliser un éditeur de méthode d'entrée, vous pouvez également entrer des données dans des langues différentes, si vous avez plusieurs machines configurées, chacune utilisant une langue de système d'exploitation distincte avec un navigateur configuré de façon appropriée. Un navigateur prend automatiquement en charge la langue qui est native pour la machine sur laquelle il est installé. Par exemple, pour entrer des données en japonais et en allemand, vous pouvez configurer deux machines, l'une utilisant un système d'exploitation allemand, l'autre utilisant un système d'exploitation japonais, chacune ayant un navigateur capable d'afficher les données de ce système d'exploitation. Pour plus d'informations, consultez la documentation de votre système d'exploitation ou de votre navigateur Web.

Unicode

HCL Commerce les données de texte sont codées à l'aide du jeu de caractères Unicode. L'Unicode peut afficher les caractères utilisés dans les principales langues, y compris les langues européennes, moyen-orientales et asiatiques. Dans HCL Commerce, la norme Unicode UTF-8 est utilisée pour stocker des données en plusieurs langues dans la même instance de base de données. Bien que les clients n'aient pas besoin d'avoir un navigateur compatible Unicode pour afficher des sites gérés par HCL Commerce, les administrateurs peuvent en avoir besoin s'ils souhaitent afficher leur site dans plusieurs langues sur la même machine. Si vous souhaitez afficher votre site dans une langue autre que l'anglais, vous devez utiliser un navigateur activé par Unicode. Pour plus d'informations sur le codage Unicode, visitez le site Web d'Unicode.

Formats d'affichage

Les formats d'affichage permettent à un magasin de vendre des produits à une base de clients multilingue globalisée. Chaque format d'affichage peut être identifié par trois facteurs : une langue, une région et une variante que vous pouvez définir. Vous pouvez concevoir votre site pour qu'il affiche du contenu à des groupes qui diffèrent au regard de ces facteurs. Par exemple, vous pouvez utiliser des attributs de langue et d'environnement local de manière à avoir un format différent pour l'anglais américain et l'anglais canadien. Ces formats d'affichage peuvent avoir le même texte, mais des devises et des unités de mesure différentes. Vous pouvez ajouter un format d'affichage pour le français canadien. Ce format d'affichage pourrait afficher la même devise et les mêmes unités de mesure que pour l'anglais canadien, mais le texte serait en français canadien. Vous pouvez même utiliser le troisième facteur pour avoir un format distinct pour des publics spécifiques au sein d'une culture, par exemple les adolescents, les scientifiques ou les techniciens professionnels, et adapter ainsi votre site pour répondre à leurs attentes.

Les clients peuvent choisir le format dans lequel ils souhaitent afficher le site, ou vous pouvez définir une valeur par défaut. Les informations concernant le format sont transmises via un paramètre URL lorsque vous souhaitez modifier la langue. Par exemple, si vous transmettez langId=-2, le français est défini comme langue en cours pour la session. L'ID langue (langId) est stocké dans la session. Lorsque le client demande une page, le format d'affichage détermine les ressources Web et les informations de catalogue à extraire.