Fwd: Launchpad 1.2.5: code branch reviews and translations search

[Milan Bouchet-Valat]

Le dimanche 01 juin 2008 à 12:04 +0200, Bruno Patri a écrit :
> > Mais comme toujours, je sais que ça pose problème
> > puisque à la prochaine mise à jour des traductions, elle ne sera pas
> > remplacée. Alors je m'interroge: est-ce que les mises à jour des
> > traductions faites par l'équipe de GNOME-fr seront répercutées sur Hardy
> > automatiquement ? Et ce qui en découle : est-ce que ça vaut le coup de
> > corriger ça à la main ?
> 
> 
> Non elle ne seront pas répercutées puisque les chaînes modifiées sur Launchpad 
> deviennent *prioritaires*. Si cela a été corrigé en amont il faut revenir à 
> la traduction de fgnome-fr en utilisant les filtres et en cochant "packaged" 
> pour les chaines concernées.
Désolé, je n'ai sans doute pas été très clair. Je sais bien que si on
modifie une traduction, elle ne sera plus mise à jour ensuite. Mais la
question était plutôt : si je ne la modifie pas, est-ce que les mises à
jour de F-Spot (par exemple) via hardy-updates mettront aussi à jour les
traductions ? Les chaînes en question ont été corrigées chez GNOME
récemment, mais je ne sais pas si un jour où l'autre elles aboutiront
automatiquement dans Hardy.

D'où la seconde question : si la mise à jour arrive dans Hardy (pour
Intrepid la question ne se pose pas puisqu'elle arrivera forcément), il
n'est pas nécessaire de le corriger à la main. Sinon ça peut être utile.

Mais c'est surtout une question de politique à suivre : est-ce qu'on
corrige manuellement des chaînes quand elles sont vraiment erronées,
quitte à les remettre à zéro pour Intrepid, ou est-ce qu'on ne touche à
rien ? Je pencherais plutôt pour la première solution.


> > Le problème c'est que Hardy étant une LTS, il est utile de corriger
> les
> > problèmes histoire que pendant 3 ans les utilisateurs n'en souffrent
> > pas. Mais pour l'instant Hardy est la version "trunk" d'où Intrepid
> > partira, donc on ne corrige pas seulement dans Hardy (version
> publiées
> > subissant des correctifs secondaires, comme ce qui se fait avec les
> > paquets logiciels dans hard-updates) mais aussi dans le processus de
> > développement.
> >
> > Encore une fois, peut-être une autre fonction serait-elle utile : celle
> > de décréter automatiquement que les traductions pour une version
> > "frozen" ne se répercutent pas dans les suivantes - ce qui équivaut à un
> > "fork" des traductions lors de la publication d'une version. Qu'en
> > dites-vous ?
> 
> Ce qui serait utile (et déjà demandé) c'est un bouton/case à cocher qui 
> permette de rétablir d'un seul coup les traductions effectuées en amont pour 
> tout le paquet concerné.
Le problème avec cette solution, c'est qu'il faut se taper la liste de
tous les paquets à chaque nouvelles version. Au contraire, la logique de
développement nous inciterait à considérer que :
- à chaque version on se remet en concordance parfaite avec les
traductions amont
- pendant toute la durée de la prise en charge d'une version publiée, on
peut être amenés à corriger des chaînes ponctuellement

Cette approche correspond à ce que font les développeurs en "branchant"
à part une version majeure, laquelle ne recevra plus que des corrections
mineures, tandis que l'autre branche se base sur le code original pour
continuer à avancer.

Est-ce que ça fait sens ?