Traduire une extension WordPress ne se limite pas à remplacer quelques mots anglais par du français. Il faut comprendre ce qui relève du code, des fichiers de langue et de l’interface d’administration, puis choisir la bonne méthode selon que l’on traduit un plugin installé ou que l’on prépare sa propre extension. Je vais aller au concret: formats de fichiers, outils utiles, étapes de travail et pièges qui font perdre du temps.
Les points essentiels à garder en tête avant de commencer
- Une extension n’est traduisible proprement que si ses chaînes ont été prévues pour l’i18n, avec un text domain cohérent.
- Les formats à connaître sont POT, PO, MO et, pour le JavaScript, JSON.
- Loco Translate est le plus simple pour une traduction rapide depuis l’admin, Poedit reste très solide pour un travail local plus propre, et WP-CLI est le meilleur choix pour automatiser.
- Pour un plugin installé, il faut stocker les traductions dans un emplacement qui survivra aux mises à jour.
- Pour une extension que vous développez, la qualité de la traduction se joue dès l’écriture des chaînes.
Ce qu’on traduit vraiment dans une extension WordPress
Quand je parle de traduction d’un plugin WordPress, je distingue toujours deux niveaux. L’internationalisation prépare le code pour qu’il soit traduisible, tandis que la localisation correspond au travail de traduction lui-même. Si le plugin n’a pas été internationalisé correctement, certaines phrases resteront figées dans une langue source, même avec le meilleur outil du monde.En pratique, WordPress s’appuie sur des chaînes marquées dans le code avec des fonctions comme __(), _x(), _n() ou _nx(). Ces chaînes alimentent ensuite des fichiers de langue. Pour un plugin classique, je retrouve généralement quatre formats utiles:
| Format | Rôle | Quand il sert vraiment |
|---|---|---|
.pot |
Modèle de traduction qui contient les chaînes source | Point de départ pour les traducteurs ou les outils |
.po |
Fichier éditable avec les traductions humaines | Travail de traduction, relecture et correction |
.mo |
Version compilée lue par WordPress | Chargement effectif des traductions sur le site |
.json |
Traductions côté JavaScript | Blocs Gutenberg, interfaces React et scripts modernes |
Le point que beaucoup ratent, c’est le JavaScript. Une extension peut être parfaitement traduisible en PHP et rester à moitié en anglais dans l’éditeur de blocs ou dans ses écrans dynamiques. Je vérifie donc toujours les deux couches. Une fois cette base claire, le choix de l’outil devient beaucoup plus simple.
Choisir l’outil qui colle à votre cas
Je ne recommande pas le même outil à un site manager, à un traducteur freelance et à un développeur. Le bon choix dépend surtout de votre niveau de contrôle, du volume de chaînes à traiter et du fait que vous vouliez travailler dans WordPress ou en dehors.
| Outil | Le plus adapté pour | Points forts | Limites |
|---|---|---|---|
| Loco Translate | Traduire rapidement une extension depuis l’admin WordPress | Édition dans le navigateur, prise en charge des fichiers de langue, intégration pratique pour un usage quotidien | Moins confortable pour des workflows lourds, techniques ou en équipe |
| Poedit | Travailler proprement sur des fichiers .po/.pot
|
Interface claire, détection des chaînes, validation des placeholders et des pluriels, travail local ou distant | Application séparée à gérer, certaines fonctions avancées sont plus utiles en contexte pro |
| WP-CLI | Automatiser la génération et la mise à jour des fichiers |
make-pot, update-po, make-mo, make-json, idéal pour CI et maintenance |
Demande d’être à l’aise avec la ligne de commande |
| translate.wordpress.org | Participer à la traduction d’un plugin du répertoire WordPress.org | Flux communautaire, language packs, cohérence avec l’écosystème WordPress | Peu adapté aux plugins privés ou à un besoin ponctuel hors écosystème public |
Si je dois résumer en une ligne: Loco Translate est pratique pour aller vite, Poedit pour garder un vrai contrôle éditorial, et WP-CLI pour industrialiser le process. Pour un plugin distribué publiquement, l’écosystème WordPress.org devient souvent la voie la plus propre. Ensuite, la vraie question n’est plus l’outil, mais le workflow.
Traduire une extension déjà installée sans perdre ses fichiers
Pour un plugin déjà présent sur un site, je pars presque toujours de la même logique: vérifier qu’il est bien traduisible, identifier son text domain, puis sauvegarder les fichiers de langue dans un emplacement persistant. C’est ce point qui fait la différence entre une traduction durable et une traduction effacée à la prochaine mise à jour.
- Je contrôle d’abord si l’extension expose réellement ses chaînes. Si tout est figé en dur dans le code, la traduction sera incomplète.
- Je repère ensuite le nom du domaine de texte et la langue cible, par exemple
fr_FRpour un site français. - J’ouvre les chaînes dans Loco Translate ou Poedit, puis je traduis en priorité les libellés visibles par l’utilisateur, les messages d’erreur et les boutons.
- Je m’assure que les fichiers finissent dans un emplacement sûr, par exemple le dossier de langues de WordPress ou un dossier custom protégé des mises à jour.
- Je teste toujours la traduction dans le contexte réel: page de réglages, formulaire, panier, messages d’alerte, e-mails si besoin.
Ce que j’évite, en revanche, c’est de modifier directement les fichiers du plugin dans son dossier d’origine. C’est tentant, mais fragile. Dès qu’une mise à jour tombe, le travail saute. Les emplacements de langue gérés par WordPress ou un dossier de sauvegarde dédié évitent ce genre de mauvaise surprise.
Sur un plugin déjà publié dans le répertoire officiel, WordPress récupère aussi les traductions via son mécanisme de language packs, ce qui simplifie beaucoup la maintenance. Pour un plugin premium, privé ou personnalisé, je préfère être encore plus strict sur le stockage et la validation des fichiers. Une fois cette mécanique en place, on peut se concentrer sur la qualité des chaînes elles-mêmes.
Préparer une extension pour qu’elle soit traduisible dès le départ
Si vous développez le plugin, c’est là que tout se joue. Je considère qu’une extension n’est vraiment prête pour plusieurs langues que si le code est pensé pour la traduction dès la première version. Corriger ça après coup coûte toujours plus cher.
Dans le PHP
Je rends chaque chaîne visible à l’utilisateur traduisible avec les fonctions adaptées. Les cas simples passent par __() ou _e(), les cas ambigus par _x(), et les formes singulier/pluriel par _n() ou _nx(). Quand une phrase contient des variables, j’utilise des placeholders et des commentaires pour le traducteur afin d’éviter les contresens.
Le text domain doit rester cohérent avec le slug du plugin, sinon WordPress risque de ne pas associer correctement les fichiers de langue. J’ajoute aussi le champ Domain Path dans l’en-tête du plugin quand c’est utile. Pour générer les fichiers de départ, wp i18n make-pot reste l’option la plus fiable dans un workflow moderne.
Lire aussi : Meilleurs plugins WordPress - La liste essentielle 2026
Dans le JavaScript
Pour les blocs et les interfaces modernes, je ne me contente jamais du PHP. Je charge wp-i18n, j’utilise les fonctions de @wordpress/i18n et je vérifie que les chaînes sont bien extraites vers les fichiers de traduction côté client. C’est indispensable dès qu’un plugin repose sur Gutenberg, des composants React ou des écrans dynamiques.
Dans ce cas, les JSON générés servent à faire le pont entre le code JS et les traductions finales. Si le build est mal configuré, on se retrouve avec une moitié de l’interface traduite et une autre moitié bloquée en anglais. C’est précisément le genre de détail que je vérifie avant toute mise en production.
Un dernier point pratique: si votre plugin doit vivre longtemps, pensez au versioning des chaînes. Dès qu’un texte change dans le code, le fichier POT doit suivre, sinon les traducteurs se retrouvent à travailler sur une base obsolète. Cette discipline évite beaucoup d’allers-retours inutiles.
Les erreurs qui sabotent la qualité d’une traduction
Les problèmes que je rencontre le plus souvent ne viennent pas de la langue elle-même, mais de la structure du plugin. Une bonne traduction peut être ruinée par un détail technique mal géré. Voici les erreurs qui reviennent le plus.
- Chaînes codées en dur dans le HTML ou le PHP, donc impossibles à extraire proprement.
- Text domain incorrect ou différent du slug du plugin, ce qui casse l’association avec les fichiers de langue.
- Absence de contexte pour des mots ambigus comme “Save”, “Order” ou “Archive”.
- Placeholders mal utilisés qui cassent la syntaxe ou forcent une traduction bancale.
- Pluriels ignorés, alors que le français impose souvent une structure différente de l’anglais.
- Traduction uniquement du PHP alors que le plugin affiche aussi des chaînes en JavaScript.
- Fichiers stockés dans le dossier du plugin, donc écrasés à la prochaine mise à jour.
- Confiance aveugle dans la machine sans relecture humaine sur les écrans critiques.
Je suis particulièrement vigilant sur les messages d’erreur, les écrans de paiement et les confirmations d’action. Ce sont les endroits où une mauvaise traduction peut créer de la confusion, voire faire perdre un client. Les automatismes aident, mais ils ne remplacent pas la relecture contextuelle.
Quand une traduction vient d’une contribution communautaire ou d’un service automatique, je vérifie aussi qu’elle n’a rien d’incohérent ou de suspect. Ce n’est pas de la paranoïa, c’est simplement de l’hygiène éditoriale. Une fois ces pièges écartés, on peut mettre en place un flux de travail stable.
Le flux de travail que je recommande pour garder un plugin multilingue propre
Si je devais choisir une méthode simple et robuste, je ferais la séparation suivante. Pour un site unique, je partirais sur Loco Translate et un emplacement de sauvegarde sûr. Pour une activité plus sérieuse ou répétée, j’utiliserais Poedit avec un glossaire de termes, puis WP-CLI pour générer et mettre à jour les fichiers. Pour un plugin distribué à grande échelle, j’intégrerais la traduction au cycle de livraison dès le début.
- Pour un site géré au quotidien : traduction rapide, sauvegarde hors du dossier du plugin, test en fr_FR.
- Pour un freelance ou une agence : Poedit, glossaire partagé, relecture systématique des placeholders et des pluriels.
- Pour un développeur : chaînes i18n dès la première version, POT généré automatiquement, vérification des JSON pour le JavaScript.
- Pour un plugin public : publication propre sur WordPress.org et suivi des language packs plutôt qu’une maintenance manuelle dispersée.
Le vrai gain de temps ne vient pas de l’outil le plus rapide, mais du workflow le plus clair. Si la structure est propre, la traduction reste légère; si la structure est bancale, chaque langue supplémentaire devient une dette. C’est pour ça que je préfère penser la traduction comme une partie du produit, pas comme une correction de dernière minute.
