Une méthode pour générer ses figures : automatisation et traduction

L’avantage de faire une thèse est de réfléchir à ses méthodes de travail et d’organisation. Dans les productions scientifiques, les figures prennent une place très importante et requièrent donc d’y consacrer du temps.

Mon objectif est d’optimiser au maximum la production de mes figures. J’ai choisi d’utiliser quasi-exclusivement LaTeX pour mes figures pour des raisons de qualité, du coté "codage" (les avantages de l’approche code vont être largement mis en exergue ici) et de manipulation de formats.

Sources des figures

Mes figures sont de trois types :

1. Chemfig pour les formules chimiques (.chem)
2. Tikz pour les schémas (.pgf)
3. Gnuplot avec la sortie Lua/Tikz (.plt -> .tikz)

Production des figures

La production des figures est réalisée à l’aide d’un makefile et de deux scripts shells. Un premier script nommé tikzmaker encapsule le fichier tikz (.pgf) avec une entête Latex en utilisant le paquet standalone, ce qui donne un .tex. De même, un script chemmaker transforme mes .chem en .tex.

Gnuplot se charge de produire un fichier .tikz à partir du fichier .plt. Ce fichier tikz passe aussi à travers tikzmaker pour avoir un .tex.

Ces fichier tex sont ensuite compilés en eps et pdf puis en svg avec pdf2svg.

Ce sont toutes ces étapes qui sont automatisées avec un makefile. Cela fait maintenant plusieurs mois que j’utilise cette mécanique que je trouve très satisfaisante. On voit ici que l’approche code permet de modifier des figures extrêmement rapidement grâce à l’automatisation totale. Par ailleurs, cette approche peut permettre de versionner ses figures ; chose que je n’ai pas encore fait mais qui se mettra facilement en place si la nécessité apparaît.

Traduction

Comme je l’ai dis, cette mécanique existe chez moi depuis un moment, j’en avais déjà parlé à l’occasion de précédents billets. La partie innovante de cet article est la traduction. En effet, je dois parfois intégrer mes figures dans des articles en anglais ou dans des documents pour des congrès internationaux. A d’autres moments, ce sont des figures en français dont j’ai besoin.

Dans l’action, il y a deux possibilités : soit on modifie le fichier source en changeant toutes les chaines d’une langue à une autre, soit on duplique le code et on traduit la copie. Chacune de ses méthodes a son inconvénient. Pour la première, je risque d’osciller entre version anglaise et française au gré de mes besoins. la perte de temps est considérable car je dois refaire ce que j’avais fait. Pour la seconde méthode, je ne traduis qu’une seule fois, mais si je modifie la figure, alors je dois reporter les modifications sur mes traductions, chose qu’on ne manquera pas d’oublier et on se perdra dans les sources après quelques mois.

L’idée est d’utiliser un outil dédié à la traduction. A l’occasion de l’écriture d’un code (inforevealer) que j’ai un peu  complètementabandonné par manque de temps, j’ai découvert le projet po4a qui s’appuie sur gettext pour traduire les fichiers qui ne sont pas du code (tex, ini, text…). Ce projet est codé en perl, il faudra adapter un peu le logiciel en ajoutant un module.
Le but de po4a est d’aller chercher les chaines de caractères dans nos fichiers .pgf et .plt. Les .chem n’ont, chez moi, pas de contenu à traduire. Ces chaines sont stockées dans un fichier .pot que l’on copiera en fr.po. Ce fichier fr.po est le fichier dans lequel il faudra traduire les différentes chaines.

Je crée d’abord un fichier de configuration pour po4a (ex po4a.cfg) :
[po_directory] po/
[type: Gnuplot] plot/plot.plt fr:plot/plot.fr.plt
[type: Tikz] fig/fig.pgf fr:fig/fig.fr.pgf

La première ligne nous dit que les traductions se trouveront dans le répertoire po/ (à créer). Il faudra y créer un fichier .pot (le nom n’importe pas) vide. Ensuite on lancera une première fois la commande :
po4a po4a.cfg
Puis on ajoute notre traduction fr :
cp po/master.pot po/fr.po
On traduit et on lance une nouvelle fois :
po4a po4a.cfg

Ceci fait, le fichier plot/plot.plt sera traduit en plot/plot.fr.plt et il suffira de relancer le makefile pour compiler la figure francophone. Ceci décrit donc le déroulement du processus de traduction.

Comme vous l’avez remarqué, il faut indiquer un type (ici Gnuplot et Tikz). Ces types, je les ai créé en ajoutant des bibliothèques perl dans /usr/share/perl5/vendor_perl/Locale/Po4a (chemin sur archlinux). C’est assez simple à réaliser (à condition de connaître un peu perl et les expressions rationnelles). Le fichier Ini.pm offre une bonne base pour la syntaxe. En passant, remarquez que le copyright de ce fichier (sous GPL) est attribué à BitDefender (j’aime ces petites découvertes dans les codes). Pour les fichiers gnuplot, j’ai pris le parti de mettre les chaines à traduire entre double quotes, les autres entre simple quotes. De ce fait, j’utilise pour le moment un copie du fichier Ini.pm pour Gnuplot.pm. Cependant, ce code ne permet de récupérer qu’une chaine par ligne. C’est assez peu gênant, mais j’améliorerai ça plus tard. Pour les fichiers Tikz, il suffit de récupérer le contenu des node{} au lieu des double quotes en prenant garde qu’il peut y avoir des options (node[above] {}).

Voilà pour la partie technique. Les avantages que je vois à cette méthode sont les suivantes :
Un fichier unique pour toutes mes traductions.
Pas de redondance de traduction : si "theory" apparaît 10 fois dans 10 fichiers différents, la traduction me sera demandée qu’une fois. Sachant que les figures voient apparaître des termes récurrents, c’est un gain non négligeable.
Pas de duplication de code à proprement parler. En pratique, il l’est : plot.plt et plot.fr.plt, mais on ne modifiera que plot.plt car plot.fr.plt est généré à partir de plot.plt et fr.po par po4a.

Les codes (tikzmaker, makefile…) sont tous triviaux, néanmoins s’ils intéressent quelqu’un, je peux les mettre à disposition. Pour les bibliothèques perl, elles sont en cours de test… mais j’ai déjà une bonne dizaine de figures traduites avec succès.

De la facilité à contribuer au logiciel libre

Avec cet article, je veux vous montrer en quoi il est facile de contribuer au logiciel libre, grâce à deux exemples. Le premier ne nécessite aucune connaissance en programmation puisqu’il s’agit d’un apport de traduction. Le second, quant à lui, requiert quelques connaissances en script shell, mais si peu que j’espère que cela restera compréhensible aux yeux de tous. Je donne les grandes lignes sans être exhaustif.

Manque de traduction

La traduction, encore nommée internationalisation (i18n) "localisation" (l10n), est sans doute le plus bel exemple où l’on contribue directement au coeur du logiciel mais sans aucun prérequis de programmation, tout au plus il faudra être sensibilisé à la gestion de projet libre. L’effort de traduction est tout aussi important à mes yeux que le soin apporté à la programmation. Un logiciel mal ou peu traduit fait souvent mauvaise impression et peut aller jusqu’à son abandon pour les nombreux utilisateurs non-anglophones.

L’exemple que j’ai choisi m’est venu lorsque j’ai parlé du logiciel grsync à un ami. grsync est une interface graphique GTK au puissant rsync permettant la synchronisation de répertoires. Après avoir installé la version 1.0.0 (qui s’avère être la dernière version comme l’atteste le site du projet), je vois que certaines phrases (que l’on nomme techniquement chaine de caractère) reste en anglais. Une première chose à se méfier est de penser que ce que l’on a sous les yeux est le dernier avancement du logiciel. Ce n’est bien sûr pas le cas, car des modifications du code peuvent être effectuées tous les jours sans pour autant qu’il y ait de nouvelles versions. Il faut donc aller sur le gestionnaire de version du projet afin de récupérer la version la plus avancée.

La traduction se fait, peu ou prou, de la même manière que ce que j’ai pu décrire dans cet article. Sur le SVN du projet, on ira toujours dans le tronc (trunk) et on va jusqu’au répertoire po et télécharger FR_fr.po. On modifie et on se fait un petit patch. Pour cela, je vous conseille la lecture de cette page par exemple. Je n’ai personnellement pas utilisé cette méthode, j’ai préféré git, mais on n’est pas obligé d’aller jusque là.

Voila le résultat.

Correction d’un bug logiciel

Attaquons nous maintenant à la correction d’un bug sur un logiciel. L’idée m’a été soufflée par une conférence de Parinux sur la distribution légère Slitaz. Lors d’une démonstration (c’est toujours comme ça ), le conférencier a voulu ouvrir le gestionnaire de paquet et a entré un mot de passe erroné. Après validation, rien ne s’est passé. Après une dizaine de secondes, il s’est souvenu avoir changé le mot de passe et a pu ouvrir le gestionnaire de paquet. On a là un bug manifeste, l’utilisateur aurait dû être prévenu de l’erreur sur le mot de passe. Les gens qui ont fait un peu de programmation dans leur vie sentent de suite que c’est un cas non géré, un type de bug fréquent.

L’avantage pour cette démonstration est que le site est partiellement en français car le créateur est suisse. On arrive alors sans trop de peine à la partie développement. On a remarqué que le programme portait le doux nom de subox, et une petite recherche nous montre que dans slitaz-tools/tinyutils on retrouve le code source de subox.

On récupère le code et on va donc chercher à corriger le bug. La ligne qui attire mon attention est celle-ci :

<action>echo $PASSWD | su -c "$SU_CMD" &</action>

On remarque alors qu’en cas d’échec, rien n’est prévu. Je propose donc de la remplacer par ceci :

<action> if [[ $(echo $PASSWD | su -c "$SU_CMD" &) ]]; \
then gtkdialog --center --program=ERROR_DIALOG;fi;</action>

où ERROR_DIALOG est une fenêtre qui comporte le message d’erreur. Je passe le détail de la création de cette fenêtre, tout est dans le rapport de bug, et un simple coup d’oeil sur le premier tuto gtkdialog ou la lecture d’autres scripts de la distro permet d’écrire sans problème ce morceau de code. Une fois mon fichier modifié, j’en ai crée un patch.  Le code étant petit, j’ai ajouté le programme complet en fichier attaché.

Le rapport final est disponible là, en attente d’un dev pour correction

Je n’ai pas la prétention que le patch soit idéal ou parfait. Sans doute ne respecte-il pas la politique de la distribution que je ne connais pas, mais quand bien même cela ne plairait pas aux développeurs, cela leur montrera très clairement le problème et une possibilité de résolution. Ceci accélérera dans aucun doute la résolution du bug.

Bien sûr, parfois on n’arrive pas à corriger le bug. On peut avoir qu’une piste voir rien du tout… nul n’est parfait. Dans tous les cas, il faut toujours ouvrir un rapport et indiquer les éventuelles pistes.

Conclusion

Les contributions au logiciel libre peuvent se faire sans connaissances particulières : écriture de documentations, entraide sur les canaux de communication, animations de manifestations… mais on peut avoir envie d’aller plus loin, de découvrir les rouages du moteur.

J’espère ainsi avoir montré, via ces deux exemples, en quoi il est possible de contribuer au code d’un logiciel libre soit sans connaître un langage ou soit sans être un codeur fou. Par contre, il est vrai qu’il faut être un peu familier de la gestion des projets et des outils associées (sourforge, svn, mercurial…), suffisamment pour savoir s’y repérer et récupérer un bout de code. Il existe pléthore de petits logiciels et de petits projets qui ne demandent que ce type de contribution.

Bref, si vous hésitez, même si vous pensez ne pas être à la hauteur, foncez ! Il n’y a pas de petites contributions. L’aventure est extraordinaire, on apprend plein de choses, c’est très enrichissant. En espérant vous avoir convaincu…

Internationalisation (i18n) pour script en bash

J’ai trouvé la documentation autour de l’internationalisation de scripts en bash assez peu fournie. Je vais donc par le biais d’un exemple vous montrer comment vous pouvez utiliser le bash pour faire des scripts dans plusieurs langues.

Voici un script court qui utilise kdialog. Mais si vous ne voulez pas l’utiliser, laissez-juste la ligne avec le echo.

#!/bin/bash

export TEXTDOMAIN=i18nscript

kdialog –title $"The title" –yesno $"This is an example \
to illustrate i18n in a bash script.\n Do you wish to continue?"

echo $"This is an example to illustrate i18n in a bash script."

exit 0

Vous remarquerez que les chaines de caractères (strings en anglais) sont précédées d’un $. C’est ce qui sera utilisé pour récupérer les chaines à traduire. A noter aussi la présence de la ligne export TEXTDOMAIN=i18nscript, qui marque où chercher la traduction. On mets généralement le nom de l’exécutable.
Ensuite nous créons un répertoire po afin de ranger tout ce qui concerne l’i18n pour notre projet.

mkdir po
bash –dump-po-strings i18nscript > po/i18nscript.po

Le fichier i18nscript.po contient ceci :

#: i18nscript:6
msgid "The title"
msgstr ""
#: i18nscript:6
msgid "This is an example to illustrate i18n in a bash script.\\n Do you wish to continue?"
msgstr ""
#: i18nscript:9
msgid "This is an example to illustrate i18n in a bash script."
msgstr ""

Ensuite, copions ce fichier de la manière suivante :

cp po/i18nscript.po po/fr.po

Ensuite, le traducteur (vous je pense ) va compléter les lignes commençant par msgstr. Si vous voulez traduire dans d’autres langues, vous devez appliquer la même procédure.

msgfmt -o i18nscript.mo fr.po
et on déplace ce fichier mo dans
mv i18nscript.mo /usr/share/locale/fr/LC_MESSAGES/
Si l’utilisateur utilise une langue non traduite, la langue figurant dans le script sera utilisée. C’est pour cela que l’on préférera utiliser l’anglais dans celui-ci.