L’Abilities API, introduite dans l’écosystème WordPress fin 2025 pour permettre à des agents logiciels d’interroger et d’agir sur un site de façon structurée, a été mise en place sur un site vitrine multilingue pour exposer une capacité précise : consulter la disponibilité d’un service de réservation via un agent conversationnel tiers. La capacité fonctionnait techniquement, mais sa description — le texte qui explique à l’agent ce que fait cette capacité et comment l’utiliser — restait figée en français, quelle que soit la langue dans laquelle l’agent lui-même interrogeait le site.
Ce détail, facile à négliger tant l’attention se porte naturellement sur la logique fonctionnelle de la capacité elle-même, a un effet concret : un agent configuré pour interagir en anglais avec le site recevait malgré tout une description en français, ce qui dégradait sa capacité à comprendre correctement l’usage prévu de cette fonctionnalité.
Ce que décrit une capacité, et pourquoi son texte compte
Une capacité déclarée via l’Abilities API comporte un identifiant technique stable, mais aussi une description en langage naturel, destinée à être lue et interprétée par un agent — souvent lui-même un grand modèle de langage — pour décider quand et comment invoquer cette capacité. Contrairement à un simple point d’accès d’API classique, la qualité et la clarté de cette description influencent directement la pertinence de son utilisation par l’agent appelant.
Ce texte descriptif est donc, d’un point de vue fonctionnel, comparable à un contenu éditorial à part entière : il mérite le même soin de traduction qu’un intitulé de bouton ou qu’un message d’erreur affiché à un visiteur humain, même si son lecteur final n’est pas une personne mais un système automatisé.
La configuration d’origine, et pourquoi elle ne traduisait rien
wp_register_ability('exemple/disponibilite-reservation', [
'label' => 'Vérifier une disponibilité',
'description' => 'Vérifie les créneaux disponibles pour une date donnée.',
'input_schema' => [ /* ... */ ],
'output_schema' => [ /* ... */ ],
'execute_callback' => 'exemple_verifier_disponibilite',
]);
Le label et la description étaient codés en dur, sans passer par les fonctions de traduction standards de WordPress, exactement comme un texte de thème non internationalisé resterait figé en une seule langue. Aucune extension multilingue, Polylang ou WPML, ne peut intercepter et proposer la traduction d’une chaîne qui ne transite jamais par le mécanisme d’internationalisation natif.
La correction : internationaliser comme n’importe quel texte de thème
La correction a consisté à appliquer exactement les mêmes principes que pour toute chaîne de texte de thème ou d’extension, en utilisant les fonctions de traduction natives, puis en laissant WPML capturer ces chaînes via son module de traduction de thèmes et plugins comme pour n’importe quel autre texte du site.
wp_register_ability('exemple/disponibilite-reservation', [
'label' => __('Vérifier une disponibilité', 'mon-domaine-texte'),
'description' => __(
'Vérifie les créneaux disponibles pour une date donnée.',
'mon-domaine-texte'
),
'input_schema' => [ /* ... */ ],
'output_schema' => [ /* ... */ ],
'execute_callback' => 'exemple_verifier_disponibilite',
]);
Une question distincte se pose alors, propre à ce contexte : dans quelle langue cette description doit-elle être servie à l’agent appelant ? Contrairement à un visiteur humain, dont la langue se déduit de sa navigation sur une URL précise, un agent peut interroger le site via un point d’accès générique, sans contexte de langue explicite dans l’URL consultée.
Déterminer la langue à servir à un agent
La solution retenue s’appuie sur l’en-tête HTTP Accept-Language, envoyé par la plupart des agents bien configurés, combiné à un filtre appliqué juste avant la récupération de la description de capacité, pour forcer temporairement la langue active de Polylang ou WPML en fonction de cet en-tête plutôt que de la langue par défaut du site.
add_filter('wp_ability_description', function ($description, $ability_name) {
$langue_demandee = accept_language_vers_code_polylang(
$_SERVER['HTTP_ACCEPT_LANGUAGE'] ?? ''
);
if ($langue_demandee && function_exists('pll_switch_language')) {
pll_switch_language($langue_demandee);
}
return $description;
}, 10, 2);
Cette approche reste simple, mais elle exige un test rigoureux : un agent qui n’envoie pas d’en-tête Accept-Language explicite reçoit la description dans la langue par défaut du site, un comportement de repli à documenter clairement pour les intégrateurs tiers qui consomment cette capacité.
Une capacité exposée à un agent reste, avant tout, un texte destiné à être compris. La traiter comme un simple paramètre technique sans se soucier de sa traduction revient à livrer une documentation à moitié rédigée.
Un point de vigilance propre à ce contexte encore jeune
L’Abilities API restant une addition récente à l’écosystème WordPress, les bonnes pratiques autour de son internationalisation ne sont pas encore stabilisées à l’échelle de la communauté, contrairement aux conventions bien établies pour les chaînes de thème classique. La documentation officielle sur le site des développeurs WordPress reste la référence à suivre en priorité, à mesure que ces conventions se précisent.
En résumé
Exposer une capacité à un agent via l’Abilities API ne dispense d’aucune des règles habituelles d’internationalisation d’un site WordPress : le texte descriptif reste un contenu à traduire comme un autre. La seule question réellement nouvelle posée par ce contexte concerne la détection de la langue à servir en l’absence d’URL de navigation classique, un problème résolu ici via l’en-tête HTTP envoyé par l’agent appelant.
