Par son statut d’extension historique de gestion multilingue sur WordPress, WPML est toujours le leader sur son marché. À nos yeux, WPML est pourtant une impasse technologique. Dans cet article, nous revenons sur les raisons pour lesquelles nous conseillons de remplacer ce plugin par Polylang, et nous proposons quelques conseils pour migrer votre site de WPML vers Polylang.
Pour commencer, il faut bien avouer que WPML est l’extension de gestion multilingue historique de l’écosystème WordPress… et c’est en fait tout le problème 😅
Pourquoi WPML est technologiquement obsolète
Il va falloir nécessairement rentrer un peu dans la technique (et dans l’histoire du CMS WordPress), mais je vais essayer de vulgariser le problème un maximum 🙂 Pour faire simple, WordPress dispose nativement de tout ce qu’il faut pour la gestion du multilingue : ce sont les taxonomies personnalisées.
En effet, si l’on veut construire une architecture WordPress avec un ensemble de publications (articles, pages et tout autre type de publication) pouvant être disponibles dans une ou plusieurs langues, le fonctionnement le plus simple et le plus efficace est de ranger chaque version traduite dans une taxonomie personnalisée « Langue » contenant chacune des langues utilisées sur le site. La version traduite d’un article ou d’une page est donc différenciée par la valeur de la taxonomie langue associée.
Cela permet de profiter de la gestion native des taxonomies de WordPress qui correspond parfaitement aux besoins d’un site multilingue : réécriture d’URL disponible nativement, interface de gestion des langues et de leurs paramètres, intégration parfaite dans le système de requête natif de WordPress (WP_Query).
Il est difficile de dater cela avec exactitude car ce fut un travail en itération, mais on peut dire que le support complet des taxonomies personnalisées a été progressivement introduit dans WordPress entre les versions 2.8 et 3.0, soit entre 2009 et 2010. Or, WPML a été créé en 2007. Et c’est là que le bât blesse.
À l’époque, sans système de taxonomies personnalisées, il n’y avait pas beaucoup de possibilités pour obtenir une gestion multilingue. WPML a donc tablé sur l’ajout de ses propres tables au sein de la base de données de WP. Presque quinze ans plus tard, ce système montre chaque jour ses faiblesses. WPML est devenu une impasse technologique.
Chaque appel à la base de données se fait donc sur des tables ajoutées par l’extension. Cela représente un grand volume de requêtes spécifiques qui sont faites, et cela se voit pour le visiteur en front, mais aussi – et surtout – sur la baisse de performances pour l’administration de votre site WordPress. Malheureusement pour WPML, il parait peu vraisemblable qu’ils soient à même de revenir en arrière et qu’ils se mettent à proposer une implémentation plus naturelle et proche de l’architecture native de WordPress.
WPML, une extension encore populaire malgré la croissance de Polylang
Pour une extension, presque quinze ans d’existence, ce n’est pas rien. les années 2010 ont vu la montée en puissance des thèmes premiums (et notamment ceux disponibles sur Envato/Theme Forrest🌲). Proposés pour quelques dizaines d’euros, ces thèmes premiums se targuent d’embarquer un maximum de fonctionnalités pour garantir à leurs auteurs un volume de vente minimal. Ils se devaient donc de proposer une solution de gestion multilingue. Au départ, il n’y avait pas énormément de possibilités et WPML en tant que solution historique avait tout pour plaire.
Les thèmes premiums ont donc beaucoup joué dans la montée en puissance de WPML en intégrant quasi-systématiquement une compatibilité native avec cette extension.
Polylang, la solution de gestion multilingue la plus fiable pour votre site WordPress
Dès sa conception, Polylang est parti sur l’utilisation de taxonomies personnalisées pour la gestion des langues. L’intégration de Polylang dans WordPress est donc complètement naturelle. Pas de table inutile dans la base de données, peu d’interface spécifique dans votre administration, aucune pièce rapportée qui entre en contradiction avec le design system de l’administration de WP. Comme on dit dans l’IT, il s’agit d’une intégration « seamless » : intégration parfaite, on ne voit pas les coutures.
Voici par exemple l’écran de gestion des langues. Il s’agit tout simplement de l’écran natif de gestion des catégories, amélioré via l’utilisation de champs personnalisés permettant d’y ajouter les éléments dont Polylang a besoin pour décrire les spécificités de chaque langue utilisée sur votre site. Mais au final, cela reste un écran de gestion de taxonomie.
Cela est dû au travail réalisé par l’équipe de développement de Polylang qui a toujours souhaité coller au plus près de ce que propose le CMS WordPress. Le fondateur de l’extension Frédéric Demarle a d’ailleurs expliqué ses parti pris lors d’un épisode de notre podcast WOA dédié à la gestion multilingue dans WordPress.
D’ailleurs, Polylang contribue activement au développement du cœur du CMS. Les développeurs de cette extension ont contribué à quasiment toutes les versions de WordPress depuis la version 3.5 sortie en 2012. Cette activité dans le développement du CMS est un vrai gage de sécurité pour les sites utilisant cette extension, car cela apporte l’assurance que Polylang sera toujours compatible avec les versions futures de WP. De son côté, WPML se comporte davantage en suiveur, en s’adaptant – généralement avec bien des difficultés – aux changements après coup.
La migration d’un site de WPML vers Polylang
Déjà, est-il possible de migrer un site WordPress de WPML vers Polylang ?
La plupart du temps, oui ! Il existe une extension pour effectuer la migration des contenus de WPML vers Polylang. Ce plugin permet de migrer l’ensemble des contenus stockés en base de données. Cette extension importe les langues et les options configurées dans WPML, tous les contenus du site ainsi que leurs traductions (incluant les types de publications personnalisés et les taxonomies personnalisées). Elle importe aussi les menus de navigation multilingue ainsi que les chaines traduites.
Grâce à cette extension, la migration de la base de données de votre site est la partie facile de la migration. En revanche, elle n’assure que la migration des données de votre site. Elle ne peut pas gérer la compatibilité de votre thème avec Polylang (si cela est nécessaire).Puis-je rendre mon thème WordPress compatible avec Polylang ?
Pour passer votre site de WPML a Polylang, il sera peut-être nécessaire d’effectuer des modifications au niveau de votre thème.
Si votre thème provient du répertoire officiel des thèmes sur WordPress.org, pas de souci, il sera forcément compatible.
En revanche, si votre thème provient d’un répertoire de thèmes payants et qu’il a été fait pour fonctionner avec WPML, cela risque de poser problème. Dans ce cas, vous pouvez demander au support technique du thème si celui-ci est aussi compatible avec Polylang.
Enfin, si votre thème a été réalisé sur mesure, il va falloir effectuer des travaux de migration manuellement.Comment effectuer la migration technique d’un thème de WPML vers Polylang ?
Si nécessaire, il faudra remplacer toutes les conditions PHP gérant l’affichage de chaînes traduisibles pour les rendre compatibles avec les fonctions de traduction proposées par Polylang. Cela impacte surtout les thèmes sur-mesure qui déclarent parfois des conditions « en dur » pour gérer l’affichage de contenus différents en fonction de la langue.
De la même façon, les bouts de codes appelant directement des fonctions WPML devront être migrés pour être fonctionnels sur Polylang. Cela concerne par exemple la gestion des menus qui peuvent être appelés via des fonctions propres à WPML.
Dans tous les cas, le passage de WPML n’est pas très complexe, il faut « simplement » savoir quoi chercher. Les fonctions WPML sont généralement reconnaissables par leur préfixe : ICL_ ou wpml_. Le plus simple est de scanner l’ensemble des fichiers de votre thème pour y rechercher les fonctions WPML et les remplacer par leur équivalent Polylang.
Les alternatives à WPML et Polylang
Weglot pour l’automatisation des traductions
Weglot est une extension premium disponible pour assurer la traduction de votre site. Ce n’est pas exactement le même besoin, puisque Weglot vous fournit les traductions de vos contenus en plus d’assurer la gestion multilingue de votre site. Cette extension fonctionne très bien, et sera recommandée si votre besoin est de pouvoir disposer d’une traduction automatisée (ou semi-automatisée) de vos contenus.
Est-ce que WordPress prendra un jour nativement en charge la gestion multilingue ?
Oui 😃 La gestion multilingue en natif est effectivement un projet à long terme de WordPress.
Ce projet est d’ailleurs rattaché au projet Gutenberg. Pour l’instant les développements n’ont pas encore commencé, c’est un projet qui ne démarrera pas avant 2022 ou 2023, mais c’est effectivement important de l’avoir en tête.
Est-ce que cela signera l’arrêt de mort des extensions de gestion multilingue comme Polylang ?
Non, je ne pense pas.
Comme les sitemaps.xml natifs n’ont pas rendu les extensions de sitemap inutiles. Comme le lazyload des images en natif n’a pas rendu les extensions de gestion du lazyload inutiles. Les extensions répondent à des besoins avancés, alors que WordPress répond aux besoins les plus communs 😃
Au contraire, connaissant l’implication de Polylang dans le projet open-source WordPress, je suis sûr et certain que Polylang saura transformer cette « menace » en opportunité, en proposant des fonctionnalités qui vont étendre la gestion multilingue que proposera Gutenberg 😎
Bonjour Jean-Baptiste, j’utilise depuis plusieurs années WPML, et j’ai bien vu en faisant ma veille que Polylang commençait à prendre de la place. En revanche, les articles que j’ai lus par la suite ne m’ont guère convaincu de migrer car ils reposaient essentiellement sur le confort d’utilisation du rédacteur. Pour le coup, je me sens un peu plus près à migrer après la lecture du tien, je pense que l’argument technique a fait mouche. Merci pour avoir attaqué sous cet angle.
Dommage qu’il n’y ai pas un comparatif de performances des deux solutions dans cet article. Beaucoup d’extensions utilisent leurs propres tables, dont WooCommerce, qui va sortir les produits et les commandes de la table wp_posts, pour des questions de performances. Je veux bien penser que Polylang soit plus rapide que WPML, mais avec un test de performances pour avoir une idée de cet écart.
Quant à la notion « d’impasse technologique », dans mon esprit cela signifie que WPML ne pourra plus fonctionner correctement dans les années à venir, je n’en comprends pas la raison.
A noter, il y a un conflit avec Polylang et Yoast qui n’est toujours pas réglé depuis très longtemps.
@J-Michel merci pour votre commentaire mais non, il n’y a aucun conflit entre Yoast et Polylang, les deux fonctionnent parfaitement ensemble.
Nous connaissons bien les gens qui sont travaillent dans les deux entreprises qui éditent ces deux extensions et je peux vous assurer que s’il y avait un conflit, d’autant plus depuis longtemps, cela serait un problème majeur 🙂