| Re: [mythtvfr_traduction] Etat de la situation |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/mythtvfr_traduction Archives
]
Nicolas Riendeau a écrit :
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...
OK je te fais ça
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..
oups je parlais de 0.22 biensûr, je pense comme toi, si on met les
obsolétes dans les fichiers de traduction ils ne seront pas utilisé car
pas appelé mais si quelqu'un utilise une version plus ancienne, il aura
ces traductions
Du coup je peux laisser un seul fichier sur le ftp pour mettre à jour sa
version, est-ce une bonne idée? à voir l'usage , peut être que pour
faire simple, je resterai comme aujourd'hui ou alors je gère une version
sur svn
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....
c'est pas le problème, il y a plein d'espace dans les nuages (pour
parler moderne). Je ne trouve pas de raison à garder, je ne vois pas
pourquoi on utiliserai une version du passé ou en quoi l'historique peut
nous être utile ?
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.....
J'ai modifié les scripts qui utilisent tes fichiers de diff sur le svn.
Si tu les maintiens à jour, il ne devrait pas y avoir de problème. Au
passage, il serait peut-être bien que tu les utilises aussi
- 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".
OK je finis de valider mes scripts puis on reprend comme avant. Si j'ai
le temps je fais les modif en direct sur le svn sinon je mets les
"unfinished" et si le nbre de modif est trop important je fais un
fichier séparé.
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...
J'utilise aussi depuis peu QT Linguist (génial comme outil) donc on
garde tout et on avisera plus tard (il faut que je vérifie si Qt
Linguist conserve les obsolétes)
Les scripts conservent maintenant les obsolètes.
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).
c'est fait, à chaque fois qu'une version est modifiée, mes scripts
génèrent un .diff par rapport à l'ancienne version, je vais les envoyer
sur la liste pendant quelque temps, vous me direz si c'est utile.
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.
OK
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.
je me suis proposer pour faire le suivi des modifs par rapport au svn de
mythtv.org. Mais tout le monde peut le faire en utilisant les scripts,
c'est extremenent plus simple grace à eux.
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?
Ces fichiers ne sont utilisés que pour le trunk, pour les autres
versions (release) j'utilise les fichiers officiels fournis avec la version
donc non on ne garde pas les versions antérieures mais juste une version
de travail pour compenser les themestrings.h non à jour.
Dès que les themestrings sont à jour sur mythtv.org, on peut supprimer
les notres et travailler avec les leurs ou les deux. Au pire
on aura quelques obsolètes qu'il faudra supprimer lors du commit montant.
Bonne lecture
Gilles
PS si tu veux utiliser mes scripts, fais moi le savoir que je fasse une
notice explicative pour une mise en place rapide et quelques
explications sur le fonctionnement. je pense que cet après midi, ils
seront dispo et validés sur le ftp