1. Traduction des messages#

1.1. Fonctionnement#

La prise en charge des messages en plusieurs langues s’appuie sur les outils standards de gettext.

On donne ici les grandes lignes du fonctionnement de gettext. On se reportera à la documentation de ce produit pour plus de précisions.

Les messages d’erreurs sont rassemblés dans des catalogues (confer [D4.06.01]).

Le module i18n.py (du package Execution) est en charge du choix de la langue d’affichage et de «l’installation» de la fonction de conversion des messages (il s’agit de la fonction «_»).

La langue choisie par défaut est fonction de l’environnement d’exécution: variables d’environnement LANG, LANGUAGE, etc. (se référer à la documentation de gettext pour l’ordre de priorité et les différentes variables). La même variable est utilisée pour déterminer la manière d’afficher les caractères non-ascii, accentués en particulier. Il s’agit de l’encodage utf-8 ou iso-8859-1).

L’utilisateur peut forcer le choix de la langue dans la commande DEBUT (confer [U4.11.01]).

C’est ce module qui définit le domaine gettext et donc le nom du fichier dans lequel les messages traduits seront cherchés. On utilise aster_ + le nom de la version, soit par exemple: aster_stable pour la version d’exploitation, aster_testing pour la version stabilisée de développement.

Les outils de gettext (pygettext en l’occurrence) permettent d’extraire les messages des fichiers sources du code afin de produire un fichier POT, par exemple: aster_unstable.pot.

Pour chaque langue, on crée une copie de ce fichier complété des traductions des messages, nommés fichiers PO, par exemple: aster_unstable.en.po.

Ces fichiers PO sont «compilés» afin de produire les fichiers dits MO qui contiennent les messages, leurs traductions et une table de hashage pour y accéder. Ce sont ces fichiers MO qui sont utilisés lors d’une exécution de Code_Aster . Ils sont installés dans $ASTER_ROOT/share/locale/, dans un sous-répertoire dédié à chaque langue, soit par exemple: en/LC_MESSAGES/aster_unstable.mo.

À des fins de tests essentiellement, on peut choisir un autre répertoire en définissant la variable d’environnement ASTER_LOCALEDIR au lieu de $ASTER_ROOT/share/locale/.

En cours d’exécution, quand on doit afficher un message, la fonction «_» est appelée avec en argument la chaine du message original (celui est qui écrit dans le code source, dans le catalogue de messages en général). Si ce message est présent à l’identique dans le fichier MO, alors la fonction «_» retourne le message tel qu’il a été traduit (dans le mécanisme d’impression des messages, ce texte est ensuite formaté, complété de variables le cas échéant avant d’être affiché).

Si le fichier MO n’est pas trouvé ou bien si le message n’est pas trouvé, c’est le message original qui est affiché quelque soit la langue choisie (donc en français).

Si un message est modifié dans le code source, même juste un caractère, il est nécessaire que les fichiers PO et MO soient regénérés sinon la traduction ne sera pas affichée.

1.2. Organisation#

Les fichiers PO ne peuvent pas être gérés en phase avec le code source. Il y a forcément un décalage entre la restitution du message en français et la mise à jour de la traduction (du moins tant que l’on n’exige pas aux développeurs de traduire simultanément leurs messages dans toutes les langues supportées).

D’ailleurs dans les projets libres, ce sont souvent des équipes différentes qui gèrent les traductions.

Un dépôt de source a été créé à l’adresse

https://bitbucket.org/code_aster/codeaster-i18n.

Il permet de diffuser les dernières versions disponibles des fichiers POT et PO (pour l’anglais dans un premier temps).

Aujourd’hui, le dépôt est géré par le responsable de cette fonctionnalité. Il pourra demain être transféré à une équipe externe qui voudra s’y investir. Les contributeurs peuvent cloner ce dépôt, puis proposer à l’administrateur du dépôt principal de récupérer et d’inclure leurs contributions ( pull request ).

L’objectif est de proposer des traductions aussi complètes que possible pour les versions stable et testing, afin de les fournir et les installer dans les paquets de Code_Aster , à chaque stabilisation.

La traduction de la version unstable est par nature continuellement en chantier du fait de la grande volatilité des messages chaque semaine.