# « No translation found » sur un type de contenu créé après coup

> Un site d'artisan affiche « No translation found » sur ses nouvelles fiches réalisations : diagnostic de l'ordre de chargement des greffons et correctif durable.

- Auteur : WordPress Développement
- Publié le : 2022-08-28
- Mis à jour le : 2022-08-28
- Catégorie : Multilingue
- URL : https://www.wpmoderne.fr/multilingue/no-translation-found-type-contenu-cree-apres-coup/

## L’essentiel

- L'ordre de chargement des greffons peut casser la déclaration d'un CPT traduisible
- Le correctif passe par une option de priorité explicite
- La prévention consiste à tester à chaque activation d'extension

« No translation found » : ce message est apparu du jour au lendemain sur les fiches « réalisations » d'un site vitrine d'artisan menuisier, alors que le reste du site fonctionnait parfaitement en français et en anglais depuis des mois. Le type de contenu personnalisé « realisation » venait pourtant d'être ajouté récemment par un second développeur, sans que personne ne signale de changement majeur dans la configuration de Polylang.

Ce cas illustre un piège classique des sites multilingues qui évoluent dans le temps : un type de contenu ajouté après la mise en place initiale de la traduction peut se retrouver mal enregistré auprès de l'extension de traduction, sans erreur visible en apparence.

## Symptôme : un message qui n'apparaît que sur le nouveau type de contenu

Le message « No translation found » remplaçait le contenu attendu uniquement sur les pages du type « realisation », jamais sur les articles ni sur les pages classiques. Les fiches existaient bien en base de données, dans les deux langues, avec un lien de traduction visible dans l'éditeur. Le problème ne se situait donc pas dans le contenu lui-même, mais dans la façon dont Polylang tentait de résoudre l'URL demandée vers la bonne traduction.

- Le contenu existe en base, dans les deux langues, avec la relation de traduction enregistrée
- Le message apparaît uniquement à l'affichage de l'URL publique, pas dans l'éditeur
- Aucune erreur PHP dans les journaux, seulement ce message côté affichage

## Diagnostic : un ordre de chargement en cause

Le type de contenu personnalisé « realisation » était déclaré par une extension maison, chargée via un fichier de plugin classique avec le hook `init` à la priorité par défaut, soit 10. Polylang, de son côté, a besoin de connaître les types de contenu à rendre traduisibles avant de résoudre les requêtes publiques, et cette connaissance passe par le filtre `pll_get_post_types`.

> L'essentiel à retenir : L'ordre de chargement des greffons peut casser la déclaration d'un CPT traduisible ; Le correctif passe par une option de priorité explicite ; La prévention consiste à tester à chaque activation d'extension

Le souci venait du fait que l'extension maison enregistrait le type de contenu à la priorité 10 sur `init`, exactement la même priorité que celle utilisée en interne par Polylang pour construire sa liste de types de contenu traduisibles. Selon l'ordre alphabétique des noms de fichiers de plugin (un détail d'implémentation de WordPress rarement documenté), Polylang construisait parfois sa liste avant que le type de contenu ne soit enregistré, et parfois après, ce qui expliquait le comportement intermittent observé par le client.

### Reproduire le bug pour le confirmer

Pour confirmer cette hypothèse, j'ai ajouté un simple `error_log()` dans le filtre `pll_get_post_types`, afin de vérifier la présence ou l'absence du type « realisation » dans le tableau reçu, à chaque rechargement de page. Le résultat alternait effectivement selon des facteurs indépendants du contenu lui-même, ce qui confirmait un problème d'ordre d'exécution plutôt qu'un problème de configuration.

## Correctif : forcer une priorité explicite

La solution retenue a consisté à enregistrer le type de contenu personnalisé plus tôt, avec une priorité explicite inférieure à celle utilisée par Polylang, afin de garantir que la déclaration soit toujours terminée avant que l'extension de traduction ne construise sa liste :

```
add_action( 'init', 'enregistrer_cpt_realisation', 5 );

function enregistrer_cpt_realisation() {
    register_post_type( 'realisation', array(
        'public'       => true,
        'show_in_rest' => true,
        'label'        => __( 'Réalisations', 'menuiserie-theme' ),
    ) );
}
```

Le changement de priorité de 10 à 5 a suffi à rendre le comportement systématique et correct, sans jamais plus revoir le message d'erreur, y compris après plusieurs cycles de désactivation et réactivation d'extensions par le client lui-même.

## Prévention : un test systématique à chaque nouvelle extension

Depuis ce cas, j'ajoute à ma liste de vérifications post-déploiement un test spécifique : après l'ajout ou la modification de tout type de contenu personnalisé sur un site multilingue, je vide le cache d'objets, je recharge chaque URL du nouveau type dans chaque langue configurée, et je vérifie l'absence de tout message d'erreur de traduction avant de considérer le déploiement terminé.

> Un ordre de chargement des greffons qui semble fonctionner neuf fois sur dix reste un bug, pas une coïncidence favorable.

## Ce qu'il faut retenir de ce cas

Ce cas ne relevait ni d'un bug de Polylang ni d'une erreur de configuration visible, mais d'une collision de priorité entre deux hooks `init` exécutés au même niveau. La leçon à retenir : sur un site multilingue, tout type de contenu personnalisé doit être déclaré avec une priorité de hook explicite et documentée, jamais laissée à la valeur par défaut quand plusieurs extensions se partagent le même point d'entrée.