Contrairement à une migration classique de contenu, migrer un blog multilingue depuis une plateforme d’édition tierce ne se limite pas à importer des billets : il faut aussi reconstruire les liens qui associaient chaque billet à sa traduction dans l’autre langue, des liens que l’export d’origine ne conservait tout simplement pas. Ce cas concerne un blog éditorial de 1 240 billets, publiés en français et en anglais depuis plusieurs années sur une plateforme propriétaire, migré vers WordPress avec Polylang.
Ce tutoriel ne traite pas du référencement de cette migration (redirections, conservation du positionnement) : il se concentre exclusivement sur la reconstruction technique des associations de traduction entre billets, une étape indispensable avant toute autre considération.
Étape 1 : comprendre ce que l’export contient réellement
L’export fourni par la plateforme d’origine produisait un fichier par billet, avec un identifiant unique propre à cette plateforme, sans aucune référence croisée vers la version traduite du même billet. En revanche, chaque fichier contenait un champ « slug d’origine » qui, par une convention interne à l’équipe éditoriale, suivait un schéma prévisible : le billet français portait le slug mon-article, sa version anglaise portait systématiquement mon-article-en.
- Aucune relation de traduction explicite dans les fichiers exportés
- Une convention de nommage de slug exploitable pour reconstruire les paires
- Environ 620 billets français et 620 billets anglais à apparier
Étape 2 : importer le contenu sans se soucier des relations
La première phase de la migration a consisté à importer l’intégralité des billets dans WordPress via un script personnalisé s’appuyant sur wp_insert_post(), en assignant à chaque billet sa langue via pll_set_post_language() d’après un indice contenu dans le nom de fichier de l’export. Aucune tentative de relier les traductions n’a été faite à ce stade, pour séparer clairement les deux problèmes.
foreach ( $fichiers_export as $fichier ) {
$donnees = json_decode( file_get_contents( $fichier ), true );
$id = wp_insert_post( array(
'post_title' => $donnees['titre'],
'post_content' => $donnees['contenu'],
'post_name' => $donnees['slug'],
'post_status' => 'publish',
) );
$langue = str_ends_with( $donnees['slug'], '-en' ) ? 'en' : 'fr';
pll_set_post_language( $id, $langue );
}
Étape 3 : reconstruire les paires via le slug pivot
Une fois tous les billets importés, un second script a parcouru l’ensemble des billets français, retiré leur slug de tout suffixe, ajouté le suffixe -en, et recherché un billet anglais portant ce slug reconstitué. Quand une correspondance était trouvée, la relation de traduction était établie via pll_save_post_translations().
$billets_fr = get_posts( array( 'lang' => 'fr', 'numberposts' => -1 ) );
foreach ( $billets_fr as $billet ) {
$slug_attendu = $billet->post_name . '-en';
$billet_en = get_page_by_path( $slug_attendu, OBJECT, 'post' );
if ( $billet_en ) {
pll_save_post_translations( array(
'fr' => $billet->ID,
'en' => $billet_en->ID,
) );
} else {
error_log( "Aucune correspondance trouvée pour : {$billet->post_name}" );
}
}
Les cas non appariés automatiquement
Sur les 620 billets français traités, 38 n’ont trouvé aucune correspondance automatique, généralement parce que le slug anglais avait été modifié manuellement après publication sur la plateforme d’origine, rompant la convention de nommage attendue. Ces 38 cas ont fait l’objet d’une vérification manuelle, billet par billet, en s’appuyant sur la date de publication et le titre pour retrouver la bonne correspondance.
Étape 4 : vérifier la cohérence des paires reconstruites
Avant de considérer la migration terminée, un contrôle systématique a comparé la date de publication de chaque paire reconstruite : un écart de plus de trente jours entre la publication du billet français et celle de sa traduction anglaise supposée a servi de signal d’alerte, permettant de repérer deux appariements incorrects que la seule convention de slug n’avait pas révélés.
| Contrôle | Résultat |
|---|---|
| Appariement automatique par slug | 582 paires correctes sur 620 |
| Correction manuelle sur slugs modifiés | 36 paires supplémentaires reconstruites |
| Appariements incorrects détectés par écart de date | 2 corrigés après vérification |
Ce qu’il faut retenir de cette migration
Comparée à une migration monolingue classique, une migration multilingue exige une étape supplémentaire, souvent sous-estimée : la reconstruction des relations de traduction, qui ne survit presque jamais à un export brut d’une plateforme tierce. S’appuyer sur une convention de nommage existante, même imparfaite, puis vérifier chaque exception manuellement, reste la méthode la plus fiable pour ne perdre aucune paire de traduction en cours de route.
