T50956 Can't override optional message in all languages with local customisation (original) (raw)
Can't override optional message in all languages with local customisation
Event Timeline
• bzimport raised the priority of this task from to Medium.Nov 22 2014, 1:41 AM
• bzimport added a subscriber: Unknown Object (MLST).
This is the normal behaviour for locally overridden messages.
I guess this needs the followup to https://gerrit.wikimedia.org/r/#/c/57518/ with the completion of the plan as per bug 46579 comment 13 (1), i.e. ability to override a message in all languages by writing on /en?
I know that this is the normal behaviour for "normal" messages (and complained about that in bug 1495).
But I wonder why this [apparently optional message, since it's empty by default and customized by wikis on their own] (so far) worked well? (i.e. it got shown even when not using the English interface, as it's still(?) the case on Meta and elsewhere).
herbythyme wrote:
This has now hit Meta and makes dealing with cross wiki issues - disruption/spamming and the like FAR harder. Getting it sorted soon would be appreciated.
(In reply to comment #2)
But I wonder why this [apparently optional message, since it's empty by
default
and customized by wikis on their own] (so far) worked well?
Perhaps the key is "empty by default", i.e. defined as "-" beside being ignored (rather than optional)? How to deal with blank or "-" messages is a tricky thing.
*sigh* don't tell me we're going to have to revert the fallback change again.
(In reply to comment #5)
(In reply to comment #2)
But I wonder why this [apparently optional message, since it's empty by
default
and customized by wikis on their own] (so far) worked well?Perhaps the key is "empty by default", i.e. defined as "-" beside being
ignored
(rather than optional)? How to deal with blank or "-" messages is a tricky
thing.
Yes, this is the issue. I tested this and running "Language::factory('de')->getMessage('sp-contributions-footer')" returns the message '-', which MessageCache would then treat as a found message.
But what I'm having trouble understanding is why that is happening. The 'sp-contributions-footer' message isn't defined anywhere in MessagesDe.php, so where is the '-' coming from? The message should come back as non-existent, allowing it to fall back onto the content language.
I guess it comes from MessagesEn.php because of the fallback merging on l10n cache.
On the other hand, it imagine it wouldn't be too hard to add the logic I proposed earlier in code review:
If MediaWiki:A exists, skip l10n cache.
It's not a perfect solution and one step back wrt to the goals of this patchet, but in any case there will a big migration later to separate overrides from customisations.
Any other ideas?
I'm not too sure. I mean, in the original links from comment 1, the issue doesn't appear to occur anymore. Also, my patch didn't change the current message fallback process; it merely appended to it.
As for how to fix the bigger issue of actually handling language fallbacks properly, unfortunately that can't be done without somehow being able to interpret the results of the CDB cache.
There is a possible workaround using WikimediaMessages to rename the message key, thus stopping regular the fallback.
There is a possible workaround using WikimediaMessages to rename the message key, thus stopping regular the fallback.
Could you provide more details?
I can't reproduce this anymore (of course, for other language codes without their subpages created). I think this is fixed by my work on T229992, because all languages have implicit fallback to en.
It can still be an issue if the site language is not English and the /en subpage is not created.
Content licensed under Creative Commons Attribution-ShareAlike (CC BY-SA) 4.0 unless otherwise noted; code licensed under GNU General Public License (GPL) 2.0 or later and other open source licenses. By using this site, you agree to the Terms of Use, Privacy Policy, and Code of Conduct. · Wikimedia Foundation · Privacy Policy · Code of Conduct · Terms of Use · Disclaimer · CC-BY-SA · GPL · Credits