Discussion a propos de l10n sur devel, et design preliminaire d'un reel service de trad pour debian

[Martin Quinson <martin.quinson@tuxfamily.org>]

Bon, je crois que c'est la premiere fois de ma vie que je vois virer le
consensus sur -devel si nettement en faveur des traducteurs contre les
developpeurs qui bloquent. Et sur un point aussi chaud au coeur des
developpeurs que les NMUs.

Par contre, Christian, fait gaffe. Tes NMU ont plutot interet a etre
irreprochables, maintenant. Fait bien attention a t'abonner au PTS, par
exemple. Ca sera un argument fort si ca tourne mal. Je dirais meme que tu
devrais t'abonner a vie. Comme ca, si y'a pas de mise a jour dans le mois
qui suit, mais deux mois apres, tu le verra aussi. Et tu peux toujours te
desabonner a la MAJ suivante, si tes changements sont bien pris en compte.

On peut repartir la charge. J'ai pas le droit de faire de NMU, mais je peux
faire de la veille bugologique sur les paquets que t'as NMUer.



Sinon, tout ca m'a donne des idees pour gerer les traductions des
programmes et des pages de manuel:

le script de Denis pour w.d.o/intl/l10n extrait le materiel a traduire, et
pour l'instant il n'en fait rien, a part quelques stats.

Mon idee serait de mettre en place une gigantesque arborescence CVS
contenant le materiel a traduire de tous les paquets. avec trois sous
repertoires sous chaque:

 transcvs/dpkg/po/fr.po  pour le programme
 transcvs/dpkg/doc/fr.po pour ce qui devrait utiliser po4a (man, info, etc)
 transcvs/dpkg/deb/fr.po pour ce qui va dans le paquet (debconf, news)

Et a la racine de chaque paquet, un fichier decrivant toutes les traductions
a faire, dans l'esprit des POTFILES.in (le mal nomme, avec son .in en trop)
de po-debconf.

Bon, jusque la, a part bouffer des resources supplementaires et avoir
l'inutile historique des traductions, ca ne sert a rien. (mais ca peut
constituer un milestone^W jalon)

La ou ca devient interressant, c'est si on rajoute des choses dans le script
invoque par cvs en cas de commit. Je pense a lui faire generer des paquets
$package-{fr,de,es,...} en fonction de ce qu'il y a dans le CVS (le POTFILE)
et contenant les traductions du CVS, placees sur le disque de l'utilisateur
avec un divert de dpkg. Ces paquets sont ensuite envoyes vers un serveur non
officiel sous differentes arborescences, en fonction de la langue. Bon, ca
ne marche pas pour la categorie "deb", qui doit vraiment etre dans le paquet
lui meme, mais c'est deja bien.

Exemple
Package: dpkg-fr
Version: 1.10.10-0.0.0.1
Depends: dpkg (= 1.10.10)
Enhances: dpkg
Description: French localization of the dpkg program
 This package contains files improving the localization of the dpkg package.
 They were produced by translators without the approval of the official dpkg
 package maintainer, but are intended to be incorporated in the next release
 of dpkg, if the maintainer agrees.
 .
 Until then, you can use this package to get the most up to date translations.
 .
 If you find a bug in this translation, please report to <quelque part>.
 .
 Le meme texte en francais.
 
Problemes :
 - faire les msgmerge qui vont bien (pas dur)
 - generer et uploader le plus vite possible les paquets de trad apres les
   paquets originaux (pour pas que dpkg-fr soit vire parce qu'il depend de
   dpkg 1.10.10). Quand ca marchera, on demandera un hook dans les scripts
   de dinstall. 
 - Verifier que enhances fait ce dont j'ai envie, ie :
   - demande l'installation du paquet si le premier est installer.
     On peut aussi faire un hook dans apt verifiant les paquets installes, et 
     affichant a l'ecran les traductions manquantes.
   - Il faut aussi que reportbug marque que ces paquets sont installes dans
     les rapports.
 - Trouver un serveur CVS assez solide pour resister a la charge
 - Trouver un serveur ftp assez solide pour resister a l'assaut des paquets
   de traduction.
 - Gerer les problemes de logistique cote traducteur et relecteur (on sait
   faire)
 - Permettre la gestion des rapports de bogue. On peut carrement duppliquer
   debbug, si on trouve une machine ultra-baleze et mettre un champ Bugs:
   dans les paquets.
 - Permettre aux mainteneurs d'integrer les traductions effectivement.
   Un dh_updatetranslation devrait faire l'affaire, je pense.
   
 - Securiser le droit d'ecriture dans le CVS. Il nous faut un serveur CVS ne
   repondant qu'a ceux qui l'attaquent avec une cle PGP en bonne et due forme.


Pour se faire une idee, Denis, ca te prend combien de place toutes les
traductions extraites (en gzip) ? Il faut ensuite multiplier par le nombre
de sous version gardees dans l'historique du CVS, plus 1 pour les paquets
binaires generes, et on trouve la place dispo necessaire sur le serveur.
Sans parler du debbugs, evidement.

Voila, voila, Mt.

-- 
There is enough for the need of everyone in this world, 
but not for the greed of everyone.
   --- Mahatma Gandhi