# Rendre un type de contenu personnalisé et ses taxonomies traduisibles avec Polylang

> Un CPT créé sans réflexion multilingue en amont finit toujours par poser problème. Voici comment le rendre correctement traduisible avec Polylang.

- Auteur : Clément Hadrot
- Publié le : 2020-11-24
- Mis à jour le : 2020-11-24
- Catégorie : Multilingue
- URL : https://wpmoderne.dev.wordpress-developpement.fr/multilingue/polylang-cpt-taxonomies-personnalisees/

## L’essentiel

- Le paramètre translatable doit être déclaré à l'enregistrement du CPT
- Chaque taxonomie personnalisée se déclare séparément
- Les métadonnées ne se traduisent pas automatiquement

Un scénario revient régulièrement en maintenance : un client a fait développer un type de contenu personnalisé — un catalogue de « Réalisations », un annuaire de « Formateurs » — sans que le développeur d'origine anticipe un usage multilingue. Six mois plus tard, le site passe en bilingue, et ce CPT refuse obstinément d'apparaître dans les écrans de traduction de Polylang. Ce n'est pas un bug : Polylang doit être informé explicitement de l'existence de ce type de contenu.

Cet article détaille la marche à suivre pour rendre un CPT et sa taxonomie associée traduisibles avec Polylang, que ce soit dès la conception ou sur un projet déjà en production.

## Déclarer le CPT comme traduisible

Par défaut, Polylang ne gère que les types de contenu natifs (articles, pages) et les types de contenu publics enregistrés avec certains réglages compatibles. Pour un CPT personnalisé, deux méthodes coexistent.

La première, la plus simple, consiste à cocher la case correspondante dans **Langues → Réglages → Types de contenus personnalisés**, où Polylang liste automatiquement tous les CPT publics détectés. C'est suffisant dans la majorité des cas.

La seconde méthode, plus fiable pour un projet géré en code, consiste à filtrer la liste des types de contenu traduisibles directement en PHP :

```
<?php
add_filter( 'pll_get_post_types', function( $post_types, $is_settings ) {
    $post_types['realisation'] = 'realisation';
    return $post_types;
}, 10, 2 );
```

Cette approche présente un avantage important : elle fonctionne même si un administrateur décoche la case dans l'interface par erreur, puisque la déclaration vit dans le code du thème ou d'une extension, pas dans une option modifiable en base.

## Déclarer la taxonomie associée

Un CPT « Réalisations » s'accompagne souvent d'une taxonomie personnalisée, par exemple « Secteur d'activité ». Cette taxonomie doit être déclarée séparément, avec un filtre équivalent :

```
<?php
add_filter( 'pll_get_taxonomies', function( $taxonomies, $is_settings ) {
    $taxonomies['secteur_activite'] = 'secteur_activite';
    return $taxonomies;
}, 10, 2 );
```

Sans cette déclaration, les termes de la taxonomie restent partagés entre toutes les langues : un même terme « Industrie » s'affiche identiquement en français et en anglais, ce qui n'est presque jamais le comportement souhaité sur un site réellement bilingue.

> L'essentiel à retenir : Le paramètre translatable doit être déclaré à l'enregistrement du CPT ; Chaque taxonomie personnalisée se déclare séparément ; Les métadonnées ne se traduisent pas automatiquement

## Traduire les termes de taxonomie existants

Une fois la taxonomie déclarée traduisible, les termes déjà créés n'ont pas de traduction automatique : chaque terme doit être dupliqué manuellement dans chaque langue, exactement comme pour un article. Sur l'écran de gestion des termes, un champ de langue apparaît, avec la possibilité de créer la traduction manquante.

Pour un volume important de termes existants (une taxonomie avec cent cinquante secteurs d'activité, par exemple), la traduction manuelle terme par terme est fastidieuse. Il existe deux options réalistes : passer par un script WP-CLI personnalisé qui itère sur `wp term list` et crée les traductions via l'API de Polylang, ou accepter de ne traduire que les termes réellement utilisés (souvent une minorité) et laisser les autres en langue par défaut, ce qui reste un compromis acceptable si le catalogue est peu consulté par un public non francophone.

## Le piège des métadonnées non traduites

Un champ personnalisé — un prix, une date, un texte enregistré via un champ ACF, par exemple — n'est jamais automatiquement lié entre les traductions d'un même contenu. Chaque traduction possède ses propres métadonnées, complètement indépendantes de l'original. Deux conséquences pratiques :

- Un champ ACF de type texte doit être retraduit manuellement sur chaque version linguistique, ce qui est souvent le comportement attendu.
- Un champ qui ne devrait **pas** changer entre les langues (une coordonnée GPS, un prix identique dans toutes les langues, une référence produit) doit être synchronisé explicitement, sans quoi un client modifie le prix en français et découvre six mois plus tard que la version anglaise affiche encore l'ancien tarif.

Polylang propose justement un mécanisme de synchronisation de champs personnalisés, accessible via **Langues → Réglages → Synchronisation**, où l'on peut lister les clés de métadonnées à garder identiques entre toutes les traductions d'un même groupe.

## Vérifier le comportement des requêtes personnalisées

Un dernier piège concerne les requêtes `WP_Query` écrites à la main pour afficher ce CPT (un shortcode personnalisé, un widget de « dernières réalisations »). Sans intervention, ces requêtes ignorent la langue courante et affichent indifféremment tous les contenus, toutes langues confondues. Il faut soit s'appuyer sur le filtre automatique de Polylang (actif par défaut sur les requêtes principales), soit filtrer explicitement la requête :

```
<?php
$args = array(
    'post_type' => 'realisation',
    'lang'      => pll_current_language(),
);
$requete = new WP_Query( $args );
```

Le paramètre `lang` accepté nativement par `WP_Query` une fois Polylang actif est la solution la plus robuste, plus fiable qu'une désactivation globale du filtrage automatique.

## En résumé

Un CPT et sa taxonomie ne deviennent traduisibles avec Polylang qu'après une déclaration explicite, que ce soit via l'interface ou par filtre PHP. Les métadonnées associées ne suivent jamais automatiquement la traduction du contenu principal, ce qui impose une réflexion sur ce qui doit être traduit et ce qui doit rester synchronisé entre les langues. Anticiper ces réglages dès la conception d'un CPT évite des heures de rattrapage lorsque le site passe en multilingue plus tard dans son cycle de vie.