...

Bref, voilà, ce serait sympa que globalement on ait une documentation plus précise (et à jour) sur le fonctionnement du projet, après quoi on pourra dire aux gens : "viendez traduire avec nous le noyau, c'est bien organisé et efficace !"

Un peu difficile de le dire quand on sait que ce n'est pas le cas.

Le mieux pourrait être de faire une réunion sur ce projet, sur IRC par exemple. Qu'en dites-vous ?

Pas exclusif au projet kernelfr, on a vu récemment un problème similaire sur le projet emacs: que faire des relectures, et en général comment évaluer l'état d'un projet vu d'un bénévole ?

L'AG est dans 2 jours, ce serait bien de mettre un truc en place, à la debian peut-être ?

Jean-Christophe

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

Encore une question : pourquoi le projet kernelfr n'utilise pas le système de fichiers *.pot et *.po, alors que c'est le format de fichiers qu'on trouve sur tlktp.sourceforge.net ? Ça me semble plus carré que d'avoir de faire du remplacement de chaînes directement dans un fichier texte, sans savoir comment les espaces vides vont être gérés en aval (on fait des traductions vers le français, donc chaînes plus longues en moyenne, etc).

JB

Jean-Baka Domelevo-Entfellner a écrit :

Re-bonjour à tous,

Je viens de lire avec un certain plaisir le long mail de Jean-Christophe, avec qui je partage pas mal de points de vue. Quand je dis "plaisir", ce n'est pas que je goûte la critique pour la critique, mais je suis content de voir qu'il y a du monde sur la liste qui est intéressé par la façon dont notre bateau vogue. C'est positif pour l'avenir.

Pour régler le problème intéressant le projet kernelfr, je remerci Gwenaël de sa réponse, _mais_ :

1. Gwenaël, je te pardonne (presque) ton orthographe, mais par contre

le vouvoiement passe mal...

Certe j'ai un véritable problème avec l'orthographe, j'en suis concient mais j'ai vraiment du mal à me reconcilier avec.

2. J'ai beaucoup ri quand tu as dit que tu ne voyais pas trace de ma

résa, alors que tout le monde peut la voir sur la page http://kernelfr.traduc.org/liste.php : je suis bien en train de traduire arch/i386/Kconfig, non ? Ca prouve au pire que le suivi du projet par les coordinateurs (Félix et toi) n'est pas fait sérieusement, au mieux que vous avec un problème d'interfaces multiples et désynchronisées). Merci d'y remédier.

donc, tu es bien en train de traduire arch/i386/Kconfig, de mon point de vue, ce n'est que 1 fichier, c'est pour cela que je ne vois pas le "gros morceau à traduire". Et j'attache autant d'importance aux petits fichiers qui d'après moi doivent au contraire etre traduit en premier, c'est petit, c'est simple, c'est rapide à faire... la relecture est là pour corriger les problèmes de traductions sur les fichiers très spécifiques comme pour les architectures. Ensuite une grosse traduction, c'est pour moi plusieurs fichiers, comme par exemple, ma tentative de traduire toute la partie sound/, mais j'ai eu un manque de temps donc j'ai laissé le reste ( kernel 2.6.10 liens tout en bas: http://kernelfr.traduc.org/liste.php?kernel=2.6.10 )

Pour parler du désynchronisme entre félix et moi, il n'y en a presque pas puisque félix n'ayant pas le temps de s'occuper du projet, je suis le seul à suivre comme je peux...

3. OK pour la procédure pour "tester" ses fichiers traduits. J'avais

dans l'idée que ça pouvait être utile dans le cas de chaînes nettement rallongées par la traduction et dont on voudrait s'assurer qu'elles ne débordent pas trop (titres, etc)

... procédure qui sera effectué lorsque la traduction sera "totale"

4. Je reste très fortement d'accord avec Jean-Christophe sur le fait

que le processus de relecture n'est absolument pas transparent. Qui relit quoi ? Je suis attaché à la procédure en pratique sur debian-l10n (je sais, on n'arrête pas de le citer, mais c'est peut-être bien parce que ça ne marche pas trop mal) : quand qqn a fini une traduction, il le signale à _tout le groupe_ (ici, tout les membres du projet kernelfr), après quoi chacun est libre de relire le document et de signaler des amendements, dans un cadre organisé

Je ne connais pas les principes de traduction/relecture du projet debian, c'est pas mon problème.

Pour le cas de kernelfr, c'est simple, la relecture ne peut se faire pas le traducteur. Et peut tres bien, etre effectué par plusieur personne, le therme de valide veut dire que le fichier a été traduit et au moins une fois relu.

5. C'est qui, < kernelfr AT traduc POINT org > ?

c'est un simple alias vers félix et moi, vu que nous ne somme que 2 a gérer le projet.

6. Comment ça se passe entre les différentes versions du noyau ? Y

a-t-il une réutilisation pseudo-automatique des chaînes déjà traduites ? Sinon, comment la mettre en place ? Par exemple, moi qui suis en train de traduire arch/i386/Kconfig pour le noyau 2.6.15, j'aimerais que l'interface me propose directement les versions traduites pour les noyaux précédents, dont j'ai pu avoir un aperçu via http://tlktp.sourceforge.net/substat.php?lang=fr

l'interface permet de voir les fichiers de différent noyau; 2.6.10, 2.6.11, 2.6.12, 2.6.14, 2.6.15. Vous avez d'ailleur des statistiques toutes les 2 semaines ( quand j'ai le temps ). liens pour consulter: http://kernelfr.traduc.org/old.php

Bref, voilà, il y a un tas de choses qui ne vont pas aussi bien qu'elles pourraient aller, je ne suis pas très content qu'on vienne me dire "ah bon, tu es en train de traduire un truc pour kernelfr ?" alors que c'est visible par tout un chacun sur cette fameuse interface (c'est féminin, "interface", les amis), etc.

J'était plus dans mon point de vue, "Ah bon tu traduit une grosse partie pour kernelfr". cf mon point de vue plus haut.

Merci encore à Jean-Christophe pour sa contribution utile et constructive, et à après-demain pour le CA sur IRC, je serai là.

Amicalement, JB.

--- Gwenael Pellen