WordPress 4.6 : un grain de sel dans le poivrier

Publié le

20 septembre 2016

par

imath

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.

Publié dans WordPress,

étiquetté i18n.

13 réponses à “WordPress 4.6 : un grain de sel dans le poivrier”

danbp

20 septembre 2016 – 18h55

+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
  
  21 septembre 2016 – 6h29
  
  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
  
  21 septembre 2016 – 6h57
  
  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 😉
Daniel Farnier

21 septembre 2016 – 8h48

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
  
  21 septembre 2016 – 13h29
  
  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.
Webyc

21 septembre 2016 – 10h42

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
  
  21 septembre 2016 – 13h21
  
  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.
Sadler

21 septembre 2016 – 18h59

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/ .
1. imath
  
  22 septembre 2016 – 1h34
  
  Hello Jérôme,
  
  Merci de me le rappeler, il faut que je regarde 🙂
fxbenard

23 septembre 2016 – 14h43

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
  
  23 septembre 2016 – 18h34
  
  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
    
    23 septembre 2016 – 23h43
    
    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.
    
    ++
    1. imath
      
      24 septembre 2016 – 8h15
      
      Avec plaisir, bisous 😉