# Locale WordPress et langue du site : pourquoi vos éditeurs s’y perdent

> Un rédacteur change sa langue d'interface personnelle et croit avoir changé la langue du site. La confusion est fréquente, la distinction est simple.

- Auteur : Clément Hadrot
- Publié le : 2024-08-10
- Mis à jour le : 2024-08-10
- Catégorie : Multilingue
- URL : https://wpmoderne.dev.wordpress-developpement.fr/multilingue/locale-wordpress-langue-site-confusion/

## L’essentiel

- La locale utilisateur ne concerne que l'interface d'administration
- La langue du contenu dépend uniquement de l'extension multilingue utilisée
- Une seule phrase suffit souvent à dissiper la confusion en formation client

« J'ai changé la langue dans mon profil, mais le site s'affiche toujours en français pour mes visiteurs anglophones. » Ce message, reçu par le support d'une agence après la livraison d'un site multilingue, illustre une confusion extrêmement fréquente chez les rédacteurs qui découvrent WordPress : la différence entre la locale de leur profil utilisateur et la langue du contenu publié sur le site.

Cette confusion n'a rien d'absurde : les deux réglages portent un nom proche, se trouvent tous deux dans les écrans d'administration, et concernent tous deux la notion de « langue ». Pourtant, ils n'ont strictement aucun lien fonctionnel entre eux, et l'expliquer clairement en une phrase évite un nombre surprenant de tickets de support.

## Le réglage de profil : une préférence purement personnelle

Chaque utilisateur WordPress dispose, dans son profil (*Utilisateurs → Votre profil*), d'un champ « Langue » qui détermine uniquement la langue dans laquelle s'affichent les libellés de l'interface d'administration pour ce compte précis : les menus, les boutons, les messages système. Ce réglage repose sur les fichiers de traduction du cœur de WordPress (fichiers `.mo`/`.po`), totalement indépendants du contenu du site.

Changer cette valeur en anglais pour un rédacteur ne modifie strictement rien pour les visiteurs du site : cela change uniquement, pour ce rédacteur précis et lui seul, le libellé des menus qu'il voit en se connectant à l'administration. Un autre utilisateur, connecté avec sa propre locale réglée en français, verra une interface entièrement différente pour les libellés, sur le même site, avec le même contenu final côté visiteurs.

> L'essentiel à retenir : La locale utilisateur ne concerne que l'interface d'administration ; La langue du contenu dépend uniquement de l'extension multilingue utilisée ; Une seule phrase suffit souvent à dissiper la confusion en formation client

## La langue du contenu : une tout autre mécanique

La langue affichée à un visiteur du site dépend exclusivement de la configuration de l'extension multilingue utilisée — Polylang, WPML ou une alternative — et du contenu réellement traduit dans chaque langue activée sur le site. Ce réglage n'a aucun lien avec la locale de profil d'un utilisateur administrateur ou rédacteur : un rédacteur dont l'interface est en anglais peut très bien rédiger et publier du contenu uniquement en français, et inversement.

La langue par défaut du site elle-même (*Réglages → Général → Langue du site*) constitue un troisième réglage, distinct des deux précédents : elle définit la locale utilisée pour l'affichage public par défaut quand aucune extension multilingue ne prend le relais, et sert également de référence pour certains textes générés automatiquement par le cœur de WordPress (formulaires de commentaires, messages d'erreur natifs) dans les zones non couvertes par l'extension multilingue.

| Réglage | Où le trouver | Ce qu'il change | Qui est concerné |
| --- | --- | --- | --- |
| Locale de profil | Utilisateurs → Votre profil | Libellés de l'interface d'administration | L'utilisateur connecté uniquement |
| Langue du site | Réglages → Général | Locale par défaut du site, textes système natifs | Tous les visiteurs, en l'absence d'extension multilingue |
| Langues du contenu | Polylang / WPML | Le contenu réellement affiché par langue | Tous les visiteurs, selon la langue choisie ou détectée |

## Pourquoi cette confusion revient si souvent en formation client

La plupart des rédacteurs découvrent le réglage de locale de profil en explorant leur propre compte, par curiosité, sans lien avec une intention de modifier le site. Le nom du champ (« Langue ») ne précise nulle part qu'il s'agit d'un réglage purement personnel, ce qui alimente naturellement l'hypothèse qu'il agit sur le site entier.

La confusion inverse existe aussi : un rédacteur qui souhaite vérifier l'apparence de la version anglaise du site pense parfois, à tort, devoir changer sa propre locale de profil en anglais avant de consulter le site, alors qu'il suffit de naviguer simplement vers l'URL ou la version anglaise du contenu en façade, sans toucher à son profil.

> La phrase qui a le mieux fonctionné en formation client : « Votre langue de profil, c'est votre bureau. La langue du contenu, c'est la vitrine. Changer votre bureau ne redécore jamais la vitrine. »

## Un cas particulier : les traducteurs à locale dédiée

Sur certains projets, il est pertinent d'assigner explicitement à chaque rédacteur une locale de profil correspondant à la langue dans laquelle il rédige principalement — un rédacteur anglophone recevra une interface en anglais, ce qui réduit les erreurs de manipulation liées à une interface dans une langue qu'il maîtrise moins bien. Ce choix reste néanmoins un confort d'usage, jamais une condition technique pour que la traduction du contenu fonctionne correctement.

## Comment prévenir cette confusion dès la livraison

- Inclure, dans la documentation remise au client, un encart dédié qui distingue explicitement les trois réglages du tableau ci-dessus.
- Lors de la formation initiale, montrer concrètement l'absence d'effet du changement de locale de profil sur le contenu public, en changeant la locale en direct devant le client sans qu'aucune page du site ne change à l'écran.
- Nommer clairement, dans les échanges avec le client, « langue d'interface » et « langue de contenu » plutôt que le terme générique « langue », qui entretient l'ambiguïté.

## En résumé

Cette confusion, bien que fréquente, se résout presque toujours par une explication simple plutôt que par un correctif technique : les deux réglages n'ont jamais été conçus pour interagir, et aucune configuration ne peut les lier artificiellement sans dénaturer leur fonction respective. Le temps investi à l'expliquer clairement en formation initiale reste largement inférieur au temps que coûterait chaque ticket de support généré par cette confusion une fois le site en production.