Re: [mythtvfr_traduction] Etat de la situation

[ Thread Index | Date Index | More lists.tuxfamily.org/mythtvfr_traduction Archives ]




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


Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/