Traduire des blocs de requête (Query Loop) avec du contenu en plusieurs langues

Peu après la sortie de WordPress 5.9 et son éditeur de site complet, un client ayant migré son thème vers un thème basé sur des blocs a construit sa page d’accueil avec un bloc Query Loop affichant les trois derniers articles publiés. Le rendu, correct en apparence lors de la construction dans l’éditeur, affichait en réalité sur le site publié un mélange d’articles français et anglais dès qu’un article avait été publié dans les deux langues à des dates proches l’une de l’autre.

Ce cas est spécifique au contexte de l’éditeur de site et des thèmes à blocs : le bloc Query Loop, nouveauté majeure de WordPress 5.9, repose sur un mécanisme de requête différent de celui d’un thème classique basé sur des templates PHP, et les extensions multilingues n’appliquaient pas encore systématiquement leur filtre de langue habituel à ce nouveau contexte au moment de sa sortie.

Comprendre la requête générée par le bloc Query Loop

Le bloc Query Loop génère sa requête à partir des réglages choisis dans l’éditeur (type de contenu, nombre d’articles, tri, filtres de taxonomie), transformés en arguments de WP_Query au moment du rendu de la page. WordPress expose un filtre dédié pour cette transformation, nommé query_loop_block_query_vars, qui permet de modifier ou compléter ces arguments avant l’exécution de la requête finale.

Ajouter le filtre de langue au bon endroit

La correction consiste à accrocher une fonction sur ce filtre spécifique, en y ajoutant l’argument de langue reconnu par l’extension multilingue installée :

<?php
add_filter( 'query_loop_block_query_vars', function( $query_vars, $block, $page ) {
    if ( function_exists( 'pll_current_language' ) ) {
        $query_vars['lang'] = pll_current_language();
    }
    return $query_vars;
}, 10, 3 );

Ce filtre s’applique à l’ensemble des blocs Query Loop du site, quel que soit le gabarit dans lequel ils sont insérés, ce qui évite d’avoir à corriger chaque page individuellement. C’est un avantage net par rapport à une correction ponctuelle dans un template PHP classique, qui ne couvrirait qu’un seul emplacement du site.

Le comportement diffère entre l’éditeur et le site publié

Un point qui a d’abord semé la confusion chez ce client : dans l’éditeur de site, la prévisualisation du bloc Query Loop s’exécute dans le contexte de langue de l’administrateur connecté, généralement configuré sur la langue par défaut du site. Le mélange de langues n’était donc pas visible pendant la construction de la page, uniquement une fois publiée et consultée par un visiteur naviguant sur la version anglaise du site. Toute vérification de ce type de bloc doit impérativement se faire sur le site publié, dans chaque langue, jamais uniquement dans l’aperçu de l’éditeur.

Le cas des filtres de taxonomie ajoutés dans l’éditeur

Quand un bloc Query Loop est configuré avec un filtre de catégorie choisi directement dans l’éditeur, ce filtre s’ajoute aux arguments de requête existants sans entrer en conflit avec l’argument de langue ajouté par le filtre PHP ci-dessus : les deux se combinent naturellement dans la requête finale, WordPress appliquant l’ensemble des conditions cumulées. Aucune configuration supplémentaire n’est nécessaire pour ce cas de figure, à condition bien sûr que les termes de taxonomie utilisés existent correctement dans chaque langue du site.

• Testez le rendu du bloc sur le site publié, dans chaque langue, jamais uniquement dans l’aperçu de l’éditeur de site.
• Vérifiez le comportement du bloc dans un gabarit de type archive, pas seulement sur la page d’accueil où le bloc a été initialement repéré comme défaillant.
• Un cache de page doit être vidé après l’ajout de ce filtre pour éviter de continuer à afficher une version mise en cache avant correction.

Pourquoi ce cas ne concerne pas la traduction des patterns eux-mêmes

Cette correction porte uniquement sur le filtrage des articles affichés par un bloc Query Loop existant, pas sur la traduction du contenu fixe éventuellement présent dans un modèle de bloc (pattern) qui entourerait ce Query Loop, comme un titre de section ou un texte d’introduction. Cette traduction de patterns suit une logique différente, propre à la gestion des templates de l’éditeur de site, et mérite un traitement distinct qui ne sera pas développé ici.

Depuis la généralisation de l’éditeur de site, j’ajoute systématiquement ce filtre query_loop_block_query_vars dès la mise en place initiale d’un site multilingue basé sur des blocs, plutôt que d’attendre qu’un client signale un mélange de langues en production.

En résumé

Le bloc Query Loop de l’éditeur de site n’applique aucun filtre de langue par défaut, un comportement qui peut rester invisible dans l’éditeur lui-même mais qui se manifeste clairement sur le site publié. Le filtre query_loop_block_query_vars, combiné à la fonction de langue courante de l’extension multilingue installée, corrige ce comportement pour l’ensemble des blocs du site en une seule intervention, à condition de toujours vérifier le résultat sur le site publié plutôt que dans l’aperçu de l’éditeur.