Chez Imagile, nous utilisons le plugin WPML ainsi que ses extensions (entre 3 et 5 selon les besoins) depuis plusieurs années pour configurer le contenu multilingue d’un site internet sur WordPress. Nous connaissons donc les contraintes de cet outil et c’est pourquoi, nous avons décidé de le challenger avec un de ses concurrents principaux : Polylang.
WPML s’imposait comme un des leaders de solution multilingue sur WordPress. Il correspondait aux besoins attendus et c’est donc naturellement que nous nous sommes dirigés vers cette solution.
Les éléments qui ont fait la différence et qui ont orienté notre choix sont les suivants :
- Pouvoir personnaliser le sélecteur de langue
- Permettre à un administrateur de traduire ses contenus en autonomie
- Gérer les URLs par langue, y compris dans la langue principale
- Prendre en compte tous les types de contenus, taxonomies, menus, médias même ceux développés sur mesure
- Avoir une grande compatibilité avec les modules tiers et personnalisés
- Dupliquer les contenus dans une langue avec tous les contenus + champs personnalisés dans la langue choisie
- Externaliser la gestion des traductions dans des logiciels spécifiques avec des imports/exports de fichiers de chaînes de traductions
WPML ne pose aucun souci du côté de nos plugins et thème sur mesure. Cela dit, nous avons détecté les contraintes suivantes :
- Interface de configuration extrêmement complexe
- Performances réduites dans l’interface d’administration
- Difficulté de mise à jour
C’est pourquoi nous avons décidé de trouver une alternative à WPML. Lors de nos recherches, celui qui sort du lot est Polylang car il respecte l’ensemble des besoins que couvre WPML et est, sur papier, plus simple d’utilisation et a une façon de fonctionner permettant de ne pas trop alourdir les performances du site. Nous avons donc décidé de le tester !
Le petit plus non négligeable : l’éditeur du plugin Polylang propose un module permettant de migrer ses contenus de WPML à Polylang.
Pour nous mettre en situation, nous avons réalisé trois cas d’utilisation : une installation sur un WordPress from scratch, une migration depuis un WordPress déjà traduit en plusieurs langues avec WPML et une mise en place sur un WooCommerce ayant besoin de passer en multilingue.
L’installation de Polylang sur une installation de base de WordPress se passe sans accros. Sa configuration est rapide à mettre en place comparé à WPML.
Nous ne constatons pas de manquement significatif par rapport aux différents éléments attendus d’un plugin de gestion de langues. Une limite constatée dans ce cas d’utilisation est que dès lors que l’on veut installer un module tiers, la liste des chaînes de traductions proposées ne couvre pas l’ensemble des textes affichés par le module. Dans ce genre de situation, ce manque de compatibilité de Polylang oblige un développeur à venir rendre traduisible l’ensemble des chaînes du module pour Polylang spécifiquement.
Le module de migration a bien repris l’ensemble des contenus. Cela dit, en regardant plus en détails, on constate le même manque de compatibilité que l’étude de cas n° 1 sur les chaînes de traductions disponibles qui sont moindres que ce que propose WPML.
De plus, suite à la migration, certaines listes de contenus (personnalisés ou natifs) ne disposent pas d’indicateur de langue traduite à faire, ce qui est déstabilisant. Ces problèmes d’affichage n’ont pas été constatés sur l’étude de cas n°1 lors d’une mise en place dès le départ.
Au premier abord, tout se passe bien : Les pages nécessaires à WooCommerce (Panier, mon compte…) ont été créées automatiquement dans la langue souhaitée et les contenus, taxonomies, médias peuvent être traduits.
En allant plus loin, nous retrouvons les mêmes travers que le cas n°1 et avons constaté que l’adaptabilité des modules tiers ou personnalisés pour Polylang n’est pas à la hauteur de l’attendu. De plus, autre manquement non négligeable pour un site e-commerce : les attributs des produits ne sont pas traduisibles. Dernier point qui concerne la duplication de produit : aucune catégorie et taxonomie custom n’ont été reprises automatiquement ce qui est déstabilisant pour le traducteur qui est obligé de tout reprendre champ par champ.
Bilan mitigé. D’une façon générale, Polylang coche les mêmes cases que WPML par rapport au besoin attendu et se différencie surtout sur sa simplicité d’utilisation. Cela impacte de facto la finesse de ce que l’on peut traduire ou non sur un site. Polylang a donc plus de “parti pris” sur une configuration ou une façon de fonctionner avec plusieurs langues comparé à WPML.
Côté performances, là où ou le fonctionnement de WPML vient rajouter des requêtes sur des tables spécifiques et donc allonger les temps de chargements, Polylang propose une implémentation plus proche de l’architecture de WP (utilisation du système de taxonomies pour localiser les contenus) et est donc plus “naturelle” et performante. Lors de nos tests, la différence sur la performance a bien été ressentie sur l’interface d’administration. Par contre sur la partie visible par les internautes, nous n’avons pas constaté de changement notable, les temps de chargement des pages sont quasiment équivalents entre WPML et Polylang.
Pour la migration d’un site existant en WPML, les quelques écueils évoqués dans l’étude de cas n°2 nous orientent plus à utiliser Polylang dès le début et donc dès la mise en place de la seconde langue. Concernant WooCommerce, les manquements évoqués dans l’étude de cas n°3 montrent que ce qu’offre Polylang n’est pas assez abouti par rapport à WPML. Nous ne préconisons donc pas d’utiliser Polylang sur un WooCommerce.
Au global, Polylang peut valoir le coup dès l’installation d’un WordPress “peu complexe” (sans trop de modules tiers ou personnalisés) et qui n’a pas vocation à devenir un e-commerce. Cela restreint donc l’éventail de possibilités et oriente naturellement notre choix à rester sur WPML au vu de la modularité qu’il offre pour tout WordPress ou WooCommerce multilingue au sein d’Imagile.