Retour d’expérience sur WPML et un WordPress multilingue

Mon premier grand projet avec WordPress en tant que Content Management System (CMS), était en 2009, pour ÉCU, le festival européen de film indépendant à Paris.

J’avais conçu leur site existant en simple HTML, reprenant le travail de mon prédécesseur en utilisant des sous dossiers pour gérer quatre langues supplémentaires.

Cette migration vers un CMS donnerait aux organisateurs, et à leur équipe de bénévoles, la réactivité et l’autonomie nécessaires pour publier rapidement des soumissions de films et informations sur les réalisateurs, au fur et à mesure qu’elles arrivaient. Alors que le festival se déroulait en Anglais, puisqu’il était basé à Paris, les organisateurs ressentaient l’obligation que le site soit aussi en Français. Et puisque c’était un festival avec des participants venant des quatre coins du globe, ils souhaitaient en plus maintenir autant de langues que possible par respect de ces derniers.

J’avais choisi WordPress parce que j’étais à la fois plus familiarisée et plus confiante avec lui que d’autres CMS tels que Drupal ou Joomla, et puis des retours de collègues m’ont assuré que c’était le meilleur choix possible. Le problème : à la différence des autres CMS, WordPress ne proposait pas le multilinguisme en natif (et ne le fait toujours pas). Je suis donc partie à la recherche d’un plugin pour combler ce manque.

Les bases d’un site multilingue

À vrai dire, je n’avais encore pas beaucoup d’expérience avec les sites multilingues à cette époque. J’en avais développé seulement quelques uns avec pas plus de deux langues, et sans composant de gestion de contenu ou base de données derrière.

Dans ces cas-là, mon objectif principal était de donner une bonne expérience à l’internaute : de faire en sorte qu’il puisse naviguer avec fluidité d’une page à l’autre et d’une langue à l’autre. C’était moi la responsable de l’intégration des contenus, donc, la complexité de la question se limitait à une navigation cohérente et fiable. Il n’y avait qu’une source de contenu — mes pages HTML— qui existaient en copies multiples ou avec des sections de page dédiées à chaque langue.

J’avais également appris en travaillant sur ces projets que, alors qu’il y a souvent une grande ambition de la part des clients de publier tous les contenus dans chaque langue, c’est plus vite dit qu’accompli. Plus que jamais, on se retrouvait avec des trous, là où la traduction n’existait pas, soit parce que le client n’avait pas pu la fournir, soit parce qu’elle n’était pas pertinente pour une langue.

Ma compréhension des besoins d’un site multilingue se résumaient donc à :

• La navigation front-end entre langues (à l’époque en forme de petits drapeaux) ;
• La connectivité entre les différentes versions d’un contenu (une page ou un article) pour une continuité de navigation ;
• Une manière de gérer les traductions manquantes et un comportement par défaut ;

La nature plus complexe d’un site WordPress multilingue

La nature même d’un CMS crée un scenario où le contenu ne vient plus d’une source, mais de sources multiples. C’est une plateforme composée de :

1. Le logiciel de base (ou le “core”) ;
2. Un thème qui sert d’habillage graphique ;
3. Des extensions (plugins) pour rajouter de la fonctionnalité ;

Chacun des composants de l’infrastructure du site contient des chaines de caractères, qui doivent eux aussi être traduits, et que l’utilisateur pourrait souhaiter modifier. Rajouter par-dessus tout cela le besoin de gérer les profils utilisateurs, des chaines de caractères diverses stockées dans les options de la base de données (titre et sous-titre du site), et d’autres sources de contenu telles que les widgets, et soudain il y a beaucoup plus de choses à prendre en compte que juste une page ou un article.

Enfin, et non le moindre, il y a l’utilisateur lui-même. Je ne parle pas de l’utilisateur final, l’internaute, mais l’utilisateur, mon client, qui veut l’autonomie sur la gestion de ses contenus et qui n’est pas équipé pour répondre à ces questions complexes (et qui ne devrait pas l’être). La plupart des utilisateurs ne veulent pas savoir comment fonctionne un site ou pourquoi. Ils ne veulent pas rentrer dans la technique. Ils veulent simplement un moyen rapide et facile / efficace pour publier leur contenu.

Ma compréhension s’est élargie pour englober les besoins plus avancés d’un site multilingue avec WordPress :

• Support pour les chaines de caractères des thèmes ;
• Support pour les chaines de caractères des plugins ;
• La traduction des media (les métadonnées des images) ;
• Support pour les métadonnées d’un profil utilisateur, les chaines de caractères dans les options et dans les widgets ;
• Des interfaces graphiques dites user-friendly pour la traduction des multiples sources de contenu ;
• Support pour la gestion du travail de traduction et les différents intervenants ;

À l’époque il y avait encore moins de plugins multilingues disponibles pour WordPress que ce que l’on connait aujourd’hui. Sur la recommandation d’un collègue, j’ai choisi ZDMultilang. De mémoire il était plutôt facile à installer, mais très limité en terme de fonctionnalités. Il était aussi difficile à mettre en forme côté front-end et la navigation entre versions d’une page, surtout en l’absence d’une traduction, n’était pas très fiable.

Au final je ne fus pas en mesure de livrer une solution multilingue satisfaisante avec WordPress et ZDMultilang. Heureusement pour moi, le client n’arrivait pas mieux à fournir les traductions, et on a décidé ensemble de rester sur une version avec une seule langue.

Diviser pour mieux régner

Une petit avancée dans le temps jusqu’en 2011 et le prochain projet où je me suis retrouvée confrontée avec la problématique multilingue. La première version commerciale de WPML était sortie et une chose m’a immédiatement marquée : au lieu d’un seul plugin pour gérer l’ensemble des différents besoins, WPML proposait plusieurs plugins, chacun avec une fonctionnalité spécifique. C’était, et je maintiens que ça l’est toujours, une approche très maline, qui montrait que les gens derrière comprenaient réellement les enjeux.

Je l’ai installé, configuré et ça a marché. L’interface intuitive a donné à ma cliente un moyen simple et efficace pour gérer son contenu, en basculant de l’anglais au français comme voulu, même dans les widgets. La documentation mise à disposition sur le site WPML m’a permis d’intégrer la navigation facilement dans mon thème et de manière homogène. Certes, il fallait que j’achète une licence, mais ce coût fut absorbé par la cliente, et valait largement l’investissement pour nous deux. En fait, il est probable que WPML fût le premier plugin m’ayant convaincu de l’intérêt d’investir dans les plugins premiums.

Vue d’ensemble de la suite WPML 

Multilingual CMS

Ceci est l’extension principale qui propose :

• Choix de langues ;
• Structure URL ;
• Choix de navigation entre langues, sa mise en forme et l’emplacement ;
• Options pour la redirection et la reconnaissance de langue du navigateur ;
• Options SEO ;
• L’interface de base pour la traduction des pages et les articles ;

Translation Management

Cette extension a deux fonctionnalités principales : support étendu pour la traduction des custom post types et les taxonomies, et un système de gestion des traductions et leur traducteurs. Elle est souvent pré-requise quand WPML est utilisé en tandem avec d’autres plugins tels que WooCommerce.

String Translation

Lit des chaines de caractères traitées au préalable dans des conteneurs gettext des thèmes et des plugins, avec une interface graphique pour la traduction manuelle de ces chaines. Alors que WPML permet l’utilisation simultanée des fichiers .po / .mo, cette extension est aussi requise par certains plugins tels que WooCommerce.

Media manager

Cette extension plus récente gère la traduction des métadonnées des images. Elle permet à l’utilisateur de choisir entre télécharger une nouvelle image pour la traduction d’une page ou un article, ou bien d’utiliser la même image physique que celle utilisée dans la langue d’origine, mais avec la possibilité de traduire le titre, texte alternatif, légende et descriptif de l’image, et ce pour chaque langue.

Sticky Links

Sensé empêcher les liens internes du site d’être rompus. J’avoue n’avoir jamais utilisé cette extension.

Il existe également des extensions proposées par WPML qui permettent la traduction des contenus venant de plugins tiers tels que WooCommerce et Gravity Forms, ainsi qu’une extension pour tester la comptabilité des thèmes.

Il n’y a pas de solution parfaite, pas encore.

En général, quand je trouve un produit qui fonctionne bien pour moi, je ne cherche pas plus loin. Je me sert de WPML depuis ce jour-là avec succès, pour des projets des plus simples aux plus complexes et ce jusqu’à quatre langues. Cependant, aucune des solutions existantes à ce jour ne sont parfaites.

Ayant travaillé avec WPML depuis environ quatre ans, et en tant que sous-traitante WPML pour un peu plus d’un an, je suis bien renseignée sur ses inconvenants, sources de frustration et causes de critiques pour beaucoup de gens.

Performance

La performance est l’une des plus grandes faiblesses de WPML. Il crée 16 tables supplémentaires dans la base de données afin de gérer ses différents composants et stocker les informations. Quand un utilisateur accède à une page traduite, de multiples requêtes (visites à la base de données) sont nécessaires pour d’abord reconnaitre la source du contenu et voir si la traduction existe, puis trouver l’identifiant correspondant pour la langue demandée, et enfin retourner le contenu traduit. Pour des pages plus complexes, ceci veut dire aussi : traductions des taxonomies, champs personnalisés, chaines de caractères, plugins des tierces parties, etc. Ça fait beaucoup de travail supplémentaire qui augmente le temps nécessaire pour charger la page dans le navigateur.

Depuis quelques versions, WPML a fait des améliorations significatives sur la performance. Utiliser les bonnes pratiques à la réalisation des thèmes, s’appuyer sur les fichiers .po / .mo le plus possible au lieu de faire traduire des chaines de caractères via l’extension String Translation, et travailler en étroite collaboration avec son hébergeur pour optimiser le cache de son site, voire employer un plugin tel que WP Rocket, sont toutes des démarches bénéfiques, qui peuvent améliorer la rapidité de chargement d’un site.

Ça casse

Combinez WordPress avec deux, trois ou quatre extensions WPML, une série d’autres plugins qui pourrait oui ou non avoir besoin d’interagir avec WPML, et un thème qui pourrait oui ou non être codé aux standards WordPress, alors on peut imaginer toutes les possibilités pour que ça casse. Quand les gens dissent, “c’est cassé,” en général c’est qu’ils ne voient pas les comportements attendus, très souvent à cause d’un conflit quelque part. Ce n’est pas autant une question d’être cassé, que le fait que tous ces différents éléments ne fonctionnent pas toujours très bien ensemble. Il est facile de pointer du doigt, mais WPML est un logiciel complexe à qui l’on demande d’accomplir une mission tout aussi complexe.

Support

Ce qui m’amène au support. Le support technique chez WPML peut être bien, comme il peut être décevant, mais je dirais que là aussi, ils se sont beaucoup améliorés dernièrement. Les plaintes principales que j’ai pu avoir avec le support sont de longs délais pour obtenir une réponse, puis de trop nombreux aller-retour avant de progresser sur un problème. Mais la plus grande difficulté est que les choses se cassent (voir ci-dessus), et la source du problème peut être très difficile à déterminer.

Lorsque je travaillais comme sous-traitant WPML, la raison n° 1 des choses qui “cassaient” était l’utilisation de thèmes premium, non-conforme aux standards WordPress. Mêmes certains thèmes vendus comme étant compatibles WPML n’expliquent pas spécialement bien aux clients comment s’en servir, et au lieu d’offrir un support technique, ils ont tendance à renvoyer les acheteurs à WPML pour résoudre leurs problèmes. Mais ce n’est pas à WPML de résoudre un problème de thème.

Bugs

Je ne dirais pas qu’il n’y a pas de bugs. Là encore, c’est plus souvent des cas de conflits qui peuvent arriver et qui prennent du temps à résoudre. Un des problèmes récurrents concerne le cas où des slugs de pages ou de catégories (des parties d’un URL) peuvent être les mêmes pour plusieurs langues. Ce sont des problèmes complexes à solutionner. 

Ça marche pas, ma page n’est toujours pas traduite.

Une des demandes de support régulière qui était une source d’amusement considérable pour moi, venait des gens qui ne comprenaient pas que WPML ne traduisait pas leurs textes. Non, WPML ne traduit pas les textes ; il est simplement un outil pour gérer la traduction des textes. Mais la société derrière WPML, OnTheGoSystems Inc., propose des services de traduction sous le nom iCanLocalize, qui s’intègrent directement au sein de WPML. Il faut, bien sûr, les payer en plus. Je me demande parfois si ce n’est pas justement cette activité parallèle qui est la cause de confusion sur ce point…

L’avenir du WordPress multilingue

Au WordCamp Europe à Séville cette année, pendant son Q&A (38:50-43:05), Matt Mullenweg a soulevé la question de pourquoi le multilinguisme n’est pas native à WordPress en mentionnant le fait qu’il n’y avait aucune statistique établie pour déterminer quel pourcentage de la base utilisateur WordPress—faible ou élevé—réclame cette fonctionnalité. “Dans l’absence de [données], nous maintenons le statuquo de laisser ces choses aux plugins,” a-t-il dit.

Il a donné deux suggestions à ceux qui sont passionnés à l’idée d’intégrer le multilinguisme au WordPress core :

1. Introduire une solution en forme de plugin, et gagner le soutien de la communauté grâce à des réunions régulières sur le Slack du Making WordPress: si le plugin fonctionne assez bien, et le soutien est présent, les développeurs principaux de WordPress pourraient être amenés à le considérer ;
2. Obtenir des statistiques : avoir une information concrète sur l’utilisation actuelle des sites multilingues parmi la base utilisateur existante, pour valider oui ou non l’importance du besoin, et donc si elle devrait constituer une priorité ;

Deux jours plus tard, lors du Contributor Day, un petit groupe s’est réuni à l’initiative de Simon Wheatley (Automattic, précédemment Code for the People) pour parler de la question multilingue et pour réfléchir aux étapes d’implémentation dans le core de WordPress, à défaut d’une solution complète, au moins quelques modifications qui pourraient aider les plugins existants à mieux faire leur travail.

Depuis, nous nous réunissons toutes les semaines sur Slack #core pour faire avancer trois propositions :

1. L’introduction d’un post format “langue” (mené par Simon Wheatley) ;
2. Une solution pour faciliter la traduction des chaines de caractères en dehors de celles contenus dans des gettext (c’est-à-dire des options dans la base de données, les métadonnées utilisateur et le contenu des widgets, mené par Andrea Sciamanna) ;
3. Une solution pour faciliter la traduction des noms déclarés des taxonomies, quelque chose que la plupart des plugins ne fait pas ou fait avec difficulté (mené by Marko Heijnen) ;

Si cette discussion vous intéresse, vous pouvez la suivre sur notre p2, ou bien lors des réunions sur Slack #core les lundis à 18h00 CEST.