Crédits Photo : Salt and Pepper by Randen Pederson, on Flickr

En 2014, à l'occasion du WordCamp San Francisco, Andrew Nacin nous parlait brillamment de l'importance de l'internationalisation pour WordPress. Si vous n'avez pas vu sa conférence, je vous conseille vivement d'en prendre connaissance depuis WordPress.TV.

Il termine notamment son propos par 3 taux qui démontrent le caractÚre stratégique de proposer WordPress dans la langue native de chacun d'entre nous :

Les 2/3 des sites WordPress sont en anglais.
10% de la population mondiale parle anglais
L'anglais est la premiĂšre langue pour seulement 5%

Je crois que nous sommes tous d'accord avec son propos. Toutefois, "se globaliser" ne doit pas se transformer en se "totalitariser". En d'autres termes, une meilleure accessibilitĂ© pour le plus grand nombre ne doit pas empĂȘcher certains contextes particuliers de profiter de WordPress dans "l'ambiance textuelle" qui leur convient le mieux. Ou plus simplement, il faut laisser le choix de pouvoir utiliser une traduction personnalisĂ©e de WordPress et en particulier lorsqu'il s'agit de ses extensions.

4.6 "Pepper" : un poivre difficilement digérable!

Alors que le poivre, selon certaines études, participerait à améliorer la digestion et à stimuler l'appétit, j'avoue que certaines évolutions de la version 4.6 de WordPress et ce que je considÚre comme une régression ont du mal à passer!

Commençons par Ă©vacuer load_plugin_textdomain(). Les gains des évolutions apportĂ©es sont selon moi discutables. Pour l'utilisateur final, il s'agit de bĂ©nĂ©ficier d'une traduction Ă  jour pour ses extensions et donc de prioriser le chargement de celles qui sont automatiquement gĂ©nĂ©rĂ©es par le systĂšme "GlotPress" et donc qui sont le fruit d'un super travail de la communautĂ© Polyglots de WordPress. Ce qui fonctionne effectivement parfaitement dans le meilleur des mondes. Si je me positionne du cĂŽtĂ© du dĂ©veloppeur de l'extension, si ce dernier est anglo-saxon ou non anglo-saxon et qu'il n'a pas envie de faire en sorte que ses compatriotes puissent profiter immĂ©diatement des mises Ă  jours intervenues dans les textes utilisĂ©s par l'extension: c'est gĂ©nial. Il n'a plus Ă  s’embarrasser Ă  traduire l'extension dans sa langue native, seul le fichier ".pot" reste Ă  gĂ©nĂ©rer.

En revanche, si comme moi le dĂ©veloppeur d'extensions se soucie des utilisateurs de son pays (Cocorico), c'est ennuyant car cela veux dire qu'ils auront besoin d'attendre que la communautĂ© Polyglots mette Ă  jour la traduction de l'extension. Comme il y en a une tripotĂ©e (un peu moins de 47000), ça peut ĂȘtre relativement long. Alors me direz-vous : rien n'empĂȘche au dĂ©veloppeur de l'extension de mettre Ă  jour la traduction sur GlotPress… Ahah! Voici le comble du comble: figurez-vous qu'en tant que concepteur de l'extension, nous n'avons pas accĂšs Ă  la validation de nos mises Ă  jour pour notre langue!!!! Je peux proposer des mises Ă  jour mais un "Translator Editor" doit les valider.

Bref, comme l'annonçait Andrew Nacin dans sa confĂ©rence, les auteurs d'extensions Ă©crivent des extensions et n'ont pas Ă  se soucier des traductions. Parfois, je me demande : si les auteurs anglo-saxons avaient Ă  Ă©crire leurs extensions en français avant de les traduire en anglais dans de telles conditions, la donne serait-elle la mĂȘme ?

Ceci Ă©tant dit, le changement d'ordre de chargement des fichiers de langue dans load_plugin_textdomain() n'est objectivement pas si grave que ça puisqu'il reste une chance qu'un jour l'extension soit finalement traduite 🙂

Selon moi, la décision la plus discutable de la version 4.6 concerne une fonction privée de WordPress intitulée _load_textdomain_just_in_time(). D'abord, je vais commencer par m'excuser car, malgré que je travaille avec la version "trunk" de WordPress au quotidien, je ne me suis aperçu que trÚs tard de son aspect néfaste. Ensuite, prenons quelques minutes pour identifier les symptÎmes du "dysfonctionnement" rencontré (trÚs particulier) et expliquer pourquoi c'est de mon point de vue (et de celui de mon employeur!) une véritable régression pour les "intranets" qui utilisent WordPress.

Illustration de la gestion du chargement des catalogues de langue dans bbPress.

On l'a vu un peu plus haut pour charger la traduction d'une extension, WordPress prĂ©conise d'utiliser la fonction load_plugin_textdomain(). Toutefois, certaines extensions populaires, telles que bbPress offrent la possibilitĂ© de charger un catalogue de langue alternatif dans la mesure oĂč il est localisĂ© Ă  un endroit bien particulier de l'arborescence de notre WordPress. Voici comment procĂšde bbPress :

Comme vous pouvez le lire dans les commentaires que j'ai ajoutés au code, bbPress commence par tenter de charger une traduction (le fichier .mo) hypothétiquement disponible dans un sous répertoire bbpress du répertoire des languages de WordPress (celui qui est définit dans la constante WP_LANG_DIR). Ensuite il tente de charger un hypothétique fichier de traduction depuis un sous répertoire de l'extension avant de se reposer sur ce que préconise WordPress. Pour cela il utilise la fonction load_textdomain(). La particularité de cette fonction est qu'à l'inverse de ce qu'on peut connaßtre dans les "hooks de la Plugin API", ce n'est pas celui qui intervient en dernier qui a le dernier mot, mais au contraire celui qui est le premier (???!!??). Cela veut dire que dés qu'un fichier de langue est chargé, plus personne ne pourra le modifier. La seule possibilité d'intervention sera le "déchargement" grùce à la fonction unload_textdomain().

Or jusqu'avant la 4.6 cette possibilitĂ© d'utilisation d'une traduction alternative Ă©tait essentiel (et l'est toujours!!) lorsqu'on utilise WordPress dans le cadre d'Intranets Corporate. En effet, si je prends l'exemple d'une extension de rĂ©seau social, il est complĂštement farfelu d'utiliser le terme "amis" dans une entreprise. On parlera volontiers de contacts, collĂšgues, relations… mais certainement pas de potes!

Depuis la 4.6, la plupart des gestions alternatives offertes par ces extensions ne fonctionnent plus. La faute Ă  _load_textdomain_just_in_time(). Pourquoi ? Tout simplement parce que cette fonction va trĂšs tĂŽt regarder si des fichiers de traduction gĂ©nĂ©rĂ©s par GlotPress sont disponibles et les charge. RĂ©sultat lorsque bbPress tente de charger notre fichier de langue alternatif, rien ne se passe puisqu'il n'est pas le premier Ă  le faire. Alors, il y a trois semaines, j'ai suggĂ©rĂ© un patch pour changer le comportement de load_textdomain() afin que les fichiers de langue alternatifs puissent ĂȘtre toujours utilisĂ©s tout en gardant le bĂ©nĂ©fice de ce chargement "autoritaire". A ce jour, le ticket est toujours en "Awaiting Review", donc j'imagine qu'il n'est pas considĂ©rĂ© comme une difficultĂ© importante et qu'il n'est pas prĂȘt d'intĂ©grer le core (en fait je n'y crois carrĂ©ment plus!).

Tu n'as pas arrĂȘtĂ© de nous louer les avantages de WordPress pour notre Intranet, cette petite pĂ©ripĂ©tie illustre deux choses : les spĂ©cificitĂ©s liĂ©es au monde de l'entreprise sont nĂ©gligĂ©es dans la phase de conception et ne sont pas prioritaires dans la phase de correction.

C'est ce que m'a dit un de mes collĂšgues pour me chambrer. Je comprends son point de vue, mĂȘme si ramenĂ© Ă  la tonne de services rendus, il est Ă  modĂ©rer. Alors, il faut aller de l'avant et faire avec. Comme l'explique cet article, on peut neutraliser cette trĂšs odieuse fonction privĂ©e grĂące Ă  la Plugin API de WordPress.

Si je me place du cĂŽtĂ© auteur d'une extension, comme il s'agit d'une course contre la montre pour ĂȘtre le premier Ă  utiliser load_textdomain(), on peut toujours tenter d'ĂȘtre avant "just in time" 🙂 Par exemple pour bbPress, ce code permet de rĂ©tablir les traductions alternatives.

Mais bon, si vous ĂȘtes comme moi avec des traductions alternatives pour quasiment chaque extension, il va falloir utiliser une astuce de ce type :

Pour finir, je pense que bien que _load_textdomain_just_in_time() soit rĂ©putĂ©e comme "amĂ©liorant la performance", elle ne s'imposait pas si tĂŽt 🙂 Les Ă©volutions apportĂ©es Ă  load_plugin_textdomain() ne sont pas mises Ă  profit car de toutes façons les fichiers de langue GlotPress sont dĂ©jĂ  chargĂ©s (ceinture et bretelles) ! WordPress aurait pu et dĂ» attendre un cycle de dĂ©veloppement supplĂ©mentaire afin que les extensions qui proposent des dispositifs de chargement alternatif de catalogues de langue puissent s'adapter. Par ailleurs, je regrette que rien ne soit structurĂ© pour prendre en compte ce besoin de traductions alternatives. De la mĂȘme maniĂšre qu'il y a un dossier pour les traductions standardisĂ©es, un dossier pour les alternatives pourrait coexister.

En revanche, je reconnais que pour le développeur d'extensions anglo-saxon ou celui pour qui ce n'est pas important que son extension soit disponible simultanément en anglais et dans sa langue natale, la vie est belle!

Voilà, j'avais juste besoin de faire mon rùleur français de base sur cette question et vous faire part de mon inquiétude quant aux prochaines astuces qu'il faudra mettre en oeuvre dans l'avenir pour pouvoir "lire WordPress" de maniÚre adaptée au contexte dans lequel on l'utilise.

13 rĂ©flexions au sujet de « WordPress 4.6 : un grain de sel dans le poivrier »

  1. danbp

    +100! Et pan dans leur g…. Je pense mĂȘme qu’il faudrait le faire savoir de maniĂšre trĂšs forte, en pĂ©titionnant par exemple, avant que le « totalitarisme » que tu Ă©voques ne devienne irrĂ©vocable.
    On a dĂ©jĂ  eu du mal Ă  s’accorder aux rĂšgles de typo anglo-saxonnes, aux expressions argotiques de type Howdy ou Cheatin, huh ? Si en plus il faut dĂ©sormais ne s’appuyer que sur le systĂšme GlotPress, ça sent la fin des projets hors normes ou pas grand public Ă  moyen terme.
    La politique WP du « presse bouton, utilisable en 5 mn » prend de plus en plus le pas sur l’aspect personnalisable Ă  volontĂ©.
    C’est non seulement une rĂ©gression, mais aussi une perte de crĂ©ativitĂ© et une forme d’enfermement idĂ©ologique aux contours flous, mais bien prĂ©sent, qui s’ammorce.

    1. imath Auteur

      Merci pour ton commentaire et ton avis sur la question Dan. Je crois qu’objectivement le fait d’avoir sĂ©parĂ© dans un sens la traduction du code du plugin est vraiment une bonne chose. Je suis incapable par exemple de faire en sorte de traduire mon extension en allemand, et grĂące Ă  ce systĂšme ça devient possible. Ce qui me dĂ©range beaucoup plus c’est une sorte de perte de contrĂŽle sur la version française de mes extensions alors que je pense ĂȘtre le mieux placĂ© pour utiliser le texte qui reflĂšte ce que je code. Par ailleurs je trouve « injuste » que les utilisateurs qui sont ma cible prioritaire soient lĂ©sĂ©s par rapport Ă  une cible qui est plus Ă©loignĂ©e. D’ailleurs on arrive Ă  une situation Ă©trange dans laquelle une version anglaise de mes extensions est validĂ©e d’emblĂ©e alors que je ne maĂźtrise pas cette langue et que prĂ©cisĂ©mment GlotPress pourrait ĂȘtre utile et Ă  cĂŽtĂ© de ça une incapacitĂ© (par dĂ©faut) Ă  valider la langue que je maĂźtrise. Ça me parait complĂštement idiot!
      J’ai utilisĂ© le terme par dĂ©faut, car j’ai pu me rendre compte qu’en demandant aux bonnes personnes on peut devenir translator editor 🙂
      A ce sujet, ça devrait ĂȘtre automatique, tu es un auteur d’exrensions françaises > tu es un translator editor pour tes extensions dans ta langue, pas besoin de demander.
      WordPress me semble-t-il a mis la charue avant les boeufs, il aurait Ă©tĂ© bcp plus logique de s’assurer que l’automatisme que j’Ă©voque soit en place pour Ă©viter le dĂ©sĂ©quilibre.

      Traductions alternatives: mon regret, WordPress semble ignorer ce sujet et c’est vraiment dommage. MĂȘme si dans leur idĂ©e j’imagine que c’est une affaire d’extensions (premiums, sans doute!), il me semble important pour les utilisateurs que WordPress l’organise un minimum car sinon ces extensions mettront les fichiers n’importe oĂč et ça sera une galĂšre quand on voudra changer d’extension. Il suffit d’un simple WP_LANG_DIR . ‘/alt’ ou WP_LANG_DIR . ‘/plugins/alt’ par exemple.

      La fonction privĂ©e que j’ai Ă©voquĂ©e c’est aussi « mettre la charue avant les boeufs » car en faisant ce changement ils ont cassĂ© les mĂ©canismes existants dans toutes les extensions que mon entreprise utilise: BuddyPress, bbPress, etc… Il aurait mieux valut s’assurer, comme il s’agit d’un pĂ©rimĂštre qui ne touche que les extensions et les thĂšmes, qu’il n’y avait aucun risque de ce type avant de faire ce commit. C’Ă©tait facile il suffisait de demander Ă  l’Ă©quipe core d’une des deux extensions que j’ai citĂ©es! Ensuite une communication pour dire ce qu’on allait faire en release + 1, les extensions s’adaptent et le client final est satisfait au moment ou c’est finalement intĂ©grĂ© au core, car il bĂ©nĂ©ficie du gain de perf sans perte de fonctionnalitĂ©!

      Dommage.

    2. imath Auteur

      Je me rends compte que je n’ai pas rĂ©pondu sur la question de la pĂ©tition. Je crois que dans le cas prĂ©sent le geste doit ĂȘtre plus fort et ĂȘtre l’expression des dĂ©veloppeurs d’extensions ou de thĂšmes non anglo-saxons. Aussi pour ma part je dĂ©cide que si je ne peux pas maĂźtriser la version française de mes extensions sur le repository WordPress.org alors je ne dĂ©poserai pas mes prochaines extensions dessus. Si tout le monde fait la mĂȘme chose, ça devrait changer 😉

  2. Daniel Farnier

    Bonjour Mathieu,

    Pourquoi ne pas rendre les fonctions de sélection de domaine de traduction pluggables ?

    Cela donnerait une souplesse maximale.
    Dans un environnement d’entreprise, on pourrait aisĂ©ment introduire des fichiers de traduction suivant les dĂ©partements.
    Par exemple :
    – plutĂŽt que d’afficher « Veuillez contacter le responsable de trucmuche »
    – on afficherait « Veuillez contacter Mme machin (tel : xxxxx), responsable de trucmuche » pour le dĂ©partement « avous ».

    Si madame machin est remplacĂ©e par monsieur chose, l’affichage peut ĂȘtre modifiĂ© rapidement de façon ciblĂ©e.

    Ma remarque vient en complément de à ce qui a été écrit plus haut, le fonctionnement par défaut devant permettre de nouveau de maßtriser le fichier de traduction utilisé.

    Daniel

    1. imath Auteur

      Salut Daniel,

      Je pense que la plugin API est beaucoup plus souple et secure que les fonctions pluggables (imaginons que deux plugins utilisent la mĂȘme fonction > white screen of death). D’ailleurs si tu lis cette page du codex, tu t’apercevras que WordPress a cessĂ© d’utiliser ces fonctions pluggables au profit des filtres de la plugin API 🙂

      Je n’ai pas bien saisi ce que tu souhaites faire mais on doit pouvoir y arriver avec les filtres existants.

  3. Webyc

    Bonjour,

    N’ayant pas encore eu le temps de me pencher sur mes plugins implĂ©mentant des traductions, j’aurai voulu savoir si vous aviez un retour d’expĂ©rience concernant la rĂ©solution possible ou non de cas de figure avec le filtre override_load_textdomain ?

    1. imath Auteur

      Bonjour Webyc,

      J’ai lu que cet article conseillait d’utiliser override_load_textdomain. Je dirais que ça dĂ©pend de l’objectif recherchĂ©. Je pense que si on souhaite charger un fichier de langue alternatif, ce n’est absolument pas le filtre Ă  utiliser. load_textdomain_mofile me semble bien mieux adaptĂ©, puisqu’il attend un fichier mo en retour et que nous n’altĂ©rons en rien la gestion des traductions de WordPress.
      En revanche, si mon objectif avait Ă©tĂ© de complĂštement remplacer la gestion du chargement des fichiers de traduction de WordPress, alors effectivement j’aurai utilisĂ© override_load_textdomain. En d’autre terme, si je retourne true Ă  ce filtre alors plus aucune traduction ne sera chargĂ©e par WordPress, je devrais concevoir ma propre logique pour que le site soit traduit.

  4. Sadler

    Bonjour Mathieu, merci pour ce billet. Je comprends ton agacement par rapport Ă  cette sensation de perte de contrĂŽle de ton projet. Surtout du fait que tu es un public particulier pour tes extensions. De notre cĂŽtĂ© nous avions vu un peu le coup venir, je t’avais donnĂ© le lien vers notre projet sur GitHub, depuis il a Ă©tĂ© validĂ© sur wp.org : https://wordpress.org/plugins/wpt-custom-mo-file/ .

  5. fxbenard

    Salut Mathieu,

    Je me permets d’intervenir sur ton article pour clarifier 2-3 points.

    PremiĂšrement je suis tout Ă  fait d’accord avec toi sur les changements au niveau de la prioritĂ© des traductions dans le Core depuis la 4.6. Cela ne donne plus facilement le moyen de crĂ©er des traductions personnalisĂ©es. D’oĂč notre extension avec @G3ronin0 😉

    Pour ce qui concerne l’accĂšs aux traductions sur translate.wordpress en tant que PTE, il suffit de les demander, 2-3 recommandations Ă  suivre et voilĂ . Il n’a jamais Ă©tĂ© question d’empĂȘcher qui que ce soit de traduire sa propre extension. Nous veillons juste Ă  ce que les termes du glossaire soient suivis et que 2-3 rĂšgles de typo soient connues.

    Cela n’est pas fait CONTRE les dĂ©veloppeurs mais POUR eux et POUR les utilisateurs finaux.

    Demande Ă  Willy ou WabĂ©o par exemple, je ne pense pas qu’ils te diront le contraire. L’on peut ĂȘtre un trĂšs bon dev mais pas connaitre toutes les finesses de la traduction de WordPress. L’équipe de traduction est Ă  VOTRE service. Je suis navrĂ© si tu as eu un ressenti diffĂ©rent et je vais tacher Ă  ce qu’il change. Nous essayons d’amĂ©liorer votre produit et par la mĂȘme l’ENSEMBLE du projet WordPress.

    AprĂšs ne t’inquiĂšte pas trop lors du premier import de ton projet sur translate, si ta traduction y est disponible, elle est automatiquement importĂ©e et VALIDÉE.

    PS : @Dan il est pas bien notre nouveau Cheatin’ Huh du glossaire 😉

    A plus les gars,
    FX

    1. imath Auteur

      Merci FX pour ces prĂ©cisions. Je n’ai aucun reproche Ă  adresser Ă  l’Ă©quipe fr_FR de translate. Je confirme que pour le plugin WP Idea Stream, j’ai rapidement Ă©tĂ© promu en tant que Translator Editor pour la version française de ce plugin.

      D’ailleurs je crois que j’aborde ce point dans mon article Ă  un moment donnĂ©. Mon problĂšme est plus global, alors peut-ĂȘtre que je me suis mal exprimĂ©.

      En tant que concepteur de l’extension et Ă©tant donnĂ©s les derniers changements intervenus dans le core de WordPress, on devrait ĂȘtre automatiquement Translator Editor pour notre langue. Ou autrement dit, avant de faire de tels changements dans le core, WordPress devrait s’assurer que chaque auteur de plugin non anglo-saxons est translator editor pour ses plugins.

      Je viens de vĂ©rifier ce n’est pas le cas 😉

      Je suis trĂšs déçu que les core committers aient fait ce choix si rapidement et sans vĂ©ritablement consulter les dĂ©veloppeurs d’extensions/thĂšmes dont la langue natale n’est pas l’anglais. Je sais bien que WordPress n’est pas une dĂ©mocratie, mais bon, sur ce sujet prĂ©cis, ça aurait mĂ©ritĂ© plus de concertations.

      Enfin, je ne m’inquiĂšte pas trop, j’attends de voir si l’automatisme PTE ne se concrĂ©tise pas ou si le rĂ©sultat du ticket que j’ai dĂ©posĂ© est nĂ©gatif, je trouverai un autre moyen de diffuser mes extensions.

      A+

      1. fxbenard

        Me voilĂ  rassurĂ© alors. Pour la fonctionnalitĂ© d’auto PTE pour les auteurs, cela n’a pas l’air d’en prendre la direction. Mais qui sait ? Good luck avec ton patch.

        La prochaine fois que je monte sur Paris, il faut qu’on arrive Ă  se faire un petit truc avec toute l’équipe.

        ++

Les commentaires sont fermés.