Bonjour,
On Thu, Jun 12, 2003 at 08:27:40AM -0400, Francois Pinard wrote:
[Pierre Machard]
Je ne comprends pas vraiment quel est le problème à résoudre. Des lignes super trop longues, probablement?
En fait on voudrait que le po-mode n'ajoute pas de '\n' à la fin des lignes. Ce n'est pas une question de longueur de lignes, mais de dire au po-mode te soucie pas de l'affichage, c'est pas ton job.
Je ne comprends toujours pas, ou je ne suis pas sûr de bien comprendre.
En fait, ce que voudrait Pierre [et pleins d'autres personnes], une fois reformule dans le jargon propre a gettext, c'est que le mode po normalise le fichier po. C'est a dire qu'il coupe ses lignes a n caracteres sans pour autant ajouter des \n a la fin.
C'est vraiment, vraiment le traducteur qui s'occupe de l'aspect d'affichage de la chaîne traduite,
oui, mais la, en gros, il y a deux modes: Soit ta chaine contient des \n, et tu passes en formatage manuel (pratique pour mettre des items, mais donne potentiellement des choses pas propre quand on change la largueur de la fenetre), soit ta chaine ne contient pas de \n, et c'est chacune des differentes interfaces debconf qui se chargent de couper tes lignes la ou il faut (et des patches ont fait leur apparition il y a peu pour tenir compte des langues asiatiques et de leurs droles de regles en la matiere. Mais ca ne nous concerne pas, chanceux locuteurs d'une langue europeene que nous sommes).
Dans cette discution, il faut se souvenir qu'on parle de po-debconf, le rejeton le plus celebre de po4a (po for anything), un projet fonde par les traducteurs Debian afin de permettre d'utiliser les po dans des contextes pour lesquels ils ne sont pas prevus, mais bien pratiques quand meme. On detourne donc le cadre gettext strict afin de profiter de bonnes proprietes comme la separation entre ce que le traducteur doit modifier et ce qu'il ne doit pas toucher ou encore la simplicite de mise a jour, quite a ajouter des regles de validite sur les po. La difference principale conceptuelle avec le gettext classique, c'est que les traductions contenues dans le po ne sont pas utilisees au runtime.
Dans le cas de po-debconf, le probleme est que debconf est utilise avant l'installation des paquets (par definition), et il faut donc ruser un peu. De plus, a l'origine, debconf a son propre format de questionnaire permettant d'embarquer des traductions. L'experience a cependant montre qu'il n'etait vraiment pas pratique pour les traducteurs (par exemple, toutes les traductions de toutes les langues sont dans le meme fichier, avec les problemes d'encodage que ca pose). Donc la ruse de po-debconf, c'est de laisser les traducteurs travailler avec des fichiers po dont ils ont l'habitude, et convertir le tout en un fichier au format que debconf aime bien au dernier moment de la compilation du paquet.
Pour information, les autres rejetons de la famille po4a sont capables d'extraire et reinjecter les traductions de formats de documentation tels que groff (pages de manuel), pod (documentation perl), sgml docbook et sgml debiandoc. Il faut que je fasse html et xml docbook, mais le temps me manque. Dans ce cas la, ce n'est meme pas a la compilation que la conversion se fait. C'est quand on invoque po4a-update, ce qui doit etre fait quand le traducteur met son travail a jour. Mais les pages de manuels du projet devraient fournir plus d'info aux curieux.
Quant au probleme de la normalisation et pour repondre a Pierre, Karl (l'un des mainteneurs actuels du Translation Project, et fervent contributeur du mode po) a annonce (je sais plus sur quelle liste) qu'il etait sur le probleme, mais qu'il avait besoin d'un gourou elisp pour l'aider. [Yes. Je merite maintenant l'oscar pour la phrase la plus longue et la plus incomprehensible...] A ma connaissance, il n'a pas recu de reponse, et on est encore contrait de faire un msgmerge inutile a la fin de la traduction pour s'assurer de la normalisation.
Si on se passe de normalisation, gettext (et po4a) fonctionnent tout aussi bien, mais on a des lignes tres tres longues. Du coup, quand on fait des relectures (le peche mignon des traducteurs debian), les diffs resultants sont illisibles. Y'a bien wdiff (que Francois connais bien :), mais son usage ne s'est pas implante.
En ce qui me concerne, je preche pour l'usage du script msgdiff suivant :
<<<<< #! /bin/sh
# Makes a clean diff of two po files, ignoring ignorable changes
if [ "x$1" = "xhelp" -o "x$1" = "x--help" ] ; then echo "msgdiff: produce a clean diff of two po files, ignoring ignorable changes." echo "usage: msgdiff orig new" exit 0; fi
if [ $# != 2 ] ; then echo "usage: msgdiff orig new" exit 1; fi
tmp1=`mktemp /tmp/msgdiff.XXXXXXXXXXXX` msgcat $1 > $tmp1 tmp2=`mktemp /tmp/msgdiff.XXXXXXXXXXXX` msgcat $2 > $tmp2 diff -u -I '^#:' -I 'PO-Revision-Date' -I 'POT-Creation-Date' $tmp1 $tmp2 | \ sed -e "s|^--- $tmp1|--- $1|" \ -e "s|^+++ $tmp2|+++ $2|" rm -f $tmp1 $tmp2
Il normalise les deux po avant de faire le diff et la vie est belle. Quand je l'ai montre a Bruno, il a dit qu'il aimait bien l'idee, et qu'il allait en faire de grandes choses, mais il semblerait qu'il n'ai pas encore eu le temps de concretiser (a moins que j'ai rate une etape).
Je déblatère ça pour informer seulement, parce que je ne m'occupe plus de toutes ces belles choses :-). Ça n'était pas toujours facile, en tout cas pour un gars comme moi, qui est doux et sans talent pour la politique! :-)
Pareil, mon message est pour le moins verbeux, mais j'avais une heure de train a perdre, alors j'en ai profite pour faire de la pub a po4a une fois de plus :)
Merci de votre attention, Mt.