# ACF et Polylang ensemble : synchroniser des champs sans les dupliquer

> Comment éviter qu'ACF recrée une valeur indépendante par langue avec Polylang, et choisir entre synchronisation et traduction champ par champ.

- Auteur : WordPress Développement
- Publié le : 2020-01-17
- Mis à jour le : 2020-01-17
- Catégorie : Extensions
- URL : https://www.wpmoderne.fr/extensions/acf-polylang-synchroniser-champs-sans-dupliquer/

## L’essentiel

- Polylang duplique chaque article traduit avec ses propres métadonnées
- Le réglage de synchronisation des champs ACF évite la resaisie
- Certains champs doivent rester traduisibles, d'autres partagés

Pourquoi la photo de l'équipe dirigeante, saisie une seule fois dans la version française d'une page « À propos », se retrouve-t-elle vide dans sa traduction anglaise malgré un champ ACF identique dans les deux articles ? La réponse tient à la façon dont Polylang gère la traduction : chaque langue crée un article distinct en base de données, avec ses propres métadonnées, y compris celles issues d'Advanced Custom Fields.

Ce comportement est voulu — un champ de type texte destiné à une traduction doit évidemment avoir une valeur différente par langue — mais il devient un problème dès qu'un champ représente une donnée qui n'a pas vocation à changer selon la langue : une image, une couleur, une date, un identifiant externe.

## Comprendre pourquoi Polylang duplique tout par défaut

Quand un contenu est traduit avec Polylang, chaque traduction est un article WordPress à part entière, lié aux autres traductions par une table de correspondance interne. Ce choix d'architecture, cohérent avec le fonctionnement natif de WordPress, signifie que les métadonnées ACF ne sont pas partagées automatiquement : chaque article traduit possède sa propre copie de chaque valeur de champ, y compris pour un champ image ou une galerie qui, dans l'idéal, devraient rester identiques d'une langue à l'autre.

Sans configuration particulière, un rédacteur qui traduit une page doit donc ressaisir manuellement chaque champ ACF non textuel — une source classique d'oublis, de champs vides en langue secondaire, ou pire, d'incohérences entre versions linguistiques d'un même contenu.

## Activer la synchronisation native des champs ACF

Polylang propose un réglage dédié, « Synchronisation », accessible depuis Réglages → Langues → onglet Synchronisation. Il permet de cocher les métadonnées personnalisées à synchroniser automatiquement entre les traductions d'un même contenu. Une fois activée pour les champs ACF concernés, toute modification apportée dans une langue se répercute automatiquement dans les autres traductions.

> L'essentiel à retenir : Polylang duplique chaque article traduit avec ses propres métadonnées ; Le réglage de synchronisation des champs ACF évite la resaisie ; Certains champs doivent rester traduisibles, d'autres partagés

## Distinguer les champs à synchroniser des champs à traduire

Toute la difficulté réside dans ce tri, qui doit se faire champ par champ, pas globalement :

| Type de champ | Comportement recommandé |
| --- | --- |
| Image, logo, document PDF | Synchroniser (valeur identique dans toutes les langues) |
| Titre, description, texte libre | Traduire (valeur différente par langue) |
| Date, identifiant externe, coordonnées GPS | Synchroniser |
| Lien vers une page interne | Traduire (pointer vers la traduction correspondante) |

Un champ répéteur ACF mêlant les deux types de données (par exemple une galerie avec légende) pose un problème plus délicat : la synchronisation Polylang s'applique au champ dans son ensemble, pas à ses sous-champs. Il faut alors soit accepter de traduire l'intégralité du répéteur, soit le scinder en deux champs distincts — un champ image synchronisé, un champ légende traduit séparément.

## Filtrer la synchronisation par code pour les cas particuliers

Pour des besoins plus précis que ce que l'interface permet, le filtre `pll_copy_post_metas` autorise un contrôle programmatique de la liste des métadonnées synchronisées, utile notamment quand certains champs ACF sont générés dynamiquement selon le type de contenu :

```
add_filter( 'pll_copy_post_metas', function ( $metas, $sync, $post_id ) {
    if ( 'page_service' === get_post_type( $post_id ) ) {
        $metas[] = 'coordonnees_gps';
        $metas[] = 'logo_partenaire';
    }
    return $metas;
}, 10, 3 );
```

Ce filtre s'exécute au moment de la copie des métadonnées lors de la création d'une nouvelle traduction, ce qui permet d'ajouter des champs à synchroniser selon des règles métier propres au projet, sans dépendre uniquement du réglage global de l'interface.

## Vérifier le résultat avec ACF côté code

Une fois la synchronisation en place, la lecture des champs reste identique côté template, avec `get_field()`, qui retourne la valeur associée à l'article courant (donc déjà dans la bonne langue pour les champs traduits, et la valeur synchronisée pour les autres) :

```
$logo = get_field( 'logo_partenaire' );
$titre_traduit = get_field( 'titre_section' );
```

Aucune adaptation de template n'est nécessaire : la synchronisation opère au niveau des métadonnées en base, pas au niveau de l'affichage. C'est aussi ce qui la rend fragile si elle est activée après coup sur un site déjà traduit : les articles existants ne sont pas rétroactivement synchronisés, seule une nouvelle modification déclenche la copie.

> Un champ qui ne devrait jamais différer d'une langue à l'autre et qui diffère quand même n'est presque jamais une coquille de saisie : c'est un réglage de synchronisation manquant.

## Pour aller plus loin

La combinaison ACF et Polylang fonctionne bien une fois ce tri effectué entre champs partagés et champs traduits, mais elle demande une discipline de configuration dès la conception des groupes de champs, pas après coup sur un site déjà rempli. Documenter, pour chaque champ créé, sa nature — traduisible ou universelle — évite à l'équipe éditoriale de découvrir le problème des mois plus tard, sur une page dont la version anglaise affiche silencieusement un champ vide depuis sa création.