By mlbrgl on

Bonjour,

Après avoir lu la FAQ et les documents associés, il y a toujours quelques points sur lesquels je m'interroge. Chaque paragraphe ci-dessous est une affirmation que je pense être vraie. Pourriez-vous confirmer ou infirmer ?

Vrai ou Faux ?

#1
Meilleure marche à suivre pour mettre à jour les traductions sur son site :

  1. Installer l10n_client
  2. Mettre à jour les modules/thèmes pour lesquels on souhaite récupérer de nouvelles traductions (si de nouvelles traductions sont disponibles, les fr.po seront mis à jour).
  3. Visiter admin/build/translate/import/package pour réimporter les traductions à partir des fr.po présents dans les différents modules/thèmes.

#2
Pour contribuer à l'effort de traduction, je vois deux moyens :

#3
Activer le partage avec localize.drupal.org via l10n_client ne fonctionne que dans un seul sens (client vers serveur). Il n'est pas possible de récupérer automatiquement des traductions (ou suggestions) proposées sur localize.drupal.org, ni même de savoir si la chaîne que je m'apprête à traduire a déjà été traitée. En utilisant l10n_client, il est donc possible que je soumette des traductions qui ont déjà été proposées.

#4
Une fois ma traduction approuvée, elle doit être soumise manuellement par un admin de localize dans l'issue queue du module s'y rapportant (ou directement soumise via CVS si celui-ci dispose d'un accès en écriture). Elle se retrouve donc dans la version -dev du module. Je ne la verrai donc officiellement dans une version stable, rc, beta ou alpha que lorsque le propriétaire du module crée une nouvelle révision. En attendant, personne ne peut profiter de ma traduction, si ce n'est en récupérant le fr.po dans le package -dev du module en question (ce point est partiellement traité dans la FAQ mais je souhaitais une clarification).

#5
Tant qu'une traduction n'a pas fait son chemin vers CVS, et qu'elle n'est donc présente que sur localize, je ne peux l'exporter (tout en étant conscient des risques liés à l'adoption d'une traduction non vérifiée).

#6
En utilisant l10n_client pour traduire les chaînes “qui me sautent aux yeux”, je n’aide pas forcément la communauté en ce sens que mes traductions ne seront que ponctuelles et ne couvriront pas forcément la totalité des termes à traduire du module. Mieux vaut (comme il a été suggéré ici http://localize.drupal.org/node/424#comment-1112), que je me positionne en tant que “traducteur officiel” du module et que je maintienne sa traduction à jour dans le temps.

#7
Si je vois un module :

alors je peux considérer que ce module ne fait pas l’objet d’une traduction à l’heure actuelle. Dois-je informer quelqu’un avant de me lancer afin d’éviter un effort inutile (autant pour moi que pour une personne souhaitant participer à la traduction) ?

Merci,

Matthieu

Groups audience: 
French team

Comments

lor commented

Voici mes réponses, point par point, d'après ce que j'ai compris (n'hésitez surtout pas à me corriger s'il y a des erreurs) :

#1
Faux.
Je ne suis pas un expert de cet outil, mais je crois que l10n_client est avant tout un module permettant d'effectuer des traductions sur n'importe quelle page de son site, ce qui permet d'effectuer des traductions contextuelles et de traduire tout ce que ne peut traduire le mécanisme habituel de traduction par chaine de caractères. Il permet aussi, s'il est paramétré dans ce sens, de remonter ses propres traductions automatiquement sur localize afin d'y créer de nouvelles suggestions de traduction. A ce jour, malheureusement, aucun mécanisme de mise à jour automatique sur les fichiers .po n'est mis en place. Mais cela devrait être le cas à terme.

#2
Vrai.

#3
Vrai. J'ai demandé à Gabor Hojtsy des améliorations pour corriger cela :
http://drupal.org/node/631906

#4
A peu près vrai.
Une fois validées, les traductions sont importables via localize (pas de synchro avec le fichier .po du module pour le moment).
A savoir si ces traductions sont releasées sur les versions -dev des modules, je n'en sais rien mais je ne crois pas.

#5
Exact. Idem #3.

#6
Hum... Tu aides évidemment plus la communauté en maintenant un module, lorsque cela sera possible, si ça l'est un jour.
L'idée originale de ce fonctionnement via l10n est de rassembler toutes les traductions localisées sur localize pour en faire bénéficier la communauté. L'ennui est que lorsqu'une traduction a déjà été validée, cela ne fait qu'ajouter des suggestions que les admin doivent "nettoyer" ensuite. Un système de verrouillage permettrait d'éviter cela et de limiter les suggestions aux traductions non validées. (Cf. #3), ce qui serait alors des plus utiles. Ainsi, le travail de "fourmi" que fournit chacun est centralisé et donc bénéfique à l'ensemble de la communauté, pourvu que l'équipe d'admin les validant puisse suivre le rythme, ce qui est actuellement notre plus gros problème. Cette contribution n'est pas à négliger pour des personnes qui n'auraient pas le temps de s'investir plus dans le travail de traduction.

#7
La liste des modules consignée sur le doc https://spreadsheets.google.com/ccc?key=0AnJCfDM6tsLVdEt1b2wwOGpYTTBkc1F... ne liste que les modules dont nous avons déjà les traductions (principalement effectuées par sbordage et slybud). Mais elle n'est en rien EXHAUSTIVE. Ce qui signifie que la traduction d'un module qui n'apparaitrait pas dans ce doc peut très bien avoir été faite par ailleurs. Il faudrait effectivement avoir un document qui permettent à chacun de savoir ce qui est fait pour chaque module. Je vais voir ce qu'il est possible d'envisager dans ce sens. L'idée serait d'avoir un doc listant tous les modules contribués (l'idéal serait qu'il soit dynamique et automatisé aux modules, afin que chaque nouveau module soit listé automatiquement), et que des "états" nous indique l'état de traduction et permette à chacun de signifier qu'il va travailler dessus afin d'éviter des doublons de travail. Mais évidemment, si quelqu'un traduit un module et ne donne pas l'info sur ce doc, personne ne saura que le travail a déjà été effectué. Etant donné l'effervescence actuelle autour de cet outil, et s'il devient aussi incontournable qu'il le laisse augurer pour tout ce qui est traduction de module, on peut espérer à terme qu'il soit rapidement assez exhaustif.

mlbrgl commented

Merci beaucoup pour toutes ces précisions. J'y vois un peu plus clair mais j'avoue être encore perplexe sur certains points.

#1 Quelle serait alors le "meilleur" moyen de mettre à jour les traductions sur son site à partir des releases officielles / localize ?

#4,5 Je ne vois pas très bien comment utiliser localize en l'état actuel des choses. Imaginons un scénario classique. J'importe une traduction via localize. Elle est validée après vérification. Que se passe-t-il ensuite ? Vu qu'il n'y a apparement pas de lien automatique entre localize et les .po, il faut donc que quelqu'un se "dévoue" pour soumettre la traduction au responsable du module en question ? Autrement, cette traduction reste sur localize. Et puisqu'elle n'est liée à aucune release officielle du module, elle n'est pas exportable via localize, et est donc inaccessible à quiconque voudrait en profiter. En résumé, doit-on voir localize comme un "trou noir" à traductions en attendant que les mécanismes de distribution soient mis en place ?

Merci,

Matthieu

lor commented

J'attends encore des réponses de Gabor pour pouvoir répondre précisément à ces questions.

#1 "L'ancienne" méthode : disposer d'un compte CVS ou connaître quelqu'un qui en dispose afin de contribuer la traduction du module. Nos "spécialistes" en la matière, slybud et sbordage en disposent. Ils ont créé de nombreuses releases via les issues de drupal.org. Mais là encore, il faut aller les chercher. Elles ne sont pas liées directement aux modules. Seuls les mainteneurs des modules ont cette possibilité.

#4,5 Seul Gabor peut répondre à cela. Nous désirons évidemment qu'il ne soit pas perçu comme "un trou noir" pour ne pas dévaluer l'intérêt (majeur) de cet outil et ne pas perdre l'intérêt de la communauté. Mais aux vues des pb actuels, force est de constater que l'outil n'est pas encore optimisé. J'espère qu'il le sera prochainement.

jimi commented

#1 VRAI-FAUX : l10n_client permet de synchroniser les traductions faites sur le site vers le serveur.
Pour charger les traductions du serveur vers le site il faut installer l10n_server. <- et d'après le readme.txt c'est prévu dans une version à venir.

jimi commented

Bonjour,

1 - j'ai un (voire plusieurs) module qui contient un fichier fr.po avec les traductions, rien n'est traduit sur mon instalation… c'est fréquent ?

2 - je traduit actuellement ubercart (c'est entre autres le cas cité ci-dessus) et différents modules uc_ pour un client (pharmacie) en intégrant ses besoins qui ne correspondront pas à une utilisation habituelle. Par exemple je traduis "order" par "réservation" alors qu'une utilisation plus habituelle serait "commande".
Je n'ai pas osé activer l10n_client pour ne pas mettre le souc… quelle est la meilleure procédure pour une traduction spécifique ?

3 - D'autre part peut on avec l10n_client (dans le cas où la traduction fonctionnerait pour un module…) apporter ses propres corrections sur quelques termes déjà traduits sans risque de perturber la traduction utilisée, ou que les modification faites ne sautent en cas de mise à jour ?

merci

lor commented

Bonjour,

Ce sont là d'excellentes questions, et qui mettent une nouvelle fois en lumière le besoin de "contextes" de traduction.

1- Je ne sais pas... Des exemples ?

2- Il me semble que Ubercart est déjà traduit ou en cours de traduction (à vérifier), ce qui peut t'éviter ce travail. Effectivement, D6 ne prend pas en compte le contexte, ce qui devrait être corrigé dans D7. Ton cas pour l10n est intéressant. Je pense que dans le cas où un module n'est pas traduit, une traduction spécifique vaut mieux que rien. De plus, si elle est correctement faite (homogène), on pourrait par un "chercher-remplacer" en base remplacer les termes "réservation" par "commande" pour en faire une traduction générique, fonctionnalité qui n'est malheureusement pas proposée dans po edit (un jour peut-être !). Il serait pour cela bien d'avoir un endroit où les contributeurs pourraient indiquer les termes posant question, ce qui faciliterait le travail des admins. A étudier. "Order" est un cas intéressant car il peut aussi signifier un ordre de tri, usage fréquent dans Drupal (notamment avec les vues), d'où la nécessité des contextes.

3- Non pas de perturbation car cela se traduira sur localize par des suggestions de traduction validée ou non par les admins.
Dans le cas où ta suggestion n'est pas acceptée par un admin, elle est effacée de localize, donc "perdue". Il n'y a aucun moyen à l'heure actuelle de faire des suggestions en fonction du contexte. Si une traduction est "verrouillée" (demande de fonctionnalité faite à Gabor : http://drupal.org/node/631906), ta suggestion ne sera pas postée.

sbordage commented

1 - Oui, il arrive très souvent que le .po présent dans le module qu tu télécharges soit un .po vide ou presque vide car le développeur n'a pas pris en compte les trads commitées via le CVS. C'est d'ailleurs en parie pour cela que localize.drupal.org existe ;-)

2 - La meilleur méthode de trad pour du spécifique est expliquée en détail ici : http://www.slideshare.net/sbordage/how-to-translate-a-drupal-module Par ailleurs, nous avons traduit et commité plusieures trad Ubercart (Slybud et moi, sbordage) sur http://l10n.privnet.biz/translation_group/french.

3 - Perso je n'utilise pas l1On client

Bon courage, Stéphane

flebas commented

A Jimi,

La traduction Ubercart est à peu près complète pour un usage général (il manque essentiellement les utilistaires et les passerelles de paiement et d'expédition qui ne sont en général pas utilisés en France) sur http://l10n.privnet.biz/translate/languages/fr?project=ubercart.

Pour un usage spécifique (pharmacie dans ton cas), je pense qu'il est mieux de ne pas modifier la traduction générale.
Tu récupères le fichier de traduction et tu le modifies avant de l'importer.

Pour le point 3, les traductions ne sont pas modifiées lors de l'installation des mises à jour.

jimi commented

Merci de ta réponse, j'ai traduit tout ce qui apparaissait côté visiteur et une bonne partie de ce que mon client doit comprendre (il ne parle pas un mot d'anglais…).
Il y a des tas de termes comme le mot "produit" qu'il m'a fait changer et remplacer par "préparation". Je ferai l'essai d'importer le fr.po pour voir si c'est sans danger sur ma version en local (mais pour l'instant une mise à jour de mySql sur mon mac a tout planté… j'ai du ménage à faire lol).