vendredi 25 septembre 2026

À propos

Contact

Multilingue

Glossaire du multilingue WordPress : traduction, localisation et hreflang

Traduction, localisation, hreflang, locale : un client confond souvent ces termes en cadrant son projet international. Chaque définition, avec ses implications concrètes.

Par Clément Hadrot • 18 décembre 2024 • 6 min de lecture • Aucun commentaire
Glossaire du multilingue WordPress : traduction, localisation et hreflang

« On veut juste traduire le site en anglais et en espagnol, rien de plus compliqué. » Cette phrase, entendue en réunion de cadrage, cache souvent un projet nettement plus vaste que ce qu’elle laisse entendre. Une fois les questions précises posées — quels formats de date, quelle devise, quelles mentions légales, quelle structure d’URL — le projet dépasse largement la simple traduction de texte. Ce glossaire vise à poser des définitions claires, utiles autant en interne pour cadrer un devis qu’en réunion pour aligner les attentes du client sur ce que chaque terme implique réellement.

Traduction

La traduction désigne le remplacement d’un texte source par son équivalent dans une autre langue, en conservant le sens du message. C’est l’opération la plus visible d’un projet multilingue, et souvent la seule anticipée par le client au moment du cadrage initial. Techniquement, sur WordPress, elle repose sur des extensions comme Polylang ou WPML, qui créent une version distincte du contenu par langue, reliée à l’original par une correspondance explicite.

Une traduction fidèle peut pourtant rester inadaptée culturellement : traduire littéralement un slogan ou une expression idiomatique produit souvent un résultat correct grammaticalement mais étrange, voire contre-productif, pour un lecteur natif de la langue cible. C’est précisément la limite que la localisation vient combler.

L'essentiel à retenir : La traduction change le texte, la localisation change les usages ; Le hreflang ne remplace jamais une bonne architecture d'URL ; Confondre ces notions coûte cher au moment du cadrage du projet

Localisation

La localisation va au-delà du texte : elle adapte l’ensemble de l’expérience aux usages et attentes culturelles d’un marché précis, au-delà de la simple langue. Un site localisé pour le marché allemand n’affiche pas seulement du texte en allemand, il adapte le format des dates (jour avant mois), le séparateur décimal (virgule plutôt que point), le format des numéros de téléphone, et parfois jusqu’aux couleurs ou images utilisées si certaines connotations culturelles diffèrent.

Sur un projet e-commerce, la localisation touche également la devise affichée, les moyens de paiement proposés (certains marchés privilégient des solutions locales absentes ailleurs) et les mentions légales spécifiques à chaque pays, un point détaillé dans un article distinct de cette série consacré aux mentions légales par pays.

  • Une traduction sans localisation : le texte est en allemand, mais les dates restent au format anglo-saxon.
  • Une localisation complète : le texte, les dates, la devise et les mentions légales correspondent tous aux usages du marché allemand.

Internationalisation

L’internationalisation, souvent abrégée « i18n » (les 18 lettres entre le « i » et le « n » de ce mot anglais), désigne la préparation technique d’un site ou d’un thème pour qu’il puisse être traduit et localisé sans modification de son code source. Un thème WordPress correctement internationalisé utilise systématiquement les fonctions de traduction du cœur (__(), _e(), esc_html__()) plutôt que du texte codé en dur, ce qui permet ensuite au module String Translation de WPML ou à un fichier .po classique de proposer une traduction sans toucher au code.

Un thème mal internationalisé — texte codé en dur dans les fichiers PHP sans passer par ces fonctions — complique considérablement tout projet multilingue ultérieur, car chaque chaîne non capturée doit être corrigée manuellement dans le code avant de pouvoir être traduite.

Locale

La locale désigne un identifiant technique précis combinant une langue et, souvent, une région (par exemple fr_FR pour le français de France, fr_CA pour le français du Canada, en_GB pour l’anglais britannique par opposition à en_US). Cette distinction importe dès qu’un même mot s’écrit différemment selon la région (« colour » contre « color »), ou que les usages locaux diffèrent malgré une langue commune.

WordPress associe une locale à chaque langue installée, visible dans les noms de fichiers de traduction du cœur (fr_FR.mo). Une confusion fréquente, traitée dans un autre article de cette série, consiste à mélanger cette notion de locale avec le réglage de langue de profil utilisateur, alors que les deux concepts restent techniquement liés mais fonctionnellement distincts.

Hreflang

La balise hreflang est une annotation technique, placée dans le <head> HTML d’une page ou dans un sitemap XML, qui indique aux moteurs de recherche l’existence de versions équivalentes d’un même contenu dans d’autres langues, avec leur URL respective. Son rôle n’est pas de traduire ni de localiser quoi que ce soit : elle sert uniquement à guider les moteurs de recherche vers la bonne version linguistique à proposer selon la langue ou la région de recherche de l’utilisateur.

<link rel="alternate" hreflang="en" href="https://exemple.com/en/page/" />
<link rel="alternate" hreflang="fr" href="https://exemple.com/fr/page/" />
<link rel="alternate" hreflang="x-default" href="https://exemple.com/" />

Une erreur fréquente consiste à croire qu’ajouter des balises hreflang correctes suffit à résoudre un problème de référencement international, alors qu’aucune balise ne compense une architecture d’URL incohérente ou un contenu réellement absent dans la langue annoncée.

Le hreflang est un panneau indicateur, pas une destination. Il annonce une route qui doit exister réellement derrière, sous peine de perdre la confiance du moteur de recherche qui le suit.

Pourquoi ce glossaire sert concrètement en cadrage de projet

Poser ces définitions dès la première réunion avec un client international change directement la nature du devis produit. Un client qui déclare vouloir « juste traduire » son site, une fois confronté à la question précise des formats de date, de devise et des mentions légales par pays, réalise souvent que son besoin réel relève de la localisation, un périmètre plus large et donc plus coûteux qu’une simple traduction de texte.

En résumé

Ces cinq termes se recoupent dans le langage courant, mais chacun désigne une opération technique distincte, avec un périmètre et un coût différents. Les distinguer clairement dès le cadrage d’un projet évite les malentendus qui, sinon, ne remontent qu’au moment de la livraison, quand le client découvre que « traduire le site » signifiait pour lui bien davantage que ce que le devis initial couvrait.

Partager :

À propos de l'auteur

Clément Hadrot

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

Voir tous ses articles

Dans la même veine

À lire aussi