 |
Vendredi 06 juin 2025 - 17:16 |
| Translate |
|
| Rubriques |
| Réseaux sociaux |
|
| Liste des jeux Amiga |
|
| Trucs et astuces |
|
| Glossaire |
|
| Galeries |
|
| Téléchargement |
|
| Liens |
|
| Partenaires |
|
| A Propos |
|
| Contact |
|
|
|
On ne comptait plus les rumeurs à son sujet. Depuis plusieurs mois, les habitués d'Usenet dissertaient sur les nouveautés qu'il apporterait. Et enfin, il est là. Le Workbench 2.1 est arrivé. Il apporte de nombreuses améliorations par rapport au 2.0, notamment un pilote PostScript, CrossDOS en standard (le lecteur de disquette PC) et surtout la "localisation" que je vais vous décrire dans cet article.
De quoi s'agit-il ?
Avant tout, c'est une bibliothèque : la locale.library. Elle permet de donner une dimension internationale à vos programmes puisque vous pouvez désormais écrire ceux-ci en plusieurs langues avec une facilité déroutante. L'aspect utilisateur étant trivial (si vous mettez la main sur un programme "localisé", il adaptera automatiquement le langage que vous avez choisi dans vos préférences).
Je vais particulièrement détailler le côté programmation. Il serait de bon ton désormais si vous avez l'intention d'écrire une application de penser à incorporer la locale.library. C'est une surcharge de travail très faible qui donnera à votre application une dimension supplémentaire.
Un programme localisé contient des fichiers auxiliaires qui regroupent toutes les chaînes utilisées dans les différentes langues. L'arborescence couramment utilisée est la suivante :
ProgDir:Catalogs/ English/prog.catalog
Français/prog.catalog
Italiano/prog.catalog
|
Si vous avez défini comme préférence locale le français par exemple, la bibliothèque recherche dans l'ordre les fichiers suivants :
- locale:catalogs/<langue>/prog.catalog.
- progdir:catalog/<langue>/prog.catalog.
Les contraintes
On n'a rien sans rien. Écrire une application localisée demande un tout petit peu plus d'efforts que si vous décidiez de faire sans. Adapter un ancien programme à la localisation peut être une tâche pénible mais si vous commencez à écrire avec l'idée en tête, le travail demandé est beaucoup moins astreignant.
Pour être plus précis, l'utilisation de la localisation vous impose d'appeler une fonction chaque fois que vous manipulez une chaîne. Cette fonction fait naturellement partie de la locale.library et elle vous retourne automatiquement la phrase traduite en fonction des préférences de l'utilisateur. Il s'agit de la fonction GetCatalogStr().
Mais il ne faut surtout pas oublier les utilisateurs qui se serviront de votre programme sans posséder la locale.library. Il serait inadmissible que votre programme refuse de tourner dans ces conditions. Je vous suggère donc d'écrire une fonction comme celle que j'ai appelée getString() dans le programme d'exemple plus bas et qui vous retournera soit la phrase sélectionnée par la locale.library si celle-ci a pu s'initialiser correctement, soit une phrase par défaut dans la négative. Votre application est dans ce cas limitée à une seule langue (l'anglais est naturellemen fortement conseillé...).
Initialisation de la bibliothèque
Il faut tout d'abord faire la distinction entre une locale et un "catalog" (catalogue). Une locale est une préférence préréglée et se trouve dans votre répertoire Sys:Prefs/Presets/<nom>. Elle sera sauvée par la préférence "Locale" qui vous présente un panneau de contrôle dans lequel vous définirez votre langue de prédilection, votre décalage horaire et votre ville.
Le code suivant est un exemple d'initialisation :
Le "tag" passé en paramètre à OpenCatalog(OC_BuiltInLanguage) sert à signaler le langage par défaut du programme. Ainsi, si vous demandez à ouvrir la locale "english", la fonction ne fera rien étant donné que ce langage est déjà chargé.
Utilisation pratique
Je vous suggère de faire appel à la fonction suivante pour obtenir une chaîne de la part de la bibliothèque. Cette fonction a le mérite de fonctionner même si la bibliothèque n'a pas pu s'initialiser pour une raison quelconque (pas de locale.library, pas de locale ou bien catalogue non trouvé).
La variable AppStrings est déclarée dans un fichier include qui est automatiquement généré par l'application permettant de créer les fichiers de langue. Il s'agit du programme CatComp.
Le programme CatComp
C'est le programme principal qui est utilisé pour générer les fichiers de langue utilisés par vos programmes. Il travaille sur quatre genres de fichiers :
- Les fichiers de description (.cd), dans lesquels vous donnez des identités à vos chaînes, leur taille maximale et leur valeur par défaut. Il y a un fichier de description par application.
- Les fichiers de traduction (.ct), dans lesquels vous spécifiez les traductions des chaînes déclarées dans le fichier de description. Il y a un fichier de traduction par langue additionnelle connue par votre programme.
- Des fichiers include pour le C.
- Des fichiers include pour l'assembleur.
La production d'un fichier ".catalog" (le seul utilisable par la bibliothèque) se fait en plusieurs étapes :
description -> traduction -> .catalog
-> include
|
Le fichier include généré vous permet de faire référence aux chaînes utilisées uniquement par un nom symbolique (un #define).
Vous pouvez demander au début à CatComp de générer pour vous un fichier de traduction type (c'est-à-dire qu'il laissera des blancs uniquement pour que vous y ajoutiez vos traductions). Par la suite, à mesure que votre application grandira et se verra augmentée de chaînes, vous éditerez directement le fichier de traduction (car si vous le regénériez, il vous faudrait retaper toutes les traductions entrées jusqu'alors).
Ainsi, la première génération de votre ".catalog" se fera de la façon suivante :
| catcomp prog.cd ctfile français.ct |
Vous éditez alors "français.ct" car il ne contient aucune traduction. Puis :
| catcomp prog.cd français.ct catalog catalogs/français/prog.catalog cfile prog locale_strings.h |
Cette commande joint le fichier de description et de traduction en un seul fichier utilisable par la bibliothèque : prog.catalog, qui est placé dans le répertoire "français". Il génère en même temps le fichier include nécessaire pour que vous puissiez retirer des chaînes de ce catalogue à partir de votre programme.
Par la suite, quand vous ajoutez des chaînes à votre application, vous n'avez qu'à éditer à la main "prog.cd", "français.ct" et à reproduire la dernière ligne.
Un exemple de programme localisé
Prenons un exemple simple : nous désirons écrire un programme qui parle anglais par défaut et français en plus. En fonction de l'argument donné (le nom de la locale, ici je ne considère que les cas "english" et "français"), celui-ci répondra une phrase dans la langue désirée. Le programme s'appelle "locale".
Dans un premier temps je définis la chaîne dans le fichier de description. Celui-ci s'appelle "locale.cd". C'est le fichier de référence. Tous les fichiers de traduction en seront dérivés. Notez que la langue par défaut ("built-in") est l'anglais. Je passe donc dans le répertoire "catalogs/" pour faire les manipulations suivantes :
|
; locale.cd ; C'est la description des chaînes utilisées par le programme. ; Les numéros entre parenthèses sont respectivement le numéro ; (qui doit être incrémenté à chaque chaîne), la taille minimale et ; la taille maximale de la chaîne (et de ses éventuelles traductions). ; Le nom générique (MSG_CHAINE) peut être utilisé directement ; dans le programme C pour peu qu'il ait inclus le fichier .h généré ; par le programme CatComp avec l'option CFILE MSG_CHAINE (1/1/50) Hello! This is Locale speaking ; |
A partir de ce fichier, je génère un fichier de traduction vide. Comme je vais y mettre les phrases françaises, je décide de l'appeler "français.ct" :
| catcomp locale.cd ctfile français.ct |
Le fichier généré a l'apparence suivante :
|
## version $VER: XX.catalog XX.XX (XX.XX.XX) ## codeset X ## language X ; MSG_CHAINE ; Hello! This is Locale speaking ; |
Il ne vous reste plus qu'à remplir les blancs. A l'avenir, vous n'aurez plus à générer ce fichier mais à ajouter les nouvelles chaînes en respectant la syntaxe montrée dans les chaînes précédentes. Notez que CatComp vous facilite la tâche au maximum : il laisse une ligne blanche en dessous du nom générique et vous rappelle en commentaires quelle est la phrase à traduire. Notez également que les indications d'identité, longueur minimale et maximale ne sont plus nécessaires.
Après édition, le fichier "français.ct" est le suivant :
|
## version $VER: locale.catalog 01.00 (25.08.92) ## codeset 0 ## language F ; MSG_CHAINE Salut! C'est Locale qui parle ; Hello! This is Locale speaking ; |
Dernière étape, génération du catalogue et du fichier d'include :
| catcomp locale.ct français.cd catalog catalogs /locale.catalog cfile /locale_strings.h |
A ce stade, nous avons l'arborescence suivante :
locale/ rwed 920927 20:56:08 0 Dir catalogs rwed 920927 20:40:15 2 942 locale.c rwed 920927 20:56:12 2 799 locale_strings.h locale/catalogs rwed 920927 20:56:11 0 Dir français rwed 920927 20:56:08 1 154 français.ct rwed 920927 20:40:17 1 505 locale.cd locale/catalogs/français rwed 920927 20:56:12 1 156 locale.catalog |
Reste encore à vous donner le programme "locale.c" :
|
1> locale english Hello! This is Locale speaking 1> locale français Salut! C'est Locale qui parle 1> |
Conclusion
Bien sûr, il ne s'agit que d'un exemple. Une application bien programmée devrait essayer d'ouvrir la locale par défaut si on ne lui en impose aucune (alors qu'ici, je sors du programme). La locale.library possède beaucoup d'autres fonctions destinées à simplifier au maximum les traitements sur les divers alphabets et notations, notamment sur les manipulations de caractères et de dates. Quoi qu'il en soit, vous devriez maintenant avoir une idée très précise sur l'immense progrès apporté par cette bibliothèque. Alors désormais, pensez international !
|
