Re: [mythtvfr_traduction] Etat de la situation

[Nicolas Riendeau <knight@xxxxxxxxxxxx>]

Bonjour Gilles,

> > Elle devrait être minimes car le principe même de -fixes est de 
> > corriger des problèmes seulement et de ne pas rajouter de nouvelles 
> > fonctionnalités (donc, par conséquent, peu de chance d'avoir de 
> > nouveaux textes...)
>
> Pas si minime que cela , quand je regarde les nombres de versions sur 
> lesquelles il y a eu des modification
> je vous envoie la liste et un fichier .diff sur la release 0.22 pour que 
> vous vous rendiez compte

Si tu as une chance (et si ça ne gruge pas trop de ton temps...) de le(s) produire
j'aimerais bien voir ce(s) diff(s)... Ca va à l'encontre du principe de ne pas
ajouter de nouvelles fonctionnalités sur -fixes alors je serais vraiment curieux de
voir ce qui bouge autant...

> > Dans ce cas toutefois on devrait probablement garder les "obsoletes" 
> > je crois car il y a une possibilité qu'un message devienne obsolète 
> > durant la durée de vie d'une version.
> >
> > (Les obsolètes ou ne devrait probablement les effacer qu'à la sortie 
> > d'une nouvelle version j'ai l'impression...)
>
> Pour 0.21, c'est une très bonne idée mais il faut que je réfléchisses à 
> la meilleur façon de faire

Il faut dire qu'il faudrait commencer par vérifier si les obsolètes sont quand même
utilisées si on utilise une version qui y fait référence...

Si ce n'est pas le cas, ça ne donne rien de conserver les obsolètes.

> Je sais pas justement, Ookaze aurait pû nous dire. Je nous vois mal 
> revenir sur une version de 0.22 donc j'aurai tendance à supprimer. Mon 
> disque fait 250Go il n'est pas plein mais je n'ai pas de sauvegarde.
> Si je suis le rythme des modifications (des textes à traduire) sur le 
> svn de Mythtv.org, l'histotique de notre svn sera suffisant je pense. 
> Pour le moment je mets en attente

A cette grosseur ça pourrait être brûler sur un CD sans problème si tu veux t'en
faire une copie de sauvegarde et/ou libérer de l'espace sur ton disque. Toutefois je
nous (team) vois mal te demander d'engager des frais pour archiver notre travail (ou
du moins ce qui nous permet de faire notre travail)...

Si cela (prendre une copie de sauvegarde sur un ou des CD) s'avérerais nécessaire il 
faudrait bien trouver une manière de te dédommager...

> Donc si je résume pour trunk
>  - tu mets à disposition les patch pour modifier les themestrings.h et 
> les translate.pro si possible sur le svn pour que toute l'équipe de 
> traduction puisse en profiter et que je puisse caler mes scripts dessus

Pas de problème... En fait je les avait initialement fait pour toi... Je n'ai
commencé à m'en servir que par la suite étant donné que j'avais du temps de disponible...

>  - je modifie mes scripts pour qu'ils prennent en compte tes patch
>  - je fais un cron par semaine pour vérifier les modifications 
> officielles de traduction que je propose des corrections sans commiter 
> sur le svn

Si le nombre de modificatios est minime je suggère que tu commites tes propositions
directement et si le volume est plus élévé on verra comment on se répartira la tâche...

(Le fait de commiter génèrera une liste de propositions de toute façon...)

Toutefois si on décide de dire qu'une personnne travaille sur un module et une autre
sur un autre il faudrait préférablement que tu commites le fichier avec les nouvelles
entrées "unfinished".

> En principe il ne devrait pas y avoir d'obsolètes, les seuls qui 
> puissent apparaitre seraient issu du svn officiel. Je propose de ne pas 
> les garder pour des problèmes de lisibilité. Qu'en penses-tu ?

Je t'avoue que de mon côté j'ai commencé dernièrement à me servir de Qt Linguist et
il rend beaucoup plus facile la consultation des entrées complétées, "unfinished" et
si on le veux "obsolete" alors leur présence ne me dérange plus tellement. Si pour
toi c'est plus pratique et que tu penses qu'on ne perd pas de compatibilité avec une
version de MythTV que l'on voudrait supporté, supprime les...

> Pour le mythfrontend_fr.ts, je propose un traitement un peu spécifique: 
> compte tenu du fait que ce fichier contient les "location", à chaque 
> mise à jour, on va générer un énorme diff (voir le svn actuel ) qui va 
> comprendre toutes les mises à jour de "location" (dont on se fout sauf 
> pour le debug) et quelques modif réelles noyées dans la masse et donc 
> illisible. Je propose de joindre sur le svn un fichier diff sans les 
> "location". Ce sera plus facile pour les autres membres de consulter les 
> modifications sans pollution des "location".

En autant que cela ne cause pas de problème lorsque viendra le temps de merger avec
un fichier qui les contient (je ne crois pas que ça le ferait toutefois).

Il y aurait aussi la possiblité de se faire un petit script qui ne nous sort que les
unfinished (ou même un qui le fait et qui envoie l'info sur la liste de distribution).

Je t'avoue toutefois que Qt Linguist rend la recherche des entrées à travailler
beaucoup plus facile (tu peux classer selon ce critère) et si tu as le (bon) code 
source (et au bon endroit) je pense  qu'il te montre ce que tu veux traduire dans son 
contexte (c'est au moins une des raisons de la présence des "location")..

> Autre solution: on ne travaille plus "directe" sur le svn, on utilise 
> toujours un fichier intermédiere de proposition et on commite ensuite.. 
> Je crois qu'à la réflexion c'est plus simple

Si c'est pour de petits commits on s'alourdit la tâche je dirais...

L'avantage de soumettre les propositions dans le SVN et de recevoir les 
contres-propositions des autres membres du team est que l'on sait déjà qui va 
procéder à la mise à jour du fichier et qui va relancer les autres si on est en 
attente d'un statut sur un traduction.

Il faudrait seulement se trouver une manière que ce ne soit pas toujours la même 
personne qui fasse la proposition initiale, la mise à jour et le suivi.

> > Merci pour l'info! La prochaine fois si j'envoie des diffs par la 
> > liste de distribution je les compresserai (zip ou gz) pour m'assurer 
> > de leur intégrité...
>
> Je préfére les avoir sur le svn comme tu les as mis, si Snouf est d'accord.

Le problème avec les mettre sur le SVN c'est que même si on les supprime, ils vont 
rester présent dans les révisions antérieures à ce que je sache (à moins que SVN soit 
vraiment différent des autres outils du genre que j'ai utilisé).

Est-ce vraiment qqchose dont on désire conserver des versions antérieures?

Bon, je regarde ce qui nous restait à commiter comme modif...

Bonne journée,

Nicolas