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

Denis Mugnier myou72 at orange.fr
Dim 9 Nov 05:26:24 PST 2014


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



More information about the lfs-traducfr mailing list