Comment compiler les fichiers .po en .mo (4 méthodes)

Vous avez passé un après-midi à perfectionner une traduction allemande. Chaque chaîne de votre fichier de_DE.po se lit parfaitement, les placeholders sont intacts, les pluriels sont corrects. Vous le téléchargez sur votre site, passez la langue en allemand, et... rien. La page est toujours en anglais. Vous vérifiez le nom du fichier, le dossier, le domaine de texte. Tout semble correct. Alors pourquoi WordPress n'affiche-t-il pas votre traduction?

Neuf fois sur dix, la réponse est la même : vous avez modifié le fichier .po mais ne l'avez jamais compilé en .mo. WordPress ne lit pas les fichiers .po à l'exécution — il charge le binaire compilé .mo. Si vous voulez que vos traductions apparaissent réellement, vous devez compiler .po en .mo chaque fois que vous modifiez le texte. Le fichier .po est votre source éditable ; le .mo est ce que le site affiche.

Ce guide explique pourquoi cette étape de compilation existe, puis présente quatre méthodes fiables pour la réaliser : WP-CLI, la commande classique msgfmt, Poedit, et un outil cloud qui produit le fichier .mo automatiquement pour vous. Nous aborderons également le piège le plus courant — oublier de recompiler — et le nouveau format .l10n.php que WordPress préfère désormais pour la vitesse.

Pourquoi WordPress charge-t-il les fichiers .mo et non les .po?

WordPress charge les fichiers .mo parce que ce sont des binaires compilés optimisés pour des recherches rapides, tandis que les fichiers .po sont du texte brut conçu pour être lu et édité par des humains. Analyser du texte à chaque chargement de page serait lent ; lire une table de hachage binaire préconstruite est presque instantané.

Un fichier .po est basé sur des lignes et est convivial pour les humains. Chaque entrée associe un msgid source à un msgstr traduit, ainsi que des commentaires indiquant l'origine de la chaîne. C'est excellent pour l'édition mais terrible pour les performances — le serveur devrait ré-analyser l'intégralité du fichier texte à chaque requête.

#: includes/cart.php:88
msgid "Your cart is empty"
msgstr "Ihr Warenkorb ist leer"

Un fichier .mo regroupe ces mêmes paires de chaînes dans un format binaire avec une table de recherche interne, de sorte que WordPress peut accéder directement à une traduction sans analyser le texte. L'inconvénient est que le .mo est illisible pour les humains et doit être régénéré chaque fois que le .po change. Si la distinction entre .po et .mo est encore floue, notre article explicatif sur les fichiers .po vs .mo vs .pot détaille chaque format et leurs relations.

Quatre façons de compiler .po en .mo

Il n'y a pas d'outil "correct" unique — le meilleur choix dépend de votre façon de travailler actuelle. Ci-dessous, quatre méthodes fiables, d'une commande d'une seule ligne à un workflow cloud entièrement automatisé. Les quatre produisent le fichier binaire .mo identique que WordPress charge à l'exécution.

Méthode 1 : WP-CLI

L'approche moderne la plus propre est WP-CLI, qui peut compiler un dossier entier de fichiers .po en une seule commande. Si vous gérez déjà WordPress en ligne de commande, cela s'intègre naturellement à votre workflow.

# Compile every .po file in the languages folder to .mo
wp i18n make-mo languages/

# Compile into a specific destination directory
wp i18n make-mo languages/ build/languages/

La commande make-mo scanne le répertoire cible, compile chaque fichier .po qu'elle trouve, et écrit un fichier .mo correspondant à côté (ou dans la destination que vous spécifiez). Elle gère les lots avec élégance, ce qui la rend idéale lorsque vous maintenez de nombreuses langues à la fois. C'est l'outil recommandé pour tout projet utilisant déjà WP-CLI.

Méthode 2 : msgfmt

L'utilitaire Gettext original pour cette tâche est msgfmt, qui fait partie du paquet GNU gettext. Il compile un seul fichier .po en un seul fichier .mo et est disponible sur pratiquement tous les systèmes Linux et macOS.

# Compile one file
msgfmt my-plugin-de_DE.po -o my-plugin-de_DE.mo

# Add statistics about translated, fuzzy, and untranslated strings
msgfmt --statistics my-plugin-de_DE.po -o my-plugin-de_DE.mo

# Install it first if missing
#   macOS:  brew install gettext
#   Debian: sudo apt-get install gettext

Le drapeau -o nomme le fichier de sortie. Le drapeau --statistics est vraiment utile — il vous indique combien de chaînes sont traduites, floues ou encore vides, ce qui vous permet de détecter une traduction incomplète avant de la livrer. Pour scripter un fichier à la fois, msgfmt est le choix fiable et sans fioritures.

Parce que msgfmt est un simple outil en ligne de commande, il s'intègre parfaitement à l'automatisation. Vous pouvez l'envelopper dans une boucle shell pour compiler un dossier entier, ou l'intégrer à un pipeline CI afin que chaque commit qui touche un fichier .po produise automatiquement un nouveau fichier .mo. Un modèle courant est for f in languages/*.po; do msgfmt "$f" -o "${f%.po}.mo"; done, qui compile toutes les langues en un seul passage. Le drapeau --check ajoute une validation, signalant les incohérences de format entre msgid et msgstr avant qu'elles n'atteignent la production — une protection peu coûteuse contre les bugs de placeholders cassés qui corrompent silencieusement les mises en page traduites.

Méthode 3 : Poedit (compile à l'enregistrement)

Si vous modifiez des traductions dans un éditeur graphique, Poedit compile pour vous automatiquement. Chaque fois que vous enregistrez un fichier .po, Poedit écrit le fichier .mo correspondant juste à côté — pas de commande séparée, pas d'étape supplémentaire.

C'est l'une des raisons pour lesquelles Poedit reste populaire auprès des traducteurs qui ne sont pas à l'aise avec la ligne de commande. Vous ouvrez le .po, tapez vos traductions, appuyez sur enregistrer, et les deux fichiers se mettent à jour ensemble. Vous pouvez confirmer ce comportement dans les préférences de Poedit, où la compilation automatique des fichiers .mo à l'enregistrement est activée par défaut. Poedit et les outils de bureau similaires sont examinés dans les 5 meilleurs outils gratuits pour éditer et traduire des fichiers PO sur Mac et Windows.

L'inconvénient d'un éditeur de bureau est que la compilation n'a lieu que lorsqu'un humain ouvre le fichier et l'enregistre. C'est bien pour un projet individuel, mais cela ne s'adapte pas à une douzaine de langues ou à une équipe qui échange des fichiers. Si quelqu'un modifie un fichier .po dans un outil différent et le copie dans le dépôt sans ouvrir Poedit, le fichier .mo ne se met jamais à jour. Pour les projets plus importants ou collaboratifs, une méthode automatisée — ligne de commande ou cloud — supprime cette dépendance au fait de se souvenir d'appuyer sur enregistrer.

Méthode 4 : Un outil cloud qui génère le fichier .mo pour vous

La quatrième option supprime entièrement l'étape de compilation : utilisez un service cloud qui renvoie le fichier .mo compilé avec le fichier .po traduit. Vous n'exécutez jamais de commande ni n'enregistrez un fichier deux fois — vous téléchargez, et des fichiers terminés, correctement nommés, vous sont renvoyés.

SimplePoTranslate fonctionne exactement de cette manière. Vous téléchargez un fichier .po ou .pot, il traduit les chaînes avec une IA sensible au contexte, et il renvoie un seul ZIP contenant les fichiers .po et .mo générés côte à côte — déjà compilés, déjà nommés pour correspondre à votre domaine de texte et à votre locale. Il n'y a pas de passe de compilation séparée et aucune chance d'en oublier une.

Il gère également les détails qui perturbent les workflows manuels. Le Verrouillage de syntaxe gèle les placeholders comme %s, %1$s et {name} ainsi que les balises HTML avant la traduction, de sorte que vos variables survivent intactes dans le fichier .mo. Le support complet des pluriels Gettext signifie que les formes plurielles complexes se compilent également correctement — un sujet qu'il vaut la peine de comprendre en profondeur, et que nous couvrons dans comprendre les pluriels Gettext. Et parce qu'il fonctionne dans le cloud, il n'y a aucun plugin à installer ni d'outils de build à maintenir.

Le piège le plus courant : vous avez oublié de recompiler

La principale raison pour laquelle les traductions n'apparaissent pas est la modification du fichier .po sans recompiler le fichier .mo. WordPress continue de charger l'ancien binaire, donc votre nouvelle formulation n'apparaît jamais — et il n'y a aucun message d'erreur pour vous dire pourquoi.

Le modèle mental à retenir : le fichier .po est votre brouillon, le fichier .mo est ce qui est livré. Toute modification du fichier .po est invisible pour WordPress jusqu'à ce que vous régénériez le fichier .mo. Faites de la recompilation un réflexe après chaque modification, ou utilisez un outil qui compile automatiquement afin que l'étape ne puisse jamais être ignorée.

Ce piège est particulièrement insidieux lors des transferts de la pré-production à la production. Un développeur modifie et recompile localement, voit la traduction fonctionner, puis déploie uniquement le fichier .po et oublie le fichier .mo — ainsi la production conserve silencieusement l'ancien texte. Chaque fois que vous déplacez des fichiers de traduction entre les environnements, déplacez le fichier .po et le fichier .mo fraîchement compilé ensemble, ou compilez dans le cadre de votre étape de déploiement afin que le binaire soit toujours reconstruit à partir de la source actuelle.

Si vos traductions refusent toujours d'apparaître après la recompilation, le problème est généralement une incompatibilité de nom, un dossier incorrect, ou une couche de cache qui retient l'ancien fichier. La liste de contrôle complète se trouve dans pourquoi vos traductions n'apparaissent pas dans WordPress.

Une note sur le nouveau format .l10n.php

Les versions récentes de WordPress ont introduit un troisième format d'exécution : .l10n.php. Au lieu d'un binaire .mo, les traductions sont stockées sous forme d'un simple tableau PHP que le cache d'opcode PHP peut conserver en mémoire, rendant les recherches encore plus rapides que les fichiers .mo sur les sites très fréquentés.

<?php
return [
	'domain'  => 'my-plugin',
	'messages' => [ 'Your cart is empty' => 'Ihr Warenkorb ist leer' ],
];

WordPress génère automatiquement les fichiers .l10n.php lorsqu'il dispose du fichier .mo correspondant, vous n'avez donc pas besoin de les construire manuellement. Pour l'instant, la compilation d'un fichier .mo correct reste la base — le format de performance en est dérivé.

En résumé

Pour compiler .po en .mo de manière fiable, choisissez la méthode qui correspond à votre façon de travailler : WP-CLI pour les lots en ligne de commande, msgfmt pour les fichiers uniques avec statistiques, Poedit pour la compilation automatique à l'enregistrement, ou un outil cloud qui génère le fichier .mo pour vous afin que l'étape ne soit jamais oubliée. Les quatre produisent le même binaire dont WordPress a besoin à l'exécution.

Quelle que soit la méthode que vous choisissez, rappelez-vous la règle d'or : modifiez le fichier .po, puis compilez-le en .mo — à chaque fois. Cette simple habitude prévient le bug de traduction le plus frustrant dans WordPress, celui où tout semble correct mais le site reste obstinément en anglais.

Prêt à sauter l'étape de compilation manuelle pour de bon ? Essayez SimplePoTranslate gratuitement — aucune carte de crédit requise. Téléchargez votre fichier .po et obtenez un pack .po + .mo prêt à être déployé sur le niveau gratuit en quelques minutes.