Il est trop tard pour ajouter un point à l'ordre du jour de l'AG. Mais si tu pouvais développer ton idée, ça serait intéressant pour tout le monde.
Dans un mail précédent, il était question que les responsables de projets fassent un bilan d'activité pendant l'AG. J'ai profité de ce mail pour relancer la discussion sur le projet emacs, qui m'intéressait en particulier mais qui semblait ne pas fonctionner au mieux.
Pour donner un pouillème de poids à mon mail et pour qu'il ne soit pas exclusivement compris comme un "yaka" (même si il y a quand même un peu de ça, on n'a pas toujours les moyens de ses idées) je me présente comme étant un des "développeurs/coordinateurs" du projet OmegaT, une application libre d'aide à la traduction. Je suis traducteur professionnel (ce qui ne veut pas dire beaucoup plus que je gagne ma vie avec ça) et j'utilise OmegaT pour lequel j'organise aussi le groupe utilisateur, la mise a jour de la documentation, la coordination de la localisation française et japonaise et d'autres bricoles à droite et à gauche comme des séminaires de formations aux outils d'aide à la traduction (aussi bien pour le monde du libre que pour les traducteurs comme moi). Tout ça pour dire que le bénévolat je connais, et dans le même domaine que Traduc, ou presque.
Debian et Traduc ce n'est pas pareil on est d'accord. Debian ils ont une date finale pour la sortie du produit et ceux qui ne sont pas à jour sont grillés. Donc c'est toujours un peu la course. Avec des bilans réguliers, des mises au point etc. Un système de contrôle de qualité qui fonctionne, et en ce qui me concerne est un des meilleurs dont j'ai fait l'expérience, l'autre étant le CQ de la localisation d'OpenOffice avec toute l'infrastructure et les ressources humaines de Sun derrière. Sachant que la localisation de OOo fonctionne bien mieux du coté camembert que du coté suchi. On doit avoir un don pour ça
En gros, ici, on ne sent pas vraiment la pression des deadlines, et c'est très bien aussi, mais le coté très relâché (on ne sait pas ce qu'il faut relire ou traduire sur emacs, il ne semble pas y avoir de système de relecture généralisé, chaque projet semble relativement indépendant mais gagneraient à partager plus) donne un peu l'impression que les gens bossent dans leur coin, bouclent leur machin et c'est fini.
Pour le peu d'activité de l'ensemble du projet (à comparer avec Debian-fr et OOo-fr) on se trouve avec une foultitude de listes et pas un processus en commun.
Premièrement, il me semble que les coordinateurs pourraient avoir une activité plus pro-active, que les interfaces soient plus uniformisés, que les processus soient plus interactifs: traduction->relecture-
derniers commentaire->livraison sur l'ensemble de Traduc et non pas
cloisonnés artificiellement, après tout les gens traduisent ce qu'ils veulent traduire, pas besoin en plus de les mettre sur des listes où rien ne se passe.
Deuxièmement on sait ce qu'il y a sur le LDP, ça doit pas être bien difficile de faire un script pour voir l'état d'avancement du projet globalement, pareil pour les projets individuels, désolé pour emacs, mais c'est la moindre des choses que de mettre une info décrivant l'état des fichiers à jour sur le site.
Le fait d'avoir des relances automatisés permet aux bénévoles de sentir la dynamique et d'y participer.
Troisièmement les outils. Faire une trad dans les balises XML, je veux bien, mais même les professionnels refusent ça, pourquoi torturer des amateurs avec ce genre de pratiques ? Il y a plein d'outils libres, ou non, et gratuits qui aident le traducteur. Le glossaire est un pas gigantesque dans ce sens. Il y a encore des bricoles à régler, mais dans l'ensemble c'est très bien. Pour utiliser ces outils il faut une demi-heure de lecture des manuels, et il y en a pour chaque plate-forme: Windows, Mac et bien sur Linux (il ne faut pas s'imaginer que les traducteurs potentiels sont aussi ou exclusivement des utilisateurs de linux).
Pour conclure: les coordinateurs de projets-> •identifient clairement les tâches, pas forcément liées à la traduction (ex, mettre à jour l'info chez emacs) •explicitent les procédures (ex, création de mémoires de traductions chez emacs) •décrivent les outils utilisables avec de mini tutoriels (ça existe chez NetBeans et OOo) •établissent un cadre de contrôle de qualité (relecture commune et multiple de tous les documents à valider)
Le nombre des listes est réduit pour s'assurer que toute l'info passe bien, avoir une page par projet ça suffit pour l'affichage de l'info, mais pour la com, une seule liste, avec des entêtes [emacs]/[tlktp]/ [lg] etc pour accrocher l'œil.
Je viens de lire le mail de Gwenael, et ça m'attriste de voir que tout doit passer par l'interface (et sans un minimum de correction orthographique, un comble pour une liste de traducteurs) ! C'est pas humain ça ! La page d'état du projet peut être nourrie par les entêtes des mails automatiquement (comme chez Debian) comme ça on sait qui a réservé quoi parce que la personne c'est déclarée sur la liste, et le coordinateur est là pour y répondre et n'est pas dissimulé derrière un script php !
Il y a plein de personnes qui ont l'air extrêmement compétentes dans tous les domaines nécessaires de l'informatique sur cette liste. Plutôt que d'utiliser ces compétences pour déshumaniser le projet, il me semble que ces compétences seraient mieux utilisés pour gérer la convivialité et l'utilisation des ressources.
Bonbonbon, voilà que je me suis un peu emporté. Mais bon, je ne souhaite que la réussite du projet avec en plus, si je peux, l'apport de ma "réflexion" quotidienne sur ce que ça peut être chiant à faire une traduction, même quand on est payé pour ça, et surtout quand l'interlocuteur est une interface de "réservation".
Cordialement,
Jean-Christophe Helary