Re: Debian goes international ?
Désole de la réponse tardive, je suis actuellement dans un avion au dessus
de l'atlantique.
<hs>Ne prenez pas British airway, c'est bon pour les sardines</hs>
On Fri, Jan 25, 2002 at 04:04:05PM +0100, Raphael Hertzog wrote:
> Le Fri, Jan 25, 2002 at 03:04:12PM +0100, Patrice Karatchentzeff écrivait:
> > > Il y a peut-être des efforts à faire sur la documentation du travail
> > > de traducteur et sur les outils dont il peut disposer. Mais je ne pense
> > > pas que cela ait sa place dans la Debian Policy.
> >
> > Je serai curieux que tu t'expliques sur ce point-là, stp. Je partage
> > assez le point de vue de Martin sur la question.
>
> Je veux dire que la Debian Policy c'est des règles strictes qu'il faut
> suivre, donc je ne vois pas l'intérêt d'y mentionner les outils qui
> permettent de vérifier qu'un fichier .po est bien fait, etc.
J'ai conscience que les concidérations techniques n'ont pas vraiment leur
place dans la charte. Et plus particulierement, il ne faut pas y imposer
d'implémentation quand ce n'est pas necessaire.
Par exemple il a été proposé dernièrement d'enlever l'obligation pour
debian/rules d'être un fichier Makefile. Je suis assez d'accord avec cette
approche : du moment que ca rend les mêmes services, on devrait pouvoir
faire comme on veut. Il ne faut pas plus imposer gettext face aux autres
solutions (le vieillissant catgets, ce qui se fait dans openoffice, ou ce
qui se fait dans Java (TM), ou ce qui se fait ailleurs).
I) Mais y'a tout de même deux trois choses à préciser dans la charte.
Je commence par un détail, pour le dropper en touche :
dans le cas de modules perl dont la doc n'est pas en anglais (ou dans le cas
ou elle est traduite), le chemin n'est plus /usr/share/man/man{1,3} mais
/usr/share/man/[lang-code]/man{1,3}
Je parle ici du chapitre 1.4 de la charte relative à Perl, maintenue entres
autres par ... Raphaël.
(provoc facile, je l'admet ;)
Je doute que le cas se soit déjà produit, mais un jour, on traduira même la
doc des exécutables en Perl, non ?
L'ajout fondamental qui serait une bonne chose à mes yeux serait de rajouter
un truc du genre :
« si un paquet source contient des choses traduites (fichier po, template
debconf, documentation, etc.), le processus de création du binaire devrait
s'assurer que ces traductions sont à jour. Dans le cas contraire, il peut
soit ne pas inclure la traduction incriminée dans le paquet binaire, soit
indiquer clairement dans la traduction que la version originale est plus
récente, ainsi que comment y accèder. »
C'est un "should", donc ca ne devrait gêner personne, et ca metterait la
puce i18n à l'oreille des mainteneurs...
Et, afin de rendre le conseil ci dessus réalisable, il faut par exemple
interdire de stocker les traductions dans le même fichier que l'original. Je
pense aux templates debconf, mais Denis est déjà en train de se « bagarrer »
pour en convaincre Joey.
II) Je ne pense pas que la documentation soit le maillon faible. Les
mainteneurs conciencieux ont des paquets bien traduits. Il faudrait surtout
aider les autres, qui sont comme tout le monde et manquent de temps. Ca
serait une bonne chose que lintian jete un oeil à comment l'i18n est faite,
et surtout qu'il y ait une poignée de dh_blabla pour aider le développeur à
faire « the Right Thing (TM) ». Du style, si on a des fichiers po, on les
déclare par un `dh_i18npo $repertoire`. Ou alors, dh_installdebconf prend
soin d'integrer les traductions. Ou encore `dh_i18ndocbook document_original
traductions*` prend le soin de mettre à jour les trads. On a les moyens de
le faire (un bete 'make update-po', debconf-mergetemplate ou les scripts de
KDE pour docbook), reste plus qu'à prendre l'habitude de les utiliser, et
simplifier leur usage en écrivant les dh_* qui automatisent la tâche.
III) Ce que je demande donc au futur leader (en ma qualité de NON
développeur Debian, mais traducteur militant ;), ce n'est pas une
révolution. C'est simplement un engagement clair dans ce sens. Dire qu'il
est consient que le prochain défi de Debian est l'ouverture au plus grand
nombre (tout en gardant la qualité comme premier objectif). Et que pour ca,
il faut (dans le désordre, ou plutôt, en parallèle) :
- Aider les porteurs à faire leur travail (ca semble pas trop mal se passer
sur ce front puisque la non compilation sur une plateforme annoncée est
une cause de non passage à testing)
(discrimination matérielle ?)
- Simplifier l'usage de Debian (La aussi, les choses vont de mieux en
mieux, je trouve. Mais détailler serait trop long)
(discrimination technique)
- Traduire Debian pour que ca ne soit plus accessible au ... 10 ou 20 % (?)
de la population mondiale qui maitrise suffisement l'anglais pour
comprendre les questions de debconf et les pages de manuel, mais par tous.
(discrimination linguistique)
IV) La révolution, pas avant woody+5 cependant, ca serait d'avoir un champs
'Lang:' à coté de 'Arch:' dans le fichier de contrôle, et que si c'est pas
traduit à 100% dans les langues annoncées, que le paquet soit bloqué hors de
testing. Mais ca demanderait d'avoir des champs 'Translator-..:' à coté du
champ 'Maintainer:', histoire de savoir à qui boter le train au besoin, que
le maintaineur accepte de partager son maigre pouvoir, qu'à coté du diff et
du orig.tgz, on ait des lang.tgz. Peut être aussi une scission systématique
des binaires entre les vrais binaires, et le résultat de la traduction.
mutt.deb et mutt-fr.deb. et pleins d'autres trucs encore, tous plus
irréalisables les uns que les autres.
Une vraie révolution, quoi. Utopique et tout et tout ;)
Désolé pour ce mail un peu long, mais on se fait chier dans cet avion.
Bye, Mt.
--
Si les grands esprits se rencontrent, les petits esprits, eux, se cognent.
Reply to: