Re: [Fwd: Vote au sujet de Michael Bramer]
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 debian-dpkg@l.d.o, 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.
Reply to: