[#47933] - [6.2] [AI] Language fallback chain
- Pending
- Medium
- Build: 6.2-dev
- # 47933
- Diff
- MacJoom:language-fallback-chain
User tests: Successful: Unsuccessful:
Pull Request resolves no issue
- I read the Generative AI policy and my contribution is either not created with the help of AI or is compatible with the policy and GNU/GPL 2 or later.
Partly generated by AI - refactored and reviewed
Summary of Changes
Adds an opt-in per-string language fallback chain so a regional language
(e.g. de-CH) can fall back to a closer base language (e.g. de-DE) before
dropping to en-GB, instead of showing English whenever an extension ships no
translation for the regional variant.
The fallback for a language is resolved with this precedence:
- Administrator override — a per-language map configured in
Languages → Options (com_languages component params). - Language pack default — an optional
<fallback>element in the pack's
langmetadata.xml. - None →
en-GBonly (today's behaviour).
Language::load() resolves the chain once per tag (cycle-safe, multi-level),
memoises it, and preloads it weakest-first before the requested language.
Because strings merge last-wins, the requested language keeps precedence on the
keys it provides while only the missing keys are filled from the chain — this
is a per-string fallback, not a whole-file one.
This supersedes #39152 and addresses the review feedback there:
- Per-string fallback (not per-file), as requested.
- Base + override load model with ordered, multi-level chains.
- User-controllable and opt-in; with no fallback configured the chain is
empty and the new loop is a no-op (zero added I/O), so default behaviour and
performance are unchanged. No core language pack ships a<fallback>tag.
Scope: This PR ships the mechanism only. No core or core-distributed
language pack declares a <fallback>, and this PR does not add one — default
behaviour is unchanged for everyone until a pack maintainer or a site
administrator opts in. Whether and where to declare <fallback> defaults is
deliberately left to each translation team, not core.
Files changed
libraries/src/Language/Language.php—getFallbackChain()resolver,
getFallbackOverrides()reader (memoised, guarded for early bootstrap), and
the preload loop inload().administrator/components/com_languages/config.xml— new Language Fallback
options fieldset with a repeatabletag → fallbacksubform.administrator/language/en-GB/com_languages.ini— language strings.
Testing Instructions
- Install the
de-CHandde-DElanguage packs (admin client). - Install a third-party extension that ships de-DE but not de-CH language
files (e.g. DPCalendar). - Set your administrator language to de-CH (User profile / Languages).
- Open the extension in the administrator. Note the UI is in English.
- Go to Languages → Options → Language Fallback, add a row
Language = de-CH,Fallback Language = de-DE, and Save. - Reopen the extension.
(Alternative to step 5: add<fallback>de-DE</fallback>inside the<metadata>
block ofadministrator/language/de-CH/langmetadata.xml.)
Actual result BEFORE applying this Pull Request
With the administrator language set to de-CH, an extension that only provides
de-DE files is displayed in English (en-GB).
Expected result AFTER applying this Pull Request
The extension is displayed in German (de-DE): strings missing from de-CH
are filled from the configured fallback, while any strings that do exist in
de-CH keep their de-CH value. With no fallback configured, behaviour is
unchanged.
Documentation Changes Required
Yes — document the optional <fallback> element of langmetadata.xml and the
new Language Fallback option in com_languages, plus a note for the language
pack build/Crowdin tooling.
Link to documentations
Please select:
-
Documentation link for guide.joomla.org: TBD
-
No documentation changes for guide.joomla.org needed
-
Pull Request link for manual.joomla.org: joomla/Manual#665
-
No documentation changes for manual.joomla.org needed
| Status | New | ⇒ | Pending |
joomla-cms-bot
- | Category | ⇒ | Administration com_languages Language & Strings Libraries |
I like the idea behind this pr and can see it solving real world problems. Its not just about language variants such as de_CH or fr_CA being able to "fallback" to de_DE or fr_FR instead of en_GB for an extension it also opens the possibility of a site admin running joomla in their preferred language which might not be translated 100% yet and them being able to chose which language the missing strings are replaced with instead of being forced to use en-GB.
I could be building a site in my native language but its not translated 100% and my second language is not english but french. This PR will allow me to see joomla in my preferred first and second choice languages. Thats why the site owner should be able to define their fallback language.
I like the idea behind this extension and can see it solving real world problems. Its not just about language variants such as de_CH or fr_CA being able to "fallback" to de_DE or fr_FR instead of en_GB for an extension it also opens the possibility of a site admin running joomla in their preferred language which might not be translated 100% yet and them being able to chose which language the missing strings are replaced with instead of being forced to use en-GB. I could be building a site in my native language but its not translated 100% and my second language is not english but french. This PR will allow me to see joomla in my preferred first and second choice languages
I like the idea behind this pr and can see it solving real world problems. Its not just about language variants such as de_CH or fr_CA being able to "fallback" to de_DE or fr_FR instead of en_GB for an extension it also opens the possibility of a site admin running joomla in their preferred language which might not be translated 100% yet and them being able to chose which language the missing strings are replaced with instead of being forced to use en-GB. I could be building a site in my native language but its not translated 100% and my second language is not english but french. This PR will allow me to see joomla in my preferred first and second choice languages
| Labels |
Added:
Language Change
PR-6.2-dev
|
||
Out of the discussion of the last PR i felt it is necessary to add an override possibility for an administrator - either to override the fallbacklanguage tag to an own setting or because the language maintainer hasn't added the tag (yet). I guess that langmetadata.xml is overwritten with every update - so changes there would be lost.
As currently coded this is a global setting and not per extension
so if your site is de-CH you can set it to global fallback to de-DE (and then en_GB)
but if an extension is not available in de-CH or de-DE you will fallback to en_GB even though it exists in de-AT
As currently coded this is a global setting and not per extension
so if your site is de-CH you can set it to global fallback to de-DE (and then en_GB)
but if an extension is not available in de-CH or de-DE you will fallback to en_GB even though it exists in de-AT
maybe i am overthinking it
As currently coded this is a global setting and not per extension so if your site is de-CH you can set it to global fallback to de-DE (and then en_GB) but if an extension is not available in de-CH or de-DE you will fallback to en_GB even though it exists in de-AT
maybe i am overthinking it
Thats true but I think it is an edge case - extension providers usually provide the most common language and that is what should be used as fallback
Hmm as mention in the other PR i do still think that this is the responsible of the developer to run a simple copy script within his build process. Just copy de-de to de-ch done. This is BTW also the same thing the de-DE core langauge pack does to generate the de-CH, and the other de-XX language packs. I personally think that we are adding here just another layer of complexity into the system just for this german special thing.
When the decision is already take to include this please explain why we need another option for that in the GUI? If anything like this will be merged I think the fallback options should be handled on the core language pack level and does not need a option for the site owner to even override that right? Or I'm missing something?
cc @tecpromotion