JSON aurait pu remplacer .po depuis longtemps. Ce format texte, plus lisible pour un humain non habitué au vocabulaire gettext, plus simple à parser dans n’importe quel langage moderne, coche presque toutes les cases qu’on attendrait d’un format de traduction pensé pour 2020. Et pourtant, un thème ou une extension WordPress continue de livrer ses traductions sous forme de fichiers .po et .mo, un couple de formats hérité tel quel du monde GNU des années 1990.
Ce choix n’a rien d’un oubli ni d’un simple conservatisme technique. Il s’explique par une combinaison de contraintes de performance, de compatibilité et d’écosystème, qui rend le coût d’un changement de format bien supérieur au bénéfice qu’on pourrait en attendre.
Ce que .mo apporte encore aujourd’hui
Le fichier .mo n’est pas un simple fichier texte compressé : c’est un format binaire structuré comme une table de correspondance, indexée pour permettre une recherche très rapide d’une chaîne traduite à partir de sa version source. À l’exécution, PHP n’a pas besoin de parser un document entier ni d’interpréter une syntaxe complexe : il consulte directement l’index binaire pour retrouver la traduction demandée.
Un format texte comme JSON, bien que plus agréable à lire pour un humain, impose un coût de traitement supplémentaire à chaque chargement : parsing complet du document, construction d’une structure en mémoire, avant de pouvoir chercher la moindre chaîne. Sur un site à fort trafic, où chaque requête PHP recharge potentiellement les traductions, cette différence de performance n’est pas négligeable.
Le poids de la compatibilité avec l’existant
Des dizaines de milliers de thèmes et d’extensions publiés depuis des années s’appuient sur les fonctions __(), _e() et leurs équivalentes, elles-mêmes construites sur l’hypothèse que des fichiers .mo existent quelque part dans un dossier languages/. Changer le format central de traduction du cœur reviendrait à casser, du jour au lendemain, la compatibilité de tout cet écosystème, pour un gain qui resterait largement cosmétique du point de vue du visiteur final.
Ce genre de décision, bien connue des mainteneurs de projets open source anciens, illustre un principe simple : la valeur d’un format standard ne tient pas seulement à ses qualités techniques intrinsèques, mais aussi à la taille de l’écosystème qui en dépend déjà. Plus cet écosystème est large, plus le coût d’un changement de format grandit avec le temps, au lieu de diminuer.
Les alternatives existent, mais en complément
WordPress n’a jamais fermé la porte à des formats additionnels : les fichiers JSON de traduction des scripts JavaScript des blocs en sont un exemple concret, chargés via wp_set_script_translations() aux côtés des fichiers .mo classiques, pas à leur place. Cette coexistence permet d’ajouter de nouveaux usages, comme la traduction côté client dans l’éditeur de blocs, sans jamais renier le mécanisme central qui gère les chaînes PHP.
| Format | Usage principal | Lecture par un humain |
|---|---|---|
| .po | Édition des traductions par un traducteur | Facile |
| .mo | Chargement rapide en exécution PHP | Illisible, binaire |
| .json | Traductions des scripts JavaScript côté éditeur | Facile |
Ce qu’un développeur doit en retenir concrètement
Comprendre cette architecture évite une confusion fréquente chez les développeurs qui découvrent le sujet : penser qu’il faudrait choisir entre .po/.mo et un format plus moderne. Dans la pratique, chaque format occupe une niche précise dans la chaîne de traduction, du fichier source lisible et modifiable jusqu’au fichier binaire consommé à l’exécution, en passant par des formats annexes pour des besoins spécifiques comme le JavaScript des blocs.
- Éditer les traductions : toujours via le fichier .po, jamais directement le .mo.
- Vérifier qu’un fichier .mo à jour existe bien après chaque modification du .po correspondant.
- Ne pas chercher à remplacer .mo par un format personnalisé : aucune fonction cœur ne saurait le lire.
Un conseil qui évite bien des soucis en production : ne jamais versionner uniquement le fichier .po d’un projet en oubliant de recompiler et de livrer le .mo correspondant, sous peine de traductions figées à l’ancienne version.
Pour aller plus loin
Le couple .po/.mo n’a rien d’un choix dépassé qu’il faudrait moderniser à tout prix : c’est un compromis mûri sur plusieurs décennies entre lisibilité pour les traducteurs et performance pour les serveurs. Tant que ce compromis reste pertinent, et il l’est toujours pour l’immense majorité des sites, il n’y a aucune urgence technique à en changer, seulement des raisons ponctuelles d’ajouter des formats complémentaires pour des besoins qui n’existaient pas à l’origine du projet.
