Je ne vais pas reprendre les arguments de Nicolas et Thomas, que je partage. Je soulignerai juste:
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).
Je préfère traduire avec la chaîne originale en anglais et ma traduction côtes à côtes. Pour cela, le PO est bien plus pratique.
J'insiste un peu sur celui-là. Pou rmoi, je trouve notablement faux le fait de dire que le fichier PO casse le contexte. Etant donné que les chaînes y sont découpées paragraphe par paragraphe, le contexte subsiste bel et bien: ce sont les chaînes précédentes et suivantes....tout simplement.
J'insisterai également très fortement sur un autre point:
- Ils permettent de distribuer des pages cohérentes avec les pages anglaise, même si elles ne sont pas entièrement traduites.
Cela fait....un bon moment....que je passe mon temps à "vendre" la localisation dans le LL et un argument fréquemment rencontré chez les technophiles contre l'utilisation d'environnements localisés est que, notamment pour les pages de man, "elles ne sont jamais à jour".
Et, on peut difficillement dire le contraire. Les pages de man traduites "artisanalement" et totalement désynchronisées avec leur VO sont innombrables. Et, avec la méthode traditionnelle, RIEN n'indique à leur lecteur qu'elles sont basées sur une VO plus ancienne.
Résultat, pou rl'auteur amont, s'il est consciencieux, la seule solution est de supprimer les pages d eman traduites obsolètes. Cela pose déjà la question de savoir COMMENT il peut décider que telle ou telle traduction est obsolète, mais quand bien même pourrait-il le faire que cela revient à jeter au panier du bel et bon travail....:-(
C'est un des énormes avantages que nous a apporté po4a (ou d'autres systèmes basés sur gettext) que de pouvoir dans ce type de cas offrir certes des pages de man partiellement traduites (ce n'est guère gênant d'avoir un seul paragraphe en anglais au milieu de dizaines correctement traduits) et surtout conserver le travail des précédents traducteurs en permettant de le compléter facilement le jour venu.
- Évite au traducteur de se soucier du format groff (on a vite fait de commencer une ligne par une apostrophe ou un point).
Oui. Je n'ai personnellement jamais traduit de page de man "à la main" mais c'est une horreur, le format groff. Cela limite incroyablement les traducteurs capables de travailler sur la traduction de pages de man.
Afficher les réponses par date
Le 2006-08-26 08:51:34 +0200, Christian Perrier écrivait :
Je ne vais pas reprendre les arguments de Nicolas et Thomas, que je partage. Je soulignerai juste:
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).
Je préfère traduire avec la chaîne originale en anglais et ma traduction côtes à côtes. Pour cela, le PO est bien plus pratique.
J'insiste un peu sur celui-là. Pou rmoi, je trouve notablement faux le fait de dire que le fichier PO casse le contexte. Etant donné que les chaînes y sont découpées paragraphe par paragraphe, le contexte subsiste bel et bien: ce sont les chaînes précédentes et suivantes....tout simplement.
C'est aussi un piège. Il est tentant pour le traducteur de ne jamais se reporter à la page de manuel originale, et de ne pas non plus vérifier le rendu final.
Le fichier .po casse le contexte, non pas seulement parce qu'il ne permet pas toujours de voir quel paragraphe suit quel autre, mais aussi parce qu'il masque la structure complète de la page.
Le traducteur risque, au bout du compte, de traduire sans réellement voir ce qu'il fait, mais en pensant bien faire.
Cela fait....un bon moment....que je passe mon temps à "vendre" la localisation dans le LL et un argument fréquemment rencontré chez les technophiles contre l'utilisation d'environnements localisés est que, notamment pour les pages de man, "elles ne sont jamais à jour".
Et, on peut difficillement dire le contraire. Les pages de man traduites "artisanalement" et totalement désynchronisées avec leur VO sont innombrables. Et, avec la méthode traditionnelle, RIEN n'indique à leur lecteur qu'elles sont basées sur une VO plus ancienne.
Résultat, pou rl'auteur amont, s'il est consciencieux, la seule solution est de supprimer les pages d eman traduites obsolètes. Cela pose déjà la question de savoir COMMENT il peut décider que telle ou telle traduction est obsolète, mais quand bien même pourrait-il le faire que cela revient à jeter au panier du bel et bon travail....:-(
C'est un des énormes avantages que nous a apporté po4a (ou d'autres systèmes basés sur gettext) que de pouvoir dans ce type de cas offrir certes des pages de man partiellement traduites (ce n'est guère gênant d'avoir un seul paragraphe en anglais au milieu de dizaines correctement traduits) et surtout conserver le travail des précédents traducteurs en permettant de le compléter facilement le jour venu.
C'est un vrai problème. Mais ce n'est pas la seule solution. Le problème est essentiellement que beaucoup de projets de traduction ne gèrent simplement pas les mise à jour.
Utiliser le format .po pour gérer les traductions est une solution technique, mais ce n'est pas la seule.
Un système de suivi gérant les mises à jour accompagné d'une utilisation astucieuse de diff peut sans doute faire aussi bien.
Très bon week-end à tous !
On 26 août 06, at 19:42, Jean-Philippe Guérard wrote:
Le 2006-08-26 08:51:34 +0200, Christian Perrier écrivait :
J'insiste un peu sur celui-là. Pou rmoi, je trouve notablement faux le fait de dire que le fichier PO casse le contexte. Etant donné que les chaînes y sont découpées paragraphe par paragraphe, le contexte subsiste bel et bien: ce sont les chaînes précédentes et suivantes....tout simplement.
C'est aussi un piège. Il est tentant pour le traducteur de ne jamais se reporter à la page de manuel originale, et de ne pas non plus vérifier le rendu final.
Le fichier .po casse le contexte, non pas seulement parce qu'il ne permet pas toujours de voir quel paragraphe suit quel autre, mais aussi parce qu'il masque la structure complète de la page.
Le traducteur risque, au bout du compte, de traduire sans réellement voir ce qu'il fait, mais en pensant bien faire.
Désolé mais c'est un peu le b.a ba de la traduction que de faire correspondre aux segments qu'on a sous les yeux (et qui dépendent de l'outil utilisé) au fichier source intégral pour avoir du contexte.
Il y a un bail que le monde de la traduction a accepté ça et il ne devrait y avoir aucun problème à demander à ce qu'un traducteur, en même temps qu'il traduit dans un éditeur PO ou autre, consulte la page man originale affichée sur une autre partie de l'écran.
C'est un des énormes avantages que nous a apporté po4a (ou d'autres systèmes basés sur gettext) que de pouvoir dans ce type de cas offrir certes des pages de man partiellement traduites (ce n'est guère gênant d'avoir un seul paragraphe en anglais au milieu de dizaines correctement traduits) et surtout conserver le travail des précédents traducteurs en permettant de le compléter facilement le jour venu.
C'est un vrai problème. Mais ce n'est pas la seule solution. Le problème est essentiellement que beaucoup de projets de traduction ne gèrent simplement pas les mise à jour.
Parce les fichiers bilingues enregistrant les associations entre texte source et texte cible ne sont pas mis en valeurs dans le processus de traduction. Ca aussi c'est un concept (mémoire de traduction) qui est couramment utilisé dans le monde de la traduction.
Utiliser le format .po pour gérer les traductions est une solution technique, mais ce n'est pas la seule.
GNU-> gettext -> PO, pourquoi faire compliqué quand on peu faire simple.
A l'heure actuelle, les logiciels d'aide à la traduction libres sont peu nombreux et ils passent tous soit par PO soit par XLIFF (un XML fonctionnant sur un principe similaire à PO).
Là encore, pas besoin de ré-inventer la roue.
Un système de suivi gérant les mises à jour accompagné d'une utilisation astucieuse de diff peut sans doute faire aussi bien.
Une utilisation des fichiers bilingues déjà disponibles parce que créés lors du passage par PO est encore plus astucieuse parce que prévue pour fonctionner comme ça.
Des applications qui prennent un fichier bilingue (PO, XLIFF, TMX) et analysent les segments de la nouvelle version non présents dans l'ancienne pour simplifier la tache du traducteur existent. Il suffit de les utiliser...
Jean-Christophe Helary
Le 2006-08-26 20:26:14 +0900, Jean-Christophe Helary écrivait :
On 26 août 06, at 19:42, Jean-Philippe Guérard wrote:
Un système de suivi gérant les mises à jour accompagné d'une utilisation astucieuse de diff peut sans doute faire aussi bien.
Une utilisation des fichiers bilingues déjà disponibles parce que créés lors du passage par PO est encore plus astucieuse parce que prévue pour fonctionner comme ça.
Désolé, je n'ai pas été très clair. Tout ce que j'ai dit, c'est que le problème n'est pas ou non d'utiliser un fichier .po, le problème est le fait que beaucoup de projets de traduction ne gèrent pas la mise à jour des documents traduits.
L'utilisation de fichiers .po est une solution technique efficace à ce problème, même si elle n'est pas parfaite, mais ce n'est pas la seule.
Très bon week-end.
On 26 août 06, at 20:56, Jean-Philippe Guérard wrote:
Le 2006-08-26 20:26:14 +0900, Jean-Christophe Helary écrivait :
On 26 août 06, at 19:42, Jean-Philippe Guérard wrote:
Un système de suivi gérant les mises à jour accompagné d'une utilisation astucieuse de diff peut sans doute faire aussi bien.
Une utilisation des fichiers bilingues déjà disponibles parce que créés lors du passage par PO est encore plus astucieuse parce que prévue pour fonctionner comme ça.
Désolé, je n'ai pas été très clair. Tout ce que j'ai dit, c'est que le problème n'est pas ou non d'utiliser un fichier .po, le problème est le fait que beaucoup de projets de traduction ne gèrent pas la mise à jour des documents traduits.
L'utilisation de fichiers .po est une solution technique efficace à ce problème, même si elle n'est pas parfaite, mais ce n'est pas la seule.
Bon, puisqu'on en est à énumérer les solutions possibles allons-y :)
Celle que je connais le mieux pour la pratiquer au quotidien (ou presque):
1-traduction d'un fichier source (format à voir, peut être PO non- bilingue) 2-création d'une mémoire de traduction TMX par l'outil 3-stockage de la mémoire dans un lieu accessible aux personnes concernées
lorsqu'une nouvelle version du document arrive: 4-chargement du nouveau fichier source dans l'outil 5-chargement de la TMX de l'ancienne version 6-traduction automatique des parties communes 7 (=1 plus haut)-traduction manuelle des parties modifiées
etc.
Ce procédé est utilisable avec OmegaT et le filtre PO que Thomas a bien voulu écrire: 0-on crée un PO avec la source exclusivement et on l'utilise comme fichier à traduire
Pour les fichiers man, je suppose que PO comme fichier intermédiaire est le plus simple ?
C'est vrai que OmegaT et PO ne sont pas vraiment prévus pour fonctionner ensemble pour le moment puisque les outils gettext sont justement là pour générer les traductions précédentes.
Si OmegaT avait un filtre PO qui fonctionne directement en bilingue on se casserait moins la tête (à la XLIFF) mais OmegaT est fait pour travailler sur un fichier source monolingue. L'idéal serait d'avoir un filtre groff directement dans OmegaT pour travailler directement sur les man...
Qu'est-ce qu'il y a d'autre comme procédé ?
Jean-Christophe
Jean-Philippe Guérard jean-philippe.guerard@tigreraye.org (26/08/2006):
Le 2006-08-26 20:26:14 +0900, Jean-Christophe Helary écrivait :
On 26 août 06, at 19:42, Jean-Philippe Guérard wrote:
Un système de suivi gérant les mises à jour accompagné d'une utilisation astucieuse de diff peut sans doute faire aussi bien.
Une utilisation des fichiers bilingues déjà disponibles parce que créés lors du passage par PO est encore plus astucieuse parce que prévue pour fonctionner comme ça.
Désolé, je n'ai pas été très clair. Tout ce que j'ai dit, c'est que le problème n'est pas ou non d'utiliser un fichier .po, le problème est le fait que beaucoup de projets de traduction ne gèrent pas la mise à jour des documents traduits.
Nous sommes donc d'accord sur la problématique.
L'utilisation de fichiers .po est une solution technique efficace à ce problème, même si elle n'est pas parfaite, mais ce n'est pas la seule.
Ce n'est pas la seule implémentable. Par contre, si on se limite à ce qui existe pour le moment ou qui est en cours de développement, quelles sont ces autres solutions dont tu parles ?
Je n'en ai pas encore trouvé (hormis l'utilisation de diff et wdiff, pour lesquels je n'ai pas encore vu d'utilisation suffisamment astucieuse pour être réellement utilisable). Et c'est pourtant la confrontation des différentes solutions qui justifierait réellement le débat que nous avons en ce moment :)
Le 2006-08-26 14:55:46 +0200, Thomas Huriaux écrivait :
Jean-Philippe Guérard jean-philippe.guerard@tigreraye.org (26/08/2006):
Le 2006-08-26 20:26:14 +0900, Jean-Christophe Helary écrivait :
On 26 août 06, at 19:42, Jean-Philippe Guérard wrote:
Un système de suivi gérant les mises à jour accompagné d'une utilisation astucieuse de diff peut sans doute faire aussi bien.
Une utilisation des fichiers bilingues déjà disponibles parce que créés lors du passage par PO est encore plus astucieuse parce que prévue pour fonctionner comme ça.
Désolé, je n'ai pas été très clair. Tout ce que j'ai dit, c'est que le problème n'est pas ou non d'utiliser un fichier .po, le problème est le fait que beaucoup de projets de traduction ne gèrent pas la mise à jour des documents traduits.
Nous sommes donc d'accord sur la problématique.
L'utilisation de fichiers .po est une solution technique efficace à ce problème, même si elle n'est pas parfaite, mais ce n'est pas la seule.
Ce n'est pas la seule implémentable. Par contre, si on se limite à ce qui existe pour le moment ou qui est en cours de développement, quelles sont ces autres solutions dont tu parles ?
Re-situont le problème. Nous parlions du fait qu'il existe beaucoup de pages de manuels non mises à jour. Je faisais juste remarquer que le problème n'est pas l'outil utilisé pour réaliser les traductions, mais l'organisation des projets qui ne prennent pas forcément en compte le besoin de mise à jour des traductions.
Des projets comme le Projet de traduction des pages de manuel du LDP (géré par Alain Portal) ou le Projet de traduction des logiciels GNU marchent bien à ce niveau là. Le premier, parce que le responsable du projet gère à la main, mais efficacement, les mises à jour, le second, car il utilise une interface automatisée facilitant les échanges entre les auteurs et les traducteurs.
Bon week-end.
Jean-Philippe Guérard jean-philippe.guerard@tigreraye.org (26/08/2006):
Le 2006-08-26 14:55:46 +0200, Thomas Huriaux écrivait :
Jean-Philippe Guérard jean-philippe.guerard@tigreraye.org (26/08/2006):
Le 2006-08-26 20:26:14 +0900, Jean-Christophe Helary écrivait :
On 26 août 06, at 19:42, Jean-Philippe Guérard wrote:
Un système de suivi gérant les mises à jour accompagné d'une utilisation astucieuse de diff peut sans doute faire aussi bien.
Une utilisation des fichiers bilingues déjà disponibles parce que créés lors du passage par PO est encore plus astucieuse parce que prévue pour fonctionner comme ça.
Désolé, je n'ai pas été très clair. Tout ce que j'ai dit, c'est que le problème n'est pas ou non d'utiliser un fichier .po, le problème est le fait que beaucoup de projets de traduction ne gèrent pas la mise à jour des documents traduits.
Nous sommes donc d'accord sur la problématique.
L'utilisation de fichiers .po est une solution technique efficace à ce problème, même si elle n'est pas parfaite, mais ce n'est pas la seule.
Ce n'est pas la seule implémentable. Par contre, si on se limite à ce qui existe pour le moment ou qui est en cours de développement, quelles sont ces autres solutions dont tu parles ?
Re-situont le problème. Nous parlions du fait qu'il existe beaucoup de pages de manuels non mises à jour. Je faisais juste remarquer que le problème n'est pas l'outil utilisé pour réaliser les traductions, mais l'organisation des projets qui ne prennent pas forcément en compte le besoin de mise à jour des traductions.
Des projets comme le Projet de traduction des pages de manuel du LDP (géré par Alain Portal) ou le Projet de traduction des logiciels GNU marchent bien à ce niveau là. Le premier, parce que le responsable du projet gère à la main, mais efficacement, les mises à jour, le second, car il utilise une interface automatisée facilitant les échanges entre les auteurs et les traducteurs.
Resituons aussi le problème au niveau distribution :)
Supposons la page truc.1 dans la version 1. La version dans Debian est légèrement adaptée.
Pour intégrer les spécificités Debian avec le système actuel, un simple diff suffit (même si ce n'est souvent pas pratique, puisque dans le diff apparaîssent aussi certaines remises en forme qui n'ont aucune incidence sur la traduction). Cela nous oblige quand même à avoir les deux versions originales sous la main, alors que nous ne nous intéressons qu'à Debian.
Le responsable Debian fait remonter en amont les modifications. Le responsable amont en rejette la moitié.
Vient la version 2.
La différence entre la version 1 et la version 2 en amont contient les remarques faites par le responsable Debian et de nouvelles modifications. La différence entre la version 1 et la version 2 chez Debian contient les différences entre la version 1 et la version 2 amont moins celles qui étaient déjà intégrées, et les modifications propres à la version 2 spécifiques à Debian (qui seront peut-être acceptées dans la version 3).
Quelle(s) solution(s) proposes-tu pour que la traduction de la version 2 dans Debian corresponde à l'original dans Debian sans que cela devienne un vrai casse-tête ?
Note : ce n'est qu'une partie de la problématique, à savoir les différences entre distribution.
Le 2006-08-26 16:49:46 +0200, Thomas Huriaux écrivait :
Resituons aussi le problème au niveau distribution :)
Supposons la page truc.1 dans la version 1. La version dans Debian est légèrement adaptée.
Pour intégrer les spécificités Debian avec le système actuel, un simple diff suffit (même si ce n'est souvent pas pratique, puisque dans le diff apparaîssent aussi certaines remises en forme qui n'ont aucune incidence sur la traduction). Cela nous oblige quand même à avoir les deux versions originales sous la main, alors que nous ne nous intéressons qu'à Debian.
Le responsable Debian fait remonter en amont les modifications. Le responsable amont en rejette la moitié.
Vient la version 2.
La différence entre la version 1 et la version 2 en amont contient les remarques faites par le responsable Debian et de nouvelles modifications. La différence entre la version 1 et la version 2 chez Debian contient les différences entre la version 1 et la version 2 amont moins celles qui étaient déjà intégrées, et les modifications propres à la version 2 spécifiques à Debian (qui seront peut-être acceptées dans la version 3).
Quelle(s) solution(s) proposes-tu pour que la traduction de la version 2 dans Debian corresponde à l'original dans Debian sans que cela devienne un vrai casse-tête ?
Oui, je comprends bien que la distribution Débian a ses propres difficultés. Et j'admire le travail qui est réalisé par Débian.
Par curiosité, quelle est le nombre de pages de manuel du Projet de documentation Linux qui ont effectivement été modifiées par Débian ?
Pouvez-vous me donner quelques exemples ?
Merci d'avance.
Très bonne soirée.
Jean-Philippe Guérard jean-philippe.guerard@tigreraye.org (26/08/2006):
Le 2006-08-26 16:49:46 +0200, Thomas Huriaux écrivait :
Resituons aussi le problème au niveau distribution :)
Supposons la page truc.1 dans la version 1. La version dans Debian est légèrement adaptée.
Pour intégrer les spécificités Debian avec le système actuel, un simple diff suffit (même si ce n'est souvent pas pratique, puisque dans le diff apparaîssent aussi certaines remises en forme qui n'ont aucune incidence sur la traduction). Cela nous oblige quand même à avoir les deux versions originales sous la main, alors que nous ne nous intéressons qu'à Debian.
Le responsable Debian fait remonter en amont les modifications. Le responsable amont en rejette la moitié.
Vient la version 2.
La différence entre la version 1 et la version 2 en amont contient les remarques faites par le responsable Debian et de nouvelles modifications. La différence entre la version 1 et la version 2 chez Debian contient les différences entre la version 1 et la version 2 amont moins celles qui étaient déjà intégrées, et les modifications propres à la version 2 spécifiques à Debian (qui seront peut-être acceptées dans la version 3).
Quelle(s) solution(s) proposes-tu pour que la traduction de la version 2 dans Debian corresponde à l'original dans Debian sans que cela devienne un vrai casse-tête ?
Oui, je comprends bien que la distribution Débian a ses propres difficultés. Et j'admire le travail qui est réalisé par Débian.
Par curiosité, quelle est le nombre de pages de manuel du Projet de documentation Linux qui ont effectivement été modifiées par Débian ?
Pouvez-vous me donner quelques exemples ?
Pour les pages du LDP, j'avais fait un diff sur la version 2.39 : http://haydn.debian.org/~thuriaux-guest/tmp/manpages.diff (pas de -N au moment du diff, les pages spécifiques ou renommées apparaissent par une ligne "Only in manpages-deb...").
Je t'invite également à reconsulter mon message de mars : http://benji1.traduc.org/pipermail/traduc/2006-March/004339.html Il y a quelques chiffres assez parlants pour coreutils.
J'aimerais aussi que la discussion continue à s'attacher à la problématique générale (comme c'est le cas depuis quelques messages) sans trop se focaliser sur le cas LDP.
Le 2006-08-26 18:39:18 +0200, Thomas Huriaux écrivait :
Pour les pages du LDP, j'avais fait un diff sur la version 2.39 : http://haydn.debian.org/~thuriaux-guest/tmp/manpages.diff (pas de -N au moment du diff, les pages spécifiques ou renommées apparaissent par une ligne "Only in manpages-deb...").
Ces différences sont loin de me paraître insurmontables. Elle le seraient encore moins en ne tenant pas compte des espaces ajoutés, ce qui, à priori, n'est pas significatif dans ce cas précis.
J'aimerais aussi que la discussion continue à s'attacher à la problématique générale (comme c'est le cas depuis quelques messages) sans trop se focaliser sur le cas LDP.
Si, justement, j'aimerais en parler. C'est même de ça qu'il était question.
Je pensais que la distribution Débian se faisait un point d'honneur à collaborer autant que possible avec les auteurs amont. Mais je peux me tromper.
Je ne comprends toujours pas la nécessité pour Débian de lancer un projet parallèle de traduction des pages de manuel du LDP. D'un autre côté, je reconnais que c'est tout à fait le droit de Débian de le faire.
Cependant je pensais qu'un projet de traduction comme celui de Débian avait déjà beaucoup de boulot. Donc, je ne comprends pas la nécessité de cette duplication du travail.
Il y a un second point qui me chagrine et que j'aimerais aborder. Quand je compare les pages de manuels distribuées par Débian avec les pages de manuels françaises originales, je constate que tous les commentaires de l'en-tête du fichier source français original ont été supprimés (reportez-vous par exemple à la page elf.5).
Cela inclut :
- les mentions indiquant les différents auteurs et contributeurs ; - la licence de diffusion ; - l'historique des révisions.
Ce point me paraît un peu choquant. Pour la page elf.5 par exemple, cette modification viole la licence du document.
D'autre part, comment est gérée la notion d'auteur dans les pages rediffusées par Débian. La mention du traducteur ayant traduit l'essentiel de la page de manuel va-t-elle rester. Va-t-elle être supprimée à la première modification ? Après quelques modifications ?
Voilà. Ce sont les questions du jour. Je pense qu'elle valent la peine que l'on se penche dessus.
Passez tous un très bon week-end.
Jean-Philippe Guérard jean-philippe.guerard@tigreraye.org (27/08/2006):
Le 2006-08-26 18:39:18 +0200, Thomas Huriaux écrivait :
Pour les pages du LDP, j'avais fait un diff sur la version 2.39 : http://haydn.debian.org/~thuriaux-guest/tmp/manpages.diff (pas de -N au moment du diff, les pages spécifiques ou renommées apparaissent par une ligne "Only in manpages-deb...").
Ces différences sont loin de me paraître insurmontables. Elle le seraient encore moins en ne tenant pas compte des espaces ajoutés, ce qui, à priori, n'est pas significatif dans ce cas précis.
Cf. http://lists.debian.org/debian-l10n-french/2006/08/msg00790.html où : 1. j'explique que pour comprendre le problème, il faut se baser sur deux mises à jour successives. 2. je rappelle que ce n'est qu'une partie de la problématique 3. je demande quelles seraient les solutions possibles.
Minimiser la différence sur une seule version d'un groupe de pages particulier n'est pas une solution générale au problème.
Et comme j'aime aussi à le répéter, un système bien conçu est indépendant du nombre de pages concernées par ce problème.
Il y a un second point qui me chagrine et que j'aimerais aborder. Quand je compare les pages de manuels distribuées par Débian avec les pages de manuels françaises originales, je constate que tous les commentaires de l'en-tête du fichier source français original ont été supprimés (reportez-vous par exemple à la page elf.5).
Cela inclut :
- les mentions indiquant les différents auteurs et contributeurs ;
- la licence de diffusion ;
- l'historique des révisions.
Ce point me paraît un peu choquant. Pour la page elf.5 par exemple, cette modification viole la licence du document.
C'est un bug dans po4a, qui sera corrigé très bientôt.
D'autre part, comment est gérée la notion d'auteur dans les pages rediffusées par Débian. La mention du traducteur ayant traduit l'essentiel de la page de manuel va-t-elle rester. Va-t-elle être supprimée à la première modification ? Après quelques modifications ?
Dans les addenda, la liste des traducteurs est (et sera) conservée.
Le 2006-08-27 13:54:35 +0200, Thomas Huriaux écrivait :
Minimiser la différence sur une seule version d'un groupe de pages particulier n'est pas une solution générale au problème.
Je ne souhaite pas minimiser les difficultés spécifiques à Débian, difficultés que je comprends.
Je souhaitais juste répondre à la question initiale, c'est à dire :
« 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 pense que j'ai donné ma réponse à cette question, même si tout le monde n'est pas d'accord avec mon opinion, ce qui me paraît normal et respectable.
Je ne comprends toujours pas que Débian ait décidé de lancer un projet parallèle de traduction des pages de manuels LDP. Peu importe.
Je n'ai pas fourni de solution technique aux difficultés du projet Débian, et je m'en excuse. Mais ce n'est pas mon rôle, et ce n'était pas non plus le sujet de la discussion. La aussi il semble que tout le monde ne soit pas d'accord.
Je m'excuse de vous avoir embêté avec mes questions et mes commentaires.
Une nouvelle fois, je voudrais mentionner que j'apprécie beaucoup le travail réaliser par Débian.
Très bon week-end à tous.
Je ne comprends toujours pas que Débian ait décidé de lancer un projet parallèle de traduction des pages de manuels LDP. Peu importe.
Je vais choquer probablement un poil mais une des raisons est notamment que nous souhaitions *en premier lieu* pouvoir fournir des pages de man à jour à NOS utilisateurs.
Cela fait partie du contrat social Debian: "Our priorities are our users and free software". L'équipe l10n francophone a jugé que la méthode la plus efficace pour nous d'offrir des pages de man à jour à nos utilisateurs dans la release en préparation était de procéder ainsi.
Cela (que faire un fork est le plus efficace) était vrai au moment où cette traduction "parallèle" s'est mis en place. Rien ne dit que cela le restera...notamment si les efforts actuels pour faire reconverger les choses aboutissent.
Jean-Philippe Guérard a écrit :
[...]
J'aimerais aussi que la discussion continue à s'attacher à la problématique générale (comme c'est le cas depuis quelques messages) sans trop se focaliser sur le cas LDP.
Si, justement, j'aimerais en parler. C'est même de ça qu'il était question.
Je pensais que la distribution Débian se faisait un point d'honneur à collaborer autant que possible avec les auteurs amont. Mais je peux me tromper.
Ben, justement, non, tu as tout à fait raison !!
c'est la raison du lancement de ce long thread... http://lists.debian.org/debian-l10n-french/2006/08/msg00355.html
La question que j'avais posée, c'est justement comment se goupiller pour fédérer nos travaux..
Je ne comprends toujours pas la nécessité pour Débian de lancer un projet parallèle de traduction des pages de manuel du LDP. D'un autre côté, je reconnais que c'est tout à fait le droit de Débian de le faire.
Cependant je pensais qu'un projet de traduction comme celui de Débian avait déjà beaucoup de boulot. Donc, je ne comprends pas la nécessité de cette duplication du travail.
J'ai traduit quelques pages de man, dans divers groupes.. Debian, mais aussi sur le site de Gérard Delafond...
Loin de moi, je pense, l'esprit de chapelle (ou plutôt, si, une seule.. le libre ! :-)) C'est pour ça que l'idée d'un fork me génait un peu...
Et c'est justement pour faire avancer l'interconnexion de l'ensemble que j'ai essayé de lancer la discussion.. voir comment on pourrait s'organiser..
De mon coté, je vais essayer de remonter mes travaux aux différents intervenants.. Malheureusement, je n'ai pas le temps nécessaire d'assurer une tentative de coordination entre tous.. je le regrette bien d'ailleurs...
Bon week end
On Sun, Aug 27, 2006 at 01:09:20PM +0200, Jean-Philippe Guérard wrote: [...]
Je pensais que la distribution Débian se faisait un point d'honneur à collaborer autant que possible avec les auteurs amont. Mais je peux me tromper.
Il n'y a pas d'incompatibilité avec la situation actuelle. Lorsque je fournissais un paquet Debian basé sur manpagesfr.free.fr, je faisais remonter les corrections des utilisateurs. C'est celà, collaborer avec les auteurs amont. Une fois que j'ai décidé de forker, je n'ai plus d'auteur amont. C'est le principe d'un fork.
Je ne comprends toujours pas la nécessité pour Débian de lancer un projet parallèle de traduction des pages de manuel du LDP. D'un autre côté, je reconnais que c'est tout à fait le droit de Débian de le faire.
Cependant je pensais qu'un projet de traduction comme celui de Débian avait déjà beaucoup de boulot. Donc, je ne comprends pas la nécessité de cette duplication du travail.
Effectivement, on ne voit pas les choses sous le même angle. Tu les vois comme traducteur amont, je les vois comme distributeur. Si tu veux comprendre les motivations, il faut te mettre à ma place.
Il y a un second point qui me chagrine et que j'aimerais aborder. Quand je compare les pages de manuels distribuées par Débian avec les pages de manuels françaises originales, je constate que tous les commentaires de l'en-tête du fichier source français original ont été supprimés (reportez-vous par exemple à la page elf.5).
Cela inclut :
- les mentions indiquant les différents auteurs et contributeurs ;
- la licence de diffusion ;
- l'historique des révisions.
Ce point me paraît un peu choquant. Pour la page elf.5 par exemple, cette modification viole la licence du document.
D'autre part, comment est gérée la notion d'auteur dans les pages rediffusées par Débian. La mention du traducteur ayant traduit l'essentiel de la page de manuel va-t-elle rester. Va-t-elle être supprimée à la première modification ? Après quelques modifications ?
Si tu regardes la section TRADUCTION de ces pages, tu verras qu'un gros boulot a été fait pour justement ne pas oublier le crédit à apporter aux anciens traducteurs. Si tu penses qu'il manque quelque chose, n'hésite pas à nous le faire savoir. Merci.
Denis
[J'ai supprimé debian-l10n-french, les personnes intéressées sont a priori abonnées à traduc]
On Sat, Aug 26, 2006 at 01:56:57PM +0200, Jean-Philippe Guérard wrote: [...]
Désolé, je n'ai pas été très clair. Tout ce que j'ai dit, c'est que le problème n'est pas ou non d'utiliser un fichier .po, le problème est le fait que beaucoup de projets de traduction ne gèrent pas la mise à jour des documents traduits.
L'utilisation de fichiers .po est une solution technique efficace à ce problème, même si elle n'est pas parfaite, mais ce n'est pas la seule.
Comme je l'expliquais au début de cette aventure, http://benji1.traduc.org/pipermail/traduc/2005-December/004212.html les distributions sont parfois amenées à adapter la documentation, et les traductions devraient en toute logique être aussi modifiées. Si les traducteurs pouvaient adopter des méthodes de traduction gérant la mise à jour et facilitant le travail dérivé, il est évident que ça arrangerait tout le monde.
Denis
-
Christian Perrier -
Denis Barbier -
Jean-Christophe Helary -
Jean-Philippe Guérard -
Sylvain Cherrier -
Thomas Huriaux