Re: Nouveau changement aux pages de stats: diff preliminaire
On Wed, Sep 10, 2003 at 10:33:41PM +0200, Denis Barbier wrote:
> On Wed, Sep 10, 2003 at 11:01:57AM +0200, Martin Quinson wrote:
> > Hello,
> >
> > Ce coup ci, j'aimerais autant eviter de me prendre les pieds dans le tapis,
> > alors je file ici mon differenciel avant d'agir.
> >
> > Aujourd'hui, on ne joue que dans templates/
> >
> > Le but du jeu est de placer un ptit '!' devant le nom des paquets contenant
> > des erreurs detectees par le systeme. Ce signe est un lien vers la page
> > listant les erreurs par paquet. Et y'a aussi un lien supplementaire sur
> > cette page depuis le nom du mainteneur vers la page listant les erreurs par
> > mainteneur.
>
> Quand j'ai écrit ces rapports d'erreur, j'ai été déçu du peu d'entrain
> que les responsables de paquets mettent à aller les voir. Du coup,
> plutôt que de leur courir après, j'ai préféré les obliger à faire les
> choses comme il faut avec po-debconf ;)
C'est clair qu'il est plus raisonable de corriger l'i18n que d'esperer que
les maint contournent les pieges de la l10n.
> En revanche, détecter les erreurs dans les traductions (codage invalide,
> champ Translator non renseigné, etc.) peut nous être utile.
C'est exactement mon objectif. Faire un outil pour les traducteurs, qui leur
permette de discuter avec qui de droit pour faire que leur travaux soient
bien integres. J'ai contacte tous les upstream fournissant des traductions
pour le code de langue "br" (breton) et contenant des traductions en
bresilien. Certains ont corrige, d'autres non. J'ai contacte tout ceux qui
difusent du fr_FR pour les ramener en fr. Il faut que je fasse de meme pour
les FR_CA et FR_BE.
Le probleme de Debian, c'est qu'on se recupere toutes les merdes du monde
des LL, et que faire corriger les problemes prend des plombes. Mais les
stats de Debian donne une assez bonne vue d'ensemble de l'etat de la l10n
dans tous les LL...
> Mais il faudrait repenser le format utilisé par les erreurs dans le
> fichier DB, il n'est pas du tout pratique. Il vaut mieux faire les
> modifications de format avant d'afficher de nouvelles erreurs, sinon
> on va encore tout casser à un moment.
Oui, c'est aussi mon avis. Un champ de champ comme PO: Du style
Errors:
(po|podebconf|templates)!(codelang|_)!type!details
Ca t'irait ?
> > C'est ok, je peux commiter ?
>
> Si tu veux, mais je pense que ça n'en vaut pas la peine, les développeurs
> n'iront pas voir ces pages.
Non, mais les traducteurs, peut etre. Alors j'ai commite tout cela, afin
d'eviter de me trainer des modifs en local me genant pour corriger les
eventuels problemes a venir.
Mais je suis d'accord pour repenser le format des erreurs dans la DB au plus
tot. Simplement, il faudra que ce soit toi qui commite la chose quand ca
sera fait, car tu es le seul a pouvoir effacer la DB invalidee par le
changement... A moins que les scripts fassent le distingo entre Errors:
actuel et un eventuel ERRORS: au nouveau format ?
Et je ne bougerais pas le ptit doigt tant qu'on se sera pas mis d'accord sur
le "bon" format ;)
Mt.
--
Il ne faut pas confondre « La société m'opprime » et « le système m'étrique ».
--- éphéméride du 19 juin
Reply to: