Someone within enWS said "html input form recently redesigned to use OOUI layout with mw-messaging" ... not that such means much to me. If that means the above effect, then we have an issue that should have been better explained and addressed through communities, and probably still does.

I didn't think it was possible to cause the language variants to follow fallbacks while finding customised messages... Also, I can't think why a commit about "html input form recently redesigned to use OOUI layout with mw-messaging" would alter how messages work across the whole wiki.
also, this does not appear to really be a config change request, moving

Either way, in the /en language wikis, the system should be able to default text that is specific for that wiki for /en-ca and /en-gb settings where those pages do not exist. I believe that it used to be the case that there was some sort of default as I used to see the /en message and I cannot remember changing this in my preferences, and feel it unlikely I would have made a recent change.

I shall add the languages team to the ticket as it is likely to be happening at Commons, etc. If this is the consequence of the code as is, it seems to more a weakness than a strength. We should not have an expectation that the wikis should maintain separate (and replicating) /en /en-ca /en-gb versions. It is not reasonable to expect our users to know that the consequence of their change that little drop down in their preferences is the disappearance of context sensitive information.

Can you give a concrete example that does not work with expected outcome?

Oops ... MediaWiki:Movepage-moved was the specific case. (community discussion) I have subsequently created internal transclusions for /en-gb and /en-ca to alleviate this particular case. [Feel free to delete one of the transcluded files if you wish to view]

Though any of our modified messages at enWS will now presumably will have the same issue if I am now to understand correctly. Or is that not the case?

@Nikerabbit

I have set a corresponding situation at test.wikipedia.org

Test file: https://test.wikipedia.org/wiki/Namespace_page
Modified mw text page: https://test.wikipedia.org/wiki/MediaWiki:Movepage-moved

Try moving with settings as en and en-gb and you will see en uses the modified message and en-gb uses generic message

@matmarex would the above issue have any relationship to T86865?

That should not be related (other than the commits from that task having changed some localisation messages). I think it always worked the way you describe.

I think this is a dupe of T3495 where there is lots of discussion how should the fallbacks actually work. One big issue right now is that there is no way to distinguish between incompatible modifications (do not use shipped translations) and minor modifications (using shipped translations is still okay).

It looks like a variation of the issue though almost the reverse.

There the discussion is that other languages should not fall back to /en.

Here with /en-gb and /en-ca it would seem to be imperative to automatic fallback to en rather than falling back to mw defaults. It would beggar credibility that there is the requirement that enWx wikis should have to replicate every modification to a page in the Mediawiki: ns. It is far easier to create required en-xx variations rather than try to create/reproduce every mediawiki: ns message.

Couldn't this be a configuration component at a site level?

Just ran across this headache again on enwiki, some user had changed their interface to en-gb and were no longer seeing any project custom interfaced messages - suggest they be able to fall back to en when interface message does not exist and user language is an en-variant.

enwiki VPT recent thread for reference: https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)&oldid=832585665#No_Watchlist_notice_for_RfAs

This is clearly a case of minor modifications (using shipped translations is still okay). One would think that for languages where we have XX and XX-LL that we can stem and identify same language. This is quite problematic for English language wikis where any person is using en-gb, en-ca, etc.

It is not clear what you are arguing for. This issue is very complicated for at least three reasons (some of which I have surfaced in 2013 already) and will not have a quick fix:

• There is no way to differentiate in MediaWiki namespaces between minor changes (like spelling fixes) and major changes (like watchlist notifications)
• The current technical implementation makes it very hard to change the order
• Changing the current behavior is absolute no-go without heavy community involvement, solution for the first reason and a migration plan

Arguably, there should be a better way to deliver the watchlist notifications that does not involve all this unnecessary complexity of message fallbacks, but it seems nobody has suggested this path yet.

@Nikerabbit - there may be competing arguments. Mine is

FOR MediaWiki namespace interface messages EXISTING locally:
WHEN project language is EN
IF en-xx DOES NOT EXIST fall back to that projects en message, not to the mediawiki default.

@Xaosflux thanks. That is what I believe that I have been saying, or believed that I have been saying. And only where mediawiki namespace message has been customised, ie. is a local message.

[remainder of my rant redacted]