FonctionnalitésPluginTarifsRessources
Changer de langue
RessourcesComment corriger les traductions floues dans les fichiers .po de WordPress

Comment corriger les traductions floues dans les fichiers .po de WordPress

SimplePoTranslate Team11 mai 2026
Comment corriger les traductions floues dans les fichiers .po de WordPress

Vous avez traduit chaque chaîne. Vous avez enregistré le fichier, téléchargé le .mo et actualisé votre site. Et pourtant, une poignée d'étiquettes restent obstinément en anglais. Vous ouvrez le fichier .po, trouvez la chaîne, et elle est là, parfaitement traduite. Alors pourquoi WordPress l'ignore-t-il ?

La réponse est presque toujours un petit indicateur caché au-dessus de l'entrée : #, fuzzy. Une traduction floue est la manière de gettext de dire "cette traduction pourrait être incorrecte, ne la fiez pas encore." Et surtout, WordPress refuse d'afficher les chaînes floues sur le site en direct, affichant à la place l'anglais original. C'est l'une des causes les plus incomprises du problème "ma traduction ne s'affiche pas".

Ce guide explique exactement ce que signifie l'indicateur de traduction floue, pourquoi il continue d'apparaître dans vos catalogues, et comment trouver et effacer les chaînes floues dans Poedit, en ligne de commande, et à grande échelle sur l'ensemble d'un arriéré. Une fois que vous comprenez le mécanisme, le mystère des traductions manquantes disparaît.

Que signifie réellement l'indicateur "Fuzzy" ?

L'indicateur "fuzzy" est un marqueur que gettext ajoute à une entrée de traduction pour indiquer que la traduction est incertaine et nécessite une révision humaine. Dans le fichier .po brut, il apparaît comme un commentaire spécial directement au-dessus de la chaîne.

#: includes/cart.php:88
#, fuzzy
msgid "Add to cart"
msgstr "Im Warenkorb"

Cette ligne #, fuzzy indique à tout outil compatible gettext, y compris WordPress, que le msgstr en dessous est provisoire. La traduction existe, mais gettext ne la considère pas comme confirmée.

Pourquoi WordPress ignore les chaînes floues

Voici le comportement qui prend tout le monde au dépourvu. Lorsque WordPress compile ou lit un fichier .mo, il traite les entrées floues comme non traduites. La chaîne est techniquement présente dans le fichier, mais WordPress l'ignore délibérément et affiche le msgid original à la place.

Donc, de votre point de vue, la traduction est "terminée", elle est là dans le fichier. Mais du point de vue de WordPress, cette chaîne n'a pas de traduction fiable, il affiche donc la source anglaise. C'est précisément pourquoi un catalogue d'apparence finie peut encore afficher du texte non traduit sur le front-end.

Cette conception est intentionnelle et, honnêtement, sensée. L'objectif de l'indicateur "fuzzy" est d'empêcher les traductions non vérifiées et potentiellement erronées de passer en production sans avertissement. Imaginez une chaîne qui disait à l'origine "Delete account" (Supprimer le compte) et qui a été ensuite modifiée en "Deactivate account" (Désactiver le compte). Si gettext conservait aveuglément l'ancienne traduction, vos utilisateurs pourraient voir un bouton étiqueté "Delete account" qui ne ferait en réalité que désactiver, une dangereuse incohérence. En masquant les chaînes floues, gettext force un humain à confirmer que la traduction correspond toujours à la nouvelle signification avant qu'elle n'atteigne qui que ce soit. L'indicateur est un mécanisme de sécurité, pas un bogue.

Pourquoi les indicateurs "Fuzzy" continuent-ils d'apparaître ?

Les indicateurs "fuzzy" ne sont pas aléatoires. Ils sont générés automatiquement par les outils gettext dans deux situations principales, et comprendre ces deux situations vous indique comment les prévenir.

La chaîne source a changé

La cause la plus courante est une mise à jour de la source. Imaginez que le développeur modifie une chaîne dans la prochaine version du plugin, passant de "Add to cart" (Ajouter au panier) à "Add to basket" (Ajouter au panier). Lorsque vous fusionnez le nouveau modèle dans votre traduction existante, gettext constate que la source ne correspond plus à ce que vous avez initialement traduit. Plutôt que de jeter votre ancienne traduction, il la conserve mais la marque comme floue, disant essentiellement : "l'anglais a changé, veuillez donc vérifier si votre traduction correspond toujours."

Correspondance automatique par la mémoire de traduction et msgmerge

La deuxième cause est la correspondance floue lors d'une fusion. L'outil msgmerge met à jour un ancien fichier de traduction par rapport à un nouveau modèle, et lorsqu'il trouve une chaîne source similaire mais non identique à une précédente, il copie l'ancienne traduction et la marque comme floue.

# Merge a new template into an existing translation.
# Similar-but-changed strings get marked #, fuzzy automatically.
msgmerge --update awesome-plugin-de_DE.po awesome-plugin.pot

La mémoire de traduction dans les éditeurs de bureau se comporte de la même manière : lorsqu'elle remplit automatiquement une suggestion à partir d'une correspondance proche, elle marque le résultat comme flou afin que vous vous souveniez de le vérifier. Dans les deux cas, l'indicateur fait son travail. Le problème est seulement que les entrées floues restent alors non révisées, et WordPress les masque discrètement.

Il existe une troisième source, plus insidieuse, qu'il est bon de connaître : les outils de copier-coller et d'importation en masse. Certaines plateformes de traduction et scripts d'importation marquent chaque entrée comme floue par défaut, par mesure de précaution, s'attendant à ce qu'un humain confirme chacune d'elles par la suite. Si vous importez un catalogue d'un autre système et constatez que chaque chaîne est soudainement floue, c'est généralement la raison. Les traductions peuvent être parfaitement correctes, mais tant que les indicateurs ne sont pas effacés, aucune d'elles n'apparaîtra sur votre site. Connaître la source des indicateurs vous indique si vous devez réellement réviser chaque entrée ou si une suppression en masse est sûre.

Comment trouver et corriger les chaînes floues ?

Effacer les chaînes floues signifie réviser chacune d'elles et, une fois que vous avez confirmé que la traduction est correcte, supprimer l'indicateur. Il existe trois façons pratiques de procéder, selon l'ampleur du travail.

Correction des chaînes floues dans Poedit

Poedit rend cela très facile. Ouvrez le fichier .po et utilisez les contrôles de recherche et de filtre pour afficher uniquement les entrées floues ; elles sont codées par couleur (généralement orange) de manière à se distinguer immédiatement. Cliquez sur chacune, confirmez ou corrigez la traduction, puis désactivez l'état flou avec le raccourci clavier (Édition puis "Traduction floue", ou le raccourci affiché dans le menu). Lorsque vous enregistrez, Poedit recompilera un .mo propre et les chaînes désormais confirmées s'afficheront sur votre site. Si vous êtes nouveau avec cet éditeur, le guide complet de Poedit couvre le flux de travail de filtrage et de révision en détail.

Correction des chaînes floues en ligne de commande

Pour l'automatisation ou les grands catalogues, la ligne de commande est plus rapide. Vous pouvez compter les entrées floues et, une fois que vous les avez vérifiées en masse, supprimer les indicateurs afin que WordPress les charge.

# Count how many fuzzy strings remain
msgattrib --only-fuzzy --no-obsolete awesome-plugin-de_DE.po | grep -c "msgid"

# Clear all fuzzy flags (only after you trust the translations)
msgattrib --clear-fuzzy --empty awesome-plugin-de_DE.po \
  --output-file=awesome-plugin-de_DE.po

Soyez prudent avec la suppression en masse. Supprimer les indicateurs flous sans réviser les traductions va à l'encontre de l'objectif de l'indicateur et peut livrer du texte réellement incorrect à vos utilisateurs. Utilisez l'approche en ligne de commande lorsque vous faites confiance à la source des traductions, et la méthode manuelle de Poedit lorsque ce n'est pas le cas.

Une solution intermédiaire sûre consiste à exporter les chaînes floues dans un fichier séparé, à ne réviser que celles-ci, puis à les fusionner. Cela maintient vos traductions confirmées intactes pendant que vous vous concentrez uniquement sur les entrées qui nécessitent réellement une attention.

# Extract only the fuzzy entries for focused review
msgattrib --only-fuzzy --no-obsolete awesome-plugin-de_DE.po \
  --output-file=fuzzy-only.po

Réviser cinquante chaînes isolées est bien moins sujet aux erreurs que de faire défiler un catalogue de mille lignes à la recherche de lignes oranges, et cela vous donne un enregistrement clair de ce qui a changé lors de la dernière mise à jour.

Après avoir effacé les indicateurs, enregistrez ou recompilez toujours le fichier .mo. L'état flou réside dans le .po, mais WordPress lit le .mo binaire, donc tant que vous ne le régénérez pas, votre front-end continuera d'afficher l'anglais même si le .po semble propre. Poedit recompile automatiquement à l'enregistrement ; en ligne de commande, vous exécutez msgfmt awesome-plugin-de_DE.po -o awesome-plugin-de_DE.mo. Oublier cette dernière étape de compilation est l'une des raisons les plus courantes pour lesquelles un catalogue fraîchement "défuzifié" n'apparaît toujours pas ; la traduction est confirmée dans le fichier source, mais le binaire que le site charge réellement est obsolète.

Notez que les entrées floues apparaissent souvent aux côtés des chaînes plurielles, où un msgid_plural modifié peut marquer l'intégralité du bloc pluriel comme flou. Si votre arriéré flou concerne beaucoup de nombres et de quantités, notre guide sur Les pluriels Gettext et la pluralisation complexe explique pourquoi ces entrées sont particulièrement fragiles lors des fusions.

Vider l'arriéré de traductions floues à grande échelle

Une seule chaîne floue est une correction de trente secondes. Un catalogue de quatre cents chaînes floues après une mise à jour majeure de plugin est un problème différent, et à travers une douzaine de langues, cela devient un véritable goulot d'étranglement. La tentation de supprimer en masse les indicateurs sans révision est précisément la façon dont des traductions défectueuses atteignent la production.

Une solution plus propre consiste à retraduire les entrées floues plutôt que de valider des correspondances obsolètes. Lorsque vous traitez un catalogue avec SimplePoTranslate, l'IA sensible au contexte produit une traduction actuelle et confirmée pour chaque chaîne modifiée, de sorte que vous ne supprimez pas seulement un indicateur d'avertissement, vous remplacez des correspondances incertaines par de véritables traductions. Le Verrouillage syntaxique maintient intacts chaque %s, %1$s, {count} et balise HTML pendant le processus, et le Traitement intelligent par lots gère les grands catalogues post-mise à jour en une seule fois. Vous récupérez un ZIP propre avec .po, .mo, .json, .php et .xliff, sans aucun arriéré de traductions floues, prêt à être déployé depuis le cloud.

Il convient de distinguer cela de la question plus large de savoir pourquoi les traductions ne s'affichent pas du tout. Les indicateurs flous sont une cause spécifique, mais des fichiers .mo manquants, des noms de fichiers incorrects et des incohérences de locale provoquent le même symptôme. Pour la liste de contrôle diagnostique complète, consultez notre guide de dépannage pour les traductions qui ne s'affichent pas dans WordPress, qui traite les chaînes floues comme un élément d'une liste plus vaste.

Prêt à vider tout un arriéré de traductions floues et à faire apparaître chaque chaîne sur votre site ? Essayez SimplePoTranslate gratuitement — aucune carte de crédit requise. Le niveau gratuit retraduit votre fichier .po à neuf, remplaçant les correspondances floues incertaines par des traductions propres et confirmées.