A mature WordPress site contains PO, MO, POT, and JSON files under plugins, themes, the global languages directory, and an old deployment tree. Nobody knows which catalogs are current, which are generated, or which custom translations will disappear during the next update.
Treat the scan as an ownership exercise, not a deletion list. Connect every maintained source to its generated output, runtime location, component release, and update owner. Files that cannot be explained should remain untouched until their role is proven.
What it means
Language-file management covers the inventory, ownership, validation, compilation, placement, and lifecycle of WordPress translation catalogs. POT files describe translatable source messages, PO files contain editable translations, MO files serve compiled PHP gettext messages, and generated JSON files can supply translations to JavaScript.
A scan identifies candidate files and metadata. It does not show by itself which catalog WordPress loads, whether a duplicate is safe to remove, or whether an update will replace a custom file.
A realistic WordPress example
A multilingual site has two German MO files for the same plugin: one inside the plugin directory and one in the global WordPress languages directory. An older deployment folder contains a third copy with the same filename. Only one serves current requests, but the timestamps alone do not reveal which one.
The administrator maps each file to its component version, text domain, locale, source PO, deployment destination, and update owner. The dormant deployment copy is excluded from the active inventory, while the two reachable catalogs are tested to establish their loading order before either is moved.
Why it matters and when to use it
Scan after installing, updating, translating, or migrating a component, when troubleshooting inconsistent translations, and before any language-file cleanup. A reliable inventory prevents custom work from being mistaken for generated output and exposes files that will be overwritten by the next release.
The goal is not the smallest possible language directory. It is a clear, update-safe chain from authoritative source to runtime artifact, with proof that each required locale works in the contexts where visitors and administrators use it.
A straightforward route for beginners
- Back up custom PO sources and their MO or JSON outputs before renaming, compiling, moving, or deleting anything.
- Inventory the file type, locale, text domain, component, version, full path, timestamp, size, hash, and owner.
- Classify each item as vendor-managed, a WordPress language pack, maintained custom source, generated output, duplicate, or unknown.
- Connect every MO or JSON artifact to the PO, POT, or source revision that produced it.
- Compare maintained catalogs with the current component source to find new, obsolete, fuzzy, contextual, and plural messages.
- Quarantine unknown files for review instead of deleting them from the scan results.
The advanced route
Present the inventory as a source-to-runtime matrix. One row should connect a component release, locale, domain, source or POT revision, maintained PO file, generated MO or JSON file, deployment path, update owner, and last successful runtime test.
- Create a collision view for identical filenames in different directories and record which loading mechanism can reach each copy.
- Check site locale, user locale, and multisite context before declaring a catalog unused.
- Test PHP and JavaScript translations separately because they can use different artifacts and registration paths.
- Compile only validated PO sources and regenerate JSON through the supported component workflow.
- Schedule another review after plugin, theme, WordPress, or deployment changes that can alter ownership or loading order.
Risks, common mistakes, backup, and rollback
The same domain and locale can exist in several reachable paths, so deleting the oldest or smallest copy is unsafe. Moving a vendor-managed file may break updates, while keeping custom translations inside an update-owned directory can make them vanish without warning.
After changes, test a message matrix across the front end, administrator screens, JavaScript interfaces, singular and plural forms, context variants, and fallback locales. If strings disappear, fallbacks change, or generated files diverge from their source, restore the preserved files and return the inventory entry to review.
How AIOWS helps:
AIOWS Language Compiler
AIOWS Language Compiler can scan supported WordPress language sources and provide a central view of catalogs that may need validation or compilation. Use that view to identify the intended component, locale, text domain, PO source, current MO output, and filesystem location before generating anything.
A scan result is the beginning of classification, not permission to clean up files. Compare each candidate with the current plugin or theme release and determine whether WordPress, the vendor, a deployment process, or your team owns it. Where identical filenames appear in different directories, establish which copy can be loaded in the affected request.
Compile only an approved and validated PO source to its matching MO destination. Confirm the generated file, then open a clean WordPress request and inspect a known translated string. Test administrator and public contexts separately when user and site locales can differ, and handle JavaScript JSON catalogs through the appropriate build and registration path.
Language Compiler cannot determine translation authorship, make an unknown duplicate safe to delete, repair an incorrect text domain in source code, or prevent an update from replacing files in an update-managed directory. Restore preserved files if a locale loses strings or fallbacks change. Record the scan date, exclusions, owners, source-to-output map, compilation result, deployment path, runtime proof, and next review trigger.
Related AIOWS articles
- How to Compile WordPress PO Files into MO Files
- WordPress Plugin Translations Not Showing: Causes and Fixes
- How to Configure Cache for a Multilingual WordPress Site
Conclusion and recommended route
Build an ownership map before treating the language tree as a cleanup target. Maintain authoritative POT and PO sources, regenerate MO or JSON outputs through supported tools, and verify a multilingual message matrix. A useful inventory explains the lifecycle of every active catalog instead of merely shortening the file list.
