Bonjour à tous,
Je reprend le mail de shaiton,
Le 25 août 2013 16:51, Kévin Raymond shaiton@fedoraproject.org a écrit :
Hum, je n'avais pas encore relu cette page… Je ne la pensais pas si précise, elle fait doublons.. Mais est peut-être nécessaire.
Ou alors on devrait réellement terminer la refonte de la page principale.
Ce serait pas mal ;)
La partie correspondante serait : http://fedoraproject.org/wiki/L10N_French_Team_choix
Voir plus bas.
(là je parle pour Nobrakal et Jfenal)
Pour moi une telle page est difficilement maintenable. Les projets évoluent en permanence, ainsi que le nom du traducteur associé. Le plus pertinent serait d'indiquer le traducteur référent (celui qui a l'habitude de traduire la ressource). La colone traducteur n'est pas liée à la réservation d'une traduction, seul les tag « IDT » dans la liste de diffusion devraient l'être. Enfin.. Je risque de te perdre là :)
Le problème est que la liste de diffusion est assez dure à suivre... En cas de doute, il faut chercher parmi les archives, se rappeler le mois, etc. Et, de plus, si comme erika, quelqu'un de nouveau arrive, il est dur pour elle de savoir quoi faire, et si personne ne s'en occupe déjà.
La page sur le wiki me semble une bonne idée, mais il faut en effet la maintenir. La combinaison mailing list/page wiki me semble dur à tenir. Sauf si l'on arrive à automatiser la mise à jour de la page wiki par rapport à la ML, ou l'envoie de mails par rapport à la page.
Mais un 'inventaire' des choses à traduire, leur états et leur priorités peut être très pratique (dommage que Transifex ne l'inclue pas...)
Je me sens presque autant perdu que toi sur cette page, simplement parce que l'entête « en cours de rédaction » est manquante... Jérôme, elle s'est faite un peu vite cette page à mon avis. Ce serait peut-être le moment qu'on trouve un moment (tous) pour discuter méthode de travail et documentation..
Là, je suis tout à fait d'accord. Pour ceux qui connaissent, il y a les 1er samedi du libre (dont le prochain fait office de Rencontres Fedora 19). Ça peut être un lieu pratique.
Peut-être qu'une suggestion de traduction ou de relecture, pour
commencer ?
En fait, ce qui est délicat c'est que les priorités évoluent en fonction de la saison...
- fedora-website est mis à jour quotidiennement avec les traductions.
Mais avant la sortie d'une nouvelle version de Fedora, nous préparons une légère mise à jour (donc plus prioritaire à ce moment là).
- fedora-docs est très utile, mais c'est un gros projet qui nécessite un effort soutenu. Le mieux est d'être à plusieurs pour avancer vite avant que le guide soit dépassé. (Là, j'invite les traducteurs de projets actuels à ce manifester).
- fedora-main sera bientôt prioritaire, mais si un projet t'intéresse et qu'il parait libre sur transifex (non verrouillé), vas-y
- fedora-upstream-projects : si un projet te tiens à cœur, lance-toi.
Même si certains projets n'utilisent pas notre équipe de traduction (parce que soit le mainteneur n'a pas compris l'utilité du concentrateur, soit parce qu'il a définit le projet ouvert à tous en traduction), tu peux toujours demander une relecture ici.
Voir http://fedorapeople.org/groups/schedule/f-20/f-20-trans-tasks.html (on retrouve la page à partir de http://fedoraproject.org/wiki/Releases/20/Schedule)
[snip]
Pour moi une telle page est difficilement maintenable. Les projets évoluent en permanence, ainsi que le nom du traducteur associé. Le plus pertinent serait d'indiquer le traducteur référent (celui qui a l'habitude de traduire la ressource). La colone traducteur n'est pas liée à la réservation d'une traduction, seul les tag « IDT » dans la liste de diffusion devraient l'être. Enfin.. Je risque de te perdre là :)
Le problème est que la liste de diffusion est assez dure à suivre... En cas de doute, il faut chercher parmi les archives, se rappeler le mois, etc. Et, de plus, si comme erika, quelqu'un de nouveau arrive, il est dur pour elle de savoir quoi faire, et si personne ne s'en occupe déjà.
Oui je comprends. D'ailleurs ça a été testé. C'était le principe du tableau suivant : http://fedoraproject.org/wiki/L10N_French_Team#Ils_traduisent_Fedora_en_fran... Mais bon...
En fait, avec la liste de diffusion, seul les nouveaux n'ont pas connaissance de l'état des traductions. Avant, quand on utilisait correctement les tag, une simple recherche dans nos courriels des dernières semaines (3 s) permettait de savoir si le projet était libre ou non.
Bien sûr, si le traducteur s'est arrêté sans prévenir, on recommence... Mais je suis d'accord, c'est lourd comme processus.
La page sur le wiki me semble une bonne idée, mais il faut en effet la maintenir. La combinaison mailing list/page wiki me semble dur à tenir. Sauf si l'on arrive à automatiser la mise à jour de la page wiki par rapport à la ML, ou l'envoie de mails par rapport à la page.
Oui, ça devrait être sur une seule interface. Le problème de Transifex, c'est qu'on ne peut pas bloquer une traduction pour plusieurs semaines d'un coup. On est obligé d'incrémenter jour par jour. Peut-être que ça a changé... Mais je l'avais rapporté en 2011 ce soucis.
En fait, le wiki c'est très bien pour les tâches qui prennent du temps. Par exemple les guides, on pourrait ne se baser que sur une page wiki. Pour les logiciels type Anaconda, ou une dizaines de chaines changent, verrouiller en ligne devrait suffire. Non ?
Mais un 'inventaire' des choses à traduire, leur états et leur priorités peut être très pratique (dommage que Transifex ne l'inclue pas...)
Ça bouge tellement... Mais ça je peux le générer. Avec l'API, un peu de bash ou python, le tour est joué (tous les projets, pourcentage de traduction...)
Peut-être qu'on pourrait développer une interface propre pour faire une synthèse, des statistiques et modifier l'état des traductions. Le problème c'est de définir sa portée (juste compléter TX sans lui supplanter des fonctionnalités.)
Vos avis ? Je propose simplement une synthèse des projets (mais bon, TX le fait, juste mal). + Page wiki spécifique pour les priorités des publications (web, docs, main..) et un tableau pour les guides. Voir les logiciels qui demandent plus de temps.
[snip]
Là, je suis tout à fait d'accord. Pour ceux qui connaissent, il y a les 1er samedi du libre (dont le prochain fait office de Rencontres Fedora 19). Ça peut être un lieu pratique.
C'est bien tôt... Si vous n'y arrivez pas, soit par liste de diffusion, soit une réunion extraordinaire sur IRC ;)
Merci d'avoir reppris mon courriel ici, je sentais bien que je devenais HS :)
Bonsoir à tous,
Le problème est que la liste de diffusion est assez dure à suivre... En cas de doute, il faut chercher parmi les archives, se rappeler le mois, etc. Et, de plus, si comme erika, quelqu'un de nouveau arrive, il est dur pour elle de savoir quoi faire, et si personne ne s'en occupe déjà.
Oui je comprends. D'ailleurs ça a été testé. C'était le principe du tableau suivant : http://fedoraproject.org/wiki/L10N_French_Team#Ils_traduisent_Fedora_en_fran... Mais bon...
Le 'mais bon...' convient assez bien ;). Plus sérieusement, c'est vrai qu'il faut la maintenir à jour.
En fait, avec la liste de diffusion, seul les nouveaux n'ont pas connaissance de l'état des traductions. Avant, quand on utilisait correctement les tag, une simple recherche dans nos courriels des dernières semaines (3 s) permettait de savoir si le projet était libre ou non.
Bien sûr, si le traducteur s'est arrêté sans prévenir, on recommence... Mais je suis d'accord, c'est lourd comme processus.
Exactement, surtout quand on s'en sert mal (moi le premier).
La page sur le wiki me semble une bonne idée, mais il faut en effet la maintenir. La combinaison mailing list/page wiki me semble dur à tenir. Sauf si l'on arrive à automatiser la mise à jour de la page wiki par rapport à la ML, ou l'envoie de mails par rapport à la page.
Oui, ça devrait être sur une seule interface. Le problème de Transifex, c'est qu'on ne peut pas bloquer une traduction pour plusieurs semaines d'un coup. On est obligé d'incrémenter jour par jour. Peut-être que ça a changé... Mais je l'avais rapporté en 2011 ce soucis.
En fait, le wiki c'est très bien pour les tâches qui prennent du temps.
Voilà
Par exemple les guides, on pourrait ne se baser que sur une page wiki. Pour les logiciels type Anaconda, ou une dizaines de chaines changent, verrouiller en ligne devrait suffire. Non ?
Techniquement oui, mais comme tu le dis, le verrouillage est de deux jours, trop peu à mon gout.
Mais un 'inventaire' des choses à traduire, leur états et leur priorités peut être très pratique (dommage que Transifex ne l'inclue pas...)
Ça bouge tellement... Mais ça je peux le générer. Avec l'API, un peu de bash ou python, le tour est joué (tous les projets, pourcentage de traduction...)
Peut-être qu'on pourrait développer une interface propre pour faire une synthèse, des statistiques et modifier l'état des traductions. Le problème c'est de définir sa portée (juste compléter TX sans lui supplanter des fonctionnalités.)
Je suis tout à fait pour!
Vos avis ? Je propose simplement une synthèse des projets (mais bon, TX le fait, juste mal). + Page wiki spécifique pour les priorités des publications (web, docs, main..) et un tableau pour les guides. Voir les logiciels qui demandent plus de temps.
Dans ton 'interface propre', il serait intéressant d'incorporer un verrouillage plus long terme, mais, bon, à programmer... Et aussi les demandes de relectures, trop souvent oublié après deux jours sur la ML (c'était une des raisons de la création de la page wiki)
Sinon, tout me parait parfait ;)
[snip]
Là, je suis tout à fait d'accord. Pour ceux qui connaissent, il y a les 1er samedi du libre (dont le prochain fait office de Rencontres Fedora 19). Ça peut être un lieu pratique.
C'est bien tôt... Si vous n'y arrivez pas, soit par liste de diffusion, soit une réunion extraordinaire sur IRC ;)
Je pense qu'une réunion sur IRC peut être pratique (pas de transport) ou toujours le premier samedi du mois d'octobre/novembre. Au choix.
Alexandre, Fedora User and Ambassador
[snip]
Peut-être qu'on pourrait développer une interface propre pour faire une synthèse, des statistiques et modifier l'état des traductions. Le problème c'est de définir sa portée (juste compléter TX sans lui supplanter des fonctionnalités.)
Je suis tout à fait pour!
Comme je ne sais pas oublier une idée.. J'ai commencé à y réflechir un peu plus. Le soucis, c'est que ça ne serait qu'une interface de consultation des projets (et de leur avancement) voir de tri de priorité. Si on commence à vouloir l'utiliser pour traduire, il faudrait gérer les utilisateurs/droits, et donc un nouveau compte... Non envisageable. Ce serait plus simple d'utiliser un robot qui ferait ça pour nous au travers de la liste de diffusion, un peu comme à la FSF. Mais bon, on verra plus tard.
Déjà je vais faire la première étape pour consultation, puis on verra si c'est utile.
Salut à vous,
Voilà une première partie du code. Celle-là même qui permet de voir un peu ce qu'on peu obtenir. Je vous présente le résultat, à vous de voir si c'est utile (et dans ce cas la seconde partie viendra, c'est à dire la mise en page...) Notez bien que Transifex évolue en permanence, et que ce qu'on essaye de remplacer ici sera peut-être prochainement disponible. Mais bon.. Ça peut mettre des années.
Donc le script principal[1] permet de : - configurer le dépôt. De la même manière que sur WIP, un dossier par parution, un dépôt transifex par parution. La première fois je l'avais fait en bash, même principe ici. Afin d'obtenir tous les projets, je parcours la liste des parutions, et récupère le nom du projet en fonction des resources ajoutées à la parution. Le seul problème c'est que je n'ai pas la possibilité de scripter l'ajout de projet qui n'apparaissent dans aucunes parution... à faire manuellement, plus tard si je n'oublie pas. - générer un fichier de donnée contenant les statistiques de traduction. Un exemple ici[2]. Je présente les stats par projet uniquement, et non par ressource. C'est mieux pour les guides, et pour les projets comme Anaconda qui on une ressource par branche, ça fausse un peu les résultats, néanmoins cela reflète ce qu'on a la possibilité de traduire. En effet, je ne compte pas les fichiers dont la traduction est bloquée (normalement...)
Cela devrait suffire en complément d'une interface web affichant les projets par parution et pourcentage de complétion. On peut aussi coupler ça à des coefficients de priorité. Suivant vos retours, je commencerai cette page (je la voyais il y a deux ans sur fedora-fr.org, c'est toujours possible). Dans tous les cas, le script [1] arrivera prochainement sur stetson (le nom du serveur fedora-fr.org où wip.fedora-fr.org est hébergé) afin que le dépôt git soit à jour. Tous commentaires ou pull requests sont les bienvenus (oui ya de la bidouille dans mon script)
[1] https://gitorious.org/tiny-scripts/transifex/source/c793387ceeb9db0235655649... [2] http://www.fpaste.org/35536/13777127/
[snip]
Cela devrait suffire en complément d'une interface web affichant les projets par parution et pourcentage de complétion. On peut aussi coupler ça à des coefficients de priorité.
Bon et bien, j'ai commencé. Voici le résultat actuel : http://www.shaiton.org/trad/traduction.cgi
Il manque le principal, la gestion des priorités :) Mais je n'ai pas encore une bonne idée pour les afficher, hormis une colone priorité avec un coefficient qui permettrait de trier le tableau. Ensuite, il faudrait un tableau qui puisse être trié suivant les priorités puis le pourcentage de complétion.. C'est l'usine.
Niveau fonctionnalité, actuellement mon script récupère toutes les heures le fichier de données disponible sur wip. Sur wip, le dépot est maintenant mis à jour deux fois par jour, par contre le fichier de donné est statique. Il faut que j'ajoute le cron (peut-être fait d'ici ce soir). Mais la page que j'ai donnée plus haut n'est qu'un exemple, qui devrait refléter la réalité quand le cron sera ajouté.
Niveau code, je suis basé sur un cgi parce que : - je n'en n'avais jamais fait; - python parce que je savais le faire en php :p - j'avais un espace de dispo sur ovh
Mais n'importe qui peut améliorer/recoder : https://gitorious.org/tiny-scripts/transifex/trees/master C'est dans le dossier l10_stats/web
Voilà, je remarque 2 projets qui n'ont pas bougés depuis 2011 (date de migration à transifex.net).. Je vais voir s'il faut les retirer.
++
trans-fr@lists.fedoraproject.org
-
Alexandre Moine -
Kévin Raymond