Constat technique de départ : la version française d’un bloc d’accroche affiche bien son titre personnalisé, mais la version espagnole de la même page affiche le titre… français, alors que la traduction avait été validée deux semaines plus tôt dans l’éditeur de traduction avancé de WPML. Aucun message d’erreur, aucune entrée suspecte dans les journaux : juste une chaîne qui semble être revenue en arrière toute seule.
Le déclencheur identifié après investigation : une synchronisation manuelle des types de contenus personnalisés, lancée par l’équipe éditoriale depuis WPML → Traduction de contenu personnalisé pour resynchroniser un modèle de page modifié. Cette opération, censée être sans risque, a réécrit l’attribut de titre du bloc avec sa valeur source, écrasant la traduction espagnole existante.
Comment WPML traduit réellement un attribut de bloc
WPML ne traduit pas le contenu sérialisé d’un bloc tel quel : il extrait, via la configuration déclarée dans wpml-config.xml, les attributs identifiés comme traduisibles, les enregistre comme des chaînes indépendantes dans sa propre base de traduction (String Translation), puis les réinjecte dans l’attribut au moment de l’affichage de la version traduite. Cette déclaration ressemble à ceci pour un bloc personnalisé :
<wpml-config>
<blocks>
<block type="acme/accroche">
<field name="title" translate="1" />
<field name="subtitle" translate="1" />
</block>
</blocks>
</wpml-config>
Le mécanisme fonctionne en deux temps distincts : une extraction des chaînes (déclenchée à l’enregistrement de la page source), puis une réinjection (déclenchée à l’affichage ou à la synchronisation de la page traduite). C’est précisément entre ces deux temps que l’incident s’est produit.
Le problème d’ordre exact
La synchronisation de contenu personnalisé, quand elle est déclenchée manuellement sur un modèle déjà traduit, réexécute l’extraction des chaînes à partir de la page source avant de vérifier si des traductions existantes doivent être conservées. Dans certaines versions de WPML antérieures à un correctif publié en 2023, ce réordonnancement provoquait une réinjection de la valeur source dans l’attribut de la page traduite, écrasant la chaîne traduite alors même que celle-ci restait présente et intacte dans la table icl_string_translations.
Autrement dit : la traduction espagnole n’était pas perdue au sens strict — elle existait toujours dans la base de String Translation — mais elle n’était plus reliée correctement à l’attribut du bloc affiché, à cause d’un identifiant de chaîne (string_id) mal réconcilié pendant la synchronisation.
Le correctif appliqué
- Vérifier, via WPML → Traduction de chaînes, que la chaîne espagnole existe toujours pour l’attribut concerné : elle était bien présente, confirmant l’hypothèse d’un problème de liaison plutôt que de perte de données.
- Forcer une réextraction propre des chaînes du bloc en resauvegardant la page source (bouton Mettre à jour), qui régénère un identifiant de synchronisation cohérent.
- Relancer la synchronisation de contenu personnalisé après cette resauvegarde, et non avant, pour que WPML réconcilie les chaînes existantes plutôt que d’en extraire de nouvelles en doublon.
- Mettre à jour l’extension WPML String Translation vers la version corrigeant ce comportement d’ordonnancement, disponible depuis la mise à jour de fin d’année 2023.
Fiabiliser durablement la déclaration de traduction
Au-delà du correctif ponctuel, la configuration wpml-config.xml du bloc a été revue pour limiter la fragilité de ce mécanisme :
- Ne déclarer traduisibles que les attributs réellement destinés à contenir du texte affiché, jamais des identifiants techniques ou des références internes.
- Éviter de synchroniser manuellement le contenu personnalisé en dehors des fenêtres de maintenance planifiées, pour limiter le risque d’écraser une traduction en cours de relecture.
- Conserver un export régulier des chaînes traduites via WPML → Traduction de chaînes → Exporter, qui sert de filet de sécurité indépendant de la table interne de WPML.
Face à une traduction qui semble avoir disparu, je vérifie toujours en premier si la chaîne existe encore côté String Translation avant de conclure à une perte de données : dans l’immense majorité des cas, c’est un problème de liaison, pas de suppression.
En résumé
Ce type d’incident illustre une limite structurelle des systèmes de traduction construits par-dessus l’éditeur de blocs plutôt qu’à l’intérieur : la traduction d’un attribut de bloc dépend d’un identifiant de synchronisation externe à Gutenberg, que toute opération de resynchronisation risque de réécrire dans le mauvais ordre. La parade la plus fiable reste de resauvegarder systématiquement la page source juste avant toute synchronisation manuelle de contenu personnalisé.
