fix(i18n): resolve regional locales to the catalogue shipped for their language - #42
Merged
Merged
Conversation
…r language WordPress matches translation files by exact locale, so a site set to es_AR looked for roxyapi-es_AR.mo, found none, and rendered English even though roxyapi-es_ES.mo was sitting in the same folder. Found by installing 1.7.5 from the directory into a clean WordPress and setting the site to Spanish (Argentina), which is a real customer configuration. WordPress offers dozens of regional Spanish, Portuguese, German and French locales, so the alternative was copying one catalogue per variant and copying it again whenever a locale is added upstream. This maps by language prefix instead: any xx_YY resolves to whichever xx_* catalogue is shipped, so one file per language covers every current and future variant. The filter only sees paths WordPress could not read, so an official wp.org language pack for the exact locale always wins and is never shadowed. Verified live across es_AR, es_MX, pt_PT, de_AT and fr_CA.
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
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.
WordPress matches translation files by exact locale. A site set to
es_ARlooks forroxyapi-es_AR.mo, finds none, and renders English — even thoughroxyapi-es_ES.mois sitting in the same folder.Found by installing 1.7.5 from the WordPress.org directory into a clean container and setting the site language to Spanish (Argentina), which is a real customer configuration. 1.7.5 would not have helped them.
Why a filter rather than more files
WordPress offers dozens of regional Spanish, Portuguese, German and French locales. Shipping one catalogue per variant means copying the same file ~20 times and copying it again whenever a locale is added upstream. This maps by language prefix instead, so one file per language covers every current and future variant.
The filter only ever sees paths WordPress could not read, so an official wp.org language pack for the exact locale always wins and is never shadowed.
Verified live, clean install from the directory
Guarded by
test-locale-fallback.php, including a non-vacuity check, an assertion that an exact match passes through untouched, that other text domains are never touched, and that an unsupported language (ja) is left alone rather than handed an unrelated catalogue.