Voici le "brouillon" du message à envoyer sur la liste lampadas. Comme précisé précédemment, puisqu'il est sensé représenter nos idées en tant que groupe, je le présente ici pour relecture et corrections éventuelles.
J'ai essayé autant que possible de condenser les consensus, mais il peut y avoir des aspects à revoir.
Notez également que l'anglais n'est certainement pas parfait. Donc s'il y a des choses qui vous choquent trop, n'hésitez pas à corriger aussi...
===
Hello all,
The intent of this mail is to summarise the results of the discussion that took place in the french mailing-list traduc@traduc.org recently, leading the contributors of the "LDP fr" to discuss needed features and development ideas for an interface similar to Lampadas.
Now that our two projects are merging, we think that it would be a good idea to give you the results of our thoughts. The intent is also to start a new discussion, together, and define what we want Lampadas to be exactly at the end.
I] The translation process
As traduc.org is today used for translation only purposes, our main contribution may be on this point.
A] Today
By now, the translation process consists of three steps, involving three types of users : the translator, the proof-reader(s) and the project coordinator. As the translator does the main job, he is designed responsible for his document and also quite naturally the document maintainer.
- the translator choose a document or a new version of a maintained document is avaible, - the translator translates or makes the appropriate changes, - when finished, he announces the document ready for proof-reading on the mailing-list, - one or more proof-readers contact the translator and help him correcting its translation (diffs), - when satisfied, the final version is submited to the project coordinator, who publish it if he estimates that enough precautions about its reliability have been taken. What "enough precautions" is depends of the nature of the document, and of te number of mistakes found by the proof-readers.
This system works well and for a quite long time now, but it has also proven its limits : the coordinator has too much work, and very few steps are really automated.
B] The future
We needed a translation process manager, so we started to discuss the changes this interface would introduce, as well as what would be automated and what would not.
Changes : - There would not be only one project coordinator this time, allowing the amount of work to be divised among two or three. This also avoids some lack of responsivness when the coordinator has no or not enough time to spare for the projet. - The process could be a little more standardized than before (for the proof-reading step, mainly), becoming more clear to the newcomers. The exact rules (numbers of proof-readings needed, exact process of the proof-reading step) have not being detailed yet. - A new kind of user could be introduced, similar to your markup assistants, providing help to the translators having difficulties to pass the XML/SGML/... validation automation.
What would be automated : - The registrations of documents, traductions and users. - The publication of the documents (web, FTP, archives...). - The translation process. Excluding the points in the "What would not be automated" section, the interface should automate all the steps; from the selection of a particular document to its publication approval by one of the coordinators. - The interface should include a depository of the changes in a document (translations, proof-readings, comments), like the one a CVS depository could provide, but probably in a more user-friendly way.
What would not be automated : - The discussions between the contributors to the project. The mailing-list would of course be preserved and a translator would still have to subscribe to it. The discussions between a translator and his proof-reader(s) could still be made privately by email; a summary of these discussions could be attached to the document, for later reference. - The approval of a publication by a project coordinator; this task is simplified, but one still has to say "ok" before the document is published.
Some alredy existing tools have been proposed for particular tasks : - Roundup ( http://roundup.sf.net ) : to track user and proof-readers error reports. - MoinMoin ( http://moin.sf.net ) : to reference common traduction problems, solutions and general help to the translator.
II] The document redaction process
As stated previously, it would be a good idea to allow contributions to the LDP in any langage, and not just the english -> foreign langages translation scheme that is actually in use.
But, as we do not have discussed this point further, and that you do have a good experience on this point, we let you speak first. :-)
And remember that it is just an overview of what we have discussed apart. We have to start a discussion on this...
Afficher les réponses par date
Le Wednesday 17 April 2002 17:43, tu écrivais :
Voici le "brouillon" du message à envoyer sur la liste lampadas. Comme précisé précédemment, puisqu'il est sensé représenter nos idées en tant que groupe, je le présente ici pour relecture et corrections éventuelles.
Puisqu'aucune autre objection ne s'est levée, je viens d'envoyer le mail sur la mailing-list lampadas. Avis à ceux qui veulent participer au débat !
Je vous soumet mes commentaires, qui ne servent évidemment à rien, le message étant déjà parti.
Le 2002-04-17 17:43:00 +0200, Xavier Antoviaque écrivait :
A] Today
Nous parlons ici uniquement des HOWTO, c'est bien cela ?
By now, the translation process consists of three steps, involving three types of users : the translator, the proof-reader(s) and the project coordinator. As the translator does the main job, he is designed responsible for his document and also quite naturally the document maintainer.
- the translator choose a document or a new version of a maintained document
is avaible,
- the translator translates or makes the appropriate changes,
- when finished, he announces the document ready for proof-reading on the
mailing-list,
- one or more proof-readers contact the translator and help him correcting
its translation (diffs),
- the proof-readers register the diff with the coordinator.
- when satisfied, the final version is submited to the project coordinator,
who publish it if he estimates that enough precautions about its reliability have been taken. What "enough precautions" is depends of the nature of the document, and of te number of mistakes found by the proof-readers.
Je ne crois pas que ceci reflète la situation présente. Le coordinateur n'étant pas en copie des échanges traducteur-relecteur, il ne connaît pas forcément le nombre de relectures effectuées.
Ma compréhension de la situation présente est qu'il reçoit, enregistre et publie le document auquel le traducteur et le relecteur ont abouti par leur travail commun.
This system works well and for a quite long time now, but it has also proven its limits : the coordinator has too much work, and very few steps are really automated.
S'il y a surcharge de travail pour le coordinateur, s'agit-il du résultat de ce processus, ou ne serait-ce pas plutôt le résultat de la grande variété et quantité de tâches qu'il doit assumer en *plus* de son implication dans ce processus ?
B] The future
We needed a translation process manager, so we started to discuss the changes this interface would introduce, as well as what would be automated and what would not.
Ah ? J'ai l'impression que nous sommes parti du mauvais côté de la question. Je pense que pour résoudre les problèmes auxquels nous sommes confrontés, il faudrait tout d'abord essayer de les identifier clairement, au lieu de partir de l'idée préconçue de la solution à adopter.
Quels sont ces problèmes ? Voici une liste des problèmes qui ont été évoqués au cours de cette discussion, soit comme problème à résoudre, soit au travers de solutions proposées (sans préjuger de l'importance ou de la réalité de ces problèmes) :
(1) Manque de relecteurs ? Combiens de documents sont-ils en souffrance de ce point de vue ? Depuis combien de temps ? (2) Manque de traducteurs ? (3) Insuffisance de publication des documents traduits ? Distribution insuffisante de ceux-ci ? (4) Surcharge de travail du coordinateur ? (5) Manque de qualité des documents traduits ? (6) Manque de fiabilité des relecteurs ? (7) Manque de fiabilité des traducteurs ?
Le problème 3 s'est certainement manifesté. Le 4 aussi. Le 1 peut-être. Je n'ai pas l'impression que 6 et 7 soient réels pour l'instant. Pour les autres je ne sais pas. Qu'en pensez-vous ?
Changes :
- There would not be only one project coordinator this time, allowing the
amount of work to be divised among two or three. This also avoids some lack of responsivness when the coordinator has no or not enough time to spare for the projet.
- The process could be a little more standardized than before (for the
proof-reading step, mainly), becoming more clear to the newcomers. The exact
Pourquoi uniquement standardiser la relecture ? C'est le problème le plus pressant ? Quel est le problème que nous cherchons à corriger ? Est-il réel ?
rules (numbers of proof-readings needed, exact process of the proof-reading step) have not being detailed yet.
Je pense qu'imposer de multiples relectures du même document, va diminuer fortement la quantité de documents pouvant être relus.
- A new kind of user could be introduced, similar to your markup assistants,
providing help to the translators having difficulties to pass the XML/SGML/... validation automation.
Ne serait-il pas plus intéressant d'utiliser la liste pour cela ?
What would be automated :
- The registrations of documents, traductions and users.
- The publication of the documents (web, FTP, archives...).
- The translation process. Excluding the points in the "What would not be
automated" section, the interface should automate all the steps; from the selection of a particular document to its publication approval by one of the coordinators.
L'automatisation du processus de traduction me donne l'impression que l'on va automatiser la traduction. Il faudrait peut-être formuler cette phrase autrement.
- The interface should include a depository of the changes in a document
^ a repository
Voilà.
On Thu, 18 Apr 2002, Jean-Philippe Guérard wrote:
Je vous soumet mes commentaires, qui ne servent évidemment à rien, le message étant déjà parti.
Xavier a peut-être envoyé le message trop vite pour que tous aient l'occasion de commenter, mais la discussion n'est pas close pour autant, il s'agit juste de la poursuivre en compagnie des autres personnes concernées.
Tout d'abord, je souaite m'excuser d'avoir publié le document un peu trop vite. Je pensais sincèrement que tout le monde l'avait lu...
Le document étant sensé refléter l'avis de tous ceux ayant participé à la conversation, tu es donc tout à fait en droit de contredire ce point te concernant sur la liste lampadas.
Le Thursday 18 April 2002 03:10, tu écrivais :
Nous parlons ici uniquement des HOWTO, c'est bien cela ?
D'aucun document en particulier. Il s'agit du fonctionnement général, sans rentrer dans les détails, qui rendraient l'exposé plus confus.
Je ne crois pas que ceci reflète la situation présente. Le coordinateur n'étant pas en copie des échanges traducteur-relecteur, il ne connaît pas forcément le nombre de relectures effectuées.
Disons alors que c'est ce qui est sensé se passer... De toutes façons, du point de vue du processus, ça ne change pas grand chose.
This system works well and for a quite long time now, but it has also proven its limits : the coordinator has too much work, and very few steps are really automated.
S'il y a surcharge de travail pour le coordinateur, s'agit-il du résultat de ce processus, ou ne serait-ce pas plutôt le résultat de la grande variété et quantité de tâches qu'il doit assumer en *plus* de son implication dans ce processus ?
Ca, c'est à Nicolas de le dire, mais je pense que l'automatisation du processus résorberait une part importante du travail. C'est le but depuis le début.
Et le fait de nommer plusieurs coordinateurs aide sur tous les plans.
(1) Manque de relecteurs ? Combiens de documents sont-ils en souffrance de ce point de vue ? Depuis combien de temps ? (2) Manque de traducteurs ? (3) Insuffisance de publication des documents traduits ? Distribution insuffisante de ceux-ci ? (4) Surcharge de travail du coordinateur ? (5) Manque de qualité des documents traduits ? (6) Manque de fiabilité des relecteurs ? (7) Manque de fiabilité des traducteurs ?
Le problème 3 s'est certainement manifesté. Le 4 aussi. Le 1 peut-être. Je n'ai pas l'impression que 6 et 7 soient réels pour l'instant. Pour les autres je ne sais pas. Qu'en pensez-vous ?
Pour cela, je reste tout de même persuadé que la première chose à faire est de se doter d'outils plus performants, qui vont alléger les tâches de tout le monde.
Notre interrogation a ici cherché à répondre à tous les points que tu soulèves : l'interface et l'intégraion au TLDP vont donner de meilleures possibilités de publication et de distribution, la simplification des tâches et la clarification des procédures permettront (du moins c'est un des buts) de toucher un plus grand nombre de volontaires.
Mais si tu as d'autres solutions à proposer, nous les accueillerons avec joie.
Pourquoi uniquement standardiser la relecture ? C'est le problème le plus pressant ?
Non, c'est juste le plus confus actuellement à mon sens. Mais ce n'est pas forcément le seul endroit où il y a des points à éclaircir.
Quel est le problème que nous cherchons à corriger ? Est-il réel ?
Oui, il est réel. Ce n'est pas pour rien je pense que le TLDP en ressent aussi le besoin, et a créé Lampadas.
Je pense qu'imposer de multiples relectures du même document, va diminuer fortement la quantité de documents pouvant être relus.
C'est aussi mon avis. Mais comme il n'y avait pas vraiment eu de consensus réel à ce niveau, j'ai préféré laisser la question en suspens.
- A new kind of user could be introduced, similar to your markup
assistants, providing help to the translators having difficulties to pass the XML/SGML/... validation automation.
Ne serait-il pas plus intéressant d'utiliser la liste pour cela ?
Je ne vois pas l'intérêt. Avec l'interface, on aurait tout immédiatement sous les yeux, de manière plus claire et plus pratique que sur une mailing-list. Ensuite, s'il y a un véritable problème, qui ne se résume pas à l'oubli d'une balise, il peut effectivement être intéressant d'en parler publiquement.
Pour finir, je te propose de continuer cette conversation sur Lampadas, pour ne pas avoir deux conversations différentes sur le même sujet.
Salut,
je viens de voir que l'on vient de répondre à ta proposition en anglais. je pense qu'il ne serait pas inutile de faire un résumé.
Peux-tu faire ce travail ? sinon, je peux essayer de m'en charger ?
a+
Le Thursday 18 April 2002 15:36, tu écrivais :
je viens de voir que l'on vient de répondre à ta proposition en anglais. je pense qu'il ne serait pas inutile de faire un résumé.
En gros, voici ce que David Merrill, l'auteur de Lampadas, a répondu :
Premièrement, il est tout à fait heureux de notre contribution et ouvert à notre prticipation au design de Lampadas. C'est important à signaler, tous les développeurs ne sont pas aussi prompts à accepter des avis extérieurs. :-)
Ensuite, il a indiqué, techniquement, comment il voyait l'introduction du processus de traduction tel qu'on le lui a décrit de notre fonctionnement envisagé. Cet ajout ne devrait visiblement ne demander que quelques modifications mineures à la base de données actuelle de Lampadas.
Pour le système de suivi de l'évolution d'un document, il a indiqué que la version finalle de Lampadas prévoyait un support intégré étendu du CVS.
Des notes seront attachables à un document, ce qui rejoint ici notre proposition.
C'est à peu près tout. J'en conclus qu'il trouve peu à redire aux autres points.
Peux-tu faire ce travail ? sinon, je peux essayer de m'en charger ?
J'avais prévu d'en reparler au fur et à mesure de la discussion, si personne ne s'en chargeait, pour que ceux qui n'y participent pas mais souhaitent néanmoins se tenir un minimum au courant puissent suivre depuis ici. Mais si tu souhaites effectuer ce travail, pas de problème : plus la tâche est répartie, mieux c'est. :-)
Une courte réponse :
S'il y a surcharge de travail pour le coordinateur, s'agit-il du résultat de ce processus, ou ne serait-ce pas plutôt le résultat de la grande variété et quantité de tâches qu'il doit assumer en *plus* de son implication dans ce processus ?
Les deux.
Ca, c'est à Nicolas de le dire, mais je pense que l'automatisation du processus résorberait une part importante du travail. C'est le but depuis le début. Et le fait de nommer plusieurs coordinateurs aide sur tous les plans.
Oui.
(1) Manque de relecteurs ? Combiens de documents sont-ils en souffrance de ce point de vue ? Depuis combien de temps ?
Il faudrait passer du temps à essayer de rameuter du monde, ou présenter suffisement bien et avoir une organisation suffisement claire pour retenir les badaus.
(2) Manque de traducteurs ?
idem.
(3) Insuffisance de publication des documents traduits ? Distribution insuffisante de ceux-ci ?
Oui et non : tous les documents sont disponibles sur le site ftp !
(4) Surcharge de travail du coordinateur ?
Compte tenu de ce que je suis prêt à y consacrer, certainement.
(5) Manque de qualité des documents traduits ? (6) Manque de fiabilité des relecteurs ? (7) Manque de fiabilité des traducteurs ?
ça pourrait être bien pire.
Le 2002-04-18 15:38:36 +0200, Nicolas Chauvat écrivait :
(3) Insuffisance de publication des documents traduits ? Distribution insuffisante de ceux-ci ?
Oui et non : tous les documents sont disponibles sur le site ftp !
Hum.
Voyons le site ftp :
+ Le dossier « a-jour » n'est pas accessible (car seul le propriétaire de ce dossier à les droits d'exécution - donc seul le propriétaire à accès à la liste des fichiers qu'il contient).
+ Le dossier « relus-a-publier » contient des documents remontant à juillet 2000.
+ Le dossier « traduits-a-relire » contient au moins 1 document dont la relecture est terminée depuis belle lurette (le « Online-Troubleshooting-HOWTO », dont la version traduite finale est disponible depuis le 8 juillet 2001).
Qui plus est, un internaute de passage ira sans doute plus volontiers consulter la liste des HOWTO en suivant le lien « Lire les HOWTO ».
Et là, il tombera sur un lien vers une page où les HOWTO récemment traduits ne sont *pas* publiés.
Sans compter l'état des traductions qui n'est plus disponible.
(1) Manque de relecteurs ? Combien de documents sont-ils en souffrance de ce point de vue ? Depuis combien de temps ?
Il faudrait passer du temps à essayer de rameuter du monde, ou présenter suffisement bien et avoir une organisation suffisement claire pour retenir les badaus.
Pour retenir les « badauds », il faudrait pouvoir leur présenter des documents à jour, autrement dit, il faudrait publier le travail que nous réalisons.
Et il en est de même pour les traducteurs et les relecteurs : pourquoi continuer à contribuer, puisque le travail réalisé ne sert à rien, les documents traduits ne sont jamais publiés, ni diffusé.
En tout cas, tel a été le cas des 2 documents dont j'ai assuré la relecture, le Mail-Administrator-HOWTO (disponible depuis le 12 février 2001) et le Online-Troubleshooting-HOWTO.
Donc, la première priorité me paraît la publication et la diffusion des documents traduits.
Il serait sans doute intéressant de séparer le rôle de coordinateur du rôle de développeur en chef, avec un coordinateur chargé de faire avancer le contenu du projet, c'est-à-dire les traductions, d'assurer leur diffusion, de recruter de nouvelles bonnes volontés, et cætera, et un développeur en chef chargé de faire évoluer les applications pour mieux répondre aux besoins du projet.
Les autres améliorations qui me paraîtraient intéressante :
+ Développer une page présentant les documents en attente de relecture, afin d'encourager les bonnes volontés. Le système actuel d'annonces sur la liste présente l'inconvénient de ne pas offrir un suivi efficace dans le temps des besoins. En effet, le traducteur doit démarcher la liste de manière répétée s'il ne trouve pas de relecteur. Ce qui a de quoi légitimement décourager les bonnes volontés.
+ Sur un principe un peu similaire, développer une page proposant des projets de traduction. Les idées de HOWTO à ajouter étant discutées sur la liste.
De mon point de vue, modifier les processus de traduction et de relecture sont loin d'être la première priorité. Il me semblerai nécessaire de commencer par améliorer ce qui ne marche pas, c'est-à-dire la publication et la diffusion, avant de s'attaquer au reste.
Qu'en pensez-vous ?
On Fri, Apr 19, 2002 at 01:50:38AM +0200, Jean-Philippe Guérard wrote: [...]
Les autres améliorations qui me paraîtraient intéressante :
- Développer une page présentant les documents en attente de relecture, afin d'encourager les bonnes volontés. Le système actuel d'annonces sur la liste présente l'inconvénient de ne pas offrir un suivi efficace dans le temps des besoins. En effet, le traducteur doit démarcher la liste de manière répétée s'il ne trouve pas de relecteur. Ce qui a de quoi légitimement décourager les bonnes volontés.
tout à fait d'accord
- Sur un principe un peu similaire, développer une page proposant des projets de traduction. Les idées de HOWTO à ajouter étant discutées sur la liste.
De mon point de vue, modifier les processus de traduction et de relecture sont loin d'être la première priorité. Il me semblerai nécessaire de commencer par améliorer ce qui ne marche pas, c'est-à-dire la publication et la diffusion, avant de s'attaquer au reste.
Qu'en pensez-vous ?
Yep d'accord à 100 % avec ça. Il faut publier, même si on a pas grand chose à dire. Au moins l'internaute qui arrive sur traduc.org. Parce que je dois bien avoué que ça n'incite pas vraiment à contribuer.
a+
Le Friday 19 April 2002 01:50, tu écrivais :
Voyons le site ftp :
Le dossier « a-jour » n'est pas accessible (car seul le propriétaire de ce dossier à les droits d'exécution - donc seul le propriétaire à accès à la liste des fichiers qu'il contient).
Le dossier « relus-a-publier » contient des documents remontant à juillet 2000.
[...]
Ca découle directement de ce que l'on disait sur les besoins d'une automatisation à ce niveau. Avec un outil automatisé, ce genre de chose est en permanence à jour. Sans, c'est à jour... quand le coordinateur a le temps de les mettre à jour.
Il serait sans doute intéressant de séparer le rôle de coordinateur du rôle de développeur en chef, avec un coordinateur chargé de faire avancer le contenu du projet, c'est-à-dire les traductions, d'assurer leur diffusion, de recruter de nouvelles bonnes volontés, et cætera, et un développeur en chef chargé de faire évoluer les applications pour mieux répondre aux besoins du projet.
Heu... Le point de la répartition des tâches a déjà été abordé : avoir plusieurs coordinateurs qui se les répartissent est déjà prévu.
- Développer une page présentant les documents en attente de relecture, afin d'encourager les bonnes volontés.
(re-)Heu... C'est déjà prévu aussi, ça.
- Sur un principe un peu similaire, développer une page proposant des projets de traduction. Les idées de HOWTO à ajouter étant discutées sur la liste.
Idem! Dans le cadre du TLDP, un document ainsi intégré sera disponible depuis tous les LDP, intégrable depuis n'importe quelle langue, et traduisible en n'importe quelle autre langue.
Voyons le site ftp :
Je vais peut-être vous surprendre, mais comme j'ai tous les documents sur ma machine, je n'utilise pas le site ftp. Et comme je le mets à jour par rsync, je ne me connecte même pas sur la machine. Donc soit on me signale qu'il y a des problèmes, soit je ne les voie pas... ce qui tend à prouver que l'organisation et les outis actuels ne sont pas si bien adaptés que ça... puisque j'ai du mal à détecter les erreurs.
- Le dossier « a-jour » n'est pas accessible (car seul le propriétaire de ce dossier à les droits d'exécution - donc seul le propriétaire à accès à la liste des fichiers qu'il contient).
corrigé.
- Le dossier « relus-a-publier » contient des documents remontant à juillet 2000.
J'ai demandé plusieurs fois de l'aide pour générer ces documents qui ne passaient pas sur ma machine... je n'en ai pas reçu beaucoup.
- Le dossier « traduits-a-relire » contient au moins 1 document dont la relecture est terminée depuis belle lurette (le « Online-Troubleshooting-HOWTO », dont la version traduite finale est disponible depuis le 8 juillet 2001).
Ah, mais ça pourrait tout simplement être une erreur... encore une fois, suffit de me le dire.
Qui plus est, un internaute de passage ira sans doute plus volontiers consulter la liste des HOWTO en suivant le lien « Lire les HOWTO ».
Et là, il tombera sur un lien vers une page où les HOWTO récemment traduits ne sont *pas* publiés.
Sans compter l'état des traductions qui n'est plus disponible.
Voir messages précédents.
Pour retenir les « badauds », il faudrait pouvoir leur présenter des documents à jour, autrement dit, il faudrait publier le travail que nous réalisons.
Et il en est de même pour les traducteurs et les relecteurs : pourquoi continuer à contribuer, puisque le travail réalisé ne sert à rien, les documents traduits ne sont jamais publiés, ni diffusé.
Sans rire ? Es-tu conscient que ce que tu viens d'écrire est quasiment une citation du message dans lequel j'expliquais que je voulais passer la main et en donnais les raisons ?
Ce qui me ge, c'est que je ne t'ai pas entendu te proposer pour me remplacer... et les deux personnes l'ayant fait étant de nouveaux arrivants, je prends sur mes nuits pour ne pas les laisser reprendre le flambeau les pieds dans la panade.
En tout cas, tel a été le cas des 2 documents dont j'ai assuré la relecture, le Mail-Administrator-HOWTO (disponible depuis le 12 février 2001) et le Online-Troubleshooting-HOWTO.
Donc, la première priorité me paraît la publication et la diffusion des documents traduits.
Puisque tu te proposes pour faire l'interim le temps que tout passe sur fr.tldp.org, je t'envoie dès ce soir les fichiers qui permettent de générer l'état de la traduction. Il te suffira de trouver le bug qui s'y cache (le fichier à télécharger pour comparer l'état du LDP avec notre état à changé) et de générer les feuilles HTML, puis de vérifier que les fichiers qui sont sur le site FTP reflètent bien l'état affiché. Ensuite, tu n'auras plus qu'à générer les versions manquantes des documents relus-a-publier.
Il serait sans doute intéressant de séparer le rôle de coordinateur du rôle de développeur en chef, avec un coordinateur chargé de faire avancer le contenu du projet, c'est-à-dire les traductions, d'assurer leur diffusion, de recruter de nouvelles bonnes volontés, et cætera, et un développeur en chef chargé de faire évoluer les applications pour mieux répondre aux besoins du projet.
Relis les messages précédents et tu verras que nous en avons déjà discuté et avons déjà abouti à la solution (car c'en est une) de notre problème (qui existe) : la charge des développements est répartie entre plusieurs personnes du LDP (et non de traduc seulement) et l'outil final permettra d'avoir plusieurs coordinateurs.
Les autres améliorations qui me paraîtraient intéressante :
- Développer une page présentant les documents en attente de relecture, afin d'encourager les bonnes volontés. Le système actuel d'annonces sur la liste présente l'inconvénient de ne pas offrir un suivi efficace dans le temps des besoins. En effet, le traducteur doit démarcher la liste de manière répétée s'il ne trouve pas de relecteur. Ce qui a de quoi légitimement décourager les bonnes volontés.
Cela fait longtemps (trois mois ?) que l'état ne marche plus, c'est vrai, mais cela fait aussi longtemps que cela a été fait (1 an au moins).
- Sur un principe un peu similaire, développer une page proposant des projets de traduction. Les idées de HOWTO à ajouter étant discutées sur la liste.
Tu es allé sur le site www.traduc.org récemment ?
http://www.traduc.org/projets.html
De mon point de vue, modifier les processus de traduction et de relecture sont loin d'être la première priorité. Il me semblerai nécessaire de commencer par améliorer ce qui ne marche pas, c'est-à-dire la publication et la diffusion, avant de s'attaquer au reste.
Qu'en pensez-vous ?
Je suis enthousiaste: "Tu commences quand ?"
Moi, je t'envoie ce soir ce dont tu as besoin pour assurer l'interim et publier un état des traductions digne de nos traducteurs et je serai disponible pour répondre à toutes tes questions.
Nicolas Chauvat wrote:
En tout cas, tel a été le cas des 2 documents dont j'ai assuré la relecture, le Mail-Administrator-HOWTO (disponible depuis le 12 février 2001) et le Online-Troubleshooting-HOWTO.
Donc, la première priorité me paraît la publication et la diffusion des documents traduits.
Puisque tu te proposes pour faire l'interim le temps que tout passe sur fr.tldp.org, je t'envoie dès ce soir les fichiers qui permettent de générer l'état de la traduction. Il te suffira de trouver le bug qui s'y cache (le fichier à télécharger pour comparer l'état du LDP avec notre état à changé) et de générer les feuilles HTML, puis de vérifier que les fichiers qui sont sur le site FTP reflètent bien l'état affiché. Ensuite, tu n'auras plus qu'à générer les versions manquantes des documents relus-a-publier.
Allez, je vais même te faciliter la vie : j'ai pris mon vendredi soir pour débusquer le bug et générer les fichiers qui pouvaient l'être simplement sur ma machine après mise à jour de tous les outils docbook. Il ne te reste qu'à générer les autres (les trois qui restent dans relus-a-publier/) et vérifier que l'état affiché correspond bien à ce qui se trouve sur le site FTP.
Je te remercie de ton aide et reste à ta disposition si tu as des questions auxquelles tu penses que je pourrais apporter une réponse.
Le 2002-04-19 14:04:09 +0200, Nicolas Chauvat écrivait :
Ce qui me ge, c'est que je ne t'ai pas entendu te proposer pour me remplacer... et les deux personnes l'ayant fait étant de nouveaux arrivants, je prends sur mes nuits pour ne pas les laisser reprendre le flambeau les pieds dans la panade.
Je l'aurais fait, mais la longue description des développements techniques à réaliser m'a fait reculer. Autant je serais prêt à assurer un rôle de coordinateur, autant je n'ai ni le temps, ni la motivation de reprendre ces développements.
De mon point de vue, modifier les processus de traduction et de relecture sont loin d'être la première priorité. Il me semblerai nécessaire de commencer par améliorer ce qui ne marche pas, c'est-à-dire la publication et la diffusion, avant de s'attaquer au reste.
Je suis enthousiaste: "Tu commences quand ?"
Moi, je t'envoie ce soir ce dont tu as besoin pour assurer l'interim et publier un état des traductions digne de nos traducteurs et je serai disponible pour répondre à toutes tes questions.
OK. Je suis un peu surpris de cette proposition, mais je te remercie de cette marque de confiance. J'accepte volontiers ton offre.
J'attends ces informations, et je verrais comment procéder à partir de là.
Le 2002-04-20 01:01:48 +0200, Jean-Philippe Guérard écrivait :
Le 2002-04-19 14:04:09 +0200, Nicolas Chauvat écrivait :
Je suis enthousiaste: "Tu commences quand ?"
Moi, je t'envoie ce soir ce dont tu as besoin pour assurer l'interim et publier un état des traductions digne de nos traducteurs et je serai disponible pour répondre à toutes tes questions.
OK. Je suis un peu surpris de cette proposition, mais je te remercie de cette marque de confiance. J'accepte volontiers ton offre.
J'attends ces informations, et je verrais comment procéder à partir de là.
Je n'ai toujours rien reçu ? Est-ce normal ? Je crois que « ce soir » est déjà largement dépassé.
Jean-Philippe
Je n'ai toujours rien reçu ? Est-ce normal ? Je crois que « ce soir » est déjà largement dépassé.
Non, ce n'est pas normal, je t'ai envoyé un message le soir même depuis chez moi... J'y expliquais que j'avais consacré mon vendredi à faire une grosse part du boulot et qu'il ne te restait qu'à générer quelques documents qui ne passent pas chez moi et à vérifier que le site FTP et l'état de la traduction étaient d'accord entre eux.
Comme mon écran m'a lâché ce week-end, je n'ai pas pu accéder à mon courrier depuis. J'en ai reçu un nouveau ajdh, mais je serai en déplacement jusqu'à jeudi, donc tu n'auras probablement pas de réponse avant jeudi soir. Si j'arrive à trouver le temps, je te renvoie le message ce soir, mais je doute d'y arriver.
PS: Pour plus de détails http://www.traduc.org (section nouvelles) et http://www.traduc.org/HOWTO/etat.html (et oui, il est revenu :-)
Le Apr 19, Jean-Philippe Guérard écrivait
...............
De mon point de vue, modifier les processus de traduction et de relecture sont loin d'être la première priorité. Il me semblerai nécessaire de commencer par améliorer ce qui ne marche pas, c'est-à-dire la publication et la diffusion, avant de s'attaquer au reste.
Qu'en pensez-vous ?
Je suis entièrement d'accord. Il faut apurer le situation actuelle (c'est à dire publier les derniers documents traduits et mettre à jour ce qui doit l'être). Il ne faut pas oublier que beaucoup d'utilisateurs de Linux ne sont pas anglophones et s'appuient donc sur les traductions. Les dites traductions ne sont pas seulement disponibles sur le réseau, mais également par le biais de CD distribués par les revues spécialisées. Je l'ai déjà dit, c'est une charge lourde pour une seule personne, un groupe de 3 ou 4 personnes pourraient s'en charger. Je suis partant pour l'une des tâches. Il n'y a pas besoin d'usine à gaz pour cela.
Amicalement.
-- Jean-Philippe Guérard -- mailto:jean-philippe.guerard@laposte.net
Traduc mailing list Traduc@traduc.org http://www.traduc.org/mailman/listinfo/traduc
------ Jacques.Chion@wanadoo.fr f6cwo Quelques HOWTO en français hhtp://perso.wanadoo.fr/jacques.chion/
Le Friday 19 April 2002 19:45, tu écrivais :
Je l'ai déjà dit, c'est une charge lourde pour une seule personne, un groupe de 3 ou 4 personnes pourraient s'en charger. Je suis partant pour l'une des tâches. Il n'y a pas besoin d'usine à gaz pour cela.
Hum... L'intérêt de l'informatique et du développement n'est-il pas de simplifier la tâche de l'homme ? J'avoue avoir du mal à cerner votre point de vue, à tous les deux.
Le 2002-04-18 15:26:34 +0200, Xavier Antoviaque écrivait :
Pour cela, je reste tout de même persuadé que la première chose à faire est de se doter d'outils plus performants, qui vont alléger les tâches de tout le monde.
Non. Je ne suis pas d'accord.
Avoir des outils plus performant n'apporte rien en soi.
Commençons par clairement définir ce que nous voulons, et ensuite seulement, nous pourrons créer ou trouver les bons outils.
Notre interrogation a ici cherché à répondre à tous les points que tu soulèves : l'interface et l'intégraion au TLDP vont donner de meilleures possibilités de publication et de distribution, la simplification des tâches et la clarification des procédures permettront (du moins c'est un des buts) de toucher un plus grand nombre de volontaires.
Justement, ce que je soulève, c'est que tous ces points ne sont pas forcément pertinents. Certains se posent sans doute d'une façon aiguë, d'autre ne sont pas des problèmes pour nous.
Attaquons-nous aux vrais problèmes, et ne perdons pas notre temps avec les autres.
Mais si tu as d'autres solutions à proposer, nous les accueillerons avec joie.
Je ne souhaite justement *pas* proposer de solutions. Je veux qu'avant de trouver les solutions, nous trouvions les problèmes.
Pourquoi uniquement standardiser la relecture ? C'est le problème le plus pressant ?
Non, c'est juste le plus confus actuellement à mon sens. Mais ce n'est pas forcément le seul endroit où il y a des points à éclaircir.
Qu'est-ce qui est confus dans la relecture ? Je n'ai rencontré aucun problème, ni aucune confusion lorsque j'ai réalisé des relectures, je suis donc très curieux de connaître les problèmes précis que posent la relecture.
Quel est le problème que nous cherchons à corriger ? Est-il réel ?
Oui, il est réel. Ce n'est pas pour rien je pense que le TLDP en ressent aussi le besoin, et a créé Lampadas.
OK. Je veux bien qu'il soit réel, mais de quel problème s'agit-il ?
Pour finir, je te propose de continuer cette conversation sur Lampadas, pour ne pas avoir deux conversations différentes sur le même sujet.
Non, je ne crois pas que ce soit une bonne idée. Je pense que nous devrions nous mettre d'accord ici ensemble avant d'aller discuter de l'outil dont nous avons besoin.
Le Friday 19 April 2002 00:37, tu écrivais :
Non. Je ne suis pas d'accord. Avoir des outils plus performant n'apporte rien en soi.
Bon. Plutôt que de partir dans un débat qui risquerait de rapidement tourner au "mais si! mais non!", je te propose un petit exercice de logique.
Postulat de base : - le coordinateur fait aujourd'hui de nombreuses tâches répétitives à la main - seul un outil automatisé permettrait de s'affranchir de cette répétitivité
Donc : - un nouvel outil est nécessaire, quoi qu'il arrive
Mais : - un tel outil automatisé devra, pour être complètement efficace, être utilisé par les membres du projet, et non seulement le coordinateur (upload des fichiers) - l'intervention d'autres membres du projet sur cette interface pose le problème de la définition des rôles
Ensuite : - la redéfinition des rôles demande notamment une réflexion de profondeur sur les problèmes actuels et la manière de les résoudre (celle que tu demandes)
Conclusion : - cette réflexion peut donc tout à fait se faire autour de la définition des spécifications du nouvel outil. Et c'est d'ailleurs ce qui s'est passé ! Pourquoi crois-tu que je me suis amusé à écrire un mail de dix pages là-dessus ? Pourquoi crois-tu que la discussion qui a suivi (et à laquelle tu as participé) a impliqué plus d'une cinquantaine de réponses, souvent très détaillées ?
Là en gros, ce que tu es en train de me dire, c'est qu'on est tous arrivés comme des fleurs, que l'on a dit "hmm, telles et telles fonctionnalités seraient sympa" sans réflexion sur les apports qu'elles donneraient ou les problèmes qu'elles résoudraient.
Je suis désolé, mais ce n'est pas le cas. (..."mais si! mais non!" ...)
D'autre part...
Postulats de base : - traduc.org, dans sa forme actuelle, va devenir le LDP fr - le TLDP est déjà en train de développer un outil, Lampadas
Donc : - nous aurons à utiliser Lampadas
Conclusion : - il ne sert à rien de continuer de discuter éternellement dans notre coin; c'est le moment de participer, si on ne veut pas que nos belles idées se retrouvent enterrées le jour où l'arrivée du nouvel outil nous forcerait à adopter un fonctionnementque l'on ne souhaite pas.
Commençons par clairement définir ce que nous voulons, et ensuite seulement, nous pourrons créer ou trouver les bons outils.
Copier-coller de mon message du 13/04 :
"Mais avant de se lancer à corps perdu dans l'installation et le développement de telles architectures, encore faut-il savoir ce que l'on doit en attendre."
Qu'est-ce qui est confus dans la relecture ? Je n'ai rencontré aucun problème, ni aucune confusion lorsque j'ai réalisé des relectures, je suis donc très curieux de connaître les problèmes précis que posent la relecture.
Ce qui n'est pas clair aujourd'hui, du moins à mon sens, c'est ce qui est nécessaire pour qu'un document soit considéré comme relu, exempt de fautes et bon à publier. Pour les HOWTO passe encore, mais pour certains, on ne sait pas toujours s'il faut zéro/une/deux/.. relectures, à partir de combien de fautes il faut une relecture supplémentaire, etc. Preuve en est ton erreur à propos des fichiers po.
Le 2002-04-19 12:28:06 +0200, Xavier Antoviaque écrivait :
- un tel outil automatisé devra, pour être complètement efficace, être
utilisé par les membres du projet, et non seulement le coordinateur (upload des fichiers)
Pour l'instant, l'efficacité « complète » n'est pas forcément nécessaire. Il nous faut surtout des outils simples opérationnels rapidement.
- la redéfinition des rôles demande notamment une réflexion de profondeur sur
les problèmes actuels et la manière de les résoudre (celle que tu demandes) => cette réflexion peut donc tout à fait se faire autour de la définition des spécifications du nouvel outil. Et c'est d'ailleurs ce qui s'est passé ! Pourquoi crois-tu que je me suis amusé à écrire un mail de dix pages là-dessus ? Pourquoi crois-tu que la discussion qui a suivi (et à laquelle tu as participé) a impliqué plus d'une cinquantaine de réponses, souvent très détaillées ?
Une discussion, c'est bien. Mais ce n'est pas une spécification. Pour écrire les spécifications d'un outil, il faut prendre des décisions, ce que nous n'avons pas fait au cours de cette discussion.
- traduc.org, dans sa forme actuelle, va devenir le LDP fr
- le TLDP est déjà en train de développer un outil, Lampadas
=> nous aurons à utiliser Lampadas
Même si nous choisissons d'utiliser cet outil, je ne crois pas que nous soyons dans une situation où nous n'avons pas le choix.
+ Nous pouvons décider d'adopter des outils automatisant la publication sans obligatoirement tout automatiser. La taille actuelle du projet ne semble pas nécessiter une automatisation totale.
+ Nous pouvons décider de construire une usine à gaz automatisant tout.
Dans chacun de ces cas, c'est à nous de définir ce que nous voulons, et la façon dont cela doit opérer.
Qu'est-ce qui est confus dans la relecture ? Je n'ai rencontré aucun problème, ni aucune confusion lorsque j'ai réalisé des relectures, je suis donc très curieux de connaître les problèmes précis que posent la relecture.
Ce qui n'est pas clair aujourd'hui, du moins à mon sens, c'est ce qui est nécessaire pour qu'un document soit considéré comme relu, exempt de fautes et bon à publier. Pour les HOWTO passe encore, mais pour certains, on ne sait pas toujours s'il faut zéro/une/deux/.. relectures, à partir de combien de fautes il faut une relecture supplémentaire, etc. Preuve en est ton erreur à propos des fichiers po.
Preuve de quoi ? Quelle erreur ? Je suis en charge de la relecture des fichiers PO de nano depuis fin décembre, et je connais donc plutôt bien le processus.
La situation actuelle est la suivante :
+ Les HOWTO nécessitent 1 relecture. Une fois la relecture reçue, le document fait autant d'aller-retour que nécessaire entre le traducteur et le relecteur, jusqu'à ce que les 2 parties soient satisfaites.
+ Il n'y a pas pour l'instant de système de relecture systématique institutionnalisé sur les fichiers PO. De plus, une relecture dans le texte d'un fichier PO n'est pas forcément une solution idéale, certaines traduction pouvant être non triviales du fait du contexte. Le meilleur moyen de relire un fichier PO est d'utiliser le logiciel qu'il traduit, et de relever les incohérences. Le meilleur relecteur est donc dans ce cas un utilisateur régulier du logiciel traduit.
Bonjour,
On Sat, Apr 20, 2002 at 03:20:08AM +0200, Jean-Philippe Guérard wrote: [...]
Une discussion, c'est bien. Mais ce n'est pas une spécification. Pour écrire les spécifications d'un outil, il faut prendre des décisions, ce que nous n'avons pas fait au cours de cette discussion.
- traduc.org, dans sa forme actuelle, va devenir le LDP fr
- le TLDP est déjà en train de développer un outil, Lampadas
=> nous aurons à utiliser Lampadas
Même si nous choisissons d'utiliser cet outil, je ne crois pas que nous soyons dans une situation où nous n'avons pas le choix.
Effectivement, je pense qu'il faut les 2, à savoir LDP fr et traduc.org. Pourquoi ? et bien premièrement traduc.org c'est le portail de la doc en Français. On y trouve des informations qui ne sont pas sur le LDP.
Il faudrait dépoussiérer un peu le site traduc.org, pour faire une présentation claire de tout les projets de traduction.
Si je prend mon cas personnel, j'ai mis pas mal de temps à comprendre ce qu'était le TP.
Ce qui n'est pas clair aujourd'hui, du moins à mon sens, c'est ce qui est nécessaire pour qu'un document soit considéré comme relu, exempt de fautes et bon à publier. Pour les HOWTO passe encore, mais pour certains, on ne sait pas toujours s'il faut zéro/une/deux/.. relectures, à partir de combien de fautes il faut une relecture supplémentaire, etc. Preuve en est ton erreur à propos des fichiers po.
Preuve de quoi ? Quelle erreur ? Je suis en charge de la relecture des fichiers PO de nano depuis fin décembre, et je connais donc plutôt bien le processus.
La situation actuelle est la suivante :
- Les HOWTO nécessitent 1 relecture. Une fois la relecture reçue, le document fait autant d'aller-retour que nécessaire entre le traducteur et le relecteur, jusqu'à ce que les 2 parties soient satisfaites.
Ne peut-on pas regarder comment procèdent les autres traducteurs, ie, autre langue ? ou alors sommes nons des précurseurs ?
- Il n'y a pas pour l'instant de système de relecture systématique institutionnalisé sur les fichiers PO. De plus, une relecture dans le texte d'un fichier PO n'est pas forcément une solution idéale, certaines traduction pouvant être non triviales du fait du contexte. Le meilleur moyen de relire un fichier PO est d'utiliser le logiciel qu'il traduit, et de relever les incohérences. Le meilleur relecteur est donc dans ce cas un utilisateur régulier du logiciel traduit.
Pour les po, on peut faire 2 types de relectures, 1 ispell + typo, et une vraie relecture. Personnellement je me contente de la première quand je ne connais pas le logiciel. Je pense cependant, comme toi, que le meilleur relecteur qui soit est l'utilisateur, et qu'il faut la aussi l'inciter à faire des rapports de bogues pour qu'il donne son avis sur une traduction.
Maintenant, je n'ai pas la moindre idée sur comment le mettre en place,
Bon week end,
Bonjour,
Le 2002-04-20 08:12:17 +0200, Pierre Machard écrivait :
Effectivement, je pense qu'il faut les 2, à savoir LDP fr et traduc.org. Pourquoi ? et bien premièrement traduc.org c'est le portail de la doc en Français. On y trouve des informations qui ne sont pas sur le LDP.
Il faudrait dépoussiérer un peu le site traduc.org, pour faire une présentation claire de tout les projets de traduction.
Tout à fait d'accord.
Ne peut-on pas regarder comment procèdent les autres traducteurs, ie, autre langue ? ou alors sommes nons des précurseurs ?
Si. Ce serait un excellente idée.
Le Saturday 20 April 2002 08:12, tu écrivais :
Effectivement, je pense qu'il faut les 2, à savoir LDP fr et traduc.org. Pourquoi ? et bien premièrement traduc.org c'est le portail de la doc en Français. On y trouve des informations qui ne sont pas sur le LDP.
C'est justement un des buts du TLDP : qu'il n'y ait plus *des* sources de documentation, mais une seule. Un document sera intégrable dans n'importe quelle langue, et pourra venir de toute source. Là où il y avait de nombreux projets éparpillés, ils seront désormais centralisés et donc plus facilement retrouvables pour l'utilisateur final.
Après, savoir ce que l'on fait de traduc.org (maintien séparé ou pas) est une décision que l'on devra prendre, mais personnellement je n'en vois pas l'utilité...
C'est justement un des buts du TLDP : qu'il n'y ait plus *des* sources de documentation, mais une seule. Un document sera intégrable dans n'importe quelle langue, et pourra venir de toute source. Là où il y avait de nombreux projets éparpillés, ils seront désormais centralisés et donc plus facilement retrouvables pour l'utilisateur final.
A mon avis, il n'y a aucun intérêt à intégrer au LDP le projet de traduction de la doc Python (par exemple).
Après, savoir ce que l'on fait de traduc.org (maintien séparé ou pas) est une décision que l'on devra prendre, mais personnellement je n'en vois pas l'utilité...
Donc www.traduc.org garde une utilité puisqu'on peut lui garder sa fonction de portail "vous cherchez à aider des projets de traduction, voici ceux qui cherchent de l'aide : LDP, Python, Perl, GNU, Gnome, etc."
En revanche, si Lampadas remplit ses promesses, les autres projets le trouveront sûrement utiles et on aura un lampadas LDP, un lampadas Gnome, etc.
Le Mon, Apr 22, 2002 at 11:55:13AM +0200, Nicolas Chauvat a écrit:
A mon avis, il n'y a aucun intérêt à intégrer au LDP le projet de traduction de la doc Python (par exemple).
Il y en a au moins un: la cohérence des termes utilisés.
A mon avis c'est plus une ressource à partager entre plusieurs projets (et donc à intégrer à traduc.org ?) plutôt qu'une raison de fondre les projets entre eux.
Il faudrait dépoussiérer un peu le site traduc.org, pour faire une présentation claire de tout les projets de traduction.
Si je prend mon cas personnel, j'ai mis pas mal de temps à comprendre ce qu'était le TP.
Ah, ah, je vois là poindre l'oreille d'un volontaire. Parfait, dès ce soir je t'envoie les fichiers qui permettent de générer le site. C'est du XML avec une section qui s'écrit en HTML. Tu ne devrais avoir aucun mal à les adapter. Ne t'inquiète pas, je me chargerai de leur publication (rapide :-)
Le Saturday 20 April 2002 03:20, tu écrivais :
Pour l'instant, l'efficacité « complète » n'est pas forcément nécessaire. Il nous faut surtout des outils simples opérationnels rapidement.
Je suis d'accord, mais tant qu'à faire des specs, autant les faire de manière complète. Après le développement se fera de toutes façons progressivement.
Une discussion, c'est bien. Mais ce n'est pas une spécification. Pour écrire les spécifications d'un outil, il faut prendre des décisions, ce que nous n'avons pas fait au cours de cette discussion.
Car nous avons choisi de la continuer avec le reste du TLDP. Au même titre que l'on ne veut pas se laisser imposer des choix, on ne va pas les imposer aux autres.
Même si nous choisissons d'utiliser cet outil, je ne crois pas que nous soyons dans une situation où nous n'avons pas le choix.
Non, mais pour intégrer les données dans la base de données commune du TLDP, c'est quand même mieux d'avoir un outil de base commun. Il peut par contre tout à fait y avoir des développement externes différenciés, je ne pense pas que ce soit gênant effectivement.
[Relectures]
- Il n'y a pas pour l'instant de système de relecture systématique institutionnalisé sur les fichiers PO.
C'est à ça que je faisais référence.
Même si nous choisissons d'utiliser cet outil, je ne crois pas que nous soyons dans une situation où nous n'avons pas le choix.
Non, mais pour intégrer les données dans la base de données commune du TLDP, c'est quand même mieux d'avoir un outil de base commun. Il peut par contre tout à fait y avoir des développement externes différenciés, je ne pense pas que ce soit gênant effectivement.
J'ai contribué il y a déjà 6 mois un outil d'export qui permet de publier les tables de la base sous forme de fichier XML : dtd OMF ou dtd LDP. Il a depuis été réécrit par David Merrill.
Voir http://db.linuxdoc.org/ ou http://db.tldp.org/
Cela démontre le désir d'ouverture du LDP et la volonté de partager au maximum les informations qui s'y trouvent, que chacun puisse en faire usage au mieux et le plus facilement possible.
J'ai longtemps essayé de maintenir traduc.org/HOWTO avec ça, et l'expérience prouve que c'est trop d'efforts, mieux vaut collaborer de plus près encore, d'où la situation actuelle avec fr.tldp.org
Pour finir, je te propose de continuer cette conversation sur Lampadas, pour ne pas avoir deux conversations différentes sur le même sujet.
Non, je ne crois pas que ce soit une bonne idée. Je pense que nous devrions nous mettre d'accord ici ensemble avant d'aller discuter de l'outil dont nous avons besoin.
Je suis tout à fait d'accord qu'il ne faut pas chercher une solution avant d'avoir trouvé quel problème on chercher à résoudre.
MAIS
Je sais quel problème je cherche à résoudre. J'ai exposé ce problème à de nombreuses reprises sur cette liste. Pour pouvoir passer la main l'esprit tranquille, je suis en train de passer mes nuits à écrire l'outil qui va permettre de régler mon problème, qui est aussi celui de tous les coordinateurs de traductions.
Je propose donc que l'on arrête de discuter en rond. Soit je résouds mon problème et ça ne change rien pour les personnes qui contribuent à traduc, soit je ne le résouds pas et ce sera vraiment à mon/mes successeurs de trouver la solution.
Bon, j'y retourne.