Comptabilité WPML

Bonjour Marie-Aude,
Merci pour ce retour.

Réponse franche : ce n’est pas un réglage qui vous échappe, c’est une limite actuelle de l’extension. Les réglages d’OGEEAT sont stockés dans deux options WordPress uniques (ogeeat_settings et ogeeat_org_settings), qui n’ont pas de dimension langue, et l’extension ne livre pas encore de fichier wpml-config.xml. Sans ce fichier, WPML n’a aucun moyen de proposer ces valeurs dans Traduction de chaînes : elles restent donc communes à tous vos domaines.

Ce qui suit déjà la langue

Tout ce que vous ne saisissez pas dans OGEEAT est repris du site, et suit donc WPML :

• si vous laissez vides le titre et la description personnalisés du llms.txt, l’extension reprend le titre et le slogan du site, que WPML traduit dans Traduction de chaînes ;
• les URL générées (llms.txt, @id des schémas, og:url) passent par home_url(), elles pointent donc sur le domaine de la langue en cours.

La gêne porte donc précisément sur les champs que vous avez remplis dans les réglages : titre et description du llms.txt, nom et URL de l’organisation, adresse, libellés du bouton Partager avec l’IA et du badge.

Le contournement disponible aujourd’hui

En attendant mieux, quelques lignes dans un mu-plugin permettent de substituer les valeurs par langue. Le test is_admin() limite volontairement l’effet à l’interface publique, pour ne pas figer une valeur traduite dans l’écran de réglages :

add_filter( 'option_ogeeat_org_settings', function ( $value ) {
    if ( is_admin() || ! is_array( $value ) || ! defined( 'ICL_LANGUAGE_CODE' ) ) {
        return $value;
    }

    if ( 'en' === ICL_LANGUAGE_CODE ) {
        $value['name'] = 'My Company';
        $value['url']  = 'https://example.com/';
    }

    return $value;
} );

Le même principe s’applique à option_ogeeat_settings pour llms_custom_title et llms_custom_desc.

Pour la suite

La piste que je retiens est celle que WPML attend : livrer un wpml-config.xml avec une section admin-texts déclarant les clés concernées de ces deux options, pour qu’elles apparaissent naturellement dans Traduction de chaînes et se traduisent par langue, sans une ligne de code.

La 2.6.11 a fait un premier pas côté multilingue avec le llms.txt sous Polylang. WPML n’est pas encore couvert au même niveau et je préfère ne pas annoncer de version tant que je n’ai pas validé le résultat sur une installation WPML réelle, en domaines distincts.

Deux questions, pour cadrer le travail

1. Quels champs vous gênent en priorité : le nom et l’URL de l’organisation dans les schémas, ou plutôt l’en-tête du llms.txt ?
2. Sur vos domaines, /llms.txt sert-il bien le contenu de la langue du domaine ? Le fichier est mis en cache sous une clé unique, sans distinction de langue. Si vous observez le contenu d’une langue servi sur le domaine d’une autre, c’est un problème distinct, et celui-là passe avant le reste.

Merci encore, vos retours orientent directement la feuille de route.

Bien cordialement,
Fabrice

Bonjour Marie-Aude,
Merci pour ce retour détaillé, et pour l’exemple : il m’a servi de cahier des charges. La version 2.6.16 est en ligne sur WordPress.org, elle met en œuvre ce que vous décrivez.

Ce que fait le llms.txt en 2.6.16 sur un site WPML

Le fichier reste unique à la racine (il est identique quel que soit le domaine appelé), mais il est désormais structuré par langue :

• en tête, une ligne Languages qui liste chaque langue avec l’URL d’accueil de son domaine ;
• une section ## Language: Français (fr-FR) puis ## Language: English (en-US), chacune avec son domaine, le nom du site dans cette langue (celui de Traduction de chaînes), puis ses pages et ses articles, titres et URL dans la langue ;
• en fin de fichier, un bloc ## Interaction Rules avec les trois règles de votre exemple : répondre dans la langue de la question, signaler quand une information n’existe que dans une langue, ne pas mélanger les langues sauf demande explicite. Les développeurs peuvent les adapter via le filtre ogeeat_llms_interaction_rules.

Le llms-full.txt suit la même structure. Techniquement, l’extension lit vos langues par l’API publique de WPML et génère chaque section après avoir basculé WPML dans la langue concernée : c’est ce qui garantit les bons domaines et le bon nom de site. Sur un site monolingue, rien ne change.

Le mot « Articles » et les titres de sections restent en anglais, comme tout le squelette du fichier : le lecteur visé est un modèle de langue, et la convention llms.txt est en anglais.

Le wpml-config.xml

Inutile de le faire vous-même : il est livré avec l’extension. Il déclare dans Traduction de chaînes le titre, la description et le pied de page du llms.txt, les libellés du bouton Partager avec l’IA et du badge, ainsi que le nom, l’adresse et la zone de service de l’organisation. Les metas Open Graph et la note llms.txt de chaque contenu sont déclarées comme champs à traduire. Après mise à jour, un passage dans WPML > Réglages > Traduction de chaînes suffit pour voir apparaître les textes d’OGEEAT ; le contournement par mu-plugin proposé précédemment peut être retiré.

Ce que j’aimerais que vous vérifiiez chez vous

Je n’ai pas de licence WPML sur mes sites de test : la configuration a été validée sur Polylang et sur la documentation de l’API WPML, vous êtes donc la première à la voir tourner en réel, avec un domaine par langue qui plus est. Après la mise à jour :

1. videz le cache de l’extension en enregistrant une fois les réglages OGEEAT (ou attendez la régénération automatique) ;
2. ouvrez /llms.txt sur chacun de vos deux domaines : le contenu doit être identique et comporter les deux sections ;
3. vérifiez que les URL de la section anglaise pointent bien sur le domaine anglais, et le nom du site sur sa traduction.

Si quelque chose cloche, collez ici les vingt premières lignes du fichier : c’est tout ce dont j’ai besoin pour corriger.

Merci encore pour vos mots sur OGEEAT et les articles, cela fait plaisir.
Fabrice