Language Compiler
How to Scan and Manage WordPress Language Files
Inventory WordPress PO, MO, POT, and JSON files by component, locale, domain, path, and ownership before compiling, moving, or removing a catalog.
Main Menu
WordPress translations do not run from the files translators produce. A translator works in a .po file, which is human-readable text, but WordPress only reads .mo — a compiled binary version of the same content. If the .po exists and the .mo does not, or the .mo is older than the .po, your site displays English and gives no indication why.
That single fact explains most translation problems, and these guides work outward from it. Compiling .po files into .mo, and doing it in a way that survives a plugin update overwriting the language folder.
Another article covers auditing what is actually installed — which locales are present, which are current, and which came from a plugin that has since been removed and is now dead weight in the languages folder.
A diagnostic article covers the specific and common case where a plugin’s strings stay stubbornly English while the rest of the site translates correctly. The cause is usually a missing compiled file, a text domain that does not match, or a load order problem, and each looks the same from the front end.
Narrow subject, and the article on compiling .po files into .mo resolves most of it.
Inventory WordPress PO, MO, POT, and JSON files by component, locale, domain, path, and ownership before compiling, moving, or removing a catalog.
Trace a missing WordPress plugin translation through its source string, text domain, locale, catalog format, path, and load timing before rebuilding or relocating files.
Compile an approved WordPress PO catalog into the matching MO runtime file, verify the locale, text domain, and path, and protect the result from later updates.