How to Fix Fuzzy Translations in WordPress .po Files

You translated every string. You saved the file, uploaded the .mo, and refreshed your site. And yet, a handful of labels are still stubbornly in English. You open the .po file, find the string, and there it is, perfectly translated. So why is WordPress ignoring it?

The answer is almost always a tiny flag hiding above the entry: #, fuzzy. A fuzzy translation is gettext's way of saying "this translation might be wrong, so do not trust it yet." And critically, WordPress refuses to display fuzzy strings on the live site, falling back to the original English instead. This is one of the most misunderstood causes of the "my translation is not showing up" problem.

This guide explains exactly what the fuzzy translation flag means, why it keeps appearing in your catalogs, and how to find and clear fuzzy strings in Poedit, on the command line, and at scale across an entire backlog. Once you understand the mechanism, the mystery of the missing translations disappears.

What Does the Fuzzy Flag Actually Mean?

The fuzzy flag is a marker gettext adds to a translation entry to indicate the translation is uncertain and needs human review. In the raw .po file it appears as a special comment directly above the string.

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

That #, fuzzy line tells every gettext-aware tool, including WordPress, that the msgstr below it is provisional. The translation exists, but gettext does not consider it confirmed.

Why WordPress Skips Fuzzy Strings

Here is the behavior that catches everyone off guard. When WordPress compiles or reads a .mo file, it treats fuzzy entries as untranslated. The string is technically present in the file, but WordPress deliberately ignores it and shows the original msgid instead.

So from your perspective, the translation is "done," it is right there in the file. But from WordPress's perspective, that string has no trustworthy translation, so it renders the English source. This is precisely why a finished-looking catalog can still display untranslated text on the front end.

This design is intentional and, in fairness, sensible. The whole point of the fuzzy flag is to prevent unverified, potentially wrong translations from silently going live. Imagine a string that originally read "Delete account" and was later changed to "Deactivate account." If gettext blindly kept the old translation, your users might see a button labeled "Delete account" that actually only deactivates, a dangerous mismatch. By hiding fuzzy strings, gettext forces a human to confirm the translation still matches the new meaning before it reaches anyone. The flag is a safety mechanism, not a bug.

Why Do Fuzzy Flags Keep Appearing?

Fuzzy flags are not random. They are generated automatically by gettext tooling in two main situations, and understanding both tells you how to prevent them.

The Source String Changed

The most common cause is a source update. Imagine the developer changes a string in the next plugin version from "Add to cart" to "Add to basket." When you merge the new template into your existing translation, gettext sees that the source no longer matches what you originally translated. Rather than throw your old translation away, it keeps it but marks it fuzzy, essentially saying: "the English changed, so please re-check whether your translation still fits."

Auto-Matching by Translation Memory and msgmerge

The second cause is fuzzy matching during a merge. The msgmerge tool updates an old translation file against a new template, and when it finds a source string that is similar but not identical to a previous one, it copies the old translation over and flags it fuzzy.

# 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

Translation Memory in desktop editors behaves the same way: when it auto-fills a suggestion from a near-match, it marks the result fuzzy so you remember to verify it. In both cases the flag is doing its job. The problem is only that the fuzzy entries then sit unreviewed, and WordPress quietly hides them.

There is a third, sneakier source worth knowing about: copy-paste and bulk-import tools. Some translation platforms and import scripts mark every entry fuzzy by default as a conservative measure, expecting a human to confirm each one afterward. If you import a catalog from another system and find that every single string is suddenly fuzzy, this is usually why. The translations may be perfectly fine, but until the flags are cleared, none of them will appear on your site. Knowing the source of the flags tells you whether you genuinely need to review each entry or whether a confident bulk clear is safe.

How Do You Find and Fix Fuzzy Strings?

Clearing fuzzy strings means reviewing each one and, once you confirm the translation is correct, removing the flag. There are three practical ways to do this depending on the size of the job.

Fixing Fuzzy Strings in Poedit

Poedit makes this the easiest. Open the .po file and use the search and filter controls to show only fuzzy entries, they are color-coded (usually orange) so they stand out immediately. Click each one, confirm or correct the translation, then toggle off the fuzzy state with the keyboard shortcut (Edit then "Translation is Fuzzy," or the shortcut shown in the menu). When you save, Poedit recompiles a clean .mo and the now-confirmed strings will display on your site. If you are new to that editor, the complete Poedit guide covers the filter and review workflow in detail.

Fixing Fuzzy Strings on the Command Line

For automation or large catalogs, the command line is faster. You can count fuzzy entries and, once you have verified them in bulk, strip the flags so WordPress will load them.

# 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

Be careful with bulk clearing. Removing fuzzy flags without reviewing the translations defeats the purpose of the flag and can ship genuinely wrong text to your users. Use the command-line approach when you trust the source of the translations, and the manual Poedit route when you do not.

A safe middle ground is to export the fuzzy strings into a separate file, review just those, and merge them back. This keeps your confirmed translations untouched while you focus only on the entries that actually need attention.

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

Reviewing fifty isolated strings is far less error-prone than scrolling a thousand-line catalog hunting for orange rows, and it gives you a clean record of exactly what changed in the last update.

After clearing the flags, always re-save or recompile the .mo file. The fuzzy state lives in the .po, but WordPress reads the binary .mo, so until you regenerate it, your front end will keep showing English even though the .po looks clean. Poedit recompiles automatically on save; on the command line you run msgfmt awesome-plugin-de_DE.po -o awesome-plugin-de_DE.mo. Forgetting this final compile step is one of the most common reasons a freshly de-fuzzed catalog still does not appear, the translation is confirmed in the source file, but the binary the site actually loads is stale.

Note that fuzzy entries often appear alongside plural strings, where a changed msgid_plural can mark the whole plural block fuzzy. If your fuzzy backlog is heavy on counts and quantities, our guide to Gettext plurals and complex pluralization explains why those entries are especially fragile during merges.

Clearing the Fuzzy Backlog at Scale

A single fuzzy string is a thirty-second fix. A catalog with four hundred fuzzy strings after a major plugin update is a different problem, and across a dozen languages it becomes a genuine bottleneck. The temptation to mass-clear the flags without review is exactly how broken translations reach production.

A cleaner solution is to re-translate the fuzzy entries fresh rather than rubber-stamping stale matches. When you run a catalog through SimplePoTranslate, the context-aware AI produces a current, confirmed translation for every changed string, so you are not just removing a warning flag, you are replacing uncertain matches with real translations. Syntax Locking keeps every %s, %1$s, {count}, and HTML tag intact during the pass, and Smart Batching processes large post-update catalogs in one go. You get back a clean ZIP with .po, .mo, .json, .php, and .xliff, no lingering fuzzy backlog, ready to deploy from the cloud.

It is worth distinguishing this from the broader question of why translations fail to appear at all. Fuzzy flags are one specific cause, but missing .mo files, wrong filenames, and locale mismatches cause the same symptom. For the full diagnostic checklist, see our troubleshooting guide for translations not showing up in WordPress, which treats fuzzy strings as one item in a larger list.

Ready to clear an entire fuzzy backlog and get every string showing up on your site? Try SimplePoTranslate free — no credit card required. The free tier re-translates your .po file fresh, replacing uncertain fuzzy matches with clean, confirmed translations.