User tests: Successful: Unsuccessful:
Right now within Joomla\CMS\Language\Language
when loading a default language's strings, those strings are mixed in with the strings of the active language. While the behavior is technically correct, this results in two message catalogues being mixed into one with data being overwritten during the various calls. Instead of doing this, a more preferential behavior is to treat each language's strings as a separate message catalogue, and that is what this PR implements.
A new class property, $defaultStrings
, is introduced which is similar to the existing $strings
array except it will only hold the strings of the default language when those are loaded, resulting in the $strings
array now only holding strings of the active language. Methods which do read/write operations to this array (the _
method handling converting language keys to translated strings, the load
and loadLanguage
methods when reading files into memory, and the hasKey
method when checking for existence of a key) are updated to work with this new methodology of splitting strings into different properties.
Install a second language to your Joomla site and make that your active language. With this PR applied, the translation keys should continue to be displayed in your active language if available, fall back to English if not available (when debugging is not active, when active we will skip this check), and display the untranslated key if not present at all.
If accepted, anyone who has subclassed this class and is working with the $strings
class property should update their code to be aware of the new $defaultStrings
class property. If they don't, the worst thing that happens is they would no longer get the English language fallbacks as those won't be included in the existing property.
Category | ⇒ | Libraries |
Status | New | ⇒ | Pending |
Labels |
Added:
?
|
A little more memory (compared to total memory usage) is worthwhile for this change
and since this will go to a major version change 3.7 -> 3.8 ?
if any 3rd party language-related extension need some updating, they will have time to do it
and since this will go to a major version change 3.7 -> 3.8 ?
Looks nice from what I see and understand
I have tested this item
Behavior after this patch is the same as before here and as detailed in the test instructions. No specific issue.
Rebased onto 3.9 branch with conflicts resolved.
Labels |
Added:
?
Removed: ? |
I'm abandoning this. Working on some stuff in the Framework package (having the message catalogue extracted to a separate object with the catalogue having its own awareness of configurable fallback catalogues) that this approach conflicts with.
Status | Pending | ⇒ | Closed |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2018-06-02 01:26:00 |
Closed_By | ⇒ | mbabker | |
Labels |
Added:
?
Removed: ? |
@Bakual this is what I was referencing in the other issue.