Bug 247359

*** Bug 248406 has been marked as a duplicate of this bug. ***

Bon les gars, c'est super mais vraiment ca ne sert a rien de me remonter
un buzilla a chaque fois. Ca va me faire perdre beaucoup de temps. Et c'est
pas ca qui va me faire mettre a jours non plus, ca depends des releases !
Je met a jours au moins chaque fois que je fais une release ...

  Donc merci d'arreter le bugzilla automatique, vraiment !

Daniel

Même si le sujet et la description sont identiques dans ces rapports de bogue, 
en aucun cas il ne s'agit de quelque chose d'automatique (je ne sais 
d'ailleurs pas comment on pourrait faire). Par contre, en effet, il sont 
systématiques.
Je pense qu'il nous faut plus de temps pour les ouvrir que de temps pour toi à 
les fermer.
Ils ne sont pas fait pour forcer la sortie d'une nouvelle version du logiciel, 
mais juste pour être certain que le mainteneur n'oubliera pas d'incorporer la 
dernière version française en date avant de produire son archive finale.
C'est à la sortie de F7 que nous avons décidé d'agir ainsi.
En effet, malgré nos efforts depuis novembre 2006 pour tenir à jour la version 
francophone de l'ensemble des outils Fedora (et bien sûr RedHat), F7 est 
sortie avec une version francophone INCOMPLÈTE alors que tout était disponible 
sur Elvis !
Et ce, malgré le fait que certains développeurs n'aient pas respecté le gel 
des chaînes (Strings freeze)...
Pour nous traducteurs, ce n'est pas acceptable, c'est clairement afficher un 
grand mépris pour notre travail.

Nous avons donc décidé de mettre en place une nouvelle procédure afin de 
s'assurer :
- de la meilleure traduction possible
- que cette traduction soit disponible dans le premier paquet suivant 
l'ouverture de bogue

- Un coordinateur remarque qu'un fichier fr.po a été mis à jour par le 
développeur, il le signale sur la liste francophone pour prévenir le 
mainteneur de la version française.
- Le mainteneur voit cet avertissement, annonce son intention de mettre à jour
- Le mainteneur soumet à la liste ces propositions
- Si quelqu'un sur la liste a des remarques à faire, il les fait, la liste en 
discute
- Le mainteneur accepte ou non les remarques et soumet une nouvelle 
proposition
- Au bout d'un temps raisonnable sans commentaire, le mainteneur commite ces 
modifications sur le cvs, ouvre un bogue sur le module
- Quand upstream referme le bogue indiquant qu'un nouveau paquet existe 
intégrant le fr.po, le mainteneur le signale sur la liste.

Voici un exemple de ces discussions à propos de libvirt 
https://www.redhat.com/mailman/private/fedora-trans-fr/2007-June/msg00151.html
qui continue ici
https://www.redhat.com/mailman/private/fedora-trans-fr/2007-July/msg00000.html
à condition que tu sois inscrit à la liste car apparemment, les archives sont 
privées

Je tiens à préciser que la plupart des développeurs a accepté notre façon 
d'opérer, même si elle est un peu contraignante pour eux. Soit certain qu'elle 
est beaucoup plus pour nous !!!!
Mais nous avons fait ce choix pour être certain de retrouver notre travail 
pris en compte. Un choix librement inspiré de la méthode de travail de 
l'équipe francophone debian.

Maintenant, si tu ne veux pas que nous ouvrons ces rapports de bogues 
concernant les paquets que tu maintiens, dis-le moi, et je devrais voir 
comment gérer cette première exception.
Je te rassure, nous avons remarqué que tu n'avais pas répondu à nos ouvertures 
de bogue, d'ailleurs, on ne savait pas comment gérer ce "problème". Est-il 
utile d'en ouvrir de nouveaux ? Mais si on ne le fait pas, quid de notre 
procédure de qualité ?
Tiens d'ailleurs, et celui-là 
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=247904 ?

Un rapport de bogue est un rapport de bogue. "nous avous mis a jour fr.po"
n'est PAS un rapport de bogue. Si je compte bien vous m'avez soumis ca 3
fois en un mois, avec 3 fois exactement la meme chose. Il y a 74 .po
dans mon CVS upstream. Si tout le monde fait pareil ca fait plus de deux cent
bugzilla par mois. Et je dis non, stop, ca n'est pas un process correct,
ca ne scale pas on ne peux pas fonctionner comme ca. Ca me semble du simple
bon sens, independemment de tout jugement sur la qualite du travail lui meme.
Ca ne me semble pas une methode d'interface correcte.

Daniel

*** Bug 247904 has been marked as a duplicate of this bug. ***

Alors proposes-moi une autre méthode qui soit applicable à l'ensemble des 
fichiers fr.po qu'on gère, une solution unique...

Vous partez de la conclusion que vous ne pouvez pas faire confiance 
packager fedora et que donc le seul moyen c'est de lui "rapeller" de
mettre a jour a chaque fois. Mais en regle general fedora repackage,
et n'est pas l'upstream, et le seul moyen vraiment fiable c'est de faire
remonter les changements a la source. Ca peut pas se faire en bombardant
dans un bugzilla qui n'est pas forcement lie. C'est un process qui prend
du temps, piquer une crise parce que vous aviez fait la localisation mais
qu'elle n'etait pas integree a temps me semble exagere, parce que ce
n'est pas juste un probleme fedora, je comprends la frustration, il faut
aussi comprendre que les choses chez nous aussi sont complexe.
Exemple j'ai eu une contribution upstream sur le ja.po parce que
Fujitsu est un contributeur du projet. Et naturellement leur changements
ne correspondaient pas a ceux du team de translation fedora Japonais.
Oui des fois cela prends du temps. Non c'est pas juste parce qu'on a un
poil dans la main, qu'on a oublie ou qu'on ne donne pas d'importance a
votre travail, mais simplement tout n'est pas instantane, et des fois
c'est complexe. Envoyer un message sans arret au packager n'est pas 
correct non plus, je n'ai pas de moyen general, excepte trouver les packages
ou la mise a jour n'est pas faites *lors des release upstream* et voir
pourquoi ca ne propage pas. Mais creer des bugzilla systematiquement
n'est pas productif, et en fait ne me semble pas correct,

Daniel

P.S.: je ne considere pas que Fedora est l'upstream pour libvirt. Le package
      est maintenu independemment, j'utilise bugzilla.redhat.com car c'est le
      plus pratique et je n'avais pas tellement de solutions possibles.
P.S.2: vouloir generaliser a tous les packages mne semble vraiment pas 
       realiste, localiser juste fedora n'est pas logique, il faut localiser
       upstream
 

http://i18n.redhat.com/cgi-bin/i18n-status?page=status&branch=HEAD&locale=fr&essential=0
Bien que cette page commence à devenir obsolète avec la mise en place du 
Fedora Localization Project, elle est la base de notre travail puisque y sont 
listés tous les modules à traduire. Ce sont tous des outils Fedora (ou Red 
Hat), ce sont eux que nous traduisons dans le cadre de Fedora.
Aussi, quand on ouvre un bogue pour un module, c'est bien à upstream que l'on 
s'attend qu'il soit affecté, upstream qui dans ce cas est aussi le packageur 
du paquet.
On ne localise pas Fedora, on localise les outils Fedora.
Si libvirt n'est pas un module Fedora, alors que fait-il sur la page des 
outils fedora à traduire ?