Envisioned usage would be mainly in system messages and templates.

In T413375#11600305, @Tacsipacsi wrote:

In T413375#11599883, @Legoktm wrote:

How will/does VisualEditor handle the new parser function?

The same way it handles all parser functions: it does as if it was a template named #isbn:963-12-3456-7 with zero parameters, making the ISBN itself uneditable. ☹ Do we have a generic task for implementing support for parser functions in VisualEditor? It has so many sub-projects that I have no idea where to look for it.

This is a bad idea. It's going to be annoying.

If it's a user's custom thingy then it would have to be saved in their userspace, not in the MediaWiki: namespace, @Awesome_Aasim e.g. [[user:Aswesome_Aasim/Custom-pre-save-transform.php]], and you'd have to allow PHP as a content model.

How exactly does one "create ContentHandler delivery lists?" - can this be added to the task description? It's very vague.

For context here, the Portuguese word for Turkey is Turquia, but the Porgueuse word for turkey is peru, and the Portuguese word for Peru is Peru. Names of countries are capitalised in Portuguese.

How does MediaWiki-extensions-Disambiguator identify disambiguation pages @kaldari ? I presume it makes a list (in Special:DisambiguationPages) and then on page rendering checks any links against the list -- is that right?

I think people know about this now. The main follow up is T397129: Bundle Extension:Disambiguator with MediaWiki.

In T397133#11562038, @Aklapper wrote:

No. Please do not completely change the scope of an existing ticket. Thanks.

In T397133#11560104, @Mr._Starfleet_Command wrote:

In T397133#11558353, @Bugreporter2 wrote:

In T397133#11555963, @Mr._Starfleet_Command wrote:

DPL3 is no longer maintained and is now incompatible with current MediaWiki, so obviously it is out of the question. DPL4, on the other hand, is now marked as stable, and is compatible with MediaWiki 1.44+. Maybe time to start considering it?

It might have been better to change the task description instead of just burying it.

I don't get what you mean. Could you please clarify?

In T397133#11555963, @Mr._Starfleet_Command wrote:

DPL3 is no longer maintained and is now incompatible with current MediaWiki, so obviously it is out of the question. DPL4, on the other hand, is now marked as stable, and is compatible with MediaWiki 1.44+. Maybe time to start considering it?

In T373711#11552386, @Izno wrote:

... that task is irrelevant to rouge's issue anyway. (T392330)

We'd like to add stuff like this to preview checks, see T394016: Check edit constraints on page preview - there is a way to do this, you just need to implement it.

I've told you elsewhere that Regex should be its own content-model, but you're like "yeah, nah, it's gonna be replaced soon," - but that was years ago, and it still hasn't been replaced!

Also, if the point of long page warning is to warn users that they're in danger of exceeding $wgMaxArticleSize (2048 KiB by default), then it performs this function poorly.

I strongly agree with what @Ammarpad wrote -- this should be encoded in the core. MW should run straight of out of the box without any local customisations.

I managed to duplicate this with T414954: Check for edit conflicts on page preview.

Thanks @Aklapper

Is this actually a bug or should it be closed as invalid? @Aklapper

OK, I see. So it's the bot that makes its own log, not MediaWiki. If that's the case, then there are no changes to MediaWiki. You need to talk to whoever wrote/runs the bot. A well-written bot should output an error log.

In plain text, you can't have links, styling or templates. Are any of those actually critical though?

This is not necessary. The spam blacklist prevents such pages from being created.

Do you need the links though?

If you want the template, instead you can use a null comment:

Why would you need this to work?

In T394016#11514499, @SomeRandomDeveloper wrote:

In T394016#11510872, @Bugreporter2 wrote:

Good idea to break it down. Some of the constraints may need tweaking to get them to work with preview. Might it be a good idea to create subtasks?

I think that would be overkill. I would rather spend time on writing the actual patches than on creating more tasks.

Thanks for looking at this @SomeRandomDeveloper!

Well, yeah, the error is in saving the page, and it's an error based on the order of operations. To fix this, we need to work out what the operations are, and change the order in which they're executed. So, what needs to be done is some code analysis to identify that.

This is a valid bug. I think I may have overzealously phrased "without error" but it should at least consider informing the user as to what has just happened.

I have edited the task description to focus on the draft namespace, which becomes:

In T407507#11474498, @MaryMunyoki wrote:

anything else left to do on this ticket?

@SD0001 I can't see the screenshots:

In T396305#11456665, @Dragoniez wrote:

In the meanwhile, I'm starting to wonder.... Is this worth fixing at all, if the content namespaces aren't really expected to contain plaintext pages?