« Pourquoi la version espagnole du site est redevenue identique à la version française ce matin ? » Cette question, posée par un client au lendemain d’un déploiement pourtant réussi côté code, révèle un piège fréquent des sites multilingues gérés avec TranslatePress. Contrairement à un système de traduction basé sur des fichiers .po et .mo versionnés avec le thème, TranslatePress stocke ses traductions directement dans des tables de la base de données. Un déploiement qui écrase la base de production avec celle de l’environnement de recette, ou qui restaure une sauvegarde de base antérieure sans précaution, efface au passage les traductions saisies depuis.
Cette recette décrit une étape de pipeline qui exporte les traductions avant tout déploiement risqué et les réimporte ensuite, pour garantir qu’elles survivent au processus. Elle ne traite pas de la traduction automatique du contenu, qui reste hors du périmètre de cet article.
Comprendre où vivent réellement les traductions
TranslatePress crée deux tables dédiées dans la base de données, généralement nommées avec le préfixe du site suivi de _trp_dictionary_dynamic et _trp_dictionary_static, selon que les chaînes traduites proviennent de contenu dynamique (articles, pages) ou de chaînes statiques du thème et des extensions. Ces tables ne font pas partie du contenu éditorial habituel exporté par les outils classiques de sauvegarde WordPress, ce qui explique qu’elles soient souvent oubliées lors de la conception d’un pipeline de déploiement.
Le problème concret rencontré sur ce projet
Le pipeline de déploiement de ce site synchronise périodiquement le contenu de la base de recette vers la base de production pour tester de nouvelles fonctionnalités dans des conditions réalistes, avant de repartir dans l’autre sens lors de la mise en ligne définitive. Ce processus, utile pour le contenu éditorial classique, écrase sans distinction les tables de traduction, ramenant les chaînes traduites à leur état antérieur, celui de l’environnement de recette qui n’avait jamais reçu les dernières corrections apportées en production par l’équipe éditoriale.
Mettre en place l’export avant chaque déploiement
La solution consiste à exporter le contenu de ces deux tables juste avant toute opération de synchronisation de base de données, puis à le réimporter juste après, en s’assurant que les identifiants internes utilisés par TranslatePress pour associer une chaîne à sa traduction restent cohérents entre l’export et le réimport.
wp db export --tables=wp_trp_dictionary_dynamic,wp_trp_dictionary_static \
sauvegarde-traductions-$(date +%Y%m%d-%H%M).sql
Cette commande, insérée en première étape du script de déploiement, produit un fichier horodaté contenant uniquement les traductions, indépendamment du reste du contenu synchronisé ensuite.
Réimporter après la synchronisation
Une fois la synchronisation de base de données terminée, le fichier exporté est réimporté pour restaurer les traductions les plus récentes par-dessus celles qui viennent d’être écrasées :
wp db import sauvegarde-traductions-$(date +%Y%m%d)*.sql
Cette séquence, exécutée dans cet ordre précis, garantit que le contenu éditorial profite bien de la synchronisation tout en préservant l’état des traductions tel qu’il existait juste avant l’opération.
Intégrer cette étape dans un pipeline existant
- Ajouter une étape d’export des deux tables de traduction en tout début de script de déploiement, avant toute opération sur la base de données.
- Conserver le fichier exporté dans un répertoire temporaire propre au déploiement en cours, jamais versionné avec le code.
- Exécuter la synchronisation ou la restauration de base de données comme précédemment.
- Réimporter le fichier de traductions immédiatement après, avant de considérer le déploiement terminé.
- Vérifier manuellement, sur une page connue pour être traduite, que le contenu multilingue reste cohérent après le déploiement complet.
Variante pour les projets où les traductions changent rarement
Sur un site où les traductions évoluent peu une fois la phase de lancement passée, il peut être plus simple de figer un export de référence versionné, mis à jour manuellement à chaque campagne de traduction, plutôt que d’automatiser un export à chaque déploiement. Cette variante réduit la complexité du pipeline au prix d’une vigilance manuelle plus grande de l’équipe éditoriale.
| Situation | Approche recommandée |
|---|---|
| Traductions modifiées fréquemment | Export et réimport automatisés à chaque déploiement |
| Traductions stables après lancement | Export de référence versionné, mis à jour ponctuellement |
Le réflexe que nous appliquons désormais sur tout projet TranslatePress : traiter les tables de traduction comme un contenu éditorial à part entière dans le pipeline, jamais comme un simple sous-produit de la configuration du thème.
En résumé
Les traductions gérées par TranslatePress vivent dans la base de données, exposées aux mêmes risques d’écrasement que n’importe quel autre contenu lors d’une synchronisation ou d’une restauration. Une simple étape d’export avant et de réimport après chaque opération sensible sur la base suffit à protéger ce travail éditorial, sans complexifier significativement un pipeline de déploiement déjà en place.
