plop vertimus n'évolue pas, pourtant il en a cruellement besoin. Voici des fonctionnalités que je juge utiles : - statut 'à revoir' - le lien vers la version CVS est toujours désynchro. autant pointer vers viewcvs directement - afficher la date de commit de la version CVS - modération des abonnement - notification par email.
par exemple epiphany aurait besoin d'être retravailler, et c'est impossible de le signaler :
http://tmp.vuntz.net/l10n/module.php?id=238
merci.
Afficher les réponses par date
- notification par email.
Je plussoie. Qui s'occupe du developpement de vertimus, j'ai un peu cherché mais je n'ai pas trouvé.
Pour Epiphany j'ai inclus les modifications judicieuses de Baptiste et je fais une relecture actuellement.
Merci :)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Benoît Dejean a écrit :
- le lien vers la version CVS est toujours désynchro. autant pointer
vers viewcvs directement
Non, pas un lien sur le viewcvs, mais sur http://l10n-status.gnome.org/
Sur viewcvs, les fichiers po ne sont pas à jour vis à vis du code source de l'appli alors que sur http://l10n-status.gnome.org/ les fichier po sont mis à jour 2 fois par jour.
Librement, - -- Christophe Merlet (RedFox)
Ok le boulot est terminé pour Epiphany gràce à vous deux sur le channel #gnome-fr. Comme indiqué sur Vertimus le bug avait déjà été corrigé, je vais envoyé un mail au rapporteur sous peu. Théoriquement il n'y a strictement aucune erreur, et si tel est le cas je veux bien me faire fouetter !
Merci :) À demain
(/me vient de me souvenir qu'il avait un rdv de bonne heure demain !)
Donc Vertimus utilise le bon lien.
Le dimanche 14 mai 2006 à 00:25 +0200, Christophe Merlet (RedFox) a écrit :
Benoît Dejean a écrit :
- le lien vers la version CVS est toujours désynchro. autant pointer
vers viewcvs directement
Non, pas un lien sur le viewcvs, mais sur http://l10n-status.gnome.org/
Sur viewcvs, les fichiers po ne sont pas à jour vis à vis du code source de l'appli alors que sur http://l10n-status.gnome.org/ les fichier po sont mis à jour 2 fois par jour.
Librement,
Le dimanche 14 mai 2006 à 00:09 +0200, Benoît Dejean a écrit :
plop vertimus n'évolue pas, pourtant il en a cruellement besoin. Voici des fonctionnalités que je juge utiles :
- statut 'à revoir'
et qui affiche la tradu d'une couleur spéciale.
il devient très urgent d'avoir ce statut. si je dois envoyer un mail à chaque fois que quelque chose ne va pas dans vertimus, autant ne pas utiliser vertimus. merci.
Le dimanche 14 mai 2006 à 12:25 +0200, Benoît Dejean a écrit :
Le dimanche 14 mai 2006 à 00:09 +0200, Benoît Dejean a écrit :
plop vertimus n'évolue pas, pourtant il en a cruellement besoin. Voici des fonctionnalités que je juge utiles :
- statut 'à revoir'
et qui affiche la tradu d'une couleur spéciale.
il devient très urgent d'avoir ce statut. si je dois envoyer un mail à chaque fois que quelque chose ne va pas dans vertimus, autant ne pas utiliser vertimus.
Si vertimus envoie des mails à chaque changement, en particulier au moment des ajouts de commentaires, ça règle une grosse partie du pb non?
Christophe
Le dimanche 14 mai 2006 à 12:37 +0200, Christophe Fergeau a écrit :
Si vertimus envoie des mails à chaque changement, en particulier au moment des ajouts de commentaires, ça règle une grosse partie du pb non?
non. Quand on débarque, on ne va pas lire les 3 derniers mois de la ML pour savoir si le package marqué TRADUIT 100% a effectivement un commentaire dessus. il faut que ça soit accrocheur. Si on suit ton raisonnement, on peut carrément virer les états. pourtant, ce que nous faisons tous, c'est ouvrir vertimus et 'voyons ce qui est en 'TRADUIT' ou 'RELU'' ... on se voit mal fouiller une ML pour savoir quoi en est ou.
par ailleurs, pour la notification par email, il faudrait une ML dédiée et/ou un RSS.
Le dimanche 14 mai 2006 à 12:42 +0200, Benoît Dejean a écrit :
Le dimanche 14 mai 2006 à 12:37 +0200, Christophe Fergeau a écrit :
Si vertimus envoie des mails à chaque changement, en particulier au moment des ajouts de commentaires, ça règle une grosse partie du pb non?
non. Quand on débarque, on ne va pas lire les 3 derniers mois de la ML pour savoir si le package marqué TRADUIT 100% a effectivement un commentaire dessus. il faut que ça soit accrocheur. Si on suit ton raisonnement, on peut carrément virer les états. pourtant, ce que nous faisons tous, c'est ouvrir vertimus et 'voyons ce qui est en 'TRADUIT' ou 'RELU'' ... on se voit mal fouiller une ML pour savoir quoi en est ou.
Je suis pas sûr à 100% de comprendre ce que tu as en tête. Si tu mets le A REVOIR en réponse à un RELU ou TRADUIT, j'ose espérer que la dernière personne qui s'est occupée de la trad la gérera rapidement, et donc l'envoi d'un mail ça permet de s'en assurer encore plus. Sinon, je vois pas trop quand tu veux l'utiliser ? Quand un truc est dans le CVS et qu'il est tout pourri ?
Christophe
Le dimanche 14 mai 2006 à 17:23 +0200, Christophe Fergeau a écrit :
Sinon, je vois pas trop quand tu veux l'utiliser ? Quand un truc est dans le CVS et qu'il est tout pourri ?
dès qu'un doit être travailler.
On 5/14/06, Benoît Dejean benoit@placenet.org wrote:
Le dimanche 14 mai 2006 à 17:23 +0200, Christophe Fergeau a écrit :
Sinon, je vois pas trop quand tu veux l'utiliser ? Quand un truc est dans le CVS et qu'il est tout pourri ?
Perso je trouve ça utile : exemple tu es dans la page d'accueil des paquets et tu vois un "À revoir" dans la liste et hop tu fonces pour dépatouiller le schmilblick.
Voici comment je vois le A REVOIR :
1 - Toto - TRADUCTION EN COURS 2 - Toto - TRADUIT
3 - Tutu - RELECTURE EN COURS Pleins de corrections éventuelles ou bien tellement mauvais qu'il décide de repartir du fichier original et dans cas effectue un RELU (avec commentaire incendiaire) puis TRADUCTION EN COURS 4 - Tutu - RELU
Cas d'une seconde relecture par Titi 3bis - Titi - RELECTURE EN COURS Ptite typo ! 4bis - Titi - RELU
5 - Titi - A COMMITER
6 - Benoit - COMMIT EN COURS 7 - Benoit - A REVOIR Parce que pas du tout content du fichier, ne doit pas arriver normalement !
8 - Titi - RELECTURE EN COURS 9 - Titi - RELU
10 - Titi - A COMMITER
11 - Benoit - COMMIT EN COURS 12 - Benoit - COMMITE
Attente mise à jour des stats
13 - Benoit - STATS A JOUR Et hop, l'historique disparait.
Est-ce que cela convient ? Perso, je n'aime pas trop l'etat COMMENTAIRE (c'etait pour faire plaisir à Vuntz :) car je pense que les commentaires peuvent se gérer par une étape ainsi les non relecteurs qui souhaitent relire peuvent enchainer les cycles de TRADUCTION EN COURS/TRADUIT (en attendant des relecteurs un jour !) plutot que de faire des commentaires avec fichier joint.
Si vous faites vos relectures par COMMENTAIRE, vous ne reservez pas le module ! Risque de conflits.
Stéphane
Le dimanche 14 mai 2006 à 17:53 +0200, Bob Mauchin a écrit :
On 5/14/06, Benoît Dejean benoit@placenet.org wrote:
Le dimanche 14 mai 2006 à 17:23 +0200, Christophe Fergeau a écrit :
Sinon, je vois pas trop quand tu veux l'utiliser ? Quand un truc est dans le CVS et qu'il est tout pourri ?
Perso je trouve ça utile : exemple tu es dans la page d'accueil des paquets et tu vois un "À revoir" dans la liste et hop tu fonces pour dépatouiller le schmilblick.
Gnomefr mailing list Gnomefr@traduc.org http://www.traduc.org/mailman/listinfo/gnomefr
Le dimanche 14 mai 2006 à 23:15 +0200, Stéphane Raimbault a écrit :
11 - Benoit - COMMIT EN COURS 12 - Benoit - COMMITE
Attente mise à jour des stats
13 - Benoit - STATS A JOUR Et hop, l'historique disparait.
Le passage "STATS A JOUR" est fait manuellement par Benoît ? D'un point de vue extérieur, ça donne une impression bizarre, par exemple pour evince hier, la trad était marquée comme COMMITTEE, les stats n'étaient pas à jour (98% de traduit), puis soudainement tout l'historique de la trad a disparu, la trad était toujours à 98% de traduit, et finalement ce matin, les stats ont été mises à jour, et la trad est à 100%. À mon avis, il faudrait que l'historique soit conservé d'une façon ou d'une autre, ça peut toujours être utile (par ex pour se faire une idée si un fichier a été relu des milliers de fois, ou bien s'il a été relu une unique fois)
Christophe
J'ai un emploi du temps de folie (pas de ralentissement prévu à court terme) mais je vais voir ce que je peux faire en fin d'après midi.
Avec en priorité : statut 'à revoir' + couleur, OK ? Puis le lien http://l10n-status.gnome.org/
Quels sont les états qu'il faut notifier sur la ml (aujourd'hui seulement 'A COMMITER') ?
Stéphane
Le dimanche 14 mai 2006 à 00:09 +0200, Benoît Dejean a écrit :
plop vertimus n'évolue pas, pourtant il en a cruellement besoin. Voici des fonctionnalités que je juge utiles :
- statut 'à revoir'
- le lien vers la version CVS est toujours désynchro. autant pointer
vers viewcvs directement
- afficher la date de commit de la version CVS
- modération des abonnement
- notification par email.
par exemple epiphany aurait besoin d'être retravailler, et c'est impossible de le signaler :
http://tmp.vuntz.net/l10n/module.php?id=238
merci. _______________________________________________ Gnomefr mailing list Gnomefr@traduc.org http://www.traduc.org/mailman/listinfo/gnomefr
Bonjour
Est-il techniquement possible d'intégrer une fonction de diff sur vertimus afin de connaitre rapidement les modifications lors de relecture par exemple ?
Merci.
Bob Mauchin.
Le dimanche 14 mai 2006 à 00:09 +0200, Benoît Dejean a écrit :
plop vertimus n'évolue pas, pourtant il en a cruellement besoin. Voici des fonctionnalités que je juge utiles :
- statut 'à revoir'
n'y a-t-il vraiment personne pour faire cette modification rapidement ? j'imagine qu'elle est très minime. ça devient vraiment bloquant à ce point.
Merci.
J'ai envoyé un mail concernant le fonctionnement de l'état A REVOIR et sa position dans le cycle mais tu n'as pas répondu : http://www.traduc.org/pipermail/gnomefr/2006-May/001276.html
Le respect du cycle est important pour que l'état du module reste cohérent (cf mail perso).
En attendant ta réponse, je mets la structure en place...
Le samedi 20 mai 2006 à 22:49 +0200, Benoît Dejean a écrit :
Le dimanche 14 mai 2006 à 00:09 +0200, Benoît Dejean a écrit :
plop vertimus n'évolue pas, pourtant il en a cruellement besoin. Voici des fonctionnalités que je juge utiles :
- statut 'à revoir'
n'y a-t-il vraiment personne pour faire cette modification rapidement ? j'imagine qu'elle est très minime. ça devient vraiment bloquant à ce point.
Merci.
Gnomefr mailing list Gnomefr@traduc.org http://www.traduc.org/mailman/listinfo/gnomefr
Le dimanche 21 mai 2006 à 09:50 +0200, Stéphane Raimbault a écrit :
J'ai envoyé un mail concernant le fonctionnement de l'état A REVOIR et sa position dans le cycle mais tu n'as pas répondu : http://www.traduc.org/pipermail/gnomefr/2006-May/001276.html
Le respect du cycle est important pour que l'état du module reste cohérent (cf mail perso).
En attendant ta réponse, je mets la structure en place...
et bien je te réponds clairement : le cycle, il faut pouvoir le casser. Seulement : - je ne vais pas me mettre à trad en cours ou relecture en cours sur chaque module. - si je passe un module à - ou traduit et que ce module est à 100%, personne n'ira voir.
Après si ta question est « c'est quoi la place de « a revoir » dans le cycle ? » et bien ça peut être n'importe où. Ça n'est pas un état intermédiaire entre deux autres. Je voudrais pouvoir marquer à revoir une mauvaise traduction mais aussi une relecture incomplète ou bien une traduction commitée mais qui aurait besoin de travail. Donc non, il n'y a pas de cycle de travail. « à revoir » c'est le « aller en prison » de vertimus.
OK ?
n'y a-t-il vraiment personne pour faire cette modification rapidement ? j'imagine qu'elle est très minime. ça devient vraiment bloquant à ce point.
Tant qu'on est à parler de Vertimus, un autre point qui me dérange, c'est la disparition de tout l'historique de traduction quand une trad est marquée "COMMITTEE" (ou "STATS A JOUR"), je sais pas exactement. Ex: des gens traduisent une appli, qqu'un relit la trad, mentionne qques points qui restent à considérer avant de la committer, marque la trad en RELU et va dormir. Pendant la nuit, la trad est committée, et il n'y a plus aucun moyen de savoir les décisions prises au sujet des points à revoir.
Christophe
On 5/21/06, Christophe Fergeau teuf@gnome.org wrote:
n'y a-t-il vraiment personne pour faire cette modification rapidement ? j'imagine qu'elle est très minime. ça devient vraiment bloquant à ce point.
Tant qu'on est à parler de Vertimus, un autre point qui me dérange, c'est la disparition de tout l'historique de traduction quand une trad est marquée "COMMITTEE" (ou "STATS A JOUR"), je sais pas exactement. Ex: des gens traduisent une appli, qqu'un relit la trad, mentionne qques points qui restent à considérer avant de la committer, marque la trad en RELU et va dormir. Pendant la nuit, la trad est committée, et il n'y a plus aucun moyen de savoir les décisions prises au sujet des points à revoir.
Ce que tu proposes, c'est de temporiser l'effacement de l'historique à quelques jours (1 semaine ?) ou bien de conserver l'historique éternellement ?
Personnellement, je préfère la temporisation de l'effacement de l'historique.
Ce que tu proposes, c'est de temporiser l'effacement de l'historique à quelques jours (1 semaine ?) ou bien de conserver l'historique éternellement ?
Je propose pas grand chose, je me plains juste du fonctionnement actuel, c'est plus simple ;) Pour ma part, je préfère la conservation de l'historique intégral, même si le "vieil" historique peut être caché dans un coin (ie accessible en cliquant sur un lien, mais caché par défaut). On pourrait peut être garder tout l'historique à partir de l'avant-dernier commit (ie on a un cycle complet de trad terminé par un COMMIT, puis le cycle actuel de trad (cycle non encore terminé), et quand ce cycle est marqué "COMMITTE", on cache le cycle le plus vieux).
Christophe
Conserver l'historique jusqu'au 2e COMMITTE : OK.
La perte de l'historique serait d'autant moins troublante si chaque action envoyait un mail à toutes les personnes _ayant_ travaillé sur le module (module, nouvel état, commentaire et lien vers le fichier). Ainsi à votre réveil (cf mail précédent), votre client mail aura la mémoire des évènements !
Si l'état STATS_A_JOUR n'est pas utilisé et si l'historique disparait de manière impromptue (je viens de le remarquer), c'est à cause d'une modif sur la branche de Vuntz (bzr diff -r11..12) dans le script de maj des stats :
+ # Reinit the state for committed translations. This needs to be kept in sync with + # what we're doing in module.inc.php ...
Stéphane
Le dimanche 21 mai 2006 à 15:49 +0200, Christophe Fergeau a écrit :
Ce que tu proposes, c'est de temporiser l'effacement de l'historique à quelques jours (1 semaine ?) ou bien de conserver l'historique éternellement ?
Je propose pas grand chose, je me plains juste du fonctionnement actuel, c'est plus simple ;) Pour ma part, je préfère la conservation de l'historique intégral, même si le "vieil" historique peut être caché dans un coin (ie accessible en cliquant sur un lien, mais caché par défaut). On pourrait peut être garder tout l'historique à partir de l'avant-dernier commit (ie on a un cycle complet de trad terminé par un COMMIT, puis le cycle actuel de trad (cycle non encore terminé), et quand ce cycle est marqué "COMMITTE", on cache le cycle le plus vieux).
Christophe _______________________________________________ Gnomefr mailing list Gnomefr@traduc.org http://www.traduc.org/mailman/listinfo/gnomefr
Le dimanche 21 mai 2006 à 16:24 +0200, Stéphane Raimbault a écrit :
Conserver l'historique jusqu'au 2e COMMITTE : OK.
La perte de l'historique serait d'autant moins troublante si chaque action envoyait un mail à toutes les personnes _ayant_ travaillé sur le module (module, nouvel état, commentaire et lien vers le fichier). Ainsi à votre réveil (cf mail précédent), votre client mail aura la mémoire des évènements !
Si l'état STATS_A_JOUR n'est pas utilisé et si l'historique disparait de manière impromptue (je viens de le remarquer), c'est à cause d'une modif sur la branche de Vuntz (bzr diff -r11..12) dans le script de maj des stats :
# Reinit the state for committed translations. This needs to bekept in sync with
# what we're doing in module.inc.php...
J'avais effectivement fait cette modification pour qu'il n'y ait pas besoin d'utiliser manuellement STATS_A_JOUR.
Je serais d'avis d'avoir un lien "Voir l'historique" qui montre tout l'historique du module. On l'a sauvegardé, donc on peut le faire, non ?
Vincent
Le samedi 20 mai 2006 à 22:49 +0200, Benoît Dejean a écrit :
Le dimanche 14 mai 2006 à 00:09 +0200, Benoît Dejean a écrit :
plop vertimus n'évolue pas, pourtant il en a cruellement besoin. Voici des fonctionnalités que je juge utiles :
- statut 'à revoir'
n'y a-t-il vraiment personne pour faire cette modification rapidement ? j'imagine qu'elle est très minime. ça devient vraiment bloquant à ce point.
Tout le monde peut participer au développement. Le code est disponible dans une branche bzr : http://www.vuntz.net/bzr/vertimus/ (donc un "bzr branch http://www.vuntz.net/bzr/vertimus/" suffit)
Pour ma part, je n'ai pas le temps de modifier cela actuellement. Peut-être que Stéphane aura le temps.
Vincent
Vuntz,
Le 'A REVOIR' est fait sur ma branche (attention codé rapido et test léger) : http://copyleft.free.fr/bzr/vertimus/
Le patch concernant cette modif inclus aussi un fix sur les transitions d'état.
A+ Stéphane
PS: vivement la réécriture de la structure des transitions (cf TODO) !
Le dimanche 21 mai 2006 à 21:46 +0200, Vincent Untz a écrit :
Le samedi 20 mai 2006 à 22:49 +0200, Benoît Dejean a écrit :
Le dimanche 14 mai 2006 à 00:09 +0200, Benoît Dejean a écrit :
plop vertimus n'évolue pas, pourtant il en a cruellement besoin. Voici des fonctionnalités que je juge utiles :
- statut 'à revoir'
n'y a-t-il vraiment personne pour faire cette modification rapidement ? j'imagine qu'elle est très minime. ça devient vraiment bloquant à ce point.
Tout le monde peut participer au développement. Le code est disponible dans une branche bzr : http://www.vuntz.net/bzr/vertimus/ (donc un "bzr branch http://www.vuntz.net/bzr/vertimus/" suffit)
Pour ma part, je n'ai pas le temps de modifier cela actuellement. Peut-être que Stéphane aura le temps.
Vincent
Gnomefr mailing list Gnomefr@traduc.org http://www.traduc.org/mailman/listinfo/gnomefr
Une autre évolution serait la possibilité d'uploader des fichiers .pot.
C'est gênant de ne pas pouvoir le faire, par exemple pour les documentations. (ex : http://tmp.vuntz.net/l10n/module.php?id=299)
Merci d'avance à ceux qui consacrent du temps à cet outil.
Yann
Fait.
Le lundi 22 mai 2006 à 10:14 +0200, Yann Simon a écrit :
Une autre évolution serait la possibilité d'uploader des fichiers .pot.
C'est gênant de ne pas pouvoir le faire, par exemple pour les documentations. (ex : http://tmp.vuntz.net/l10n/module.php?id=299)
Merci d'avance à ceux qui consacrent du temps à cet outil.
Yann _______________________________________________ Gnomefr mailing list Gnomefr@traduc.org http://www.traduc.org/mailman/listinfo/gnomefr
Le lundi 22 mai 2006 à 10:14 +0200, Yann Simon a écrit :
Une autre évolution serait la possibilité d'uploader des fichiers .pot.
C'est gênant de ne pas pouvoir le faire, par exemple pour les documentations. (ex : http://tmp.vuntz.net/l10n/module.php?id=299)
Merci d'avance à ceux qui consacrent du temps à cet outil.
Je ne comprends pas : tu ne devrais jamais avoir besoin d'uploader des .pot, même pour les documentations. Dans quel cas en as-tu besoin ?
Vincent
Le mardi 23 mai 2006 à 09:15 +0200, Vincent Untz a écrit :
Le lundi 22 mai 2006 à 10:14 +0200, Yann Simon a écrit :
Une autre évolution serait la possibilité d'uploader des fichiers .pot.
C'est gênant de ne pas pouvoir le faire, par exemple pour les documentations. (ex : http://tmp.vuntz.net/l10n/module.php?id=299)
Merci d'avance à ceux qui consacrent du temps à cet outil.
Je ne comprends pas : tu ne devrais jamais avoir besoin d'uploader des .pot, même pour les documentations. Dans quel cas en as-tu besoin ?
Vincent
J'ai mis le lien dans mon mail. Merci de me préciser si je me trompe.
Yann
Le mardi 23 mai 2006 à 09:25 +0200, Yann Simon a écrit :
Le mardi 23 mai 2006 à 09:15 +0200, Vincent Untz a écrit :
Le lundi 22 mai 2006 à 10:14 +0200, Yann Simon a écrit :
Une autre évolution serait la possibilité d'uploader des fichiers .pot.
C'est gênant de ne pas pouvoir le faire, par exemple pour les documentations. (ex : http://tmp.vuntz.net/l10n/module.php?id=299)
Merci d'avance à ceux qui consacrent du temps à cet outil.
Je ne comprends pas : tu ne devrais jamais avoir besoin d'uploader des .pot, même pour les documentations. Dans quel cas en as-tu besoin ?
Vincent
J'ai mis le lien dans mon mail. Merci de me préciser si je me trompe.
Les .pot c'est les templates (i.e. quand il n'y a encore jamais eu de traduction), tu dois le renommer en .po ensuite.
Le dimanche 21 mai 2006 à 23:06 +0200, Stéphane Raimbault a écrit :
Vuntz,
Le 'A REVOIR' est fait sur ma branche (attention codé rapido et test léger) : http://copyleft.free.fr/bzr/vertimus/
C'est live.
Vincent
-
Benoît Dejean -
Bob Mauchin -
Christophe Bliard -
Christophe Fergeau -
Christophe Merlet (RedFox) -
Jonathan Ernst -
Stéphane Raimbault -
Vincent Untz -
Yann Simon