Une migration multilingue WordPress, c’est jamais anodin. Surtout quand tu gères 5000 pages en anglais, six langues à supporter, et un site international qui bouffe des traductions tous les jours. J’ai dû effectuer cette migration multilingue WordPress d’Artefact en urgence : WeGlot tournait depuis des années, mais le modèle SaaS commençait à étouffer. On paye les traductions à vie, même celles de 2019. Il fallait changer vite.
Ma décision : passer d’une migration multilingue WordPress classique avec WeGlot à TranslatePress. Trois jours plus tard, la migration multilingue WordPress était faite. Zéro downtime. Et surtout, l’équipe d’Artefact pouvait enfin respirer.
Pourquoi tu as quitté WeGlot ?
Ma migration multilingue WordPress d’Artefact était devenue critique. Le site gère six langues sur WordPress+Avada : anglais, français, allemand, espagnol, néerlandais, portugais brésilien et chinois. WeGlot tournait là-dedans depuis des années. Puis quelques semaines avant la deadline, j’ai fait un calcul simple : pourquoi je continue à payer des traductions que j’ai faites il y a 5, 6 ans ?
Le chiffre qui change la donne pour cette migration multilingue WordPress : 5000 pages en anglais. À traduire en 6 langues. 30 000 pages au total une fois que j’ajoute toutes les versions linguistiques. C’est pas un blog de 50 articles. C’est du vrai contenu, du vrai volume, du vrai défi pour une migration multilingue WordPress.
C’est du SaaS. J’ai un abonnement, je paie chaque mois, mes traductions vivent dans leur système. Sauf que je peux pas les effacer. Je les paie. Peu importe que ça date de 2019, peu importe que ce soit pourri ou que ça ait changé trois fois. WeGlot c’est une facture qui monte, jamais qui redescend.
Avec du volume réel, ça devenait vraiment cher. Au point que je me demandais : pourquoi je fais encore confiance à ce truc ? C’est là qu’une migration multilingue WordPress vers une solution open-source s’imposait comme évidence.
WeGlot ça marche pas à scale ?
Pour une migration multilingue WordPress à cette échelle, WeGlot marche bien pour les petits sites. Deux langues, quelques pages, facile. Mais Artefact c’est pas petit. Six langues, beaucoup de contenu, des updates régulières. Et là ça s’écroule.
Le problème de maintenance. Avec WeGlot je traduis pas depuis mon site. Je vais dans l’editeur, je cherche la chaîne de texte, je la traduis là-bas. C’est une vraie perte de temps. Si j’ai une typo, je la corrige à la source, puis je relance la traduction. Si du contenu a changé ? Je le signale à WeGlot, j’attends la sync. C’est lent, c’est inintuitif, c’est juste pas pensé pour quelqu’un qui veut juste maintenir un site.
Fusion Builder + WeGlot c’est un combat. Avada génère du contenu en PHP et shortcodes. WeGlot arrive pas vraiment à s’y brancher. Je finissais toujours à faire du travail manuel : corriger des traductions ratées, gérer les variables du thème qui s’injectent pas. C’est de la maintenance pour rien.
Dépendance. Si WeGlot tombe demain, mes traductions c’est chez eux. J’exporte quoi, au juste ? Et mon site c’est juste… anglais partout. Ça coûte des clients, surtout si j’ai une audience internationale.
Pourquoi tu as choisi TranslatePress pour ta migration multilingue WordPress ?
TranslatePress Pro c’est l’inverse de WeGlot. Presque sur tous les points.
Base de données interne. Mes traductions elles vivent dans mes tables WordPress : wp_trp_dictionary, wp_trp_gettext_*. C’est chez moi. Si un truc merde, mes données c’est en local. Je peux les exporter, les modifier, les contrôler. Aucune dépendance.
Éditeur au cœur du site. Je traduis directement depuis WordPress. Je clique, j’édite, c’est là. Pas besoin de basculer vers une plateforme externe. Avada + TranslatePress ? Ça marche. Pas parfait (rien l’est), mais vraiment.
Coûts clairs. Je paie une fois pour le plugin. Pas d’API à ma charge qui s’accumule, pas de frais cachés par traduction, pas de pénalité à garder une vieille traduction. Un prix, je l’utilise.
DeepL intégré. Si je veux pas tout traduire à la main, je branche DeepL. C’est mieux que Google Traduction pour les nuances. Je fais un passage, je vérifie, j’affine. Pas de prestataire externe qui me tient par les couilles.
Comment tu as migré les traductions ?
Artefact avait 5000+ traductions dans WeGlot. Je pouvais pas juste les importer dans TranslatePress via l’interface. C’est pas viable. Et franchement, je pouvais même pas les exporter d’une manière que TranslatePress comprendrait vraiment.
J’ai pris une décision simple : je jette les anciennes traductions et je recommence.
J’ai déployé TranslatePress sur staging, activé DeepL, laissé l’IA faire un premier passage. DeepL a traduit tout le contenu. Puis j’ai copié les tables de TranslatePress directement en prod. Pas d’import, pas de magie, juste une copie de base. Après j’ai dû faire du regex pour remplacer les URLs de staging en URLs de prod (la partie qui a pris du temps manuellement).
L’idée ? J’appelle DeepL une seule fois. Une traduction en staging, puis c’est juste une copie de base en prod. Zéro appel API supplémentaire.
Qu’est-ce qui a vraiment changé ?
Les URLs d’abord. Avec WeGlot, c’était des paramètres cachés. Avec TranslatePress, j’ai des vrais chemins : /fr/, /de/, /es/, /nl/, /br/, /zh/. Google aime ça. Les hreflang se génèrent tout seul, les moteurs de recherche comprennent qu’il y a plusieurs langues.
Avada + TranslatePress : ça marche. Fusion Builder crée du contenu PHP, TranslatePress le traduit sans bidouilles. Les menus se dupliquent par langue. Les widgets se traduisent. Propre.
Glossaires. Un truc important : TranslatePress a un système de glossaires qui filtre avant d’envoyer à DeepL. Les mots du glossaire ne vont pas à DeepL, ils se traduisent directement. Ça économise du quota et surtout ça garantit la cohérence. J’ai repris mes glossaires depuis WeGlot (noms de produits, termes métier), ce qui a évité des traductions bizarres qui auraient fallu corriger à la main.
Cache. J’utilise LiteSpeed (pas WP Rocket, c’est plus performant sur mon VPS). LiteSpeed met en cache partout. Il fallait tout purger puis laisser les bots régénérer. Classique mais fatal si je l’oublie.
Comment ça marche avec DeepL ?
Là, c’était pas ce que je pensais. DeepL s’en fiche d’où les traductions arrivent, staging ou prod. C’est les appels API avec ma clé qui font le coût. Point.
Donc j’ai exporté les tables depuis la staging, puis j’ai fait du regex pour remplacer staging.artefact.com en artefact.com dans les données. Ça paraît simple sur le papier, pas vraiment. Plusieurs tentatives avant de finir à la main pour vérifier que rien s’était cassé. Mais une fois c’est fait, je copie en prod, zéro appel API supplémentaire.
Comment ça s’est passé le jour J ?
Pas de drame. J’ai testé sur la prod avec des redirections temporaires. J’ai vérifié que les URLs se résolvent. Que les hreflang sont correctement injectées. Que les menus français pointent au bon endroit en français. Que les commentaires qui traînaient en HTML encodé sont lisibles.
J’ai vidé le cache deux fois (c’est pas une blague). J’ai attendu une heure, j’ai regardé Search Console pour voir si Google avait déjà indexé les nouvelles URLs.
Il y a toujours un truc que j’avais pas anticipé. Un widget nulle part. Un bout de contenu qui était resté en hardcod anglais. Mais pour un site de cette taille avec six langues, c’était très clean.
Qu’est-ce que tu as retenu ?
Sous pression, je choisis la simplicité. J’oublie d’importer les anciennes traductions, c’est trop compliqué et trop risqué. Je recommence à zéro. L’IA fait un premier passage, j’affine après. Plus rapide, moins de galère, plus facile à déboguer.
Et surtout je reprends du contrôle. Mes traductions c’est chez moi. Mes coûts ils sont stables. Ma maintenance elle est simple.
WeGlot ? C’est bien pour un blog personnel ou un petit site. Pour quelque chose qui bouge une fois par an. Mais pour du vrai contenu, du vrai maintenance, du vrai scale ? TranslatePress gagne. C’est interne, c’est pragmatique, et ça fait le job.
Bilan : trois jours pour changer la donne
La migration multilingue WordPress a pris exactement trois jours. Staging → test → production. Pas de drame, pas de downtime. Le client est très satisfait : sa facturation de traductions a chuté drastiquement. Fini les pénalités SaaS, fini les appels API qui s’accumulent.
Mais la vraie victoire, c’est l’autonomie. L’équipe d’Artefact n’est plus dépendante de WeGlot. Ils peuvent traduire directement depuis WordPress, sans attendre la synchronisation d’une plateforme externe. Et ça compte vraiment quand tu as des collaborateurs dans le monde entier : des équipes à Paris, au Brésil, en Allemagne, aux Pays-Bas, en Chine. Des gens qui parlent le français, l’allemand, l’espagnol, le néerlandais, le mandarin en langue maternelle. Avant, tout passait par WeGlot. Maintenant, ils peuvent corriger une traduction en direct, vérifier le rendu dans le contexte du site, et c’est live. TranslatePress + DeepL, c’est passé de « outil qu’on subit » à « outil qu’on contrôle ».
Cette migration multilingue WordPress vers TranslatePress confirme une chose : quand tu dois scaler une migration multilingue WordPress, les outils SaaS propriétaires deviennent des boulets. WordPress avec une bonne solution de traductions, c’est imbattable. C’est pragmatique. C’est efficace. Et trois jours plus tard, c’était déjà du passé.
Ressources pour ta migration multilingue WordPress
Si tu envisages ta propre migration multilingue WordPress, voici les ressources essentielles :
Outils recommandés :
• TranslatePress – Solution de traduction WordPress native
• DeepL – Moteur de traduction IA de haute qualité
• TranslatePress sur le répertoire WordPress – Version gratuite disponible