add_filter( 'determine_locale', 'wpm_locale_api_rest' ); — ce filtre, introduit dans le cœur de WordPress pour permettre de calculer la langue active à partir d’éléments propres à chaque requête, résout un cas particulier : un site propose un rendu classique en français pour ses visiteurs web, mais une application mobile consomme son API REST dans une langue différente, par exemple l’anglais, sans jamais afficher la moindre page HTML du site.
Installer une extension multilingue complète pour ce seul besoin serait disproportionné : le site n’a besoin que d’une langue pour son rendu web, et une autre langue précise, fixe, pour les réponses de son API. Le filtre determine_locale permet de traiter ce cas sans aucune dépendance supplémentaire.
Le contexte : une locale différente selon le point d’entrée
Le filtre determine_locale intervient très tôt dans le cycle de chargement de WordPress, avant même que les fichiers de traduction ne soient chargés. Il reçoit la locale déterminée par défaut, généralement celle configurée dans les réglages du site, et peut la remplacer selon la logique souhaitée, avant que le reste du chargement des chaînes traduites ne s’appuie dessus.
Pour distinguer une requête REST d’un affichage classique, la fonction native wp_is_serving_rest_request(), ou à défaut la constante REST_REQUEST définie par le cœur pendant le traitement d’une requête API, permet une détection fiable sans avoir à analyser manuellement l’URL demandée.
L’implémentation concrète
add_filter( 'determine_locale', 'wpm_locale_api_rest' );
function wpm_locale_api_rest( $locale ) {
if ( defined( 'REST_REQUEST' ) && REST_REQUEST ) {
return 'en_US';
}
return $locale;
}
Cette fonction retourne la locale anglaise dès qu’elle détecte une requête REST en cours, et laisse la locale par défaut inchangée pour toute autre situation, notamment le rendu classique des pages du site pour les visiteurs web habituels. Le reste du chargement des traductions, notamment la sélection des fichiers .mo correspondants, s’appuie ensuite sur cette valeur sans distinction supplémentaire à gérer ailleurs dans le code.
Un cas plus fin : une langue par paramètre de requête
Certaines applications mobiles préfèrent transmettre explicitement la langue souhaitée via un paramètre de requête plutôt que de dépendre d’une valeur fixe côté serveur. Le même filtre peut alors inspecter ce paramètre :
add_filter( 'determine_locale', 'wpm_locale_api_parametre' );
function wpm_locale_api_parametre( $locale ) {
if ( ! defined( 'REST_REQUEST' ) || ! REST_REQUEST ) {
return $locale;
}
$langues_disponibles = array( 'fr_FR', 'en_US', 'es_ES' );
$langue_demandee = isset( $_GET['lang'] ) ? sanitize_text_field( wp_unslash( $_GET['lang'] ) ) : '';
if ( in_array( $langue_demandee, $langues_disponibles, true ) ) {
return $langue_demandee;
}
return $locale;
}
La validation stricte contre une liste blanche de langues disponibles évite qu’une valeur arbitraire transmise par le client ne provoque le chargement d’une locale inexistante ou non installée sur le serveur, ce qui reviendrait silencieusement à afficher les chaînes source en anglais faute de fichier de traduction correspondant.
- Toujours valider la valeur reçue contre une liste explicite de langues supportées.
- Utiliser
REST_REQUESTouwp_is_serving_rest_request()pour isoler ce comportement à l’API seule. - Laisser la locale par défaut inchangée pour tout ce qui n’est pas une requête REST.
Ce que ce filtre ne remplace pas
Ce mécanisme concerne uniquement la locale utilisée pour les chaînes traduites du cœur, des extensions et du thème, pas le contenu lui-même. Si les articles ou pages exposés par l’API doivent aussi exister en plusieurs langues, une architecture de contenu multilingue plus complète reste nécessaire en complément, avec des articles distincts par langue plutôt qu’un simple changement de locale d’affichage des libellés système.
Un repère utile pour ne pas confondre les deux sujets :
determine_localechange la langue des messages système et des chaînes traduites, jamais celle du contenu éditorial publié sur le site.
Pour aller plus loin
Ce filtre reste une solution ciblée, adaptée à un site headless partiel où l’API REST sert un usage distinct du rendu classique. Il évite d’installer une extension multilingue complète pour un besoin qui se résume, au fond, à changer la locale active selon le canal d’accès, sans jamais toucher au contenu affiché aux visiteurs du site classique.
