Un site associatif que je maintiens publie l’essentiel de son contenu en français, avec une traduction anglaise progressive réalisée par une bénévole au fil de son temps disponible. Un visiteur anglophone tombait régulièrement sur une erreur 404 en cliquant sur un article partagé sur les réseaux sociaux, simplement parce que cet article particulier n’avait pas encore été traduit au moment de sa visite. Ce comportement, techniquement correct au sens strict, donnait une impression de site cassé plutôt que de contenu simplement pas encore disponible dans sa langue.
Cette situation est extrêmement fréquente sur les sites dont la traduction avance progressivement plutôt que d’être livrée intégralement d’un coup, et le choix du comportement de repli mérite une vraie décision de configuration plutôt que de laisser le réglage par défaut du plugin s’appliquer sans y avoir réfléchi.
Les trois comportements possibles
Face à une URL demandée dans une langue sans traduction disponible, trois approches existent. La première consiste à renvoyer une erreur 404 classique, ce qui est honnête mais frustrant pour le visiteur qui ne comprend pas toujours pourquoi le lien qu’il a suivi ne mène nulle part. La seconde consiste à afficher automatiquement le contenu de la langue par défaut à la place, ce qui garde le visiteur sur le site mais peut le surprendre s’il ne comprend pas cette langue de repli. La troisième, la plus transparente, affiche le contenu de la langue par défaut tout en signalant clairement au visiteur qu’il s’agit d’une traduction manquante, avec éventuellement un message dédié.
Configurer ce comportement avec Polylang
Polylang propose, dans Langues > Réglages, une option nommée « Contenu traduit manquant » avec un choix entre plusieurs comportements : afficher le contenu de la langue par défaut, masquer le contenu, ou afficher une page introuvable. La sélection s’applique globalement au site, mais peut être nuancée selon le type de contenu (articles, pages, contenus personnalisés) dans certaines configurations avancées de l’extension.
Pour ce site associatif, j’ai retenu l’option d’affichage du contenu par défaut, combinée à un message ajouté manuellement en haut du gabarit d’article, visible uniquement lorsque la langue affichée diffère de la langue demandée par le visiteur via son URL initiale.
Configurer ce comportement avec WPML
WPML propose un réglage équivalent dans WPML > Réglages, section « Ce qui doit se passer quand le contenu n’est pas encore traduit », avec des options similaires : afficher les traductions disponibles, cacher le contenu non traduit du site, ou afficher le contenu dans la langue par défaut avec un avertissement. WPML propose nativement l’affichage d’un message de type « Cette page n’est pas encore disponible dans votre langue » quand cette option est activée, ce qui évite d’avoir à coder ce message manuellement contrairement à l’approche nécessaire avec Polylang.
Construire soi-même le message de repli
Quand le plugin ne propose pas nativement ce message, un simple test conditionnel dans le gabarit suffit à l’ajouter, en comparant la langue actuellement affichée avec celle initialement demandée par l’URL, ou plus simplement en vérifiant si le contenu affiché correspond réellement à une traduction existante pour la langue courante du visiteur.
- Le message doit lui-même être traduit dans chaque langue du site, avec le module de traduction de chaînes du plugin.
- Un lien vers la liste des articles disponibles dans la langue du visiteur limite la frustration du repli.
- Le repli ne doit jamais être appliqué silencieusement sur des pages stratégiques comme la page de contact ou les conditions générales, qui méritent une traduction complète avant publication.
L’impact SEO de ce choix, traité ailleurs
Le choix du comportement de repli a des conséquences en matière de référencement, notamment sur le contenu dupliqué perçu par les moteurs de recherche quand une même page apparaît sous plusieurs URL de langue avec un contenu identique. Cette question mérite un traitement dédié et ne sera pas développée ici, cet article se concentrant uniquement sur la configuration du comportement côté visiteur.
Un repli de traduction silencieux, sans aucun signal visuel pour le visiteur, est à mes yeux la pire des trois options : le visiteur croit lire du contenu dans sa langue alors que ce n’est pas le cas, ce qui peut créer un malentendu bien plus gênant qu’une simple page manquante.
Notre verdict
Le comportement face à une traduction manquante ne devrait jamais rester sur son réglage par défaut sans réflexion préalable : selon le rythme de traduction du site et le profil des visiteurs, une erreur 404 franche, un repli silencieux ou un repli signalé conviennent à des contextes différents. Pour la plupart des sites en traduction progressive, un repli clairement signalé au visiteur reste le compromis le plus respectueux, à condition de traduire ce message d’avertissement lui-même dans toutes les langues du site.
