« Make WordPress Core » décrit ainsi le rôle du fichier .pot dans sa documentation d’internationalisation : un gabarit qui recense toutes les chaînes traduisibles d’un projet, destiné à être dupliqué par langue puis rempli. Sur un projet livré une fois par trimestre, extraire ce fichier à la main et l’envoyer au traducteur ne pose aucun problème. Sur une équipe qui livre chaque semaine, ce geste manuel devient vite le goulot d’étranglement de tout le cycle de traduction.
L’enjeu n’est pas de traduire plus vite, mais de ne traduire qu’une seule fois chaque chaîne, même quand le code évolue en continu. Voici l’architecture retenue pour automatiser ce cycle extraction → traduction → réintégration, sans jamais reproduire un travail déjà fait.
Étape 1 : extraction automatique à chaque build
La commande wp i18n make-pot régénère le fichier .pot à partir du code source, en scannant les appels à __(), _e(), _x() et consorts. Cette étape est intégrée à la pipeline de build, déclenchée à chaque fusion sur la branche principale :
wp i18n make-pot ./wp-content/themes/mon-theme ./languages/mon-theme.pot \
--domain=mon-theme \
--exclude=node_modules,vendorLe fichier .pot généré ne contient jamais de traduction : c’est un gabarit vierge, une liste de chaînes source avec leur emplacement dans le code. C’est la comparaison avec la version précédente qui permet d’isoler ce qui a réellement changé.
Étape 2 : isoler les nouveautés, pas tout retraduire
Un script maison compare le .pot fraîchement généré avec celui de la livraison précédente, conservé en artefact de build, et produit la liste des chaînes ajoutées, modifiées ou supprimées :
#!/bin/bash
msgcmp --use-fuzzy languages/mon-theme.pot languages/mon-theme.pot.previous \
2>&1 | grep -c "this message is used but not defined"
diff <(grep '^msgid' languages/mon-theme.pot.previous) \
<(grep '^msgid' languages/mon-theme.pot) > nouvelles-chaines.diffCette liste de différences, plutôt que le fichier complet, part vers le service de traduction. Sur un projet mature où l’essentiel des chaînes existe déjà, cette réduction change complètement l’échelle du travail à chaque livraison — de plusieurs centaines de chaînes à quelques dizaines dans le cas courant.
Étape 3 : réintégration dans les fichiers .po existants
Une fois les nouvelles chaînes traduites (par un service externe ou une équipe de traducteurs internes), elles sont fusionnées dans les fichiers .po par langue via msgmerge, qui préserve les traductions déjà validées et ajoute uniquement les nouvelles entrées :
msgmerge --update --backup=off \
languages/mon-theme-de_DE.po \
languages/mon-theme.potCette commande marque automatiquement en « fuzzy » toute chaîne dont le texte source a légèrement changé depuis la dernière traduction, ce qui permet à un traducteur de repérer immédiatement les entrées à revalider plutôt que de tout reparcourir.
Étape 4 : compilation .mo, jamais manuelle
La dernière étape, souvent oubliée dans les processus manuels, consiste à recompiler les fichiers .mo binaires à partir des .po mis à jour :
wp i18n make-mo ./languagesSans cette étape automatisée, il arrive régulièrement qu’un traducteur livre un fichier .po à jour, sans que personne ne pense à régénérer le .mo correspondant — et le site continue d’afficher les anciennes traductions pendant des semaines, un décalage silencieux qui ne se voit qu’en testant activement chaque langue.
Arborescence du pipeline complet
.github/workflows/i18n.yml
└─ déclenché sur merge vers main
├─ wp i18n make-pot (extraction)
├─ comparaison avec .pot.previous (diff)
├─ notification service de traduction (webhook)
├─ msgmerge sur retour de traduction (fusion)
└─ wp i18n make-mo (compilation finale)Ce qui reste manuel, volontairement
- La validation humaine de chaque nouvelle traduction avant fusion en production
- La revue des chaînes marquées « fuzzy » après un changement de texte source
- La décision de publier une traduction partielle ou d’attendre le lot complet
Automatiser l’extraction et la réintégration ne signifie pas supprimer la relecture humaine : cela libère simplement le temps qui partait auparavant dans des tâches mécaniques répétitives, pour le réinvestir dans la qualité de la traduction elle-même.
Le fichier
.potn’est jamais la source de vérité des traductions : il n’est que le miroir du code à un instant donné. C’est la comparaison entre deux miroirs qui indique où porter l’effort.
En résumé
Une chaîne de traduction continue ne demande pas d’outil exotique : wp i18n make-pot, msgmerge et wp i18n make-mo suffisent à couvrir tout le cycle, à condition de les enchaîner automatiquement à chaque livraison plutôt que de les déclencher à la main. Le gain ne se mesure pas seulement en temps gagné, mais en fiabilité : plus aucune chaîne traduite n’est oubliée entre deux mises en production.
