{"id":2255,"date":"2026-06-28T13:34:19","date_gmt":"2026-06-28T10:34:19","guid":{"rendered":"https:\/\/allinonewpsettings.com\/blog\/?p=2255"},"modified":"2026-10-18T05:20:22","modified_gmt":"2026-10-18T02:20:22","slug":"wordpress-plugin-translations-not-showing-causes-and-fixes","status":"publish","type":"post","link":"https:\/\/allinonewpsettings.com\/blog\/wordpress-plugin-translations-not-showing-causes-and-fixes\/","title":{"rendered":"WordPress Plugin Translations Not Showing: Causes and Fixes"},"content":{"rendered":"

You translated a plugin, your file is on the server, and your screen still shows English. Nothing is broken in the usual sense. WordPress looks for one file per plugin, chosen by your language, by the file name and by the folder. If one of the three is off by a single character, it says nothing and shows you English.<\/p>\n

So don’t edit your translation yet. First find out which file WordPress is really reading for you, or whether it reads any at all. Every check below was run on a test site, with a small plugin that tags each string with the file it came from, so you can see what each mistake looks like.<\/p>\n

Table of contents<\/strong><\/p>\n
    \n
  1. Which language is WordPress asking for?<\/a><\/li>\n
  2. Is the file named for exactly that language?<\/a><\/li>\n
  3. A file in wp-content\/languages wins<\/a><\/li>\n
  4. The .l10n.php file beside it<\/a><\/li>\n
  5. Strings from JavaScript need their own file<\/a><\/li>\n
  6. Code that translates too early<\/a><\/li>\n
  7. Verification<\/a><\/li>\n
  8. AIOWS Language Compiler<\/a><\/li>\n
  9. FAQ<\/a><\/li>\n
  10. Sources<\/a><\/li>\n<\/ol>\n<\/div>\n

    Which language is WordPress asking for?<\/h2>\n

    WordPress keeps two language settings, and your admin screens follow the one you may not think of:<\/p>\n

    \n\n\n\n\n\n\n
    Setting<\/th>\nWhere you find it<\/th>\nWhat it controls<\/th>\n<\/tr>\n<\/thead>\n
    Site language<\/td>\nSettings<\/strong> > General<\/strong> > Site Language<\/strong><\/td>\nyour public pages<\/td>\n<\/tr>\n
    Your profile language<\/td>\nUsers<\/strong> > Profile<\/strong> > Language<\/strong><\/td>\nevery admin screen you see<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n

    Set your site to German and your own profile to English, and you get what the test site showed: the plugin’s admin page in English, with a correct German file in place.<\/p>\n

    \"The
    Your profile language English: your admin stays English, whatever the site language says.<\/figcaption><\/figure>\n

    If your profile says Site Default<\/strong>, it follows the site language. If it names a language, that one wins on your admin screens, and only for you. Another administrator can see the same screen in a different language.<\/p>\n

    Is the file named for exactly that language?<\/h2>\n

    A plugin’s translation file is named text-domain-locale.mo<\/code>. The text domain is the plugin’s own identifier, normally its folder name. The locale is the full code WordPress uses, with no shortening:<\/p>\n

    \n\n\n\n\n\n\n\n\n
    Your language setting<\/th>\nFile WordPress looks for<\/th>\n<\/tr>\n<\/thead>\n
    English (United States)<\/td>\nnone, English is built in<\/td>\n<\/tr>\n
    Deutsch<\/td>\nmy-plugin-de_DE.mo<\/code><\/td>\n<\/tr>\n
    Deutsch (Sie)<\/td>\nmy-plugin-de_DE_formal.mo<\/code><\/td>\n<\/tr>\n
    T\u00fcrk\u00e7e<\/td>\nmy-plugin-tr_TR.mo<\/code><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n

    Two results from the test site show you how literal this is: – A file named -tr.mo<\/code> is ignored.<\/strong> With your language set to Turkish and only i18n-lab-tr.mo<\/code> in place, your page stays English. Rename it to i18n-lab-tr_TR.mo<\/code>, and it turns Turkish. – There is no fallback between German variants.<\/strong> With Deutsch (Sie)<\/strong> set and only a de_DE<\/code> file, your page is English. A de_DE_formal<\/code> file fixes it.<\/p>\n

    If your plugin ships only de_DE<\/code> and your site runs Deutsch (Sie)<\/strong>, copy its de_DE<\/code> files under the de_DE_formal<\/code> name. Your readers get the informal form, but they get German.<\/p>\n

    A file in wp-content\/languages wins<\/h2>\n

    There are two places a plugin’s translation can come from: – wp-content\/languages\/plugins\/<\/code>, where WordPress puts the language packs it downloads from translate.wordpress.org; – the plugin’s own languages<\/code> folder, which only counts if the plugin tells WordPress about it with load_plugin_textdomain()<\/code>.<\/p>\n

    WordPress checks wp-content\/languages\/plugins\/<\/code> first.<\/strong> Put the same string in both places, tagged by origin, and your page shows the language pack’s version. Edit the plugin’s own file as often as you like: nothing changes.<\/p>\n

    \"The
    The language pack wins, and your plugin folder’s JavaScript file stops being read.<\/figcaption><\/figure>\n

    The reverse also holds. If your plugin never calls load_plugin_textdomain()<\/code>, it is translated only from wp-content\/languages\/plugins\/<\/code>. Your file in its own folder stays English until you move it there.<\/p>\n

    Language packs come from translate.wordpress.org. A plugin gets its first pack in a language only once 90 % of its stable strings are translated there. Below that, the partial translation you can see on translate.wordpress.org does not reach your site.<\/p>\n

    How to compile a corrected file, and where to put it, is in how to compile WordPress PO files into MO files<\/a>.<\/p>\n

    The .l10n.php file beside it<\/h2>\n

    Since WordPress 6.5, a .l10n.php<\/code> file with the same name as your .mo<\/code> file is loaded instead of it. On the test site, a .l10n.php<\/code> beside the language pack’s .mo<\/code> won. So did one with no .mo<\/code> next to it.<\/p>\n

    If you edit and recompile a .mo<\/code> file and nothing changes, look for a .l10n.php<\/code> of the same name. Regenerate it from your PO file with wp i18n make-php<\/code>, or delete it so the .mo<\/code> file is read.<\/p>\n

    One difference catches people out. msgfmt<\/code> leaves entries marked fuzzy out of the .mo<\/code> file, so they stay English. wp i18n make-php<\/code> in WP-CLI 2.12.0 kept the fuzzy entry, and the test page showed its unconfirmed translation. Clear the fuzzy flags you mean to keep before you build your PHP file, and leave the others untranslated.<\/p>\n

    Strings from JavaScript need their own file<\/h2>\n

    Text that a script writes into your page never touches the .mo<\/code> file. You need a JSON file named after the text domain, the locale and the MD5 hash of the script’s path inside the plugin, for example my-plugin-de_DE-0a1b2c\u2026.json<\/code>. wp i18n make-json<\/code> writes it from your PO file, and your plugin must call wp_set_script_translations()<\/code>.<\/p>\n

    Two results from the test site are worth knowing: – Without the JSON file<\/strong>, your PHP string is German and your script’s string English, on the same screen. – With a language pack present<\/strong>, your JSON file in the plugin’s own folder is ignored, and your script’s string falls back to English. Put the JSON file next to the file that wins.<\/p>\n

    If your screen is half translated and half English, start here.<\/p>\n

    Code that translates too early<\/h2>\n

    Since WordPress 6.7, a plugin that asks for a translation before the init<\/code> action triggers a notice in your debug log:<\/p>\n

    Translation loading for the my-plugin domain was triggered too early.\nThis is usually an indicator for some code in the plugin or theme running\ntoo early. Translations should be loaded at the init action or later.<\/code><\/pre>\n
    Turn on WP_DEBUG_LOG<\/code> and search your wp-content\/debug.log<\/code> for the plugin’s text domain.<\/p>\n
    On the test site, a string translated while the plugin’s file was loading stayed English, while the rest of your page was German. Your log has the notice.<\/p>\n
    You cannot fix this one with a file. Send the notice to the plugin’s author: the fix is to move that code to init<\/code> or later.<\/p>\n
    Verification<\/h2>\n
    You have found the cause when you can name the file that serves the string, and removing it changes the screen.<\/p>\n
    \n\n\n\n\n\n\n\n\n\n
    Check<\/th>\nExpected<\/th>\n<\/tr>\n<\/thead>\n
    Open the screen with your profile language set to the language that fails<\/td>\nThe language you expect. If not, see the first section<\/a>.<\/td>\n<\/tr>\n
    Rename the file you believe is serving, for example to .mo.off<\/code>, and reload<\/td>\nMust change.<\/strong> The text falls back to English, or to another file’s version.<\/td>\n<\/tr>\n
    Put the name back and reload<\/td>\nThe translation returns.<\/td>\n<\/tr>\n
    Check one PHP string and one JavaScript string on the same screen<\/td>\nBoth translated. If only one is, see JavaScript<\/a>.<\/td>\n<\/tr>\n
    Search debug.log<\/code> for the text domain<\/td>\nNo “triggered too early” line.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n
    The rename is the check that settles it for you. On the test site, renaming the language pack’s .mo<\/code> switched the text to the plugin folder’s version. The file you were editing had never been the one on your screen.<\/p>\n
    If nothing changes when you rename your file, WordPress was not reading it. Look for a .l10n.php<\/code> file, a second copy in another folder, or a page cache serving you an older copy.<\/p>\n
    When you rename the only .mo<\/code> file, your PHP string turns English while your script’s string stays German. Each kind of string has its own file, so you check each one.<\/p>\n
    \n
    How AIOWS helps:<\/p>\n
    AIOWS Language Compiler<\/h2>\n
    Language Compiler handles your AIOWS translations, and AIOWS loads them differently from the plugin in this article, so the traps above work out differently for you.<\/p>\n
    It reads its own folder first, on purpose.<\/strong> For the languages it ships, German and Turkish, AIOWS loads the file in its own languages<\/code> folder and puts it in place of any language pack for its text domain in wp-content\/languages\/plugins\/<\/code>. An older pack there cannot hide strings a new AIOWS version shipped. On the test site, a planted pack with a different label, .mo<\/code> and .l10n.php<\/code>, changed nothing on your AIOWS screens.<\/p>\n
    It does not leave you in English on Deutsch (Sie).<\/strong> For a German locale it has no file for, such as de_DE_formal<\/code>, AIOWS gives you its de_DE<\/code> translation.<\/p>\n
    It shows you what is missing.<\/strong> The Scan tab compares AIOWS’s code with each of your PO files. It reports translated, empty, duplicate and missing entries per locale. Read your Empty and Missing columns: they name what is missing, and the coverage figure never rounds a missing string up to 100 %.<\/p>\n
    It compiles safely without msgfmt.<\/strong> Compile turns your AIOWS PO files into MO files, with GNU msgfmt<\/code> if your server allows it, otherwise with its own compiler. Both leave fuzzy and untranslated entries out, so an unfinished string shows you English, never a blank.<\/p>\n
    \"Language
    One string missing: your Missing column says 1, and coverage stops at 99.9 %.<\/figcaption><\/figure>\n
    Its limits, stated plainly. It works on AIOWS’s own languages<\/code> folder and nothing else. Your other plugins’ and your theme’s translations are yours to compile with msgfmt<\/code>, Poedit or WP-CLI, as shown above. It writes .mo<\/code> files only, with no .l10n.php<\/code> and no JSON for scripts. And it does not diagnose how other plugins load: a profile language, a too-early call or a second copy of a file are yours to check with the verification above.<\/p>\n
    Explore AIOWS Language Compiler<\/a>Compare AIOWS plans<\/a><\/p>\n<\/section>\n
    FAQ<\/h2>\n
    I uploaded the translation and cleared the cache. Why is it still English?<\/strong> Check your profile language first, then the file name, then whether a file in wp-content\/languages\/plugins\/<\/code> wins over yours.<\/p>\n
    Can I keep my own translation when the plugin updates?<\/strong> A file in the plugin’s own folder goes when the plugin’s folder is replaced by an update. Keep your PO file somewhere else, and rebuild after updates.<\/p>\n
    Why is the plugin translated on the front end but not in my admin?<\/strong> Your profile language decides your admin, the site language your public pages.<\/p>\n
    Does WordPress fall back from de_DE_formal<\/code> to de_DE<\/code>?<\/strong> Not for plugins. AIOWS does this for itself; your other plugins need their own de_DE_formal<\/code> file.<\/p>\n
    Where do I see which strings are still untranslated?<\/strong> In your PO file, or in your editor’s list of untranslated entries. For AIOWS, the Scan tab counts them for you per language. More on reading language files is in how to scan and manage WordPress language files<\/a>.<\/p>\n
    Sources<\/h2>\n