Le WordPress d'aujourd'hui, décodé pour les développeurs

IA & MCP

Le filtre determine_locale appliqué à un contenu généré par un agent IA

Comment ce filtre cœur détermine la langue dans laquelle un agent doit produire du texte, pour rester cohérent avec le réglage du site.

Par WordPress Développement • 11 juin 2023 • 4 min de lecture • Aucun commentaire
Le filtre determine_locale appliqué à un contenu généré par un agent IA

« determine_locale (string $locale) : Filters the locale for the current request. » La documentation officielle du cœur WordPress décrit ainsi ce filtre, disponible depuis WordPress 5.0, qui détermine la langue effective appliquée à une requête donnée. Pour un développeur qui intègre un agent capable de générer du texte, cette fonction constitue le point d’entrée naturel pour connaître la langue attendue en sortie.

Le piège le plus courant consiste à figer la langue de génération dans la configuration du plugin, sans tenir compte du fait que WordPress calcule cette valeur dynamiquement, requête par requête, selon plusieurs facteurs qui peuvent varier d’un site multilingue à l’autre.

Ce que fait réellement determine_locale

Le filtre determine_locale intervient au moment où WordPress détermine la locale à utiliser pour la requête en cours. Sa valeur par défaut provient du réglage général du site, mais elle peut être modifiée par des extensions de gestion multilingue, ou par des paramètres de requête spécifiques dans l’administration.

add_filter( 'determine_locale', function ( string $locale ): string {
    if ( is_admin() && isset( $_GET['locale'] ) ) {
        return sanitize_text_field( wp_unslash( $_GET['locale'] ) );
    }
    return $locale;
} );

Un agent qui ignore ce filtre et se contente de lire l’option WPLANG directement obtiendra une valeur qui ne reflète pas nécessairement la langue réellement appliquée à la requête en cours, notamment sur un site utilisant une extension de traduction qui modifie la locale par sous-domaine ou par préfixe d’URL.

Lire la locale effective avant de générer un texte

La fonction determine_locale(), sans argument, retourne directement la valeur calculée après application de tous les filtres enregistrés. C’est cette valeur, et non une lecture d’option, qu’un agent doit transmettre au modèle de langage dans sa consigne système :

L'essentiel à retenir : determine_locale fixe la langue effective de la requête ; Un agent doit lire cette valeur avant de générer du texte ; Ignorer ce filtre produit des contenus dans la mauvaise langue
function construire_consigne_langue(): string {
    $locale = determine_locale();
    $langue = locale_get_display_language( $locale, 'fr' );

    return sprintf(
        'Réponds exclusivement en %s. N\'utilise aucune autre langue, y compris dans les titres.',
        $langue ?: $locale
    );
}

Le cas des sites multilingues avec agent transversal

Sur un site où plusieurs langues cohabitent, un agent qui traite des contenus provenant de sections différentes doit rappeler cette lecture à chaque tâche plutôt que la mémoriser une seule fois au démarrage. La locale peut changer d’une requête à l’autre, y compris au sein d’une même session d’administration, si l’agent traite successivement des contenus rattachés à des langues différentes.

Distinguer locale de site et locale d’affichage utilisateur

WordPress distingue la locale générale du site de la locale propre à chaque compte utilisateur, réglable individuellement dans son profil. Le filtre determine_locale peut être complété d’une lecture de get_user_locale() lorsque l’agent produit un contenu destiné à l’interface d’administration plutôt qu’au contenu public du site :

  • determine_locale() pour le contenu public généré (articles, descriptions)
  • get_user_locale() pour les messages d’interface adressés à l’utilisateur connecté
  • Ne jamais mélanger les deux sans distinction dans la consigne envoyée au modèle

Erreur fréquente : coder la langue en dur dans le prompt système

Un prompt système qui contient littéralement « réponds en français » fonctionne tant que le site reste monolingue, puis produit des contenus dans la mauvaise langue dès qu’une extension de traduction change la locale sans que le code du plugin en soit informé. La lecture dynamique via determine_locale() évite cette dépendance implicite.

Un agent qui génère du texte sans interroger la locale effective de la requête suppose, à tort, que le site restera toujours dans une seule langue.

Ce qu’il faut retenir

Le filtre determine_locale reste la source de vérité pour connaître la langue attendue d’une requête WordPress. Un agent qui génère du texte gagne à lire cette valeur systématiquement, plutôt qu’à la déduire d’une configuration statique, particulièrement sur les sites où la gestion multilingue introduit une logique de détermination de langue plus complexe qu’un simple réglage général.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Partager :

À propos de l'auteur

WordPress Développement

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

Voir tous ses articles

Dans la même veine

À lire aussi