# determine_locale : comment WordPress choisit la langue avant un plugin

> Avant qu'un plugin multilingue n'entre en jeu, un filtre du cœur a déjà tranché la langue. Voici son fonctionnement exact et l'ordre de priorité qu'il applique.

- Auteur : WordPress Développement
- Publié le : 2020-07-04
- Mis à jour le : 2020-07-04
- Catégorie : Multilingue
- URL : https://www.wpmoderne.fr/multilingue/determine-locale-choix-langue-wordpress/

## L’essentiel

- Le filtre determine_locale s'exécute avant les plugins de traduction
- La variable de requête l passe devant le cookie et l'utilisateur
- Trois sources de langue, un seul filtre pour arbitrer

Comment WordPress décide-t-il, dès les premières lignes de `wp-settings.php`, quelle langue servir à un visiteur, alors qu'aucun plugin de traduction n'est encore chargé ? La réponse tient dans une fonction du cœur, `determine_locale()`, qui tranche la question bien avant que WPML, Polylang ou tout autre outil n'ait la moindre chance d'intervenir.

Cette fonction est peu documentée pour ce qu'elle fait réellement : elle ne traduit rien, elle choisit seulement un identifiant de langue (une chaîne comme `fr_FR` ou `en_US`) qui servira ensuite de base à tout le reste du chargement des traductions. Comprendre son ordre de priorité évite bien des surprises quand un plugin multilingue semble « ignoré » sur certaines pages.

## Ce que fait réellement determine_locale()

La fonction est appelée très tôt, avant le chargement des extensions actives, depuis `wp-includes/l10n.php`. Son rôle est simple à énoncer : renvoyer une chaîne de locale unique qui sera utilisée pour charger les fichiers `.mo` correspondants. Elle applique un ordre de priorité fixe :

- la variable de requête `l`, si elle est présente et qu'il s'agit d'un contexte d'administration ou de connexion
- la locale associée à l'utilisateur connecté, stockée en base dans les métadonnées utilisateur
- la locale générale du site, définie dans les réglages ou par la constante `WPLANG`

Ce classement explique un comportement souvent mal compris : un utilisateur connecté avec une préférence de langue personnelle verra cette préférence l'emporter sur la langue par défaut du site, même sur le front, dans certains contextes.

## Le filtre determine_locale et son point d'entrée

Le filtre porte le même nom que la fonction qui l'expose : `determine_locale`. Il reçoit la locale calculée par le cœur et permet de la remplacer entièrement. C'est ce point précis que les extensions multilingues accrochent pour imposer leur propre logique, fondée sur l'URL, un cookie ou un sous-domaine.

```
add_filter( 'determine_locale', function( $locale ) {
    if ( isset( $_COOKIE['site_lang'] ) ) {
        $allowed = array( 'fr_FR', 'en_US', 'es_ES' );
        if ( in_array( $_COOKIE['site_lang'], $allowed, true ) ) {
            return $_COOKIE['site_lang'];
        }
    }
    return $locale;
}, 20 );
```

Le paramètre de priorité compte ici davantage que d'habitude : un plugin de traduction accroche presque toujours ce filtre à une priorité élevée, précisément pour passer après la logique par défaut et avoir le dernier mot. Un filtre maison ajouté sans réfléchir à la priorité peut donc être écrasé silencieusement.

> L'essentiel à retenir : Le filtre determine_locale s'exécute avant les plugins de traduction ; La variable de requête l passe devant le cookie et l'utilisateur ; Trois sources de langue, un seul filtre pour arbitrer

## Pièges observés en pratique

### Un cache de page qui fige la locale

Le filtre s'exécute à chaque requête PHP, mais si une page complète est servie depuis un cache statique (fichier HTML généré), la locale calculée au moment de la génération reste figée dans le contenu servi. Le symptôme classique : un visiteur change de langue via un cookie, mais reçoit toujours la version mise en cache dans l'ancienne langue jusqu'à expiration du cache.

### Confusion entre locale du site et locale de l'utilisateur

Sur un site multi-auteurs, chaque compte peut avoir sa propre langue d'administration, réglée dans son profil. Cette langue n'a aucun rapport avec la langue affichée au public : elle ne s'applique qu'à l'interface d'administration, jamais au contenu du site vitrine. Confondre les deux mène à des correctifs appliqués au mauvais endroit.

## Cas d'usage légitimes d'un filtre maison

Écrire son propre filtre sur `determine_locale` a du sens pour des besoins simples : un site bilingue sans catalogue de contenu à dupliquer, où seule l'interface change (libellés, formulaires, notifications), peut se contenter de ce mécanisme sans installer d'extension complète. C'est un choix pertinent quand le contenu éditorial reste identique dans les deux langues et que seule la coquille change.

> Avant d'ajouter un filtre sur determine_locale, vérifiez toujours qu'aucune extension active n'accroche déjà ce hook : deux filtres concurrents à la même priorité produisent un résultat imprévisible selon l'ordre de chargement des extensions.

## En résumé

Le filtre `determine_locale` est le point d'entrée le plus bas niveau pour influencer la langue d'un site WordPress, bien avant qu'un plugin de traduction ne prenne le relais. Sa priorité d'exécution, la distinction entre locale utilisateur et locale de site, et l'interaction avec un éventuel cache de page sont les trois points à vérifier en premier lorsqu'un comportement de langue semble incohérent. Maîtriser ce mécanisme du cœur rend le diagnostic des problèmes multilingues nettement plus rapide, quelle que soit l'extension utilisée par la suite.