Traduire un thème WordPress

Ayant une fois de plus acheté un thème “beau mais mal foutu”, et notamment sans aucune internationalisation, je vais en profiter pour détailler toutes les étapes de la traduction d’un thème WordPress. Ce tuto s’appuie notamment sur l’excellente série publiée par Marc Charlet sur l’internationalisation des thèmes WordPress. Sur le fonds, rien n’a changé depuis 2006…

Un bref rappel théorique : internationalisation et traduction

L’internationalisation c’est la mise en place des structures techniques qui vont permettre de faire la traduction (un peu plus de détails ici).

WordPress utilise la technologie Gettext, qui identifie les chaînes à traduire à travers une fonction php et va chercher la traduction dans un fichier spécial, le .mo , (par exemple, fr_FR.mo pour le français). Le fichier .mo, en langage machine, n’est pas directement éditable, et il est généré par un programme spécial, PoEdit, qui permet de créer les fichier .po et d’enregistrer les traductions (en enregistrant le fichier, PoEdit génère automatiquement un fichier .mo). Le fichier .po est un “bête” fichier texte, qui liste les chaines dans la langue d’origine (généralement l’anglais) et la traduction.

L’internationalisation d’un thème se base donc sur celle de WordPress : toutes les fonctions de gestion des traductions sont dans le “core”, reste à coder correctement les chaînes dans le thème pour qu’elles soient identifier comme à traduire. Un thème peut comporter des fonctions javascript : si les fichiers sont légèrement différents, le principe est le même.

La traduction, quant à elle, se fera une fois le thème internationalisé : avec gettext (ou un autre utilitaire, ou WPML), on passera à travers toutes les chaînes pour en faire la traduction.

Les outils de la traduction

Pour travailler dans de bonnes conditions, il faut donc :

• un éditeur de texte supportant les macros (je suis une convaincue de l’utilisation de Dreamweaver en mode code, mais des Notepad++ ou autres font aussi parfaitement l’affaire)
• l’utilitaire gettext, pour pouvoir générer les fichiers .pot
• PoEdit pour générer les différents fichiers .po et .mo
• un serveur local (j’utilise Wamp, il y a aussi Easyphp), pour voir en direct les résultats de son travail

Accessoirement, un bon dictionnaire n’est pas inutile, ainsi qu’un accès à la doc de WordPress.

L’identification des chaînes à traduire

La syntaxe php pour gettext

WordPress utilise deux notations :
__('Ma chaine', 'le domaine de texte') pour les chaînes de textes utilisées en tant que telles, par exemple en paramètre d’une fonction et _e('Ma chaine', 'le domaine de texte') qui est un racourci pour echo __(

Domaine de texte késako ? Basiquement, pour résumer, on dira que c’est l’identifiant du fichier .po / .mo à utiliser.

Dans le gettext d’origine, les fichiers sont stockés dans des répertoires par langue, où peuvent coexister plusieurs fichiers .po . On pourrait donc avoir dans le même répertoire un fichier wordpress-Fr_fr.po, un fichier monplugin-FR_fr.po, qui correspondraient aux domaines de texte (“textdomain” en anglais) wordpress et monplugin. Gettext irait chercher la traduction de __('Leave a comment', 'wordpress') dans le fichier wordpress-FR_fr.po et de __('Leave another comment', 'monplugin') dans monplugin-FR_fr.po .

WordPress a changé légèrement cela (ce qui facilite la distribution des fichiers de langues directement à l’intérieur du thème ou du plugin). Il ira chercher les fichiers dans le dossier du thème ou du plugin. On peut donc se contenter de les identifier avec FR_fr (ou tout autre code langue). En revanche, il faut toujours lui indiquer le domaine de texte.

Cela se fait au début du fichier functions.php avec l’instruction load_theme_textdomain('le domaine de texte', 'le chemin vers le fichier') donc la documentation se trouve dans le codex de WordPress. Le chemin vers le fichier est optionnel, dans ce cas les fichiers .po / .mo doivent se trouver à la racine du thème. Le nom du domaine est un nom informatique, donc pas d’espace, de caractères accentués ou exotiques.

Le marquage des chaînes

On va avoir plusieurs situations possibles :

1. la chaine est dans du code HTML, il faut donc insérer avant <?php _e(' et après la chaine ', 'le domaine de texte') ; ?>
2. la chaine est dans du php, elle est donc normalement déjà quotée. Il faut donc insérer avant __( et après la chaine , 'le domaine de texte')
3. la chaine est déjà identifiée comme à traduire, mais sans domaine de texte (par exemple, traduction standard de WordPress que l’on souhaite pouvoir modifier pour ce thème), il faudra rajouter à l’intérieur de la commande gettext ', 'le domaine de texte'.

J’ai donc défini dans Dreamweaver trois fragments de code (deux qui enveloppent la sélection, et un qui s’insère simplement) chacun avec leur commande clavier (en étant sûre que je peux la faire de la main gauche seulement) et parcourir mes fichiers avec la souris. Productivité maximum !

Prendre du temps pour ne pas en perdre

L’étape d’identification des chaînes est importante. Il faut travailler avec méthode, en pensant à ce que l’on va obtenir à l’étape suivante : une liste de chaînes à traduire. Un certain nombre de pièges sont à éviter, quitte à modifier le code source.

Ne pas multiplier les versions d’une chaîne

“Bonjour!”, “Bonjour” et “bonjour,” sont trois chaînes différentes. “Laissez un commentaire” et “Laisser 1 commentaire” sont deux chaînes différentes, avec exactement la même signification. “Se connecter”, “Connectez vous”, “Je me connecte”, “se loguer” aussi.

Dans certaines fonctions de WordPress, il faut inclure le marquage HTML. On pourra trouver

Archives

et Archives.

Une bonne internationalisation (préparation de la traduction) va éviter ces doublons au maximum, ce qui permettra d’avoir :

1. un nombre minimum de chaînes à traduire, moins de travail, moins de risques d’erreurs
2. une formulation cohérente à travers tout le site, donc une meilleure ergonomie

Ainsi dans le dernier cas, on va transformer echo '

Archives

‘ en echo '

‘.__(‘Archives’, ‘textdomain’).’

‘ ce qui permettra de ne pas doubler la chaîne avec Archives “tout seul”.

Localiser et pas seulement traduire : typographie et autres joyeusetés

Selon les langues, les règles typographiques changent : ainsi en français on met un espace avant et après les signes doubles (comme les deux points et le point virgule), le point d’interrogation ou le point d’exclamation, mais pas en anglais ni en allemand. Juste pour vous donner un exemple, la complexité des règles typographiques sur les guillemets.

Certaines langues, comme le slovène ou l’arabe, on une forme de pluriel de plus, le duel, qui s’applique uniquement à “deux”, tandis que le polonais a un pluriel pour les nombre finissant par 2, 3 ou 4 et un autre pour les nombres finissant par 5, 6, 7 , 8, 9, 0 et 1 (chose que Gettext sait gérer avec ngettext et dngettext)

Personnellement, j’essaie de “traduire” à part les caractères typographiques qui changent.

Le traducteur va t il comprendre ce qu’on lui demande de traduire ?

La personne qui va faire la traduction connaît t elle WordPress et l’informatique ? Au moins suffisamment pour comprendre des phrases où des variables sont insérées ?
Comme par exemple
%1$s has been successfully subscribed to %2$s
ou pire
You have searched the href="%1$s/">%2$s blog archives for ‘%3$s’. If you are unable to find anything in these search results, you can try one of these links.
ou pour savoir que dans
Trash <span class="count">(%s)
il ne faut pas traduire count ?

Si vous utilisez PoEdit, il est possible de donner un exemple de phrase générée par le code pour aider le traducteur, ou de donner des instructions.

La préparation du thème pour la traduction est donc une tâche intelligente qui facilite la suite (qui fera l’objet des prochains articles de la série)