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).

Maybe different versions of software deployed.

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?

Tyler: Any other ideas? (refering to comment 7)

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.

(In reply to comment #9)

I'm not too sure. I mean, in the original links from comment 1, the issue
doesn't appear to occur anymore.

This is only because I created https://incubator.wikimedia.org/wiki/MediaWiki:Sp-contributions-footer/de as a workaround to prevent the complete unusability of the interface for me.
On e.g. https://incubator.wikimedia.org/wiki/Special:Contributions/QuincyMcc?uselang=fr it still appears.

Change 72867 had a related patch set uploaded by Parent5446:
Complete usage of message fallback chain

https://gerrit.wikimedia.org/r/72867

For the records, patch was -1'ed and needs improvement.

Add Wikidata tag: per recent discussion https://www.wikidata.org/wiki/MediaWiki:Talkpageheader is changed but currently the functionality only work if interface language is English.

There is a possible workaround using WikimediaMessages to rename the message key, thus stopping regular the fallback.

In T50956#7996294, @Nikerabbit wrote:

There is a possible workaround using WikimediaMessages to rename the message key, thus stopping regular the fallback.

Could you provide more details?