One File In, Five Formats Out: How to Future-Proof Your WordPress Translations

You spent three weeks translating your WordPress theme into Spanish. The .po file is perfect — every string reviewed, every variable intact, every plural form correct. Then your client decides to migrate from a classic PHP theme to a headless setup with React on the frontend.

Suddenly your .po file is useless. The React app needs .json. The legacy PHP widgets still need .mo. The freelancer handling the mobile app wants .xliff. And nobody has time to re-translate 4,000 strings into three different formats.

This is not an edge case. It is the reality of modern WordPress development, where themes ship with both PHP and JavaScript components, plugins use a mix of Gettext and i18next, and clients change their minds about architecture more often than they change their passwords.

Why Translation File Formats Matter More Than Ever

Five years ago, WordPress translation was simple. You had a .po file (human-readable source) and a .mo file (compiled binary). That was it. Every theme, every plugin, every translation tool spoke the same language.

Today, the WordPress ecosystem uses at least five translation file formats in production:

The Five Formats You Need to Know

.po (Portable Object) — The human-readable source format used by GNU Gettext. Contains original strings (msgid) and their translations (msgstr). This is what translators edit.

msgid "Add to Cart"
msgstr "Anadir al carrito"

msgid "Your order has been shipped to %s"
msgstr "Su pedido ha sido enviado a %s"

.mo (Machine Object) — The compiled binary version of a .po file. WordPress reads .mo files at runtime using load_textdomain(). Faster than parsing .po at runtime, but not human-editable.

.json (JavaScript Object Notation) — Used by wp_set_script_translations() for JavaScript-based translations in Gutenberg blocks, React components, and modern themes. WordPress expects a specific JSON structure with locale_data keys.

{
  "locale_data": {
    "flavor-starter": {
      "Add to Cart": ["Anadir al carrito"],
      "Your order has been shipped to %s": ["Su pedido ha sido enviado a %s"]
    }
  }
}

.php (PHP Array) — An increasingly popular format for themes and plugins that use Laravel-style translation loading. Some modern WordPress themes bypass Gettext entirely and load translations from PHP arrays for performance.

<?php
return [
    'Add to Cart' => 'Anadir al carrito',
    'Your order has been shipped to %s' => 'Su pedido ha sido enviado a %s',
];

.xliff (XML Localization Interchange File Format) — The industry standard for translation interchange between different tools and platforms. Used by CAT (Computer-Assisted Translation) tools like memoQ, Trados, and Memsource. Essential when working with professional human translators.

<trans-unit id="1">
  <source>Add to Cart</source>
  <target>Anadir al carrito</target>
</trans-unit>

The Problem: Format Lock-In

Most translation tools produce one output format. Poedit gives you .po and .mo. WPML stores translations in the database (not in files at all). Weglot keeps translations on their servers in a proprietary format. Even TMS platforms like Crowdin and Lokalise require you to manually configure export formats for each project.

This creates format lock-in — your translations are trapped in whatever format your current tool produces. When your requirements change, you face two options:

1. Re-translate everything in the new format (expensive, time-consuming, and you lose any manual corrections)
2. Write custom conversion scripts (error-prone, especially for complex plural forms and variables)

Neither option is good. Both waste time and money. Both introduce risk.

Real Scenarios Where Format Lock-In Hurts

Scenario 1: Theme modernization. Your client's theme is being rebuilt with Gutenberg blocks. The old PHP templates used .mo files. The new blocks need .json for wp_set_script_translations(). Your 3,000 translated strings need to exist in both formats during the transition.

Scenario 2: Agency workflow. You manage 20 client sites. Some use classic themes (.mo). Some use headless setups (.json). One uses a custom framework that reads PHP arrays. You need the same translations in different formats for different clients.

Scenario 3: Professional review. Your AI translations are 95% accurate, but you want a native speaker to review the remaining 5%. Professional translators use CAT tools that import .xliff. You need to export your translations to .xliff, send them for review, and merge the corrections back.

Scenario 4: Platform migration. Your client is moving from WordPress to a custom Node.js application. The new app uses i18next and needs .json files. Your 5,000 translated strings in .po format need to be converted — without losing a single variable or plural form.

The Solution: Translate Once, Get Every Format

SimplePoTranslate takes a different approach. When you upload a .po, .pot, .json, or .xliff file and run a translation, you get back a ZIP containing all five formats:

translations-es_ES.zip
├── flavor-starter-es_ES.po
├── flavor-starter-es_ES.mo
├── flavor-starter-es_ES.json
├── flavor-starter-es_ES.php
└── flavor-starter-es_ES.xliff

This is not a "premium feature" locked behind an enterprise tier. Every paid plan — Pro ($19/month) and Lifetime ($399 one-time) — includes all five output formats in every translation job.

Why This Matters for Future-Proofing

When you have all five formats from the start, you never need to re-translate. Your translations are an asset that adapts to any technical requirement:

• Client migrates from classic to Gutenberg? Deploy the .json file.
• New developer prefers PHP arrays? Hand them the .php file.
• Professional translator wants to review? Send the .xliff file.
• Moving to a different CMS? The .json and .xliff files are platform-agnostic.

You translate once. The formats are ready when you need them.

How Each Format Works in WordPress

Knowing which file goes where is essential for a clean deployment.

Deploying .mo Files (Classic PHP Themes and Plugins)

wp-content/languages/plugins/woocommerce-es_ES.mo
wp-content/languages/themes/flavor-starter-es_ES.mo

WordPress loads these automatically when the site language matches. No plugin required. Zero database overhead. This is the approach that delivers the best performance.

Deploying .json Files (Gutenberg Blocks and JS Components)

wp-content/languages/plugins/woocommerce-es_ES-{handle}-{md5}.json

The filename includes the script handle and an MD5 hash. WordPress matches these when you call wp_set_script_translations() in your plugin or theme. If you are building Gutenberg blocks, this is the file that makes your translated block labels and descriptions appear correctly.

Using .xliff Files (Professional Review Workflow)

.xliff files are not deployed to WordPress. They are used as an interchange format when you need to send translations to a professional reviewer or import them into a CAT tool. The workflow looks like this:

1. Upload .po to SimplePoTranslate and get .xliff in the ZIP
2. Send .xliff to your translator or reviewer
3. Receive corrected .xliff back
4. Upload corrected .xliff to SimplePoTranslate and get updated .mo and .json

This round-trip workflow preserves every variable and plural form because SimplePoTranslate's Syntax Locking protects them at every stage.

The Vendor Lock-In Test

Here is a simple test to determine whether your current translation workflow has a lock-in problem:

1. Can you export your translations as standard .po files right now?
2. If you cancel your translation tool subscription today, do you keep every translated string?
3. Can you import your translations into a completely different tool or platform without re-translating?

If the answer to any of these is "no," you are locked in. Services like Weglot and GTranslate fail all three questions — cancel the subscription and your translations vanish. WPML stores translations in the database, making export possible but painful. Even desktop tools like Poedit pass the test on paper but limit you to .po and .mo only.

With SimplePoTranslate, the answer to all three questions is "yes." You download standard files in five formats. They are yours. Delete your account tomorrow and every translation you ever made still works.

Building a Format-Agnostic Translation Library

For agencies and developers managing multiple projects, the smartest approach is to build a translation library — a Git repository or shared folder where you store translated files for every client project.

translations/
├── client-acme/
│   ├── es_ES/
│   │   ├── flavor-starter-es_ES.po
│   │   ├── flavor-starter-es_ES.mo
│   │   ├── flavor-starter-es_ES.json
│   │   ├── flavor-starter-es_ES.php
│   │   └── flavor-starter-es_ES.xliff
│   └── de_DE/
│       └── ...
├── client-globex/
│   └── ...

When a client needs a new format, you already have it. When a client changes platforms, your translations migrate with zero effort. When a new developer joins the team, they can see exactly what has been translated and in which formats.

This is what "future-proof" actually means — not predicting which technology your clients will use next year, but making sure your translations work with whatever they choose.

Ready to stop worrying about file formats? Try SimplePoTranslate free — upload one file, get five formats back. No conversion scripts, no re-translation, no lock-in.