Opened 2 months ago

Last modified 4 weeks ago

#7296 new enhancement

Add PHP files to language packs

Reported by: swissspidy's profile swissspidy Owned by:
Milestone: Priority: normal
Component: Translate Site & Plugins Keywords: has-patch has-unit-tests



The WordPress core performance team is working on a Performant Translations feature plugin that uses a new approach to handle translation files in WordPress, making localization blazing fast. This plugin helps to make localized WordPress sites faster by replacing the traditional MO translation files with PHP files, which are much faster to parse.

Learn more at

The goal is to merge this new feature into WordPress 6.5, but nothing is set in stone yet. I merely want to get a headstart on making all the infra changes.

Anyway, once that lands, will need to serve PHP files as part of language packs.

-> Here is the PR adding PHP support to GlotPress

I do have a patch for the \WordPressdotorg\GlotPress\Customizations\CLI\Language_Pack class to enable this for plugins and themes. But I couldn't find where the language packs are generated for core. Any help would be appreciated.

Another open question is if and how PHP files should be added conditionally. If a site is running WordPress 6.0, the language pack (either for core or a plugin/theme) shouldn't need to include the PHP files. Though it doesn't really hurt either, as the files are rather small (smaller than the MO file).

Attachments (2)

7296.diff (2.7 KB) - added by swissspidy 2 months ago.
POC patch for the Language_Pack command class
7296.2.diff (4.5 KB) - added by swissspidy 2 months ago.
Updated patch that also exports PHP files for core

Download all attachments as: .zip

Change History (9)

2 months ago

POC patch for the Language_Pack command class

#1 @mihdan
2 months ago

This is a great idea, hopefully this approach will be in WordPress core soon!

2 months ago

Updated patch that also exports PHP files for core

This ticket was mentioned in PR #5306 on WordPress/wordpress-develop by @swissspidy.

2 months ago

  • Keywords has-patch has-unit-tests added

Notable changes from the plugin

  • Does not automatically convert any MO files to PHP files upon reading.
    • This avoids any FS interaction on regular requests, avoiding any unexpected results.
    • Makes the logic much simpler.
    • This additional feature can stay in the Performant Translations plugin for those who wish to use it.
  • No integration with Language_Pack_Upgrader to automatically convert MO files to PHP files.
    • This was only needed because didn't yet serve PHP files in language packs.
    • If someone is using a custom translation platform like Traduttore, it is up to them to provide PHP files as well (if they want to)



  • [ ] Merge in latest changes from plugin

Trac ticket:

#3 @Otto42
2 months ago

Can we get some statistics on why this improvement is better? And maybe a simplified explanation of how it works?

#4 @swissspidy
2 months ago

@Otto42 Sure, please see for an in-depth analysis of various solutions including the PHP file approach, covering extensive benchmarks and comparisons. See also as linked in the ticket description.

tl;dr: instead of MO files, WP will load PHP files returning arrays containing the translations, which is much faster and benefits from OPcache as well.

We‘re targeting a 6.5 merge with all the necessary blog posts etc. This ticket here is for bringing this on the radar for meta early on.

@ocean90 commented on PR #5306:

4 weeks ago

If an MO file has a corresponding PHP file, that file is loaded instead.

To keep the PR even "simpler" can we remove this part from this PR for now too? So basically as a first step just let add the foundation (replacement of POMO) and then extend that with the PHP format. This should give us more confidence that the replacement is working as expected with just MO which will still likely be the primary use case for a while.

@swissspidy commented on PR #5306:

4 weeks ago

@ocean90 What would be your proposed timeline for that? For gradual adoption I would recommend not removing the part but simply changing the default format in the translation_file_format filter to mo. Later on we can then simply switch the default to php. Given the benefits of PHP I would suggest doing that sooner rather than later. Alternatively, keep the default but don't ship PHP translation files yet (so control it via the translation API)

@swissspidy commented on PR #5306:

4 weeks ago

btw, yes I am aware of the failing tests. And no, leaky core tests are not fun.

Note: See TracTickets for help on using tickets.