The wfDiff() calls in there were way too slow, so I don't think it's an option to block page saves.

This can either use after-the-fact notifications or maybe some other pre-validation method/hook can be added to check for signatures in the text beforehand and give some appropriate notification.

Also, the plan was to move this into the job queue: T99573: F14. Pushing notifications into the JobQueue should happen at the generateEventsForRevision() level.

@Legoktm just as a clarification: We are not sure yet if this will contain any notifications. The ideal way for our story would be to add info about mentions to the save message (which would only be possible if the mentions are not sent out after the save, hence our initial question). Notifications are more of a plan b.

Thanks for looking into it!

In T136928#2360401, @Lea_WMDE wrote:

@Legoktm just as a clarification: We are not sure yet if this will contain any notifications. The ideal way for our story would be to add info about mentions to the save message (which would only be possible if the mentions are not sent out after the save, hence our initial question). Notifications are more of a plan b.

Thanks for looking into it!

I think he was talking about the notifications generated by the mentions themselves (i.e. to the mentioned users), not the proposed "your mention was/wasn't sent" notifications you seem to be talking about. T99573 asks for the step of figuring out which users have been mentioned to be deferred even more than it already is, whereas for a save notice we'd probably need it to happen sooner.

@aaron how does edit stashing/preprocessing for wikitext edits work? Could we do something like:

1. User stops typing for a while
2. JS sends the edit to the server for opportunistic preprocessing
3. The preprocessing step (or a separate step afterwards) figures out which users would be pinged if the edit were to be saved
4. This information is sent back to the client, and JS displays it to the user

This could give you an as-you-type "mention preview" with some delay. We might also be able to use a similar technique to show a post-save notice, by having JS send a request to an API module that waits for the processing to be done and displays the result. Jobqueue-ifying mention parsing would probably make that harder though.

That seems kind of hacky and prone to being inconsistent. What is the compelling use case for throwing this information at users make edits? The tasks seemed unclear.

In T136928#2363518, @aaron wrote:

That seems kind of hacky and prone to being inconsistent. What is the compelling use case for throwing this information at users make edits? The tasks seemed unclear.

Because of the complex rules for when a link to a user page is or is not considered a mention, it's common for users to think that they've pinged someone when they actually haven't. My favored long-term approach to this is legoktm's idea of making mentions explicit and unambiguous using different syntax (e.g. {{ping:Catrope}}; not that hard to migrate to because people already use a template for this anyway). The short-term approach that this task's parent task proposes is to show a mid-edit, pre-save or post-save notice stating which users would be / have been pinged.

Perhaps the explicit {{ping:}} thing is less trouble than I think it is and we should just skip right to it.

@Addshore can we close this, now that we have an answer to the original question?

@Lea_WMDE Yes I believe so!