Bonjour,
Je suis en train de traduire des fichiers po pour Debian avec l'aide de Emacs et de son mode « po-mode ».
Plusieurs questions : - comment insérer un retour à la ligne sans pour autant ajouter \n (nouvelle ligne) ? - comment mettre à jour l'en-tête automatiquement (date de dernière modif, etc.) ?
Enfin, quel outils utilisez-vous pour traduire des fichiers po ?
Afficher les réponses par date
On Tue, 10 Jun 2003 21:35:47 +0200 Michel Grentzinger mic.grentz@online.fr wrote:
Bonjour,
Je suis en train de traduire des fichiers po pour Debian avec l'aide de Emacs et de son mode « po-mode ».
Plusieurs questions :
- comment insérer un retour à la ligne sans pour autant ajouter \n (nouvelle
ligne) ?
- comment mettre à jour l'en-tête automatiquement (date de dernière modif,
etc.) ?
Quand tu valides ton .po (touche "V") emacs met à jour la date de dernière modification.
Enfin, quel outils utilisez-vous pour traduire des fichiers po ?
Michel Grentzinger OpenPGP key ID : B2BAFAFA Available on http://www.keyserver.net
Traduc mailing list Traduc@traduc.org http://www.traduc.org/mailman/listinfo/traduc
Bonjour,
Le mardi 10 juin 2003 à 21:35 +0200, Michel Grentzinger a écrit :
Bonjour,
Je suis en train de traduire des fichiers po pour Debian avec l'aide de Emacs et de son mode « po-mode ».
Plusieurs questions :
- comment insérer un retour à la ligne sans pour autant ajouter \n (nouvelle
ligne) ?
Je n'ai pas trouvé de solution à ce problème. J'édite mon po dans emacs avec le po-mode, et ensuite je force l'édition de la structure.
- comment mettre à jour l'en-tête automatiquement (date de dernière modif,
etc.) ?
Il me semble que ça ne le fait que lorsque tu choisi de poster ton po via le po-mode d'emacs. Je sais que ça fonctionne pour les po traités par le robot du TP. En revanche ma dernière expérience d'envoi de fichier po-debconf directement via emacs sur la liste debian-l10n-french n'a pas été concluante. (encodage cassé)
Enfin, quel outils utilisez-vous pour traduire des fichiers po ?
emacs ou bien vim.
A+
Le Mercredi 11 Juin 2003 07:51, Pierre Machard a écrit :
Je suis en train de traduire des fichiers po pour Debian avec l'aide de Emacs et de son mode « po-mode ».
Plusieurs questions :
- comment insérer un retour à la ligne sans pour autant ajouter \n
(nouvelle ligne) ?
Je n'ai pas trouvé de solution à ce problème. J'édite mon po dans emacs avec le po-mode, et ensuite je force l'édition de la structure.
En chargeant le mode standard, je suppose ?
- comment mettre à jour l'en-tête automatiquement (date de dernière
modif, etc.) ?
Il me semble que ça ne le fait que lorsque tu choisi de poster ton po via le po-mode d'emacs. Je sais que ça fonctionne pour les po traités par le robot du TP. En revanche ma dernière expérience d'envoi de fichier po-debconf directement via emacs sur la liste debian-l10n-french n'a pas été concluante. (encodage cassé)
Merci à tous !
Je suis en train de traduire des fichiers po pour Debian avec l'aide de Emacs et de son mode « po-mode ».
Il y a longtemps que j'ai touché au mode PO, c'est Bruno qui s'en occupe maintenant, je crois. Mais je peux essayer de répondre quand même, avec le vague souvenir que j'en ai.
- comment insérer un retour à la ligne sans pour autant ajouter \n
(nouvelle ligne) ?
Je n'ai pas trouvé de solution à ce problème. J'édite mon po dans emacs avec le po-mode, et ensuite je force l'édition de la structure.
Je ne comprends pas vraiment quel est le problème à résoudre. Des lignes super trop longues, probablement?
En passant, n'y a-t-il pas une commande `E' pour passer en mode d'édition fondamentale? `M-x po-mode' ensuite pour revenir au mode PO...
- comment mettre à jour l'en-tête automatiquement (date de dernière
modif, etc.) ?
Il me semble que ça ne le fait que lorsque tu choisis de poster ton po via le po-mode d'emacs.
Il y a probablement un paramètre pour ça que l'on peut installer dans son `.emacs' personnel. Il faudrait jeter un coup d'oeil au début de `po-mode.el' pour savoir ce qui est disponible.
Enfin, quel outils utilisez-vous pour traduire des fichiers po ?
emacs ou bien vim.
Il y a aussi quelques outils interactifs spécialisés (dans Gnome ou KDE?), je n'en ai pas l'expérience. J'imagine que, ayant été écrits après le mode PO, ils offrent davantage, ou mieux. De mon point de vue, Emacs est probablement le meilleur outil, particulièrement pour les langues utilisant des jeux de caractères assez éloignés de l'ASCII. Le mode PO (dans Emacs) a aussi l'avantage de s'occuper de plusieurs petits détails administratifs ennuyeux, comme l'échappement approprié des caractères, et le suivi de quelques standards de format pour le Projet de Traduction.
Un désavantage important du mode PO, pour ceux qui ne peuvent pas blairer Emacs (eh oui, il y en a! :-), c'est d'exiger son usage.
Le mercredi 11 juin 2003 à 21:18 -0400, Francois Pinard a écrit :
Je suis en train de traduire des fichiers po pour Debian avec l'aide de Emacs et de son mode « po-mode ».
Il y a longtemps que j'ai touché au mode PO, c'est Bruno qui s'en occupe maintenant, je crois. Mais je peux essayer de répondre quand même, avec le vague souvenir que j'en ai.
- comment insérer un retour à la ligne sans pour autant ajouter \n
(nouvelle ligne) ?
Je n'ai pas trouvé de solution à ce problème. J'édite mon po dans emacs avec le po-mode, et ensuite je force l'édition de la structure.
Je ne comprends pas vraiment quel est le problème à résoudre. Des lignes super trop longues, probablement?
Enfait 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. Nous avons besoin de ça pour les fichiers po-debconf. C'est un utilitaire qui utilise po pour le traitement des fichiers debconf. (Rapidement : Debconf est le système utilisé dans le système Debian pour afficher/demander des informations à la personne qui installe un paquet)
Ex:
#. Description #: ../templates:33 msgid "" "This version of the autopartitioner is not elaborate enough to handle " "the partitioning of the selected disk. It will partition only an empty " "disk or a disk with no more than 2 FAT partitions (and no extended "partitions or other non-FAT partitions)." msgstr "" "Cette version de l'outil d'auto-partitionnement n'est pas assez " "évoluée pour traiter le partitionnement du disque que vous avez " "sélectionné. Il peut uniquement partitionner un disque vide ou un " "disque qui ne contient pas plus de 2 partitions FAT (et pas de " "partition étendue ou d'autres partitions non-FAT)."
a+
[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. C'est vraiment, vraiment le traducteur qui s'occupe de l'aspect d'affichage de la chaîne traduite, dans les limites de ce que le programme internationalisé permet, bien sûr. C'est le traducteur qui décide où il y aura des fins de lignes, et s'il y aura ou non une fin de ligne à la fin de la chaîne. Oh, il y a bien certaines validations (assurées soit par `msgfmt', soit par le robot du Projet de Traduction) pour vérifier la conformité entre la chaîne traduite et la chaîne originale, dans le but d'attraper des erreurs de détail que l'expérience nous a montré fréquentes; et je n'ai pas souvenir que quiconque se soit plaint de ces validations.
D'un autre côté, le format du fichier PO, une fois la chaîne traduite encapsulée, c'est vraiment l'affaire du mode PO, et pas du tout celle du traducteur, ni des distributeurs de logiciels d'ailleurs. (Aux débuts du Projet de Traduction, cela a été toute une saga que d'amener les gens à s'entendre, chacun ayant des opinions fortes et personnelles au sujet de ce que tous les autres devaient faire.) Le fait est que le traducteur a la responsabilité des chaînes, mais pas celle de leur encapsulage. Le mode PO respecte (ou du moins respectait, je ne sais pas où il en est présentement) les conventions de format du Projet de Traduction, et ces conventions ont (ou ont déjà eu) beaucoup de force, de manière à assurer une certaine uniformité entre tous les fichiers PO. Mais d'un autre côté, il se peut fort bien que ces conventions doivent être révisées en fonction de nouveaux besoins, et il appartient (ou a déjà appartenu) au collège de tous les chefs d'équipe nationale de traduction de choisir, discuter et déterminer ces conventions (mais ils n'en ont pas beaucoup usé).
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! :-)
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.
[Martin Quinson]
Bonjour,
Tourlou! (Est-ce que ça se dit, en France?)
[Yes. Je merite maintenant l'oscar pour la phrase la plus longue et la plus incomprehensible...]
Surtout à cause des accents manquants. Pour le reste, ça va! :-)
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 [...]
Bon, si Karl est favorable à l'idée, c'est déjà beaucoup de gagné.
mais qu'il avait besoin d'un gourou elisp pour l'aider.
Des volontaires dans la salle? :-)
Y'a bien wdiff (que Francois connais bien :), mais son usage ne s'est pas implante.
Les gens qui utilisent le mode PO utilisent nécessairement Emacs, et à ce niveau, le merveilleux `ediff' n'est pas mal du tout pour mettre en évidence, dans un "hunk" calculé au niveau des lignes, les différences raffinées au niveau du mot. C'est un bon compromis pour les utilisateurs de Emacs. Il y a aussi le `ndiff' de Tim Peters que l'on trouve caché quelque part dans la distribution Python, qui pourrait donner un coup de main.
Si je refaisais le mode PO aujourd'hui, je le ferai sûrement en Python plutôt qu'en Lisp, et j'aurais accès à ces belles choses. (Certains savent peut-être que je me suis fabriqué la possibilité de scripter Emacs en Python en plus de Lisp, possibilité que j'utilise à tour de bras et tout le temps.)