Bonsoir à tous !
Le 2006-08-25 16:39:01 +0200, Christian Perrier écrivait :
Eh bien si. J'aimerais bien comprendre ce qui t'a amené à juger que la proposition d'utilisation de l'outil po4a pour améliorer la qualité des traductions françaises des pages de man (car c'est bien de cela dont il s'agit) ne te convenait pas.
Je voudrais juste faire une remarque, qui reflète mon avis personnel sur l'utilisation de po4a. Je ne suis pas sûr que cet avis reflète aussi celui d'Alain Portal, mais cela n'est pas impossible.
Personnellement, je suis plutôt contre l'utilisation de po4a comme support unique de traduction des pages de manuels. Autrement dit, je pense qu'un fichier .po ne doit pas être l'outil exclusif de travail du traducteur.
En effet, un document est en général plus facile à traduire correctement car le traducteur dispose du contexte de chacune des phrase (de par la structure même du document). De plus, la relecture du document traduit ne pose, en soi, aucune difficulté particulière.
En comparaison, les logiciels sont très difficiles à traduire. Le traducteur commence par traduire toutes les chaînes du fichier .po (sans forcément comprendre leur contexte), puis, s'il veut obtenir une bonne traduction, il doit lancer la version traduite du logiciel, et essayer de trouver le mode opératoire permettant de faire apparaître tous les textes traduits, afin de vérifier la pertinence de la traduction.
Ce qui est l'équivalent de la relecture pour un logiciel. Selon la complexité et la nature du logiciel, cela peut se révéler de très difficile à impossible.
Utiliser un fichier .po comme support unique de traduction de pages de manuels, cela revient à traduire un document dont le contexte a été masqué. La perte du contexte rend beaucoup plus probable les erreurs de traduction.
La relecture du fichier .po sans relire la page traduite en elle-même ne garantit pas non plus de trouver ces erreurs de traduction. Seule la relecture de la page de manuel traduite permettra de débusquer efficacement de telles erreurs.
Maintenant, les fichiers .po ne sont pas non plus sans avantages :
- Ils facilitent la mise à jour des traductions. - Ils peuvent permettre de traduire une seule fois une même phrase utilisée dans plusieurs documents (ce qui peut aussi être vu comme un inconvénient). - En segmentant le travail, ils permettent sans doute de partager plus facilement la tâche entre plusieurs traducteurs.
Globalement, je pense que l'utilisation de fichiers .po pour traduire des pages de manuel permet d'obtenir une meilleure productivité, au prix d'une qualité moindre.
Donc, le choix d'utiliser po4a pour un projet ayant des fortes contraintes de délai ne me paraît pas choquant. Mais je ne pense pas que po4a en lui-même soit un bon outil pour améliorer la qualité des traductions.
Je n'ai pas participé à ces discussions et, pourtant, je considère qu'elles ont un intérêt pour moi. Je voudrais être sûr de pouvoir un jour motiver correctement mes explications sur la justification du probable définitif fork de manpages-fr. Pour l'instant, je me contente de dire que c'est parce que je suis persuadé que les traductions que nous avons dans Debian sont, par définition et parce que nous utilisons un outil permettant de le garantir, à jour par rapport aux VO.
La facilité de mise à jour est sans doute le gros point fort de po4a.
Très bonne soirée à tous !
Afficher les réponses par date
Jean-Philippe Guérard jean-philippe.guerard@tigreraye.org (26/08/2006):
Personnellement, je suis plutôt contre l'utilisation de po4a comme support unique de traduction des pages de manuels. Autrement dit, je pense qu'un fichier .po ne doit pas être l'outil exclusif de travail du traducteur.
En effet, un document est en général plus facile à traduire correctement car le traducteur dispose du contexte de chacune des phrase (de par la structure même du document). De plus, la relecture du document traduit ne pose, en soi, aucune difficulté particulière.
En comparaison, les logiciels sont très difficiles à traduire. Le traducteur commence par traduire toutes les chaînes du fichier .po (sans forcément comprendre leur contexte), puis, s'il veut obtenir une bonne traduction, il doit lancer la version traduite du logiciel, et essayer de trouver le mode opératoire permettant de faire apparaître tous les textes traduits, afin de vérifier la pertinence de la traduction.
Ce qui est l'équivalent de la relecture pour un logiciel. Selon la complexité et la nature du logiciel, cela peut se révéler de très difficile à impossible.
Utiliser un fichier .po comme support unique de traduction de pages de manuels, cela revient à traduire un document dont le contexte a été masqué. La perte du contexte rend beaucoup plus probable les erreurs de traduction.
La relecture du fichier .po sans relire la page traduite en elle-même ne garantit pas non plus de trouver ces erreurs de traduction. Seule la relecture de la page de manuel traduite permettra de débusquer efficacement de telles erreurs.
Il y a du vrai. Par contre : * la comparaison avec un logiciel est à mon avis mauvaise car si pour un logiciel, il est parfois très difficile de comprendre le contexte d'affichage de la chaîne, pour un document textuel, c'est extrêmement simple. * même si les chaînes communes peuvent se retrouver mélangées, il reste quand même globalement dans le fichier PO une certaine linéarité. Les chaînes uniques sont triées selon leur ordre de leur apparition dans le document original. * je trouve qu'il est beaucoup plus simple de traduire (extrait de intro.1)
We see that there are commands I<date> (that gives date and time), and I<cal> (that gives a calendar).
que
.LP We see that there are commands .I date (that gives date and time), and .I cal (that gives a calendar). .LP
La déformation nécessaire à la mise en page, par exemple avec des retours à la ligne incessants pour les pages de man, entraîne également une perte de contexte. Avec po4a, le traducteur n'a quasiment pas à se soucier de la mise en forme (ce qui en plus abaisse le niveau d'entrée nécessaire aux traducteurs pour participer). * il faut de toute façon relire le document avec un outil adéquat, c'est un processus indispensable pour l'assurance qualité (il y a par exemple po4aman-display-po dans le paquet po4a).
Maintenant, les fichiers .po ne sont pas non plus sans avantages :
- Ils facilitent la mise à jour des traductions.
- Ils peuvent permettre de traduire une seule fois une même phrase utilisée dans plusieurs documents (ce qui peut aussi être vu comme un inconvénient).
Si on évite les POs de 20 000 chaînes, la probabilité de se retrouver dans la situation gênante est extrêmement faible. Cependant, elle existe.
- En segmentant le travail, ils permettent sans doute de partager plus facilement la tâche entre plusieurs traducteurs.
Globalement, je pense que l'utilisation de fichiers .po pour traduire des pages de manuel permet d'obtenir une meilleure productivité, au prix d'une qualité moindre.
Je pense que la qualité est également supérieure, à condition de ne pas traduire chaîne par chaîne comme un robot le ferait. Outre les arguments ci-dessus, les POs facilitent en plus les relectures en fournissant au relecteur la chaîne originale immédiatement au-dessus de la chaîne traduite.
Très bonne soirée à tous !
Merci, toi aussi.
Le 2006-08-26 01:42:33 +0200, Thomas Huriaux écrivait :
Il y a du vrai. Par contre :
- la comparaison avec un logiciel est à mon avis mauvaise car si pour un logiciel, il est parfois très difficile de comprendre le contexte d'affichage de la chaîne, pour un document textuel, c'est extrêmement simple.
Tout à fait d'accord. À condition que le traducteur se réfère au document original et ne travaille pas exclusivement sur le fichier .po.
- même si les chaînes communes peuvent se retrouver mélangées, il reste quand même globalement dans le fichier PO une certaine linéarité. Les chaînes uniques sont triées selon leur ordre de leur apparition dans le document original.
je trouve qu'il est beaucoup plus simple de traduire (extrait de intro.1)
We see that there are commands I<date> (that gives date and time), and I<cal> (that gives a calendar).
que
.LP We see that there are commands .I date (that gives date and time), and .I cal (that gives a calendar). .LP
La déformation nécessaire à la mise en page, par exemple avec des retours à la ligne incessants pour les pages de man, entraîne également une perte de contexte. Avec po4a, le traducteur n'a quasiment pas à se soucier de la mise en forme (ce qui en plus abaisse le niveau d'entrée nécessaire aux traducteurs pour participer).
Dans tous les cas, il faut traduire en ayant la page formatée en version originale sous le nez. Ce que je critique, ce n'est pas le format .po en lui-même, mais la facilité qu'il donne pour traduire sans regarder la version originale, ni relire la version française finale.
Il rend également moins évident l'ajout de notes par le traducteur, par exemple pour signaler un point spécifique à l'utilisation par un francophone.
- il faut de toute façon relire le document avec un outil adéquat, c'est un processus indispensable pour l'assurance qualité (il y a par exemple po4aman-display-po dans le paquet po4a).
Tout à fait d'accord. Relire le fichier .po en lui-même ne suffit pas.
Très bon week-end à tous !
Jean-Philippe Guérard jean-philippe.guerard@tigreraye.org (26/08/2006):
Dans tous les cas, il faut traduire en ayant la page formatée en version originale sous le nez. Ce que je critique, ce n'est pas le format .po en lui-même, mais la facilité qu'il donne pour traduire sans regarder la version originale, ni relire la version française finale.
Je suis d'accord. Quand on utilise le format PO, il ne faut pas tomber dans la facilité en se basant uniquement sur le PO. Mais au final, un traducteur consciencieux fera de toute façon (au moins) les deux choses suivantes : 1. traduction du document original ou du fichier PO 2. relecture du document dans son affichage final
Si la première étape peut être facilitée, autant en profiter.
Au passage, il y a d'autres outils permettant de faciliter la traduction. Je pense en particulier aux TM (mémoires de traduction). Si elles peuvent s'avérer être un outil très puissant (pour la cohérence entre les chaînes, entre autre), là-aussi, le risque pour le traducteur est de se reposer sur les traductions proposées sans faire attention au contexte. Je ne pense pas qu'il faille rejeter un outil pour éviter les pièges, mais plutôt « éduquer » les traducteurs à ne pas tomber dedans (j'avoue moi-même être tombé dans ce piège du « rejet » lorsque Jean-Christophe - que je salue au passage - a présenté OmegaT sur debian-l10n-french).
Il rend également moins évident l'ajout de notes par le traducteur, par exemple pour signaler un point spécifique à l'utilisation par un francophone.
Ici c'est un des désavantages de po4a, à savoir que l'ajout des addenda est une opération plus difficile que l'ajout manuel de paragraphes dans le document traduit. Mais ça reste évidemment possible.
Le 2006-08-26 13:00:42 +0200, Thomas Huriaux écrivait :
Au passage, il y a d'autres outils permettant de faciliter la traduction. Je pense en particulier aux TM (mémoires de traduction). Si elles peuvent s'avérer être un outil très puissant (pour la cohérence entre les chaînes, entre autre), là-aussi, le risque pour le traducteur est de se reposer sur les traductions proposées sans faire attention au contexte. Je ne pense pas qu'il faille rejeter un outil pour éviter les pièges, mais plutôt « éduquer » les traducteurs à ne pas tomber dedans (j'avoue moi-même être tombé dans ce piège du « rejet » lorsque Jean-Christophe - que je salue au passage - a présenté OmegaT sur debian-l10n-french).
Je suis tout à fait d'accord. Je ne vois pas d'inconvénient à utiliser po4a dans le cas d'un projet qui aurait fait ce choix ou de l'utiliser à titre personnel.
Néanmoins, ce n'est pas un outil magique. Il a ses limites. Il a des avantages mais aussi des inconvénients. Il n'améliore pas automatiquement la qualité des traductions. Le fait qu'un projet utilise po4a ne garantit en rien qu'il produira de bonnes traductions.
po4a est un choix technique. Il me paraît légitime de choisir po4a, comme il me paraît légitime pour un projet de choisir de ne pas l'utiliser.
Très bon week-end à tous !
-
Jean-Luc Coulon (f5ibh) -
Jean-Philippe Guérard -
Thomas Huriaux