Faut-il rassembler tous les libellés d’un thème dans un seul fichier de configuration, ou laisser chaque gabarit porter ses propres appels à __() et esc_html__() ? La question se pose dès qu’un projet grandit au-delà d’une dizaine de gabarits et que plusieurs langues doivent rester cohérentes dans le temps. Ce n’est pas un détail de style : c’est un choix d’architecture qui détermine qui peut modifier un libellé, avec quel risque d’erreur, et combien de temps prendra la prochaine campagne de traduction.
Ce choix ne concerne pas la génération du fichier .pot lui-même, qui reste identique dans les deux cas grâce à wp i18n make-pot. Il concerne l’endroit où vivent les chaînes source avant même d’être extraites : dans un fichier dédié qui centralise les libellés du thème, ou directement à l’endroit où elles s’affichent, gabarit par gabarit.
La centralisation : un fichier qui rassemble les libellés
La première approche consiste à créer un fichier, par exemple inc/labels.php, qui déclare des constantes ou des fonctions retournant les chaînes traduisibles utilisées par plusieurs gabarits : les intitulés de boutons récurrents, les messages d’état, les libellés de formulaires. Chaque gabarit appelle ensuite une fonction du thème plutôt qu’un __() direct.
- Un seul endroit à ouvrir pour vérifier la cohérence d’un libellé répété douze fois dans le thème.
- Un risque de fichier qui grossit sans limite si personne ne le découpe par domaine fonctionnel.
- Une indirection supplémentaire : le traducteur qui relit un gabarit ne voit plus la chaîne, seulement un appel de fonction.
La délégation : chaque gabarit porte ses propres chaînes
La seconde approche laisse chaque fichier de gabarit appeler directement _e(), __() ou esc_attr__() avec le texte source en argument, comme le recommande la documentation de WordPress pour l’internationalisation des thèmes. Le contexte de la chaîne reste visible au même endroit que son usage.
- Une relecture contextuelle immédiate : le traducteur voit la chaîne dans son environnement d’affichage.
- Un risque réel de doublons : la même formule saisie deux fois avec une variante d’espace ou de ponctuation devient deux chaînes distinctes dans le fichier
.pot. - Une dette qui grossit avec le nombre de gabarits, sans point de contrôle unique.
Le tableau comparatif
| Critère | Chaînes centralisées | Chaînes déléguées |
|---|---|---|
| Nombre de fichiers à ouvrir pour un audit | Un ou deux | Autant que de gabarits concernés |
| Risque de doublon de chaîne | Faible | Élevé sans discipline d’équipe |
| Lisibilité pour le traducteur | Moyenne, hors contexte | Bonne, en contexte |
| Charge de refactorisation initiale | Réelle, à prévoir dès le départ | Nulle, elle suit l’écriture du gabarit |
| Adapté à combien de langues cibles | À partir de trois langues et plus | Convient jusqu’à deux langues |
Un exemple concret de fonction centralisée
<?php
// inc/labels.php
function theme_label( $key ) {
$labels = array(
'cta_contact' => __( 'Prendre rendez-vous', 'mon-theme' ),
'cta_devis' => __( 'Demander un devis', 'mon-theme' ),
'etat_charge' => __( 'Chargement en cours…', 'mon-theme' ),
);
return isset( $labels[ $key ] ) ? $labels[ $key ] : '';
}
Ce fichier devient le point d’entrée unique pour tout libellé partagé par au moins deux gabarits. Un libellé utilisé une seule fois n’a, lui, aucune raison d’y figurer : il reste dans son gabarit, avec un appel direct à __().
Le critère qui tranche : le nombre de traducteurs impliqués
Sur un projet mené par une seule personne qui code et traduit à la fois, la délégation suffit largement : le contexte reste sous les yeux, et la charge de maintenance reste faible. Dès qu’une deuxième personne relit les traductions sans connaître le code, la centralisation partielle des libellés répétés devient un vrai gain de temps, parce qu’elle évite d’expliquer où se trouve chaque variante d’un même bouton.
Ne centralisez que les chaînes réellement partagées entre plusieurs gabarits. Une chaîne unique dans un fichier centralisé n’apporte rien, sinon un aller-retour de plus pour la lire.
Une approche mixte, la plus fréquente en pratique
Dans la majorité des projets multilingues suivis sur plusieurs années, la solution qui tient dans le temps combine les deux : un fichier labels.php pour les chaînes transverses (boutons, messages système, textes de formulaire), et des appels directs pour tout le reste. Le fichier centralisé reste volontairement court, rarement plus d’une cinquantaine d’entrées, ce qui le garde lisible et évite qu’il devienne un second thème caché dans un seul fichier.
Cette organisation facilite aussi un futur passage à un plugin de traduction comme Polylang ou WPML : les chaînes centralisées deviennent le premier lot à vérifier lors d’un audit de cohérence entre langues, avant même de lancer une nouvelle extraction du fichier .pot.
Notre verdict
Centraliser les chaînes d’un thème n’est pas une bonne pratique universelle : c’est une réponse à un problème précis, celui de la cohérence entre plusieurs traducteurs sur un nombre élevé de gabarits. En dessous de ce seuil, la délégation reste la voie la plus simple et la plus honnête vis-à-vis du code. Le signal à surveiller n’est pas le nombre de chaînes, mais le nombre de fois où une même formule a dû être corrigée séparément dans plusieurs fichiers : dès que ce chiffre dépasse deux ou trois occurrences, il est temps d’extraire la chaîne vers un point commun.
