Internationaliser un plugin WordPress avec gettext

Si vous avez déjà utilisé des plugins WordPress, vous n’êtes sûrement pas passé à côté de certains détails comme une langue différente de celle présente sur les captures d’écran que vous aviez pu voir avant de l’installer. Évidemment, ça n’a rien de mystérieux : l’internationalisation est passée par là, et si nous avons déjà vu comment internationaliser un site quelconque grâce à gettext et sa déclinaison PHP, il est maintenant temps de passer à l’internationalisation d’un plugin WordPress.

Comme vous pourrez le constater, il y a quelques différences avec ce que nous faisions auparavant sans WordPress, ce dernier ayant quelque peu simplifié la démarche. Vous pourrez par exemple vous permettre de mettre tous vos fichiers de langues dans un seul et unique dossier, voire même dans le seul dossier qui contient votre plugin, même si ça fera un peu bordel.

Préparation du plugin

Pour commencer, comme sans WordPress, nous devons créer le domaine et demander à WordPress de le charger. Cela se fait en une seule ligne, que nous insérerons dans une fonction, comme par exemple :

<?php
function charger_mes_langues() {
	load_plugin_textdomain('mon-plugin', false, dirname(plugin_basename(__FILE__)) . '/lang/');
}
?>

Vous l’aurez compris, la chaîne dans le premier argument n’est autre que le nom du domaine, que vous allez devoir choisir unique pour ne pas interférer avec les autres plugins utilisés. Le nom du plugin peut être une bonne idée. Le second argument, qui vaut ici false, vaudra toujours false : il s’agit d’un ancien argument utilisé dans les vieilles versions de WordPress et qui est aujourd’hui déprécié. Le troisième argument est lui beaucoup plus important puisqu’il indique à WordPress où chercher les fichiers de langues.

Pour cette troisième valeur, utiliser la syntaxe décrite ici est vivement recommandé puisqu’il s’agit de la plus adaptative. Le chemin attendu par WordPress est un chemin relatif par rapport au dossier contenant votre plugin, et ces fonctions nous permettent justement de faire ça sans connaître à l’avance le nom du dossier ou l’emplacement exact du fichier utilisé.

Ainsi, plugin_basename() est une fonction WordPress qui renvoie le chemin, relatif à partir du dossier de base de votre plugin, vers le fichier indiqué en argument, d’où la constante PHP __FILE__ qui donne justement le chemin vers le fichier actuel. La fonction dirname() nous vient elle directement de PHP et permet de supprimer le nom du fichier qui traîne toujours, pour ne récupérer que le nom du dossier que l’on voulait. Enfin, on concatène ici le sous-dossier lang qui est l’endroit où j’ai choisi de mettre mes fichiers de langues.

Bon, maintenant il faut appeler la fonction charger_mes_langues(). Si vous avez l’habitude de WordPress, vous devez sûrement vous demander quelle action nous devons utiliser ici, et vous avez bien raison. Le nom de l’action en question est ici « plugins_loaded » qui est appelée après que les plugins activés aient été chargés :

<?php
add_action('plugins_loaded', 'charger_mes_langues');
?>

Et c’est tout pour la création du domaine. Comme quoi, c’était plus simple sous WordPress. La suite des opérations diffère encore quelque peu de nos habitudes puisqu’il va falloir utiliser les fonctions de WordPress et non celles de gettext. Bon, que l’on se rassure tout de même, ce n’est pas franchement plus compliqué : au lieu d’utiliser la fonction _(), nous allons utiliser _e() qui affiche automatiquement la chaîne sans avoir à faire un echo. Cette fonction s’utilise comme ceci :

<p><?php _e('Hello World!', 'mon-plugin'); ?></p>

Comme vous pouvez le voir, elle attend deux arguments, faciles à deviner : le premier est la chaîne à traduire et le second est le nom du domaine créé pour votre plugin. Notez que, comme pour gettext seul, WordPress nous fournit plusieurs fonctions, utiles ou non selon les cas. Ainsi, si vous voulez récupérer la chaîne traduite sans qu’elle ne soit affichée par défaut, c’est possible en utilisant la fonction __() (notez les deux underscores à la place d’un seul) qui attend les mêmes arguments que _e().

Traduction

Côté WordPress, nous en avons fini : il faut maintenant passer à la partie traduction qui, pour le coup, est quasiment identique au cas général. Hormis quelques détails.

Premièrement, l’utilisation de xgettext va différer un peu : nous n’utilisons pas de fonctions gérées nativement par gettext, et il va donc falloir indiquer à xgettext dans quelles fonctions il doit aller chercher les informations. C’est on ne peut plus simple puisqu’il suffit d’utiliser l’option –keyword qui demande en valeur le nom de la fonction :
xgettext --keyword="_e" mon-plugin.php -o lang/mon-plugin.pot

Une fois ce *.pot créé, il faut maintenant le traduire, ce qui se fait exactement de la même façon que dans le cas général. Le seul détail qui va encore différer est le nom des fichiers qui doit contenir le nom du domaine suivi du code de langue, comme par exemple « mon-plugin-fr_FR.po » (ou *.mo c’est pareil).

C’est tout !

Et voila ! Votre plugin est maintenant prêt à être internationalisé. Ce n’était franchement pas compliqué et ça peut vous faire gagner plus d’utilisateurs, alors il ne faut surtout pas s’en priver !