Speedy: Allow sysops to issue warning upon csd

[Amorymeltzer]

Requested on IRC.

It's not really standard practice, mainly since most pages are already tagged with users warned, and we offer the option to open the user's page after deletion. Still, I suppose it could be helpful? There are already a lot of options there.

[MusikAnimal]

By "warning" I assume you mean something like Template:Db-notice. If so, 👍. I have always wanted this; If I speedy delete a page that wasn't already tagged for speedy, I of course want to let the user know the reasoning. So I usually tag for speedy myself, then immediately delete. This is subpar because the notice says "A page you created has nominated for speedy deletion ... you can contest it by...". They can't contest it because I already deleted it. So I think that's step one... adding a |deleted=yes parameter or something to the templates, such that the language is adjusted accordingly.

[Amorymeltzer]

Would it be easier to just use something like {{Db-reason-notice}}? That has most of the text that we'd like — the "contest this" text is like half of CSD notices — and would be easier to modify than switching on and off tenses in each individual template. That'd also allow us to just use the deletion summary, which would be nice so that we're not stuck maintaining something like {{Db-notice-multiple}}.

I've been meaning to look into being smarter about detecting and using CSD templates on a page. I'll try and tackle that next week as I think that will be required before moving on this, which by itself should be fairly straightforward.

[MusikAnimal]

Would it be easier to just use something like {{Db-reason-notice}}?

That's better than nothing. I do like how Template:Db-copyvio-notice for instance explains the problem, and how they can avoid it in the future. Ideally we could get all that with our post-deletion notice.

[Amorymeltzer]

Slept on it, I think you're right as usual. Db-notice-multiple looks feasible, I've made changes to {{db-notice-multiple/sandbox}}, take a look and tell me what you think. Language could probably use some work, especially the closing note and stuff around F3/F7. I'll try and whip something up next week to implement this on our end, but it'd probably be good to ask for input at Template talk:Db-notice and WT:CSD before going too far.

ETA: Apparently you thought of this three years ago in #300 (comment)! We could expand the use of *-warn-deletion templates and build something like Db-csd-notice-custom to handle those. That'd simplify things, can just hook into the already-existing infrastructure for issuing notifications and toggle between user and sysop.

(Also, per #300 (comment), I'm one of the few who uses the radio buttons. I had no idea, I thought surely everyone would do it that way!)

[Amorymeltzer]

@MusikAnimal Alright, I've got something working. Still tweaking, but I had a question for you first.

You wrote the current openUserTalk setup in #300, which I'm coopting/replacing with this. Basically, it checks the preferences whenever the user makes a selection and determines whether to check openUserTalk based on that. That's different from how we handle tagging notifications, where the box has to be checked AND selected in the preferences for the notification to be issued.

Aesthetically and behaviorally, I think these should be aligned. I like the system you wrote, but I worry that dynamically changing a box they've already (de)selected might be easy to miss once they move to the criteria section.

In terms of this specific issue, if there is a tag already on the page, I'd like to default to not issuing a warning after deletion, assuming they were notified upon the page being tagged. I've got it working, but because selecting an option can dynamically turn the warning on, I'm also building in a popup confirmation in those cases; this is especially important for radioClick (submit right away) users, as they have no chance to toggle the box.

Moving to the same system as the tag notification would alleviate this, but I wanted to take your temperature first. I'm overwriting the openUserTalk option, so if there's a good time to change behavior, this'd be it.

Also, Do we have a good way of migrating/removing preferences? The old openUserTalk... stuff will persist otherwise, which isn't the end of the world.

[Amorymeltzer]

To that last point, https://github.com/azatoth/twinkle/blob/5971e76d81c9f960f14a54f06d4850c212ede1ef/twinkle.js#L401-L410 has some old (pseudo)code aimed at a system of version preferences. There's other stuff in there that we can probably remove, and it's probably overkill for just this, but that's something to think about down the road at least.