Pour celles et ceux qui ont déjà écrit un plug-in WordPress, il peut être intéressant de le traduire dans différentes langues afin que des utilisateurs du monde entier puissent l’utiliser correctement, dans leur langue maternelle. Le système d’internationalisation (i18n) intégré à WordPress utilise l’utilitaire gettext, et se base sur des catalogues (un par langue). On trouve de la documentation sur Internet, certes, mais ce n’est pas toujours clair ni complet, et surtout pas souvent en français. D’où ce petit article
Identifier les chaînes à traduire
Dans votre code PHP, identifiez les différentes chaînes à traduire et remplacez-les par un appel à une des fonctions PHP suivantes :
__()
: pour récupérer la chaîne traduite (return),_e()
: pour afficher la chaîne traduite (echo),_n()
: pour gérer les formes plurielles (return).
Prenons un exemple qui affiche une liste d’éléments. On aimerait l’affichage suivant :
- si la liste est vide : La liste est vide.
- si la liste contient un seul élément : La liste contient un élément.
- si la liste contient plusieurs éléments : La liste contient <n> éléments.
Avant :
c9CD413ad60239cefcdacb57afc5dda7000
On cherche toutes les chaînes de texte et on les remplace par des appels aux fonctions PHP citées ci-dessus.
Après :
c9CD413ad60239cefcdacb57afc5dda7001
- Ligne 10 : appel à
_n()
pour gérer les formes plurielles. Arguments :- texte si 0 ou 1 élément (ligne 11),
- texte si 2 éléments ou plus (ligne 12),
- valeur utilisée pour choisir entre le texte 1 ou 2,
- text domain : généralement, le nom de votre plug-in.
- Ligne 30 : utilisation de
_e()
qui fait unecho()
; - Ligne 32 : utilisation de
__()
qui retourne la chaîne.
Il est important de ne pas oublier le deuxième argument (ou quatrième pour _n()
) correspondant au text domain, qui est généralement le nom de votre plug-in.
On va voir qu’on peut aller assez loin dans les traductions pour fournir un texte différent quand la liste est vide ($count = 0
), mais ça ne se gère pas dans le code PHP. Nous aurons donc trois formes plurielles.
Créer le catalogue
Pour cela, nous allons utiliser l’utilitaire libre Poedit (télécharger).
Cet utilitaire, une fois correctement configuré (!), va retrouver les chaînes identifiées par __()
, _e()
et _n()
directement dans le code PHP et créer un catalogue de traduction. Il s’agit d’un fichier texte dont l’extension est .po (d’où le nom de Poedit). Rassurez-vous : Poedit ne touche pas à vos fichiers PHP, il ne fait que les lire.
Allons-y !
- Lancez Poedit.
- Menu Fichier > Nouveau catalogue… puis remplissez les champs dans les 3 onglets comme indiqué ci-dessous :
Onglet 1 : quelques informations génériques
- Jeu de caractères :
utf-8
(recommandé), - Jeu de caractères du code source :
utf-8
(recommandé), - Formes plurielles :
nplurals=3; plural=n<=1 ? n : 2;
(nous allons gérer trois formes plurielles : si 0, si 1, si 2 ou plus).
Onglet 2 : emplacement des fichiers PHP à traduire
- Chemin de base : laissez la valeur proposée (
.
), - Chemins : ajoutez l'entrée
..
. En effet, nous allons enregistrer le catalogue dans un sous-répertoirelanguages
de notre plug-in et Poedit va alors chercher dans les fichiers du répertoire parent.
Onglet 3 : mots-clés permettant d'identifier les chaînes à traduire
Supprimez les entrées existantes de manière à avoir les 3 entrées suivantes :
__
(deux underscores)_e
_n:1,2
Cliquez sur OK. Poedit vous demande où vous souhaitez enregistrer le catalogue de traduction. Créez un répertoire languages
dans le répertoire de votre plug-in puis enregistrer le fichier sous le nom suivant : <nom-de-votre-plugin>-<code_locale>.po
(par exemple : nom-du-plugin-fr_FR.po
pour le fichier français). Après cela, Poedit va analyser vos fichiers PHP et devrait vous afficher une fenêtre contenant la liste des chaînes à traduire qu'il a trouvées (grâce aux marqueurs indiqués dans l'onglet 3) :
Vous pouvez ensuite traduire les chaînes trouvées dans l'interface principale de Poedit. Concernant les multiples formes plurielles, vous avez plusieurs zones de saisie en bas de la fenêtre pour éditer les différentes valeurs :
Si Poedit ne vous affiche pas ces trois zones de saisie, allez dans le menu Catalogue > Configuration..., vérifiez que le champ Formes plurielles est bien saisi puis cliquez sur OK.
Lorsque vous enregistrez, Poedit génère un autre fichier au même endroit que le fichier .po
, avec l'extension .mo
: c'est une version compactée (binaire) de votre catalogue, bien plus efficace à lire lors de l'exécution de votre script PHP.
Dans le code PHP
Pour que les traductions soient utilisées par les fonctions __()
, _e()
et _n()
, il faut charger le catalogue de traduction avec la fonction load_plugin_textdomain()
. Pour cela, dans votre plug-in WordPress, vous devez ajouter ceci :
c9CD413ad60239cefcdacb57afc5dda7002
Puis, lors des appels aux fonctions de traduction, il faut spécifier en deuxième argument (quatrième pour _n()
) le nom du text domain, généralement le nom de votre plug-in (ici : liste-plugin).
Traduire dans d'autres langues
Il vous suffit maintenant de dupliquer votre fichier languages/mon-plugin-fr_FR.po
pour gérer les traductions dans d'autres langues ! Utilisez les codes de locales complet : mon-plugin-en_US.po
, mon-plugin-en_GB.po
, mon-plugin-de_DE.po
, ... Ouvrez ces fichiers avec Poedit, modifiez les textes et enregistrez. Poedit génèrera alors les fichiers .mo
correspondants.
Pour tester, modifiez la constante WP_LANG
définie dans le fichier wp-config.php
de votre installation de WordPress.
Tiens, tu te mets au plugin wordpress maintenant ?
Tiens, ça me rappelle les plugins WordPress que j’ai développés il y a quelques années… J’avais moyennement aimé la gestion de l’internationalisation.
D’une part les méthodes aux noms cabalistiques qui n’ont aucun sens. Certes c’est court mais bon avec une bonne complétion on s’en fiche de gagner quelques caractères.
Ensuite à cause du logiciel de traduction Poedit imposé (de par le fait que c’est lui qui fait la compilation). Devoir installer un logiciel tiers pour faire ses traductions, je trouve ça pas top. D’autant qu’autant que je me souvienne, je trouvais la version Windows de l’époque pas super intuitive sur certains points (pas testé la version Mac donc je peux pas dire).
Et enfin parce que même si ça peut paraitre plus simple d’utiliser les textes directement comme clés, je suis pas fan du tout. D’une mettre des caractères libres dans une clé ça mène facilement à de la merde. De deux quand la traduction dans la langue de référence évolue pour ajouter des précisions ou affiner la formulation, soit on change la clé en passant et on casse la traduction dans les autres langues tant qu’on n’est pas repassé dessus (alors qu’on a fait que préciser ou affiner, donc la traduction préexistante reste valable), soit on ne la change pas et alors on perd totalement l’intérêt de ne pas utiliser des clés plus formatées, voire pire on induit en erreur avec une clé qu’on pense représentative.
Après c’est peut-être parce que je suis trop formaté par les autres systèmes que j’ai utilisés mais j’avais vraiment pas été convaincu.
@teles J’ai eu l’occasion d’en écrire un, et j’ai du l’internationaliser. Donc si mon aide peut servir…
@Darathor Ah, je n’ai pas dit que j’étais fan
C’est un peu lourd, et Poedit est assez… Comment dire… Faut comprendre, quoi ! Cela dit, on n’est pas obligé de l’utiliser : il existe des utilitaires en ligne de commande pour compiler les locales. (Mais sous Mac, c’est marrant à installer…).
Pour les clé de traductions, je suis d’accord avec toi. D’ailleurs rien n’empêche de mettre des clés plutôt que les textes pseudo-définitifs.
@FruityFred
Déjà fait des plugins en gérant la traduction, donc pas de souci
Et oui, ce qu’on passe en param de _() c’est une clé, c’est juste que le premier couillon a mis du texte alors tout le monde pense qu’il faut mettre du texte
et comme j’y repense, on peut même s’en servir pour de la trad dans une appli js http://www.telesphore.org/2009/02/27/poedit-xgettext-et-javascript/
Pour avoir travaillé sur des modules Magento en plusieurs langues et des boutiques multilingues, je trouve le système WordPress tellement archaïque !
Ne connaissant pas Magento (uniquement de nom), je ne peux que vous croire
Pourriez-vous résumer très succinctement les points forts du système utilisé dans Magento ? Merci d’avance !
Je rejoins les avis ci-dessus : c’est très sommaire comme façon de gérer la traduction (après je ne suis pas encore un habitué de poEdit), j’ai pris l’habitude de travailler avec une solution interne qui tourne sur une bdd au lieu de fichiers plats, qui permet par exemple des alertes en cours de saisie si une traduction manque.
Merci de vos commentaires !
Je n’ai jamais dit que c’était révolutionnaire Mais au final, en terme de performances à l’exécution, c’est pas si mal. Et c’est un système assez connu dans le monde de la traduction, et permet à des traducteurs de travailler sur des fichiers simples à traiter.
[…] la création et la modification des fichiers .po. Je vous invite à vous rendre à cet adresse : http://www.fruityfred.com/2012/08/20/internationaliser-traduire-un-plugin-wordpress/ Pour définir, dans une extension, qu’il y a des fichiers de traduction, il faut ajouter la […]
[…] « Internationaliser (traduire) un plug-in WordPress ». fruityfred. http://www.fruityfred.com/2012/08/20/internationaliser-traduire-un-plugin-wordpress/ […]