Site multilingue WordPress : ce que j’ai appris en traduisant ce site

La question se pose dès le premier jour

Au Luxembourg, un site professionnel est rarement dans une seule langue. On croise partout du français, de l’allemand et de l’anglais, parfois du luxembourgeois. Avant même de choisir un thème, j’ai dû répondre à deux questions : quelle langue est la langue par défaut, et à quoi ressemblent les adresses des autres langues ?

Ces deux décisions sont pénibles à changer plus tard : redirections, référencement à refaire, et souvent une perte de positions le temps que les moteurs réindexent tout. Pour mon site, la réponse était simple. Je suis francophone, mon public principal lit le français, donc le français est à la racine du domaine. L’anglais vit sous /en/. Si j’ajoutais l’allemand un jour, il irait sous /de/ sans rien casser.

Sous-répertoire, sous-domaine ou domaine séparé

Trois structures d’adresses sont possibles. Le sous-répertoire, du type monsite.lu/en/, garde tout sur un seul domaine et une seule installation WordPress. C’est un peu une maison avec une aile par langue, une seule adresse postale, une seule porte d’entrée. C’est la structure la plus simple à gérer, et la réputation du domaine profite à toutes les langues. C’est celle que j’ai retenue.

Le sous-domaine, du type en.monsite.lu, sépare un peu plus les langues aux yeux des moteurs de recherche. Il demande un réglage chez le registrar et un certificat qui couvre les sous-domaines. Le domaine séparé, un .lu et un .fr par exemple, envoie le signal géographique le plus fort mais multiplie les coûts, les installations et le travail de référencement. Pour un site vitrine ou un portfolio, le sous-répertoire est presque toujours le bon choix.

Polylang, WPML ou TranslatePress

J’ai comparé les trois extensions les plus courantes avant de commencer. Elles ne fonctionnent pas de la même façon, et ce point compte plus que le prix.

Polylang crée une page ou un article distinct par langue, puis relie ces contenus entre eux. Chaque traduction est une vraie entrée dans WordPress, avec sa propre adresse, ses propres informations pour les moteurs et sa propre image mise en avant. La version gratuite couvre les pages, les articles, les catégories, les menus et les textes du thème. C’est sobre, sans surcouche, et je n’ai constaté aucun ralentissement du site.

WPML suit la même logique de contenus séparés, avec plus d’options : gestion de traducteurs, connexion à des services de traduction, prise en charge fine de WooCommerce. C’est une solution payante et plus lourde, adaptée aux sites d’entreprise ou aux boutiques qui ont besoin de ce niveau d’outillage. TranslatePress prend le problème autrement. On traduit directement depuis l’affichage du site, phrase par phrase, en voyant la page. C’est très accessible pour quelqu’un qui n’est pas à l’aise avec l’administration WordPress, mais on contrôle moins la structure de chaque traduction, et le référencement par langue est réservé à la version payante.

Pour un site que je gère seul, avec du contenu que je rédige moi-même dans les deux langues, Polylang gratuit suffisait. Je conseillerais WPML à une entreprise qui externalise ses traductions, et TranslatePress à un client qui veut tout faire depuis la page sans toucher au tableau de bord.

Ce que j’ai concrètement mis en place

Au départ, j’ai traduit douze pages et six articles. Pour chaque contenu français, Polylang crée un brouillon anglais que je remplis, puis les deux sont reliés comme traductions l’un de l’autre. J’ai défini la page d’accueil anglaise comme page d’accueil de cette langue, de sorte que /en/ affiche bien cette page et pas la liste des articles.

Les catégories aussi sont traduites : « Articles » devient « Insights », « Projets » devient « Projects ». Sans cela, un article anglais apparaît dans une catégorie au nom français. Côté navigation, j’ai créé deux menus, un par langue, chacun assigné à l’emplacement principal du thème pour sa langue. Le sélecteur de langue est un élément de menu fourni par Polylang. Les textes du thème qui ne passent par aucune page, comme le pied de page ou le libellé d’un bouton, se traduisent dans Polylang, écran Traductions.

Pour le contact, j’ai deux formulaires Contact Form 7, un par langue. Chaque formulaire a ses libellés, ses messages de validation et son accusé de réception rédigés dans la langue du visiteur. Les pages légales et la politique de cookies doivent exister dans chaque langue aussi, et j’ai failli les oublier.

Le bouton « EN » m’envoyait toujours sur l’accueil

Pendant un moment, cliquer sur « EN » depuis une page française renvoyait vers l’accueil anglais au lieu de la page équivalente. La cause était simple : les traductions n’étaient pas encore liées. Polylang ne devine pas qu’une page anglaise correspond à une page française, il faut le lui dire dans la boîte « Langues » de l’éditeur, en choisissant la traduction correspondante. Dès que le lien existe, le sélecteur envoie vers la bonne page.

Le second problème concernait le formulaire. Avant d’avoir un formulaire par langue, les messages d’erreur et de confirmation s’affichaient en anglais sur la version française. Un seul formulaire ne peut porter qu’une seule langue de messages. La solution a été de dupliquer le formulaire, de traduire ses textes et d’insérer le bon formulaire sur la bonne page.

Le référencement d’un site multilingue

Un site multilingue bien fait indique aux moteurs de recherche quelle version servir à quel visiteur. C’est le rôle d’une petite étiquette invisible ajoutée à chaque page (hreflang), que Polylang génère tout seul dès que les traductions sont reliées. Là encore, un contenu non lié n’a pas d’étiquette.

J’utilise Rank Math, et j’ai rédigé un titre et une description par langue, à la main. Le plan du site est également séparé par langue. Ces réglages rejoignent ma checklist SEO technique pour WordPress, que j’applique à chaque version comme s’il s’agissait d’un site à part entière. Ce qui doit être traduit va au-delà du texte visible. Avant de considérer une page comme traduite, je vérifie :

• l’adresse de la page, pour ne pas avoir un mot français dans une adresse anglaise ;
• le titre et la description destinés aux moteurs de recherche ;
• les textes alternatifs des images ;
• les e-mails automatiques, accusés de réception et notifications ;
• les catégories, étiquettes et éléments de menu.

Une page, une langue, et pas de traduction automatique sans relecture

Deux règles que je m’impose. La première : une page, une langue. Un bouton en anglais sur une page française, ou une notice de cookies restée en français sur la version anglaise, donne une impression de site inachevé.

La seconde : pas de traduction automatique publiée sans relecture sur un site professionnel. Les outils actuels sont utiles pour un premier jet, mais ils produisent des faux amis et parfois des contresens sur le vocabulaire métier. Sur un site qui sert à convaincre un client ou un recruteur, une phrase bancale coûte plus cher que le temps de relecture.

Traduire un site n’est pas seulement traduire des pages. C’est dupliquer toute une structure, menus, catégories, formulaires, e-mails, pages légales. La plupart des problèmes que j’ai rencontrés venaient d’un élément que j’avais oublié de dupliquer ou de relier, jamais de l’extension elle-même. Avec Polylang gratuit, une structure en sous-répertoires et une liste de vérification sérieuse, un site vitrine bilingue ou trilingue se fait sans budget supplémentaire. C’est ce que je propose aux entreprises luxembourgeoises qui hésitent encore à passer le cap.