D’après les notes de version officielles de WordPress 6.5, publiée en avril 2024, le cœur introduit un nouveau format de fichier de traduction, .l10n.php, conçu pour réduire le temps de chargement des chaînes traduites par rapport au format historique .mo. Contrairement à un fichier .mo, qui doit être analysé au moment du chargement, un fichier .l10n.php retourne directement un tableau PHP natif, ce qui évite l’étape de parsing binaire.
Cette évolution technique, plutôt discrète dans la communication autour de cette version, change néanmoins un paramètre important pour tout projet qui accepte des fichiers de traduction fournis par des contributeurs externes : un fichier .l10n.php est un fichier PHP exécutable au sens propre, ce qui change la nature du risque par rapport à un fichier .mo binaire.
Comment fonctionne le nouveau format
Un fichier .l10n.php retourne simplement un tableau PHP représentant les chaînes traduites et leurs métadonnées, dans une structure documentée sur developer.wordpress.org. La fonction load_textdomain(), déjà utilisée pour le format .mo, détecte automatiquement l’extension du fichier fourni et choisit le mécanisme de chargement approprié — aucun changement de code n’est nécessaire côté extensions ou thèmes pour bénéficier du nouveau format.
Pourquoi la provenance compte davantage qu’avec un .mo
Un fichier .mo corrompu ou malveillant reste, dans le pire des cas, mal interprété par le parseur binaire de WordPress, ce qui peut provoquer une erreur ou un comportement inattendu, mais reste borné par la logique du parseur lui-même. Un fichier .l10n.php, en revanche, est chargé via un mécanisme PHP natif : s’il provient d’une source non fiable et qu’il est chargé sans validation de son contenu réel, rien n’empêche techniquement qu’il contienne autre chose qu’un simple tableau de traductions.
Ce risque reste théorique tant que le fichier provient exclusivement d’un processus de compilation automatisé et fiable — ce que WordPress fait lui-même en interne — mais il devient concret dès qu’un projet accepte des fichiers .l10n.php fournis directement par des contributeurs externes sans repasser par une génération contrôlée.
Ce qu’il faut vérifier avant d’accepter un fichier .l10n.php externe
- Ne jamais accepter un fichier
.l10n.phpfourni directement par un contributeur externe sans le régénérer soi-même à partir d’un fichier.posource - Utiliser l’outil officiel de conversion plutôt qu’un fichier
.l10n.phptransmis tel quel - Stocker les fichiers de traduction hors d’un répertoire accessible en écriture par un rôle non fiable
Générer soi-même le fichier plutôt que de l’accepter tel quel
La pratique la plus sûre, pour un projet qui reçoit des traductions de contributeurs externes au format .po, consiste à conserver ce format comme seul format accepté en entrée, puis à générer le .mo et le .l10n.php correspondants via l’outillage WP-CLI officiel, plutôt que d’accepter un fichier .l10n.php déjà compilé venant de l’extérieur :
wp i18n make-mo chemin/vers/traductions/
wp i18n make-php chemin/vers/traductions/
Cette approche garantit que le fichier .l10n.php effectivement chargé par le site a toujours été produit par un outil de confiance, à partir d’un fichier .po lui-même relu, plutôt que reçu directement sous une forme déjà exécutable.
Coexistence des deux formats
Le format .mo reste pleinement pris en charge après l’introduction de .l10n.php : aucune extension ni aucun thème n’est obligé de migrer, et WordPress choisit automatiquement le format disponible le plus performant si les deux existent pour une même langue. Un projet qui ne génère jamais de fichier .l10n.php continue de fonctionner exactement comme avant l’introduction de ce format.
Un format plus rapide à charger n’est utile que si la confiance accordée à son contenu reste au moins aussi rigoureuse que pour l’ancien format qu’il complète.
En résumé
Le format .l10n.php introduit par WordPress 6.5 apporte un gain de performance réel au chargement des traductions, sans rien changer côté code pour la majorité des projets. La vigilance à maintenir concerne exclusivement les projets qui acceptent des fichiers de traduction de sources externes : dans ce cas, régénérer systématiquement le fichier .l10n.php via l’outillage officiel, à partir d’un .po relu, reste la seule pratique qui évite d’introduire un fichier PHP exécutable non maîtrisé dans le projet.
