[long] une idée pour faire avancer les choses
Salut,
Bon, j'ai réfléchi un peu. Je ne dis pas que j'ai *la* solution du
problème de i18n sous Debian mais je crois en avoir une. De plus, je
ne suis pas debian-devel, donc excusez-moi si quelqu'un a déjà eu la
même idée.
Si j'ai bien compris, c'est le bordel car il n'y a pas de solution
adoptée pour tout le monde. D'un côté, « on » ne veut pas modifier
dpkg et apt tant que *la* solution n'est pas trouvée et de l'autre
côté, on se casse le cul à traduire un peu pour rien puisque peu ou
prou, cela n'est pas ou peu intégré (je caricature, prière de ne pas
en rajouter sur ce sujet).
Voici ma solution : je propose la création d'un seul paquet
supplémentaire (un .deb donc) par langue. Cela ajoute donc uniquement
une quarantaine de paquets dans la distribution, ce qui est peu.
Ce paquet ne serait pas réellement un paquet (au sens où il ne serait
pas installable en tant que tel). Ce serait un gigantesque tarball, ou
assimilé, qui regrouperait une architecture de la forme :
paquet_version/po,dtts, etc.
(ou peut-être un sous-répertoire intermédiaire pour n'avoir qu'une
entrée mais cela est secondaire pour l'idée générale)
Bref, *tout* ce qui concerne la l10n du paquet. Et ceci pour tous les
paquets.
On décorrèle ainsi le travail du paquet proprement dit (le programme
lui-même géré par le mainteneur Debian) et sa localisation.
Quant à ce fameux paquet l10n, je le verrai bien non dépendant d'un
mainteneur spécifique mais plutôt auto-engendrable (à l'instar des
pages wml du site Debian). Quand une traduction a été validée sur
debian-l10n, un mainteneur aura juste la charge de la coller dans une
base de données cvs qui engendrera une fois (ou plus) par jour le
fameux paquet l10n. À tout moment, on pourra donc avoir un paquet de
traduction à jour. Le script doit être quasi-enfantin à faire.
D'autre part (et c'est à mon avis le plus important), on pourra ainsi
gérer finement la localisation de Debian. Il faudra ajouter des
options à apt et dpkg qui permettent, *ad libitum*, d'installer telle
ou telle localisation. Par défaut, ce serait certainement bien
d'installer la localisation de la variable LANG.
Bien sûr, si le paquet est désinstallé, on devra aussi désinstaller la
localisation qui a été introduite (si besoin au fur et à mesure). On
pourrait garder l'option --purge de dpkg (dans le même esprit,
i.e. tant que l'on ne jette pas la configuration du paquet, c'est que
l'on a l'intention de le remettre à un moment). Il faudra quand même
offrir la possibilité de purger une localisation donnée, ou bien
toutes (toujours d'un paquet), sans purger la configuration.
Donc, pour résumer, on n'installe jamais le paquet l10n mais de ce
dernier est extrait la localisation d'un paquet dans une langue
donnée. Reste à trouver une façon propre de les désinstaller (je pense
garder le même principe que celui de dpkg, i.e. faire une sorte de
méta-paquet par paquet de traduction. On retire ainsi toute la
localisation d'une langue d'un paquet d'un seul coup. Je ne pense pas
qu'il soit nécessaire de faire une distinction entre le .po, le dtts,
etc. Cela forme un tout homogène. Ce n'est pas vraiment très compliqué
je pense.
Ainsi, on aurait une action très fine au niveau de la distribution
pour la localisation. On pourrait soit gérer cela paquet par paquet,
pour les masos qui comme moi installe une Debian paquet par paquet, ou
bien de façon globale (en forçant une ou deux variables dans les
fichiers de conf de dpkg et d'apt).
Je crois que l'on aurait la même finesse légendaire de Debian au
niveau de la localisation qu'au niveau de la gestion proprement dite
des paquets .deb. En plus, cela soulagerait d'autant les disques car
la méthode d'aujourd'hui installe un paquet (c'est le cas de le dire)
tout à fait inutile...
Je pense que c'est tout à fait réalisable. Je suis un peu balade en ce
moment mais cela ne m'empêche pas de réfléchir :-)
Y-a-t'il une objection à cela ? J'entends par là une objection
*technique* pas les délires d'un gars qui ne veut pas changer les
choses, bien sûr. Personnellement, le script d'extraction des
localisations du paquet l10n est assez triviale à faire en Perl. Pour
apt, un pro du CC+ devrait aussi faire cela en deux coups de cuillère à
pot. Donc, il n'y a pas une masse énorme de développement à faire.
Par contre, je suis conscient que tous les paquets qui intègrent déjà
des localisations seront à modifier. Mais cela ne parait pas
monstrueux (désolé, Christian, c'est sûr que quand on a beaucoup de
paquets, cela en fait plus). Ceci dit, cela peut attendre Sid et non
Woody. Sauf si tout le monde se rassemble autour de cette idée pour
offrir à Debian une nouvelle caractéristique unique dès Woody :-)
On pourrait essayer de se rassembler sur cette idée, ou au moins
partir de cette idée pour proposer quelque chose de cohérent...
Qu'en pensez-vous ?
PK
--
|\ _,,,---,,_ Patrice KARATCHENTZEFF
ZZZzz /,`.-'`' -. ;-;;,_ mailto:p.karatchentzeff@free.fr
|,4- ) )-,_. ,\ ( `'-' http://p.karatchentzeff.free.fr
'---''(_/--' `-'\_)
Reply to: