Comment traduire un export WPML (fichiers XLIFF dans un ZIP)

Si vous venez d’exporter des tâches de traduction depuis WPML et que vous vous demandez quoi faire de votre fichier ZIP, ce guide est pour vous. Vous n’avez pas besoin de le décompresser, ni d’ouvrir le moindre fichier XLIFF.

Ce que vous avez réellement entre les mains

L’export de WPML est une archive ZIP contenant un seul dossier, nommé posts/, et un fichier .xliff par article. Rien d’autre.

Les chiffres ci-dessous proviennent d’un export réel de 44 articles, mesurés et non estimés, afin que vous puissiez les comparer aux vôtres.

Deux aspects de cette archive surprennent généralement les utilisateurs.

Chaque fichier déclare sa propre paire de langues. L’élément <file> en haut de chaque XLIFF indique la langue source et la langue cible :

<file original="103-3aeb85935a8505760aa368dc691898a7"
      source-language="fr"
      target-language="en"
      datatype="plaintext">

Ainsi, un seul export peut contenir quatre langues cibles différentes simultanément, comme c’est le cas dans l’exemple : du français vers l’anglais, l’allemand, l’espagnol et l’italien. L’archive n’est pas une seule tâche de traduction. Ce sont quatre tâches entremêlées.

WPML vous indique la taille de la tâche. Chaque fichier contient son propre nombre de mots dans un attribut personnalisé :

tool:wpml-words-to-translate-count="843"

Additionnez-les et vous saurez exactement à quoi vous attendre avant de vous lancer. Dans l’exemple : 34 829 mots.

Ce que contient un fichier

Un fichier XLIFF est un fichier XML. Chaque segment de texte traduisible est une unité <trans-unit> avec une source <source> et une cible <target>. Le contenu est encapsulé dans du CDATA pour que le HTML présent dans un article ne corrompe pas le XML.

Voici une unité complète. Celle-ci a déjà été traitée par la mémoire de traduction, comme l’indiquent les attributs state:

<trans-unit resname="title" restype="string" datatype="html" id="title">
  <source><![CDATA[Bien ventiler son logement en hiver]]></source>
  <target state="needs-review-translation" state-qualifier="tm-suggestion">
    <![CDATA[Ventilating your home in winter]]>
  </target>
  <tool:extradata unit="Title" type="text" group="Main Content" group_id="Main_Content-0"/>
</trans-unit>

Les unités dans cet état étaient l’exception lors de l’exportation: 18 sur 228. Les 210 autres ne possèdent aucun attribut state, et leur cible contient le texte source mot pour mot.

Et voici le détail qui détermine votre approche de l’ensemble du projet.

WPML inscrit le texte source dans la cible comme point de départ. Ainsi, un fichier XLIFF où chaque <target> est rempli n’est pas forcément un fichier traduit. Dans l’export réel, 217 des 228 unités contenaient encore le texte source mot pour mot. Seules 18 proposaient une suggestion réelle issue de la mémoire de traduction, marquée state="needs-review-translation".

Si vous parcourez le fichier rapidement, vous pourriez conclure que le travail est terminé. Ce n’est pas le cas.

Les unités que vous trouverez

WPML n’exporte pas uniquement le corps de l’article. Dans l’exemple d’export, les 228 unités se répartissaient ainsi :

Chaque unité comporte également une balise <tool:extradata> précisant sa nature et son groupe d’appartenance, ce qui permet de distinguer une catégorie d’un titre sans avoir à deviner.

Notez les champs du plugin SEO. Vos méta titres et descriptions se trouvent dans cette archive, ce qui est une bonne nouvelle et implique une décision : une méta description traduite littéralement est rarement celle qui génère le clic dans la langue cible.

Notez également URL. Vos slugs sont traduisibles et, dans l’exemple d’exportation, ils ont été délibérément laissés dans la langue source. C’est un vrai choix qui a des conséquences sur vos liens existants, et vous seul pouvez le faire.

Les shortcodes sont déjà déclarés

C’est l’une des meilleures fonctionnalités de WPML et presque personne ne le remarque. L’en-tête de chaque fichier contient une phase listant tous les shortcodes enregistrés sur votre site :

<phase phase-name="shortcodes" process-name="Shortcodes identification">
  <note>wp_caption,caption,gallery,playlist,audio,video,embed,
  wpml_language_switcher,product_brand,...</note>
</phase>

Vos shortcodes personnalisés s’y trouvent aux côtés de ceux de WordPress. C’est une liste lisible par machine d’éléments qui doivent rester intacts après le traitement.

Pourquoi les méthodes évidentes sont problématiques

Les ouvrir un par un signifie devoir chercher les lignes cibles dans le XML, traduire autour des balises HTML et des shortcodes, sauvegarder, et recommencer 43 fois. Puis refaire la même chose pour chacune des trois autres langues.

Les envoyer à un traducteur ou à une agence signifie que le travail linguistique sera impeccable, mais pas la gestion des fichiers. Vous payez le tarif horaire d’un expert pour qu’il manipule prudemment du XML, et vous le paierez à nouveau lors de la prochaine mise à jour du contenu. Le coût réside dans la coordination, pas dans le tarif au mot.

Coller le corps du texte dans un assistant de chat fonctionne pour un article. Au bout du dixième, vous ne savez plus quels fichiers sont terminés, la terminologie a dérivé et aucune cohérence ne lie vos décisions d’un fichier à l’autre.

Tout le processus, en cinq étapes

Tout est gratuit jusqu’à la quatrième étape. C’est un point essentiel : si un plan a mal interprété vos archives, sa correction ne coûte rien. Il n’y a donc aucune raison de deviner.

Deux façons de gérer l’étape intermédiaire

Les étapes deux à quatre peuvent être réalisées dans un navigateur ou entièrement depuis votre terminal. Le choix modifie simplement la manière de saisir les données, pas le résultat final.

Choisissez selon vos habitudes de travail. Si vous lisez ceci avec un terminal ouvert, l’option B demande moins d’étapes. Sinon, l’option A n’est en aucun cas une version simplifiée.

Méthode 1 : envoyer le ZIP tel quel

AI Glot accepte les formats XLIFF et ZIP, donc un export WPML est importé sans être ouvert. Téléchargez l’archive, puis décrivez la mission en une phrase.

L’instruction est un texte libre, et c’est là que les particularités de l’exportation deviennent simples plutôt qu’agaçantes :

Translate every trans-unit into the target language declared in each file.
Only translate units where the target still holds the same text as the source.
Leave the URL units exactly as they are.
Keep every shortcode, HTML tag and CDATA wrapper untouched.

Relisez cette deuxième ligne, car c’est elle qui compte. “Traduire uniquement les unités où la cible contient encore le même texte que la source” correspond exactement à la situation 217-sur-228 décrite plus haut, et signifie que vous ne payez pas pour refaire les 18 unités déjà gérées par votre mémoire de traduction.

Vous recevez un plan avant tout engagement : les langues détectées, le périmètre, le nombre de mots et le coût. Si le plan comporte une erreur, corrigez-la en une phrase et il est recalculé. Vous téléchargez ensuite un seul ZIP avec la même structure, prêt à être importé.

Méthode 2 : laisser votre agent IA s’en charger

Si vous travaillez avec Claude, ChatGPT, Cursor ou tout autre agent de codage, vous n’avez pas besoin d’utiliser un navigateur. Notre outil en ligne de commande se connecte via OAuth et prend un fichier directement, permettant à un agent de gérer l’intégralité du travail.

Installez et connectez-vous une seule fois :

npm install -g @ai-glot/cli
aiglot auth login

Cela ouvre un navigateur pour autoriser la machine. Sur un serveur sans navigateur, utilisez aiglot auth login --device pour le flux device-code, ou aiglot auth login --key <key> en CI.

Donnez ensuite l’emplacement du fichier à votre agent et laissez-le travailler. Une instruction comme celle-ci suffit :

My WPML export is at ~/Downloads/my-site-export.zip. It is a ZIP of XLIFF
files, one per WordPress post, and each file declares its own target
language.

Use the aiglot CLI to translate it. Run `aiglot batches create --help` and
`aiglot batches approve --help` first so you use the real flags. Create the
batch from the ZIP with an instruction that translates only the units whose
target still equals the source, and leaves the URL units alone. Show me the
plan and the cost before you approve anything. Use the lite quality tier.
Then poll until it is done and download the result next to the original.

Deux éléments rendent ce prompt efficace, et tous deux méritent d’être copiés.

Il demande à l’agent de lire l’aide d’abord. Un agent qui devine le nom des drapeaux échouera dès le premier appel, puis inventera une raison. aiglot help --json exporte toutes les commandes, drapeaux et codes de sortie d’un coup s’il préfère une structure.

Il impose un arrêt avant la dépense. aiglot batches approve est la seule commande qui consomme des crédits. Tout ce qui précède est gratuit, donc demander de voir le plan d’abord ne coûte rien et évite les malentendus coûteux.

Pour référence, voici la séquence que l’agent finira par exécuter :

# 1. Create the batch. Free. Returns a plan and an id.
aiglot batches create ~/Downloads/my-site-export.zip \
  --instruction "Translate every trans-unit into the target language declared in each file. Only translate units whose target still holds the same text as the source. Leave URL units unchanged. Keep shortcodes, HTML and CDATA intact." \
  --json

# 2. Approve. This is the only step that spends credits.
aiglot batches approve <batch-id> --quality lite

# 3. Poll until it finishes.
aiglot batches get <batch-id> --json

# 4. Download the translated archive.
aiglot batches download <batch-id> --output ~/Downloads/my-site-export.translated.zip

Il existe également un serveur MCP (aiglot mcp) si votre agent préfère les outils au shell. Le CLI est le meilleur point de départ : il fonctionne dans un script, en CI, et vous permet de voir exactement ce qui a été exécuté.

Intégrer votre glossaire

Si votre site contient des termes qui ne doivent pas varier, comme un nom de produit ou une traduction interne pour une phrase récurrente, ajoutez-les une seule fois dans un glossaire d’espace de travail. Ils s’appliqueront ensuite à chaque fichier de l’archive ainsi qu’à l’export suivant.

C’est là que les traducteurs automatiques sont peu performants. Leur glossaire substitue un terme partout où il apparaît. Ici, un glossaire est traité comme un lemme, il s’inflechit et se conjugue selon la phrase environnante au lieu d’insérer une chaîne fixe en plein milieu.

Réimportation dans WPML

L’archive traduite revient avec la même structure : le même dossier posts/, les mêmes noms de fichiers, les mêmes unités dans le même ordre, avec les cibles remplies. L’écran des tâches de traduction de WPML les réintègre de la même manière qu’il vous les a fournies.

Deux suggestions basées sur la structure du fichier. Importez d’abord un seul fichier et examinez l’article dans WordPress avant de valider toute l’archive, car une chaîne de constructeur de page mal placée est bien plus facile à repérer une fois rendue qu’en XML. Et décidez des slugs avant l’import, pas après : modifier une URL publiée crée une redirection que vous devrez maintenir.

La portée réelle de l’outil

Utilisez ceci pour le gros du travail. Quarante-quatre articles en quatre langues est précisément le type de tâche pénible à la main et banale en un seul passage. Consacrez ensuite la révision humaine là où elle est indispensable : vos pages les plus fréquentées et tout contenu où la formulation est le produit même. De nombreuses équipes utilisent AI Glot pour un premier passage, puis font relire le résultat par un expert, ce qui est une bonne utilisation de ses compétences et une meilleure façon de passer son après-midi que dans du XML.

Pour une page d’accueil, engagez un traducteur. Pour l’archive de 44 articles exportée ce matin, n’y passez pas votre semaine.

La structure d’export décrite ici a été analysée à partir d’un export WPML réel de 44 articles sur quatre paires de langues. Votre export peut différer si votre site utilise un constructeur de page ou un plugin SEO différent, et les IDs d’unités refléteront vos propres plugins. Le dossier posts/, le format XLIFF 1.2, la paire de langues par fichier et les cibles copiées de la source sont les éléments qui étaient constants sur les 44 fichiers.