vendredi 25 septembre 2026

À propos

Contact

Thèmes

Traduire un pattern de thème bloc sans fichier .pot classique

Un thème bloc destiné à l'international doit marquer les chaînes de ses patterns correctement. La bonne fonction de traduction pour du HTML enregistré en PHP, pas de .pot ici.

Par Clément Hadrot • 27 mars 2023 • 5 min de lecture • Aucun commentaire
Traduire un pattern de thème bloc sans fichier .pot classique

Une entreprise de formation en ligne déployait son thème bloc maison sur trois marchés simultanément : francophone, anglophone et hispanophone. Les templates principaux avaient été correctement internationalisés dès la conception, mais les patterns de mise en page, des sections de témoignages et d’appels à l’action réutilisables, contenaient encore du texte français en dur, invisible pour le système de traduction du thème alors que ces mêmes patterns fonctionnaient parfaitement en apparence sur le marché francophone.

Ce tutoriel montre comment marquer correctement les chaînes d’un pattern destiné à l’international. La traduction d’un thème classique via un fichier .pot traditionnel, déjà couverte séparément, ne fait pas l’objet de cet article : ici, le sujet est spécifiquement les patterns d’un thème bloc, dont l’enregistrement diffère fondamentalement.

Deux façons d’enregistrer un pattern, deux réalités très différentes

La confusion de départ vient du fait qu’un pattern peut être enregistré de deux manières distinctes, avec des conséquences radicalement opposées sur la traduction. La première consiste à placer un fichier HTML statique dans le dossier patterns/ du thème, avec un en-tête de commentaire PHP pour les métadonnées, chargé automatiquement par WordPress depuis la version 6.0. La seconde consiste à appeler register_block_pattern() explicitement dans du code PHP, avec le contenu du pattern passé en tant que chaîne de caractères.

Seule la seconde approche permet un marquage de traduction fonctionnel avec les outils standards de WordPress, parce qu’elle seule s’exécute réellement en tant que code PHP interprété au moment du chargement, capable d’appeler des fonctions de traduction.

Le pattern en fichier HTML brut : hors de portée

Un fichier patterns/temoignage.html chargé automatiquement par le thème contient du HTML statique, jamais interprété comme du PHP. Toute chaîne de texte qui s’y trouve reste figée telle quelle, sans jamais passer par une fonction de traduction, quelle que soit la langue active du site.

<?php
/**
 * Title: Témoignage client
 * Slug: entreprise/temoignage
 * Categories: temoignages
 */
?>
<!-- wp:paragraph -->
<p>Nos clients nous font confiance depuis 2015</p>
<!-- /wp:paragraph -->

Même si ce fichier commence par un bloc PHP pour les métadonnées d’en-tête, le corps HTML qui suit n’est jamais passé à une fonction de traduction : c’est du contenu figé, littéralement recopié tel quel dans l’éditeur à chaque insertion du pattern, quelle que soit la langue de l’utilisateur.

L'essentiel à retenir : Un pattern déclaré en PHP peut passer chaque chaîne dans une fonction de traduction ; Un pattern purement HTML statique échappe totalement à ce mécanisme ; wp i18n make-pot détecte les chaînes correctement marquées, pas les autres

Basculer vers register_block_pattern pour un contenu traduisible

Pour rendre un pattern réellement traduisible, il faut construire son contenu HTML dans une variable PHP en y insérant les chaînes via __() ou esc_html__(), puis enregistrer le tout avec register_block_pattern() plutôt que de déposer un fichier statique.

function entreprise_register_patterns() {
    $texte = esc_html__( 'Nos clients nous font confiance depuis 2015', 'entreprise' );

    $contenu = '<!-- wp:paragraph --><p>' . $texte . '</p><!-- /wp:paragraph -->';

    register_block_pattern(
        'entreprise/temoignage',
        array(
            'title'      => __( 'Témoignage client', 'entreprise' ),
            'categories' => array( 'temoignages' ),
            'content'    => $contenu,
        )
    );
}
add_action( 'init', 'entreprise_register_patterns' );

Avec cette approche, chaque chaîne passe par le mécanisme standard de traduction de WordPress, exactement comme n’importe quelle chaîne de functions.php. Le texte du pattern s’affiche alors dans la langue active de l’éditeur, à condition qu’un fichier de traduction correspondant existe pour le domaine de texte du thème.

Générer et vérifier le fichier de traduction

La commande WP-CLI dédiée à l’internationalisation détecte automatiquement les chaînes correctement marquées, y compris celles issues de patterns enregistrés en PHP de cette façon.

wp i18n make-pot . languages/entreprise.pot

En exécutant cette commande avant et après la migration des patterns, la différence était nette : zéro chaîne de pattern détectée avant la conversion, contre l’ensemble des chaînes correctement extraites après le passage à register_block_pattern(). C’est un bon test de vérification rapide pour confirmer qu’un pattern est réellement internationalisable, sans avoir à tester manuellement chaque langue.

Un compromis : générer le HTML depuis un fichier, mais en PHP

Pour éviter de construire tout le HTML du pattern directement dans une chaîne PHP peu lisible, une alternative consiste à conserver un fichier de gabarit HTML séparé, avec des espaces réservés remplacés dynamiquement, puis à injecter les chaînes traduites via sprintf() ou str_replace() avant de passer le résultat à register_block_pattern(). Sur ce projet, cette approche a permis de garder des patterns complexes lisibles pour les intégrateurs tout en conservant la traduction fonctionnelle.

En résumé

Un pattern de thème bloc chargé comme simple fichier HTML statique échappe totalement au système de traduction de WordPress, quel que soit le soin apporté par ailleurs au reste du thème. Seul un enregistrement explicite via register_block_pattern(), avec chaque chaîne passée dans une fonction de traduction comme __(), rend le contenu du pattern réellement traduisible et détectable par les outils standards comme wp i18n make-pot.

Partager :

À propos de l'auteur

Clément Hadrot

Développeur WordPress, passionné par Elementor, le FSE et l’automatisation par IA.

Voir tous ses articles

Dans la même veine

À lire aussi