{"id":2252,"date":"2026-06-27T11:25:37","date_gmt":"2026-06-27T08:25:37","guid":{"rendered":"https:\/\/allinonewpsettings.com\/blog\/?p=2252"},"modified":"2026-10-18T05:20:22","modified_gmt":"2026-10-18T02:20:22","slug":"how-to-compile-wordpress-po-files-into-mo-files","status":"publish","type":"post","link":"https:\/\/allinonewpsettings.com\/blog\/how-to-compile-wordpress-po-files-into-mo-files\/","title":{"rendered":"How to Compile WordPress PO Files into MO Files"},"content":{"rendered":"

You edited a translation, compiled the PO file into an MO file, uploaded it, and your site still shows the old text. On WordPress 6.5 and later, the most likely reason is that WordPress is not reading your MO file at all. A PHP translation file with the same name sits next to it, and WordPress prefers that one.<\/p>\n

This guide compiles WordPress PO files into MO files with three tools. It also covers the four reasons a correct MO file still changes nothing on screen: the PHP file, a fuzzy flag, a wrong file name, and strings that come from JavaScript.<\/p>\n

Table of contents<\/strong><\/p>\n
    \n
  1. Which file WordPress actually reads<\/a><\/li>\n
  2. Compiling with msgfmt or Poedit<\/a><\/li>\n
  3. Compiling with WP-CLI, and the PHP file beside it<\/a><\/li>\n
  4. Where the file goes, and what overwrites it<\/a><\/li>\n
  5. Strings marked fuzzy never reach the site<\/a><\/li>\n
  6. The plural line in the header<\/a><\/li>\n
  7. Text from JavaScript needs a JSON file<\/a><\/li>\n
  8. Verification<\/a><\/li>\n
  9. AIOWS Language Compiler<\/a><\/li>\n
  10. FAQ<\/a><\/li>\n
  11. Sources<\/a><\/li>\n<\/ol>\n<\/div>\n

    Which file WordPress actually reads<\/h2>\n

    You will meet three file types that share one name and do three different jobs:<\/p>\n

    \n\n\n\n\n\n\n\n
    File<\/th>\nWho reads it<\/th>\nWhat it is<\/th>\n<\/tr>\n<\/thead>\n
    my-plugin-de_DE.po<\/code><\/td>\nYou, and editors such as Poedit<\/td>\nThe text source. WordPress never reads it.<\/td>\n<\/tr>\n
    my-plugin-de_DE.mo<\/code><\/td>\nWordPress<\/td>\nThe compiled binary catalogue.<\/td>\n<\/tr>\n
    my-plugin-de_DE.l10n.php<\/code><\/td>\nWordPress 6.5 and later<\/td>\nThe same catalogue as a PHP array, faster to load.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n

    When both compiled files exist, WordPress 6.5 and later loads the .l10n.php<\/code> file and ignores your .mo<\/code>. Language packs you download from WordPress.org now ship both. So if you compile only an MO file and a PHP file of the same name is already there, your edit stays invisible.<\/p>\n

    You have two ways out. Compile the PHP file as well, which the WP-CLI section shows. Or delete the stale .l10n.php<\/code>, after which WordPress falls back to your MO file. If the file is right and the text still does not change, plugin translations not showing<\/a> covers the causes outside the file.<\/p>\n

    The test site for this article showed it step by step. A .mo<\/code> and its .l10n.php<\/code> were built from the same PO file, and your page showed that text. After one string changed and only the .mo<\/code> was rebuilt, the page still showed the old text. Once wp i18n make-php<\/code> regenerated the PHP file, the next reload showed the new one.<\/p>\n

    Compiling with msgfmt or Poedit<\/h2>\n

    msgfmt<\/code> is the GNU gettext compiler. You will find it on most Linux servers and in Git for Windows:<\/p>\n

    msgfmt --check --statistics -o my-plugin-de_DE.mo my-plugin-de_DE.po<\/code><\/pre>\n
    --check<\/code> validates your header and your format strings, such as %s<\/code> and %d<\/code>, against the original text. --statistics<\/code> tells you how many strings are translated, fuzzy and untranslated. Read that line. It tells you before you upload whether the file contains what you think it contains.<\/p>\n
    In Poedit, saving your PO file writes the MO file beside it by default. In Poedit 3.10 on Windows and Linux you find the setting under File<\/strong> > Settings\u2026<\/strong> > General<\/strong>, in the Editing group: “Automatically compile MO file when saving”. On a Mac it sits in the Poedit menu’s settings.<\/p>\n
    Neither tool writes the .l10n.php<\/code> file for you.<\/p>\n
    Compiling with WP-CLI, and the PHP file beside it<\/h2>\n
    WP-CLI’s i18n commands compile both formats:<\/p>\n
    wp i18n make-mo  wp-content\/languages\/plugins\/my-plugin-de_DE.po\nwp i18n make-php wp-content\/languages\/plugins\/my-plugin-de_DE.po<\/code><\/pre>\n
    Each command writes its file next to your source unless you give a destination. Run both after every edit, and the stale-PHP-file problem above cannot happen to you. But clear your fuzzy flags first: both commands keep fuzzy entries, as the fuzzy section below shows. make-php<\/code> arrived in WP-CLI 2.10.0 and make-mo<\/code> in 2.5.0. Run wp cli version<\/code> if either command is missing.<\/p>\n
    On the test site, WP-CLI 2.12.0 answered each command with one line, Success: Created 1 file.<\/code><\/p>\n
    Where the file goes, and what overwrites it<\/h2>\n
    You cannot choose the name. It is the plugin’s text domain, a hyphen, the locale, the extension. my-plugin-de_DE.mo<\/code> works. my-plugin-de.mo<\/code> and de_DE.mo<\/code> do not. Find the text domain in the plugin’s main file header, on the Text Domain:<\/code> line.<\/p>\n
    WordPress looks in wp-content\/languages\/plugins\/<\/code> (themes: wp-content\/languages\/themes\/<\/code>) before the plugin’s own languages<\/code> folder. If you put a file there, it wins.<\/p>\n
    That is also the folder your automatic translation updates write to. When WordPress.org ships a newer language pack for that plugin, your file of the same name is replaced. Your edits are gone, and nothing tells you.<\/p>\n
    If you maintain your own translation, keep a copy of your PO file outside wp-content\/languages\/<\/code>. To see what is in that folder before you add to it, scan and manage WordPress language files<\/a>. Then you can recompile it after an update. A translation plugin that loads from its own protected folder is the other route.<\/p>\n
    Strings marked fuzzy never reach the site<\/h2>\n
    A fuzzy entry is one your editor guessed, or one that changed in the source. It carries a #, fuzzy<\/code> comment in your PO file. Poedit shows it to you as needing work.<\/p>\n
    msgfmt<\/code> leaves fuzzy entries out of the MO file unless you add --use-fuzzy<\/code>. So your fully translated file can still show English on screen for every fuzzy string. --statistics<\/code> gives you the fuzzy count.<\/p>\n
    Clear the fuzzy flag after you have checked the translation, then compile again. Do not compile with --use-fuzzy<\/code> to make the count look better. A fuzzy entry is fuzzy because nobody has confirmed it yet.<\/p>\n
    wp i18n make-mo<\/code> does not work that way. On the test site, WP-CLI 2.12.0 wrote the fuzzy entry into the MO file as a normal translation, and so did wp i18n make-php<\/code>, and your screen showed the unconfirmed text. msgfmt<\/code> left it out. If you compile with WP-CLI, clear or empty every fuzzy entry you have not checked before you run it.<\/p>\n
    The plural line in the header<\/h2>\n
    Your PO header carries one line that changes how WordPress picks a translation:<\/p>\n
    "Plural-Forms: nplurals=2; plural=(n != 1);\\n"<\/code><\/pre>\n
    For German you use n != 1<\/code>. For Turkish, WordPress.org uses nplurals=2; plural=(n > 1);<\/code>. If you start a PO file by hand, copy the header from an existing translation of the same language. With the wrong formula, “1 comment” and “2 comments” can swap or collapse into one form, and msgfmt --check<\/code> will not always catch it.<\/p>\n
    Text from JavaScript needs a JSON file<\/h2>\n
    The strings you see in the block editor, and in plugins that render their screens in JavaScript, are not read from your MO file. They come from JSON files named my-plugin-de_DE-.json<\/code>, one per script.<\/p>\n
    If the PHP-side text is translated and a button in the editor is not, you are looking at this. wp i18n make-json<\/code> builds those files for you from the same PO file.<\/p>\n
    Verification<\/h2>\n
    \n\n\n\n\n\n\n\n\n
    Check<\/th>\nExpected<\/th>\n<\/tr>\n<\/thead>\n
    msgfmt --check --statistics<\/code> on your PO file<\/td>\nNo errors. The fuzzy and untranslated counts are the ones you expect.<\/td>\n<\/tr>\n
    List the folder: .mo<\/code> and, if present, .l10n.php<\/code><\/td>\nBoth have a modification time after your edit. A PHP file older than your MO file is the stale-file trap.<\/td>\n<\/tr>\n
    Open a screen that uses a string you changed<\/td>\nYour new text.<\/td>\n<\/tr>\n
    Mark one string fuzzy, compile, and reload that screen<\/td>\nMust still show the original English text.<\/strong> If it shows your guess, the compiler included fuzzy entries.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n
    The fourth row is there to prove that the compiler respects the fuzzy flag. A check whose every row passes only tells you that your happy path works. This one tells you that an unconfirmed translation cannot reach your visitors by accident.<\/p>\n
    Run it with the tool you actually use. msgfmt<\/code> passes it, and so does AIOWS Language Compiler with either of its compilers. A compiler that ignores the fuzzy flag fails it. On the test site, msgfmt<\/code> 1.0 passed, and WP-CLI 2.12.0 failed with both make-mo<\/code> and make-php<\/code>.<\/p>\n
    \n
    How AIOWS helps:<\/p>\n
    AIOWS Language Compiler<\/h2>\n
    Language Compiler is the compiler for AIOWS’s own translations. It is not a general PO editor for your other plugins, and the limits below say exactly where that line is.<\/p>\n
    It compiles where AIOWS reads.<\/strong> It turns the PO files in your AIOWS plugin’s languages<\/code> folder into MO files, one locale at a time or all at once with Compile All Locales. It uses GNU msgfmt<\/code> when your server lets PHP run it, and its own compiler when it does not. Both leave your fuzzy entries out, as msgfmt<\/code> does, so an unconfirmed translation never reaches your screens. AIOWS ships no .l10n.php<\/code> file for its own text domain, so the stale-PHP-file trap above does not apply to these files. WordPress reads the MO file the module writes for you.<\/p>\n
    It shows you what is missing before you compile.<\/strong> The Scan tab compares the plugin’s code with its PO files. It reports how much of the AIOWS interface is translated, and it lists empty and duplicate entries. An empty entry compiles without an error and still shows English, so read this list first.<\/p>\n
    It takes your edited file.<\/strong> Upload \/ Manage accepts a PO or MO file you edited elsewhere, for example in Poedit, and puts it where AIOWS loads it. A file of the same name is replaced. Every file there can be downloaded from the same screen, so take a copy first.<\/p>\n
    That is the practical value. You correct a German or Turkish label in AIOWS from your admin screen, with no SFTP and no local gettext install.<\/p>\n
    \"Language
    One log line per step and per file.<\/figcaption><\/figure>\n
    Its limits, stated plainly. It compiles only the files in AIOWS’s own languages<\/code> folder. For another plugin’s or a theme’s PO file, use msgfmt<\/code>, Poedit or WP-CLI as shown above. It writes MO files only, with no .l10n.php<\/code> and no JSON. It replaces the old MO file without keeping a copy, so download the old one first if you may want it back.<\/p>\n
    Explore AIOWS Language Compiler<\/a>Compare AIOWS plans<\/a><\/p>\n<\/section>\n
    FAQ<\/h2>\n
    Do I need to upload the PO file to the server?<\/strong> Not for WordPress. It reads only your MO and PHP files. Keep your PO file, because it is the only one you can edit.<\/p>\n
    Can I edit an MO file directly?<\/strong> No. It is a compiled binary. Edit your PO file and compile again.<\/p>\n
    I compiled the file, and nothing changed. What first?<\/strong> Look for a .l10n.php<\/code> file of the same name. If it is older than your MO file, it is the one WordPress reads.<\/p>\n
    Why did my translation disappear after an update?<\/strong> A language pack replaced your file in wp-content\/languages\/plugins\/<\/code>. Keep your PO file elsewhere and recompile it.<\/p>\n
    Does the theme use the same process?<\/strong> Yes. You use wp-content\/languages\/themes\/<\/code> and your theme’s text domain.<\/p>\n
    Sources<\/h2>\n