I cannot reproduce this now. It might have been fixed after this task was filed.

There's already a generous limit of 10_000 bytes for the pattern length. But it's not clear if it's possible to check the nesting depth without executing the regex. Else silencing the error might the better option.

I have added screenshots. In regular watchlist line, the indicated unwatch link in the no-AMC mode can't be clicked because of this rule: skinStyles/mediawiki.special.changeslist.less#228.

As user A, enable email notifications for thanks, and change your language away from the site default

It can also be obeserved if only B changes their language; which is more likely what happened in the enwiki report

Go to https://www.mediawiki.org/wiki/Special:Watchlist?action=render&days=7&enhanced=0&from=20251110074718&hideWikibase=1&hidepreviousrevisions=1&isAnon=false&limit=250&peek=1&urlversion=2 ...
Get a completely empty page.

Yes

OK, if you shorten url on wiki, both codes will be shown.

You can use the alt code: https://w.wiki/_mzo2

Underlying issue has been fixed in T409700. Many pages with title input are already passing 'creatable' option. It worked, but only after the form has been submitted. It will now work before submission.

In T223051#11354575, @Multichill wrote:

[ ... ] Yes, the underlying issue has been address. Yes, the two example files have been solved,

The task shows files known to have been affected and they have been fixed. There's nothing more to do.

but we still have plenty of files out there that need solving

Is this an assumption or you've real examples? If you know them we can run the script.

OK, that looks like T409367: Gadgets not loaded when wikitext editing

The section is added by local gadget not the extension.

This affects most pages using the Title input widget like Special:TalkPage, Special:WhatLinksHere etc, because the relevant option is not being passed to the JS widget, but it do support excluding such pages from the suggestion.

I have now figured out that the page has been reloaded as if it had been saved after clicking the "Save" button (no JSON error was reported)

See https://www.mediawiki.org/wiki/Help:Dummy_edit#Null_edit

but the change has not been implemented.

Because there's no change. The escape sequence (you can't save that) has been decoded back to readable character which already exists.

Date of creation was May 1st for the "User:" account (based on userpage creation logs from my main account)

There was no 'account' creation from your main account on May 1. But on May 3, you created User:Chuckthetestbuck

The listed pdf files seem to have been fixed now? Maybe the problem only remain for djvu files now.

It seems there's not much to do here. The linked files seem to have been corrected in the meantime by whatever.

For https://commons.wikimedia.org/wiki/File:2018-05-11_Joensuu_station_4.jpg

In T376564#11208987, @IKhitron wrote:

Great thing, but sure it already works?

This is not yet deployed. It will be in 1.45.0-wmf.21. (T376564#11208211)

Note that "- 1" casts to 0 not -1.

There's a patch already: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/ProofreadPage/+/1144673

• Syntax Highlighting option/button not available in editor toolbar.

It's available and works on wikitext pages: https://en.wikisource.org/w/index.php?title=Davis_v._North_Carolina&action=edit