Un dossier languages qui ne contenait jusque-là que des paires .po / .mo voit apparaître, sur un thème mis à jour vers une version compatible WordPress 6.5, des fichiers portant l’extension .l10n.php. Rien n’a changé dans les chaînes traduites elles-mêmes : c’est le format de stockage qui évolue, pas le contenu linguistique.
Ce nouveau format a été introduit avec WordPress 6.5, sorti en avril 2024, dans le cadre d’un effort plus large pour accélérer le chargement des traductions, en particulier sur les thèmes et extensions qui embarquent de nombreuses chaînes.
Pourquoi un nouveau format à côté du .mo
Le format .mo (Machine Object) est un format binaire compact, mais son analyse demande un travail de décodage à chaque chargement : lire l’en-tête, parcourir la table des chaînes, reconstruire les correspondances en mémoire. Ce coût, minime pour un petit nombre de chaînes, devient mesurable sur des thèmes ou extensions qui en embarquent plusieurs milliers, ou sur des sites où de nombreuses locales sont actives.
Le fichier .l10n.php évite ce travail de décodage : c’est un fichier PHP qui, une fois inclus, retourne directement un tableau associatif contenant les chaînes traduites, prêt à être utilisé sans étape d’analyse intermédiaire. PHP charge ce type de fichier nativement, avec l’avantage supplémentaire de pouvoir bénéficier du cache d’opcode déjà en place sur la plupart des hébergements (comme OPcache), ce qui n’était pas le cas pour un fichier .mo traité par le lecteur de traduction du cœur.
Comment WordPress choisit entre les deux formats
Le chargeur de traductions du cœur vérifie en priorité la présence d’un fichier .l10n.php correspondant à la locale demandée. S’il existe, il est utilisé directement. Sinon, WordPress retombe sur le fichier .mo classique, garantissant une compatibilité totale avec les traductions existantes qui n’ont pas encore été converties dans le nouveau format.
Générer ce format pour son propre thème
La génération ne se fait pas à la main : l’outil en ligne de commande WP-CLI, via son extension i18n, produit ce format à partir des fichiers .po existants.
wp i18n make-php languages/ languages/Cette commande parcourt le dossier indiqué, repère les fichiers .po compilés, et génère à côté un fichier .l10n.php équivalent pour chaque locale. Le processus s’intègre naturellement dans une chaîne de build existante, aux côtés de la génération classique des fichiers .mo et .json (ce dernier utilisé pour les traductions côté JavaScript).
Ce que cela change concrètement pour un thème à blocs
Un thème à blocs charge ses traductions PHP de la même façon qu’un thème classique, via load_theme_textdomain(). Rien ne change dans l’appel de cette fonction : c’est en amont, au moment de la génération des fichiers, que le format .l10n.php entre en jeu. Aucune modification du code du thème n’est nécessaire pour en bénéficier, à condition que les fichiers correspondants soient générés et livrés avec le thème.
- Le fichier
.poreste la source de vérité éditable par les traducteurs. - Le fichier
.mocontinue d’être généré, pour la compatibilité avec les sites qui n’ont pas encore mis à jour WordPress vers une version qui reconnaît le nouveau format. - Le fichier
.l10n.phps’ajoute comme une optimisation de chargement, sans remplacer les deux premiers dans la chaîne de production.
Un point de vigilance sur le contenu du fichier généré
Le fichier .l10n.php étant un fichier PHP exécuté directement, il ne doit jamais être modifié à la main : toute chaîne ajoutée manuellement dans ce fichier, plutôt que régénérée depuis le .po source, sera perdue à la prochaine génération et créera un écart silencieux entre les traductions visibles dans le fichier source et celles réellement servies au site.
Sur les projets qui gèrent plusieurs locales, l’habitude qu’on a prise : la génération du
.l10n.phpfait partie du script de build, au même titre que la compilation des styles, jamais une étape manuelle séparée qu’on oublie de relancer.
En résumé
Le format .l10n.php introduit par WordPress 6.5 ne change rien au contenu des traductions d’un thème, seulement à la rapidité avec laquelle elles sont chargées. Il coexiste avec le format .mo historique plutôt que de l’imposer, ce qui en fait une adoption sans risque dès lors que la génération est intégrée à la chaîne de build existante.
