| Re: [mythtvfr_traduction] Etat de la situation |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/mythtvfr_traduction Archives
]
Bonjour Gilles,
bonjour
avant de répondre dans le détail, je voudrais préciser certaine chose
- je ne suis pas développeur, ni même informaticien, je suis
J'étais au courant et ce parce que tu l'avais dit par le passé. Si tu ne l'avais pas
dit j'aurais pu facilement croire que tu est informaticien car tu me sembles savoir
ou tu t'en vas (ie de t'y connaître) lorsque tu parles d'informatique....
électronicien de formation et chef d'entreprise, je suis tombé dans la
Ça je t'avoue que je l'avais compris lorsque j'ai vu ta "signature corporative" au
bas de certains de tes courriels... (-; (-;
J'ai aussi l'impression que c'est en partie pour cela que tu as parler de domotique
lorsqu'on a abordé les "évènements" dans MythTV...
De mon côté j'ai quelques connaissances de bases en électronique (je connais de
manière générale l'utilisation des résistances, diodes, condensateurs, etc...) mais
seulement les principes de base. A mon grand désarroi du côté soudure je suis un
spécialiste des soudures froides... )-;
marmite linux il y a 5/6 ans en même temps que je découvrais Mythtv..
De mon côté ça fait moins longtemps mais j'aurais de la difficulté à te donner une
date.... Il y a 5-6 ans je m'intéressait plus aux DNS et serveurs de courrier...
donc ne vous étonnez pas si je pose certaine question idiote, je ne
Je ne l'ai jamais pensé et si je t'ai donné cet impression ce n'était pas voulu et je
m'en excuse...
maitrise aucun langage de programmation même si j'ai fait des choses en
bash.
Considérant la complexité de certains circuits électroniques et la programmation de
script sous bash je ne crois pas que tu aurais beaocoup de difficulté à travailler
sous un autre langage.
- je ne revendique pas le leadership, que celui tourne est tout à fait
sain mais je souhaite simplement que l'on tienne compte de l'existant
Encore une fois, si j'ai semblé suggéré que tu le fesais ce n'étais pas le cas et je
m'en excuse...
- j'utilise les scripts d'Ookaze (merci à lui) qui me simplifie la vie
dans le suivi du svn de mythtv.org
Que font ses scripts
maj_mythtv.sh : un simple script qui récupère la dernière version de
MythTV provenant du SVN.
01_download_mythtv.sh : récupère une version de SVN de MythTV passée
en paramètre, et prépare une version de traduction. Crée deux
répertoires,
orig et trad, contenant les versions de SVN.
02_prepare_trad.sh : récupère la traduction de MythTV-FR, et la place
dans un répertoire fr sous trad/. Met à jour la traduction MythTV-FR
avec les derniers changements opérés dans la version SVN de MythTV
récupérée.
03_pousse_trad.sh : place notre traduction et génère les fichiers ..qm
et XML. C'est à ce moment qu'il faut surveiller toute erreur remontant
sur le traitement des fichiers _fr.ts .
04_recup_trad.sh : met à jour nos fichiers .ts dans notre répertoire
de travail fr/ , une fois que l'on a vérifié qu'il n'y avait pas de
problème de génération.
05_livre_trad.sh : pour faire un checkin éventuel de la traduction
vers MythTV-FR
06_cree_tarball.sh : crée des archives à partir des versions traduites.
07_diff_pour_upstream.sh : création de diff pour le SVN MythTV, placés
dans un répertoire diff
J'en ai ajouté 3 autres que j'ai trouvé utile
02_compare.sh : compare 2 indices (exemple 23406 et 23446) d'une même
version et génère un .diff contenant les + et les -
05_prepare_ftp.sh : copie les fichiers .ts et .qm dans le répertoire ftp
et respectant l'arborescence de Mythtv packagé
00_general.sh : automatise les scrcipts 01_download_mythtv.sh,
02_prepare_trad.sh, 02_compare.sh pour identifier les versions modifiées
et les modifications apportées
OK, merci pour les explications...
Je crois qu'il faut faire le point car ça a tendance à partir dans
tous les sens.
Il faudrait décider ce sur quoi on désire mettre de l'effort je dirais...
Si les prochaines versions de MythTV sont livrées de manière aussi
rapprochées entre elles que les devs nous le promette, il faudrait
voir si cela vaut la peine de maintenir une version séparée pour
-fixes je dirais...
-Fixes par défimition ne vois habituellement pas de nouvelles
fonctionnalité se rajouter vs la version initiale alors le nombre de
nouveaux textes à traduire devrait être minime alors que Trunk lui
bouge beacoup plus...
il faut bien évidemment porter l'effort sur le trunk mais la première et
dernière expérience, nous a fait livrer une version qui nécessitait
beaucoup de corrections. Si effectivement nous savons anticiper le
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...)
Pour 0.22, j'ai un script qui tourne pour recherche les différences
entre 2 versions de mythtv.org. Je peux le faire tourner une fois par
semaine pour vérification et correction, puis intégration dans le svn
mythtv-fr branches-release-0.22.
Je ne suis pas sûr que l'on soit gagnant de l'exécuter si souvent....
Je crois avoir vu plusieurs commits qui n'avait aucun nouveaux textes
et uniquement des changements de ligne...
Ca ne donne pas grand chose de suivre les modifications de no de ligne
du code source de MythTV...
Le script 00_general est là pour cela, il vérifie s'il y a des nouveaux
textes à traduire en utilisant le contenu des sources (themestrings.h,
translate.pro, ....). les dernières modifications que j'ai faite sur
release-0.22 provienne de ce processus. Je peux le "cronner", si il n'y
a pas de modif, ça prend 15 à 20 minutes. Je pense que l'on peux le
conserver pour le moment.
OK
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...)
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...
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...
Je n'ai jamais analyser les scripts pour voir comment ceux-ci
fonctionnait mais si j'aurais à le faire manuellement essentiellement
ce que je ferais serait comme suit:
- Faire un checkout du trunk.
- Mettre les themestrings.h à jour (appliquer les patchs). Si elles ne
s'applique par correctement on arrête ici car les themestrings.h ont
été mis à jour par les devs de MythTV (ou la patch s'est corrompue de
quelque manière...).
- Recopier nos traductions actuelles sur le contenu du checkout pour
ne pas perdre les mises à jour qu'on aurait pu faire par rapport à ce
que le SVN de MythTV contient...
- Rouler lupdate (ou lupdate-qt4 avec certaines distributions) et
build_translations.pl (sp?).
il travaille comme cela et comme tu l'as compris il supprime les
obsolete d'ou mes derniers égarements
Bah, ce n'est pas comme si on avait perdu qqchose j'avais encore les dernières
versions ici et on les avait encore aussi dans l'historique de SVN...
D'un autre coté on travaille en avance de phase, sur le principe il
faudrait gérer 2 versions avec et sans les nouveaux themestrings.h
mais en a-t-on les moyens?
Sur lequel on travaille ?
Pourquoi faire deux versions? Est-ce pour conserver les textes
obsolètes ou pour une autre raison?
Pour être en cohérence avec le svn de Mythtv.org
Si tu veux dire pour la version téléchargeable du site je ne crois pas que cela soit
un problème d'avoir plus de textes de traduit que l'original. Le seul problème je
crois est qu'on ne devrait probablement supprimer les obsolètes que lors de la
soumission finale avant la sortie d'un nouvelle version...
Toutefois ici j'assume que les obsolètes sont utilisées si l'application veux s'en
servir (comme dans le cas d'un vieille version avec un fichier qm plus récent),
est-ce vraiment le cas ou est-ce que les obsolètes ne sont pas utilisées même si
elles sont présentes (comme les unfinished je crois...).
Ne serait-il pas mieux de proposer une méthode de génération des
themestrings.h qui permette à tous les traducteurs de bosser ?
Je me demande dans quel sens tu proposes cela...
Veuz-tu dire tous les traducteurs et/ou les teams de traductions
(auquel cas il faudrait que ce soit fait le le véritable SVN de
MythTV) ou veux-tu dire dans notre cas spécifique.
Tous les teams attendent les mises à jour des themestrings ; Pourquoi ?
si tu peux les générer pourquoi ne pas les mettre à disposition de tous
les teams et/ou fournir le process de génération ??
J'ai l'impression qu'on se mettrait les devs à dos si on essaie de se substituer à
ceux-ci...
Il y a aussi une autre chose... Je peux te dire qu'actuellement, selon les tests
d'intégrité que j'ai fait, mes themestrings.h sont conforme à ceux que qu'ils
génèreraient mais il est possible que du jour au lendemain les devs changeraient
quelque chose dans ce traitement ce qui renderait ceux-ci non conforme à ceux qu'ils
génèrerait.
Ce qu'il faudrait serait de sensibiliser les devs (ou le dev responsable des
traductions...) à essayer de maintenir ces fichiers plus à jour...
J'ai bien essayé mais avec peu de résultat...
réf: http://www.gossamer-threads.com/lists/mythtv/dev/418305
On ne peut guère blâmer Robert McNamara car comme il le disait ce n'était pas "his
area of expertise"...
Je commence à me douter d'où provient le problème toutefois... Le dev qui est supposé
s'occuper des traductions semble avoir peu de temps de disponible et je ne suis même
pas sûr si c'est lui qui les a mis à jour la dernière fois.
(Tu n'as qu'à regarder à qui était assigné les billet de nos soumissions de
traduction et qui les a appliquées... Ce n'est jamais celui à qui c'est assigné qui
les applique je crois... Soit dit en passant, le dev qui les a appliqué (celui qui je
crois nous est sympatique) nous a reconnu comme étant un team dans au moins un de ses
commits...))
J'ai l'impression que s'il serait plus disponible on ne serait pas toujours pris à la
dernière minute avec autant de textes à traduire et valider... Mais que peut-on y
faire, pas grand chose malheureusement...
Gilles, lorsque je travaille sur MythTV j'essaie d'y mettre presque
autant de rigueur que lorsque je fais mon travail
(analyste-programmeur et ce depuis plus de 15 ans).** Etant donné que
je sais que l'on triche en faisant nous même nos themestrings.h je
fais doublement attention car je ne veux pas risquer de détruire du
travail que nous avons déjà fait...
Je ne doute pas de tes compétences, tu nous en déjà donné un aperçu et
au pire si tu fais une erreur il faudra faire un peu plus de boulot
lorsque les themestrings.h officiels
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é...
Bonne journée,
Nicolas