Un client repérait, mois après mois, qu’un encart « Nos horaires » dans la colonne latérale de son site continuait d’afficher « Monday to Friday, 9am to 6pm » sur la version française du site, alors que tout le reste de la page s’affichait correctement en français. Ce détail avait échappé à trois relectures successives, simplement parce que personne ne pensait à vérifier la sidebar en changeant de langue.
Ce type d’oubli est très fréquent parce que les widgets de la colonne latérale vivent en dehors du flux éditorial habituel. Un article traduit passe par le tableau de bord de traduction du plugin multilingue et apparaît dans les rapports de statut. Un widget texte, lui, est configuré une fois dans Apparence > Widgets et reste ensuite invisible pour quiconque ne va pas explicitement vérifier cet écran.
Pourquoi les widgets échappent au circuit de traduction standard
Les widgets classiques ne sont pas des articles ni des pages : ce sont des instances d’options stockées dans la table wp_options, sous la clé correspondant au type de widget (par exemple widget_text pour les widgets texte). WordPress ne les traite pas comme du contenu traduisible par défaut, et un plugin multilingue doit donc proposer un mécanisme dédié, différent de celui utilisé pour les articles et les pages.
Polylang gère ce cas par un principe simple : chaque zone de widgets (sidebar, pied de page) est dupliquée par langue dans l’écran Apparence > Widgets, à condition d’avoir coché l’option correspondante dans les réglages de Polylang, section « URL des langues » puis onglet des zones de widgets. Une fois cette option activée, l’écran affiche une zone par langue, par exemple « Barre latérale (fr) » et « Barre latérale (en) », chacune configurable indépendamment.
La méthode WPML pour les widgets
WPML procède différemment : il ajoute un bouton de traduction directement sur chaque widget dans l’écran de personnalisation du thème (le Customizer), qui ouvre une fenêtre de traduction similaire à celle utilisée pour le contenu des articles. Cette approche garde une seule zone de widgets déclarée dans le thème, mais duplique en interne le contenu affiché selon la langue courante du visiteur.
Vérifier la configuration avant la mise en production
Sur un nouveau projet, je teste systématiquement chaque zone de widgets dans chaque langue publiée avant la recette finale. La méthode la plus fiable reste visuelle : ouvrir chaque page type (accueil, article, page de contact) dans chaque langue, et confirmer que rien de la colonne latérale ne reste dans la langue par défaut.
- Les widgets de type « Articles récents » posent un cas particulier : ils doivent aussi être filtrés par langue, sans quoi ils affichent des titres d’articles dans toutes les langues confondues.
- Les widgets tiers ajoutés par des extensions (newsletter, réseaux sociaux) ne sont pas toujours compatibles avec la traduction par zone : vérifiez la documentation du plugin concerné avant de supposer qu’il fonctionne.
- Un widget encart HTML personnalisé mérite une relecture ligne par ligne, car le texte y est souvent mélangé à des balises et peut être partiellement oublié lors d’une traduction rapide.
Le cas particulier du widget Articles récents
Un widget « Articles récents » natif de WordPress interroge la base de données sans filtre de langue par défaut. Avec Polylang, ce filtre s’applique automatiquement dès lors que l’extension est active, car elle modifie la requête principale de WordPress pour n’inclure que les contenus de la langue courante. Avec WPML, le comportement dépend du réglage global de compatibilité des requêtes personnalisées, accessible dans WPML > Réglages, section « Langue du contenu affiché par les requêtes personnalisées ».
Je vérifie toujours ce réglage de requête personnalisée en tout premier lieu quand un client me signale un widget « Articles récents » qui mélange les langues : neuf fois sur dix, c’est la seule cause du problème.
Construire une checklist de recette dédiée aux widgets
Pour éviter de reproduire l’oubli de l’encart horaires, j’ai ajouté à mes recettes de mise en production une étape spécifique aux zones de widgets, distincte de la vérification du contenu éditorial. Elle consiste à ouvrir l’écran Apparence > Widgets, à lister toutes les zones affichées par langue, et à comparer visuellement leur contenu avec une capture d’écran de référence validée par le client.
| Type de widget | Risque principal | Vérification recommandée |
|---|---|---|
| Texte libre | Contenu jamais traduit | Comparer chaque langue manuellement |
| Articles récents | Mélange des langues | Vérifier le réglage requêtes personnalisées |
| Encart HTML | Traduction partielle | Relecture ligne par ligne du code |
En résumé
Les widgets classiques ne bénéficient d’aucune traduction automatique par WordPress : chaque plugin multilingue propose sa propre méthode, zones dupliquées pour Polylang, bouton de traduction pour WPML, et il revient à l’équipe éditoriale de vérifier chaque zone dans chaque langue avant publication. Une checklist dédiée à la sidebar, séparée de la checklist de contenu éditorial classique, évite ce type d’oubli qui passe facilement inaperçu pendant des mois.
