WordPress: Traduire un thème

Je garde l’objectif de publier le thème actuel du site. Pour cela, j’ai planifié quelques « travaux », d’abord pour l’améliorer, puis pour la publication proprement dite. L’une des tâches consiste à rendre le thème multilingue, pour que les textes fixes puissent s’afficher correctement en fonction de la langue de l’utilisateur.
WordPress fournit une méthode relativement simple pour internationaliser thèmes et plugins.

Principe général

Un peu de vocabulaire

Si vous faîtes des recherches concernant la traduction de thèmes, de plugins, ou de logiciels, vous tomberez souvent sur deux termes: Internationalisation (en anglais Internationalization, et en abrégé i18n), et Régionalisation (en anglais localization, et en abrégé i10n).

L’internationalisation est le processus qui consiste à développer un produit, une application ou un document, de façon à le rendre facilement adaptable à différentes langues et cultures.

La Régionalisation est la tâche qui consiste à traduire le contenu d’un produit, d’un document, ou l’interface d’un logiciel, dans une autre langue, en tenant compte de la culture locale.

On utilise souvent les abréviations i18n et i10n pour désigner les deux termes, parce qu’il y a 18 lettres entre le i et le n de Internationalization, et 10 lettres pour localization.

L’internationalisation est plutôt technique, et nécessite des connaissances informatiques. La régionalisation fait plus appel à des connaissances linguistiques.

Framework GNU GetText

WordPress utilise un framework appelé GNU GetText pour gérer les textes dans différentes langues. Globalement, tout texte, doit être préalablement traité avant affichage. Le framework fournit pour cela deux fonctions PHP:

  • __(<texte>), qui renvoie un texte sous forme de chaîne de caractères. Cette fonction doit être utilisée lorsque le texte est envoyé à une autre fonction par exemple,
  • _e(<texte>), qui affiche directement le texte.

Dans les deux cas, le mécanisme est le suivant:

  • Les fonctions précédentes récupèrent le texte passé en paramètre,
  • Recherchent ce texte dans un référentiel spécifique,
  • Récupèrent dans ce référentiel, la traduction du texte, en fonction de la langue sélectionnée,
  • Affichent ou renvoient cette traduction.

Le référentiel est constitué de fichiers suffixés .MO, et qui doivent être fournis avec le thème.
Exemple de fonctionnement: la fonction _e('Welcome') renverra

  • Bienvenue si la langue de WordPress est le français,
  • Willkommen si la langue sélectionné est l’allemand,
  • Bienvenida en espagnol,

Si les fonctions ne trouvent pas de fichiers .MO alors elles renvoient la chaîne non traduite.

Ce système d’internationalisation et de régionalisation est également utilisé pour les plugins. Si le thème ainsi que tous les plugins sont accompagnés d’un fichier .MO, WordPress doit savoir s’adresser au bon fichier pour trouver la bonne traduction. GNU GetText gère cette contrainte, avec la notion de domaine:

  • Il faut d’abord déclarer le domaine pour notre thème (fonction load_theme_textdomain)
  • Par la suite, la syntaxe des fonctions __( ) ou _e( ), devient __(<texte>,<nom du domaine>) et _e(<texte>,<nom du domaine>).

Conception des fichiers .MO

La construction de ces fichiers s’effectue en deux étapes:

  • Internationalisation:
    • Élaboration d’un fichier modèle .POT (Portable Object Template), qui contiendra toutes les entités à traduire,
    • Construction ou modification du thème pour qu’il fasse appel à des instructions spécifiques d’affichage.
  • Régionalisation:
    • Construction d’un fichier .PO à partir du fichier .POT, en traduisant toutes les entités précédemment décrites,
    • Compilation du fichier .PO pour obtenir un fichier .MO .

Il y aura autant de fichiers .PO et .MO que de traductions.

Application à un thème

Nous venons de voir la théorie, passons à la pratique.

Internationalisation 1: Création d’un fichier .POT

La création du fichier est assez simple, il suffit

  • D’ouvrir un éditeur de texte,
  • De copier le texte présenté dans le Codex WordPress et de le coller dans l’éditeur,
  • De sauvegarder le fichier.

Il n’existe pas de convention spécifique pour ce fichier. J’ai choisi de lui donner le nom du thème (MyOwntTheme.pot).

Le fichier prend la forme suivante:

# LANGUAGE (LOCALE) translation for WordPress.
# Copyright (C) YEAR WordPress contributors.
# This file is distributed under the same license as the WordPress package.
# FIRST AUTHOR , YEAR.
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: WordPress VERSION\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2005-02-27 17:11-0600\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME\n"
"Language-Team: LANGUAGE\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=CHARSET\n"
"Content-Transfer-Encoding: 8bit\n"

Internationalisation 2: Internationalisation

Il s’agit d’indiquer à WordPress quel est le domaine associé au thème. Il faut, pour cela

  • Créer ou éditer le fichier functions.php à la racine du thème,
  • Ajouter la ligne load_theme_textdomain('<nom du domaine>');.

Le plus simple est de donner au domaine, le même nom que le thème.

A partir de là, nous avons le fichier modèle, et le nom du thème, nous pouvons commencer sa transformation.

Internationalisation 3: Modification du thème

Cette phase consiste à remplacer toutes les messages codés « en dur » dans les fichiers du thème, par un appel à l’une des fonctions __() ou _e(), comme dans l’exemple qui suit:

<div class="entry-nav">
       Navigation bar</div>

devient

<div class="entry-nav">
      _e('Navigation bar','MyOwnTheme');</div>

Parallèlement, chaque message, label, chaînes de caractères … rencontré, doit être ajouté au fichier .POT. Si l’on reprend l’exemple précédent, il faut ajouter les lignes suivantes dans le fichier POT:

# index.php: line 1
msgid "Navigation bar"
msgstr ""
 
# index.php: line 2
msgid "Previous posts"
msgstr ""
 
# index.php: line 3
msgid "Next posts"
msgstr ""

Même si les commentaires ne sont pas obligatoires, ils sont importants pour améliorer/faciliter la maintenance.

La tâche n’est pas complexe, mais elle est assez ingrate: il faut parcourir tous les fichiers du thème, un par un, sans rien oublier. Un tests de temps en temps, en naviguant dans les pages du blog, permet de voir si tout s’affiche toujours correctement (l’oubli d’une quote ou d’un point-virgule est vite arrivé).

A ce stade, l’internationalisation est terminée. Notre thème ne s’affiche toujours pas dans une autre langue, mais il est prêt à être très facilement traduit.

Régionalisation: Traduction

Cette phase consiste à

  • Copier le fichier .POT en .po
  • Editer le .po

Contrairement au cas des plugins, WordPress n’offre pas beaucoup de souplesse dans la gestion des fichiers de régionalisation.

  • Le répertoire de stockage de ces fichiers doit obligatoirement être celui du thème,
  • Les fichiers doivent avoir un nom du type ll_CC.po, où ll_CC est un code représentant la langue et le pays (fr_FR, en_US, de_DE, es_ES …).

La phase de traduction consiste à traduire les lignes msgid du fichier, et d’inscrire la traduction dans les lignes msgstr. En continuant notre exemple: nous avons un fichier fr_FR.po qui ressemble à

# index.php: line 1
msgid "Navigation bar"
msgstr "Barre de navigation"
 
# index.php: line 2
msgid "Previous posts"
msgstr "Articles précédents"
 
# index.php: line 3
msgid "Next posts"
msgstr "Articles suivants"

Régionalisation: Compilation

Une fois terminé ce travail de traduction, il ne reste plus qu’à « compiler » le fichier .po pour qu’il puisse être exploité par GNU gettext.
La documentation de WordPress fournit une liste de produits pour éditer et compiler les fichiers .po. Je ne connais les pas suffisamment pour en conseiller un. Personnellement j’utilise PoEdit.

Le fichier compilé portera le même nom que le fichier .po, mais avec l’extension .mo. Dans notre cas, nous obtenons donc fr_FR.mo.

Utilisation

Si vous avez effectué toutes les étapes précédentes, la régionalisation du thème devrait fonctionner sans problème.
Dans l’exemple que nous avons suivi depuis le début, le fichier .pot est écrit en langue anglaise. Donc en l’absence de tout fichier .mo dans le répertoire du thème, le site s’affichera dans cette langue. En présence du fichier fr_FR.mo, le site s’affichera en langue française.

La langue du thème est définie par la langue de l’interface d’administration. Si celle-ci est en français, le thème s’affichera en français.

Le choix de langue dans WordPress nécessite l’édition du fichier wp-config.php (à la racine du blog), et la modification de la ligne define('WPLANG', '').

Particularités

Nous venons de voir la méthode a employer pour le cas de messages simples. Mais pour être complet, une simple traduction ne suffit pas, il faut également tenir compte

  • du format des dates,
  • des caractères spéciaux (caractères accentués, ponctuation spécifiques, …).
  • la direction d’affichage (de gauche à droite ou inversement)

Pour les dates, nous n’avons normalement rien à faire, WordPress se charge de tout: il traduit les mois, les jours de la semaine (lundi, mardi, …), ainsi que leur abréviation (Lun, Mar, Mer …). Si le thème à traduire propose des formats de date spécifiques, alors il faudra le gérer dans le fichier .POT, puis dans les fichiers .PO, en utilisant les codes de date de PHP.

Le cas des ponctuations est simples à traiter, mais assez rébarbatifs: il faut remplacer tous les caractères « spéciaux » par leur code HTML ou ISO. Le tableau suivant présente quelques exemples de codes pour les caractères accentués courants:

Caractère Entité HTML Code ISO
à & agrave ; & #224;
á & aacute; & #225;
é & eacute; & #233;
è & egrave; & #232;

Concernant la direction d’affichage, je n’ai pas suffisamment d’informations pour en parler correctement. Cette gestion me semble plus compliquée, puisqu’elle suppose différentes modifications au niveau du texte, mais également au niveau de certaines balises HTML. Je compléterai l’article dès que j’ai des informations pertinentes sur le sujet.

Quelques commentaires

Si vous vous lancez dans la traduction de thèmes existants:

  • Attention aux traductions trop proches du dictionnaire: une traduction mot à mot ne produira rien de réellement efficace. Il vaut mieux consulter des sites dans la langue cible, pour s’imprégner du vocabulaire habituellement pratiqué.
  • Il faut également veiller à ce que la traduction proposée ne « déforme » pas le design du thème, à cause de phrases ou de mots trop longs ou trop courts.
  • Respectez le travail de l’auteur du thème en laissant les mentions de copyright ou de crédit de cet auteur. Vous pouvez éventuellement ajouter une mention du type « Traduit par … ».
  • Vous pouvez également envoyer les fichiers POT, PO et MO pour qu’il les ajoute à l’archive de son thème.
  • Pour finir, prenez en compte les recommandations de développement de WordPress

Si vous souhaitez internationaliser votre thème, commencez par construire le fichier .pot en langue anglaise. Cette langue cumule plusieurs avantages: d’abord le fichier pourra être repris par n’importe qui, ensuite la langue anglaise n’est pas accentuée, le fichier ne contiendra donc pas de caractères spéciaux.

Conclusion

En s’appuyant sur GNU gettext, WordPress propose un système d’internationalisation facile à utiliser. Cette méthode proposée ici dans le cadre des thèmes, est applicable (et appliquée) pour les plugins, et WordPress lui-même.

Références

22 thoughts on “WordPress: Traduire un thème”

  1. Bonjour

    J’ai télécharger les traductions de mon thème ici : http://www.wptrads.fr/theme/velvet-sky/

    Puis j’ai inséré fr_FR.mo et fr_Fr.po dans un dossier que j’ai nommé languages car il n’y en avait pas , ni lang ni languages dans mon thème, je l’ai donc créer dans /www/blog/wp-content/themes/velvetsky/

    j’ai essayé d’ajouter load_theme_textdomain( »);

    à mon fichier functions.php dans le répertoire de mon thème mais ça ne marche pas ,

    J’ai vérifié Wp-config y’a bien la bonne ligne WP-LANG ….

  2. Bonjour Thierry,

    Obtenir des exemples de fichiers PO est assez simple: il suffit de télécharger n’importe quel plugin traduit, et d’éditer le ou les fichiers PO.
    En exemple, voici les deux premieres lignes du fichier PO de mon plugin EG-Attachments:
    msgid « Cannot display attachments. Current post or page is protected. »
    msgstr « Impossible d’afficher les pièces jointes. L’article ou la page est protégé. »

    Emmanuel.

  3. Bonjour,
    je reviens à la charge avec mon problème d’accentuations.
    Sur mon po en iso, j’ai remplacé les accents par le code correspondant. Résultat: le code remplace l’accent (visibilité).
    Peut-être faut-il des espaces ?
    Pourriez vous me faire parvenir un exemple de ligne avec le code insérré afin de comprendre son positionnement(code) exact.
    Merci pour votre aide

    PS Merci pour votre aide sur le « remplacer » avec poedit.

  4. Bonjour,

    Pour moi non. Le texte dans le fichier PO doit correspondre a ce que l’on veut au final. S’il s’agit d’une page HTML générée par WordPress, il faut donc que les accents, ponctuations soient remplacés par les codes ISO.

    Par contre, le fichier PO peut être édité avec un éditeur de texte (du genre Notepad++), et l’opération devient moins pénible avec une série de find/replace.

    Emmanuel

  5. Bonjour,
    Je viens de faire une traduction d’aprés un po de prés de 4000 lignes et je dois dire que c’est pénible parce qu’aprés il faut retoucher les erreurs (code,espace,….).
    Maintenant que c’est fait il faut que je retouche les ponctuations auxquels je n’avais pas pensés.
    MA QUESTION: Le po d’origine est en « Content-Type: text/plain; charset=ISO-8859-1 ».
    Est-ce qu’en changeant l’unité de texte je peus éviter de retravailler tous les accents ?
    Et restera t-il fonctionnel ?
    Merci.

  6. Bonjour,
    Pour ceux qui s’aident de google dans la traduction, attention aux majuscules qui ne donne pas forcemment la phrase dans le bon sens voir les mots qui ne correspondent pas.
    Je dis cela pour ceux qui comme moi ne parle pas l’Anglais.
    En dehors de cette parenthèse, je trouve l’article trés bien et il m’a beaucoup aidé.

  7. Merci pour cette réponse rapide

    En fait, je viens de trouver une solution, pas très « élégante » en terme de programmation, mais qui fonctionne sur le mode « ruse »

    Quand vous avez dit que WordPress ne permet pas d’avoir deux langues différentes entre la zone admin et le thème, je me suis dit que cette restriction était un avantage…

    Via Poedit, j’ai ouvert le fichier es_ES.mo puis l’ai enregistré en fr_FR.mo

    Ainsi, on reste bien en français dans la langue de l’interface mais il est leurré car j’obtiens bien de l’espagnol pour les msgs utilisateur

    Merci pour votre participation et bravo pour le reste de votre blog également

  8. Merci pour les compliments.
    Pour la réponse, plusieurs pistes:
    – si le widget utilisé et celui de WordPress: il faut recuperer les fichiers .mo/.po de WordPress lui-meme,
    – si le widget est celui du theme, il faut verifier que le terme non traduit se trouve bien dans le fichier .po du theme (sinon il s’agit d’un bug de traduction du theme).

    Sans logiciel de multilinguisme, WordPress ne permet pas d’avoir deux langues differentes entre la zone admin et le theme.
    Une solution consisterait à modifier le fichier function.php du theme, mais je n’ai pas de solution prete a l’emploi pour cela.
    Je regarderai a l’occasion

  9. En effet excellent article

    Juste une petite question

    J’ai un site WP en espagnol mais j’utilise l’interface admin en français

    J’utilise un thème qui possède sa traduction (es_ES.mo)

    J’ai placé ce fichier dans le répertoire du thème.

    Mais ce n’est pas pris en compte et le texte des widgets (module de recherche) passe en anglais au lieu de l’espagnol attendu.

    Si vous aviez une piste

    Par avance merci

  10. Je suis d’accord, mais lorsque j’ai écrit l’article, je découvrais la méthode, et je n’avais pas abordé ces fonctions-là …

  11. Effectivement, très pédagogique… Mais (oui, faut bien dire qqch de moins positif…) il faudrait peut-être développer un peu plus. Par exemple, rien sur les formes plurielles…

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.