Re: [MAJ] ddp://manuals.sgml/securing-howto/fr/*.sgml
David Prévot un jour écrivit:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Le 27/08/2010 04:12, Philippe Batailler a écrit :
David Prévot <david@tilapin.org> écrivait :
Salut,
Ce TODO traîne depuis plus de deux ans sur le robot, j'ai l'intention de
m'en occuper en commençant par convertir la traduction en fichiers PO,
comme annoncé dans le fil « DDP en fichiers PO » [1].
Simon Valiquette <v.simon at ieee.org>, le traducteur de ce manuel a fait
une mise à jour récemment. Il semble toujours actif et il serait bon de
le contacter, mais peut-être l'as-tu déjà fait...
Effectivement, Simon a procédé à une mise à jour partielle fin 2008,
sans fermer le [TODO] et je ne l'avais pas contacté, merci de m'avoir
prévenu, je repasse en [MAJ] du coup. Simon, es-tu intéressé à continuer
? Je viens de finir de mettre en place le fichier PO conforme à la
traduction existante si ça t'intéresse.
Oui, et je peux mettre au cours des 10 prochains jours beaucoup de temps
sur cette traduction. J'ai aussi encore quelques vieux morceaux qui
traînent depuis longtemps et qui n'avaient pas encore été soumis.
Merci de m'avoir mis en cc, car depuis un certain temps je ne regardais
que rarement la liste.
J'ai également vu le courriel de Ronan Trotin du 28 juillet.
> Je pense qu'il serait intéressant de rajouter que les
> nosuid,noexec,nodev fonctionnent aussi pour les ext3 (voir ext4 si
> ça fonctionne aussi).
Le développement de ext4 n'avait pas encore commencé lors de la rédaction
de cette partie du manuel, mais c'est certain que c'est supporté pour ext4.
De mémoire, la version anglaise est incomplète ici car sauf erreur de ma
part, ça fait longtemps que ces options sont maintenant respectées par la
plupart des systèmes de fichiers de type Unix. Du moins, ceux qui sont
couramment utilisés sous Linux tel que xfs.
À propos de gettextisation avec po4a, mon point de vue de _traducteur_
est que si le responsable de paquet perd la division en chapitres du
manuel, ou bien perd la division en pages man (par exemple apt ou dpkg),
et propose un seul énorme po, alors le traducteur ne gagne rien à la
gettextisation.
Je trouve le fichier PO vraiment pratique les mises à jour. Par exemple
avec le securing-howto qui est plutôt énorme et dont les chapitres sont
séparés pour aider les traducteurs, il y a un système de suivi des mises
à jour sous forme d'indicateur en haut de chaque fichier, de la version
avec laquelle il est synchronisé.
C'est vraiment utile d'avoir ça, car ça permet de demander directement à
Subversion de faire un diff entre 2 versions même si on ne traduit pas
vers la dernière version. Mais j'imagine que rien n'empêche de continuer
à utiliser ça avec les .po
Pour mettre à jour ce type de document, le traducteur doit générer le
diff de la version anglaise depuis cette version, puis trouver dans la
version française où les modifications sont à apporter, avant de pouvoir
enfin procéder à la mise à jour.
Avec un fichier PO, pas besoin de chercher pendant des plombes où se
trouve la chaîne à mettre à jour, et le paragraphe en version originale
est directement sous les yeux dans le même fichier, avec, s'il ne s'agit
que d'une petite modification mineure, comme l'ajout de mots ou de
phrases, la possibilité de mettre en évidence la différence entre
l'ancienne et nouvelle version originale.
Personnellement, une fois habitué et en utilisant vimdiff + une 3e fenêtre
dans vim avec la version en français, je n'ai jamais vraiment eu à
chercher et ça ne représentait pas plus de travail.
Là où on gagne cependant, c'est lorsque l'ancien traducteur a oublié de
traduire certaines parties. Dans la situation actuelle, la seule façon de
trouver ces oublis est de tout relire, et j'en ai corrigé plusieurs dans
le manuel.
Ceci dit, l'ancienne traduction devra de toute façon être révisée au
complet car dans certains cas l'ancien traducteur comprenait mal l'aspect
technique de ce qu'il traduisait.
Pour ce qui est de la division en chapitres ou en page de manuel, j'ai
pour habitude lors d'une traduction initiale ou de la reprise d'un
fichier de créer les documents construits (et de le mettre à disposition
sur un site web) pour faciliter la relecture.
Et les relecteurs, lors des diffs de mise à jour, sont confrontés à
des trucs illisibles.
Pour les mises à jour, je trouve plus facile d'offrir à la relecture le
diff d'un seul fichier avec suffisamment de contexte pour permettre au
relecteur d'avoir accès au texte en version originale.
C'est certain que c'est un gros avantage d'offrir aux relecteurs un accès
direct à la version originale, car pour eux ça représente effectivement
beaucoup moins d'efforts. Il est cependant utile qu'ils voient également
les exemples et pas seulement les chaînes à traduire.
Voilà une petite critique de l'utilisation démesurée de po4a. Mais comme
Denis est là (Salut Denis !) on peut bien critiquer :-)
Hihi, il aura peut-être d'autres remarques à ajouter ;-).
Après avoir mis à jour quelques pages du site web en wml pour avoir une
idée de ce que ça représente, et des documents (SGML, XML et man) plutôt
gros en fichier PO, je préfère utiliser les fichiers PO, mais suis bien
que d'autres avis s'expriment : la question se pose de convertir les
traductions du site en fichier PO, et j'essaye de comprendre les raisons
qui poussent des traducteurs à préférer le système existant.
Dans le cas du manuel de sécurisation, il y a beaucoup de situations où
j'ai trouvé la traduction beaucoup plus simple, plus claire et beaucoup
plus naturelle si elle était faite par paragraphe, ceux-ci étant parfois
volumineux. J'évite de le faire, mais j'ai parfois même altéré légèrement
la structure des paragraphes pour améliorer la traduction.
On peut également facilement imaginer que la bonne façon de représenter
une idée longue et complexe en japonnais puisse être significativement
différente de la présentation à utiliser en anglais.
J'ai surtout utilisé les .po pour des logiciels, et ça fonctionne
extrêmement bien pour traduire de courtes chaînes. Cependant, pour le
manuel j'aimerais ne pas être limité à respecter la structure exacte du
document original. J'ai une connaissance limitée des .po, alors peut-être
existe-t-il qqc pour éviter cette limitation.
Mais à court terme, étant donné qu'il me reste des traductions partielles
non-soumises, je crois que c'est plus simple de rester avec les fichiers
SGML tels quels. Aussi, est-ce que le Freeze de Squeeze peut affecter ce
genre de conversion, ou est-ce que à cette étape-ci ça ne pose pas encore
de problème?
Si utiliser les .po s'avèrent finalement être un gros plus sans causer des
limitations artificielles pouvant affecter la qualité de la traduction,
alors le meilleur moment pour faire la conversion sera à mon avis lorsque
la traduction sera à jour.
En effet, le document devra de toute façon être révisé au complet et
comparé avec la traduction originale, et à cette occasion les petits
ajustements qui pourraient être nécessaires lors de la conversion ne
représenteraient pas plus d'efforts.
Bon, je vais réactiver cette fin de semaine mon accès SVN, car j'ai oublié
le mot de passe de la clef SSH que j'utilisais. Je devrais également
pouvoir soumettre pour lundi une ou deux nouvelles traductions.
Bonne fin de semaine à tous,
Simon Valiquette
Amicalement
David
Reply to: