Site multilingue

Introduction

Dès la conception d’un site web, il est indispensable de se poser la question si celui-ci va être multilingue ou si, au contraire, son contenu sera publié uniquement dans une seule langue. Quoiqu’il en soit, la langue principale de l’internet est l’anglais. En tant que concepteur de site web, on vous le rappellera souvent, de commencer par créer le site en anglais. Chez les développeurs, c’est encore plus la norme. Tout le code est écrit en anglais, surtout les commentaires, encore plus si celui-ci doit être publié. Écrire dans une autre langue n’a de sens que si le site reste dans une communauté restreinte à une région linguistique. Même les sites des offices du tourisme, ou des restaurants, sont souvent écrit en anglais, puis traduit.

Multisite ou monosite

Un multisite est un type d’installation WordPress qui permet de piloter plusieurs sites depuis une seule console d’administration. Ceci permet de modifier les paramètres de WordPress sur tous les sites en même temps et de garder une certaine cohérence. Par exemple, on peut créer plusieurs site, dont le propriétaire n’est pas forcément l’administrateur, comme une société dont chaque département est indépendant. L’administrateur s’occupe des mises à jour de WordPress, et de l’installation des plugins, ce qui permet de garder une certaine cohérence de l’ensemble. Un autre avantage du multisite est forcément son hébergement. Il n’existe qu’un seul domaine principale, et autant de sous-domaines qu’il y a de sites hébergés sur le domaine.

Exemple de mutisites

Les sous-domaines peuvent être utilisés pour la création d’un site multilingue, par exemple :

• https://fr.fuyens.ch pour le français.
• https://en.fuyens.ch pour l’anglais.

Ils seraient tous deux des sous-domaines de fuyens.ch, avec son installation de WordPress indépendante.

Exemple de monosite

Le monosite, pour citer un contre-exemple, ne va héberger qu’une seule installation de WordPress, mais partager plusieurs sous-dossiers. Pour reprendre l’exemple ci-dessus, un monosite multilingue aurait comme nom de domaine :

• https://fuyens.ch/fr pour la version français.
• https://fuyens.ch/en pour la version anglaise.

Toute la différence est là. Et encore, il n’est pas indispensable de préciser le dossier pour la langue principale.

Pour la clarté et la hiérarchie des différentes pages, il est recommandé d’afficher le dossier de la langue dans l’URL d’une page de type monosite.

Alors, multisite ou monosite ? Un avis personnel serait de créer un monosite, sauf dans les cas où il y a beaucoup de langues à gérer (3 et plus) et que ces sites sont gérés par différentes personnes ou départements.

Fuyens.ch est un monosite.

Les différents plugins

La question que tous les concepteurs se posent est bien entendu le choix du plugin, car, en effet, il faut bel et bien installer un plugin pour traduire un site. A moins de choisir l’option de créer un multisite que chaque responsable va traduire manuellement, il est quasi indispensable de passer par cette option.

Les différents plugins du marché offrent tous, approximativement, les mêmes possibilités. Dès le moment où l’on désire rendre l’interface de navigation claire et intuitive, il en ressort que le plugin ne sera pas gratuit. Tous les plugins offrent une version gratuite, mais celle-ci reste limitée. Avec Elementor, le plugin de traduction rentre dans la catégorie des versions pro à acheter. Il faut y penser dès le moment où l’on désire créer un site multilingue.

Pour réaliser ce site, 4 plugins ont été testés. En voici un aperçu avec leurs avantages et inconvénients. Ceci est bien entendu un avis personnel.

	Avantages	Désavantages
WeGlot Pro	Compatible ACF et types personnalisés Traduction automatique Compatible multisite	$99 / an Limité à 10000 mots Limité à une langue supplémentaire pour ce plan tarifaire Pas d’import / export dans ce plan tarifaire
Polylang Pro	Compatible ACF et type personnalisés Traduction des slugs et URL Offre une librairie de fonctions PHP Un seul plugin, deux avec Elementor Pas d’extension dans la base de données Export des traductions du thème	$99 / an Chaque publication ou modèle est doublé dans la deuxième langue N’utilise pas de console indépendante pour la traduction Les pages d’options ACF ne sont pas supportés Utilise un plugin tiers pour les modèles Elementor
WPML Pro	$29 / an pour la version de base $79 / an pour la version totale Compatible type personnalisés Compatible ACF seulement dans la version $79 Traduction des slugs et URL Utilise une console de traduction intuitive Une seule publication pour toutes les langues	Beaucoup de plugins à l’installation Import et Export des publications à l’aide d’un plugin tiers Extension de la base de données Pas d’export des traductions du thème sans plugin supplémentaire
TranslatePress Pro	$79 / an Compatible ACF et type personnalisés Utilise une console de traduction intuitive Traduction des slugs et URL Export des traductions du thème Une seule publication pour toutes les langues	Extension de la base de données La traduction se trouve dans la base de données Pas d’export possible des publications Traduction automatique seulement disponible dans le plan $139 / an

Analyse et choix du plugin

Au moment de la décision d’utiliser un produit, plutôt qu’un autre, l’analyse réalisée dans ce sens a tenu compte de (du) :

• Prix
• La complexité de l’installation
• La complexité d’utilisation
• La traduction du thème et pas seulement des publications
• La compatibilité avec Elementor, ACF et des types personnalisés

Prix

Concernant le prix, deux versions pro ont été testés (Polylang et WPML). La version à $29 est à exclure très rapidement, car trop limitée. WeGlot Pro est le premier produit de la liste abandonné pour des raisons évidentes de prix. Il est surtout limité à 10000 mots, ce qui est une vraie barrière psychologique.

Complexité d’installation

Pour la complexité de l’installation, WPML ne marque pas beaucoup de points. Il installe pas moins de 5 plugins pour offrir les services de bases. Polylang n’utilise qu’un seul plugin, mais n’est pas compatible avec les modèles Elementor dans sa version de base. TranslatePress n’installe qu’un seul plugin. Sur ce point, TranslatePress est vraiment le meilleur produit.

Complexité d’utilisation

Pour l’utilisation, WPML et TranslatePress utilisent tous deux une console très intuitive qui permet de traduire une publication directement depuis la console WordPress. Polylang, au contraire, demande de créer une copie de la publication dans la langue étrangère, ce qui n’est pas forcément un inconvénient, mais plutôt un gage de vouloir séparer les différents objets dans les différentes langues, pour plus de clarté. WPML et TranslatePress modifie la base de données pour aller y inscrire le texte des traductions, ce que ne fait pas Polylang, qui utilise l’architecture de base pour enregistrer les publications dans les différentes langues. Sur ce point, Polylang marque un point.

Traduction du thème

La traduction du thème, à savoir, tout le texte qui constitue le site est normalement écrit dans un fichier de traduction externes aux publications. Il se doit également d’être exportable. La norme utilise des fichiers avec une extension “.po” ou “.pot”. TranslatePress utilise des fonctions de traductions du thème, mais sans possibilités d’exporter le fichier. WPML permet de traduire le thème, mais n’est pas compatible avec cette norme, ou en tout cas, pas dans la version native. Polylang offre les fonctions standard de traductions et l’a intégré dans son plugin sous forme de console où est répertorié tout le texte du thème. De plus, le texte est compatible avec la norme “.po” et est exportable. Ce point étant relativement important, Polylang reste le meilleur produit pour cette tâche.

Compatibilité avec Elementor, ACF et type personnalisés

Polylang n’est pas compatible nativement avec Elementor. Il demande un plugin tiers “Polylang connect for Elementor”.

Les trois produits restants de la sélection sont tous compatible avec Elementor. WPML et TranslatePress, qui traduisent le texte de n’importe quel contenu, permettent également la traduction des modèles Elementor. Sur ce point, on voit clairement que Polylang n’a pas été développé pour Elementor, ce qui le rend inutilisable. Son choix a été écarté dans un premier temps, avant de découvrir un plugin externe qui se nomme “Polylang connect for Elementor”, créé par David Decker. Ce plugin, permet de connecter Polylang à Elementor et de traduire les modèles. Sans ce plugin, Polylang devient tout simplement inutilisable avec Elementor. En ce qui concerne ACF et les types personnalisés, les trois produits les intègrent très bien.

Choix final

Pour la réalisation de ce site, le choix s’est porté sur Polylang. Une fois l’incompatibilité avec Elementor levée, il possède un énorme atout par rapport aux autres plugins, sa bibliothèque de fonctions “pll”.

Il est bien difficile de sélectionner en fin de compte, le meilleur produit de traduction. Tous ont quelques points forts. Polylang n’est pas le plugin le meilleur marché, mais celui dont l’installation est la plus simple, à savoir deux plugins pour l’utilisation avec Elementor. TranslatePress fait mieux (un seul plugin), mais modifie la structure de la base de données, ce qui n’est pas un bon gage de fiabilité et de stabilité, quand on sait que WordPress mets à jour son produit très régulièrement. La possibilité de traduire le thème ET de pouvoir en exporter le contenu est vraiment un atout en faveur de Polylang. Imaginez juste un instant que vous désirez traduire le site dans une langue étrangère. Vous mandatez une personne externe pour exécuter ce travail. Vous exportez le thème sous forme de fichier “.po” et le traducteur vous rends une copie que vous pouvez importer. Idem avec les publications. Vous pourrez exporter celle-ci sous forme de fichier “XML”, les traduire, puis les importer en retour. De plus, en tant que développeur, Polylang offre une vraie bibliothèque de fonctions. Celle-ci permet de traduire, par exemple, le contenu hors thème, comme les messages électroniques envoyés aux visiteurs. Cette publication reviendra plus à fond sur ces fonctions appelés “pll”.

Les réglages de Polylang

Une fois l’analyse du plugin réalisée et celui-ci installé, il reste à parcourir ses différents paramètres de réglages.

Modifications des URL

Ci-dessous, les recommandations et options retenues sur fuyens.ch.

• La langue est déterminée par le nom du répertoire dans les permaliens.
• Décochez l’option “Cacher l’information de langue dans l’URL de la langue par défaut”.
• Supprimer “/language/” dans les permaliens.
• Décochez “L’URL de la page d’accueil contient le code de la langue au lieu du nom ou de l’ID de la page”.

Dans une installation de type monosite, il est recommandé d’utiliser des noms de dossiers différents pour chaque langue.

Dans le même ordre d’idées, il est préférable d’afficher le dossier de la langue, même pour celle par défaut. Le dossier “language” n’a aucune utillité ici. De plus, il s’écrit “langage” en français.

Enfin, pour plus de clarté, afficher le nom de la page d’accueil n’est pas un luxe.

Détecter la langue du navigateur

Même si cette fonctionnalité ne fonctionne pas avec tous les navigateurs, celle-ci est activée par défaut.

Médias

Polylang ne permet pas de lier deux images différentes sur une publication écrite dans deux langues. Ce serait bien pratique.

• La recommandation va pour “Dupliquer automatiquement les médias dans toutes langues lorsqu’un nouveau fichier est téléversé”.

Même si l’on utilise pas la traduction des légendes et autres noms d’images, celles-ci sera disponible dans les deux langues. Décocher cette option ne permet pas, par exemple, de lier une pièce jointe sur une publication écrite dans les deux langues.

Types de publication personnalisés et taxonomies

Ici, il faut tout simplement tout cocher. Polylang prend en compte les champs ACF et les types personnalisés grâce à cette fonctionnalité.

Synchronisation

Ici aussi, il faut tout cocher. Polylang va ainsi synchroniser tous les champs d’une publication écrite dans une langue. Et si le site utilise des champs personnalisés, il est possible de les ignorer dans les réglages d’ACF pour chaque champ.

Partage et traduction des slugs

Ces deux options sont activées par défaut dans la version pro. Elles servent à pouvoir utiliser les mêmes slugs dans le nom d’une page tout en modifiant sa description. Par exemple, le slug de la page d’accueil sera “home”, mais son vrai nom en français sera “page d’accueil” et en anglais “home page”.

Création d’une langue

Sous l’onglet langue, on peut ajouter une ou plusieurs langues et sélectionner la langue par défaut. Il existe trois réglages différents pour la langue sous WordPress.

• La langue principale du site (Réglages – Général). Ce réglage permet de modifier les réglages principaux en fonction du pays.
• La langue principale de l’utilisateur (Utilisateurs). Ce réglage permet de choisir la langue d’affichage de la console d’administration de WordPress pour un utilisateur. Ce qui permet de dire qu’il est tout à fait possible de créer de multiples utilisateurs, chacun affichant la console WordPress dans sa propre langue.
• La langue d’affichage du thème. (Langues – Langues). Ce réglage Polylang permet de choisir la langue d’affichage par défaut des publications et autres messages. A première vue, il devrait toujours être “anglais“, mais il va aussi afficher en anglais tous les plugins qui offrent une traduction, comme Elementor.

Création d’une publication

Une fois la publication écrite, il est temps de la traduire. Polylang n’offre pas de console de traduction comme WPML ou TranslatePress, qui permet de traduire la publication directement. Polylang créé une copie de la publication dans l’autre langue. Ceci peut paraître, au premier abord, un peu archaïque et complexe, mais ceci à le mérite de présenter une structure des plus claire. Chaque page, publication, modèle aura droit à son double. De plus, comme mentionné plus haut, il est possible d’exporter une publication sous forme de fichier “XML”. Ce qui rends possible la traduction par une tierce personne, sans lui donner accès à la console d’administration WordPress.

Un petit drapeau va afficher que la publication est traduite, ce qui à le mérite d’être clair. Polylang va créer une copie de la publication et lui attribuer une autre langue. A partir de cette nouvelle publication, il ne reste plus qu’à traduire paragraphe par paragraphe, le contenu dans l’autre langue. Il est possible d’utiliser des traducteurs automatiques ou semi-manuel, comme le fameux “DeepL”.

Synchronisation avec ACF

Polylang va traduire et synchroniser automatiquement tous les champs ACF, ce qui n’est pas forcément une bonne idée. Un champ texte écrit en anglais ne sera pas le même en français et vice-versa. Heureusement, il existe un moyen d’ignorer ces champs lors de la synchronisation. Pour ceci, il faut ouvrir le champ ACF et sélectionnez “Ignorer” dans les options.

Le sélecteur des langues

Polylang affiche par défaut un drapeau pour sélectionner un contenu dans une langue. Ce petit drapeau est disponible sous l’onglet “Apparence – Menus”. Polylang n’utilise pas d’autres moyen pour afficher son sélecteur de langue. C’est ultra simple et très intuitif.

Ci-dessous, les réglages, comme ils sont paramétrés sur Fuyens.ch.

Le paramètre qui masque les langues sans traduction va permettre de supprimer le drapeau si la publication n’a pas été traduite.

Il est possible de modifier l’aspect de l’icône du drapeau avec du CSS. L’objet porte le nom de “li.lang-item”. Ce n’est rien d’autre qu’une balise de liste à puce (li) et de la balise “img” ou “a” pour modifier respectivement le drapeau ou le texte qui l’accompagne.

/* Polylang country flag */
li.lang-item {
  display: flex!important;
  align-items: center!important;
}

li.lang-item a {
  justify-content: left!important;
}

li.lang-item img {
  width: 20px!important;
  height: 16px!important;
}

La traduction des URL

Pour pousser le chic jusque dans les moindres recoins, il est possible de traduire les URL en fonction de la langue affichée.

Par exemple, traduire l’URL

• https://www.fuyens.ch/fr/informatique/impression-dun-pdf/

par

• https://www.fuyens.ch/en/it/printing-a-pdf/

Le dossier de la langue va être traduit automatiquement. Inutile de traduire “fr” par “en”.

Il en va de même pour le nom de la publication. Celui-ci étant différent pour chaque publication.

Il reste à traduire le mot “informatique” par “it” et pour réaliser ceci, on va utiliser les fonctions “pll” fourni par Polylang. Dans cet exemple le filtre “pll_the_language_link” permet de modifier le lien de traduction publié par le changement de langue. Associé à la fonction “pll_translate_string”, qui permet de traduire un mot ou une expression dans une autre langue et la fonction PHP “str_replace”, qui permet, quant à elle, de remplacer un mot ou une expression par un(e) autre, il est possible de traduire les URL.

Voici le code :

// On language switch, translate the URL
function pll_translate_url($url, $slug) {

  if (function_exists('pll_translate_string')) {
    
    // Translate Search Slugs
    $url = str_replace(array('informatique','it'), pll_translate_string('it', $slug), $url);
  }
  return $url;
}
add_filter('pll_the_language_link', 'pll_translate_url',10,2);

Les possibilités sont infinies. La documentation se trouve en ligne.

• Pour retrouver les références vers les fonctions, allez jeter un coup d’oeil sur :

“https://polylang.wordpress.com/documentation/documentation-for-developers/functions-reference/”.

• Pour retrouver les références vers les filtres, rendez-vous sur :

“https://polylang.wordpress.com/documentation/documentation-for-developers/filter-reference/”.

Le mot de la fin

Choisir un plugin de traduction est un choix difficile. Il faut peser le pour et le contre de chacun. Pour ce site, les arguments en faveur de Polylang ont été en grande partie la librairie “pll”, mais également la possibilité de créer des requêtes SQL sur la base de données qui sont largement utilisées dans le moteur de recherche. Polylang n’étend pas la base de données avec de nouvelles tables. Il ne va pas non plus écrire les chaînes de traductions dans la base de données, mais utilise les fichiers standard “.po”, qui permettent en tout temps de les extraire, de les modifier avec un éditeur comme “PoEdit”, et de les réimporter dans un autre site web.

Il est également possible, grâce aux fonctions “pll” de traduire des messages électroniques envoyés aux visiteurs du site. Ceci fait l’objet de la prochaine publication “Messages multilingues avec Polylang”.