Quelle est la différence exacte entre get_locale() et determine_locale() ? La question paraît anodine, mais la confusion entre ces deux fonctions cœur de WordPress explique une bonne partie des filtres de langue qui, sur le papier, semblent corrects mais n’ont jamais l’effet attendu en pratique.
get_locale : une lecture de l’état déjà établi
get_locale() renvoie la locale actuellement active pour l’exécution en cours. C’est une fonction de lecture : elle consulte une variable globale déjà positionnée, éventuellement modifiée en cours de route par switch_to_locale(), mais elle ne décide de rien elle-même. Appeler get_locale() très tôt dans le cycle de chargement de WordPress, avant que cette valeur ait été établie pour la requête, peut renvoyer une valeur par défaut qui ne correspond pas encore à ce que verra finalement le visiteur.
add_action( 'plugins_loaded', function () {
error_log( get_locale() ); // Peut déjà être fiable ici selon le contexte
} );determine_locale : le calcul de cette valeur
determine_locale(), introduite plus tard dans le cœur de WordPress, est la fonction responsable du calcul initial de cette locale pour une requête donnée. Elle applique une série de règles : locale de l’utilisateur connecté le cas échéant, préférences du site, filtres personnalisés accrochés sur le filtre determine_locale lui-même. C’est cette fonction qui, en interne, alimente ensuite ce que get_locale() viendra lire.
add_filter( 'determine_locale', function ( $locale ) {
if ( pll_current_language() ) {
return pll_current_language( 'locale' );
}
return $locale;
} );
Un plugin multilingue comme Polylang ou WPML s’accroche précisément à ce filtre determine_locale pour imposer sa propre logique de détection de langue, en fonction de l’URL ou du sous-domaine consulté, avant que le reste de WordPress ne commence à charger les fichiers de traduction correspondants.
Pourquoi confondre les deux mène à des bugs silencieux
L’erreur la plus fréquente consiste à ajouter un filtre sur determine_locale en pensant modifier un comportement déjà en place, ou inversement à essayer de modifier la locale via un filtre sur un hook qui s’exécute après que determine_locale a déjà fait son travail et que les fichiers de traduction ont déjà été chargés en conséquence. Dans ce second cas, la valeur renvoyée par get_locale() change bien apparemment, mais les traductions déjà chargées en mémoire restent celles de l’ancienne locale, ce qui produit un site à moitié traduit dans une langue, à moitié dans une autre.
Ordre d’exécution à retenir
determine_locale()s’exécute en tout début de cycle de requête, avant le chargement des fichiers de traduction.- WordPress charge les fichiers
.mocorrespondant à la locale déterminée. get_locale()devient fiable et reflète cette locale pour le reste de la requête, jusqu’à un éventuel appel àswitch_to_locale().
Cas d’usage typiques de chacune
- determine_locale : utile pour un plugin multilingue qui doit imposer sa propre règle de détection de langue avant que quoi que ce soit d’autre ne se charge.
- get_locale : utile partout ailleurs dans le code applicatif, pour adapter un affichage, un format de date, ou un choix conditionnel selon la langue active de la requête en cours.
Ce que cet article ne couvre pas
Le fonctionnement détaillé des différentes extensions multilingues (Polylang, WPML, TranslatePress) et leurs mécanismes internes propres de détection de langue ne sont pas traités ici : cet article se limite strictement à la distinction entre les deux fonctions cœur, indépendamment de tout plugin.
Une règle simple à garder en tête :
determine_localedécide,get_localeconstate. Confondre les deux revient à modifier un panneau indicateur après que la voiture a déjà pris la sortie.
En résumé
Distinguer clairement ces deux fonctions évite une classe entière de bugs de traduction incomplète ou de filtres sans effet observable. Avant d’ajouter un filtre lié à la langue, la première question à se poser est simple : cherche-t-on à influencer la décision initiale, ou à lire une décision déjà prise ?
