Duplicate Post et Polylang : le conflit qui crée des traductions fantômes

« Pourquoi cet article traduit pointe-t-il vers un contenu qui n’a jamais été écrit ? » C’est la question que pose l’équipe éditoriale quand elle tombe, dans le sélecteur de langue d’un article, sur une traduction censée exister mais qui affiche une page vide ou un contenu sans rapport. Le coupable est presque toujours le même : une duplication d’article faite avec une extension tierce comme Duplicate Post, sur un site où Polylang gère les traductions.

Le problème ne saute pas aux yeux immédiatement, ce qui le rend particulièrement pénible à diagnostiquer. Il apparaît souvent des semaines après la duplication initiale, quand quelqu’un d’autre touche à l’article dupliqué et découvre que Polylang le considère comme une traduction d’un article auquel il n’a jamais été rattaché intentionnellement.

Comment la duplication casse le lien de traduction

Polylang relie deux versions linguistiques d’un contenu via une table de relations de taxonomie interne (wp_term_relationships et un term de type post_translations qui stocke, sous forme sérialisée, les identifiants des articles liés par langue). Quand Duplicate Post clone un article, il copie par défaut les métadonnées personnalisées (wp_postmeta) et, selon la configuration, les taxonomies associées. Or la langue d’un article dans Polylang est elle-même stockée comme une taxonomie (post_translations et language). Si Duplicate Post copie ces taxonomies sans les réinitialiser, le nouvel article cloné hérite du même identifiant de langue que l’original, et pire, reste rattaché au même groupe de traduction sérialisé — alors que Polylang, lui, croit toujours qu’il n’y a qu’un seul article français relié à la traduction anglaise existante.

Résultat concret : l’article original et sa copie partagent la même entrée dans le tableau de traduction. Modifier le sélecteur de langue sur l’un des deux peut alors écraser silencieusement la relation de traduction de l’autre, ou faire apparaître un lien de traduction vers un article qui n’a plus aucun rapport de contenu avec l’original.

Le nettoyage, étape par étape

La première chose à faire n’est pas de modifier l’article dans l’éditeur — cela ne fait souvent qu’aggraver le désordre, Polylang recalculant la relation à chaque sauvegarde sans corriger l’incohérence de fond. Il faut d’abord identifier précisément le groupe de traduction concerné.

1. Repérer l’ID du term de type post_translations concerné dans la table wp_term_taxonomy, en filtrant sur taxonomy = 'post_translations'
2. Lire la valeur sérialisée dans wp_terms.description ou via le champ associé pour voir quels IDs d’articles sont actuellement rattachés à ce groupe
3. Comparer cette liste à la réalité éditoriale : quel article doit vraiment être la traduction française, lequel est un doublon fantôme
4. Retirer le doublon du groupe de traduction en le désassociant proprement, plutôt qu’en le supprimant directement (pour ne pas perdre le contenu si un éditeur en a besoin)
5. Vérifier, une fois le lien corrigé, que le sélecteur de langue en front n’affiche plus qu’une seule traduction par langue

Pourquoi la fonction de duplication de Polylang existe déjà

L’ironie de la situation, c’est que Polylang propose sa propre fonctionnalité de duplication de contenu entre langues, pensée précisément pour éviter ce genre de conflit : elle crée un nouvel article dans la langue cible, sans dupliquer les métadonnées de langue de l’original, et l’associe correctement au groupe de traduction. Utiliser Duplicate Post pour dupliquer un article dans la même langue (un gabarit de page produit, par exemple) reste sans risque. Le problème survient uniquement quand Duplicate Post est utilisé comme raccourci pour créer une base de traduction, un usage pour lequel il n’a jamais été prévu.

Prévenir plutôt que nettoyer

Sur ce type de conflit entre deux extensions qui touchent chacune aux métadonnées de contenu, la règle qui évite le plus d’incidents est simple : une seule extension a le droit de manipuler la relation de traduction, jamais deux.

Concrètement, cela veut dire former les équipes éditoriales à ne jamais utiliser le bouton de duplication générique pour créer une traduction, même s’il semble plus rapide sur le moment. Si Duplicate Post reste installé pour d’autres usages (dupliquer un gabarit de page dans la même langue, par exemple), il est possible de restreindre son comportement via le filtre duplicate_post_meta_keys_filter pour exclure explicitement les clés de métadonnées liées à Polylang, ou plus simplement de désactiver la copie des taxonomies dans les réglages de l’extension.

• Ne jamais dupliquer un article avec une extension tierce pour créer une base de traduction
• Utiliser exclusivement la fonction de duplication native de Polylang pour ce cas d’usage
• Exclure les taxonomies de langue de la copie via les réglages ou un filtre dédié si l’extension tierce reste utile ailleurs
• Vérifier périodiquement les groupes de traduction en base pour repérer des doublons avant qu’un éditeur ne tombe dessus

En résumé

Une traduction fantôme n’est jamais un bug aléatoire de Polylang : c’est presque toujours la conséquence d’une extension tierce qui a copié, sans le savoir, une métadonnée de langue qu’elle n’aurait jamais dû toucher. Le nettoyage se fait proprement en base, sans paniquer et sans supprimer de contenu à l’aveugle, mais la vraie solution reste en amont : réserver la création de traductions à l’outil pensé pour ça, et ne jamais laisser un outil de duplication générique s’approcher des métadonnées de langue.