-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
[ TL;DR: Serait-il possible de permettre aux développeurs amont d'ajouter une date attendue pour les traductions demandées, et de les encourager à envoyer régulièrement des demandes de traduction ]
Salut,
La récente expérience intéressante avec Vladimir pour GRUB nous a fait remarquer un manque dans les messages envoyés par le robot : ce serait pratique de permettre aux membre du projet amont d'indiquer, facultativement, une date limite pour recevoir les traductions.
Dans le cas de GRUB, Vladimir a pu participer à la relecture (c'est vraiment idéal de pouvoir échanger avec l'amont dans ces conditions), ce qui lui a permis de modifier les chaînes en amont, et de relancer une paire d'appel à traduction, tout en m'informant de la date de mise à jour attendue.
Ce serait pratique pour les traducteurs d'avoir une date indicative pour leur permettre d'ordonner leurs priorités si possible, et être capable de se conformer au calendrier amont. Ça peut être encourageant de savoir « si je finis cette traduction avant la fin de la semaine, la prochaine version de $programme sera complète en $langue ».
Les échanges avec GRUB ont montré qu'une collaboration étroite est possible, mais même sans aller jusque là, ce serait chouette d'encourager les développeurs amont a renvoyer les chaînes de beta2, beta3, rc2, rc3, ainsi que des mises à jour mineures, même quand il n'y a qu'un nombre réduit de modifications (corrections de typo et autres éclaircissements). C'est un peu frustrant de se dépêcher de mettre à jour des centaines de chaînes en un temps record (à cause de l'absence d'indication temporelle de la publication finale), et s'apercevoir que la version finale n'est pas complète, par exemple :
$ msgfmt -vc util-linux-2.21/po/fr.po 2675 messages traduits, 1 traduction approximative.
(ce n'est ici qu'une chaîne mais l'expérience passée à montré que les version intermédiaires de ce programme était souvent modifiées, sans possibilité de mise à jour par l'interface du Translation Project).
Amicalement
David
Afficher les réponses par date
Bonsoir,
Le Dim 18 mars 2012 20:57, David Prévot a écrit :
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
[ TL;DR: Serait-il possible de permettre aux développeurs amont d'ajouter une date attendue pour les traductions demandées, et de les encourager à envoyer régulièrement des demandes de traduction ]
Salut,
La récente expérience intéressante avec Vladimir pour GRUB nous a fait remarquer un manque dans les messages envoyés par le robot : ce serait pratique de permettre aux membre du projet amont d'indiquer, facultativement, une date limite pour recevoir les traductions.
Dans le cas de GRUB, Vladimir a pu participer à la relecture (c'est vraiment idéal de pouvoir échanger avec l'amont dans ces conditions), ce qui lui a permis de modifier les chaînes en amont, et de relancer une paire d'appel à traduction, tout en m'informant de la date de mise à jour attendue.
Ce serait pratique pour les traducteurs d'avoir une date indicative pour leur permettre d'ordonner leurs priorités si possible, et être capable de se conformer au calendrier amont. Ça peut être encourageant de savoir « si je finis cette traduction avant la fin de la semaine, la prochaine version de $programme sera complète en $langue ».
Les échanges avec GRUB ont montré qu'une collaboration étroite est possible, mais même sans aller jusque là, ce serait chouette d'encourager les développeurs amont a renvoyer les chaînes de beta2, beta3, rc2, rc3, ainsi que des mises à jour mineures, même quand il n'y a qu'un nombre réduit de modifications (corrections de typo et autres éclaircissements). C'est un peu frustrant de se dépêcher de mettre à jour des centaines de chaînes en un temps record (à cause de l'absence d'indication temporelle de la publication finale), et s'apercevoir que la version finale n'est pas complète, par exemple :
$ msgfmt -vc util-linux-2.21/po/fr.po 2675 messages traduits, 1 traduction approximative.
(ce n'est ici qu'une chaîne mais l'expérience passée à montré que les version intermédiaires de ce programme était souvent modifiées, sans possibilité de mise à jour par l'interface du Translation Project).
Personnellement, ça me semble une excellente idée. J'ai eu le même type d'expérience sur les traductions dont je m'occupe.
À priori, la bonne liste pour faire cette suggestion est la liste translation-i18n, qui chapeaute le projet :
https://lists.sourceforge.net/lists/listinfo/translation-i18n
Amicalement.
On 18.03.2012 20:57, David Prévot wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
[ TL;DR: Serait-il possible de permettre aux développeurs amont d'ajouter une date attendue pour les traductions demandées, et de les encourager à envoyer régulièrement des demandes de traduction ]
Salut,
La récente expérience intéressante avec Vladimir pour GRUB nous a fait remarquer un manque dans les messages envoyés par le robot : ce serait pratique de permettre aux membre du projet amont d'indiquer, facultativement, une date limite pour recevoir les traductions.
Ca serait une bonne idée. Mais il faut aussi la communication en sens inverse. Les dates sont parfois flexible et il serait utile de savoir s'il y a un traducteur intéressé mais qui n'arrive pas à finir la traduction en temps prévu et que le traducteur en question puisse demander de repousser la date de limite. Ceci prend surtout son poids si la traduction à plusieurs langues majeurs ne serait pas fini en temps. Optionellement le maintaineur de l'amont peut aussi décider de faire un release separé avec plus de langues. P.ex. 2.00 et 2.00-lang1 ce qui informerait l'utilisateur qu'il n'y a pas de changement de code mais juste des traductions. Dans ce cas il faut aussi savoir si d'autres traducteurs sont dans un cas similaire pour éviter d'avoir -lang1 et -lang2 à quelques jours de différence.
Dans le cas de GRUB, Vladimir a pu participer à la relecture (c'est vraiment idéal de pouvoir échanger avec l'amont dans ces conditions), ce qui lui a permis de modifier les chaînes en amont, et de relancer une paire d'appel à traduction, tout en m'informant de la date de mise à jour attendue.
Ceci est un cas particulier car je parle le français. Pour ce type de collaboration il faut que le developpeur en amont puisse au moins comprendre la langue en question. Moi, je relis les traductions en allemand, français, italien, russe et ukrainien. Je serais en mesure de relire l'espagnol si une telle traduction existait. Si le developpeur en amont ne comprend la langue que partiellement il ne peut pas vérifier toutes les chaînes et se sent moins impliquer pour le faire (rien que par le fait de ne pas pouvoir le faire à 100% et devoir fournir plus d'effort pour comprendre certains chaînes). Dans mon cas c'est valable pour catalan ou polonais (un peu pour asturien, néerlendais, danois ou suédois). Mais je ne comprends pas un seul mot de finlandais, hongrois, indonésien, japonais, coréen, vietnamien ou chinois. La troisième catégorie est de loin la plus nombreuse dans plupart de projets. Il faudrait qu'il y ait aussi une communication avec ces traducteurs surtout qu'ils représentent souvent des langues non-indo-européens qui probablement nécessitent le plus de contexte supplémentaire. Le plus souvent les cas de traductions inapproprié surviennent si le traducteur ne saisit pas le contexte et je suppose qu'il s'en rends compte mais essaie de traduire quand même. Vu qu'on peut ajouter des commentaires dans les fichiers .po et en prenant compte que la communication dans l'autre sens se fait avec les commentaires TRANSLATORS: on pourrait faire un commentaire similaire DEVELOPPERS: and .po et leur contenu serait envoyé automatiquement par le robot à l'adresse de msgid-report-bugs. Bien sûr, on pourrait faire qqch de similaire manuellement mais c'est plus compliqué et donc n'est presque jamais fait.
Ce serait pratique pour les traducteurs d'avoir une date indicative pour leur permettre d'ordonner leurs priorités si possible, et être capable de se conformer au calendrier amont. Ça peut être encourageant de savoir « si je finis cette traduction avant la fin de la semaine, la prochaine version de $programme sera complète en $langue ».
Les échanges avec GRUB ont montré qu'une collaboration étroite est possible, mais même sans aller jusque là, ce serait chouette d'encourager les développeurs amont a renvoyer les chaînes de beta2, beta3, rc2, rc3, ainsi que des mises à jour mineures, même quand il n'y a qu'un nombre réduit de modifications (corrections de typo et autres éclaircissements).
Le problème actuellement c'est qu'il y a un humain (coordinateur) pour mettre en place les .pot (sauf si j'ai mal compris les instructions pour les maintaineurs). Il serait préférable si on pouvait juste envoyer le .pot au robot signé avec la clé publique et le robot l'aurait mis à disposition automatiquement.