Le processus d’internationalisation de l’application

Comme nous l’avons fait dans l’article précédent concernant le fichier d’affichage, vous devez d’abord changer les fichiers physiques d’EBCDIC en Unicode. La figure 7 montre la source DDS modifié pour les fichiers physiques Order et Inven. Les seuls changements apportés au source sont les suivants :

•    Utiliser un type de données G (Graphic) pour les champs texte concernés par de multiples langues nationales.
•    Ajouter le mot-clé CCSID DDS à ces champs graphiques. 13488 est le CCSID Unicode que nous associerons aux champs texte. 13488 est le CCSID pour UCS-2, CCSID 1200 représente UTF-16.

La définition de fichier OrdDet, qui ne contient aucune donnée texte nécessitant l’usage d’Unicode, n’a besoin d’aucun changement. On voit aussi dans la figure 7 le source pour le programme LOADORDSU. Le programme LOADORDSU charge une commande additionnelle dans les fichiers Order et OrdDet. Cette commande, qui porte le numéro 2, mêle l’anglais, le chinois et le russe. Pour une explication des changements de fichiers et du programme LOADORDSU, voir l’article « Unicode and System i: évolution plutôt que révolution. »

La source du fichier d’imprimante ShipList mis à jour se trouve dans la figure 8. Bien que le programme ShipToRpt générant la liste de livraison doive être recompilé pour tenir compte des changements du fichier physique et d’imprimante, il n’y a besoin d’aucun changement source sur le programme RPG, donc il n’est pas répété dans la figure 8.

Le processus d’internationalisation de l’application

Le premier changement apporté à la définition du fichier d’imprimante ShipList est l’ajout du mot-clé DDS FONTNAME au niveau fichier, montré au renvoi A. Le mot-clé FONTNAME sert à spécifier la police TrueType (ce sont les polices déjà chargées avec l’option 43 du système d’exploitation) à utiliser pour l’impression des données Unicode. Ce mot-clé peut être utilisé à trois niveaux : fichier, enregistrement ou champ. Dans le cas de ShipList, le fait de spécifier FONTNAME au niveau fichier fait que la police de référence s’appliquera par défaut à toutes les variables Unicode dans le rapport.
Pour ShipList, FONTNAME s’accompagne de deux paramètres : la police à utiliser, Times New Roman WT TC, et la taille en points, 10. Le système propose beaucoup d’autres polices TrueType. Vous pouvez vous renseigner à ce sujet dans le manuel Infoprint Fonts: Font Summary de l’IBM Information Center. J’ai choisi Times New Roman WorldType (WT) Traditional Chinese (TC), puisque le nom du contact à imprimer est chinois. En plus de TC pour Traditional Chinese, vous verrez aussi des suffixes  comme J pour Japanese, K pour Korean, et SC pour Simplified Chinese. La police retenue peut être codée en dur dans le DDS, comme c’est le cas dans l’exemple, ou bien vous pouvez utiliser un champ program-to-system pour fournir la police au moment de l’exécution. Dans ce second cas, vous devez spécifier le mot-clé FONTNAME au niveau du champ ou de l’enregistrement (par opposition au niveau du fichier comme je l’ai fait pour éviter des changements redondants à la source DDS).

Je souligne au passage que ces polices pour Chinese, Korean, et Japanese fournissent les glyphes pour des langues classiques à un seul octet comme l’anglais, le russe, le polonais, et le grec. Comme vous le verrez, Unicode codé en russe s’imprime bien sans qu’une police russe doive être spécifiée. Mais pour bien prendre en charge les langues courantes à double octet, vous devez identifier la bonne police pour la langue nationale imprimée. Le mot-clé FONTNAME accepte d’autres paramètres que les deux utilisés ici. Pour avoir une idée des autres fonctions existantes, je vous engage à examiner la documentation FONTNAME DDS.

Le second changement apporté au fichier d’imprimante ShipList, montré au renvoi B pour la variable Company, est l’ajout du mot-clé CCSID à chacun des champs validés Unicode (Company, Contact, Addr1, Addr2, et PartDesc). Quand on travaille avec des données validées Unicode dans un fichier d’imprimante, le comportement par défaut est de convertir les données Unicode en l’ID caractère (CHRID) spécifié pour le fichier d’imprimante. Cette façon de faire convient bien lorsqu’on fait migrer des données d’EBCDIC en Unicode et qu’on veut continuer à utiliser les définitions d’imprimante existantes, mais elle ne convient pas quand nous voulons profiter pleinement des qualités multilingues d’Unicode dans un rapport, comme nous le faisons dans cet article. Comme le paramètre CHRID ne peut pas être utilisé pour spécifier un jeu de caractères graphiques Unicode et une code page comme cible de conversion, nous devons coder l’option *NOCONVERT du mot-clé CCSID. Cette option *NOCONVERT aurait pu être spécifiée avec la définition DDS des champs du fichier physique, mais cette façon de faire pourrait aussi affecter d’autres fichiers (non imprimante) qui utilisent aussi les fichiers/champs de référence. Pour l’application ShipToRpt, il est facile de simplement ajouter le mot-clé CCSID avec deux paramètres—*REFC pour indiquer que le fichier physique CCSID (13488) doit être utilisé, et *NOCONVERT pour indiquer que les données Unicode doivent rester en ce format—pour chacun des champs codés en Unicode.

Une fois ces changements effectués, nous pouvons imprimer une liste de livraison internationalisée. Pour générer la liste de livraison Unicode que l’on voit dans la figure 3, procédez ainsi :

1.    Après avoir changé le DDS pour le fichier physique Order, changez le fichier en utilisant CHGPF FILE(ORDER) SRCFILE(QDDSSRC).
2.    Après avoir changé le DDS pour le fichier physique Inven, changez le fichier en utilisant CHGPF FILE(INVEN) SRCFILE(QDDSSRC).
3.    Créez le programme LoadOrdsu en utilisant CRTBNDRPG PGM(LOADORDSU).
4.    Chargez la commande numéro 2 dans les fichiers en utilisant CALL PGM(LOADORDSU).
5.    Après avoir changé le DDS pour le fichier d’imprimante ShipList, recréez le fichier en utilisant CRTPRTF FILE(SHIPLIST) SRCFILE(QDDSSRC) DEVTYPE(*AFPDS).
6.    Recréez le programme ShipToRpt en utilisant CRTBNDRPG PGM(SHIPTORPT).
7.    Générez le rapport en utilisant CALL PGM(SHIPTORPT) PARM(2).
Vous devriez obtenir une liste de livraison spoolée semblable à celle de la figure 3.

Cependant, vous ne pourrez pas la visualiser par la même méthode que celle de la liste de livraison en anglais seulement. Vous pouvez bien sûr la visualiser, en choisissant l’une des méthodes suivantes :

•    Imprimer la liste de livraison vers une imprimante attachée AFPDS.
•    Imprimer la liste de livraison vers une imprimante attachée HPT (comme on l’a vu dans la section sur les prérequis).
•    Visualiser la liste de livraison à l’aide de l’AFP Viewer de System i Navigator ou avec Web Navigator.

À noter que beaucoup d’installation Windows ne fournissent que des polices de base (sans idéogrammes) dans le répertoire C:\WINDOWS\Fonts, donc vous ne verrez peut-être que le texte en anglais et en russe, avec des caractères de substitution pour le texte en chinois. Pour voir les caractères chinois, vous pouvez transférer les polices TrueType nécessaires de l’IBM i dans le répertoire \WINDOWS\Fonts. Quand vous avez restauré l’option 43 du système d’exploitation i, les polices ont été copiées dans le répertoire /QIBM/ProdData/OS400/Fonts/TTFonts. Ces fichiers de polices TrueType (tnrwt_t.ttf pour Times New Roman WorldType Traditional Chinese, tnrwt_s.ttf pour Simplified Chinese, tnrwt_k.ttf pour Korean, et tnrwt_j.ttf pour Japanese, et ainsi de suite) peuvent être envoyés par FTP en mode binaire, dans le répertoire \WINDOWS\Fonts. AFP Viewer devrait alors pouvoir afficher le texte en chinois de la liste de livraison.
Vous remarquerez peut-être une différence notable dans la police utilisée pour les variables Unicode et les constantes définies dans le fichier d’imprimante ShipList. Pour les besoins de la démonstration, j’ai volontairement laissé les constantes ‘Part No’, ‘Part Description’, et ‘Quantity:’ avec la police spécifiée par le paramètre FONT de la commande CRTPRTF. Dans ce cas, le paramètre CRTPRTF FONT adopte par défaut la valeur spéciale *CPI et, en supposant que votre valeur CPI par défaut soit 10, c’est donc la police 11 qui doit être utilisée. Celle-ci est définie comme Courier 10 pitch.

Changez le fichier d’imprimante ShipList en Gothic bold 10 pitch avec CHGPRTF FILE(SHIPLIST) FONT(39) et réexécutez l’application ShipToRpt pour la commande numéro 2. Comparez les résultats. Changez le FONTNAME spécifié dans le ShipList DDS en (*POINTSIZE 20.0), recréez le fichier d’imprimante avec CRTPRTF FILE(SHIPLIST) SRCFILE(QDDSSRC) DEVTYPE(*AFPDS), puis réexécutez l’application ShipToRpt. Vous allez à nouveau observer un changement important et aussi prendre conscience que les changements de taille en points modifient l’interligne !

Outre son contrôle de la police utilisée pour les variables validées Unicode, le mot-clé FONTNAME peut aussi être associé à des données codées non-Unicode comme les constantes de liste de livraison—de sorte que vous pouvez utiliser les mêmes polices TrueType pour des données non-Unicode. Pour utiliser une police TrueType telle que Times New Roman WT TC pour la constante ‘Quantity:’, par exemple, il faudrait ajouter ceci à la ligne source ShipList DDS définissant le littéral :

14’Quantity:’ SPACEB(1)
FONTNAME( +
‘Times New Roman WT TC’ +
(*POINTSIZE 10.0) +
(*CODEPAGE T1001140))

L’ajout du paramètre *CODEPAGE indique que la constante ‘Quantity:’ est codée en code page T1001140. Ce code page correspond à EBCDIC CCSID of 37, CCSID 1140, validé Euro. La ressource code page T1001140 a été installée dans la bibliothèque QFNTCPL quand vous avez restauré l’option 8 du système d’exploitation i. Vous pouvez utiliser la commande Work with Font Resources (WRKFNTRSC) pour voir quelles autres ressources ont été restaurées sur votre système.

L’option 8 en question assure le support du code page pour les langues d’Europe de l’Ouest (comme l’anglais). Vous pouvez transférer le support pour les autres code pages à partir de l’article « Extended Code Pages zip files » à www-01.ibm.com/support/docview.wss?uid=psd1P4000878. Le contenu de la bibliothèque générale de code page étendue, avec référence croisée CCSID, peut être consulté à l’aide du lien qui se trouve dans la Download Description de cet article. Après ce téléchargement, vous pouvez utiliser la commande Create Font Resource (CRTFNTRSC) pour créer les ressources de police code page pour d’autres langues. Mais vous ne devez faire cela que si, comme je l’ai fait avec mes en-têtes dans l’exemple, vous choisissez de combiner des données EBCDIC et Unicode dans le même fichier d’imprimante.

Recréez le fichier d’imprimante et réexécutez l’application ShipToRpt pour voir le changement associé à la constante ‘Quantity:’. Chaque variable ou constante du fichier d’impression peut utiliser la même police, une police différente, ou toute combinaison de polices nécessaire pour obtenir le meilleur rapport possible. C’est ce que j’appelle de la souplesse.

Trois mots-clés DDS sont directement associés à l’impression des données Unicode : CCSID, FONTNAME, et UNISCRIPT. Nous avons utilisé les deux premiers dans notre application de listes de livraison. Dans cet article, il est hors de question de parler du mot-clé UNISCRIPT, qui peut être nécessaire pour des langues nationales dont la présentation est très spéciale : aspect bidirectionnel pour l’arabe et l’hébreu, graphisme contextuel pour l’arabe, et autres particularités. En effet, il faudrait plusieurs articles pour expliquer les nombreux usages de ce mot-clé. Pour l’instant, sachez simplement que si vous devez traiter des langues comme l’arabe, l’hébreu, l’urdu, le devanagari (entre autres langues indiennes), ou le thaï, le i en est parfaitement capable.

Moderniser, internationaliser

Vous savez donc comment moderniser vos applications RPG pour incorporer des données multilingues. Sur le marché global actuel, la possibilité de stocker et de reproduire correctement des noms et des adresses en plusieurs langues ne peut être qu’un atout. Certes, toutes les applications ne seront pas aussi faciles à internationaliser que l’exemple ShipToRpt. Vous trouverez d’autres informations sur ce sujet dans l’article « Retour sur  Unicode et sur la conversion d’applications RPG« .

Sachez que les fichiers d’imprimante externes ne servent pas qu’à l’internationalisation. Par exemple, si vous deviez améliorer la productivité dans l’entrepôt en imprimant le code barre des pièces commandées sur la liste de livraison elle-même. Ou, si vous deviez attacher les étiquettes de code barre aux pièces elles-mêmes. Dans un prochain article, nous verrons comment ce genre d’amélioration est facile dès lors que vous avez instauré des fichiers d’imprimante décrits en externe. Ce serait beaucoup plus difficile si vous utilisiez encore une sortie imprimée décrite par programme.