Le pattern « bandeau d’alerte » avait été construit une fois, avec soin, puis synchronisé pour pouvoir l’insérer sur plusieurs pages du site sans devoir recréer sa mise en forme à chaque fois. Six mois plus tard, le site est passé au multilingue. Résultat : le bandeau affichait toujours son texte français d’origine, même sur les pages traduites en anglais, en allemand et en italien. Modifier le texte depuis n’importe quelle page le modifiait certes partout — mais toujours dans la même langue, celle du texte d’origine.
C’est le comportement attendu d’un pattern synchronisé, pas un bug : sa raison d’être est justement de partager un contenu identique à tous les endroits où il est inséré. Le problème apparaît seulement quand ce contenu doit varier selon la langue, ce qui contredit directement le principe de synchronisation. Voici comment on a résolu ce paradoxe sans renoncer à l’intérêt du pattern.
Pourquoi un pattern synchronisé ignore la langue
Un pattern synchronisé (introduit en 2023 sous le nom de « bloc réutilisable » avant d’être renommé) est stocké comme un contenu unique en base de données, de type wp_block, référencé par son identifiant depuis chaque page où il est inséré. Toute modification de ce contenu se répercute instantanément partout où le pattern apparaît, quelle que soit la langue de la page hôte.
Polylang et WPML traduisent les contenus de type article ou page en créant une copie distincte par langue. Un pattern synchronisé, lui, reste un contenu unique par défaut : il n’existe qu’une seule version en base, non liée à une langue précise, ce qui explique qu’il affiche toujours le même texte partout, indépendamment de la page qui l’accueille.
Séparer ce qui doit être identique de ce qui doit varier
La première étape, avant toute correction technique, consiste à se poser une question simple sur chaque pattern concerné : quelle partie doit vraiment rester identique entre langues (une mise en page, une couleur, une icône), et quelle partie doit varier (le texte du message, l’intitulé d’un bouton) ? Cette distinction change complètement la solution à appliquer.
- Si toute la structure doit varier (texte et mise en page adaptés par langue) : le pattern ne devrait pas être synchronisé, mais transformé en pattern classique, dupliqué et adapté librement par langue.
- Si seule la mise en page doit rester identique et seul le texte doit varier : la solution passe par la traduction Polylang ou WPML des chaînes de texte, pas par une désynchronisation complète.
La méthode retenue avec Polylang
Pour le bandeau d’alerte, la mise en page (couleur de fond, icône, disposition) devait rester identique partout, seul le texte du message devait varier par langue. Polylang propose depuis plusieurs versions une prise en charge des chaînes de texte à l’intérieur des patterns synchronisés, via le module « Traduction des chaînes » couplé à un marquage explicite du contenu traduisible.
- Le texte du bandeau a été extrait dans une chaîne dédiée via
pll_register_string(), appelée depuis le thème lors du chargement du pattern. - Cette chaîne est ensuite apparue dans Langues → Traductions des chaînes, où chaque langue a reçu sa propre valeur.
- Le pattern a été modifié pour afficher la chaîne traduite via
pll__()plutôt que le texte figé d’origine.
// Dans functions.php ou un fichier d'inclusion du thème
add_action('init', function () {
if (function_exists('pll_register_string')) {
pll_register_string(
'bandeau_alerte_texte',
'Livraison gratuite ce mois-ci',
'Bandeaux',
true // multiligne autorisé
);
}
});
// Dans le rendu du pattern
echo function_exists('pll__')
? pll__('Livraison gratuite ce mois-ci')
: 'Livraison gratuite ce mois-ci';
Ce mécanisme garde la synchronisation utile — la mise en page reste identique, une seule source à maintenir — tout en permettant à chaque langue d’afficher son propre texte, géré depuis un écran centralisé plutôt que dispersé sur chaque page.
Et avec WPML ?
WPML propose un mécanisme équivalent via son module « String Translation », combiné à l’enregistrement explicite des chaînes présentes dans les patterns via l’API icl_register_string() ou, plus simplement pour un contenu déjà présent dans un bloc, en scannant le thème depuis WPML → Traduction de thèmes et plugins, qui détecte automatiquement les chaînes de texte visibles dans le code du thème.
Ce qui ne fonctionne pas comme raccourci
Créer un pattern synchronisé différent par langue, en changeant simplement son nom (« Bandeau FR », « Bandeau EN »), fonctionne à court terme mais recrée exactement le problème que la synchronisation était censée résoudre : toute modification de mise en page doit alors être répétée manuellement dans chaque pattern, ce qui finit toujours par désynchroniser silencieusement les versions au bout de quelques mois.
Un pattern par langue n’est pas une traduction, c’est une duplication déguisée. Elle paraît plus simple le premier jour et coûte plus cher chaque mois suivant.
Notre check avant de synchroniser un pattern sur un site multilingue
Depuis cet incident, un contrôle simple précède la création de tout nouveau pattern synchronisé sur un site multilingue : lister précisément les éléments de texte qu’il contient, et vérifier pour chacun s’il doit varier selon la langue. Si oui, cette chaîne est enregistrée dès la création du pattern, jamais après coup une fois le contenu déjà dupliqué sur plusieurs pages en plusieurs langues.
Pour aller plus loin
Cette même logique de séparation entre structure figée et contenu traduisible s’applique à d’autres briques du thème bloc : les gabarits (theme.json), les parties de thème comme l’en-tête ou le pied de page, et plus largement tout élément conçu pour être réutilisé identique à travers le site. La règle reste la même : ce qui doit varier par langue doit passer par une chaîne enregistrée, jamais par un texte codé en dur dans la structure du bloc.
