This sounds to me like something that T107595 (Multi-Content Revisions) could be useful for.

@AfroThundr3007730 Usually these notices are not rly revision specific however. (protection expires, namespace/page notices are removed and/or added based on the behaviour of the audience/not the content etc etc).

Mostly I just miss the PHP class EditPageNotice.

There's also the editintro parameter to index.php.

@Tgr already captured in the description, by point 4 of "Site specific Page level notices"

Change 910112 had a related patch set uploaded (by Bartosz Dziewoński; author: Bartosz Dziewoński):

[mediawiki/core@master] [WIP] Introduce a class for producing edit notices etc.

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

Change 910602 had a related patch set uploaded (by Bartosz Dziewoński; author: Bartosz Dziewoński):

[mediawiki/extensions/VisualEditor@master] Use edit notices etc. from MediaWiki core

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

Comparing the initial edit summary to what I'm implementing, almost everything is done, except for:

These notices are also not tracked in core and thus not queryable by API (T45683)

I consider an action API out of scope, but as shown by the VisualEditor API change, it is trivial to add now.

and mostly lack structured information to decouple presentation from the data

I am improving this only slightly, by adding a name for each intro message (the message key if available, or something made up in other cases).

The use case I want to support is omitting some of the notices in some tools (because the tool presents the information in a different manner – e.g. https://gerrit.wikimedia.org/g/mediawiki/extensions/DiscussionTools/+/c7cf74eab0dab5fe25c6a1d53fed9a2a0642a61d/modules/NewTopicController.js#52).

I think trying to decouple presentation from the data beyond that is completely infeasible. Our struggles with mobile editing have shown that a) each editing tool must be able to display HTML error messages or perish b) our communities will, eventually, adapt the error messages to different interfaces if they see them being displayed poorly. I think this also applies to the intro messages.

• no permission to edit

I think this is an error message, and not an intro message, therefore I'm not including it. (As evidence, I note that if this message is shown, then all intro messages are hidden.)

It's already possible to generate these messages – using PermissionManager::getPermissionErrors() in PHP code, or using action=query&prop=info&intestactions=edit&intestactionsdetail=full&errorformat=html&errorsuselocal=1 in the action API (except for T335319).

• longpage-hint

I think this is a warning message specific to EditPage, similar to e.g. 'blankarticle', and not an intro message, therefore I'm not including it.

(I also think it's outdated and should be deleted, and I don't want to encourage its use.)

• thisisdeleted

This is the short message shown in page subtitle, even in read mode, and I don't think it should be in this list. I included 'recreate-moveddeleted-warn' though, which is the intro message serving the same purpose.

Change 910112 merged by jenkins-bot:

[mediawiki/core@master] editpage: Split off producing edit intro messages and preloaded content

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

In T201613#8803054, @matmarex wrote:

Comparing the initial edit summary to what I'm implementing, almost everything is done, except for:

and mostly lack structured information to decouple presentation from the data

I am improving this only slightly, by adding a name for each intro message (the message key if available, or something made up in other cases).

The use case I want to support is omitting some of the notices in some tools (because the tool presents the information in a different manner – e.g. https://gerrit.wikimedia.org/g/mediawiki/extensions/DiscussionTools/+/c7cf74eab0dab5fe25c6a1d53fed9a2a0642a61d/modules/NewTopicController.js#52).

I think trying to decouple presentation from the data beyond that is completely infeasible. Our struggles with mobile editing have shown that a) each editing tool must be able to display HTML error messages or perish b) our communities will, eventually, adapt the error messages to different interfaces if they see them being displayed poorly. I think this also applies to the intro messages.

I think we're on the same page here. I was never thinking about the html contents within the message when I wrote that, more the fact that there are messages, what type, at most a title or something the like. The idea being that if you know exactly what kind of message at a data level is required, you could basically present it in a way that is suitable for that message (show an icon in the iOS app, that when clicked shows the full message for instance).

Really nice work @matmarex. The kind of fundamental building blocks that create more readable, predictable and easier to work with code in my opinion.

Change 910602 merged by jenkins-bot:

[mediawiki/extensions/VisualEditor@master] Use edit intro messages and preloaded content from MediaWiki core

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

This change – surprise, surprise! – seems to have broken a hack in FlaggedRevs: T337637: Duplicated edit notice about pending changes.

@matmarex: I checked few Edit Notices as you suggested, they seemed to be consistent through out different editors: Old Wikitext Editor, VisualEditor and New Topic tool in DT.

T353870: editintro no longer does language conversion since MediaWiki 1.41+ might be caused by https://gerrit.wikimedia.org/r/910112/ ( 6a20dc2 , If0b05710cb52a977bf4e85947d72d68683a0a29e ).