Le volume de textes à traduire était beaucoup plus important et le
temps pour les traduire et les revalider dans le contexte pas assez
long.
On a aussi eu la mauvaise surprise qu'à la dernière minute la
traduction des textes affichés dans les thèmes est passée des thèmes
eux-mêmes au fichiers themestrings.h...
mouvement et livrer des versions correctes,
l'entretien des releases devient obsolète, surtout qu'il n'y a, comme
tu le dit, aucune modification sur les traductions entre 2 releases.
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
Mon script me prépare aussi les
répertoires mythtv et mythweb à mettre sur le tfp et intégrant les
fichiers .ts et .qm pour utilisation immédiate dans une version
packagée. Je pense qu'à terme je supprimerai la notion de version qui
n'a pas grand intérêt, sauf si vous me prouvez ne contraire.
Version dans quel sens, Trunk et Fixes ou autre chose?
Je parle ici des révisions 23406 par exemple, je pense qu'il ne faut
plus tenir compte de ces révisions et fournir une version valable pour
toute la branche release-0.22 par exemple
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
Voyez-vous une utilité à garder les anciens
historiques de 0.22 par exemple ? je peux stocker quelque part le liste
des versions modifiées et supprimer tout le reste ??? ou tout mettre
sur le site ????
A première vue non mais n'ayant pas vu exactement ce de quoi il s'agit
c'est difficile à dire...
Si tu penses que c'est utile je me range à ton opinion...
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
Si l'on introduit des themestrings.h
modifiés, je ne peux plus suivre les modif du svn de mythtv.org
Non, on peut les suivre en autant qu'avant de regénérer les traductions
on s'assure que nos themestrings.h sont à jour. Dans notre cas on
réapplique la ou les patch concernées.
C'est bien là mon interrogation, comme les themestrings ne sont pas à
jour, est-ce que l'on attend leurs mises à jour? ou est-ce que l'on
génère nos propres themestrings ?
Si on génère nos propres themestrings.h on a un meilleur contrôle sur
la date à laquelle on fera la traduction des nouveaux textes et on a
plus de temps pour valider nos traductions dans le contexte (ie en s'en
servant dans l'application).
Qui sait si lorsque ceux-ci seront mis à jour si on aura les
disponibilités nécesaire pour travaller sur la traduction?
Quelles conséquences cela pourra avoir lors
de la mise à jour officielle des themestrings ?
Certains textes que nous aurons traduit seront peut-être devenu
obsolètes alors que de nouveaux se seront ajoutés.
Lorsqu'on livrera pour la prochaine version on devrait enlever les
obsolètes avant de soumettre...
A première vue je ne vois pas d'autres conséquences...
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
- 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
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 ?
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".
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
Merci! ;-)
J'ai l'impression que mes collègues ne seraient guère surpris que
j'essaie de "déboguer/débugger/déverminer" (choisi celui que tu veux,
je ne sais pas lequels (lesquels) des termes sont en usage de votre
côté) des "bogues/bugs/vermine?" car c'est selon certain ma
spécialité...
(Que veux-tu, à force d'en faire on fini par savoir comment les
corriger... (-; (-; (-; )
Les scripts sur le svn fonctionnent,
certainement des caractères invisibles ou érronés.
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.
Gilles
|