feat(i18n): consume central translations from escalated-dev/locale#51
Merged
feat(i18n): consume central translations from escalated-dev/locale#51
Conversation
Wire the WordPress plugin to load translations from the central
escalated-dev/locale Composer package, with site-level overrides
under languages/overrides/.
Layered loading (later layer wins):
1. vendor/escalated-dev/locale/languages/escalated-{locale}.mo
2. languages/overrides/escalated-{locale}.mo
Falls back to the legacy in-tree languages/ dir when the central
package is not installed, so existing checkouts keep working until
escalated-dev/locale v0.1.0 lands on Packagist.
Note: assumes the central package ships compiled .mo files. WordPress
gettext requires .mo at runtime; .po alone is not loadable.
Composer resolves escalated-dev/locale ^0.1 from github.com/escalated-dev/escalated-locale via vcs repository (v0.1.1 tag). Once the package is submitted to Packagist this block can be removed.
mpge
added a commit
that referenced
this pull request
May 2, 2026
The plugin's textdomain loader reads from
vendor/escalated-dev/locale/languages/escalated-{locale}.mo (introduced
in #51 / cfc9c81). The release workflow built the zip from a fresh
checkout without running composer install, so vendor/ was empty and the
zip silently shipped without central translations — the plugin's
fallback to the legacy in-tree languages/ dir hid the regression at
runtime, but downstream installs miss portfolio-wide updates.
Add a setup-php + composer install step before the rsync. composer.json
itself stays excluded from the zip (end-users don't need it); only the
resolved vendor/ tree is bundled.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Wires the WordPress plugin to consume translations from the new central
escalated-dev/localeComposer package, replacing the in-tree
languages/*.pofiles as thecanonical source of strings.
escalated-dev/locale: ^0.1tocomposer.json.Escalated::boot()translation loading into a dedicatedload_translations()method that loads two layers via WordPress'gettext system (later layer wins):
vendor/escalated-dev/locale/languages/escalated-{locale}.movia
load_textdomain().languages/overrides/escalated-{locale}.movia
load_textdomain().in-tree
languages/dir viaload_plugin_textdomain()so existingcheckouts continue working until v0.1.0 is on Packagist.
languages/overrides/.gitkeepas the override drop-in location.README.mdwith a Translations section andCHANGELOG.md..mo / .po assumption
WordPress' gettext implementation only loads compiled
.mofiles atruntime, not
.posources. This PR assumes the central packageships pre-compiled
.mofiles at:The escalated-locale repo's CI is expected to compile
.poto.movia
msgfmtand commit/publish the compiled artifacts. If that repoends up shipping JSON instead of
.mo, this plugin will need a smallJSON-to-gettext bridge (
MO::import_from_readeror equivalent) — trackthat as a follow-up.
Status
Blocked on escalated-dev/escalated-locale v0.1.0 Packagist publish.
CI will fail at
composer installbecauseescalated-dev/locale ^0.1does not yet exist on Packagist. This is expected — the PR is marked
draft for that reason. Once v0.1.0 is published, re-run CI and lift the
draft status.
Test plan
escalated-dev/localev0.1.0 publishes to Packagist, runcomposer update escalated-dev/localelocally and verifyvendor/escalated-dev/locale/languages/escalated-{locale}.moexists.
WPLANG=fr_FR(or equivalent), confirmstrings load from the central
.mo(e.g. add a sentinel stringto the central package and verify it renders).
escalated-fr_FR.moinlanguages/overrides/andverify its entries override the central translations for the
same keys.
vendor/escalated-dev/localeand confirm the plugin stillloads translations from the legacy
languages/dir (fallbackpath).