WordPress 5.8, sorti en juillet 2021, a introduit le format de templates au format bloc et les widgets par blocs, sans encore livrer l’écran complet du Site Editor, réservé au plugin Gutenberg en mode expérimental. C’est sur cette base, mêlant fonctionnalités stables du cœur et compléments expérimentaux du plugin, qu’un site multilingue a été construit pour un client actif en France et en Belgique, avec Polylang comme extension de gestion des langues, déjà éprouvée sur plusieurs projets antérieurs de l’agence.
L’hypothèse de départ était optimiste : Polylang, mature sur les thèmes classiques, gérerait sans trop de friction les nouveaux éléments du thème bloc. La réalité a été plus nuancée, et ce retour d’expérience assume de raconter les difficultés rencontrées, pas seulement les solutions trouvées après coup.
Le problème : les template parts ne se dupliquent pas nativement par langue
Un template part, dans un thème bloc, est un contenu structuré, stocké comme un article du type wp_template_part. Polylang, à cette date, sait dupliquer et traduire correctement les articles, pages et taxonomies classiques, mais son support des types de contenu liés au thème bloc restait, en novembre 2021, expérimental et partiellement documenté.
Concrètement, un template part d’en-tête traduit en néerlandais pour le public belge n’était pas automatiquement proposé au bon moment : le site continuait d’afficher la version française du menu de navigation, même sur les pages explicitement marquées comme néerlandaises dans Polylang.
Diagnostic : un défaut de liaison entre langue active et template part
L’inspection du comportement a montré que le mécanisme de résolution de templates de WordPress, qui choisit quel fichier ou quel article de type wp_template_part afficher, ne consultait pas la langue active définie par Polylang pour déterminer la bonne variante à charger. Les deux systèmes, chacun cohérent pris isolément, ne communiquaient simplement pas entre eux à ce stade.
Correctif : un filtre maison pour router la bonne variante
La solution retenue a été d’intercepter la résolution du template part via le filtre render_block_data, en réinjectant l’identifiant du template part correspondant à la langue active, déterminée par la fonction pll_current_language() fournie par Polylang.
add_filter( 'render_block_data', function ( $bloc ) {
if ( 'core/template-part' !== $bloc['blockName'] ) {
return $bloc;
}
$langue = function_exists( 'pll_current_language' ) ? pll_current_language() : 'fr';
if ( 'fr' !== $langue ) {
$bloc['attrs']['slug'] .= '-' . $langue;
}
return $bloc;
} );
Cette approche suppose une convention de nommage stricte pour les template parts : un fichier header.html pour le français, et un fichier header-nl.html distinct pour le néerlandais, créé manuellement dans le Site Editor puis dupliqué à chaque évolution du contenu, une contrainte de maintenance assumée faute de mieux à cette date.
Ce que cette solution n’a pas résolu
Le filtre fonctionne pour les template parts explicitement dupliqués, mais ne résout pas la synchronisation de contenu entre langues : toute modification du menu de navigation en français doit être répercutée manuellement sur la variante néerlandaise, sans aucun mécanisme de traduction assistée comme celui dont bénéficient les articles classiques via l’interface de Polylang.
- Documenter clairement, pour l’équipe éditoriale, quelles zones du site nécessitent une double modification manuelle.
- Prévoir, dans le devis, une marge de temps pour ce type de contrainte technique encore non résolue par les extensions.
- Surveiller les prochaines versions de Polylang, dont le support du thème bloc s’annonçait en cours d’amélioration active.
Sur ce projet, la leçon la plus utile n’a pas été technique mais commerciale : annoncer clairement au client, avant le développement, que le multilingue sur un thème bloc coûterait plus cher que sur un thème classique à cette date, plutôt que de découvrir le surcoût en cours de route.
Ce que ce retour ne couvre pas
Ce billet ne traite pas de WPML, alternative à Polylang non testée sur ce projet, ni de la traduction automatique des patterns, fonctionnalité qui n’existait tout simplement pas à cette date sur aucune des deux extensions. Il documente uniquement l’expérience vécue avec la combinaison Polylang et template parts sous WordPress 5.8.
Pour aller plus loin
Ce genre de friction, propre à une technologie encore jeune, a vocation à se résorber avec les mises à jour successives de Polylang et la stabilisation du Site Editor lui-même. En attendant, ce retour d’expérience sert avant tout à alerter d’autres équipes sur un piège concret, plutôt qu’à vanter une solution parfaite : trois jours de travail imprévus, sur ce seul point, valent la peine d’être anticipés dans un futur devis.
