[lfs-fr] J'ai traduit un .po ;o))

MENGUAL Jean-Philippe jmengual at linuxfromscratch.org
Dim 9 Nov 05:42:11 PST 2014


Salut,

Merci de ce retour d'expérience. Je rappelle que l'objectif des .po est 
d'attirer des contrib par une méthodologie plus simple et, aussi, une 
interface plus simple. Ce bilan m'incite à penser que restent à 
accomplir les étapes suivantes:
- déboguer le Makefile (pour qu'on n'ait pas à faire 2 genhtml, le 1e 
s'arrêtant sur une erreur, pour générer).
- réussir à sortir des .po les labels des xml qui ne se traduisent pas 
(sans quoi le xml reste indispensable)
- mettre au point une méthode pour que la mise à jour soit possible 
révision par révision, pour que comme aujourd'hui, à chaque mise à jour, 
hop on synchro la version française (et ne pas avoir à traduire à chaque 
stable);
- intégrer le tout dans un outil type OmegaT ou Pottle

En termes d'outils, je dirais que pour rester en ssh/putty, on peut 
utiliser Emacs et le module gettext-el qui remplace avantageusement poedit.

Voilà où en est le processus. Plutôt bien avancé, reste à le finaliser 
pour le rendre exploitable selon les objectifs initiaux.

Merci amj et bon courage ^^ N'hésite pas pour toute aide en termes de 
comm, infrastructure, etc.

Amitiés,

Le 09/11/2014 14:26, Denis Mugnier a écrit :
> Bonjour tous,
>
> bon je ne vais pas faire un mail pour me gratifier de cela ... ;o)
>
> Brièvement la méthode que j'aurais utilisée pour traduire un fichier 
> completement nouveau:
> 1 - ouvrir le fichier xml avec un éditeur de texte
> 2 - le traduire
> 3 - enregistrer et commiter
>
> les avantages :
> - méthode simple, rien à installer
> - en effectuant la traduction, on a en permamence le contexte, ce qui 
> est une aide à la traduction
> - on sait facilement ce que l'on traduit et on voit rapidement ce 
> qu'il faut traduire ou pas
>
> les inconvénients :
> - pas de mémoires de traduction
> - avoir une connaissance de la structure xml du livre pour ne pas tout 
> casser
>
>
> Maintenant le même fichier en utilisant la méthode des .po
> 0 - il faut que le .po soit généré (merci amj pour ton Makefile)
> 1 - ouvrir le fichier .po avec un editeur de texte mais le mieux ce 
> serait avec poedit ou equivalent
> 2 - traduire les chaines
> 3 - ouvrir le fichier xml d'origine pour savoir ce qu'il faut traduire 
> ou pas...
> 4 - enregistrer, commiter
>
> Sur la méthode, cela peut paraitre identique ....
>  les avantages :
>  - mémoire de traduction si on utilise un programme qui le gère (donc 
> pas vi ;o))
>  - pas a connaitre le xml
>
> les inconvénients :
> - il faut installer un prog poedit ou autre, avec mon editeur de 
> texte, j'ai pas respecté la syntaxe et mon fichier n'était pas correct 
> (désolé)
> - il faut ouvrir en plus le xml si on veut etre certain de ce que l'on 
> traduit... avec juste le .po on a du mal a s'y retrouver, il manque le 
> contexte
> - possible d'introduire des bugs xml qui ne seront pas simple à 
> trouver....
>
> J'ai voulu me limiter aux avantages et aux inconvénients sur une seule 
> traduction....
>
> Maintenant, je vais donner mon sentiment sur la méthode dans l'état 
> actuel des choses. Donc cela ne veut pas dire que ma position est 
> définitive et qu'elle n'évoluera jamais.
>
> Pour moi qui travaille principalement sur les trads depuis le bureau 
> pendant ma pause repas, si on passait t en po, cela me demanderai 
> d'installer poedit ou équivalent (? il existe quoi qui fonctionne sous 
> windows ?), et il faudrait de plus que j'installe subversion pour 
> récupérer les fichiers.
> Aujourd'hui, j'ai juste putty qui me sert à me connecter sur une 
> machine chez moi via ssh et à travailler sur un éditeur de texte que 
> je lance depuis la console. Ce qui ne me semble plus possible de faire 
> si je veux utiliser poedit, (pas possible pour moi d'utiliser ssh avec 
> un deport d'affichage, X11 n'est pas installé sur la machine ou je me 
> connecte et je ne veux pas l'installer).
>
> On peut dire qu'il est un avantage de pouvoir traduire sans connaitre 
> la structure XML du livre... mais au final pour ne pas introduire des 
> bugs dans le XML, il faut connaitre la structure. Pour le moment, on 
> retrouve des balises XML dans les chaînes.
>
> Il est difficile de traduire en ouvrant simplement le .po, j'ai besoin 
> pour ma part d'avoir le fichier d'origine pour avoir le contexte. Ce 
> qui fait que pour le moment, cela demande d'ouvrir 2 fichiers à la 
> place d'un seul... oui je sais c'est pas forcement compliqué... mais 
> cela peut le devenir des qu'on travaille en console sur une machine 
> distante.
>
> Pour le moment, les essais de traduction se déroulent sur des fichiers 
> statiques.... je souhaite que des essais soient réalisés et qu'une 
> stratégie soit testée pour suivre une version svn....
>
> Le gros avantage que je vois est la possibilité d'avoir une mémoire de 
> traduction et ainsi de donner plus de cohérence à l'ensemble des 
> traductions... ce que ne permet pas la méthode actuelle.
>
> Voila mes reflexions actuelles...je le repete, rien n'est figé, et 
> c'est plus pour marquer les points ou il faut que la méthode évolue 
> que pour dire NON de façon catégorique. Il est juste certain que dans 
> l'état actuel des choses, je ne vois pas comment appliquer les .po à 
> la traduction de BLFS.
>
> Merci amj pour ton investissement dans la mise en place de cette 
> méthode ;o)
>
> Denis
>


-- 
Jean-Philippe MENGUAL
Président de l'association traduc.org
Coordinateur francophone du projet Linux From Scratch
Animateur suppléant du groupe de travail Accessibilité de l'April
Administrateur d'accelibreinfo



More information about the lfs-traducfr mailing list