# Synchroniser les traductions Polylang entre trois environnements en une commande

> Une commande maison qui synchronise les chaînes de traduction Polylang entre local, recette et production, pour éviter de perdre du contenu traduit d'un environnement à l'autre.

- Auteur : Clément Hadrot
- Publié le : 2025-03-28
- Mis à jour le : 2025-03-28
- Catégorie : Outils & workflow
- URL : https://wpmoderne.dev.wordpress-developpement.fr/outils/synchroniser-traductions-polylang-trois-environnements/

## L’essentiel

- Exporter les traductions sans exporter tout le contenu
- comparer avant d'écraser
- commande wp-cli maison réutilisable

Comment expliquer qu'une traduction validée en recette disparaisse mystérieusement après un déploiement en production ? La réponse tient souvent à une confusion fréquente sur les projets multilingues : synchroniser les bases de données entre environnements écrase les traductions Polylang au même titre que le reste du contenu, y compris celles qui viennent d'être ajoutées uniquement en recette pour validation.

Ce problème touche particulièrement les équipes qui traduisent directement dans l'environnement de recette avant validation client, puis synchronisent la base vers la production sans distinguer ce qui doit réellement remonter de ce qui ne doit pas être écrasé. Une commande wp-cli maison, ciblée sur les seules données Polylang, répond à ce besoin sans passer par une synchronisation complète de base de données à chaque fois.

## Comprendre où vivent les traductions Polylang

Polylang stocke les relations de traduction dans des taxonomies dédiées (`post_translations`, `term_translations`) et la langue de chaque contenu via une taxonomie `language` associée à chaque article, page ou terme. Synchroniser uniquement ces structures, sans toucher au reste du contenu, demande de cibler précisément ces tables et taxonomies plutôt que d'exporter la base entière.

## Étape 1 : exporter uniquement les données de traduction

> L'essentiel à retenir : Exporter les traductions sans exporter tout le contenu ; comparer avant d'écraser ; commande wp-cli maison réutilisable

Une commande personnalisée s'appuie sur les fonctions internes de Polylang pour extraire, environnement par environnement, la correspondance entre identifiants de contenu et langues :

```
class Polylang_Sync_Command {
    public function export( $args, $assoc_args ) {
        $traductions = array();
        $posts = get_posts( array( 'post_type' => 'any', 'numberposts' => -1 ) );

        foreach ( $posts as $post ) {
            $lang = pll_get_post_language( $post->ID );
            if ( $lang ) {
                $traductions[ $post->ID ] = array(
                    'langue'       => $lang,
                    'traductions'  => pll_get_post_translations( $post->ID ),
                );
            }
        }

        file_put_contents( 'traductions-export.json', wp_json_encode( $traductions ) );
        WP_CLI::success( 'Export des traductions terminé.' );
    }
}
WP_CLI::add_command( 'polylang-sync export', array( new Polylang_Sync_Command(), 'export' ) );
```

## Étape 2 : comparer avant d'écraser

La partie la plus sensible n'est pas l'export mais l'import : appliquer aveuglément un fichier exporté depuis la recette sur la production écraserait des traductions ajoutées entre-temps directement en production, un cas qui arrive plus souvent qu'on ne le pense sur les corrections urgentes. La commande d'import compare donc, contenu par contenu, l'état cible avant d'écrire quoi que ce soit :

```
public function import( $args, $assoc_args ) {
    $import = json_decode( file_get_contents( 'traductions-export.json' ), true );

    foreach ( $import as $post_id => $donnees ) {
        $lang_actuelle = pll_get_post_language( $post_id );
        if ( $lang_actuelle === $donnees['langue'] ) {
            WP_CLI::log( "Post {$post_id} déjà à jour, ignoré." );
            continue;
        }
        pll_set_post_language( $post_id, $donnees['langue'] );
    }
    WP_CLI::success( 'Synchronisation appliquée.' );
}
```

## Étape 3 : orchestrer les trois environnements

1. Exporter les traductions depuis l'environnement source (généralement la recette, où la validation a lieu).
2. Transférer le fichier exporté vers la cible via le mécanisme de déploiement déjà en place pour le reste du projet.
3. Lancer l'import en mode comparaison d'abord (avec un indicateur `--dry-run` ajouté à la commande), pour visualiser ce qui serait modifié avant de l'appliquer réellement.
4. Appliquer l'import une fois la liste des changements validée manuellement.

## Ce que cette commande ne fait pas

- Elle ne traduit pas le contenu automatiquement : elle synchronise uniquement des relations déjà établies manuellement dans un environnement source.
- Elle ne gère pas les conflits de traduction simultanée dans deux environnements différents, un cas rare mais possible qui demande une résolution manuelle au cas par cas.

> Synchroniser des environnements ne veut pas dire tout écraser : cela veut dire choisir précisément ce qui doit voyager, et laisser le reste tranquille.

## En résumé

Une commande wp-cli ciblée sur les seules structures de traduction Polylang évite l'écrasement accidentel de contenu traduit lors des synchronisations entre environnements. Elle ne remplace pas une politique claire sur l'environnement où la traduction doit avoir lieu en premier, mais elle limite fortement les pertes accidentelles quand cette politique n'est pas toujours respectée à la lettre.