# Un annuaire de plusieurs milliers de fiches traduit en cinq langues avec Polylang

> Un client nous a confié la traduction d'un annuaire professionnel de plusieurs milliers de fiches en cinq langues sous Polylang. Voici les difficultés d'échelle rencontrées, loin des cas d'école habituels.

- Auteur : Clément Hadrot
- Publié le : 2023-05-24
- Mis à jour le : 2023-05-24
- Catégorie : Multilingue
- URL : https://wpmoderne.dev.wordpress-developpement.fr/multilingue/annuaire-entreprises-cinq-langues-polylang/

## L’essentiel

- Au-delà de quelques centaines de fiches, la synchronisation manuelle des champs communs devient intenable
- Le budget de traduction humaine complète était incompatible avec le volume, d'où un tri par priorité
- Les performances de l'admin WordPress se dégradent nettement avec ce volume de contenus liés

Un client opérant un annuaire professionnel du secteur du bâtiment, avec six mille quatre cents fiches d'entreprises réparties par métier et par région, nous a confié l'an dernier un projet d'ouverture à cinq langues (français, anglais, allemand, italien, espagnol) via Polylang, déjà utilisé pour une première extension bilingue française-anglaise limitée aux pages institutionnelles du site. Le projet paraissait, sur le papier, une simple extension d'un chantier déjà connu. À cette échelle, plusieurs difficultés que l'on ne rencontre jamais sur un site de contenu éditorial classique sont apparues.

## Le premier mur : le budget de traduction humaine intégrale

Traduire intégralement six mille quatre cents fiches dans quatre nouvelles langues représentait, au tarif d'un traducteur professionnel qualifié, un budget totalement disproportionné par rapport à la valeur commerciale de l'annuaire pour le client. La décision a été prise, avec l'accord du client, de distinguer deux niveaux de traitement :

- les champs structurés communs à toutes les fiches (nom du métier, catégorie, zone géographique, libellés d'interface) traduits une fois pour toutes par un traducteur professionnel, car réutilisés des milliers de fois ;
- le texte libre propre à chaque fiche (description de l'entreprise, rédigée par l'entreprise elle-même) traduit automatiquement via l'API DeepL, avec une mention visible indiquant une traduction automatique, sans relecture individuelle systématique compte tenu du volume.

Ce compromis, impensable sur un site éditorial soigné, s'est avéré le seul réalisme économique pour ce projet précis : les visiteurs de l'annuaire recherchent avant tout un contact et une catégorie, rarement une prose élaborée.

## Le deuxième mur : la synchronisation des champs communs entre langues

> L'essentiel à retenir : Au-delà de quelques centaines de fiches, la synchronisation manuelle des champs communs devient intenable ; Le budget de traduction humaine complète était incompatible avec le volume, d'où un tri par priorité ; Les performances de l'admin WordPress se dégradent nettement avec ce volume de contenus liés

Polylang gère la traduction d'un article personnalisé (ici le type `fiche_entreprise`) comme des articles distincts liés entre eux, chacun avec ses propres champs personnalisés. Sur un contenu éditorial classique, ce fonctionnement pose rarement problème. Sur un annuaire, certains champs ne doivent jamais diverger entre langues : le numéro de téléphone, l'adresse physique, le statut d'adhésion de l'entreprise à l'annuaire. Une mise à jour de ces champs sur la fiche française doit se répercuter automatiquement sur les quatre autres langues, sans quoi une entreprise ayant changé de numéro de téléphone se retrouve avec des coordonnées différentes selon la langue consultée.

Polylang propose une synchronisation de champs personnalisés via le filtre `pll_copy_post_metas`, mais celui-ci ne fonctionne qu'à la création initiale de la traduction, pas en mise à jour continue. Nous avons dû développer un correctif spécifique, déclenché sur `save_post`, qui répercute la mise à jour de certains champs identifiés comme non traduisibles vers l'ensemble des traductions liées d'une fiche :

```
add_action( 'save_post_fiche_entreprise', function( $post_id ) {
    $champs_communs = array( 'telephone', 'adresse', 'statut_adhesion' );
    $translations = pll_get_post_translations( $post_id );
    foreach ( $translations as $lang => $id_traduit ) {
        if ( $id_traduit === $post_id ) continue;
        foreach ( $champs_communs as $champ ) {
            update_post_meta( $id_traduit, $champ, get_post_meta( $post_id, $champ, true ) );
        }
    }
}, 20 );
```

## Le troisième mur : les performances de l'administration WordPress

Avec plus de trente mille fiches au total une fois les cinq langues créées, l'écran de gestion des articles est devenu notablement plus lent, en particulier le filtre par langue et par catégorie de métier de Polylang, qui multiplie les jointures sur la table des termes. Nous avons dû ajouter un index composite supplémentaire sur la table `wp_term_relationships` et limiter le nombre d'éléments chargés par page dans l'administration, une optimisation rarement nécessaire sur un site de contenu classique mais incontournable à ce volume.

## Ce que nous retenons de ce projet pour un futur cas similaire

1. Chiffrer le coût de traduction humaine intégrale *avant* de s'engager sur le nombre de langues visé, pour arbitrer avec le client dès le cadrage plutôt qu'en cours de projet.
2. Identifier en amont les champs qui ne doivent jamais diverger entre langues, et développer la synchronisation correspondante avant le premier import de masse, pas après.
3. Tester les performances de l'administration sur un volume représentatif (import de test à pleine échelle) avant la mise en production, plutôt que de découvrir la lenteur une fois le site ouvert aux gestionnaires.

> Un projet multilingue à grande échelle n'est pas un projet multilingue classique multiplié par le nombre de fiches : certains problèmes n'existent tout simplement pas en dessous d'un certain volume, et apparaissent brutalement au-delà.

## Ce que cet article ne traite pas

La prise en main de base de Polylang, la création d'un type de contenu personnalisé traduisible et la configuration initiale du sélecteur de langue ont été couvertes dans un article dédié aux fondamentaux et ne sont pas reprises ici.

## En résumé

Traduire un annuaire de plusieurs milliers de fiches en cinq langues sous Polylang a révélé des difficultés propres au volume : un arbitrage budgétaire entre traduction humaine et automatique selon la nature du champ, une synchronisation des données communes à développer spécifiquement, et des performances d'administration à optimiser en amont. Aucun de ces trois points n'aurait été visible sur un projet de quelques dizaines de pages.