Salut.
J'aimerais suggérer un petit état des lieux sur le présent et l'avenir en ce qui concerne le présent groupe de traduction mais aussi ceux avec lesquels il collabore.
D'autre part, il y a quelques discussions off-list dont le fait de les tenir en public pourrait pporter je pense une meilleure dynamique, afin que tout le monde puisse suggérer des idées et/ou prendre sa part du boulot.
Si j'ai bien compris, nous avons :
- Martin Quinson, déjà actif dans le projet de Traduction de Debian prend en main la gestion des trads des programmes (docs ?) du projet GNU dans le cadre du "Translation Project" (lire Translation Project des éléments du projet GNU)
- Nicolas Chauvat, gestionnaire du projet de traduction en français du Linux Documentation Project (LDP == HOWTOs, mans et autres)
- Christophe Merlet (récemment arrivé ici), gestionnaire du projet (moins formel que les précédents pour l'instant) de traduction de Gnome en français (rattaché au Gnome Translation Project), btw qui vient de rejoindre cette liste
D'autres, que je ne citerai pas pour l'instant.
Il me semble qu'il y a de fortes synergies entre ces 3/4 projets à développer.
Ma réflexion, dans la continuité de celles entamées depuis cet été sur le sujet, ici notamment, vient de l'absence de page pour le projet gnomefr (gnomefr.traduc.org jusque là), et de liste de discussion dédiée, et de ma volonté d'aider à réparer cet état de fait.
Je pense qu'il serait intéressant de mutualiser les outils et méthodes, notamment : entre le projet GNU et Gnome pour les trads d'applis, et entre le LDP et Gnome pour la doc...
Ayant pris contact avec Joël Bernier, qui gère la machine hébergeant traduc.org, j'ai discuté avec lui, et il semble qu'il ait quelques projets pour traduc.org. Nicolas Chauvat aussi, si j'ai bien compris. Comme Gnome n'a pas encore de page, il serait bon, je pense que Christophe Merlet soit associé à ces discussions car s'il faut faire des pages/ mettre des resources de gestion du projet en place, autant mutualiser / réutiliser au mieux.
Voilà quelques réflexions destinées à instaurer une discussion sur ces sujets, vous permettant en outre de faire plus ample connaissance...
En espérant faire avancer un peu plus le schmilblick... et afin de diminuer les échanges de mails privés, et devoir répeter des infos à droite ou à gauche...
Mes 2 centimes d'euro...
Bon courage et merci d'avance de tout commantaire.
Afficher les réponses par date
D'autre part, il y a quelques discussions off-list dont le fait de les tenir en public pourrait pporter je pense une meilleure dynamique, afin que tout le monde puisse suggérer des idées et/ou prendre sa part du boulot.
Bonne idée.
Si j'ai bien compris, nous avons :
- Martin Quinson, déjà actif dans le projet de Traduction de Debian
prend en main la gestion des trads des programmes (docs ?) du projet GNU dans le cadre du "Translation Project" (lire Translation Project des éléments du projet GNU)
Il s'agit pour utiliser un terme anglophone et tenter d'être le plus précis, de la "localisation" des programmes GNU. La doc est traitée séparément.
- Nicolas Chauvat, gestionnaire du projet de traduction en français du
Linux Documentation Project (LDP == HOWTOs, mans et autres)
C'est moi :-)
- Christophe Merlet (récemment arrivé ici), gestionnaire du projet
(moins formel que les précédents pour l'instant) de traduction de Gnome en français (rattaché au Gnome Translation Project), btw qui vient de rejoindre cette liste
Bienvenue !
D'autres, que je ne citerai pas pour l'instant.
Pourraient-ils dire un petit bonjour pour rappeller à tout le monde qui ils sont et ce qu'ils font ?
Il me semble qu'il y a de fortes synergies entre ces 3/4 projets à développer.
Je pense qu'il serait intéressant de mutualiser les outils et méthodes, notamment : entre le projet GNU et Gnome pour les trads d'applis, et entre le LDP et Gnome pour la doc...
A mon avis, les principaux problèmes de la situation actuelle sont :
1. difficile, parmi tous les projets en cours, de savoir rapidement qui a besoin d'aide et pour quoi
2. difficile d'installer les outils pour DocBook,
3. difficile de savoir rapidement quels outils et formats employer,
4. difficile, quand on maintient une traduction, de savoir ce qui a changé depuis la version précédente lorsqu'il y a une mise à jour
5. déplaisant, quand on prend sur son temps libre pour traduire, de ne pas voir le résultat de son travail publié rapidement,
6. difficle, quand on coordonne un projet de traduction, de s'assurer de la qualité des documents et de ne pas trop ralentir le mouvement,
XYZ. qu'en pensez-vous ?
Ayant pris contact avec Joël Bernier, qui gère la machine hébergeant traduc.org, j'ai discuté avec lui, et il semble qu'il ait quelques projets pour traduc.org. Nicolas Chauvat aussi, si j'ai bien compris. Comme Gnome n'a pas encore de page, il serait bon, je pense que Christophe Merlet soit associé à ces discussions car s'il faut faire des pages/ mettre des resources de gestion du projet en place, autant mutualiser / réutiliser au mieux.
Pour traiter les points ci-dessus, voilà quelques idées :
Pour 1. rassembler un peu plus les projets. L'idée n'est pas de tout intégrer dans une structure rigide, mais de permettre à ceux qui veulent conrtibuer de s'y retrouver plus facilement. Une façon de faire serait de maintenir un site web commun dans lequel les différents projets auraient chacun une section qui respecterait une même structure (description, référence mailing-list, outils, état de la traduction, ...)
La navigation serait ainsi plus facile et on peut espérer fédérer les différentes tâches à faire au moyen de canaux RSS, par exmple, pour les présenter sur la page d'accueil.
Lorsque j'ai eu Joël au téléphone hier, nous avons discuté de la possibilité de mettre en place un CVS sur www.traduc.org, lequel permettrait aux coordinateurs des différents projets de maintenir à jour leurs pages web. Pour que tout ait même un aspect, je propose d'employer une représentation intermédiaire en XML, à partir de laquelle seront générées les pages du site. Y'aurait rien à inventer, je génére déjà www.traduc.org comme ça...
Pour 2. Il faut attendre que les distributions fassent avancer les choses, ou s'organiser un peu pour pousser à la roue. Il me semble qu'il y a déjà pas mal de documentation disponible sur le sujet, mais parfois, trop de documentation nuit à la documentation, pour le débutant tout au moins.
Pour 3. Se mettre d'accord sur les formats et développer des outils pour les manipuler. Mon avis personnel est formé : DocBook/XML 4.1.2 comme format de base, convertible au besoin en po/html/pdf/ps etc. (oui, oui, .po inclus pour gérer les versions avec les mêmes outils :-)
Pour 4. Logilab a contribué http://www.logilab.org/xmldiff/ dont j'ai déjà parlé sur cette liste. Je n'ai pas eu plus de temps à y consacrer, un volontaire pour creuser le sujet serait le bienvenu.
Pour 5. S'il y avait moins de format différents et de possibilités d'avoir des problèmes au moment de la génération des documents, j'avoue que le genre de travail que j'ai à faire serait facilité.
Pour 6. C'est le problème de la relecture et de la qualité du résultat. Avec certains traducteurs, la relecture est presque inutile, avec d'autres elle est tout simplement indispensable. Il faut cependant que tous puissent participer et il est difficile pour celui qui coordonne de se faire une idée de la qualité du résultat sans lire une grosse part des documents, ce qui prend du temps... et ralenti encore le processus de publication.
Remarque finale : j'avais dit la dernière fois que je ferai un résumé de notre discussion au resto et de celle qui avait suivi sur la liste, mais je n'ai pas trouvé le temps. Pourrions-nous cette fois-ci trouver un volontaire "secrétaire de séance" qui nous fera un résumé qui sera mis sur www.traduc.org et mis à jour au fur et à mesure ?
On Wed, Oct 03, 2001 at 05:30:45PM +0200, Nicolas Chauvat wrote:
D'autre part, il y a quelques discussions off-list dont le fait de les tenir en public pourrait pporter je pense une meilleure dynamique, afin que tout le monde puisse suggérer des idées et/ou prendre sa part du boulot.
Bonne idée.
Si j'ai bien compris, nous avons :
- Martin Quinson, déjà actif dans le projet de Traduction de Debian
prend en main la gestion des trads des programmes (docs ?) du projet GNU dans le cadre du "Translation Project" (lire Translation Project des éléments du projet GNU)
Vi, on parle pas de la doc des programmes, mais des messages affichés par les programmes. Il s'agit donc de traduire les classiques fichiers pot en non moins classiques fichiers po. Et précision supplémentaire, j'y tiens pour m'etre fait grondé par Karl y'a pas longtemps, le GNU est de trop dans le nom. Quasi tous les programmes GNU (au sens, parainés par la FSF) sont la dedans, mais y'a pas besoin d'etre GNU pour profiter de cette infrastructure. J'avais discuté avec Francois Pinard (l'auteur originel, meme s'il semble s'etre dégagé) y'a maintenant un moment, et il disait qu'il regrettait que les autres projets tels que kde, gnome et debian aient mis en place une infrastructure comparable.
Donc, une fois pour toute, d'accord pour parler de projet de traduction GNU à l'oral (en concidérant la liste de diffusion comme orale), mais dans les faits, il s'agit du 'projet de traduction libre', ouvert à tous.
- Nicolas Chauvat, gestionnaire du projet de traduction en français du
Linux Documentation Project (LDP == HOWTOs, mans et autres)
C'est moi :-)
Bonjour !
- Christophe Merlet (récemment arrivé ici), gestionnaire du projet
(moins formel que les précédents pour l'instant) de traduction de Gnome en français (rattaché au Gnome Translation Project), btw qui vient de rejoindre cette liste
Salut RedFox ! C'est moins formel du coté de Gnome parce que pendant un moment, il y a eu un seul traducteur régulier (lui) et de rares occasionels (dont moi), alors l'irc etait amplement suffisant pour gerer tout ca. Mais les choses sont en train de bouger...
D'autres, que je ne citerai pas pour l'instant.
Ah, dommage...
Il doit bien y avoir quelqu'un de KDE et quelqu'un d'autre de python dans la salle, non ? Qui d'autre ?
Il me semble qu'il y a de fortes synergies entre ces 3/4 projets à développer.
A mon avis, les principaux problèmes de la situation actuelle sont :
- difficile, parmi tous les projets en cours, de savoir rapidement qui a besoin d'aide et pour quoi
Pour 1. rassembler un peu plus les projets. L'idée n'est pas de tout intégrer dans une structure rigide, mais de permettre à ceux qui veulent conrtibuer de s'y retrouver plus facilement. Une façon de faire serait de maintenir un site web commun dans lequel les différents projets auraient chacun une section qui respecterait une même structure (description, référence mailing-list, outils, état de la traduction, ...)
La navigation serait ainsi plus facile et on peut espérer fédérer les différentes tâches à faire au moyen de canaux RSS, par exmple, pour les présenter sur la page d'accueil.
Lorsque j'ai eu Joël au téléphone hier, nous avons discuté de la possibilité de mettre en place un CVS sur www.traduc.org, lequel permettrait aux coordinateurs des différents projets de maintenir à jour leurs pages web. Pour que tout ait même un aspect, je propose d'employer une représentation intermédiaire en XML, à partir de laquelle seront générées les pages du site. Y'aurait rien à inventer, je génére déjà www.traduc.org comme ça...
Je suis assez d'accord, mais j'ai un bemol : on a des pages chez Debian, qui ont le look 'page Debian' classique, et on a pas le gout d'en faire 15 sortes... Je suppose que c'est pareil pour tous les projets. En regroupant tout ce qui parle de trad, on disperse ce qui parle de Debian. C'est inévitable.
- difficile d'installer les outils pour DocBook,
Pour 2. Il faut attendre que les distributions fassent avancer les choses, ou s'organiser un peu pour pousser à la roue. Il me semble qu'il y a déjà pas mal de documentation disponible sur le sujet, mais parfois, trop de documentation nuit à la documentation, pour le débutant tout au moins.
no comment qui ne soit pas un troll
- difficile de savoir rapidement quels outils et formats employer,
Pour 3. Se mettre d'accord sur les formats et développer des outils pour les manipuler. Mon avis personnel est formé : DocBook/XML 4.1.2 comme format de base, convertible au besoin en po/html/pdf/ps etc. (oui, oui, .po inclus pour gérer les versions avec les mêmes outils :-)
Je suis *vraiment* d'accord avec ce souhait d'universalité du format po. Je pense que les traducteurs ont maintenant des outils sympas pour traduire les po, tels que kbabel, gtranslator, ou le mode po d'emacs, et il faut leur permettre de les utiliser.
- difficile, quand on maintient une traduction, de savoir ce qui a changé depuis la version précédente lorsqu'il y a une mise à jour
Pour 4. Logilab a contribué http://www.logilab.org/xmldiff/ dont j'ai déjà parlé sur cette liste. Je n'ai pas eu plus de temps à y consacrer, un volontaire pour creuser le sujet serait le bienvenu.
Ben alors ? On est plus d'accord, là. Moi, je pense qu'il faut convertir le XML en po, traduire le po, puis réinjecter le texte dans le XML. Dans ce cas, on peut oublier ces histoires de xmldiff, c'est déja fait par gettext lors de la création des po...
- déplaisant, quand on prend sur son temps libre pour traduire, de ne pas voir le résultat de son travail publié rapidement,
Pour 5. S'il y avait moins de format différents et de possibilités d'avoir des problèmes au moment de la génération des documents, j'avoue que le genre de travail que j'ai à faire serait facilité.
Oui. gettext rules. Voila pour la famille d'outils. Ensuite, pour l'extraction/la remise en place des chaines à traduire, les gens de KDE ont ca, meme s'il me semble qu'on devrait pouvoir améliorer un peu.
Pour la logistique, j'y reviens apres.
- difficle, quand on coordonne un projet de traduction, de s'assurer de la qualité des documents et de ne pas trop ralentir le mouvement,
Pour 6. C'est le problème de la relecture et de la qualité du résultat. Avec certains traducteurs, la relecture est presque inutile, avec d'autres elle est tout simplement indispensable. Il faut cependant que tous puissent participer et il est difficile pour celui qui coordonne de se faire une idée de la qualité du résultat sans lire une grosse part des documents, ce qui prend du temps... et ralenti encore le processus de publication.
Chez Debian, le role de relecteur et de coordinateur est séparé. On poste sur la liste tout ce qu'on voudrait voir relire, et on a des gens qui font ca tres bien. Mieux que ce que nous, coordinateurs avec Denis nous ne pourrions faire. Chacun son job.
De plus, toujours chez Debian, on pense qu'il vaut mieux moins de traduction de meilleur qualité. On veut pas faire du chiffre. Donc, on passe beaucoup de temps à relire. Donc, un traducteur qui fait une mauvaise traduction va se manger pleins de mails de correction et il va passer un sale quart d'heure pour integrer toutes ces corrections. La fois suivante, il utilisera ispell avant d'envoyer son document, il fera attention à ce que le format de son document soit juste d'un point de vue technique et tout et tout. Mais on a de la chance d'avoir de bons relecteurs, aussi.
Dans mes reves les plus fous, on aurait des moulinettes pour extraire dans des fichiers po tous les formats existants, afin que les traducteurs et relecteurs puissent faire leur boulot sans se soucier de savoir si c'est un livre, les messages d'un programme, la page man, des fichiers debconf, la description d'un paquet ou dieu sait quoi.
Ensuite, on utiliserait tous des robots comme celui du projet de traduction GNU. Voire ce robot la exactement, lui meme. Je ne parle pas de cette instance la, mais de ce programme la. Ie, de la meme facon qu'il existe des floppées de bugzilla sur terre, il pourrait y avoir des floppées de TP-Robot.
Ce robot gererait qui traduit quoi, relancerait les traducteurs quand qqch change, demanderait leur avis à quelques relecteurs triés sur le volet avant d'accepter quoi que ce soit, ferait de belles pages webs de statistiques, et ainsi de suite. La vie serait belle, et les coordinateurs pourraient aller dormir (ce que je fais maintenant ;).
Remarque finale : j'avais dit la dernière fois que je ferai un résumé de notre discussion au resto et de celle qui avait suivi sur la liste, mais je n'ai pas trouvé le temps. Pourrions-nous cette fois-ci trouver un volontaire "secrétaire de séance" qui nous fera un résumé qui sera mis sur www.traduc.org et mis à jour au fur et à mesure ?
Je suis d'accord, car je suis marié à Lyon, alors c'est meme pas la peine de me parler de bouffe à Paris...
M'en fous, j'ai au moins deux espions dans la place : Denis et RedFox... ;)
Bye, Mt.
Martin Quinson wrote:
Je suis assez d'accord, mais j'ai un bemol : on a des pages chez Debian, qui ont le look 'page Debian' classique, et on a pas le gout d'en faire 15 sortes...
Si les données statistiques sont dans une base de données, cela permets à chaque équipe de traduction de gérer le look de ses pages web comme il l'entends.
Je suppose que c'est pareil pour tous les projets. En regroupant tout ce qui parle de trad, on disperse ce qui parle de Debian. C'est inévitable.
Pas forcement, quand je parle de l'état des traductions GNOME, je pense à l'état du CVS GNOME à l'instant t. Dans Debian parle de l'état des traductions, c'est de l'état des paquet qu'elle distribue (y compris la description des paquets). Ce sont deux traductions différentes, même si elles sont similaires. Je ne pense pas que cela disperse le travail de l'équipe Debian à partir du moment ou les traductions sont différenciées.
Je suis *vraiment* d'accord avec ce souhait d'universalité du format po.
Je ne pense pas que le format po soit bien adapté à de la documentation, c.a.d. des phrases/textes faisant plus de 10 lignes.
Ben alors ? On est plus d'accord, là. Moi, je pense qu'il faut convertir le XML en po, traduire le po, puis réinjecter le texte dans le XML. Dans ce cas, on peut oublier ces histoires de xmldiff, c'est déja fait par gettext lors de la création des po...
Je suis d'accord avec Mt. Le _vrai_ format de fichier de traduction est le format .po. XML ne doit être au mieux qu'un format intermédiaire.
Oui. gettext rules. Voila pour la famille d'outils. Ensuite, pour l'extraction/la remise en place des chaines à traduire, les gens de KDE ont ca, meme s'il me semble qu'on devrait pouvoir améliorer un peu.
Le projet GNOME utilise intl-tools (ex xml-i18n-tools) pour l'extraction/insertion de chaînes dans tout les types de fichiers d'un paquet contenant des chaînes à traduire et ça marche plutôt bien.
Dans mes reves les plus fous, on aurait des moulinettes pour extraire dans des fichiers po tous les formats existants, afin que les traducteurs et relecteurs puissent faire leur boulot sans se soucier de savoir si c'est un livre, les messages d'un programme, la page man, des fichiers debconf, la description d'un paquet ou dieu sait quoi.
Je me répète, le format po pour de la documentation de ma parait pas du tout adapté.
Ensuite, on utiliserait tous des robots comme celui du projet de traduction GNU. Voire ce robot la exactement, lui meme. Je ne parle pas de cette instance la, mais de ce programme la. Ie, de la meme facon qu'il existe des floppées de bugzilla sur terre, il pourrait y avoir des floppées de TP-Robot.
Ce robot gererait qui traduit quoi, relancerait les traducteurs quand qqch change, demanderait leur avis à quelques relecteurs triés sur le volet avant d'accepter quoi que ce soit, ferait de belles pages webs de statistiques, et ainsi de suite. La vie serait belle, et les coordinateurs pourraient aller dormir (ce que je fais maintenant ;).
Par contre, un robot pour surveiller les changements dans les fichiers de traduction et tenir informer les coordinateurs/traducteurs/relecteurs ça me plait.
Je suis d'accord, car je suis marié à Lyon, alors c'est meme pas la peine de me parler de bouffe à Paris...
M'en fous, j'ai au moins deux espions dans la place : Denis et RedFox... ;)
Je ne suis pas sûr de bien comprendre ta phrase :-/ Je n'était pas à ce repas. Et il y a peu de chance que je participe à un des ces bouffes. J'habites à Pau dans le Sud-Sud-Ouest, c'est encore plus loin que Lyon...
On Thu, Oct 04, 2001 at 09:52:54AM +0200, Christophe Merlet wrote:
Martin Quinson wrote:
Je suppose que c'est pareil pour tous les projets. En regroupant tout ce qui parle de trad, on disperse ce qui parle de Debian. C'est inévitable.
Pas forcement, quand je parle de l'état des traductions GNOME, je pense à l'état du CVS GNOME à l'instant t. Dans Debian parle de l'état des traductions, c'est de l'état des paquet qu'elle distribue (y compris la description des paquets). Ce sont deux traductions différentes, même si elles sont similaires.
Vi, mais mon avis c'est que Debian n'a pas à traduire les paquets issus de gnome. Je t'ai envoyé toutes les bonnes ames qui se présentaient pour traduire des gnomeries sur les listes Debian. Et d'une maniere plus générale, c'est à la source du code de traduire. Quand ce n'est pas possible (pour les ptits projets), il reste le projet de traduction libre...
Je ne pense pas que cela disperse le travail de l'équipe Debian à partir du moment ou les traductions sont différenciées.
Je parlais de disperser les informations relatives à Debian, pas le travail.
Je suis *vraiment* d'accord avec ce souhait d'universalité du format po.
Je ne pense pas que le format po soit bien adapté à de la documentation, c.a.d. des phrases/textes faisant plus de 10 lignes.
Euh, le format n'est pas idéal pour ces grandes chaines, mais c'est le seul existant permettant un minimum d'automatisation (a ma connaissance)...
Ben alors ? On est plus d'accord, là. Moi, je pense qu'il faut convertir le XML en po, traduire le po, puis réinjecter le texte dans le XML. Dans ce cas, on peut oublier ces histoires de xmldiff, c'est déja fait par gettext lors de la création des po...
Je suis d'accord avec Mt. Le _vrai_ format de fichier de traduction est le format .po. XML ne doit être au mieux qu'un format intermédiaire.
Oui. gettext rules. Voila pour la famille d'outils. Ensuite, pour l'extraction/la remise en place des chaines à traduire, les gens de KDE ont ca, meme s'il me semble qu'on devrait pouvoir améliorer un peu.
Le projet GNOME utilise intl-tools (ex xml-i18n-tools) pour l'extraction/insertion de chaînes dans tout les types de fichiers d'un paquet contenant des chaînes à traduire et ça marche plutôt bien.
Si j'ai bien compris, cet outil gnome permet de traduire des attributs de balises tandis que l'outil KDE permet de traduire le texte entre les balises. Unifier les deux est l'amélioration dont je parlais...
Dans mes reves les plus fous, on aurait des moulinettes pour extraire dans des fichiers po tous les formats existants, afin que les traducteurs et relecteurs puissent faire leur boulot sans se soucier de savoir si c'est un livre, les messages d'un programme, la page man, des fichiers debconf, la description d'un paquet ou dieu sait quoi.
Je me répète, le format po pour de la documentation de ma parait pas du tout adapté.
Et quoi d'autre, alors ?
Je suis d'accord, car je suis marié à Lyon, alors c'est meme pas la peine de me parler de bouffe à Paris...
M'en fous, j'ai au moins deux espions dans la place : Denis et RedFox... ;)
Je ne suis pas sûr de bien comprendre ta phrase :-/ Je n'était pas à ce repas. Et il y a peu de chance que je participe à un des ces bouffes. J'habites à Pau dans le Sud-Sud-Ouest, c'est encore plus loin que Lyon...
Merdalors. Bon, ben soit Denis est un espion super efficace, soit il nous faut absolument des compte-rendus de sessions (et je préfererais la seconde solution).
Bye, Mt.
Martin Quinson wrote:
Vi, mais mon avis c'est que Debian n'a pas à traduire les paquets issus de gnome. Je t'ai envoyé toutes les bonnes ames qui se présentaient pour traduire des gnomeries sur les listes Debian. Et d'une maniere plus générale, c'est à la source du code de traduire. Quand ce n'est pas possible (pour les ptits projets), il reste le projet de traduction libre...
Je suis d'accord.
Si j'ai bien compris, cet outil gnome permet de traduire des attributs de balises tandis que l'outil KDE permet de traduire le texte entre les balises. Unifier les deux est l'amélioration dont je parlais...
intl-tools permet de reconnaitre dans dans les fichiers de différents formats (.c, .h, xml, ini, ...) les balises identifiants une chaîne à traduire. D'extraire la chaîne et l'intégrer dans un fichier .pot. de synchroniser les po avec le pot. Puis de réintégrer les traductions si nécessaires dans les différents format de fichiers (xml, ini, ...) comme les .desktop par exemple.
intl-tools permet de reconnaitre dans dans les fichiers de différents formats (.c, .h, xml, ini, ...) les balises identifiants une chaîne à traduire. D'extraire la chaîne et l'intégrer dans un fichier .pot. de synchroniser les po avec le pot. Puis de réintégrer les traductions si nécessaires dans les différents format de fichiers (xml, ini, ...) comme les .desktop par exemple.
Une URL serait bienvenue, à moins qu'il ne faille faire appel au Google tout puissant ?
Nicolas Chauvat wrote:
Une URL serait bienvenue, à moins qu'il ne faille faire appel au Google tout puissant ?
La voici : ftp://ftp.gnome.org/pub/gnome/unstable/sources/intltool/intltool-0.9.5.tar.bz2
PS : Personne n'a jamais eu l'idée de configurer la liste pour avoir un reply-to sur la liste ?
On Thu, 4 Oct 2001, Christophe Merlet wrote:
PS : Personne n'a jamais eu l'idée de configurer la liste pour avoir un reply-to sur la liste ?
C'est une FAQ à propos des listes de discussions. La réponse est "Non, car c'est une mauvaise pratique". Je n'ai pas d'URL à portée de main pour te dire quel document lire pour t'en convaincre, mais si tu cherches sur Google, tu devrais pouvoir trouver. A moins que quelqu'un sur la liste ne puisse donner une référence ?
Le Thu, Oct 04, 2001 at 12:15:00PM +0200, Nicolas Chauvat a écrit:
PS : Personne n'a jamais eu l'idée de configurer la liste pour avoir un reply-to sur la liste ?
C'est une FAQ à propos des listes de discussions. La réponse est "Non, car c'est une mauvaise pratique". Je n'ai pas d'URL à portée de main pour te dire quel document lire pour t'en convaincre, mais si tu cherches sur Google, tu devrais pouvoir trouver. A moins que quelqu'un sur la liste ne puisse donner une référence ?
Il suffit de bien configurer son mutt afin qu'il reconnaisse la liste, et comme ça en appuyant sur L, tu as la paix.
Arnaud.
* Nicolas Chauvat Nicolas.Chauvat@logilab.fr (20011004 12:15):
Google, tu devrais pouvoir trouver. A moins que quelqu'un sur la liste ne puisse donner une référence ?
http://www.unicom.com/pw/reply-to-harmful.html
olive
Au fait, qui s'est déclaré volontaire pour jouer le rôle de "secrétaire de séance" ?
Martin Quinson wrote:
Ben alors ? On est plus d'accord, là. Moi, je pense qu'il faut convertir le XML en po, traduire le po, puis réinjecter le texte dans le XML. Dans ce cas, on peut oublier ces histoires de xmldiff, c'est déja fait par gettext lors de la création des po...
Je suis d'accord avec Mt. Le _vrai_ format de fichier de traduction est le format .po. XML ne doit être au mieux qu'un format intermédiaire.
Il y a dans le paquet kdesdk-2.2.1 une suite d'outil permettant de transformer du xml en po et vice versa. Ces outils servent au projet KDE à maintenir leur documentation DocBook XML. Ces outils sont empaqueté par Debian http://packages.debian.org/unstable/devel/poxml.html
Quelqu'un peut t'il donner plus d'informations sur le fonctionnement et la pertinence de ces outils pour aider à la traduction de documentation DocBook XML ?
On Thu, Oct 04, 2001 at 01:34:07PM +0200, Christophe Merlet wrote: [...]
Il y a dans le paquet kdesdk-2.2.1 une suite d'outil permettant de transformer du xml en po et vice versa.
[...]
Quelqu'un peut t'il donner plus d'informations sur le fonctionnement et la pertinence de ces outils pour aider à la traduction de documentation DocBook XML ?
Je fais part de ma faible expérience résultant seulement d'une évaluation de ces outils, les utilisateurs avertis me corrigeront si je dis des bêtises. Pour travailler sur la traduction de ktoto, c'est très simple : 1. Génération du POT xml2pot ktoto.xml > ktoto.pot 2. Si on a une version déjà traduite ktoto-fr.xml, on peut faire split2po ktoto.xml ktoto-fr.xml > ktoto-fr.po Il faut évidemment que la version française soit à jour. On peut aussi s'appuyer sur une traduction non à jour, mais il faut alors avoir la version anglaise correspondante. L'autre alternative est de partir de zéro en copiant le POT. 3. Travail sur les traductions. On a un fichier PO, on utilise son outil préféré pour travailler dessus. 4. Génération du fichier XML traduit po2xml ktoto.xml ktoto-fr.po > ktoto-fr.xml 5. Mises à jour Quand une nouvelle version anglaise arrive, on utilise msgmerge de façon usuelle : mv ktoto-fr.po ktoto-fr.old.po xml2pot ktoto.xml > ktoto.pot msgmerge ktoto-fr.old.po ktoto.pot > ktoto-fr.po
Voilà, c'est relativement simple, et a l'air de bien marcher. Le fonctionnement réside sur l'équivalence (ce n'est certainement pas le bon terme, mais je ne trouve pas) des arbres des deux documents, le fichier PO ne contient aucune autre information que la traduction des chaînes. Cela implique qu'on ne peut pas modifier l'ordre des paragraphes, ni en ajouter ou en supprimer. Il doit être assez facile d'ajouter un 3e argument à po2xml qui serait un fichier XSLT permettant de faire ces manipulations. L'autre critique que l'on peut opposer est qu'il ne peut y avoir qu'une seule traduction par chaîne, ce qui peut être gênant. Une solution est d'insérer un identifiant unique devant chaque msgid et msgstr, qui serait ajouté/supprimé par xmlpot, split2po et po2xml.
Je n'ai pas été voir dans les sources, ni sur les ML ce qui se dit, il se peut donc que ces points y soient évoqués.
Denis
Je suis assez d'accord, mais j'ai un bemol : on a des pages chez Debian, qui ont le look 'page Debian' classique, et on a pas le gout d'en faire 15 sortes... Je suppose que c'est pareil pour tous les projets. En regroupant tout ce qui parle de trad, on disperse ce qui parle de Debian. C'est inévitable.
Il ne s'agit pas forcément d'en faire quinze différentes, mais au moins de ne pas contraindre le traducteur potentiel à parcourir quinze sites de qunize projets différentes avant de trouver ce qui reste à faire et qui aider.
- difficile de savoir rapidement quels outils et formats employer,
Pour 3. Se mettre d'accord sur les formats et développer des outils pour les manipuler. Mon avis personnel est formé : DocBook/XML 4.1.2 comme format de base, convertible au besoin en po/html/pdf/ps etc. (oui, oui, .po inclus pour gérer les versions avec les mêmes outils :-)
Je suis *vraiment* d'accord avec ce souhait d'universalité du format po. Je pense que les traducteurs ont maintenant des outils sympas pour traduire les po, tels que kbabel, gtranslator, ou le mode po d'emacs, et il faut leur permettre de les utiliser.
Malheureux, tu as compris l'inverse de ce que j'essayais de dire !
Je n'ai rien contre le format po pour les *messages*des*programmes*, au contraire, mais vouloir l'utiliser pour autre chose frise l'hérésie. En particulier, je pense qu'il s'applique très très mal à de la documentation.
Quand je parlais de XML comme format de base, c'était pour tout conserver sous forme de XML, documentation *et* messages de programmes, et de le retransformer en po au bon moment et au besoin. Mais je vais passer là-dessus pour l'instant, car je connais plusieurs fervents admirateurs du format po dans la salle et ne souhaite pas lancer une guerre de religion sur ce sujet.
Ben alors ? On est plus d'accord, là. Moi, je pense qu'il faut convertir le XML en po, traduire le po, puis réinjecter le texte dans le XML. Dans ce cas, on peut oublier ces histoires de xmldiff, c'est déja fait par gettext lors de la création des po...
A mon avis, utiliser po pour des textes de documentation n'est pas une bonne idée. Ca marche, cela ne fait pas de doute. Mais ça n'aide pas à avoir un texte final cohérent. L'unité de base dans un programme est un message de quelques mots, au pire quelques lignes. Dans une documentation, c'est plutôt quelques phrases, voir quelques paragraphes. Et là, po traite beaucoup moins bien le problème AMHA.
Oui. gettext rules. Voila pour la famille d'outils. Ensuite, pour l'extraction/la remise en place des chaines à traduire, les gens de KDE ont ca, meme s'il me semble qu'on devrait pouvoir améliorer un peu.
Oui, lors de la dernière bouffe, cette solution avait été exposée en détail. Je ne doute pas qu'elle s'applique très bien pour les messages, mais je continue à penser que ce n'est pas la meilleure pour les documentations (cf ci-dessus).
Chez Debian, le role de relecteur et de coordinateur est séparé. On poste sur la liste tout ce qu'on voudrait voir relire, et on a des gens qui font ca tres bien. Mieux que ce que nous, coordinateurs avec Denis nous ne pourrions faire. Chacun son job.
Pour les documents du LDP c'est pareil.
De plus, toujours chez Debian, on pense qu'il vaut mieux moins de traduction de meilleur qualité. On veut pas faire du chiffre. Donc, on passe beaucoup de temps à relire. Donc, un traducteur qui fait une mauvaise traduction va se manger pleins de mails de correction et il va passer un sale quart d'heure pour integrer toutes ces corrections. La fois suivante, il utilisera ispell avant d'envoyer son document, il fera attention à ce que le format de son document soit juste d'un point de vue technique et tout et tout. Mais on a de la chance d'avoir de bons relecteurs, aussi.
D'accord "Debian rules". Il n'empêche que pour le LDP c'est pareil et que ça ne marche pas si bien que ça... parce qu'il y a somme toute peu de gens, que tous sont occupés par ailleurs, et qu'il est difficile, sans vouloir faire du chiffre, de garder un rythme aussi soutenu pour la traduction que celui de la publication des documents (il y a *beaucoup* de gens qui travaillent en amont sur les documents du LDP).
A mon avis, il est donc important d'arriver à mettre en place un système qui facilite au maximum le boulot des traducteurs. Je sais que tu vas me répondre "kbabel" est ton ami", donc j'arrête :-)
Dans mes reves les plus fous, on aurait des moulinettes pour extraire dans des fichiers po tous les formats existants, afin que les traducteurs et relecteurs puissent faire leur boulot sans se soucier de savoir si c'est un livre, les messages d'un programme, la page man, des fichiers debconf, la description d'un paquet ou dieu sait quoi.
Je ne pense pas qu'on puisse faire une traduction de qualité en traduisant des phrases isolées sans savoir si c'est un livre, un programme ou autre chose...
Mais je suis d'accord pour dire qu'il faudrait que toutes ses traductions se fasse avec un petit nombre d'outils communs (pas forcément un outil ou un format unique non plus, s'il y en a trois au plus, ça me paraît encore raisonnable).
Ensuite, on utiliserait tous des robots comme celui du projet de traduction ... ainsi de suite. La vie serait belle, et les coordinateurs pourraient aller dormir (ce que je fais maintenant ;).
J'y travaille.
<<rires dans la salle>>
Non, sans rigoler, arrêter de me charrier quoi, j'y travaille vraiment !
Le Jeudi 4 Octobre 2001 11:31, vous avez écrit :
Je n'ai rien contre le format po pour les *messages*des*programmes*, au contraire, mais vouloir l'utiliser pour autre chose frise l'hérésie. En particulier, je pense qu'il s'applique très très mal à de la documentation.
Quand je parlais de XML comme format de base, c'était pour tout conserver sous forme de XML, documentation *et* messages de programmes, et de le retransformer en po au bon moment et au besoin. Mais je vais passer là-dessus pour l'instant, car je connais plusieurs fervents admirateurs du format po dans la salle et ne souhaite pas lancer une guerre de religion sur ce sujet.
Ben alors ? On est plus d'accord, là. Moi, je pense qu'il faut convertir le XML en po, traduire le po, puis réinjecter le texte dans le XML. Dans ce cas, on peut oublier ces histoires de xmldiff, c'est déja fait par gettext lors de la création des po...
A mon avis, utiliser po pour des textes de documentation n'est pas une bonne idée. Ca marche, cela ne fait pas de doute. Mais ça n'aide pas à avoir un texte final cohérent. L'unité de base dans un programme est un message de quelques mots, au pire quelques lignes. Dans une documentation, c'est plutôt quelques phrases, voir quelques paragraphes. Et là, po traite beaucoup moins bien le problème AMHA.
C'est là que tu te trompes. Chaque paragraphe devient un message. C'est très facile à traduire et ça facilite les mises à jour. Dans KDE, on a l'expérience de 28 000 messages traduits.
Oui. gettext rules. Voila pour la famille d'outils. Ensuite, pour l'extraction/la remise en place des chaines à traduire, les gens de KDE ont ca, meme s'il me semble qu'on devrait pouvoir améliorer un peu.
Oui, lors de la dernière bouffe, cette solution avait été exposée en détail. Je ne doute pas qu'elle s'applique très bien pour les messages, mais je continue à penser que ce n'est pas la meilleure pour les documentations (cf ci-dessus).
cf ci-dessus
A mon avis, il est donc important d'arriver à mettre en place un système qui facilite au maximum le boulot des traducteurs. Je sais que tu vas me répondre "kbabel" est ton ami", donc j'arrête :-)
J'ai rien dit. T'as qu'à utiliser GBabel.
On Thu, Oct 04, 2001 at 11:31:14AM +0200, Nicolas Chauvat wrote:
Je suis assez d'accord, mais j'ai un bemol : on a des pages chez Debian, qui ont le look 'page Debian' classique, et on a pas le gout d'en faire 15 sortes... Je suppose que c'est pareil pour tous les projets. En regroupant tout ce qui parle de trad, on disperse ce qui parle de Debian. C'est inévitable.
Il ne s'agit pas forcément d'en faire quinze différentes, mais au moins de ne pas contraindre le traducteur potentiel à parcourir quinze sites de qunize projets différentes avant de trouver ce qui reste à faire et qui aider.
Bon, bon, c'est vrai que le raport investissement par nous/ gain pour les volontaires est favorable.
Yapluka.
Je n'ai rien contre le format po pour les *messages*des*programmes*, au contraire, mais vouloir l'utiliser pour autre chose frise l'hérésie. En particulier, je pense qu'il s'applique très très mal à de la documentation.
C'est vrai que c'est une hérésie. Je suis d'accord avec ca. Mais si ca marche (et l'experience KDE semble le montrer), et qu'on a aucune autre solution viable, alors pourquoi pas ?
Quand je parlais de XML comme format de base, c'était pour tout conserver sous forme de XML, documentation *et* messages de programmes, et de le retransformer en po au bon moment et au besoin. Mais je vais passer là-dessus pour l'instant, car je connais plusieurs fervents admirateurs du format po dans la salle et ne souhaite pas lancer une guerre de religion sur ce sujet.
Est ce que le projet de Karl de faire un dtd xml pour les fichiers po (ie, utiliser la grammaire xml pour le format des fichiers po) est hors sujet ici ? Perso, il me semble que les gains ne valent pas la peine qu'on se casse à le faire, mais si c'est fait tant mieux. Je ne suis pas tant admirateur de comment le format a été concu[¹], mais je constate que c'est un standard de fait dans le monde de la traduction...
¹: Par exemple, j'aimerais que msgmerge mette dans le fichier résultant le diff entre l'ancienne chaine originale et la nouvelle. Mais comme le format est un peu ... préhistorique, c'est pas possible sans casser les outils qui l'utilisent.
A mon avis, utiliser po pour des textes de documentation n'est pas une bonne idée. Ca marche, cela ne fait pas de doute. Mais ça n'aide pas à avoir un texte final cohérent. L'unité de base dans un programme est un message de quelques mots, au pire quelques lignes. Dans une documentation, c'est plutôt quelques phrases, voir quelques paragraphes. Et là, po traite beaucoup moins bien le problème AMHA.
Les messages (ie dans ce cas, les paragraphes) vont se retrouver dans le meme ordre que dans le texte. Alors pour gerer la coherence, c'est pas *si* différent. Le bonheur serait d'avoir comme fonctionnalité des frontaux de traduction (comme le mode d'emacs) de prévisualiser le document résultant. Ca semble faisable quand la chaine d'outil se sera un peu standardisée.
D'accord "Debian rules". Il n'empêche que pour le LDP c'est pareil et que ça ne marche pas si bien que ça... parce qu'il y a somme toute peu de gens, que tous sont occupés par ailleurs, et qu'il est difficile, sans vouloir faire du chiffre, de garder un rythme aussi soutenu pour la traduction que celui de la publication des documents (il y a *beaucoup* de gens qui travaillent en amont sur les documents du LDP).
Y'a pas de Debian rules dans mon propos, mais je présente en publique notre politique. Pas de jugement de valeur. Je connais un peu les autres projets, et y'a pleins de gens qui font mieux que nous, mais on fait de notre mieux.
A mon avis, il est donc important d'arriver à mettre en place un système qui facilite au maximum le boulot des traducteurs. Je sais que tu vas me répondre "kbabel" est ton ami", donc j'arrête :-)
kbabel, et toutes les interfaces du monde ne sont pas suffisante si y'a pas l'infrastructure derriere. Je parle ici du robot de mes reves (et des tiens?).
Je ne pense pas qu'on puisse faire une traduction de qualité en traduisant des phrases isolées sans savoir si c'est un livre, un programme ou autre chose...
Non, mais on peut traduire tous les formats avec le meme frontal s'ils arrivent au meme format dédié à la traduction. Et ensuite, en navigant entre les messages, tu vois le texte d'origine. D'ailleurs, perso, je n'utilise que le mode d'emacs car j'aime pas le fait qu'on ne puisse pas voir les messages précédents et suivants dans les frontaux graphiques que j'ai testé.
Mais je suis d'accord pour dire qu'il faudrait que toutes ses traductions se fasse avec un petit nombre d'outils communs (pas forcément un outil ou un format unique non plus, s'il y en a trois au plus, ça me paraît encore raisonnable).
C'est vrai. Mais alors, quels seraient les autres formats ? Peux tu nous donner un exemple de ce à quoi resemblerait grosso merdo le fichier XML que tu penses mieux adapté que po ? Y'a pas de sarcasme ici, ou quelque chose du genre. Juste de la vraie curiosité. J'ai pas ma carte dans la secte des croisés des fichiers Portable Object, mais jusque la, je n'ai pas vu de concurents sérieux...
Ensuite, on utiliserait tous des robots comme celui du projet de traduction ... ainsi de suite. La vie serait belle, et les coordinateurs pourraient aller dormir (ce que je fais maintenant ;).
J'y travaille.
<<rires dans la salle>>
Non, sans rigoler, arrêter de me charrier quoi, j'y travaille vraiment !
Je ne ris pas, je suis curieux. T'as regardé ce que fesais le robot du TP, pour en tirer la substentifique moelle ?
Bye, Mt.
C'est vrai que c'est une hérésie. Je suis d'accord avec ca. Mais si ca marche (et l'experience KDE semble le montrer), et qu'on a aucune autre solution viable, alors pourquoi pas ?
Les gens de KDE en général et Gérard en particulier semblent en effet satisfaits de cette utilisation. On peut juger qu'il n'y a pas aujourd'hui de meilleure solution. En ce qui me concerne je pense qu'on peut faire mieux... donc j'en parle :-)
Est ce que le projet de Karl de faire un dtd xml pour les fichiers po (ie, utiliser la grammaire xml pour le format des fichiers po) est hors sujet ici ?
Non, je suis d'accord avec Karl sur ce sujet justement: il serait avantageux de conserver le contenu des po dans du XML et de n'utiliser les outils pour po qu'au dernier moment :-)
Perso, il me semble que les gains ne valent pas la peine qu'on se casse à le faire, mais si c'est fait tant mieux. Je ne suis pas tant admirateur de comment le format a été concu[¹], mais je constate que c'est un standard de fait dans le monde de la traduction...
Je comprends, mais je trouve que faire quelques efforts pour manipuler du XML profite à tellement de projets et de domaines en même temps que ces efforts valent la peine d'être fait. D'un autre côté, tu peux sans conteste me répondre "alors fais-les et on verra si tu obtiens un meilleur résultat". N'ayant pas assez de temps, je ne peux pas fournir de programme qui prouve ce que j'avance...
Les messages (ie dans ce cas, les paragraphes) vont se retrouver dans le meme ordre que dans le texte. Alors pour gerer la coherence, c'est pas *si* différent. Le bonheur serait d'avoir comme fonctionnalité des frontaux de traduction (comme le mode d'emacs) de prévisualiser le document résultant. Ca semble faisable quand la chaine d'outil se sera un peu standardisée.
Autour d'un format Docbook/XML ? :-)
Y'a pas de Debian rules dans mon propos, mais je présente en publique notre politique. Pas de jugement de valeur. Je connais un peu les autres projets, et y'a pleins de gens qui font mieux que nous, mais on fait de notre mieux.
Comparé à d'autres projets, Debian a l'avantage d'être globalement plus cohérents et de réunir des personnes en général très motivées.
kbabel, et toutes les interfaces du monde ne sont pas suffisante si y'a pas l'infrastructure derriere. Je parle ici du robot de mes reves (et des tiens?).
Le robot de mes rêves fait bien plus que coordonner des traductions :-)
Non, mais on peut traduire tous les formats avec le meme frontal s'ils arrivent au meme format dédié à la traduction. Et ensuite, en navigant entre les messages, tu vois le texte d'origine. D'ailleurs, perso, je n'utilise que le mode d'emacs car j'aime pas le fait qu'on ne puisse pas voir les messages précédents et suivants dans les frontaux graphiques que j'ai testé.
Je trouve moi aussi que traduire en dehors du contexte est périlleux.
C'est vrai. Mais alors, quels seraient les autres formats ? Peux tu nous donner un exemple de ce à quoi resemblerait grosso merdo le fichier XML que tu penses mieux adapté que po ? Y'a pas de sarcasme ici, ou quelque chose du genre. Juste de la vraie curiosité. J'ai pas ma carte dans la secte des croisés des fichiers Portable Object, mais jusque la, je n'ai pas vu de concurents sérieux...
Le format défini par Karl. Attends, je vais te retrouver ça dans les archives... [qqs instants plus tard]
http://www.iro.umontreal.ca/contrib/po/rmail/leaders http://www.traduc.org/pipermail/traduc/2001-July/000309.html
Je ne ris pas, je suis curieux. T'as regardé ce que fesais le robot du TP, pour en tirer la substentifique moelle ?
Ma première version de robot tournait avant que je n'ai connaissance du TP-Robot. J'ai regardé ce que faisais le TP-Robot, et je pense qu'il faudrait avoir les mêmes fonctionnalités. J'en ai même d'autres à rajouter, mais pour le moment j'essaie de me concentrer sur les fonctions de base...
On Thu, Oct 04, 2001 at 03:26:43PM +0200, Nicolas Chauvat wrote:
C'est vrai que c'est une hérésie. Je suis d'accord avec ca. Mais si ca marche (et l'experience KDE semble le montrer), et qu'on a aucune autre solution viable, alors pourquoi pas ?
Les gens de KDE en général et Gérard en particulier semblent en effet satisfaits de cette utilisation. On peut juger qu'il n'y a pas aujourd'hui de meilleure solution. En ce qui me concerne je pense qu'on peut faire mieux... donc j'en parle :-)
Et c'est bien parce que ca m'interresse que je t'y incite.
Perso, il me semble que les gains ne valent pas la peine qu'on se casse à le faire, mais si c'est fait tant mieux. Je ne suis pas tant admirateur de comment le format a été concu[¹], mais je constate que c'est un standard de fait dans le monde de la traduction...
Je comprends, mais je trouve que faire quelques efforts pour manipuler du XML profite à tellement de projets et de domaines en même temps que ces efforts valent la peine d'être fait. D'un autre côté, tu peux sans conteste me répondre "alors fais-les et on verra si tu obtiens un meilleur résultat". N'ayant pas assez de temps, je ne peux pas fournir de programme qui prouve ce que j'avance...
Je suis pas comme ca... J'aime les phrases courtes à taper: Patch welcome. ;) Non, serieux, je suis pres à me laisser convaincre, meme sans programme...
kbabel, et toutes les interfaces du monde ne sont pas suffisante si y'a pas l'infrastructure derriere. Je parle ici du robot de mes reves (et des tiens?).
Le robot de mes rêves fait bien plus que coordonner des traductions :-)
Ah ? et quoi ?
Je ne ris pas, je suis curieux. T'as regardé ce que fesais le robot du TP, pour en tirer la substentifique moelle ?
Ma première version de robot tournait avant que je n'ai connaissance du TP-Robot. J'ai regardé ce que faisais le TP-Robot, et je pense qu'il faudrait avoir les mêmes fonctionnalités. J'en ai même d'autres à rajouter, mais pour le moment j'essaie de me concentrer sur les fonctions de base...
Et pourquoi ne pas ajouter ces fonctionnalites au TP-Robot, directement ? Ca te permetterais de te concentrer sur les ajouts, et laisser les fonctions de base de coté, non ? Tu veux le coder en quoi ? TP-Robot est en python.
Le robot de mes rêves fait bien plus que coordonner des traductions :-)
Ah ? et quoi ?
Il répond aux questions et aux FAQ sur IRC, les news et les listes de discussions. Il répond au téléphone à ma place et prend les messages. Il me joue de la musique quand je rentre chez moi et il m'appelle sur mon portable pour m'annoncer qu'il vient de me déplacer un rendez-vous, car lui et le robot de l'autre personne qui ne pouvait pas venir en ont convenu ainsi.
Tout cela n'est pas utopique, puisqu'il y en a déjà une partie qui fonctionne déjà chez nous (Logilab). Malheureusement, ce n'est pas encore assez stable à mon goût... et quand il y a un problème, ce n'est pas immédiat à débugger :-(
Et pourquoi ne pas ajouter ces fonctionnalites au TP-Robot, directement ? Ca te permetterais de te concentrer sur les ajouts, et laisser les fonctions de base de coté, non ? Tu veux le coder en quoi ? TP-Robot est en python.
Le mien aussi est en python, mais il est fait pour être beaucoup plus générique que le TP-Robot : http://www.logilab.org/narval/
Pour ce qui est des fonctionnalités du TP-Robot, j'ai déjà l'équivalent, mais il persiste à planter un jour sur deux, et je n'ai pas assez de temps à y consacrer ces jours-ci (refrain).
Enfin bon, sans aller jusqu'à un robot bon à tout faire, il y a déjà pas mal de choses améliorables pour la coordination des traductions, non ?
On Wed, Oct 03, 2001 at 04:46:04PM +0200, Olivier Berger wrote:
Salut.
J'aimerais suggérer un petit état des lieux sur le présent et l'avenir en ce qui concerne le présent groupe de traduction mais aussi ceux avec lesquels il collabore.
Si j'ai bien compris, nous avons :
- Martin Quinson, déjà actif dans le projet de Traduction de Debian
prend en main la gestion des trads des programmes (docs ?) du projet GNU dans le cadre du "Translation Project" (lire Translation Project des éléments du projet GNU)
- Nicolas Chauvat, gestionnaire du projet de traduction en français du
Linux Documentation Project (LDP == HOWTOs, mans et autres)
- Christophe Merlet (récemment arrivé ici), gestionnaire du projet
(moins formel que les précédents pour l'instant) de traduction de Gnome en français (rattaché au Gnome Translation Project), btw qui vient de rejoindre cette liste
D'autres, que je ne citerai pas pour l'instant.
[...]
Le projet KDE fait partie de ceux que tu citeras plus tard, où il pue vraiment trop de la gueule ?
Denis
On Wed, Oct 03, 2001 at 05:43:21PM +0200, Denis Barbier wrote:
On Wed, Oct 03, 2001 at 04:46:04PM +0200, Olivier Berger wrote:
Salut.
J'aimerais suggérer un petit état des lieux sur le présent et l'avenir en ce qui concerne le présent groupe de traduction mais aussi ceux avec lesquels il collabore.
Si j'ai bien compris, nous avons :
- Martin Quinson, déjà actif dans le projet de Traduction de Debian
prend en main la gestion des trads des programmes (docs ?) du projet GNU dans le cadre du "Translation Project" (lire Translation Project des éléments du projet GNU)
- Nicolas Chauvat, gestionnaire du projet de traduction en français du
Linux Documentation Project (LDP == HOWTOs, mans et autres)
- Christophe Merlet (récemment arrivé ici), gestionnaire du projet
(moins formel que les précédents pour l'instant) de traduction de Gnome en français (rattaché au Gnome Translation Project), btw qui vient de rejoindre cette liste
D'autres, que je ne citerai pas pour l'instant.
[...]
Le projet KDE fait partie de ceux que tu citeras plus tard, où il pue vraiment trop de la gueule ?
Je vous présente Denis, avec qui je coordonne les traductions dans Debian. En fait, il est sympa :)
C'est vrai que c'est vraiment dommage d'oublier KDE de cette liste, car ce sont ceux qui ont le plus d'avance dans pas mal de domaines à mes yeux. Mais c'est peut être qu'on ne sait pas quels membres de KDE sont présents sur la liste. Allo ? Alloooo ? S'ils sont pas la, j'irais les chercher sur leur liste à eux, ou je suis aussi abonné...
Bye, Mt.
Bonjour,
Comme c'est mon premier message dans cette liste, je me présente.
Je suis depuis plus d'un an le coordinateur du projet de traduction Francophone GNOME. Cette coordination est tout ce qu'il y a de plus informelle puisque je n'ai jamais pris la peine d'en informer les autres projets de traduction et que je ne me suis guère inquiété lorsque le site gnomefr.traduc.org et sa liste de diffusion furent indisponible.
Les dernières statistiques sur l'état des traductions des applications GNOME comptabilisent 208 paquets; 64409 chaînes au total dont 47481 traduites. Cela correspond à 77,94% de traduction effectué et place la France au quatrième rang mondial. Ce qui plutôt pas mal :-) La traduction des documentations est pour sa part en standby.
Olivier Berger m'a contacté ya quelques jours et c'est proposer pour remettre en ligne le site gnomefr.traduc.org et m'a informé que des projets de refonte de traduc.org sont à l'étude.
Cela fait un moment que j'ai envie (mais pas le temps) de mettre en ligne un vrai site pour le projet de traduction Francophone GNOME. La refonte de traduc.org donne l'occasion de mutualiser les efforts.
Je vais faire abstraction des commentaires précédents et vous exposer comment je vois cette refonte. Selon moi les traductions d'applications et les traductions de documentations sont des tâches complètement différentes. Elles sont différentes dans les outils à mettre en oeuvre, le niveau de compétence linguistique exigé et dans les processus de validation. N'étant pas compétent dans les traductions de documentation je ne développerai que les traductions d'applications.
traduc.org pourrait mutualiser les besoins des différents projets de traductions en mettant en place une base de données qui contiendrait les statistiques et état de traductions des fichiers .po. Les infos nécessaires sont nom du paquet, nombre de chaînes totales, traduites, approximées et non traduites. Le mainteneur de la traduction, le dernier traducteur, le relecteur. L'état de la traduction (terminé, en cours, en relecture, à l'abandon, obsolète). Le lien vers le fichier po à jour pour téléchargement. En plus de la base de données de statistiques, il faudrait mettre à disposition une base de données de termes traduits, de rêgles typographiques, d'outils d'aide à l'édition de fichier de traduction. Des scripts d'extraction/insertion de chaînes. Tous ces outils de backend étant mis à disposition, chaque projet de traduction aurait la possibilité de construire un site web ayant son look propre mais interrogant la base commune de traduction. Traduc.org aurait un site permettant de naviguer globalement dans toute la base.
Une difficulté que je rencontre est de recruter des traducteurs (peut-être que si je faisait de la pub, yen aurait plus) et de dialoguer avec les traducteurs du projet. Pour recruter des traducteurs le mieux me semble d'avoir un site web attractif et vivant. Je pense a un site de news utilisant daCode, le moteur de news de linuxfr (je suis en train de bosser dessus pour les traductions GNOME). Un serveur de liste de diffusions est indispensable et un serveur IRC serait pas mal (j'utilise beaucoup plus l'IRC que les ML).
Ces outils étant en place, je pense qu'il serait lus simple pour les traducteurs de ce coordonner et de travailler plus efficacement. Passer d'un projet à l'autre serait aussi facilité, je ne voit pas pourquoi on devrait se limiter à ne traduire que des applications GNOME, GNU, KDE ou autres. Par ailleurs les applications n'appartenant a aucun projet (la majorité ?) trouverait facilement leur place sur traduc.org.
L'alimentation de la base de données de statistiques étant une tâche dévoreuse de CPU, d'espace disque et de bande passante, la collecte des statistiques pourrait être décentralisé sur des stations de volontaires qui se contenterait d'envoyer à la base de données les résultats des traitement. Je peux m'occuper de traiter tout le CVS GNOME.
Voilà de quoi commenter ;-)
Librement,
-- Christophe Merlet (RedFox)
On Wed, Oct 03, 2001 at 08:58:54PM +0200, Christophe Merlet wrote: [...]
traduc.org pourrait mutualiser les besoins des différents projets de traductions en mettant en place une base de données qui contiendrait les statistiques et état de traductions des fichiers .po. Les infos nécessaires sont nom du paquet, nombre de chaînes totales, traduites, approximées et non traduites. Le mainteneur de la traduction, le dernier traducteur, le relecteur. L'état de la traduction (terminé, en cours, en relecture, à l'abandon, obsolète). Le lien vers le fichier po à jour pour téléchargement.
[...]
Salut,
j'ai un peu réfléchi à ce problème, en travaillant avec Martin sur le pendant de ce que tu décris pour Debian. Quand on travaille au sein d'un projet comme GNU ou Gnome, on peut imposer un certain format d'empaquetage, on saura par exemple que les fichiers po sont dans le sous-répertoire po/, avec des noms bien définis. Pour Debian, notre problématique est différente, on a des paquets venant d'horizons très différents. En revanche, on impose l'arborescence lors de l'installation. Il est alors tentant de récupérer les informations que tu énonces (nombre de chaînes totales, traduites, approximées et non traduites) dans les fichiers installés, à savoir les MO. J'ai demandé à Bruno Haible de rajouter ces informations dans le format MO (ce qui peut être fait en restant compatible avec l'ancien format), mais il n'est vraiment pas chaud. Comme je ne suis pas non plus très sûr que ce soit une bonne idée, je n'ai pas insisté, mais j'aimerai avoir vos avis éclairés sur ce problème.
C'est un peu hors-sujet, on peut en discuter ailleurs si ça l'est vraiment trop. Pour le reste de ton message, ce que tu décris est intéressant, je crois que tout le monde est d'accord pour avoir un tel système, yapukafokon ;)
Denis
-
Arnaud S . Launay -
Christophe Merlet -
Christophe Merlet -
Denis Barbier -
Gerard Delafond -
Martin Quinson -
Nicolas Chauvat -
Olivier Berger -
Olivier Tharan