i18n, l10n et debian
[Je répond à Christian, qui m'a demandé quels etaient mes projets en i18n et
l10n. Je le fais en public parce que je pense que d'autres peuvent etre
intéressés.]
Ca y est, a priori, j'ai une bourse de these (parallélisme) ! Je peux donc te
répondre, meme si mon temps libre risque de décroitre un peu les prochains
temps...
D'abord, une ptite précision :
i18n : permettre à un programme de causer plusieurs langues. Ca se fait donc
souvent en C.
l10n : traduire tout ce qu'on peut traduire. Ca se fait donc en langue
naturelle.
g11n (globalisation) : permettre à un programme de causer plusieurs langues en
meme temps, et pas avec les bascules LC_ALL et compagnie. Ca se fait en C, et
a part emacs, je connais pas de programme globalisé.
Je me permet de te faire ce petit cours parce que dans ton mail, on dirais que
t'emploie i18n à la place de l10n...
Moi, je me suis surtout interressé à l10n. La seule fois ou j'ai eu envie de
toucher à i18n, c'est dsellect, ou i18n n'est pas parfait, et quand on a
traduit entre autres avec Jerome Marant, on obtient des trucs pas tres beaux
du style "requis paquets à jour". Mais Jerome m'a convaincu de ne pas aller
mettre mon nez dans un code aussi sensible politiquement.
En ce qui concerne l10n, pour l'instant, j'ai fait un jeu de scripts perl pour
faire des pages qui montrent l'avancement de l10n (et donc, i18n aussi,
puisqu'il n'y a pas de l10n possible sans i18n) dans debian.
Les pages sont à deux endroits :
www.debian.org/international/l10n (de memoire)
www.ens-lyon.fr/~mquinson/debian/l10n
(Les scripts sont dans le cvs des pages web de debian)
Le second endroit est un peu historique, et tous les liens y sont cassé car
les pages supposent que l'on utilise la négociation de contenu d'apache, ce
qui n'est pas le cas à l'ecole. Si je le cite, c'est que la bas, on trouve les
pages en francais et en anglais, ce qui montre que les pages elles meme sont
i18n ;). De plus, certaines pages ne sont pas générés sur w.d.o il s'agit des
pages montrant le détail de chaque équipe de traduction, et permettant meme de
télécharger les fichiers po à traduire. Par exemple :
http://www.ens-lyon.fr/~mquinson/debian/l10n/l10n-lang-fr.fr.html
Cette derniere capacité est tres intéressante, mais pose problème car elle
offre à tous de traduire des trucs, sans apporter ne serait ce que le début de
solution logistique. Prenons l'exemple de gimp. Si qqun le télécharge depuis
mes pages, et avance la traduction, il y a fort à parier que son travail va
faire double emploi avec celui du traducteur habituel, hors debian...
Il faut donc trouver un moyen de ne pas marcher sur les plates bandes des
autres projets de traduction, qui d'habitude ne sont pas
distribution-centriques, mais projet centriques. Citons
http://www.iro.umontreal.ca/contrib/po/HTML/index.html (pour gnu)
http://developer.gnome.org/arch/translate/ (pour gnome)
http://i18n.kde.org/ (pour kde)
Et il y en a sans doute d'autres, au moins pour les gros projets comme
gnustep, et compagnie, mais je les connais pas.
Dans la catégorie distrio centriques, il y a mandrake, qui se concentre sur
l'i18n et la l10n des programmes développés en interne :
http://www.linux-mandrake.com/en/l10n.php3
Et peut etre d'autres que je ne connais pas.
(si qqun a plus de pointeurs, je suis prenneur)
Ok, maintenant que l'on sait quel est le pb, comment je compte le resoudre,
quand j'aurais le temps de coder ?
1) Faire un programme de patch de po, pour isoler les messages induits par les
modifications des developpeurs debian, que l'on peut traduire en interne, des
messages du code de la source, qu'il faut traduire dans le cadre du projet
concerné.
Etat : projet dans ma tete
2) Modifier les pages de facon à ce qu'elles offrent les parties debian en
telechargement et des liens sur les projets à contacter pour les parties non
debian.
Etat : noble idée
3) Utiliser le robot du projet gnu pour automatiser le retour des traductions
debian, et des programmes distribués par debian n'ayant pas leur propre
systeme de traduction.
Etat : J'ai discuté avec François Pinard, l'auteur, il est d'accord, il me
reste plus qu'a me mettre au boulot.
4) mettre en place une base de donnée de qui maintient quelle trad dans le
projet debian, comme c'est fait dans les projets gnu et kde, pour
sauvegarder les plates bandes de chacun.
Etat : noble idée
5) simplifier l'usage des pages sur w.d.o en rajoutant un menu, et
depoussierer un peu les scripts.
Voila, je crois que c'est toutes les idées que j'ai dans ce cadre. Pour
l'application, je pars ce soir pour revenir début aout, et à ce moment, il
faut que je mette le feu à ma these des le début si je veux assurer. Donc, je
sais pas trop quand j'aurais le temps d'agir efficacement. On verra. D'autant
que la FAQ de debian-french aurait aussi besoin de dépoussierage...
Ma priorité, c'est le programme po-from-patch.
Bye, Mt.
Reply to: