Guide complet pour la traduction multilingue de sites web WordPress

Traduire un site web WordPress est un processus complexe qui nécessite une planification et une exécution soigneuses. Nous avons créé ce guide complet en nous appuyant sur notre vaste expérience dans la traduction de sites web, en utilisant le plugin Gato AI Translations for Polylang.

Ce guide vous accompagne à travers tout ce que vous devez savoir : depuis les préparations initiales et la configuration, en passant par le processus de traduction proprement dit, jusqu'à la validation et la résolution des problèmes. Suivez ce guide pour garantir une expérience de traduction fluide.

​

Installer et configurer Polylang

Gato AI Translations for Polylang nécessite que Polylang soit installé et activé. Polylang est le framework multilingue qui gère vos langues et les relations de traduction.

Après l'installation, vous devrez configurer Polylang avec vos langues :

1. Accédez à Languages dans le menu d'administration de WordPress
2. Ajoutez votre langue par défaut (la langue de votre contenu existant)
3. Ajoutez toutes les langues cibles vers lesquelles vous souhaitez traduire

​

Auditez et corrigez d'abord votre contenu d'origine

Avant de commencer à traduire, il est essentiel de vous assurer que votre contenu d'origine est en parfait état. Tout problème dans votre contenu original sera répliqué dans toutes les traductions, ce qui signifie que vous devrez corriger le même problème plusieurs fois (une fois par langue).

Liste de contrôle d'audit du contenu :

1. Vérifiez les liens brisés

   • Utilisez un plugin comme Broken Link Checker pour identifier les liens internes et externes brisés
   • Corrigez tous les liens brisés avant de traduire
   • Vérifiez que les liens internes pointent vers les articles/pages corrects

2. Vérifiez que toutes les images existent et sont optimisées

   • Vérifiez que toutes les images se chargent correctement
   • Assurez-vous que les images ont un texte alt approprié pour l'accessibilité et le SEO
   • Vérifiez que les tailles de fichiers des images sont raisonnables (pas trop grandes)
   • Supprimez toutes les images de remplacement ou les références d'images brisées

3. Vérifiez la mise en forme et le style

   • Vérifiez que la mise en forme du texte est cohérente
   • Vérifiez que les titres sont correctement structurés (H1, H2, H3, etc.)
   • Assurez-vous que les listes, les tableaux et autres contenus structurés s'affichent correctement
   • Testez que le style personnalisé et le CSS fonctionnent comme prévu

4. Validez la structure du contenu

   • Assurez-vous d'une utilisation correcte des blocs Gutenberg ou des éléments du constructeur de pages
   • Vérifiez que les custom post types et les taxonomies sont correctement configurés
   • Vérifiez que les métadonnées (custom fields, champs ACF, etc.) sont complètes

5. Recherchez le contenu de remplacement

   • Supprimez tout texte "Lorem ipsum" ou de remplacement
   • Remplacez tout contenu temporaire par les versions finales
   • Assurez-vous que tout le contenu est prêt pour la publication

6. Considérations SEO

   • Vérifiez que les meta titles et les descriptions sont définis
   • Vérifiez que les URLs sont conviviales pour le SEO
   • Assurez-vous d'une utilisation correcte des titres pour la structure SEO

​

Configurer le remplacement des liens internes

Lors de la traduction du contenu, les liens internes doivent être mis à jour pour pointer vers les versions traduites. Gato AI Translations for Polylang peut gérer cela automatiquement pour vous.

Le plugin vous permet de configurer quels types de liens internes doivent être remplacés :

• Custom Posts : liens vers d'autres articles, pages, custom post types, etc.
• Media : liens vers des éléments multimédias (images, vidéos, etc.)
• Tags : liens vers les pages d'archives des étiquettes
• Categories : liens vers les pages d'archives des catégories
• Users : liens vers les pages des auteurs

Comment configurer :

1. Accédez à la page Paramètres, sous Plugin Configuration > Internal Links Replacement
2. Activez uniquement les types de liens que vous utilisez réellement dans votre contenu
3. Enregistrez vos paramètres

​

Vérifiez que tous les liens utilisent des URLs correctes

Pour que la fonctionnalité de remplacement des liens internes fonctionne correctement, tous les liens de votre contenu doivent utiliser le format d'URL approprié. Cela s'applique aux liens dans :

• Le contenu des articles/pages (blocs Gutenberg, HTML, etc.)
• Les widgets Elementor et les meta fields
• Les éléments Bricks builder et les meta fields
• Les custom fields et les métadonnées

Exigences d'URL :

1. Les URLs doivent inclure le domaine complet

   • ✅ Correct : https://www.mysite.com/hello-world/
   • ❌ Incorrect : /hello-world/ (URL relative)
   • ❌ Incorrect : hello-world/ (pas de domaine ni de protocole)

2. Les URLs doivent pointer vers le slug actuel

   • Si vous avez modifié le slug d'un article, mettez à jour tous les liens pour utiliser le nouveau slug
   • WordPress doit être capable de récupérer l'article à partir de l'URL
   • Les anciens slugs qui redirigent ne fonctionneront pas pour le remplacement des liens

3. Les URLs doivent utiliser le domaine correct (sans redirections)

   • ✅ Correct : https://www.mysite.com/hello-world/
   • ❌ Incorrect : https://mysite.com/hello-world/ (si votre site utilise www)
   • Le plugin a besoin du domaine exact pour faire correspondre et remplacer les liens correctement

​

Choisir le statut Brouillon ou Publié

Lorsque les traductions sont créées, vous devez décider si elles doivent être publiées immédiatement ou enregistrées comme brouillons pour révision d'abord.

Par défaut, les traductions sont enregistrées comme brouillons. Pour que les traductions soient immédiatement publiées, accédez à la page Paramètres, sous Plugin Configuration > General Configuration, et définissez l'option Status when translated sur Publish ou Same as origin post (si l'article d'origine est déjà publié).

​

Prise en charge des langues de droite à gauche (RTL)

Si vous traduisez vers des langues de droite à gauche comme l'hébreu, l'arabe, le farsi ou l'ourdou, vous devez vous assurer que votre thème prend correctement en charge les mises en page RTL.

Ce qu'affecte RTL :

Les langues RTL nécessitent plus que de simples changements de direction du texte. Votre thème doit gérer :

• Direction de la mise en page : les éléments doivent s'écouler de droite à gauche
• Alignement du texte : le texte doit être aligné à droite par défaut
• Ajustements d'espacement : margin-left doit devenir margin-right, padding-left doit devenir padding-right, etc.
• Navigation : les menus et la navigation doivent s'écouler RTL
• Formulaires : les champs de saisie et les boutons doivent s'aligner correctement
• Icônes et images : peuvent nécessiter une mise en miroir ou un repositionnement

Ce qui est déjà géré :

• Polylang définit automatiquement la direction de langue correcte (attribut dir="rtl")
• La traduction du contenu fonctionne de manière identique pour les langues RTL et LTR
• Gato AI Translations traduit le contenu correctement quelle que soit la direction du texte

Ce que vous devez vérifier :

1. Prise en charge RTL du thème : testez votre thème avec une langue RTL pour voir s'il la gère correctement

   • De nombreux thèmes modernes incluent des feuilles de style RTL
   • Consultez la documentation de votre thème pour les informations sur la prise en charge RTL
   • Recherchez des fichiers rtl.css ou similaires dans votre thème

2. CSS personnalisé : vérifiez tout CSS personnalisé que vous avez ajouté

   • Les valeurs gauche/droite codées en dur peuvent nécessiter des ajustements
   • Envisagez d'utiliser des propriétés logiques (margin-inline-start au lieu de margin-left)

3. Compatibilité des constructeurs de pages : si vous utilisez Elementor, Bricks ou d'autres constructeurs de pages

   • Vérifiez s'ils prennent en charge les mises en page RTL
   • Testez les mises en page en mode RTL avant de traduire

Si votre thème ne prend pas bien en charge RTL, vous devrez peut-être passer à un thème compatible RTL, ajouter du CSS RTL personnalisé, ou utiliser un plugin qui ajoute la prise en charge RTL.

​

Identifier le contenu des plugins tiers à traduire

De nombreux plugins WordPress créent leurs propres Custom Post Types (CPTs) pour stocker du contenu (par exemple : les produits WooCommerce, les événements Events Calendar, les cours LearnDash, etc.).

Avant de traduire, vous devez :

1. Identifier quels CPTs contiennent du contenu à traduire

   • Examinez vos plugins actifs et leurs CPTs
   • Déterminez lesquels nécessitent une traduction (tous ne le nécessitent pas)

2. Vous assurer que les CPTs et taxonomies concernés sont traduisibles

   • Accédez à Languages > Settings > Custom post types and Taxonomies de Polylang
   • Activez la traduction pour les CPTs et taxonomies concernés

​

Créer automatiquement des entrées de traduction pour les CPTs

Si un CPT s'appuie sur la méthode wp_insert_post pour créer des entrées, vous pouvez accéder à la page Paramètres, sous Plugin Configuration > General Configuration, et activer l'option Automatic creation of translation entries pour ce CPT afin que le plugin crée les entrées de traduction automatiquement.

​

Vérifiez que votre plugin SEO est pris en charge

Les métadonnées SEO (meta titles, descriptions, balises Open Graph, etc.) sont essentielles pour le SEO multilingue. Gato AI Translations for Polylang inclut une prise en charge intégrée des plugins SEO les plus populaires, traduisant automatiquement toutes les métadonnées liées au SEO.

Le plugin prend en charge 8 plugins SEO majeurs :

1. All in One SEO
2. Rank Math
3. SEO Simple Pack
4. SEOPress
5. Slim SEO
6. The SEO Framework
7. WP Meta SEO
8. Yoast SEO

Si vous utilisez un plugin SEO qui ne figure pas dans la liste ci-dessus, vous devez indiquer quelles meta keys synchroniser et traduire, correspondant au plugin SEO que vous utilisez. Tout plugin qui stocke ses métadonnées dans la table wp_postmeta est pris en charge.

​

Choisir votre fournisseur et modèle d'IA

La qualité de vos traductions dépend du service IA et du modèle que vous choisissez.

Les services IA modernes (comme ChatGPT, Claude et Gemini) produisent des traductions significativement meilleures que les services hérités (Google Translate ou DeepL) car ils comprennent mieux le contexte, le ton et les nuances ; préservent correctement la structure HTML et la mise en forme ; ne traduisent pas incorrectement les URLs ou les liens relatifs ; maintiennent le style d'écriture et la voix dans toutes les traductions ; et gèrent mieux les termes techniques et le langage spécifique au domaine.

Vous pouvez choisir parmi les services IA suivants :

• ChatGPT (OpenAI)
• Claude (Anthropic)
• DeepSeek
• Gemini (Google)
• Mistral AI
• OpenRouter (agrégateur de LLMs offrant accès à tous les grands modèles, dont Grok et Llama)
• LLM auto-hébergé (hébergé sur votre propre serveur, par exemple via Ollama)

Nous recommandons d'utiliser les dernières versions de modèles disponibles (par exemple : ChatGPT 5.2 plutôt que 5.0), car les modèles plus récents fournissent systématiquement une meilleure qualité de traduction.

Vous pouvez utiliser OpenRouter pour accéder aux derniers modèles d'IA dès qu'ils sont lancés.

​

Envisagez de personnaliser votre prompt de traduction IA

Le prompt de traduction par défaut fonctionne bien pour la plupart des contenus, mais le personnaliser peut améliorer la qualité de la traduction pour votre cas d'utilisation spécifique.

Exemple :

Un blog de voyage pourrait personnaliser son prompt en ajoutant ce qui suit :

Translate to a natural, flowing, easy-to-read, casual blog-style language. Keep original content structure, meaning, and styling (but do adjust sentence structure and style to be relevant to the target language).
 
Lightly improve boring parts - Add curiosity triggers, light humor, and light slang (as fits the target language), like a human travel blogger would write.Copy

Vous pouvez modifier le prompt par défaut, ou créer plusieurs prompts IA personnalisés et sélectionner celui à utiliser dans les Paramètres :

​

Auditez vos blocs Gutenberg

Avant de traduire, vous devez identifier quels blocs vous utilisez et vous assurer qu'ils sont pris en charge pour la traduction.

Blocs Gutenberg pris en charge nativement :

• Tous les blocs du core WordPress : Paragraph, Heading, List, Quote, Image, Gallery, etc.
• Blocs tiers : blocs des plugins Yoast SEO, GenerateBlocks, Kadence, Greenshift, etc.

Si vous utilisez un bloc non pris en charge qui contient des chaînes à traduire, vous pouvez soit :

• Ajouter une intégration pour traduire le bloc, ou
• Le remplacer par un bloc pris en charge (par exemple, remplacer un bloc de témoignage personnalisé par une alternative prise en charge).

Remarque : il existe des blocs qui ne peuvent pas être traduits.

Si vous devez remplacer un bloc non pris en charge, vous voudrez trouver tous les articles qui l'utilisent. Consultez le tutoriel sur la recherche des articles contenant un certain bloc pour les méthodes permettant d'identifier où des blocs spécifiques sont utilisés.

​

Auditez vos widgets Elementor

Si vous utilisez le constructeur de pages Elementor, vous devez auditer quels widgets vous utilisez et vous assurer qu'ils sont pris en charge pour la traduction. Le processus est similaire à l'audit des blocs Gutenberg, mais spécifique aux widgets Elementor.

Tous les widgets du core d'Elementor sont pris en charge nativement.

Si vous avez des widgets non pris en charge :

• Ajoutez une intégration pour traduire le widget, ou
• Remplacez-le par un widget pris en charge

​

Auditez vos éléments Bricks

Si vous utilisez le constructeur de pages Bricks, vous devez auditer quels éléments vous utilisez et vous assurer qu'ils sont pris en charge pour la traduction. Le processus est similaire à l'audit des blocs Gutenberg, mais spécifique aux éléments Bricks.

Tous les éléments du core de Bricks sont pris en charge nativement.

Si vous avez des éléments non pris en charge :

• Ajoutez une intégration pour traduire l'élément, ou
• Remplacez-le par un élément pris en charge

​

Gérer les images contenant du texte

Un oubli courant lors de la traduction de sites web est d'oublier que les images peuvent contenir du texte qui peut nécessiter une traduction.

Lorsque vous traduisez un article, les images sont copiées dans la version traduite, et les métadonnées des images (titre, texte alt, légende) sont traduites, mais tout texte dans ces images reste dans la langue d'origine.

Pour auditer vos images, la façon la plus simple est de passer la Médiathèque WordPress en mise en page Grille — cela vous permet de parcourir visuellement toutes vos images d'un coup d'œil et de repérer rapidement celles qui contiennent du texte intégré dans la mauvaise langue.

Par exemple, cette image contient du texte en hébreu, ce qui la rend inadaptée aux autres langues.

Vos options :

1. Conserver le texte intégré (si la langue peut encore être généralement comprise)

   • Convient lorsque le texte est dans une langue largement comprise ou utilise des symboles/chiffres universels
   • Aucun travail supplémentaire requis

2. Supprimer le texte des images

   • Utilisez des images sans texte intégré

3. Utiliser des superpositions de texte au lieu de texte intégré

   • Utilisez des images sans texte intégré
   • Superposez du texte (en utilisant des blocs Gutenberg, des widgets Elementor, des éléments Bricks ou du CSS) qui sera automatiquement traduit

4. Créer des versions traduites des images

   • Créez des fichiers image séparés pour chaque langue
   • Remplacez manuellement les images dans les articles traduits

​

Gérer la traduction des données utilisateur supplémentaires

Polylang peut gérer le champ biographie pour les profils utilisateur WordPress, mais si vous avez des données utilisateur supplémentaires stockées dans des custom fields (via ACF, Meta Box ou d'autres moyens), vous aurez besoin d'une approche spéciale.

Si vous avez des données utilisateur qui nécessitent une traduction (par exemple, des titres de poste, des qualifications, des descriptions, etc.), vous devrez créer des champs séparés pour chaque langue.

1. Créer des champs séparés pour chaque langue

   • En utilisant ACF ou Meta Box, créez des champs comme :
     • Qualification EN
     • Qualification FR
     • Qualification DE
     • etc.

2. Mettre à jour votre thème pour afficher le bon champ

   • Modifiez vos modèles de thème pour vérifier la langue actuelle
   • Affichez le champ approprié selon la langue active
   • Exemple de code PHP :

     $current_lang = pll_current_language();
     $qualification = get_field("qualification_{$current_lang}", 'user_' . $user_id);
     echo $qualification;Copy

3. Remplir les champs manuellement

   • Après avoir traduit le contenu, mettez à jour manuellement les champs de profil utilisateur

​

Ignorer la traduction des termes qui ne doivent pas être traduits

Certains termes ne doivent jamais être traduits — noms de marques, noms propres, termes techniques ou terminologie spécifique au domaine.

Vous pouvez ignorer la traduction de ces termes en ajoutant des instructions à votre prompt personnalisé, par exemple :

Do not translate the following types of terms:
- Hotel names (e.g., "Grand Hotel", "Beach Resort")
- Restaurant names
- Brand names
- Technical acronyms (API, SEO, CMS, etc.)
 
Keep these terms exactly as they appear in the original text.Copy

​

Éviter les étiquettes en double entre les langues

Notre contenu peut avoir des étiquettes représentant le même concept dans deux langues différentes. Lorsque ces étiquettes sont traduites, elles peuvent créer des doublons ou des conflits.

Par exemple, si vous avez un site web chinois traduit en anglais, et que vous avez à la fois une étiquette 布宜诺斯艾利斯 (Buenos Aires en chinois) et une étiquette Buenos Aires en anglais, lors de la traduction en anglais, les deux étiquettes deviennent buenos-aires. Cela crée une situation d'étiquette dupliquée.

Comment corriger avant de traduire :

1. Auditez vos étiquettes

   • Examinez toutes les étiquettes dans votre langue d'origine
   • Identifiez les étiquettes qui pourraient être des doublons d'étiquettes dans d'autres langues
   • Recherchez les étiquettes qui représentent le même concept mais dans des langues différentes

2. Consolidez les étiquettes

   • Choisissez une version de langue à conserver (généralement votre langue d'origine)
   • Fusionnez ou supprimez les étiquettes dupliquées
   • Mettez à jour les articles pour utiliser l'étiquette consolidée

3. Nettoyez avant de traduire

   • Assurez-vous que votre contenu d'origine n'a que des étiquettes dans la langue d'origine
   • Supprimez toutes les étiquettes dans les langues cibles du contenu d'origine
   • Cela évite les conflits lors de la traduction

​

Éviter les noms de lieux en double entre les langues

Si votre contenu utilise des titres qui mélangent les scripts, vous pouvez voir ce schéma : le titre commence par un nom de lieu local, puis le même nom en lettres latines entre parenthèses, puis le reste de la ligne.

Schéma d'origine typique (exemple) :

• Origine (par exemple en hébreu) : פוקט (Pouket) - מדריך לאי היפה — nom local, puis une orthographe anglaise ou internationale entre parenthèses, puis le sous-titre.
• Traduit (par exemple en anglais) : Pouket (Pouket) - beautiful island guide.

Après la traduction, le titre est déjà dans une langue et un script, de sorte que le rendu littéral du modèle répète le même nom de lieu deux fois (par exemple Pouket (Pouket)).

Solution : affiner le prompt de traduction

Personnalisez votre prompt pour que le modèle normalise les ouvertures redondantes "Nom (MêmeNom)" lorsque la parenthèse n'apporte aucune nouvelle information. Par exemple, ajoutez des instructions comme :

If a heading begins with a place name followed by the same translated name in parentheses, remove the duplicate and keep one natural version. Do not remove the parenthesis if the text inside uses a different script, a different spelling, or includes additional descriptive information.Copy

​

Faites attention aux slugs de vos étiquettes/catégories

Si les slugs de vos étiquettes ou catégories sont déjà dans la langue cible, vous pourriez supposer qu'il n'y a rien à traduire.

C'est souvent bien — mais il y a un problème avec Polylang free (non Pro).

Avec Polylang Pro, les termes traduits peuvent réutiliser le même slug entre les langues. Avec la version gratuite, WordPress impose des slugs uniques dans l'ensemble, de sorte que le slug du terme traduit reçoit automatiquement un suffixe -2.

Par exemple : une catégorie avec le slug travels_and_attractions en hébreu, lors de sa traduction en anglais, devient travels_and_attractions-2 au lieu de conserver le même slug.

Si cela affecte vos URLs ou votre SEO, vous devrez corriger manuellement les slugs après la traduction, ou passer à Polylang Pro pour permettre la réutilisation des slugs entre les langues.

​

Assurez-vous que vos intégrations sont dans une langue acceptable

Si vous intégrez du contenu tiers — comme Google Maps, des widgets de réseaux sociaux ou d'autres iframes de plateformes — vérifiez que l'intégration s'affiche dans la langue cible.

Par exemple, une intégration Google Maps configurée pour l'hébreu affichera toujours des étiquettes hébraïques, des noms de rues et une interface en hébreu même après avoir traduit le reste de la page en anglais. Dans ce cas, vous voudrez peut-être utiliser une intégration agnostique à la langue.

La même chose s'applique à toute plateforme ou service qui génère des intégrations spécifiques à une langue (par exemple, les chapitres YouTube, les widgets d'avis, les formulaires de réservation). Vérifiez toujours chaque intégration après la traduction.

​

Assurez-vous qu'il n'y a pas de style spécifique à une langue dans le contenu d'origine

Le contenu des articles écrit pour une langue spécifique — en particulier les langues RTL comme l'hébreu ou l'arabe — peut inclure des attributs de direction et de langue en ligne appliqués directement aux éléments HTML. Lorsque ce contenu est traduit dans une autre langue, ces styles codés en dur se propagent et brisent la mise en page.

Coupables courants dans le contenu d'origine RTL :

• <div dir="rtl" lang="he"> — force la direction RTL et marque la langue comme hébreu sur toute une section
• <p dir="rtl"> — force l'alignement RTL sur des paragraphes individuels
• <h2 style="text-align: right;"> — code en dur l'alignement à droite sur les titres

Lorsque ce contenu est traduit en anglais (ou dans toute langue LTR), le texte devient anglais mais la mise en page s'affiche toujours de droite à gauche — entraînant des titres désalignés, un flux de texte inversé et une mise en forme brisée.

Avant de traduire, auditez votre contenu d'origine à la recherche de ces attributs et supprimez-les. Laissez le thème et les paramètres de langue/locale de WordPress contrôler globalement la direction et l'alignement, plutôt que de les intégrer dans des blocs de contenu individuels.

​

Gérer les modèles Theme Builder d'Elementor

Si vous utilisez le Theme Builder d'Elementor pour créer des modèles globaux (en-têtes, pieds de page, modèles de post unique, modèles d'archive, etc.), il est important de comprendre comment ces modèles sont gérés lors de la traduction.

Ce qui est traduit :

• Menus : les éléments de menu sont remplacés par les versions de menu traduites
• Contenu dynamique : le contenu extrait des articles/pages est traduit (puisque le contenu source est traduit)

Ce qui n'est pas traduit :

• Texte codé en dur : tout texte ajouté directement au modèle (pas du contenu dynamique) N'EST PAS traduit
• Texte des widgets : le texte dans les widgets comme les titres, les paragraphes, les boutons, etc. reste dans la langue d'origine
• HTML personnalisé : tout bloc HTML personnalisé ou de code reste non traduit

Exemple :

Ce modèle d'en-tête Elementor contient du texte codé en dur ("Our Phone Number:") :

Solution :

Concevez les modèles pour utiliser uniquement :

• Des menus (qui sont remplacés automatiquement)
• Des images (qui sont agnostiques à la langue)
• Du contenu dynamique (qui provient des articles traduits)
• Évitez d'ajouter tout texte, titre ou description codé en dur directement dans les modèles

Cela garantit que les éléments globaux de votre site (en-têtes, pieds de page, etc.) fonctionnent correctement dans toutes les langues.

​

Configurer Advanced Custom Fields (ACF)

Si vous utilisez Advanced Custom Fields (ACF), vous devez configurer comment chaque champ doit être géré lors de la traduction. Les champs ACF peuvent contenir divers types de contenu, et chaque type peut nécessiter un traitement différent.

Dans la section Gato Translate, les champs ACF peuvent être définis sur l'une de ces options :

1. (Do nothing) : le champ est ignoré de la traduction ou de la synchronisation

2. Translate : le contenu du champ est traduit dans la langue cible

   • À utiliser pour : les champs de texte, les champs textarea, les champs WYSIWYG et tout champ contenant du texte traduisible

3. Copy : la valeur du champ est copiée telle quelle dans la traduction (pas traduite)

   • À utiliser pour : les chiffres, les dates, les cases à cocher, les champs vrai/faux et tout champ qui ne doit pas être traduit

4. Translate Reference : le champ fait référence à une autre entité (article, page, utilisateur, etc.), et la référence est mise à jour pour pointer vers la version traduite

   • À utiliser pour : les champs Post Object, Page Link, Relationship, User et Taxonomy

Si vous utilisez Polylang Pro, vous devez également désactiver ses fonctionnalités de traduction ACF pour permettre à Gato AI Translations de gérer la traduction à la place.

​

Configurer Meta Box

Si vous utilisez Meta Box (un autre plugin populaire de champs personnalisés), le processus de configuration est similaire à ACF. Les champs Meta Box doivent également être configurés pour la traduction, la copie ou la traduction de référence.

Dans la section Gato Translate, les champs Meta Box peuvent être définis sur l'une de ces options :

1. (Do nothing) : le champ est ignoré de la traduction ou de la synchronisation
2. Translate : le contenu du champ est traduit
3. Copy : la valeur du champ est copiée telle quelle
4. Translate Reference : la référence du champ est mise à jour pour pointer vers l'entité traduite

Vous devez également désactiver les fonctionnalités de traduction Meta Box de Polylang pour permettre à Gato AI Translations de gérer la traduction à la place.

​

Configurer les champs meta personnalisés

Au-delà d'ACF, Meta Box et des plugins SEO, votre site peut avoir d'autres champs meta personnalisés provenant de :

• Du code personnalisé
• D'autres plugins
• Des custom fields WordPress (le metabox Custom Fields de base)

Ces champs meta doivent être configurés manuellement dans les paramètres du plugin.

Identification des meta keys personnalisées :

1. Exportez votre contenu

   • Accédez à Outils > Exporter dans WordPress
   • Exportez tous les types de contenu que vous prévoyez de traduire
   • Cela crée un fichier XML avec tout votre contenu et vos métadonnées

2. Analysez le fichier d'exportation

   • Ouvrez le fichier XML dans un éditeur de texte
   • Recherchez les balises <wp:postmeta>
   • Listez toutes les meta keys uniques

3. Filtrez les champs connus

   • Supprimez les champs ACF (généralement préfixés par le nom de votre field group)
   • Supprimez les champs Meta Box
   • Supprimez les champs du core WordPress (par exemple, _edit_last, _wp_old_slug, _thumbnail_id)
   • Supprimez les champs des plugins SEO (si vous utilisez un plugin SEO pris en charge)

4. Identifiez ce qui reste

   • Ce sont vos champs meta personnalisés
   • Déterminez ce que contient chaque champ et comment il doit être géré

Déterminer les besoins de traduction :

Pour chaque champ meta personnalisé, déterminez :

• Translate : contient du texte traduisible (titres, descriptions, contenu)
• Copy : contient des données qui ne doivent pas être traduites (IDs, chiffres, paramètres)
• Translate Reference : contient des IDs d'entités qui doivent pointer vers les versions traduites

Configuration dans le plugin :

1. Accédez aux Paramètres, sous l'onglet Meta Configuration
2. Choisissez l'option de traduction (Translate/Copy/Translate Reference)
3. Ajoutez les noms des meta keys personnalisées, en utilisant une correspondance exacte ou un motif regex

​

Exécuter le processus de traduction

Maintenant que toutes les préparations sont terminées, il est temps d'exécuter les traductions.

​

Testez d'abord le processus

Avant de vous lancer dans la traduction de l'intégralité de votre site web, il est crucial de tester le processus à petite échelle d'abord. Cette approche vous fera gagner du temps et empêchera les problèmes d'être répliqués sur tout votre contenu.

Voici le flux de travail de test recommandé :

1. Commencez avec un seul article et une seule langue

   • Choisissez un article représentatif qui inclut divers types de contenu (texte, images, liens, etc.)
   • Traduisez-le dans une seule langue cible que vous comprenez bien
   • Validez la traduction en détail : vérifiez chaque bloc, chaque lien, chaque image et chaque élément de métadonnées
   • Si vous découvrez un problème (par exemple, un bloc n'a pas été traduit, un lien n'a pas été remplacé, la mise en forme a été brisée), corrigez-le avant de continuer. Le même problème sera répliqué pour toutes les langues si vous ne le traitez pas maintenant.

2. Élargissez à quelques articles supplémentaires

   • Une fois la première traduction parfaite, traduisez 3 à 5 articles supplémentaires dans la même langue
   • Validez chacun d'eux minutieusement
   • Cela vous aide à identifier les schémas ou les problèmes récurrents

3. Testez avec des langues supplémentaires

   • Si vous traduisez dans plusieurs langues, testez avec une autre langue pour vous assurer que tout fonctionne entre différentes paires de langues

4. Procédez ensuite à la traduction en masse

   • Une fois que vous êtes confiant que tout fonctionne correctement, vous pouvez procéder à la traduction du reste de votre site web

Cette approche incrémentale garantit que tout problème de configuration ou de contenu est détecté tôt, lorsqu'il est facile à corriger.

​

Ordre de traduction

L'ordre dans lequel vous traduisez différents types de contenu est important, surtout lorsque le contenu fait référence à d'autres contenus.

Traduisez le contenu dans cet ordre spécifique pour éviter les problèmes de référence :

1. Users

   • Les descriptions d'utilisateurs peuvent être incluses dans des blocs

2. Taxonomies (Tags/Categories)

   • Les étiquettes et les catégories (et les taxonomies personnalisées) sont souvent référencées par les articles, elles doivent donc exister avant que les articles soient traduits

3. Media

   • Les éléments multimédias (images, vidéos, documents) sont référencés par les articles comme images à la une ou images de galerie, traduisez-les donc avant les articles

4. Custom Post Types

   • Traduisez les articles, les pages et les autres CPTs
   • Important : si un CPT fait référence à un autre, traduisez dans l'ordre de dépendance inverse
   • Par exemple : si les articles utilisent des Blocs réutilisables, traduisez d'abord les Blocs réutilisables, puis les Articles

5. Menus

   • Traduisez les menus en dernier, car ils font référence aux articles, aux pages et aux catégories

​

Décidez si vous voulez traduire les slugs ou non

Traduire les slugs des articles et des taxonomies dans la langue cible est souvent souhaitable pour les langues à script latin (par exemple, le français, l'allemand, l'espagnol) : le chemin reste lisible et vous pouvez refléter des mots-clés localisés dans l'URL.

Pour les scripts non latins — l'hébreu, le japonais, le chinois et similaires — les slugs localisés se transforment souvent en un désordre : des translittérations maladroites, des segments très longs, un encodage en pourcentage ou des URLs difficiles à partager et à comparer. De nombreuses équipes conservent des slugs latins (ou dans la langue d'origine) pour ces langues et s'appuient sur le titre traduit pour le nom visible et localisé.

Traitez la traduction des slugs comme une politique par langue cible, pas comme un simple interrupteur on/off pour tout le site :

1. Divisez les langues en groupes — par exemple, "traduire les slugs" pour les cibles latines vs "ne pas traduire les slugs" pour le chinois, le japonais, l'hébreu, etc.
2. Exécutez des lots de traduction séparés — traduisez en masse vers un groupe avec la traduction des slugs activée, puis exécutez un autre lot vers l'autre groupe avec la traduction des slugs désactivée.
3. Configurez chaque lot via Gato Translate (Custom) (couvert sous Comment exécuter les traductions ci-dessous) : désactivez des options comme Translate custom post slugs? et Translate tag and category slugs? pour les lots où vous souhaitez garder les slugs inchangés. Visez une politique par exécution (par exemple, une langue ou un groupe de langues partageant la même règle) afin que les paramètres correspondent au résultat attendu.

Pour les flux de travail scriptés ou répétables, WP-CLI prend en charge --translate-slugs=true ou --translate-slugs=false par invocation.

​

Traduction en deux passes

Si vous avez activé le remplacement des liens internes ou la traduction des références d'entités, vous devrez peut-être traduire en deux passes :

Passe 1 : traduire uniquement les propriétés

1. Configurez la traduction pour exclure le contenu et les meta, c'est-à-dire traduire uniquement les propriétés (titre/nom et slug)
2. Exécutez la traduction

Après l’exécution de la première passe, les articles traduits seront créés avec leurs URLs et IDs traduits, permettant aux URLs de liens internes et aux IDs de références d'entités d'être résolus dans la langue cible.

Passe 2 : traduire uniquement le contenu et les meta

1. Configurez la traduction pour traduire uniquement le contenu et les meta (c'est-à-dire exclure les propriétés)
2. Exécutez à nouveau la traduction

Après l’exécution de la deuxième passe, le contenu et les meta restants seront traduits, et les URLs de liens internes et les IDs de références d'entités seront remplacés par les versions traduites.

​

Comment exécuter les traductions

Option 1 : Administration WordPress (Bulk Actions)

1. Accédez à la liste de contenu (Articles, Pages, Médias, etc.)
2. Sélectionnez les éléments que vous souhaitez traduire
3. Choisissez Gato Translate dans le menu déroulant des bulk actions
4. Cliquez sur Appliquer

Alternative : Gato Translate (Custom)

Pour plus de contrôle, utilisez Gato Translate (Custom) qui vous permet de remplacer les paramètres pour cette exécution de traduction spécifique :

Cela ouvre une page de paramètres personnalisés où vous pouvez fournir des options spécifiques pour cette exécution de traduction :

Option 2 : WP-CLI (pour les grands lots)

Pour les grands sites web comptant des centaines ou des milliers d'éléments, WP-CLI est une alternative pratique.

Vous pouvez exécuter des traductions par lots via la ligne de commande, puis vous pouvez exécuter les traductions en arrière-plan, pendant que vous travaillez sur autre chose.

​

Vérification des logs de traduction

Lorsqu'une traduction échoue (en raison de la mise hors ligne de l'API, du manque de crédits API, etc.) ou produit des avertissements, vous verrez un badge de notification dans le menu du plugin :

Consultez les logs de traduction pour comprendre ce qui s'est passé :

1. Accédez à l'élément de menu Logs dans le menu du plugin
2. Examinez les erreurs ou les avertissements
3. Corrigez les problèmes avant de continuer

​

Réexécuter les traductions échouées

Chaque fois qu'une traduction échoue, vous pouvez redéclencher la traduction de cette entrée et de cette langue uniquement, et éviter de dépenser des crédits API pour les traductions qui ont réussi.

Les traductions échouées sont mises en évidence avec un fond jaune sur l'icône d'édition de Polylang :

Vous pouvez filtrer pour n'afficher que les entrées avec des traductions échouées :

Pour retraduire uniquement les entrées échouées, utilisez la bulk action Gato Translate (Custom) avec l'option Process failed translations only :

​

Valider la qualité et l’exhaustivité de la traduction

Après avoir traduit le contenu, il est crucial de valider que les traductions ont été réussies et de bonne qualité. Ne supposez pas que tout a fonctionné parfaitement — prenez le temps de vérifier.

Validation dans l'éditeur :

Ouvrez les articles traduits dans l'éditeur WordPress et vérifiez :

1. Traduction du contenu

   • Tout le texte est-il traduit ? (pas seulement le titre)
   • Tous les blocs/widgets/éléments sont-ils traduits ?
   • Vérifiez les blocs Gutenberg, les widgets Elementor ou les éléments Bricks
   • Vérifiez que la mise en forme est préservée

2. Champs personnalisés

   • Les champs ACF sont-ils correctement traduits/copiés/référencés ?
   • Les champs Meta Box sont-ils correctement gérés ?
   • Les champs meta personnalisés sont-ils correctement configurés ?

3. Métadonnées SEO

   • Vérifiez que les meta titles sont traduits
   • Vérifiez que les meta descriptions sont traduites
   • Confirmez que les balises Open Graph sont traduites
   • Examinez tout autre champ du plugin SEO

4. Médias

   • Les images à la une sont-elles correctement définies ?
   • Les images dans le contenu pointent-elles vers les versions traduites (le cas échéant) ?
   • Les textes alt des images sont-ils traduits ?

5. Liens

   • Les liens internes pointent-ils vers les versions traduites ?
   • Les liens externes sont-ils correctement préservés ?
   • Les liens de catégories/étiquettes fonctionnent-ils ?

Validation sur le frontend :

Affichez les articles traduits dans le navigateur et vérifiez :

1. Apparence visuelle

   • La page s'affiche-t-elle correctement ?
   • La mise en page est-elle préservée ?
   • Les images s'affichent-elles correctement ?
   • Le style est-il correct ?

2. Application des modèles

   • Le bon modèle est-il utilisé ?
   • L'en-tête/pied de page s'affichent-ils correctement ?
   • Les barres latérales/widgets s'affichent-ils ?
   • Le menu affiche-t-il la version traduite ?

3. Fonctionnalité

   • Tous les liens fonctionnent-ils ?
   • Les formulaires fonctionnent-ils ?
   • Les éléments interactifs fonctionnent-ils ?
   • La navigation est-elle correcte ?

4. Éléments spécifiques à la langue

   • Pour les langues RTL, la mise en page est-elle correcte ?
   • Les polices s'affichent-elles correctement ?
   • La direction du texte est-elle correcte ?

Qualité de la traduction :

La traduction IA moderne est généralement très bonne, mais vous devriez quand même vérifier :

1. Les langues que vous comprenez

   • Lisez les traductions dans les langues que vous connaissez
   • Vérifiez l’exactitude, le ton et le style
   • Vérifiez que les termes techniques sont corrects
   • Assurez-vous que la voix de la marque est maintenue

2. Les langues que vous ne comprenez pas

   • Pour les langues que vous ne parlez pas, envisagez d'engager un locuteur natif pour les vérifier
   • Cela est particulièrement important pour les langues très différentes de la vôtre (par exemple, de l'anglais au coréen, au chinois, à l'arabe)
   • Même une révision rapide peut détecter les problèmes majeurs
   • Une relecture professionnelle est recommandée pour le contenu important

3. Contenu spécifique au domaine

   • Le contenu technique peut nécessiter une révision par des experts
   • Le contenu juridique/médical doit être revu par des professionnels
   • Le contenu marketing peut nécessiter des ajustements de la voix de la marque

​

Réparer les blocs "Invalid Content"

Lors de la traduction de grands blobs HTML contenant de nombreuses balises et attributs, les services IA peuvent parfois renvoyer une réponse qui brise la sortie du bloc.

Par exemple, lors de la traduction d'un bloc core/paragraph contenant un très grand blob HTML en utilisant ChatGPT 5.0 mini, comme celui-ci :

<!-- wp:paragraph -->
<p>
  Pédagogie: 
  <mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">
  <mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">
  <mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">
  <mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">★★★★
  <mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">
  <mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">
  <mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">☆</mark></mark></mark></mark></mark></mark></mark><strong><br></strong>Support : 
  <mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">
  <mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">
  <mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">
  <mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">★★★★
  <mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">
  <mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">
  <mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">☆</mark></mark></mark></mark></mark></mark></mark><br>Coûts : 
  <mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">
  <mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">
  <mark style="background-color:rgba(0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">
  <mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">★★★★
  <mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">
  <mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">
  <mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">☆</mark></mark></mark></mark></mark></mark></mark><br>Débouchés : 
  <mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">
  <mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">★★★★
  <mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">
  <mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">
  <mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">☆</mark></mark></mark></mark></mark>
</p>
<!-- /wp:paragraph -->Copy

...la réponse pourrait introduire une balise <mark> supplémentaire qui n'était pas présente dans le contenu original :

<mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">
<mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">★★
+<mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">
<mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">
<mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">Copy

Lors de l'édition de l'article dans l'éditeur WordPress, ce bloc peut ne pas s'afficher et afficher à la place le message "Block contains unexpected or invalid content" :

Cliquer sur Attempt recovery résoudra très probablement le problème.

​

Résoudre les erreurs de données corrompues

Occasionnellement, vous pouvez rencontrer des erreurs lors de la traduction parce que votre contenu contient des données corrompues ou périmées. Cela se produit généralement lorsque :

• Un type d'article prenait auparavant en charge une fonctionnalité (comme les articles parents) mais ne le fait plus
• Le contenu fait référence à des entités qui n'existent plus
• Des incohérences dans la base de données résultant de migrations ou de changements de plugins
• Des relations orphelines dans les custom fields

Comprendre l'erreur :

Lorsque vous voyez une erreur comme celle-ci dans les logs :

2025-10-25T03:40:38+00:00 Error [Query "create-missing-translation-media"] Execution with errors: 🔴 Object with ID '26061' (of type 'GenericCustomPost') cannot be loaded. Please check if referencing this ID is stale data (i.e. still stored on the WordPress database, but pointing to a non-existing object) and, if so, remove it or fix it.Copy

Cela signifie :

• Le contenu fait référence à une entité (article, page, média, etc.) avec l'ID 26061
• Cette entité n'existe plus dans la base de données
• Le plugin ne peut pas traduire car il ne peut pas résoudre la référence

Comment corriger :

Méthode 1 : Éditeur WordPress (la plus simple)

1. Ouvrez l'article/l'élément qui échoue à la traduction
2. Identifiez la référence corrompue (vérifiez les custom fields, les relations, etc.)
3. Supprimez ou corrigez la référence
4. Enregistrez l'article
5. Réessayez la traduction

Méthode 2 : Nettoyage de la base de données

Si vous ne pouvez pas le corriger via l'éditeur :

1. Identifiez quel champ contient la mauvaise référence
2. Utilisez un outil de base de données ou un plugin pour supprimer les données périmées
3. Soyez prudent — faites toujours une sauvegarde avant d'apporter des modifications à la base de données

Méthode 3 : Gato GraphQL (avancé)

Comme Gato AI Translations for Polylang utilise Gato GraphQL sous le capot, vous pouvez exécuter des queries GraphQL pour corriger les données corrompues par programmation :

1. Récupérez d'abord les IDs des éléments présentant des problèmes en utilisant une query GraphQL.

2. Puis corrigez le problème en utilisant une mutation. Par exemple, pour supprimer une référence parent d'un élément multimédia :

mutation {
  updateMediaItem( input: { id: 26066, customPostID: null } ) {
    status
    errors {
      __typename
      ...on GenericErrorPayload {
        message
      }
    }
  }
}Copy

Si vous ne pouvez pas le corriger :

Si les données corrompues ne peuvent pas être nettoyées, vous devrez peut-être :

• Recréer l'article/l'élément à partir de zéro
• Exporter le contenu, le nettoyer et le réimporter
• Contacter le support pour obtenir de l'aide avec les cas complexes

​

Intégrer les entrées traduites dans la configuration

Après avoir traduit votre contenu, les entrées traduites nouvellement créées peuvent nécessiter d'être intégrées dans la configuration du site web.

​

Mettre à jour les ACF Field Groups

Les ACF Field Groups peuvent être attribués à des articles, des pages, des catégories, des étiquettes ou d'autres entités spécifiques. Lorsque vous traduisez du contenu, les versions traduites peuvent également nécessiter d'être attribuées aux mêmes field groups.

Après la traduction, mettez à jour les attributions de vos ACF Field Groups pour inclure les versions traduites :

1. Accédez à l'élément de menu Field Groups dans le menu du plugin ACF
2. Modifiez le field group qui s'applique à des entités spécifiques
3. Dans les Location Rules, ajoutez les versions traduites
4. Enregistrez le field group

Exemple :

Un field group s'applique à l'article spécifique "Hello World" dans la langue d'origine :

Après la traduction de l'article, les versions traduites ("Hola Mundo" en espagnol et "你好世界" en chinois) doivent également être attribuées au même field group :

​

C'est tout !

Vous avez maintenant terminé le processus de traduction. Félicitations ! 👏

​

Conclusion

Ce guide complet devrait vous aider à traduire avec succès votre site web WordPress. Si vous avez besoin de plus d'informations, consultez la documentation de Gato AI Translations for Polylang.