By bès on
Salut les gens,
bon on va avoir un petit soucis, j'ai passé le week-end à gérer les dernières suggestions sur le projet Drupal core mais j'en reprend tous les jours.
Je ne sais pas si ca vient de quelqu'un qui charge des .po à la main ou d'un l10n_client qui se synchronise avec http://localize.drupal.org mais c'est assez ennuyeux.
Il faudrait qu'on réfléchisse à une solution et voir si on peut la proposer ou même la coder.
Damz a proposé de virer l'utilisateur, ce qui pourrait fonctionner mais je n'en suis pas sur et ça serait dommage si en plus la personne aide aussi :)
So let's talk !
Groups audience:
Comments
so, quelle est la procédure
so, quelle est la procédure ?
c'est normal qu'il y ai autant de strings a valider sur le drupal Core ?
Si a chaque fois que qq'un injecte des .po à la volée et qu'il faut valider ttes les strings, ça va être dur de s'en sortir (d'autant plus que d'après ce que j'ai vu, les suggestions sont identiques au "contrib initial") ??
y a qqes choses qui m'echappe.
robin
Hello, Pourquoi ne pas
Hello,
Pourquoi ne pas simplement abandonner, dans l'attente de trouver et mis en place une solution, l'import à la volé...
En tout cas je trouve que l'import à la volé ne devrait pas ajouter des suggestions sur des strings déjà validés.
Et hop une belle interface pour traduction par lot :)
C'est tout frais Damien vient de re-tweeter Gabor :
http://localize.drupal.org/node/117
Il y a maintenant un système identique à celui de Development Seed pour OpenAtrium qui facilite la validation par lot des traductions :)
Edit : Gabor vient de me préciser qu'ils ont amélioré et testé intensivement à partir des suggestions de Jose chez DS, c'est donc un travail d'équipe on va avoir une interface robuste cool :)
Excellente nouvelle ! :-)
Excellente nouvelle ! :-)
Effectivement je me joins à
Effectivement je me joins à Robby avant de me lancer je veux être sûr que ça ne pose pas de problème...
Quelle est la méthode à suivre : utiliser la synchronisation depuis l10n_client ou importer des .po ?
Ensuite, l'utilisateur en cause n'a peut-être pas conscience du problème et ça n'est très probablement pas intentionnel... le mieux serait quand même de le contacter et voir quelle est sa méthode / config avant de le zapper... non ? Parcequ'on est tous candidats au zapping sinon, n'étant pas sûr de la marche à suivre... Perso je n'ai eu aucun problème avec le serveur d'OpenAtrium en synchro avec l10nclient mais je suspectent qu'ils utilisent une version modifiée...
Wait and see, donc, avant d'importer un paquet de strings (notamment j'ai une trad d'Organic Groups D6 à 96%)...
Pour moi utiliser l10n_client
Pour moi utiliser l10n_client ou importer des .po pose le même soucis dans le cas de projet qui possède déjà une traduction assez complète (comme le core de drupal).
Pour tous autres projets il n'y a pas de soucis. Il faut juste vérifier en amont si le projet est bien traduit ou s'il est vierge.
N'ayant pas encore testé l10n_client je ne saurais pas dire si les reversement vers http://localize.drupal.org se font de façon automatique pour tous les projets ou si c'est manuel.
Pour le moment le plus simple semble être l'export / Import de .po de projet relativement non traduit ou l'utilisation directe de http://localize.drupal.org. J'ai par exemple commencé à traduire le module "Demonstration Site" directement ici.
Comme tu l'a dis il n'est pas question de virer qui que ce soit, et j'ai aussi fait ce topic pour prendre contact avec les gens. Je devrais peut être passer par leur compte d.o car il n'y a pas de formulaire de contact sur localize.
Actuellement le problème que j'évoque n'appairait, je le répète, que sur des projets presque complètement traduit où on se retrouve d'un coup avec beaucoup de suggestion à revalider sans possibilité de pouvoir faire se travail massivement.
Ok merci pour la réponse
Ok merci pour la réponse rapide... je comprend mieux la nature du problème...
Pour la validation massive je sais que le l10n_server de Development Seed pour OpenAtrium a mis en place un outil pour valider les chaînes par lot mais le filtre permet de valider que 200 chaînes maxi à chaque fois (j'ai le même souci en tant que maintainer de OA parceque les chaînes FR par défaut de Drupal on été importées dans OA et que j'ai 3500 chaînes à valider, alors que je sais qu'elles sont bonnes :-\ )
J'imagine en plus qu'il n'est pas forcémment possible de lancer une requête MySQL pour modifier le statut des trad concernées "à la barbare" ?
Oui la procédure est compliquée et localize.drupal.org est beta
Les suggestions proviennent des imports croisés initiaux des .po :
* du core drupal
* des modules contrib (mea culpa pour ma part)
Cela pose un problème effectivement d'uniformisation des traductions auquel toute communauté active de traducteur est confrontée. Comme disait Gabor : il ne peut y avoir qu'une traduction qui l'emporte pour une string originale
Les pb de suggestion en attente d'approbation auxquelles nous sommes confrontés proviennent de cette non uniformisation qui découle de nos anciennes méthodes de travail :
* pas de guidelines/de glossaire
* des import/export de po entre le core/les modules, d5/d6 avec différents traducteurs
Si on importe un .po et que la trad d'uns string est identique à celle existante sur drupal.org, il n'y aura pas de suggestion
Mes conclusions sont donc :
- que l'on valide rapidement nos guidelines/notre glossaire pour que les risques de trad multiples se limitent par la suite
- que les 10+ admin de ce groupe passent une heure par semaine pour faire de l'approve/disapprove de suggestions dans cet esprit d'uniformisation (c'est leur rôle)
- la convergence va être d'autant plus facilité quand localize.drupal.org réexportera automatiquement les .po à chaque nouvelle release de module => les install de nouveaux drupal avec des traductions up to date seront la base de cette convergence
Pour info l10n_client par défaut ne rebalance pas des suggestions sur localize.drupal.org (il faut activer une option + demander une API key dans la config du module)
Le système est bancal pour le moment mais on en aperçoit à peine la puissance. Ceux qui ont fait de la trad à l'ancienne (potx/import/export/.po/poedit/issue queue/Cvs/recherche fr.po sur google) seront surement d'accord avec moi
On est à mon avis (IMHO) au début de quelque chose de très grand pour la localisation de drupal et de ses modules
Keep on the fight !
C'est ennuyeux, en effet !
On pourrait imaginer quelques outils qui nous simplifieraient la vie :
- un comparateur de strings qui virerait automatiquement toute chaine identique
- changer l'affichage - comme tu l'as fait, Guillaume - pour nous permettre de voir d'un coup d'oeil l'ensemble des suggestions, et de les virer d'un clic si elles ne conviennent pas
- enfin, lorsqu'une traduction est éprouvée, ne serait-il pas judicieux de pouvoir la verrouillée, de façon réversible au cas où, afin de ne pas perdre notre temps à faire le ménage là où ce n'est pas nécessaire ?
Un autre problème se posera très vite, celui incontournable du contexte !
Il n'est vraiment pas terrible qu'une string soit traduite partout (sur tous les modules) de la même façon.
Ne pourrait-on les différencier ?
Un exemple que j'ai vu passer, la chaine "Views". Qu"est-ce qui différencie le nom du module "Views" des "vues" ?
Il serait bien, enfin, que l'interface soit plus conviviale et l'ergonomie repensée : c'est aussi opaque que le fut drupal.org, qui a fait des progrès depuis, et il faudrait que l'on puisse faire une recherche vraiment poussée (tous les opérateurs de 'Contains', par exemple et un moyen d'affiner les résultats...
Qui en parle à Gabor ? ;o)
Prend ton destin en main !
Qui en parle à Gabor ? ;o)
C'est déjà fait... Ori et moi avons discuté longuement de ce sujet avec Gabor lors du sprint.
Nous avons proposé d'organiser un sprint avec 2 ou 3 codeurs français expérimentés pour mettre en œuvre un contexte par module.
Mais avant il va donc falloir écrire des specs et proposer un concept technique.
Bref Gabor est OK sur le principe par contre c'est à nous de faire bouger la chose.
Bon alors, c'était trop
Bon alors, c'était trop simple.
Après en avoir discuté avec damz, il semble qu'ajouter un contexte au niveau du serveur n'est une bonne idée. Sur ce type de question j'ai tendance à le croire sur parole.
Il a aussi une bonne remarque qui consiste à dire que aujourd'hui on ne sait pas vraiment à quel point ce phénomène de collision entre les chaînes est un problème et que peut-être sur la plupart des cas la traduction commune va fonctionner.
Bon, bref, peut-être va-t-il falloir fonctionner comme cela et évaluer la criticité de ce sujet.
:o)
Je doute que cette question ne pose pas de soucis.
Mais il me parait effectivement judicieux d'en constater exactement la nature et l'étendue avant de trouver une solution au problème. Disons que cela nous laisse du temps pour y réfléchir...
:)
Je viens de constater le même problème avec le module features que je suis en train de traduire pour une démo au boulot. D'ailleurs à ce propos, j'ai du l'importer plusieurs fois en croyant à une erreur. Désolé.
Déterrage...
Bonjour à tous,
Le problème des "contextes" se pose encore dans Localize (ex. "Quotes" -> "Devis"/"Citations"). Y a t-il un moyen de contribuer à faire avancer ce sujet ?
Ce n'est pas parceque le
Ce n'est pas parceque le système de traduction est simplifié par un outil qu'il faut négliger le travail manuel : j'entends par là qu'avant d'uploader un .po pour un module (ce n'est plus nécessaire pour le core, on arrive au bout à priori et Guillaume l'a bien rappelé) il suffit de checker de visu s'il y a déjà beaucoup de suggestions pour ce dernier (en utilisant le système de filtre).
Bref, c'est à chacun de prendre ses précautions, à rappeler dans le guide du traducteur peut être ?
Question : est-ce que l'uplaod de .po est possible pour les non-admins (je ne sais plus) ? Si oui, pourquoi ne pas juste bloquer cette fonctionnalité sur le core dans un premier temps ?
Salut Arnaud, Oui, c'est bien
Salut Arnaud,
Oui, c'est bien parce que chacun peut proposer un .po ou une suggestion manuelle ou via l10n qu'il sera difficile d'appliquer pour tout le monde ta suggestion. Il faudra évidemment expliquer tout cela dans le guide.
Pour le blocage du core, je ne sais si cela est possible. Bes ?
Il faut demander au Manager
Mais je pense que ce n'est pas possible.
J'ai demandé rapidement à Damien hier et apparemment les seuls droits qu'il a en plus c'est la gestion du groupe OG pas de toute la partie Traduction.
Je suis en tout cas d'accord avec Arnaud et Lor, il faut responsabiliser les gens le temps qu'on trouve une solution, peut être la notion de freeze de traduction pour un projet visant à ne plus accepter les suggestions sauf venant d'un admin. Mais il faudra coder ce genre de chose ou ouvrir une issue et attendre :)
En attendant il faut finir de traduire le core (13 chaines je devrais les finir rapidement) et gérer les 250 suggestions, si tous les admins font une page par jour ça sera bon avant la fin de la semaines :)
Question
J'y pense, n'y a t'il pas une option permettant d'exporter que les chaînes non traduites? De temps en temps on pourrait faire ça sur un module, traduire les chaînes et réimporter? Pour le moment je tente de le faire à la main mais ce n'est pas évident.
Autrement est ce que poedit ou un autre éditeur dispose d'une option pour n'exporter que les chaînes modifiées?