Le WordPress d'aujourd'hui, décodé pour les développeurs

Thèmes

Quand un plugin de traduction écrase le fichier de langue du thème lui-même

Certaines chaînes traduites du thème redeviennent anglaises un jour sur deux, sans intervention humaine : deux sources de traduction se disputent le même fichier.

Par Clément Hadrot • 5 janvier 2026 • 5 min de lecture • Aucun commentaire
Quand un plugin de traduction écrase le fichier de langue du thème lui-même

-rw-r--r-- 1 www-data www-data 8412 janv. 4 03:12 mon-theme-fr_FR.mo, puis le lendemain -rw-r--r-- 1 www-data www-data 6890 janv. 5 03:07 mon-theme-fr_FR.mo : deux tailles différentes, sur le même fichier, à un jour d’intervalle, sans qu’aucune personne de l’équipe n’ait touché aux traductions. Un client a fini par signaler que trois libellés du thème redevenaient anglais de façon aléatoire, avant de repasser en français quelques jours plus tard, sans logique apparente.

Ce chantier ne revient pas sur le conflit de text domain déjà documenté entre un thème et l’extension Loco Translate : la situation ici implique deux mécanismes distincts qui écrivent, chacun de leur côté, dans le même emplacement de fichier, sans se coordonner ni même se connaître.

Symptôme : des chaînes qui reviennent à leur version d’origine par intermittence

Le comportement observé n’est ni permanent ni aléatoire au sens strict : il suit un cycle régulier, correspondant à la fréquence des tâches planifiées de WordPress. Certaines chaînes traduites manuellement dans le thème disparaissent après le passage d’une tâche cron, remplacées par leur version d’origine en anglais, avant qu’une autre tâche ne les restaure quelques heures plus tard.

  • Le comportement touche uniquement les chaînes du thème, pas celles d’une extension.
  • Aucune erreur PHP n’apparaît dans les journaux : les deux mécanismes en cause fonctionnent chacun normalement.
  • Le fichier concerné change de taille et de date de modification plusieurs fois par semaine, sans intervention manuelle.

Diagnostic : deux sources écrivent le même fichier .mo

Le premier mécanisme est natif à WordPress : depuis WordPress 4.6, le cœur télécharge automatiquement, via une tâche planifiée, les traductions communautaires disponibles sur translate.wordpress.org pour les thèmes installés, et les place dans wp-content/languages/themes/mon-theme-fr_FR.mo. Le second mécanisme, ici une extension d’aide à la traduction installée par l’équipe, régénère elle aussi un fichier .mo personnalisé au même emplacement, à partir des modifications saisies manuellement par le client. Chaque exécution de tâche planifiée écrase le résultat de l’autre, sans qu’aucun des deux mécanismes ne détecte le conflit.

L'essentiel à retenir : Deux mécanismes distincts peuvent écrire le même fichier .mo, sans se connaître ; Le filtre load_textdomain_mofile permet de reprendre la main sur la priorité ; La prévention passe par un seul point de vérité désigné pour chaque texte

Vérifier l’hypothèse avant de corriger

Avant toute correction, il convient de confirmer le mécanisme en observant l’horodatage du fichier sur plusieurs jours, et en comparant son contenu binaire aux deux sources suspectées :

ls -la wp-content/languages/themes/mon-theme-fr_FR.mo
wp language theme list mon-theme
wp cron event list --hook=wp_maybe_auto_update_translation

Si un événement planifié de mise à jour des traductions apparaît dans la liste, et que le fichier change de taille peu après son exécution, l’hypothèse d’un conflit entre les deux sources se confirme.

Correctif : désigner une seule source de vérité

La correction consiste à choisir explicitement quelle source doit avoir la priorité, plutôt que de laisser les deux mécanismes se disputer le fichier. Le filtre load_textdomain_mofile permet de rediriger le chargement des traductions du thème vers un fichier dédié, à l’abri des mises à jour automatiques :

<?php
add_filter( 'load_textdomain_mofile', function ( $mofile, $domain ) {
    if ( 'mon-theme' === $domain ) {
        return get_stylesheet_directory() . '/languages/mon-theme-fr_FR-personnalise.mo';
    }
    return $mofile;
}, 10, 2 );

Ce fichier personnalisé, placé dans le thème lui-même et versionné avec le code, échappe aux mises à jour automatiques de traductions communautaires comme aux régénérations de l’extension tierce. Il devient le seul point de vérité pour les chaînes du thème, alimenté manuellement par l’équipe à partir des retours du client.

Prévention : documenter le circuit de traduction dès le départ

Sur un projet multilingue, le circuit de traduction mérite d’être décidé et documenté avant la première modification de chaîne : qui édite quoi, avec quel outil, et quel fichier fait autorité en cas de désaccord entre deux sources. Cette décision, prise une seule fois en début de projet, évite le diagnostic long et incertain qu’impose un conflit découvert après plusieurs mois de production.

Deux mécanismes de traduction qui ignorent l’existence l’un de l’autre finissent toujours par se marcher dessus : la solution n’est jamais de les laisser cohabiter, mais de désigner lequel des deux a le dernier mot.

En résumé

Une chaîne traduite qui revient périodiquement à sa version d’origine, sans erreur visible dans les journaux, trahit presque toujours deux sources distinctes qui écrivent le même fichier de langue à intervalles différents. Rediriger le chargement des traductions du thème vers un fichier dédié, via le filtre load_textdomain_mofile, règle le conflit de façon durable, sans dépendre d’une désactivation manuelle de l’un des deux mécanismes en cause.

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