Un fichier en entrée, cinq formats en sortie : comment pérenniser vos traductions WordPress

Vous avez passé trois semaines à traduire votre thème WordPress en espagnol. Le fichier .po est parfait : chaque chaîne de caractères a été vérifiée, chaque variable est intacte, chaque forme plurielle est correcte. Puis votre client décide de migrer d’un thème PHP classique vers une configuration headless avec React en frontend.

Soudain, votre fichier .po est inutile. L’application React a besoin de .json. Les widgets PHP existants ont toujours besoin de .mo. Le freelance qui s’occupe de l’application mobile veut du .xliff. Et personne n’a le temps de retraduire 4 000 chaînes de caractères dans trois formats différents.

Ce n’est pas un cas limite. C’est la réalité du développement WordPress moderne, où les thèmes sont livrés avec des composants PHP et JavaScript, les plugins utilisent un mélange de Gettext et i18next, et les clients changent d’avis sur l’architecture plus souvent qu’ils ne changent leurs mots de passe.

Pourquoi les formats de fichiers de traduction sont plus importants que jamais

Il y a cinq ans, la traduction WordPress était simple. Vous aviez un fichier .po (source lisible par l’homme) et un fichier .mo (binaire compilé). C’était tout. Chaque thème, chaque plugin, chaque outil de traduction parlait la même langue.

Aujourd’hui, l’écosystème WordPress utilise au moins cinq formats de fichiers de traduction en production :

Les cinq formats que vous devez connaître

.po (Portable Object) — Le format source lisible par l’homme utilisé par GNU Gettext. Contient les chaînes de caractères originales (msgid) et leurs traductions (msgstr). C’est ce que les traducteurs modifient.

msgid "Add to Cart"
msgstr "Anadir al carrito"

msgid "Your order has been shipped to %s"
msgstr "Su pedido ha sido enviado a %s"

.mo (Machine Object) — La version binaire compilée d’un fichier .po. WordPress lit les fichiers .mo au moment de l’exécution en utilisant load_textdomain(). Plus rapide que l’analyse syntaxique de .po au moment de l’exécution, mais non modifiable par l’homme.

.json (JavaScript Object Notation) — Utilisé par wp_set_script_translations() pour les traductions basées sur JavaScript dans les blocs Gutenberg, les composants React et les thèmes modernes. WordPress attend une structure JSON spécifique avec des clés locale_data.

{
  "locale_data": {
    "flavor-starter": {
      "Add to Cart": ["Anadir al carrito"],
      "Your order has been shipped to %s": ["Su pedido ha sido enviado a %s"]
    }
  }
}

.php (tableau PHP) — Un format de plus en plus populaire pour les thèmes et les plugins qui utilisent le chargement de traductions de style Laravel. Certains thèmes WordPress modernes contournent complètement Gettext et chargent les traductions à partir de tableaux PHP pour améliorer les performances.

<?php
return [
    'Add to Cart' => 'Anadir al carrito',
    'Your order has been shipped to %s' => 'Su pedido ha sido enviado a %s',
];

.xliff (XML Localization Interchange File Format) — La norme industrielle pour l’échange de traductions entre différents outils et plateformes. Utilisé par les outils de TAO (traduction assistée par ordinateur) tels que memoQ, Trados et Memsource. Essentiel lorsque vous travaillez avec des traducteurs humains professionnels.

<trans-unit id="1">
  <source>Add to Cart</source>
  <target>Anadir al carrito</target>
</trans-unit>

Le problème : l’enfermement dans un format

La plupart des outils de traduction produisent un seul format de sortie. Poedit vous donne .po et .mo. WPML stocke les traductions dans la base de données (pas du tout dans des fichiers). Weglot conserve les traductions sur ses serveurs dans un format propriétaire. Même les plateformes de système de gestion de la traduction (TMS) comme Crowdin et Lokalise vous obligent à configurer manuellement les formats d’exportation pour chaque projet.

Cela crée un enfermement dans un format — vos traductions sont piégées dans le format produit par votre outil actuel. Lorsque vos besoins changent, vous avez deux options :

1. Retraduire tout dans le nouveau format (coûteux, chronophage et vous perdez toute correction manuelle)
2. Écrire des scripts de conversion personnalisés (sujet aux erreurs, en particulier pour les formes plurielles complexes et les variables)

Aucune de ces options n’est bonne. Les deux gaspillent du temps et de l’argent. Les deux introduisent des risques.

Scénarios réels où l’enfermement dans un format est préjudiciable

Scénario 1 : Modernisation du thème. Le thème de votre client est en cours de reconstruction avec des blocs Gutenberg. Les anciens modèles PHP utilisaient des fichiers .mo. Les nouveaux blocs ont besoin de .json pour wp_set_script_translations(). Vos 3 000 chaînes traduites doivent exister dans les deux formats pendant la transition.

Scénario 2 : Flux de travail d’agence. Vous gérez 20 sites clients. Certains utilisent des thèmes classiques (.mo). Certains utilisent des configurations headless (.json). L’un d’eux utilise un framework personnalisé qui lit les tableaux PHP. Vous avez besoin des mêmes traductions dans différents formats pour différents clients.

Scénario 3 : Révision professionnelle. Vos traductions IA sont précises à 95 %, mais vous voulez qu’un locuteur natif examine les 5 % restants. Les traducteurs professionnels utilisent des outils de TAO qui importent des fichiers .xliff. Vous devez exporter vos traductions au format .xliff, les envoyer pour révision et fusionner les corrections.

Scénario 4 : Migration de plateforme. Votre client passe de WordPress à une application Node.js personnalisée. La nouvelle application utilise i18next et a besoin de fichiers .json. Vos 5 000 chaînes traduites au format .po doivent être converties — sans perdre une seule variable ni forme plurielle.

La solution : traduire une fois, obtenir tous les formats

SimplePoTranslate adopte une approche différente. Lorsque vous téléversez un fichier .po, .pot, .json ou .xliff et que vous exécutez une traduction, vous récupérez une archive ZIP contenant les cinq formats :

translations-es_ES.zip
├── flavor-starter-es_ES.po
├── flavor-starter-es_ES.mo
├── flavor-starter-es_ES.json
├── flavor-starter-es_ES.php
└── flavor-starter-es_ES.xliff

Ce n’est pas une « fonctionnalité premium » bloquée derrière un niveau d’entreprise. Chaque plan payant — Pro (19 $/mois) et Lifetime (399 $ en une seule fois) — inclut les cinq formats de sortie dans chaque tâche de traduction.

Pourquoi c’est important pour la pérennisation

Lorsque vous avez les cinq formats dès le départ, vous n’avez jamais besoin de retraduire. Vos traductions sont un atout qui s’adapte à toute exigence technique :

• Le client migre d’un thème classique vers Gutenberg ? Déployez le fichier .json.
• Le nouveau développeur préfère les tableaux PHP ? Donnez-lui le fichier .php.
• Le traducteur professionnel veut faire une révision ? Envoyez le fichier .xliff.
• Vous passez à un autre CMS ? Les fichiers .json et .xliff sont indépendants de la plateforme.

Vous traduisez une fois. Les formats sont prêts lorsque vous en avez besoin.

Comment chaque format fonctionne dans WordPress

Savoir quel fichier va où est essentiel pour un déploiement propre.

Déploiement de fichiers .mo (thèmes et plugins PHP classiques)

wp-content/languages/plugins/woocommerce-es_ES.mo
wp-content/languages/themes/flavor-starter-es_ES.mo

WordPress les charge automatiquement lorsque la langue du site correspond. Aucun plugin requis. Zéro surcharge de la base de données. C’est l’approche qui offre les meilleures performances.

Déploiement de fichiers .json (blocs Gutenberg et composants JS)

wp-content/languages/plugins/woocommerce-es_ES-{handle}-{md5}.json

Le nom de fichier inclut le descripteur de script et un hachage MD5. WordPress les fait correspondre lorsque vous appelez wp_set_script_translations() dans votre plugin ou votre thème. Si vous construisez des blocs Gutenberg, c’est le fichier qui fait apparaître correctement les étiquettes et les descriptions traduites de vos blocs.

Utilisation des fichiers .xliff (flux de travail de révision professionnelle)

Les fichiers .xliff ne sont pas déployés sur WordPress. Ils sont utilisés comme un format d’échange lorsque vous devez envoyer des traductions à un réviseur professionnel ou les importer dans un outil de TAO. Le flux de travail ressemble à ceci :

1. Téléversez le fichier .po vers SimplePoTranslate et obtenez le fichier .xliff dans l’archive ZIP
2. Envoyez le fichier .xliff à votre traducteur ou réviseur
3. Recevez le fichier .xliff corrigé
4. Téléversez le fichier .xliff corrigé vers SimplePoTranslate et obtenez les fichiers .mo et .json mis à jour

Ce flux de travail aller-retour préserve chaque variable et forme plurielle, car le verrouillage de la syntaxe de SimplePoTranslate les protège à chaque étape.

Le test d’enfermement propriétaire

Voici un test simple pour déterminer si votre flux de travail de traduction actuel a un problème d’enfermement :

1. Pouvez-vous exporter vos traductions sous forme de fichiers .po standard dès maintenant ?
2. Si vous annulez votre abonnement à l’outil de traduction aujourd’hui, conservez-vous chaque chaîne traduite ?
3. Pouvez-vous importer vos traductions dans un outil ou une plateforme complètement différent sans retraduire ?

Si la réponse à l’une de ces questions est « non », vous êtes enfermé. Les services comme Weglot et GTranslate échouent aux trois questions — annulez l’abonnement et vos traductions disparaissent. WPML stocke les traductions dans la base de données, ce qui rend l’exportation possible, mais pénible. Même les outils de bureau comme Poedit réussissent le test sur papier, mais vous limitent aux formats .po et .mo uniquement.

Avec SimplePoTranslate, la réponse aux trois questions est « oui ». Vous téléchargez des fichiers standard dans cinq formats. Ils sont à vous. Supprimez votre compte demain et chaque traduction que vous avez faite fonctionnera toujours.

Construction d’une bibliothèque de traduction indépendante du format

Pour les agences et les développeurs qui gèrent plusieurs projets, l’approche la plus intelligente consiste à construire une bibliothèque de traduction — un référentiel Git ou un dossier partagé où vous stockez les fichiers traduits pour chaque projet client.

translations/
├── client-acme/
│   ├── es_ES/
│   │   ├── flavor-starter-es_ES.po
│   │   ├── flavor-starter-es_ES.mo
│   │   ├── flavor-starter-es_ES.json
│   │   ├── flavor-starter-es_ES.php
│   │   └── flavor-starter-es_ES.xliff
│   └── de_DE/
│       └── ...
├── client-globex/
│   └── ...

Lorsqu’un client a besoin d’un nouveau format, vous l’avez déjà. Lorsqu’un client change de plateforme, vos traductions migrent sans effort. Lorsqu’un nouveau développeur rejoint l’équipe, il peut voir exactement ce qui a été traduit et dans quels formats.

C’est ce que signifie réellement « pérenniser » — non pas prédire quelle technologie vos clients utiliseront l’année prochaine, mais s’assurer que vos traductions fonctionnent avec tout ce qu’ils choisissent.

Prêt à ne plus vous soucier des formats de fichiers ? Essayez SimplePoTranslate gratuitement — téléversez un fichier, récupérez cinq formats. Pas de scripts de conversion, pas de retraduction, pas d’enfermement.