Articles liés multilingues : afficher le bon contenu associé dans chaque langue

Un client m’a signalé qu’en bas de ses pages produit, le bloc « Produits similaires » affichait parfois trois références en français, parfois un mélange de français et d’anglais, sans logique apparente pour un visiteur naviguant sur la version française du site. Le développeur précédent avait codé ce bloc avec une requête WP_Query personnalisée basée sur la taxonomie de catégorie produit, sans jamais penser à y ajouter un filtre de langue.

Ce cas est extrêmement courant sur les sites multilingues : toute requête WP_Query écrite à la main, en dehors de la boucle principale de WordPress, échappe par défaut au filtre de langue appliqué automatiquement par Polylang ou WPML sur la requête principale de la page. Il faut l’ajouter explicitement.

Pourquoi la requête principale est filtrée mais pas les requêtes secondaires

Polylang et WPML interceptent la requête principale de WordPress (celle qui détermine le contenu affiché sur la page en cours) via le hook pre_get_posts, et y ajoutent automatiquement une condition sur la langue. Mais une requête personnalisée créée dans un template avec new WP_Query( $args ) n’est pas automatiquement une requête « principale » au sens de WordPress : selon la configuration de l’extension multilingue, elle peut ou non hériter du même filtre, et il vaut toujours mieux ne pas compter sur ce comportement implicite.

La correction avec Polylang

Polylang expose la fonction pll_current_language(), qui renvoie le code de la langue actuellement affichée. Ce code s’ajoute directement dans les arguments de la requête, via le paramètre lang reconnu nativement par Polylang :

<?php
$args = array(
    'post_type'      => 'product',
    'posts_per_page' => 3,
    'post__not_in'   => array( get_the_ID() ),
    'tax_query'      => array(
        array(
            'taxonomy' => 'product_cat',
            'field'    => 'term_id',
            'terms'    => $categories,
        ),
    ),
    'lang'           => pll_current_language(),
);
$produits_similaires = new WP_Query( $args );
?>

L’ajout de la clé 'lang' => pll_current_language() suffit : Polylang reconnaît ce paramètre dans n’importe quelle requête WP_Query et filtre les résultats en conséquence, sans nécessiter de modification supplémentaire.

La correction avec WPML

WPML fonctionne différemment : il ne reconnaît pas de paramètre lang natif dans WP_Query. Le filtrage passe par un réglage global activable dans WPML > Réglages, section « Langue du contenu affiché par les requêtes personnalisées », avec trois options possibles : langue courante, toutes les langues, ou une langue spécifique. Une fois ce réglage sur « Langue actuellement affichée », toute requête WP_Query du thème est automatiquement filtrée sans modification de code, ce qui simplifie l’intégration pour un thème déjà écrit sans considération multilingue.

Le cas des taxonomies partagées entre langues

Le rapprochement par taxonomie, comme dans l’exemple ci-dessus avec product_cat, suppose que chaque terme de taxonomie existe dans chaque langue et que l’article traduit est bien rattaché au terme traduit correspondant, et non au terme de la langue source. Ce point mérite une vérification distincte, propre à la configuration des taxonomies elles-mêmes, qui ne sera pas traitée ici puisqu’elle dépend de réglages différents de ceux d’une simple requête.

Vérifier le résultat sur plusieurs cas de figure

Une correction de requête doit être testée sur plusieurs scénarios, pas seulement sur la page qui a signalé le problème initialement. Je vérifie systématiquement quatre cas : une page dont tous les articles associés existent dans la langue courante, une page où un seul article associé existe encore dans la langue par défaut faute de traduction, une page sans aucun article associé disponible dans la langue courante, et enfin le comportement sur une langue tierce si le site en compte plus de deux.

• Le cas « zéro résultat » doit afficher un message ou masquer le bloc proprement, jamais une erreur PHP silencieuse.
• Un test avec WP_DEBUG activé permet de repérer une requête mal formée avant la mise en production.
• Un cache de fragment de page doit être invalidé par langue, sinon le résultat filtré d’une langue peut rester affiché sur une autre après un changement de cache.

Documenter la règle pour l’équipe

Après cette correction, j’ai ajouté une note dans la documentation technique interne du projet : toute nouvelle requête WP_Query écrite dans ce thème doit inclure le filtre de langue approprié selon l’extension installée, avec un exemple de code type comme référence. Cette règle simple évite qu’un futur développeur reproduise l’erreur sur un autre bloc du même site.

Je considère qu’une requête personnalisée sans filtre de langue explicite sur un site multilingue est un bug latent, même si elle fonctionne correctement au moment où elle est écrite : le jour où une deuxième langue reçoit du contenu réel, l’erreur devient visible.

En résumé

Une requête WP_Query personnalisée n’hérite jamais automatiquement du filtre de langue appliqué à la requête principale d’une page. Avec Polylang, l’argument lang ajouté directement à la requête suffit. Avec WPML, le réglage global des requêtes personnalisées couvre l’ensemble du thème sans modification de code. Dans les deux cas, tester sur plusieurs scénarios de disponibilité de traduction reste indispensable avant de considérer le correctif terminé.