Sur un même site cohabitent souvent des dizaines d’extensions, chacune avec ses propres textes à traduire. Sans étiquette distinctive, WordPress ne saurait pas quel fichier de traduction correspond à quelle chaîne : c’est ce que règle cet identifiant, généralement identique au dossier de l’extension.
Où il apparaît
Le domaine de traduction est déclaré une première fois dans l’en-tête de l’extension, puis répété comme second argument dans chaque appel aux fonctions de traduction :
/**
* Plugin Name: Mon Extension
* Text Domain: mon-extension
*/
echo esc_html__( 'Réglages enregistrés.', 'mon-extension' );Ce second argument doit être une chaîne littérale et non une variable, car les outils d’extraction des chaînes (comme WP-CLI i18n) analysent le code source sans l’exécuter et ne peuvent pas résoudre une variable.
Pièges fréquents
- Le domaine doit correspondre exactement au nom du dossier de l’extension telle qu’elle est publiée, sous peine que les fichiers de traduction ne soient jamais chargés une fois l’extension distribuée sur le répertoire officiel.
- Depuis WordPress 4.6, il n’est en général plus nécessaire d’appeler soi-même
load_plugin_textdomain()pour une extension hébergée sur le répertoire officiel : le chargement se fait automatiquement. - Un thème utilise le même principe, mais avec la fonction
load_theme_textdomain()et un domaine qui correspond alors au nom de son dossier plutôt qu’à celui d’une extension. - Un domaine de traduction trop générique, réutilisé par erreur entre plusieurs projets d’un même auteur, peut provoquer des traductions incohérentes lorsque les deux projets sont actifs simultanément sur un même site.