Distribution EOLE

h1. Gestion traduction

h2. Besoins

Pouvoir mettre à jour les fichiers de traduction distribués dans les paquets.

Idéalement, il faut :

* un mécanisme permettant de mettre à jour les fichiers .po pour chaque langue déjà traduite et le fichier .pot pouvant servir de point de départ à la traduction dans une nouvelle langue ;

* un mécanisme permettant d'être sûr que la version compilée installée est bien à jour.

h2. Procédures

Les fichiers de traduction sont installés sous forme compilée (.mo).

Ces fichiers compilés ne sont pas éditables directement.

Ils sont générés à partir de fichiers texte (.po).

La mise à jour des fichiers de traduction est faite en trois étapes :

# extraction des chaînes de caractères à traduire dans un ensemble de fichiers (création ou mise à jour des fichiers .po),

# édition des fichiers .po,

# compilation des fichiers .mo à partir des fichiers .po.

L'extraction des chaînes de caractères à traduire est possible par l'emploi de la commande xgettext (également conseillée par l'auteur de pygettext depuis qu'elle gère le code python).

Le passage des .po aux .mo et inversement est possible par l'emploi des commandes msgfmt et msgunfmt réciproquement.

Les fichiers .po et .mo sont redondants et il n'est pas nécessaire de conserver les deux formats dans les dépôts.

Les fichiers .mo ne sont utiles que pour l'exécution des programmes traduits et les fichiers .po sont plus facilement exploitables dans un contexte de dépôt git.

h2. Implémentation

h3. À ce jour, dans les dépôts eole

Les dépôts mettant actuellement en place une gestion de la traduction sont :

* eole-sso ;

* eoleflask-aaa ;

* eole-bacula ;

* zephir-client ;

* python-pyeole ;

* ead ;

* creole ;

* tiramisu.

L'idée retenue dans l'ead, eole-sso, est l'inclusion du fichier .po dans le dépôt avec un script permettant de générer le .mo.

Dans le cas de l'ead, le .po et le script sont installés (ils sont placés dans le répertoire i18n qui est installé de manière globale).

Dans le cas de eole-sso, le .po et le script ne sont pas installés ; seul le .mo est dans un répertoire installé.

Dans les deux cas, le script générant les .mo n'est pas lancé automatiquement.

Dans eoleflask-aaa, le fichier .po (et un fichier .pot) est dans un répertoire translations mais aucun dispositif ne semble en place pour compiler le .mo.

Dans eole-bacula, le .po est celui de bacula recompilé.

L'ensemble du dossier lang est installé (.po, script pour compiler le .mo et le .mo lui-même).

Le script ne gère pas la mise à jour des fichiers .po et doit être lancé manuellement. 

Zephir-client dispose d'une cible dans le Makefile situé dans data/monitor pour générer le .mo à partir du .po et d'une cible pour extraire les chaînes de caractères.

Python-pyeole lance la commande msgfmt dans le setup.py qui assure la compilation des .mo.

Creole ne met à disposition que le fichier .mo.

Tiramisu dispose de trois cibles (utilisées dans le .PHONY) dans le Makefile pour extraire les chaînes de caractères, compiler les .mo et les installer.

h3. bilan

Seul les dépôts tiramisu et zéphir-client prennent en charge les trois étapes : extraction des chaînes de caractères, compilation et installation des .mo.

Aucun n'assure, a priori, la mise à jour des fichiers .po déjà existant.

Tiramisu déclenche automatiquement l'extraction des chaînes de caractères et la compilation directement après.

Les projets python utilisent soit les mécanismes du Makefile, soit ceux du setup.py.

Les .po et les scripts se retrouvent parfois installés.

Deux trois questions :

* est-ce que les fichiers .mo doivent tous être installés dans /usr/share/locale/ ?

* est-ce que la procédure est suffisamment générique pour l'intégrer dans le Makefile de eole-skeletor ?

h2. Proposition

# si nécessaire, mettre à jour tous les fichiers .po déjà créés et écraser le fichier .pot servant à initier les nouvelles traductions (cible du Makefile appelée manuellement),

# si les fichiers .po ont été mis à jour, les éditer,

# compiler les fichiers .mo dans un répertoire installé à chaque construction de paquet (cible Makefile lancée automatiquement).

Les utilitaires à disposition (voir également la documentation gettext au format texinfo, chapitre 9):

* xgettext : extraction de chaînes de caractères et création d'un catalogue vide ou ajout des chaînes à un catalogue déjà existant ;

* msginit : création d'un catalogue .po pour une langue donnée, à partir d'un catalogue vide .pot ;

* msgfmt : compilation d'un catalogue .po au format binaire .mo ;

* msgunfmt : décompilation d'un catalogue au format binaire .mo en un catalogue .po ;

* msgmerge : assemblage d'un catalogue avec traductions et d'un catalogue avec références mises à jour.

h3. Arborescence des projets

Le fonctionnement de gettext nécessite de disposer, pour chaque langue, d'un fichier portant le même nom.

Sur le serveur, cela est rendu possible par l'organisation en arborescence avec un répertoire par langue, variante linguistique.

Dans le dépôt, on propose de distinguer les différentes langues en utilisant également une arborescence :

<pre>

|

`-- translations

    |-- creole.pot

    |-- en

    |   `-- creole.po

    `-- fr

        `-- creole.po

</pre>

Le niveau de répertoire LC_MESSAGES présent sur les serveurs n'est pas reproduit dans les dépôts.

Au moment de la compilation, on recherchera tous les fichiers correspondant au motif translations/*/*.po.

h3. Mise à jour des .pot et des .po

La mise à jour des fichiers .pot et .po est une opération lancée si besoin.

Les informations nécessaires pour générer le .pot sont un nom de projet (domaine, également utilisé pour le nom de paquet) et les répertoires ou fichiers dans lesquels chercher les chaînes de caractères.

Ces informations doivent être fournies en paramètres au script assurant la génération du .pot et la mise à jour des .po (en cas de chaîne vide, le message d'origine est utilisé).

Ces informations seront fournies sous la forme d'un fichier texte structuré par des tabulations comme suit :

<pre>

projet\tfichier1.po fichiers2*.po

</pre>

h3. Compilation des .mo

La compilation des .mo sera faite à la compilation des paquets : le .mo ne sera pas présent dans le dépôt.

Les cibles ajoutées dans eole.mk seront tous les fichiers .po disponibles.

La recette compilera les .po en .mo directement dans $(DESTDIR)/usr/share/locale/…