Le plan concert� avec Grisu, c'est de laisser les choses se calmer (rat�),
et de *peut etre* faire un fork exp�rimental de dpkg. Pas pour le publier et
faire bisquer [EMAIL PROTECTED], mais pour tester sur nos machines � nous si
ca marche, comment on peut integrer les id�es propos�es lors de la discution
pr�c�dente. point.
En clair : rentrer la tete dans les epaules, attendre que ca passe, et
reflechir.
On Thu, Oct 04, 2001 at 04:31:35PM +0200, Raphael Hertzog wrote:
> Quel est votre plan pour la suite ? Quelle synth�se avez vous faite de la
> discussion ?
Mon avis (et la, c'est plus aussi concert� avec Grisu), c'est que
maintenant, on a une infrastructure satisfaisante pour traduire en francais,
avec relecture et tout et tout. Voir les archives de debian-l10n-french pour
s'en convaincre. On traduit, donc. Et au rythme actuel, on aura fini mi
2003. On ne veut pas aller plus vite car l'architecture de relecture
actuelle passe pas tres bien a l'echelle, et si on a trop de traducteurs,
les relecteurs vont eclater. Nicolas est en train de modifier le ddts pour
am�liorer ca, mais d'ici la, on reste � ce rythme. Donc, on a le temps de
reflechir � comment utiliser ces traductions.
Mon analyse de la discution qui a eu lieu sur -devel, c'est que wichert a
raison, c'est le merdier dans les fichiers de status. dpkg en a, dselect en
a --peut etre les memes-- et apt en a d'autres. Cf, la derniere discution
sur -dpkg ou jason et wichert se renvoient la balle � propos d'un probleme
li� � cet etat de fait. Donc, notre proposition de ranger des meta data dans
un troisieme systeme (les fichiers mo de gettext) n'est pas forc�ment
raisonnable. Meme si c'est le plus naturel. Par exemple, le format utilis�
dans les fichiers de status de dpkg ne passe pas simplement � l'echelle en
nombre de langues support�es. Donc, rien n'est simple.
Mais cette histoire de fichier de status est assez anecdotique, je trouve.
Mettre les donn�es dans un fichier po, le patch est �crit et il est
ridiculement simple. Mettre les donn�es dans le status de dpkg, c'est pas si
compliqu�, il suffit d'autoriser les expressions r�gulieres extra
simplifiees dans la table qui indique quelles fonctions gerent quelles
champs. Et apres, il faut modifier l'affichage pour utiliser ces infos. Je
l'ai fait avec gettext, je peux le faire sans. C'est plus chiant, mais bon.
Donc, le probleme n'est pas la. Le probleme, c'est que personne n'est
d'accord sur le cahier des charges des modifications � faire, et les gens de
dpkg ne veulent plus en parler avec nous...
Voici une proposition :
� faire que l'utilisateur finale puisse voir les descriptions des paquets en
langue maternelle �
Les probl�mes � r�soudre sont:
1) traduire les descriptions, et les relire pour s'assurer de leur qualit�
Ca, c'est ok. le ddts tourne.
2) Faire que les trads soient disponible � l'utilisateur quand y'en a besoin
2.1) Choisir le format de la traduction
2.2) Choisir la facon de publier les traductions (obtenir les donn�es �
temps, et les stocker sur le disque de l'utilisateur)
2.3) Choisir comment les outils utilisent la traduction
Le probleme le plus visible, c'est le format de la trad. Mais en fait, le
plus compliqu�, c'est la publication.
On a en plus les contraintes suivantes :
2.a) Il ne faut pas que les mainteneurs soient *oblig�s* de remettre leur
paquet sur le serveur quand une trad a chang�
2.b) Il en faut pas que le systeme soit sp�cifique � l'archive Debian (ie,
il n'est pas suffisant de modifier katie ou un copain � elle) car certains
paquets ne sont pas dans l'archive.
Mais ca, c'est pas la mort : il faut qu'il y a deux sources possible de
traduction : un truc maintenu par les traducteurs eux memes (comme un paquet
s�par�, un fichier donn� � manger � katie, etc) pour que ce qui est interne
� Debian demande le moins d'effort possible au mainteneur, et dans les
paquets lui meme afin que l'ext�rieur de Debian puisse s'organiser comme il
veut.
Pour r�soudre les probl�mes, on a deux familles de solutions : gettext, ou
un truc fait maison.
Pour l'utilisation, je pense que gettext est la meilleure solution car c'est
un putain de standard de fait. Pardon de l'expression, mais il n'existe meme
pas de concurent tellement la solution est solide et reconnue. Certes, on
l'utilise la un peu en dehors de son champ d'action, mais je pense que ca
reste adapt�. Pour le prouver, il faudrait implementer la solution et la
tester en grandeur nature...
Le probleme de gettext, c'est que ca impose le format, et qu'il semble tres
difficile de regler le probleme de publication avec.
Pour le truc fait maison, les problemes de format et de stockage deviennent
simple: il suffi de faire comme avant, � quelques b�mols pres. Le probleme,
c'est qu'il n'y a pas qu'une seule base de donn�e des infos sur le disque
d'un utilisateur.
Donc le choix entre les deux solutions peut se r��crire en : on fait autant
de solutions maisons qu'il y a de format de donn�es sur le disque, ou on
factorise grace � gettext ? Comment ca je suis partial ?
J'en suis l�. Soit on trouve comment publier les informations de la famille
gettext, et on laisse dpkg et apt se d�merder avec leurs bases de donn�es
diff�rentes, soit on trouve comment mettre les trads dans chacune des bases
de donn�es, et comment r�implementer ce que fait gettext (�limination des
trads pas � jour ; m�canisme de fallback avanc� ; autres ?).
Dans le premier cas (que je prefere), on peut faire un peu ce que debconf
fait : utilis� un crochet (hook) dans apt fait expres pour nous. Ca serait
d'installer un paquet sp�cial � chaque update (celui qui contient les trads
magiques) et se d�merde des trads inclues dans les paquets non magiques. Par
exemple en ajoutant l'info dans le Package.gz pour que l'info soit la avant
que le paquet ne soit t�l�charg�.
Donc, pour arriver � mes fins une facon de faire est :
- on modifie le fichier Packages.gz, pour qu'il contienne les trads
contenues dans chaque paquet (sans compter le paquet magique). Ca demande
de modifier apt ET le programme qui g�n�re ce fichier. Faisable, mais faudra
modifier la charte (policy), je pense. Bonne chance.
- on modifie apt pour ajouter un crochet permettant de telecharger le
paquet magique � l'update (faisable), puis qu'il construise le paquet mo
contenant toutes les trads r�cup�r�es � droite � gauche. Facile avec la
version de gettext telle qu'elle est dans le CVS, et dans la prochaine
version, hopefully. Mais ca va pas accelerer `apt-get update`.
- on modifie dpkg et apt pour qu'ils utilisent gettext pour l'usage des
trads. Fait pour dpkg, et vaudrait mieux qu'apt utilise gettext pour ses
messages avant de l'utiliser pour ca.
Bien bien, pour parvenir � mes fins, il faut que je fasse accepter des
patchs par dpkg, apt et la charte. Mmm. Je vais retourner faire du
metacomputing pour ma these, c'est moins chiant...
Bye, Mt.
PS: d�sol� de la longueur, merci d'avoir lu jusqu'au bout.
--
Un clavier azerty en vaut deux.
