Que devient une chaîne traduite via une extension de traduction de chaînes, une fois que le thème classique qui l’affichait est remplacé par un thème de blocs ? La question mérite d’être posée avant la migration, pas après, car la réponse dépend entièrement de l’endroit où vivait cette chaîne : dans le contenu d’un article, elle survit sans problème ; dans un fichier PHP de gabarit ou un widget classique, elle disparaît souvent avec le gabarit lui-même.
Cette checklist ne couvre pas la migration des templates en tant que telle (un sujet à part entière), mais uniquement ce qui concerne spécifiquement la préservation des traductions déjà produites, souvent à grand coût, sur l’ancien thème.
1. Auditer où vivent réellement les chaînes traduites
Avant toute migration, il faut lister précisément les sources de traduction du site : contenu d’articles et de pages (survit naturellement, indépendant du thème), chaînes de thème enregistrées via __() dans les fichiers PHP (liées au domaine de texte du thème, disparaissent si le thème change de domaine), widgets classiques traduits (liés à leur instance, à vérifier un par un), et menus de navigation (généralement indépendants du thème, donc préservés).
2. Vérifier le domaine de texte du nouveau thème de blocs
Un thème de blocs déclare son propre domaine de texte, distinct de celui de l’ancien thème classique. Toute chaîne traduite via une table de correspondance liée à l’ancien domaine (mon-ancien-theme) devient invisible si le nouveau thème utilise un domaine différent (mon-theme-fse), même si le texte source est identique caractère pour caractère.
// Ancien thème classique
__( 'Découvrir nos services', 'mon-ancien-theme' );
// Nouveau thème de blocs
__( 'Découvrir nos services', 'mon-theme-fse' );Une extension de traduction de chaînes indexe généralement par couple (texte source, domaine). Un changement de domaine, même pour un texte identique, crée une entrée orpheline qu’il faut retraduire ou réassocier manuellement.
3. Comprendre le statut particulier des templates FSE traduits
Avec l’édition complète du site, un template ou une partie de template personnalisée devient une entité stockée en base (type wp_template), pas un simple fichier PHP. Si le projet a besoin de variantes de template par langue (un en-tête différent en arabe pour des raisons de direction d’écriture, par exemple), chaque variante doit être créée comme une entité distincte, avec sa propre logique d’association à la langue — un mécanisme entièrement différent du système de chaînes traduites classique.
4. Ne pas oublier les widgets classiques traduits
Les widgets classiques, encore présents sur de nombreux thèmes hybrides via la zone de widgets sidebar-1, stockent leur contenu et leurs réglages dans l’option widget_{type}. Une traduction appliquée sur le texte d’un widget classique (via une extension de traduction de chaînes ou une simple option en base) ne suit généralement pas la migration vers des blocs, puisque les widgets deviennent alors des blocs autonomes stockés différemment. Il faut prévoir une passe de recréation manuelle de ce contenu en blocs, langue par langue.
5. Tester le sélecteur de langue sur chaque type de page migré
Une fois la migration technique terminée, la vérification finale consiste à parcourir le sélecteur de langue sur un échantillon représentatif : page d’accueil, article de blog, page de catégorie, page de contact. Un test superficiel sur la seule page d’accueil manque souvent les régressions qui touchent des templates secondaires, moins visibles mais tout aussi consultés par les visiteurs.
- Page d’accueil : vérifier le template FSE et ses parties (en-tête, pied de page) dans chaque langue
- Article de blog : vérifier que le contenu traduit s’affiche toujours, indépendamment du template
- Page de contact : souvent porteuse d’un widget ou d’un formulaire, point sensible de la migration
Une migration vers l’édition complète du site déplace la frontière entre ce qui est « contenu » et ce qui est « gabarit » : toute traduction qui vivait du mauvais côté de cette frontière avant la migration mérite d’être revérifiée après.
Pour aller plus loin
Cette checklist ne remplace pas un plan de migration complet des templates eux-mêmes, qui relève d’une démarche distincte et plus large. Elle vise seulement à éviter la surprise la plus fréquente observée sur ce type de projet : une équipe éditoriale qui découvre, plusieurs semaines après la mise en production du nouveau thème, que telle ou telle traduction patiemment construite a discrètement disparu avec l’ancien gabarit qui la portait.
