Un client gérant un réseau de gîtes ruraux, avec une clientèle internationale variée, nous a demandé un avis tranché : fallait-il installer GTranslate, qui promettait une mise en ligne en quelques minutes, ou repartir sur WPML, plus lourd à mettre en œuvre mais déjà utilisé sur un projet précédent de la même agence de location ? La question posée était « lequel est le meilleur outil de traduction ? ». La vraie question à se poser est différente : quelle philosophie de gestion du contenu traduit convient à ce projet précis ?
Ces deux outils ne répondent en réalité pas au même besoin, et les comparer uniquement sur la vitesse de mise en place masque des différences de fond bien plus déterminantes sur la durée de vie du site.
GTranslate : traduction automatique à la volée, sans stockage
GTranslate, dans sa formule la plus répandue, s’appuie sur l’API Google Translate pour traduire le contenu au moment où la page est servie au visiteur, sans jamais enregistrer cette traduction comme un contenu WordPress distinct. Le contenu source reste unique en base de données ; seule la version affichée change selon la langue sélectionnée par le visiteur, via un widget ou un sous-domaine dédié à chaque langue.
Les avantages concrets de cette approche :
- mise en ligne en quelques minutes, sans traduction manuelle initiale à fournir ;
- couverture immédiate de dizaines de langues, y compris celles peu demandées mais parfois consultées (utile pour un site touristique à audience variée) ;
- aucune charge de maintenance supplémentaire lors de l’ajout d’un nouvel article : la traduction suit automatiquement.
Les limites, elles, deviennent visibles à l’usage : la qualité de traduction automatique reste inégale sur du contenu à forte connotation commerciale ou culturelle, et surtout, aucune correction manuelle durable n’est possible sans passer par les formules payantes de l’outil qui permettent un « glossaire » de substitutions, bien plus limité qu’une vraie relecture éditoriale phrase par phrase.
WPML : chaque traduction est un contenu à part entière
WPML fonctionne à l’opposé : chaque article, page ou fiche produit traduit devient un article WordPress distinct, lié à l’original par une relation de traduction stockée dans la table wp_icl_translations. Cette traduction peut être rédigée manuellement, importée depuis un prestataire externe via XLIFF, ou générée automatiquement puis relue et corrigée directement dans l’éditeur, sans limite de personnalisation.
// Vérifier si un article possède une traduction dans une langue donnée
$translated_id = apply_filters( 'wpml_object_id', $post_id, 'post', false, 'en' );
if ( $translated_id ) {
// une traduction existe et peut être éditée comme un article normal
}Cette structure a un coût : elle demande un travail de traduction réel, humaine ou assistée, article par article, et une maintenance continue à chaque mise à jour du contenu source pour ne pas laisser une version linguistique devenir obsolète.
Comparatif sur les critères qui déterminent la maintenance réelle
| Critère | GTranslate | WPML |
|---|---|---|
| Délai de mise en ligne initiale | Quelques minutes | Plusieurs jours à semaines selon volume |
| Contenu traduit stocké en base | Non, traduit à la demande | Oui, article WordPress distinct |
| Correction manuelle durable d’une traduction | Limitée, glossaire de substitution seulement | Totale, édition libre comme un article normal |
| Impact SEO par langue | Variable selon configuration, souvent en sous-domaine | URL et hreflang natifs par langue |
| Nombre de langues couvertes | Très large, y compris langues rares | Dépend du travail de traduction fourni |
| Charge de maintenance à chaque nouvel article | Aucune, automatique | Traduction à produire ou commander |
Verdict selon le profil du site
Pour un site à fort volume de contenu généré en continu, où la traduction manuelle de chaque page serait disproportionnée par rapport à l’enjeu commercial de chaque langue secondaire (un blog de niche consulté ponctuellement par des visiteurs non francophones, par exemple), GTranslate rend un service honnête : une traduction imparfaite mais immédiate vaut mieux qu’aucune traduction.
Pour un site où chaque langue représente un marché commercial à part entière — ce qui est précisément le cas de ce client, dont les réservations en anglais et en néerlandais pèsent une part significative du chiffre d’affaires — la capacité à corriger, nuancer et adapter culturellement chaque traduction justifie largement l’investissement initial de WPML.
La question à poser à un client hésitant entre les deux outils n’est jamais « combien de langues voulez-vous couvrir » mais « combien de langues représentent un vrai marché pour vous ». La réponse tranche presque toujours le choix.
Ce que cet article ne traite pas
Ce comparatif porte sur GTranslate face à WPML. Weglot, autre solution de traduction par couche externe fonctionnant différemment de GTranslate, a fait l’objet d’une comparaison distincte publiée la même année et n’est pas repris ici.
En résumé
GTranslate et WPML ne sont pas deux concurrents sur un même terrain, mais deux réponses à des besoins différents : traduction automatique jetable et non stockée d’un côté, gestion éditoriale complète du contenu traduit de l’autre. Le client des gîtes ruraux a finalement opté pour WPML sur ses deux langues commercialement stratégiques, en conservant l’idée d’un widget de traduction automatique en complément pour les langues plus marginales de sa clientèle.
