Heads up on an interaction with the WordPress 6.5 .l10n.php format.
When the downloader installs a pack that only contains .mo/.po (no .l10n.php), and the site already has a .l10n.php for that text domain from an earlier version, the old PHP file keeps being used. WP 6.5+ and performant-translations prefer the .l10n.php over the .mo and do not compare timestamps, so the freshly downloaded .mo gets shadowed and the site serves outdated strings.
I hit this with a self-hosted GlotPress/Traduttore source wired through api.names (those packs are .mo only). I fixed it on my side by regenerating the .l10n.php from the downloaded .po on deploy with wp i18n make-php, but it would be nicer if the downloader took care of it, since it is the thing that knows a pack was just (re)installed.
Two options that would solve it:
- Delete an existing
.l10n.php for a package when a new pack is installed. Cheap, and WP or performant-translations regenerates it from the fresh .mo on the next load.
- Or run something like
WP_Translation_File::transform() over the installed files to write a fresh .l10n.php directly.
The first is probably enough and avoids needing WP-CLI at install time.
Is this something you would consider? The cleaner fix might live upstream in Traduttore (ship the .l10n.php inside the pack), and I have raised that there too: wearerequired/traduttore#284. But the downloader is where a lot of .mo-only packs land in practice. What do you think?
Heads up on an interaction with the WordPress 6.5
.l10n.phpformat.When the downloader installs a pack that only contains
.mo/.po(no.l10n.php), and the site already has a.l10n.phpfor that text domain from an earlier version, the old PHP file keeps being used. WP 6.5+ and performant-translations prefer the.l10n.phpover the.moand do not compare timestamps, so the freshly downloaded.mogets shadowed and the site serves outdated strings.I hit this with a self-hosted GlotPress/Traduttore source wired through
api.names(those packs are.moonly). I fixed it on my side by regenerating the.l10n.phpfrom the downloaded.poon deploy withwp i18n make-php, but it would be nicer if the downloader took care of it, since it is the thing that knows a pack was just (re)installed.Two options that would solve it:
.l10n.phpfor a package when a new pack is installed. Cheap, and WP or performant-translations regenerates it from the fresh.moon the next load.WP_Translation_File::transform()over the installed files to write a fresh.l10n.phpdirectly.The first is probably enough and avoids needing WP-CLI at install time.
Is this something you would consider? The cleaner fix might live upstream in Traduttore (ship the
.l10n.phpinside the pack), and I have raised that there too: wearerequired/traduttore#284. But the downloader is where a lot of.mo-only packs land in practice. What do you think?