Délimiter ce qui reste en anglais
Vous avez téléchargé le pack français et un bouton de l’extension affiche toujours « Review draft ». Relevez ce libellé exact et son emplacement. Un menu du tableau de bord, un bouton qui apparaît dans l’éditeur après quelques secondes et un message sur la page publique peuvent être produits par des composants différents. Notez aussi la version de l’extension, celle de WordPress et le code de langue visé. Faites une capture limitée au libellé si vous devez transmettre le cas au mainteneur.
Sur le même écran, comparez un texte fourni par WordPress, comme le libellé d’une rubrique standard, et deux textes provenant de l’extension. Si tout le tableau de bord est en anglais pour un seul compte, commencez par son profil. Si le tableau de bord est en français et que tous les textes d’une extension restent en anglais, vérifiez son catalogue. Si un seul bouton est en anglais, la version de ce texte, son contexte ou le script qui le rend deviennent des pistes plus précises. Gardez un exemple d’une chaîne traduite de la même extension. Elle sert de témoin lorsque vous faites une modification.
Certains textes sont déjà saisis ou enregistrés dans les réglages de l’extension. Ouvrez le champ correspondant si vous le trouvez, par exemple le libellé d’un bouton de formulaire que quelqu’un a saisi. Le texte peut être une valeur éditoriale enregistrée en anglais alors que les menus de l’extension se traduisent correctement. Dans ce cas, changez la valeur à son emplacement prévu, relevez l’ancienne et ouvrez la page publique pour vérifier la sortie. Un champ qui accepte un texte par langue doit être renseigné pour la version française. Le téléchargement d’un catalogue agit sur les chaînes prévues pour la traduction.
Approche 1 — Comparer la langue du compte et celle du site
Commencez par ce parcours si le problème touche un compte, un écran précis ou une installation dont le site public et le tableau de bord n’ont pas la même langue. Chaque personne peut vérifier son profil dans **Utilisateurs → Profil**. Un administrateur peut également vérifier le réglage général du site dans **Réglages → Général → Langue du site**. Si vous travaillez sur un réseau, relevez le sous-site qui sert l’écran ou l’URL, puis contrôlez sa langue.
Pour la demande d’administration ordinaire, WordPress choisit généralement la langue du compte. Pour une page publique ordinaire, la langue du site sert de base. Un appel REST, un commutateur de langue ou une extension peut choisir un autre contexte. Si le problème apparaît après une interaction sans rechargement, relevez l’adresse de la page et repérez si l’interaction lance une requête. Une vérification de la page initiale ne suffit pas toujours à déterminer la langue de cette requête.
Le résultat attendu après un changement de profil est la traduction des chaînes disponibles pour ce compte. Si le test n’explique pas l’écart, remettez le choix de profil d’origine et passez à la vérification du catalogue. Modifiez la langue du site uniquement si c’est la langue attendue pour le site entier. Avant cette modification, notez la valeur de départ et vérifiez les autres écrans et pages concernés. Rétablissez cette valeur si le changement dépasse la portée voulue.
- Ouvrez votre profil et relevez la valeur du champ **Langue**. Un choix explicite comme English (United States) peut conserver l’administration en anglais alors que la langue du site est le français. Le choix de la langue par défaut du site suit le réglage du site.
- Si le tableau de bord doit être en français pour votre compte, choisissez le français ou la langue par défaut si le site est déjà en français. Enregistrez le profil, rechargez l’écran exact de l’extension et vérifiez le libellé témoin.
- Demandez à un second compte avec des droits comparables d’ouvrir le même écran. Gardez la même extension, le même sous-site et la même version. Une différence entre les deux comptes vous aide à localiser l’effet du profil.
- Ouvrez la page publique dans une fenêtre privée. Comparez le même emplacement en session anonyme et, si cela fait partie du problème, avec le compte connecté. Notez l’adresse et la langue sélectionnée sur les sites qui proposent un sélecteur.
Vérifier la langue exacte du pack et son emplacement
Les fichiers sont associés à un code de locale. Le français de France utilise fr_FR et le français du Canada fr_CA. Relevez la variante choisie par la requête ou par le profil. La présence d’un pack français quelconque ne garantit pas qu’il existe pour la variante demandée. Si le français de France est acceptable pour ce compte, le choisir sur la copie permet une comparaison. Si le site doit rester en français canadien, vérifiez ce que l’éditeur fournit pour fr_CA.
Dans **Tableau de bord → Mises à jour**, vérifiez si WordPress propose des mises à jour de traductions. Avec un compte habilité et sur une copie, lancez la mise à jour disponible puis reprenez le même écran. Pour une extension du répertoire WordPress, identifiez précisément sa fiche et sa version. Pour une extension distribuée ailleurs, vérifiez la documentation de l’éditeur et la version du fichier livré. Deux extensions de noms proches peuvent utiliser des domaines différents. Le nom visible de l’extension sert à retrouver la fiche, puis le domaine de texte identifie le catalogue que le code demande.
Avec accès aux fichiers, commencez par wp-content/languages/plugins/ sur une installation standard. Pour le domaine fictif atelier32-localisation et la locale fr_FR, le test a utilisé atelier32-localisation-fr_FR.mo. WordPress récent peut aussi charger un fichier .l10n.php. Une extension peut fournir ses catalogues dans son propre dossier si elle déclare ou enregistre le chemin prévu. Si l’installation personnalise le dossier des langues, partez de la valeur de WP_LANG_DIR. Pour déterminer quel fichier a servi à l’écran, observez le chargement au lieu de conclure d’après la seule liste des fichiers.
Un fichier .po permet de lire ou de préparer les traductions. Une présence exclusive de ce fichier ne suffit pas au chargement PHP normal. Contrôlez que le fichier attendu est lisible par WordPress et correspond à la version installée. Un pack téléchargé avant l’ajout d’un bouton peut contenir presque toute l’interface et manquer justement ce bouton. Comparez alors le texte anglais exact, sa ponctuation et, si la chaîne utilise un contexte, le contexte indiqué dans le code. La version du catalogue et le texte témoin permettent de vérifier une correction après une mise à jour.
Sur une copie, Loco Translate peut servir à ouvrir le catalogue et à rechercher la chaîne exacte avec sa ponctuation. Comparez le domaine et la locale affichés avec ceux que vous venez de relever. Si la chaîne est absente ou si son champ de traduction est vide, gardez ce constat avant toute modification. Pour une chaîne déjà traduite dans le fichier, reprenez le diagnostic de chargement ci-dessous. L’essai de ce guide vérifie le chargement natif de WordPress.
Approche 2 — Observer le domaine dans la requête concernée
Ce parcours est destiné à la personne qui maintient l’extension ou qui dispose d’un accès aux fichiers et aux journaux d’une copie locale. Demandez-lui de retrouver le texte anglais dans le code livré. Dans un appel PHP tel que __('Review draft', 'atelier32-localisation'), le second argument est le domaine demandé. Comparez-le au champ Text Domain de l’extension et au nom du catalogue. Si le domaine de l’appel est différent, WordPress cherche la traduction dans cet autre domaine. Un fichier lisible qui contient bien « Review draft » pour le premier domaine ne résout pas ce décalage.
L’exemple ci-dessous lit la locale et les tentatives de chargement PHP pour un seul domaine. Sur une copie déclarée locale via WP_ENVIRONMENT_TYPE, enregistrez le code dans wp-content/mu-plugins/atelier32-trace.php. Créez le dossier s’il manque et remplacez atelier32-localisation par le domaine à examiner. Utilisez le journal PHP privé de la copie. Ajoutez trace_locale=1 à l’URL de l’écran concerné en conservant les paramètres existants, puis rechargez avec le compte qui voit la chaîne anglaise. Si le libellé arrive via une requête séparée, ce relevé porte uniquement sur la requête à laquelle le marqueur a été ajouté.
Comparez site, compte et requete dans la ligne de bilan. Cherchez les lignes de fichier avec la locale attendue. Une ligne qui mentionne un fichier illisible ou absent décrit une tentative. Vous pouvez en voir une pour .l10n.php, suivie d’une lecture réussie du fichier .mo. Le champ charge indique l’état du domaine en fin de requête. Il ne confirme pas que le catalogue contenait la traduction de cette chaîne. Retirez le fichier de diagnostic après la comparaison et rechargez la page pour vérifier que la trace ne se répète plus.
<?php
if (wp_get_environment_type() !== 'local' || ($_GET['trace_locale'] ?? '') !== '1') {
return;
}
$domain = 'atelier32-localisation';
add_filter('load_translation_file', static function ($file, $current, $locale) use ($domain) {
if ($current === $domain) {
error_log('atelier-locale fichier ' . wp_json_encode([
'locale' => $locale,
'fichier' => basename($file),
'lisible' => is_readable($file),
]));
}
return $file;
}, 10, 3);
add_action('shutdown', static function () use ($domain) {
error_log('atelier-locale bilan ' . wp_json_encode([
'site' => get_locale(),
'compte' => is_user_logged_in() ? get_user_locale() : null,
'requete' => determine_locale(),
'charge' => is_textdomain_loaded($domain),
]));
});Corriger selon la preuve obtenue
Si la locale de la requête ne correspond pas au pack, reprenez le réglage de langue approprié. Une installation peut comporter un sélecteur de langue ou un filtre ajouté par une extension. Comparez l’écran et la requête avec ces réglages sur une copie. Si plusieurs équipes utilisent l’administration dans des langues différentes, gardez les préférences individuelles et corrigez seulement celle du compte concerné. Les autres comptes doivent continuer à voir leur langue choisie.
Si la locale et le domaine sont corrects mais que le fichier attendu manque, installez le catalogue correspondant par la mise à jour des traductions ou par le mécanisme documenté par l’éditeur. Pour une extension maison qui livre ses fichiers dans un dossier spécifique, le développeur peut enregistrer le chemin avec load_plugin_textdomain() à partir de init, avant d’utiliser les chaînes traduites dans les actions qui les rendent. Pour un domaine distribué et chargé automatiquement depuis le dossier standard, une déclaration supplémentaire n’est généralement pas nécessaire. Sur WordPress récent, une traduction déclenchée trop tôt peut aussi produire un message signalant un chargement prématuré. Si ce message nomme le domaine, relevez où la chaîne est calculée et déplacez son évaluation vers un moment adapté, comme la construction effective de l’écran.
Si la langue est correcte et le domaine chargé, cherchez la chaîne exacte dans le catalogue et comparez-la au code installé. Une chaîne avec un contexte, une forme plurielle ou des paramètres doit avoir l’entrée qui lui correspond. Lorsque le domaine du code diffère, le développeur peut le corriger sur la branche maintenue et reconstruire le catalogue si nécessaire. Pour une extension d’un éditeur tiers, transmettez le libellé, le code de langue, la version et le résultat de la comparaison des deux comptes. Une modification manuelle dans le dossier du fournisseur risque d’être écrasée à la prochaine mise à jour. Si vous utilisez un emplacement de surcharge pris en charge par l’éditeur, conservez l’original et rétablissez-le si la correction touche d’autres chaînes.
Vérifier si la chaîne vient du navigateur
Si les menus PHP se traduisent et que seul un panneau interactif reste en anglais, notez à quel moment apparaît le texte. Retrouvez, avec l’aide du mainteneur si nécessaire, le script qui rend ce panneau et son identifiant d’enregistrement dans WordPress. Les chaînes JavaScript internationalisées par WordPress utilisent leurs propres catalogues JSON. Le script doit demander le bon domaine. Côté PHP, wp_set_script_translations() associe des traductions à un script déjà enregistré. Un catalogue PHP fonctionnel peut donc coexister avec une traduction JavaScript manquante ou attachée au mauvais script.
Sur la copie, comparez l’identifiant enregistré, le domaine du code JavaScript et la locale réellement utilisée. Vérifiez ensuite qu’un catalogue JSON existe pour le script distribué. Quand l’extension embarque les scripts compilés, assurez-vous que ses traductions correspondent aux fichiers de cette version. Dans le navigateur, examinez les ressources chargées et le HTML qui initialise les traductions. Le JSON peut avoir été injecté dans la page par WordPress. L’absence d’une requête réseau séparée vers un fichier JSON ne suffit donc pas à établir une panne.
Après correction, rechargez l’écran dans le même compte, puis déclenchez de nouveau l’interaction qui affichait le texte. Comparez aussi une chaîne PHP qui fonctionnait déjà. Si seul un navigateur continue à charger l’ancienne version du script, vérifiez la version servie et son cache avant de modifier le pack une deuxième fois. Si l’interaction reçoit directement un texte anglais dans la réponse d’une requête, examinez la locale de cette requête et le code côté serveur. Pour revenir en arrière, restaurez l’association précédente du script et son catalogue, puis reprenez le contrôle sur le même écran.
Refaire le test avec un libellé qui sert de témoin
Sur une copie de WordPress 7.1.4, une extension fictive a déclaré le domaine atelier32-localisation. Un véritable catalogue binaire .mo a fourni une seule traduction. La langue du site était fr_FR. Dans le contexte d’administration, un compte réglé sur en_US a obtenu « Review draft » alors que le compte réglé sur fr_FR et celui qui suivait la langue du site ont obtenu « Relire le brouillon ». Sur la partie publique simulée, le contexte est resté français en anonyme et avec le compte dont le profil était en anglais.
Dans la requête française, la trace a d’abord signalé la tentative de lecture d’un fichier .l10n.php absent, puis la lecture du .mo présent. Le bilan a confirmé le chargement du domaine. Le même libellé appelé avec un domaine fictif différent est resté anglais, de même qu’un second libellé qui ne figurait pas dans le catalogue. Après retrait du pack, le libellé principal est redevenu anglais avec le même compte français. Les essais ont utilisé le moteur PHP de WordPress et des contextes de requête préparés pour la recette. Le parcours JavaScript repose sur la documentation de l’API des scripts.
Pour refaire la comparaison sur votre installation de test, choisissez un texte court dont vous connaissez la traduction. Relevez son résultat dans le compte en cause, dans un compte français qui a accès au même écran et sur le site public s’il y existe. Modifiez ensuite une seule chose. Après un changement de profil, le libellé traduit doit suivre la nouvelle langue sur l’écran du compte. Après la correction d’un catalogue, la requête déjà française doit continuer de l’être et afficher la traduction du témoin. Vérifiez aussi un second texte de l’extension qui fonctionnait avant l’intervention.
Une fois le résultat obtenu, retirez l’instrumentation et remettez les réglages de test à leur valeur d’origine. Conservez un relevé court pour l’équipe qui fait les mises à jour. Notez la version de l’extension, le domaine, la locale, l’écran et le nom du catalogue retenu. Si un nouveau libellé reste en anglais après une prochaine mise à jour, ce relevé permet de vérifier si le code a changé, si le pack couvre la nouvelle version ou si le problème se limite à un autre script.
