add_filter( 'gettext', 'corriger_ma_chaine', 10, 3 ); — cette seule ligne suffit à intercepter n’importe quelle chaîne traduite affichée par WordPress, y compris celles produites par une extension tierce dont le code source reste totalement intouché. C’est la solution la plus rapide face à une traduction maladroite, incohérente avec le vocabulaire du site, ou tout simplement fausse, sans passer par la case fichier de traduction.
Ce filtre existe depuis longtemps dans le cœur de WordPress, mais reste largement sous-utilisé, souvent parce que les développeurs pensent à tort qu’il faut nécessairement modifier un fichier .po pour corriger une chaîne, quitte à devoir maintenir un fork de plugin pour un simple mot mal choisi.
Le problème typique : une chaîne qu’on ne peut pas éditer proprement
Imaginons une extension de formulaire de contact qui affiche « Envoyer le message » sur son bouton de soumission, alors que la charte éditoriale du site impose « Envoyer ma demande ». Éditer directement le fichier .po de l’extension fonctionne, jusqu’à la prochaine mise à jour du plugin, qui écrase purement et simplement ce fichier avec la version d’origine, faisant disparaître la correction sans prévenir personne.
Une extension de traduction visuelle complète peut résoudre ce cas, mais representerait un outil disproportionné pour corriger une seule chaîne. Le filtre gettext, lui, s’installe dans le thème actif ou une extension maison, survit à toutes les mises à jour du plugin ciblé, et ne touche à aucun fichier appartenant à ce plugin.
Comment le filtre fonctionne réellement
Chaque fois que WordPress traduit une chaîne via __(), _e() ou leurs variantes, le résultat passe par le filtre gettext avant d’être renvoyé au code appelant. Ce filtre reçoit trois arguments : la traduction déjà appliquée, la chaîne source originale en anglais, et le domaine de texte du plugin ou thème d’origine.
add_filter( 'gettext', 'wpm_corriger_bouton_contact', 10, 3 );
function wpm_corriger_bouton_contact( $traduction, $source, $domaine ) {
if ( 'mon-plugin-contact' === $domaine
&& 'Envoyer le message' === $traduction ) {
return 'Envoyer ma demande';
}
return $traduction;
}
La condition sur le domaine de texte n’est pas optionnelle : sans elle, le filtre s’appliquerait à toutes les chaînes du site portant exactement le même texte, y compris celles venant d’autres extensions ou du thème, ce qui pourrait provoquer des corrections indésirables ailleurs.
Variante utile : cibler un pluriel avec ngettext
Pour les chaînes construites avec _n(), un filtre frère existe, nommé ngettext, qui reçoit un argument supplémentaire pour le nombre évalué. Il s’utilise exactement de la même manière, avec la même logique de vérification du domaine de texte avant toute substitution.
gettextpour les chaînes simples issues de__()et_e().ngettextpour les chaînes au pluriel issues de_n().gettext_with_contextpour les chaînes désambiguïsées avec_x().
Précautions avant de généraliser cette approche
Ce filtre reste un outil de correction ponctuelle, pas une méthode de traduction complète d’un plugin entier. Multiplier les conditions dans une même fonction pour corriger dix ou vingt chaînes différentes finit par produire un code difficile à maintenir, où chaque mise à jour du plugin ciblé impose de revérifier que les chaînes sources n’ont pas changé entre-temps.
Un repère simple pour savoir quand s’arrêter : au-delà de trois ou quatre corrections sur un même plugin, il devient plus raisonnable de fournir un vrai fichier de traduction complémentaire plutôt que d’empiler les conditions dans un filtre.
En résumé
Le filtre gettext offre une solution chirurgicale à un problème très courant : corriger une chaîne gênante sans dépendre d’un fichier de traduction fragile, écrasé à chaque mise à jour de l’extension d’origine. Utilisé avec parcimonie, en vérifiant toujours le domaine de texte concerné, il évite bien des forks de plugins pour un simple mot mal choisi dans une interface qu’on ne maîtrise pas entièrement.
