# Des chaînes JavaScript non traduites dans l’éditeur malgré un fichier JSON

> Le fichier de traduction JSON du bloc existe, il est même correctement rempli, et pourtant l'éditeur continue d'afficher les chaînes en anglais. Voici pourquoi.

- Auteur : WordPress Développement
- Publié le : 2020-09-05
- Mis à jour le : 2020-09-05
- Catégorie : Multilingue
- URL : https://www.wpmoderne.fr/multilingue/chaines-js-non-traduites-editeur-json/

## L’essentiel

- Le fichier JSON doit porter un nom précis, calculé par un hash
- Le script doit être enregistré avant d'être associé à ses traductions
- Le domaine de texte doit correspondre exactement partout

Un bloc personnalisé fonctionne parfaitement côté rendu final : le texte affiché aux visiteurs est bien en français, grâce à des appels classiques à `__()` côté PHP. Mais dans l'éditeur, les libellés des contrôles, les info-bulles et les messages du panneau latéral restent obstinément en anglais. Le développeur vérifie, un fichier `fr_FR-mon-bloc.json` existe bel et bien dans le dossier `languages/` du thème, rempli avec les bonnes traductions.

Ce cas revient régulièrement dès qu'un thème ou une extension embarque des blocs personnalisés avec du JavaScript traduit via les fonctions de l'API `wp.i18n`. Le fichier JSON existe, il est syntaxiquement valide, et pourtant l'éditeur ne va jamais le chercher. Le problème vient presque toujours du nom de fichier attendu, pas de son contenu.

## Symptôme : traductions ignorées silencieusement

Côté JavaScript, le bloc utilise l'API de traduction de la même façon que n'importe quel script du cœur :

```
import { __ } from '@wordpress/i18n';

const label = __( 'Choisir une mise en page', 'mon-bloc' );
```

Aucune erreur dans la console. Aucun message dans les journaux PHP. Le navigateur charge bien le fichier JavaScript compilé, mais le libellé reste affiché tel quel, en anglais, comme si aucune traduction n'était disponible pour ce domaine de texte.

## Diagnostic : un nom de fichier calculé, pas choisi librement

La fonction `wp_set_script_translations()` ne cherche pas un fichier au nom arbitraire. Elle construit un nom précis à partir du handle du script, en lui appliquant une empreinte MD5 du chemin du fichier source. Le format réel ressemble à `fr_FR-a1b2c3d4e5f6.json`, où la partie hexadécimale dépend du chemin exact du fichier `.js` enregistré, pas du nom du bloc lui-même.

Le fichier créé manuellement, nommé d'après une convention plus intuitive comme `fr_FR-mon-bloc.json`, ne correspond donc jamais à ce que le script va réellement chercher. La génération correcte du fichier passe par l'outil en ligne de commande fourni par le paquet `@wordpress/i18n`, ou par WP-CLI avec la commande `wp i18n make-json`, qui calcule elle-même le bon nom de fichier à partir du `.pot` et des chemins réels des scripts.

> L'essentiel à retenir : Le fichier JSON doit porter un nom précis, calculé par un hash ; Le script doit être enregistré avant d'être associé à ses traductions ; Le domaine de texte doit correspondre exactement partout

## Correctif : régénérer le fichier avec l'outil adapté

La commande WP-CLI suivante régénère les fichiers JSON avec le bon nommage, à partir des chaînes déjà présentes dans le fichier .po :

```
wp i18n make-json languages/ --no-purge
```

Cette commande produit un ou plusieurs fichiers JSON par script traduit, en respectant l'algorithme de hachage attendu par `wp_set_script_translations()`. Il faut ensuite vérifier que l'enregistrement du script précède bien l'appel qui lui associe les traductions :

```
wp_register_script(
    'mon-bloc-editor',
    plugins_url( 'build/index.js', __FILE__ ),
    array( 'wp-blocks', 'wp-i18n', 'wp-element' ),
    filemtime( plugin_dir_path( __FILE__ ) . 'build/index.js' )
);

wp_set_script_translations(
    'mon-bloc-editor',
    'mon-bloc',
    plugin_dir_path( __FILE__ ) . 'languages'
);
```

Le deuxième argument, le domaine de texte, doit être rigoureusement identique à celui utilisé dans les appels à `__()` côté JavaScript. Une simple différence de tiret ou de casse suffit à faire échouer silencieusement l'association, sans le moindre message d'erreur visible.

## Prévention : automatiser la génération à chaque build

Le point de fragilité principal reste la régénération manuelle du fichier JSON à chaque modification du code source. Une équipe qui oublie cette étape après avoir renommé un fichier JavaScript se retrouve avec un fichier JSON orphelin, dont le hash ne correspond plus au nouveau chemin.

- Intégrer la commande `wp i18n make-json` dans le script de build du projet, pas seulement en exécution manuelle ponctuelle.
- Vérifier après chaque renommage de fichier source que le hash du nom JSON a bien changé en conséquence.
- Contrôler le domaine de texte des deux côtés, PHP et JavaScript, en cas de nouvelle chaîne ignorée.

> Un réflexe simple avant de chercher plus loin : ouvrir l'onglet réseau du navigateur et vérifier que le fichier JSON attendu est bien chargé avec un code 200, plutôt qu'une erreur 404 silencieuse.

## En résumé

Ce type de panne se règle en quelques minutes une fois la cause identifiée, mais elle égare longtemps un développeur qui cherche du côté du contenu du fichier plutôt que de son nom. Le mécanisme de traduction des scripts de blocs repose sur une convention de nommage stricte, que seuls les outils officiels savent respecter correctement. Éditer un fichier JSON à la main, sans passer par la génération automatique, revient presque toujours à produire un fichier que rien n'ira jamais lire.