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.
