Yes, I tested it. It works in editnotices; it did cause a template loop on the page itself yeah. But the main complaint from Izno seems to be about cross-template communication, not about accessing info about the current page; and this definitely works if the page given is not the current page.

In T50175#8865219, @Izno wrote:

getContent does not expand templates. I'm pretty sure the PHP implementation of getCategories

See this thread: this popup keeps nagging people even for just opening a new tab.

Boldly triaging as unbreak now since this half totally breaks maps functionality.

If T50175 is doable, it's probably the best way to do this. That would enable other functionality and enable wikis to properly customize when they load editnotices.

There's https://www.mediawiki.org/wiki/Extension:CategoryToolbox but I don't how suitable the code is.

the vast majority of them are test edits, which would have to be reverted anyway

That's definitely true, but that's also why I mention "It also makes it hard for the abusefilter to detect when new users are adding a new section" - I created filter 1245 which blocks a decent portion of test edits, but it can only detect those with a heading. And yeah, hopefully prompting for a heading stops some portion of the test edits.

I think this would be useful simply because I think people often don't realize/know about (?i) and so use lcase when using rcount.

I updated the task description with an estimate of how often new users add sections without a header, since I saw in T272543 that @ppelberg created T274221 to estimate this issue and mentioned that "If we observe this happening often [i], I think it makes sense to adjust the approach this ticket is implementing".

That makes sense. I wasn't able to find the reason for this from searching through phab. The reason I raise this issue is that there's been lots of new users using add topic. While most set a header, there's quite a few who don't, and it is quite annoying, since that means either just reverting the user or manually adding a section heading. The cases you mention are where power users automatically add a heading through a template; I think the new topic tool should be able detect when a heading is automatically added (since it already generates a preview). I think T295509 should be implemented and what I'm asking for is when that's done, the contrapositive of "ask me to put a section heading in the section heading field if I'm not typing it in my new section" should also be done.

Since T213006 is resolved, I think this isn't stalled anymore.

Huh, I didn't get notified about this ticket until today. The last time I was emailed about this I was hoping T249787 would be done and couldn't figure out how to do this migration otherwise, so I just moved my jobs to buster. Looks like https://wikitech.wikimedia.org/wiki/Help:Toolforge/Pywikibot has been updated finally, and I was able to do the migration; wasn't too bad, and I like the new interface.

I think it is more likely that the errors relating to using the wikimarkup for italics but not closing it (which are automatically fixed by the parser to output valid html it seems) are not counted by the linter extension but are by linthint than anything to do with things not updating.

Yup, this is definitely very important. How exactly are editors supposed to communicate with mobile IP editors if they receive absolutely no notification from talk page messages?

I can reproduce with Firefox on Linux from the US (User agent: "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:71.0) Gecko/20100101 Firefox/71.0", Firefox on Android ("Mozilla/5.0 (Android 10; Mobile; rv:68.0) Gecko/68.0 Firefox/68.0"), but not Chrome on Linux ("Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.108 Safari/537.36"2), or Chrome on Android ("Mozilla/5.0 (Linux; Android 10; Pixel 3a) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.108 Mobile Safari/537.36"). Seems like a Firefox bug.

This seems Unbreak now to me, as it seems like about every Page Preview by every reader from everywhere in the world is affected (I can reproduce in Asia). "Switch summary to proxying to the backend service" by @Pchelolo from https://gerrit.wikimedia.org/r/#/c/mediawiki/services/restbase/deploy/+/519107/ (https://github.com/wikimedia/restbase/commit/dd1bc3b535a91ca0e7513a4460a29d3815969ca0) seems most likely at a glance to be the issue, since only the page summary is not updating.

Dup of T222859?
Probably hit the Catalan Wikipedia first due to the train..

Now every time an edit is made to an article where there are unknown parameters, the preview-only warning is shown on view until the page is purged; see report of issues at VPT.

There's a broken comment in both pages

<!-- Inline citations added to your article will automatically display here. See en.wikipedia.org/wiki/WP:REFB for instructions on how to add citations. --

which should be

<!-- Inline citations added to your article will automatically display here. See en.wikipedia.org/wiki/WP:REFB for instructions on how to add citations. -->

resulting the rest of page to be treated as a comment, including the templates to be substed.

The contrast of links against the background is 3.91, below the 4.5 required by WCAG AA for normal text. (going off this )

.fmbox shouldn't be treated like a page issue because the class is not used for page issues - it is used for edit notices and system messages (see documentation of template here). Treating fmbox as a page issue also breaks things on enwiki e.g on (view logged out)
https://en.m.wikipedia.org/w/index.php?title=Barack_Obama&action=edit&mobileaction=toggle_view_mobile

Indeed already configurable on-wiki through Template:Reviewednote-NPF and Template:Unreviewednonote-NPF (Messages for deletion tags, along with what appears to be every type of message sent, are also configureable, e.g Template:Empty-warn-NPF)