Le WordPress d'aujourd'hui, décodé pour les développeurs

Multilingue

Traduire un thème avec load_theme_textdomain, sans extension multilingue

Un thème vitrine bilingue n'exige pas toujours WPML ou Polylang. La fonction load_theme_textdomain suffit à charger les traductions des chaînes fixes du thème.

Par WordPress Développement • 10 août 2020 • 4 min de lecture • Aucun commentaire
Traduire un thème avec load_theme_textdomain, sans extension multilingue

load_theme_textdomain( 'agence-theme', get_template_directory() . '/languages' ); : cette seule ligne, placée au bon endroit, suffit à faire basculer un thème vitrine entre deux langues, sans installer la moindre extension de traduction.

Le cas visé est précis : un thème sur mesure, développé pour une agence de communication qui présente son activité en français et en anglais, dont seules les chaînes fixes du thème (libellés de menus, textes de formulaires, mentions de pied de page) doivent changer de langue. Le contenu éditorial, lui, reste identique ou est géré séparément par des pages dédiées à chaque langue.

Préparer le thème pour l’internationalisation

Avant de charger la moindre traduction, le thème doit déclarer un domaine de texte cohérent et l’utiliser sur chaque chaîne affichée. Les fonctions à connaître sont __(), _e(), esc_html__() et esc_html_e(), chacune prenant le domaine de texte en second argument :

<h2><?php esc_html_e( 'Nos services', 'agence-theme' ); ?></h2>
<a href="#contact"><?php esc_html_e( 'Nous contacter', 'agence-theme' ); ?></a>

Le domaine de texte, ici agence-theme, doit être identique partout : dans le code du thème, dans l’en-tête du fichier style.css, et dans le nom des fichiers de traduction générés ensuite.

Charger les traductions avec load_theme_textdomain

L’étape suivante consiste à appeler la fonction au bon moment, généralement accrochée au hook after_setup_theme :

add_action( 'after_setup_theme', function() {
    load_theme_textdomain( 'agence-theme', get_template_directory() . '/languages' );
} );

Cette fonction cherche, dans le dossier indiqué, un fichier nommé selon la locale active, par exemple en_US.mo. Si ce fichier existe et que la locale du site correspond, les chaînes marquées avec le domaine agence-theme sont automatiquement remplacées par leur traduction.

Générer les fichiers .po et .mo

Les fichiers sources .po contiennent les paires chaîne originale / traduction en texte lisible ; ils sont ensuite compilés en fichiers .mo binaires, seuls réellement lus par WordPress. L’outil WP-CLI facilite cette extraction directement depuis les fichiers du thème :

wp i18n make-pot . languages/agence-theme.pot
wp i18n make-mo languages/

La commande make-pot parcourt le code du thème à la recherche des appels à __() et consorts, et construit un modèle de traduction. Ce modèle sert de base à la traduction en anglais, sauvegardée ensuite sous en_US.po puis compilée en en_US.mo.

Vérifier la locale réellement chargée

Un piège fréquent consiste à tester le résultat depuis l’administration, en changeant sa propre langue de profil, en pensant vérifier ainsi la traduction du site public. Ce test ne prouve rien : la langue de profil d’un compte administrateur ne concerne que l’interface d’administration, jamais le rendu du thème pour un visiteur anonyme. La seule vérification fiable consiste à modifier la langue générale du site dans les réglages, ou à ouvrir le site depuis une session de navigation privée après avoir changé cette langue générale.

L'essentiel à retenir : load_theme_textdomain charge les fichiers .mo du thème sans extension tierce ; Le domaine de texte doit correspondre exactement entre le code et les fichiers ; Cette méthode traduit le thème, pas le contenu éditorial dynamique

Ce que cette méthode ne couvre pas

Il faut être honnête sur les limites de l’approche : elle traduit uniquement les chaînes codées en dur dans le thème. Le contenu saisi dans l’éditeur (titres de pages, corps de texte, légendes d’images) n’est pas concerné, car ce contenu n’est jamais passé dans une fonction de traduction. Pour un contenu éditorial multilingue, il faut soit dupliquer les pages par langue, soit recourir à une extension dédiée.

  • les chaînes du thème (menus, boutons, libellés) : couvertes par cette méthode
  • le contenu des pages et articles : non couvert, nécessite une duplication manuelle ou un plugin
  • les chaînes des extensions tierces installées : non couvertes, chaque extension gère son propre domaine de texte

Vérifiez toujours que le domaine de texte déclaré dans l’en-tête de style.css correspond au mot-clé passé en argument des fonctions de traduction : une simple faute de frappe suffit à rendre tout le fichier .mo invisible pour WordPress, sans le moindre message d’erreur.

Pour aller plus loin

Cette approche convient parfaitement à un thème sur mesure au périmètre de traduction limité et connu à l’avance. Dès que le nombre de langues dépasse deux, ou que le contenu éditorial doit lui-même être traduit et synchronisé, la maintenance manuelle des fichiers .po/.mo devient vite plus coûteuse que l’installation d’une extension dédiée à la gestion multilingue du contenu.

Laisser un commentaire

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

Partager :

À propos de l'auteur

WordPress Développement

Développeur WordPress, passionné par Elementor, le FSE et l’automatisation par IA.

Voir tous ses articles

Dans la même veine

À lire aussi