Wikipedia:Village pump (proposals)

"WP:PROPOSE" redirects here. For proposing article deletion, see Wikipedia:Proposed deletion and Wikipedia:Deletion requests.

 Policy Technical Proposals Idea lab WMF Miscellaneous 

• Table of contents
• First discussion
• End of page
• New post

The proposals section of the village pump is used to offer specific changes for discussion. Before submitting:

• Check to see whether your proposal is already described at Perennial proposals. You may also wish to search the FAQ.
• This page is for concrete, actionable proposals. Consider developing earlier-stage proposals at Village pump (idea lab).
• Proposed policy changes belong at Village pump (policy).
• Proposed speedy deletion criteria belong at Wikipedia talk:Criteria for speedy deletion.
• Proposed WikiProjects or task forces may be submitted at Wikipedia:WikiProject Council/Proposals.
• Proposed new wikis belong at meta:Proposals for new projects.
• Proposed new articles belong at Wikipedia:Requested articles.
• Discussions or proposals which warrant the attention or involvement of the Wikimedia Foundation belong at Wikipedia:Village pump (WMF).
• Software changes which have consensus should be filed at Phabricator.

Discussions are automatically archived after remaining inactive for nine days.

« Archives, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214

Discussion at Wikipedia:Village pump (WMF) § Unnecessary line on fundraiser banner

 You are invited to join the discussion at Wikipedia:Village pump (WMF) § Unnecessary line on fundraiser banner. It is about a controversial line in current fundraiser (putting invitation here as it is kind of a proposal to remove it). –ExclusiveEditor _{Notify Me!} 14:56, 11 July 2024 (UTC)

A profound emotion of acceptance It’s privilege to be invited on this matter but my familiarity with the topic is pretty much kindergarten level, but I would try my best if I can to be of service for the cause of of this organization spreading facts and knowledge of false/correct informations and understanding of both information’s existence. Thank you for the inviteThe Summum Bonum (talk) 12:22, 12 July 2024 (UTC)

Are you using an LLM to generate your answers, or are you writing in a language other than English and using a translator program? Donald Albury 17:44, 12 July 2024 (UTC)

Doesn't look like an LLM. They are either translating, or are a new user trying to be very well language(d), reminding me of myself when I was new. ExclusiveEditor _{Notify Me!} 13:45, 13 July 2024 (UTC)

I tried removing unnecessary lines on my comment then learned that it is considered an act of destroying the context of a non private conversation, within minutes I changed it. I would have just said a simple "thank you for the invitation but Im not qualified on the topic I was invited to."(The Summum Bonum (talk) 13:25, 18 July 2024 (UTC)

productive criticism? or Assuming Im not human?am I invited or nil?The Summum Bonum (talk) 12:19, 18 July 2024 (UTC)

Is my name Intimidating? that your curiously asking me if I'm using an LLM. "I find your lack of faith disturbing"- Darth Vader. lol. now I sound more like an A.I.. The Summum Bonum (talk) 12:28, 18 July 2024 (UTC)

@The Summum Bonum: Its not about your name but the way you wrote your reply in a stretchy fashionable and to be honest, in an unusual way made it feel like written by an LLM, especially because this descriptions also match others comments which were confirmed to be written by LLM. However I think it is clear now, that is really written by you, a human! ExclusiveEditor _{Notify Me!} 13:29, 21 July 2024 (UTC)

Request

Hi Wikipedia users and admins!

I am a new user on Wikipedia. I have made more than 10 edits and I need to edit some pages that are semi-protected or first level protection and also create some new pages on Wikipedia, without having to create them as a draft first. Please can you unlock the feature of semi-protected pages or first level protection pages on my account and also make possible for me to create some pages directly, without having to create them as a draft first.

Thanks AdamSala1991 (talk) 08:04, 18 July 2024 (UTC)

@AdamSala1991: You just have to wait one more day and your account will be autoconfirmed, then you can do all of those things. – Joe (talk) 11:39, 18 July 2024 (UTC)

Watchlisted. ——Serial Number 54129 13:17, 18 July 2024 (UTC)

The Khmer Wikipedia appears with the letters in Bold

Hi Wikipedia editors and admins!

I am a new user in Khmer Wikipedia and I have a concern. I have seen that this Wiki appears with its writing system in Bold (dark letters), which previously didn't appeared. This is seen on the language list where the Khmer language appears, when viewing articles on the Khmer Wikipedia and on the search results on Khmer Wikipedia. Can you fix the issue and make the Khmer Wikipedia to appear in normal letters, in all its forms (where the Khmer language appears, when viewing articles on the Khmer Wikipedia and on the search results on Khmer Wikipedia), like the other Wikipedia editions are?

Thanks Cheni001 (talk) 13:57, 18 July 2024 (UTC)

The editors here at the English Wikipedia cannot do anything regarding issues on any other wikis, you will need to ask for help on that Wiki (I don't speak or read Khmer so I can't advise what the best location is, but based on Google Translate km:ជំនួយ:មាតិកា is probably a good place to start looking). However, my guess is that it might be a font issue, you should be able to check that by looking at the entry for Khmer at Help:Multilingual support (Indic). If that is the issue some of the other information on that page may resolve your issue. Thryduulf (talk) 14:11, 18 July 2024 (UTC)

@Cheni001, what kind of phone are you using?

@SGrabarczuk (WMF), is there any chance that the Web team changed any fonts? WhatamIdoing (talk) 05:24, 20 July 2024 (UTC)

Thanks @WhatamIdoing for pinging me! We haven't changed any fonts recently. I will ask the teammates if they know what this may be about, though. SGrabarczuk (WMF) (talk) 20:29, 22 July 2024 (UTC)

Allow everyone to move pages in draftspace

I'm proposing that moving a page that's in draftspace to a target also in draftspace be an action that doesn't require being autoconfirmed. This is so if a draft is created in the wrong place by an IP, they can fix it themselves without going to RM, which they probably don't know exists. An example where this would have been useful is Moshe Mizrahi (basketball) which, according to its history, was created at Draft:Moshe Mizrahi ( basketball), moved to mainspace by an AfC reviewer at Moshe Mizrahi ( basketball) and only then moved to the correct title. This left behind a useless mainspace redirect that I had to RfD. If the IP could have moved the draft to the correct title, there is a good change they would have done so and the useless mainspace redirect would not have been created in the first place. Nickps (talk) 14:46, 18 July 2024 (UTC)

AfC reviewers should and usually do correct the titles of drafts when they move them to mainspace. If and until that happens, what they're called in draftspace doesn't really matter. – Joe (talk) 15:37, 18 July 2024 (UTC)

In theory, I agree that allowing anybody to move a draft to a different draft title would be fine. The problem is that (as far as I know), the MediaWiki permissions system isn't flexible enough to allow non-autoconfirmed moves only in specific namespaces, and the effort required to add that capability wouldn't be justified by the benefit. RoySmith (talk) 15:50, 18 July 2024 (UTC)

Well, similarly to how editors don't have to worry about performance, editors shouldn't worry about how easy or difficult something is to implement either. I'll take it to Phabricator and let the devs worry about it. What we need to figure out is just whether there is any reason not to do it. Nickps (talk) 16:46, 18 July 2024 (UTC)

Please post the phab number here when you get one. RoySmith (talk) 16:47, 18 July 2024 (UTC)

Wait, before I do, are you sure that's right? We can limit who moves a page like we do with Files and Categories. Is there a reason we can't go the other way around with drafts and lift a restriction? Nickps (talk) 16:55, 18 July 2024 (UTC)

For now I just asked VPT to come here. Nickps (talk) 17:00, 18 July 2024 (UTC)

My understanding is that moving a page requires the "move" user permission. The Files and Categories namespaces are special-cased by the movefile and move-categorypages permissions, but I don't believe there is any general-case ability to apply the move permission to arbitrary namespaces. RoySmith (talk) 17:12, 18 July 2024 (UTC)

This seems like a solution in search of a problem. A non-autoconfirmed editor who notices that a page is misnamed and successfully moves it will be a rare creature indeed. Meanwhile, any regular editor can move a draft page to the correct name in Draft space, and AFC editors should be checking the name. It's right there in step 1 of accepting an AFC: "Select an appropriate name". – Jonesey95 (talk) 19:13, 18 July 2024 (UTC)

You are mostly correct. However, a) AfC reviewers don't always do that as my example demonstrates and b) even if we ignore that, I believe that we should be providing as much freedom to users as possible. Locking actions behind user rights should be done only when necessary, not merely because it's convenient. Restricting moves in mainspace makes sense because move vandalism is disruptive. In draftspace that is way less of a problem and if necessary, move semi-protection exists. Nickps (talk) 19:35, 18 July 2024 (UTC)

To be fair, your example is eight years old, was corrected in less than four hours, and the AfC reviewer that accepted it has been banned for years. Do you have any idea how frequent this problem is? I take your point that technical implementation isn't our job, but some sort of cost–benefit analysis still wouldn't go amiss, and I'm sure the devs will ask for one anyway. – Joe (talk) 21:38, 18 July 2024 (UTC)

I'm not sure how I could gather frequency data for this situation but, here's a recent example of a non-autoconfirmed (at the time) editor asking to move a draft to a new title in WP:RM/TR. So it's not like the feature would go unused. Nickps (talk) 01:24, 19 July 2024 (UTC)

Also, going back to the original RfD that inspired this, we find Draft:Marabella North Secondary School ( Marabella Senior Comprehensive), Draft:Philip Dukes ( Viola Soloist) and Draft:Argo ( Sword Art Online ) which were all moved to mainspace to the uncorrected names. That last one might have been a cut and paste since the move log is empty but Argo ( Sword Art Online ) was created all the same. Nickps (talk) 01:51, 19 July 2024 (UTC)

Draft authors usually want to move to mainspace, not another draft name. Giving them a move link and move form which doesn't work for mainspace may confuse and annoy them more than help them. PrimeHunter (talk) 15:31, 19 July 2024 (UTC)

That's one way of looking at it. But, on the other hand, that move form would be the perfect place to put instructions for how to move to mainspace since people would look there. Something like: "This form can be used to change the name of the draft. Only autoconfirmed users can move drafts to the main namespace. If that is what you want to do, see WP:Articles for creation". Nickps (talk) 19:25, 19 July 2024 (UTC)

@RoySmith phab:T370471 has now been opened. Nickps (talk) 19:30, 18 July 2024 (UTC)

I would worry about draft hijacking. BD2412 T 02:18, 19 July 2024 (UTC)

All I hear is "Encourage move vandals to focus on the Draft: space", and I don't think I like what I hear. WhatamIdoing (talk) 05:27, 20 July 2024 (UTC)

This seems less like a solution in search of a problem than a problem in search of a problem. Non-autoconfirmed editors don't need the ability to move pages, and the most common use case (moving their user sandbox to Draft:Title) wouldn't even be covered, since it would cross namespaces. On the other hand, this would open up a broad attack surface for very little benefit. Folly Mox (talk) 09:38, 21 July 2024 (UTC)

I see some comments saying that this will increase vandalism in draftspace but very little evidence to support this view. In my opinion, until someone provides such evidence, restrcting IPs' ability to move in draftspace goes against WP:SOP#2 as it fails to meet the standard of strict scrutiny. Nickps (talk) 12:06, 21 July 2024 (UTC)

WP:SOP#2 doesn't have anything to do with this proposal. Not giving IP addresses/un-confirmed editors the ability to move pages is a technical anti-spam/anti-vandal measure, since moves are demonstrably much harder to undo than plain edits. Sohom (talk) 19:57, 21 July 2024 (UTC)

Such a measure makes sense on mainspace sure, but not on draftspace which is not as popular of a target for vandals and where the damage isn't as front facing. SOP#2 has everything to do with it since it's an arbitrary restriction that targets new/unregistered users. Nickps (talk) 20:06, 21 July 2024 (UTC)

How would you revert a vandal who went on a vandalism spree and moved a few thousand drafts to Draft:<insert_random_expeletive_here> ? (Short answer, you couldn't, you would need to get hold of a page-mover (or if the vandal is more sophisticated, a admin) to undo the damage). Sohom (talk) 20:13, 21 July 2024 (UTC)

The thing you're describing isn't even possible. Moving a page to overwrite a page that already exists is not allowed (except WP:MOR but that is irrelevant). Can you provide an example of my proposal being harmful that can actually happen? Nickps (talk) 21:46, 21 July 2024 (UTC)

They don't have to all be the same random_expletive. (I am somewhat dismayed to discover that Willy on Wheels is a bluelink.) —Cryptic 21:59, 21 July 2024 (UTC)

Ok, in that case I'll just revert the moves like normal. Due to WP:MOR that should be easy. No need for a page mover. Nickps (talk) 23:27, 21 July 2024 (UTC)

Nickps, thank you for volunteering to clean up all the complicated chained page move vandalism your proposal would open the door to, but kindly read the room. Folly Mox (talk) 11:07, 22 July 2024 (UTC)

When I think the room is wrong, I'm going to say so, thank you very much. Also, I'm not just saying it, my actions support it as well. Nickps (talk) 11:12, 22 July 2024 (UTC)

And just to be clear, yes, I'm saying that I'm going to be watching Recent Changes if we do this. Nickps (talk) 11:27, 22 July 2024 (UTC)

I'll try to spell it out a bit more, it takes the vandal exactly one more edit to each page for it be effectively irreversible without admin/page-mover help. Also, I assume you will not be reading RecentChanges, all the time 24 * 7 * 365 hours.

Your previous actions proves the opposite, that we already have to deal with a fair bit of page move vandalism, and we don't want to enable features that opens us up to more of the same kind of vandalism. Sohom (talk) 12:12, 22 July 2024 (UTC)

Again, no one has shown that this draftspace move vandalism will actually happen let alone that our processes will be overwhelmed by it. Up until that is shown, I can only consider such statements fear mongering. But, as I'm willing to compromise, I suggest we at least do a trial of this and see whether I'm right and constructive moves are the rule or you're right and move vandalism overwhelms our processes.

I have to also point out that we do have the tools to deal with move vandalism. Semi-move protection is already a thing and page movers/admins can revert more advanced vandalism. If you're worried about me pushing work to other people, rest assured that if the kind of vandalism you describe actually happens, I'll go directly to WP:PERM/PM. Nickps (talk) 12:24, 22 July 2024 (UTC)

"0 days ago" in time duration calculation

Reading the July 2024 global cyber outages article one notices in the infobox that the incident happened "0 days ago". Shouldn't that be "today" or "Today" instead? Nxavar (talk) 10:32, 19 July 2024 (UTC)

• This was raised a year ago at Template talk:Time ago#Unnatural "0 days ago" and "0 days' time" by Brightgalrs, but it didn't receive a reply. Based on the history of Module:Time ago, Mr. Stradivarius, Johnuniq and GreenC appear to be the people to ask. Thryduulf (talk) 11:09, 19 July 2024 (UTC)

Thanks for pointing this out. Nxavar (talk) 14:38, 19 July 2024 (UTC)

Looks like it was discussed about a year ago at Template_talk:Time_ago. I don't think anyone has volunteered to add this feature, nor is it the result of anyone's previous work causing it, more like a design question than a bug, best way to say "now". Could also try WP:TEMPREQ for help. -- GreenC 15:49, 19 July 2024 (UTC)

It really feels like the most expedient solution would be to use Template:Start date and switch to Template:Start date and age after a day has passed. Firefangledfeathers (talk / contribs) 16:01, 19 July 2024 (UTC)

"Today" isn't the same day everywhere in the world. "0 days ago" indicates less than 24 hours ago, which could include "yesterday" in some time zones. WhatamIdoing (talk) 05:30, 20 July 2024 (UTC)

So have it say "Less than 24 hours ago" or "Less than 1 day ago" instead of "0 days ago" Soni (talk) 03:42, 24 July 2024 (UTC)

Legalize "subsection" parameter of template "imdb title"

There are 20 thousands of pages which refer to a movie's IMDB title page subsection. They can't use Template:IMDb title because the template doesn't document how to link to a subsection.

Even current template allows doing that via undocumented trick (although that produces a warning) - just add /section to the movie id. Example: test at IMDb.

So I propose - either document this trick and make it official, or add another parameter to the template. fuxx (talk) 18:52, 20 July 2024 (UTC)

{{IMDb title}} is meant for an external links section, not a reference. There is rarely reason to link a subsection there. IMDb is a deprecated source for references: WP:IMDb. PrimeHunter (talk) 00:22, 21 July 2024 (UTC)

Does the community still want moved pages to be unreviewed

Back in 2017, the community decided in this RfC that moved pages should be unpatrolled. The feature was stuck in Phabricator purgatory and was never actually implemented.

Does the community still want this feature implemented? (cc @Pppery, @Hey man im josh and @Novem Linguae who participated in an initial discussion on the NPP Discord server, also see T370593) Sohom (talk) 07:44, 21 July 2024 (UTC)

Taking my developer hat away, I personally don't think this should be implemented anymore. Sohom (talk) 07:54, 21 July 2024 (UTC)

I'm really surprised so many people supported that: it would create a substantial added burden for patrollers in exchange for maybe making a very rare problem slightly easier to detect. (Redirects from page moves already go into the queue, and even if they're retargeted elsewhere, a good reviewer should notice the suspicious history.) Unless this is a much larger-scale issue than I'm aware of, I don't think that proposal should be implemented. Extraordinary Writ (talk) 08:00, 21 July 2024 (UTC)

I have seen cases (e.g. recently at AT CBS This Morning) where a long-standing patrolled page becomes unpatrolled because a non-autopatrolled user moved the page - like from vandalism being reverted like CBS This Morning, or from requested moves like (709487) 2013 BL76. There can be quite a lot of these cases. Is this scenario also part of this discussion? thanks. Aszx5000 (talk) 09:36, 21 July 2024 (UTC)

@Aszx5000 That specific behavior is part of a bug that started happening recently and will be probably reverted. It's being tracked in T370593. The default behaviour is to not unpatrol page that are moved. Sohom (talk) 10:00, 21 July 2024 (UTC)

I think the RfC should be respected. Yes, WP:CCC but we really shouldn't overturn an RfC without an new RfC. Besides, this will help with detecting move vandalism in some cases so it is a useful change. Nickps (talk) 12:32, 21 July 2024 (UTC)

• Oppose: If the RfC hasn't been implemented in 7 years, and it was only recently implemented by accident, it makes sense to revisit the discussion instead of implementing it by surprise so much later on in time. As one of the more active patrollers, I absolutely hate the idea of adding to the workload / massive backlog by adding pages to the queue just for being renamed. Really we'd want to just mark it as patrolled 99% of the time anyways. Hey man im josh (talk) 14:49, 21 July 2024 (UTC)
• Strong oppose per nom and Josh. Reviewers already are swamped as it is. (t · c) buidhe 14:53, 21 July 2024 (UTC)
• Oppose on the merits. I agree this is unnecessary and wasteful. But this discussion needed to be had and formally codified anyway to avoid unintentional cabalish behavior /WP:CONLEVEL problems. * Pppery * _{it has begun...} 15:19, 21 July 2024 (UTC)
• FWIW, I attempted to figure out how much moving and patrolling actually goes on so I could see if making it necessary to re-patrol moves would indeed add a significant workload. I came up with 916 moves and 1225 patrols yesterday. My SQL is weak (and my understanding of the MediaWiki schema even weaker) so I don't know if these numbers are accurate or not. If they are, then it looks like this would almost double the patrolling workload. RoySmith (talk) 15:33, 21 July 2024 (UTC)

  Hmmm, maybe I should have restricted this to mainspace? But I'll let somebody with better SQL-fu than I have play with it. RoySmith (talk) 15:34, 21 July 2024 (UTC)

  It's even worse than that - there were more moves in mainspace yesterday than there were total curations. —Cryptic 16:27, 21 July 2024 (UTC)

  Though, as usual, raw statistics are misleading. Neither of our queries, for instance, try not to count page moves by autopatrolled users, or pages moved out of the main namespace without leaving a redirect or where the redirect was later deleted. I can at least compensate for the small sample size by showing stats for all of July up to now, which are better: 7068 page moves starting in mainspace, 13519 mainspace page curations. —Cryptic 16:55, 21 July 2024 (UTC)

• Oppose. I don't see much of a point in implementing this as it would unnecessarily double the workload of the NPP team. Redirects left behind from moves are already placed in the redirect queue (except for users in the page mover, autopatrolled, and redirect autopatrolled groups, including administrators). DannyS712 bot then automatically reviews a portion of them if the changes fit certain criteria, and the rest are reviewed manually. I feel like this system works just fine; it's not like we have a runaway page-move vandalism issue on our hands. —TechnoSquirrel69 (sigh) 17:50, 21 July 2024 (UTC)
• Oppose. To quote myself from 2017: Oppose pending more information. I'm concerned about rushing into something that will potentially hugely increase the load at the already hugely-backlogged WP:NPP. How many pages are moved per day? How many more reviewers would we need to handle the extra load? What's the scale of this problem? Are there other solutions we could explore (e.g. marking pages that have {{disambig}} removed as unpatrolled)? We have the answers to some of those questions above, and it's not looking good. Doing this would double the NPP workload in order to close a loophole that is apparently so small that nobody noticed it had been accidentally left open for the last seven years. Really bad idea. – Joe (talk) 21:35, 21 July 2024 (UTC)
• Comment: the proposal as it developed in the 2017 RfC was not for all article moves but for those by non-EC users which I think was 40 a day at the time. Cenarium's comment is not clear to me but search for "40" (not pinging them because they have not edited since April). Pinging @Ivanvector: who initiated the proposal for their comments. We don't know if this is still a concern or if other mechanisms were put in place. S0091 (talk) 19:39, 22 July 2024 (UTC)
  • That makes more sense. Numbers for July 20 and all of July. —Cryptic 20:02, 22 July 2024 (UTC)
• ??? I don't know that area that well because that not normally where I do my NPP work but I thought this was already happening. For example Extracorporeal procedure was in the cue. The community really needs for fix some things to help with the disaster at NPP but worrying about easy stuff like this really isn't it. North8000 (talk) 20:28, 22 July 2024 (UTC)

Adding a slight speed bump to slow down revert wars.

There's a editor's notice right now on a really contentious page: "You must follow the bold-revert-discuss cycle if your change is reverted." My reaction was, "Good idea. Reverting a revert never seems to end well. Maybe that rule should apply to all pages."

Yes, I know, that's not going to happen. But we can nudge people in that direction. How about a feature detects this and makes the user confirm that's what they want to. "We see you want to revert a revert. This is often viewed with antagonism. Please consider using the BOLD, revert, discuss cycle instead."

And if the user still wants to revert, they can, but at least we've slowed down the madness a tad. Isaac Rabinovitch (talk) 15:34, 23 July 2024 (UTC)

There is an opt-in script (preference?) (although I can't remember where to find it) that asks you for confirmation before actioning a rollback. The intent of this is to avoid accidental rollbacks, IIRC there was a discussion that rejected making it opt-out because it hinders vandal fighting and similar activities, although this was quite a long time ago and consensus may have changed with the rise of tools like huggle, etc Thryduulf (talk) 15:48, 23 July 2024 (UTC)

That is legitimately a good idea in my opinion, although it should be noted that WP:BRD is only an essay and technically optional. Wikipedia:Edit warring, which is policy, could be a better basis for a reminder if a revert-of-revert is detected, and I don't object to the text itself mentioning BRD if it is clear that it's optional (but encouraged).

The functionality itself might need some MediaWiki software tweaking to be implemented, but I'm not a specialist. Chaotic Enby (talk · contribs) 15:51, 23 July 2024 (UTC)

It is difficult to slow down revert wars without slowing down vandal fighting. —Kusma (talk) 16:38, 23 July 2024 (UTC)

You must follow the bold-revert-discuss cycle if your change is reverted. Is that a thing? Or it's just an ordinary editor writing that? Selfstudier (talk) 16:52, 23 July 2024 (UTC)

Awilley added this to Template:American politics AE a few years ago. I assume this was related to his Enforced BRD idea. I don't think it makes sense to tell editors that they must follow an optional process, but WP:EPTALK (which is mandatory for all editors) is less well-known, and perhaps they couldn't get consensus for imposing WP:1RR. WhatamIdoing (talk) 17:00, 23 July 2024 (UTC)

Bit like WP:CRP. Selfstudier (talk) 17:06, 23 July 2024 (UTC)

I'm concerned about how this would impact anti-vandalism, especially when you can't seem to get ahold of an admin to block or protect. It won't matter to a vandal if it takes an extra click and five or ten seconds to re-deface a page; it will matter if takes longer to revert them. Slowing down fights over content disputes is all well and good, but not when the WP:WRONGVERSION is one full of profanity. —Cryptic 17:49, 23 July 2024 (UTC)

Although I am an admin, I do not particularly focus on antivandalism, and in my experience, before I turned on requiring a confirmation prompt for a rollback, I was accidentally rolling back edits far more often than I used rollback for vandalism. In fact, when I do have to revert a lot of edits I still prefer to verify that each edit is indeed vandalism. I think that the 'requiring an affirmative prompt before rollback' setting should be optout rather than optin. Donald Albury 18:08, 23 July 2024 (UTC)

This is a potential application of edit check that is being explored, I believe. Sdkb ^talk 04:08, 24 July 2024 (UTC)

This seems like a good idea, and I'm not concerned about its impact on anti-vandalism. It isn't the end of the world if vandalism is reverted a few seconds later; and it will help cut down on accidental or over-zealous reverts. Cremastra (talk) 00:20, 25 July 2024 (UTC)

What does vandalism have to do with this idea? I'm not talking about making it harder to revert other people's edits. I'm talking about making it harder to do a double revert. Isaac Rabinovitch (talk) 11:32, 25 July 2024 (UTC)

1. Vandal replaces the lead image of a highly-viewed but not-currently-protected article with a freshly-uploaded dickpic at some time after most US admins have gone to bed and before most European admins have woken up. 2. Cluebot immediately reverts. 3. Appalled bystander immediately tags the image on Commons for speedy deletion and asks for the vandal to be blocked at WP:AIV. 4. Vandal makes the same edit, which is a revert of Cluebot; it's slow because of the new revert-of-a-revert feature, but he doesn't mind. 5. Entire group of appalled bystanders try to revert the vandal; it's slow because because of the new revert-of-a-revert feature, and Cluebot doesn't intervene because it doesn't re-revert the same page. 6. Entire group expands their futile pleading for help to WP:RFPP and WP:ANI. 7-20ish: repeat steps 4 and 5 and occasionally 6 until an admin intervenes.

The problem here is that it's making step 5 slower, no matter how large the entire group of appalled bystanders is or how quickly they react. —Cryptic 14:12, 25 July 2024 (UTC)

How often have you seen this happen? Vs how often have you seen revert wars? Isaac Rabinovitch (talk) 14:19, 25 July 2024 (UTC)

This exact scenario? Never, because we don't have this exploitable misfeature you're proposing that makes reverting vandalism arbitrarily slower. Non-exactly-repeated vandalism that persists for dozens of reverts before an admin puts a stop to it? All the time. Try searching the ANI archives for, say, AIV backlogged. —Cryptic 14:33, 25 July 2024 (UTC)

@Cryptic I'm a bit confused, because I don't see a proposal to implement a cooldown timer. Steps 5 and 6 would be "5. Entire group of appalled bystanders try to revert the vandal, get a message asking them to confirm, and hit 'OK'. 6. Entire group moves on with their lives." --Ahecht (TALK
PAGE) 15:32, 25 July 2024 (UTC)

This can't be done in a client-side javascript "Are you sure?" popup like the existing, optional ones for rollback links. There needs to be a roundtrip to the server to find that the attempted edit is a revert, and that at least one of the edits it's reverting was itself a revert, and then kick it back to the user. Besides, the last sentence of the proposal - but at least we've slowed down the madness a tad - makes the goal explicit; if it's not appreciably slowing down a vandalism rerevert, it's not accomplishing its stated purpose anyway. —Cryptic 15:41, 25 July 2024 (UTC)

Although I agree with the spirit behind the idea, I can't help but think that the existing policies rules and guides are sufficient. If an editor is intent on BRRD, for example, there is not much to be done about it except to take it up in talk, if an editor were continuously making use of BRRD to try and force through their view, then that's a behavioral problem and should be dealt with as such. One could ask an admin to impose WP:CRP if the issues were causing disruption. And so on.Selfstudier (talk) 16:12, 25 July 2024 (UTC)

Bot to restore long-term protections after shorter-term higher protections expire

A recurring issue with page protection is that long-term protections are sometimes overwritten by shorter-term protections at a higher protection level. When the shorter-term protection expires, administrators need to manually restore the previous lower protection level. For example, Beyoncé is indefinitely semi-protected due to vandalism and was recently fully protected due to edit warring. When the full protection expired, semi-protection needed to be restored manually by an administrator (more examples: 162794559, 162856607, 162974964, 163272356, 163337925). In addition to this happening after full protection due to edit warring, it also happens with ECP being applied to previously semi-protected articles.

Right now, administrators need to remember on their own, set a reminder, or rely on someone submitting a reprotection request on WP:RFPP. Unfortunately, disruption can be the result when the restoration of protection is delayed too long. Also, concerns about timely restoration can influence administrators to choose an approach other than protection when protection would have been their first choice in some situations.

The bot will not take any action if the duration of the higher protection level extends beyond the prior protection's expiration date, or if the protection level is the same or lower.

Following the requirements in WP:ADMINBOT, I'm requesting community approval before requesting approval at WP:BRFA. Thanks. Daniel Quinlan (talk) 02:47, 24 July 2024 (UTC)

This is a great idea. It would be helpful for the protection log entry to note the original protecting admin, the one responsible for the long-term protection. Firefangledfeathers (talk / contribs) 03:04, 24 July 2024 (UTC)

Definitely! I also plan to include the originally logged reason. Daniel Quinlan (talk) 03:09, 24 July 2024 (UTC)

Thanks, this would be very helpful. Johnuniq (talk) 03:31, 24 July 2024 (UTC)

Great idea. I've had to badger too many admins to reapply protections in similar scenarios. – Aza24 (talk) 06:10, 24 July 2024 (UTC)

I'm definitely not the first person to have the idea. After I starting looking into this, I found more than a few previous discussions (which also helped me iron out some details), such as this proposal for a bot in 2017. Starting with this task, I'm hoping to alleviate some of the drudgery I've experienced as an administrator helping out on WP:RFPP. Daniel Quinlan (talk) 08:56, 24 July 2024 (UTC)

I should also mention https://phabricator.wikimedia.org/T41038 which is from 2012. In the absence of a solution built into MediaWiki, a bot seems like the best approach and I'm volunteering to maintain and run it. Daniel Quinlan (talk) 09:21, 24 July 2024 (UTC)

As I mentioned on discord, and at m:Community Wishlist/Wishes/Restore long term protection when short term protection expires. This would be super handy. ScottishFinnishRadish (talk) 10:48, 24 July 2024 (UTC)

I agree this would be useful functionality. I'n not sure implementing it as a bot is the right approach (but I won't oppose the idea either). T194697 covers the same idea for blocks; all the reasons given there apply equally well to page protections. RoySmith (talk) 12:05, 24 July 2024 (UTC)

I feel like this has been raised before and went nowhere, though I might be misremembering. In any case, yes, this is functionality that should exist, whether as a bot or part of the protection interface. Vanamonde93 (talk) 17:59, 24 July 2024 (UTC)

Ah, now I remember why this sounded familiar: Wikipedia:Bots/Requests for approval/DYKToolsAdminBot. RoySmith (talk) 20:14, 24 July 2024 (UTC)

This would be useful functionality. May I suggest that the bot also drop a templated message about its actions at the user talkpage of the (non-bot) admin who most recently protected the page, so that they can undo/adjust the bot's page-protection if needed? Abecedare (talk) 02:29, 25 July 2024 (UTC)

Full support here. One would think this would just be in the MediaWiki code by now... EggRoll97 ^(talk) 21:41, 25 July 2024 (UTC)

Organized toolbar

I've tried making the toolbar a bit more orderly: https://snipboard.io/12CV83.jpg. Infogiraffic (talk) 09:19, 24 July 2024 (UTC)

"Has wiki in the name vs. not" isn't that useful of an organizational principle to me. Sdkb ^talk 12:15, 24 July 2024 (UTC)

In this example, how do Blame and Wikiblame differ? Folly Mox (talk) 17:55, 25 July 2024 (UTC)

@Folly Mox. For some reason they exist as two different pages: https://xtools.wmcloud.org/blame/en.wikipedia.org?page and https://blame.toolforge.org/wikiblame.php. Infogiraffic (talk) 17:48, 26 July 2024 (UTC)

Should it be permitted to list shortcuts in the documentation pages for maintenance templates?

Many templates have shortcuts; e.g. {{citation needed}} can be invoked by typing {{cn}}. This produces the same result, and saves a great amount of time for editors by eliminating pointless busywork (especially those with arthritis, RSI, bad keyboards, mobile devices, or other impairments).

It improves the project for people to tag uncited statements, even if they do so without a perfect understanding of template syntax. The same is true of all inline maintenance templates (e.g. {{dubious}}, {{failed verification}}, et cetera). Indeed, while tagging articles is necessary and vital, many people who do it don't know how templates work at all, and just type <sup>[citation needed]</sup> -- I have an AWB task to fix this. This is fine. We want people to help out even if they are not programmers. This is why templates have documentation pages, which explain how the templates work and what to type into the edit box. Typing {{dub}} instead of {{dubious}} saves time for volunteer editors (which we already have a shortage of), and it is good and proper to tell them they can do this.

These shortcuts are made possible by "template redirects": a non-intuitive MediaWiki hack where "transcluding" a redirect is equivalent to "transcluding" its target page. Template:Cn is a redirect to Template:Citation needed, the same way United States of America is a redirect to United States. This behavior is an idiosyncratic quirk of the MediaWiki software, and there is no reason to think it would be obvious to someone unfamiliar with how the backend works.

The only way to get a list of these redirects is a very complicated, obscure set of actions that don't clearly indicate their outcome. Users must:

• Know about this unorthodox feature of MediaWiki in the first place (that a "redirect" is a shortcut when it's a template)
  • Pick one of nineteen options in a "Tools" dropdown, which is not in any way labeled to indicate it is a list of redirects, and has no clear relation to it (Special:WhatLinksHere)
    • There's no option to list redirects, so you have to create a list of redirects by exclusion, by clicking on two separate selection boxes for unrelated things, not indicated as being related to redirects ("Hide transclusions" and "Hide wikilinks")
      • Select these and reload the page a second time

Since this is an extremely time-consuming and inconvenient task involving counter-intuitive workarounds, most editors are not going to be aware that it's possible, and they are definitely not going to be doing it every time they look at a template's documentation.

Nevertheless, because it saves a significant amount of time to be able to use these shortcuts, many commonly-used templates explicitly list them in their documentation. For example, since at least 2013 (see Special:Permalink/562463167), the documentation for {{citation needed}} has featured a section listing redirects/shortcuts. However, after I spent a couple hours adding lists of shortcuts to other maintenance templates (like {{dubious}}, I was reverted, and a request made for formal consensus that template documentation pages are allowed to list shortcuts.

I propose that the documentation pages for inline maintenance templates be allowed to mention their shortcuts, either by listing them (e.g. with a collapsible {{list redirects}}) or by mentioning them in a hatnote.

These documentation pages are already quite long, often including sections that do not provide a whole lot of benefit to the average template user, as well as {{Inline cleanup tags}} which is about 3 kilobytes and includes around fifty links. The specific templates which prompted this discussion are {{According to whom}}, {{Ambiguous}}, {{Among whom}}, {{Attribution needed}}, {{Better source needed}}, {{Buzzword inline}}, {{By whom}}, {{Circular reference}}, {{Circular}}, {{Citation needed}}, {{Clarify}}, {{Context inline}}, {{Contradictory inline}}, {{Disputed inline}}, {{Dubious}}, {{Example needed span}}, {{Fact or opinion}}, {{From whom?}}, {{Importance inline}}, {{Incomprehensible inline}}, {{Inconsistent}}, {{Like whom?}}, {{List redirects}}, {{Needs independent confirmation}}, {{Nonspecific}}, {{Opinion}}, {{Peacock inline}}, {{POV statement}}, {{Promotion inline}}, {{Relevance inline}}, {{Speculation inline}}, {{To whom?}}, {{Tone inline}}, {{Unbalanced opinion}}, {{Unreliable source?}}, {{Update after}}, {{Update inline}}, {{Update}}, {{Vague}}, {{Weasel inline}}, {{Who}}, and {{With whom}}. Failing this, I would alternately propose that a link to the properly-formatted WLH for the current page be included in the inline cleanup tag template. I will here embed this template, so that you can get an idea of the templates I'm talking about (this navbox currently appears at the bottom of all the templates' documentation pages it mentions).

jp×g🗯️ 19:13, 26 July 2024 (UTC)

Support Shortcuts like that are huge time-savers for me. Becoming aware of others that aren't currently mentioned on their doc pages will be useful. Using citation-needed as an example, that tiny box listing its shortcuts demonstrates that providing that helpful information doesn't unnecessarily expand the doc page. Schazjmd (talk) 19:21, 26 July 2024 (UTC)

Afd to Prn/Pcn

Can we rename Articles for deletion to Articles for checking/Reviewing notability which will give a positive impression than the present one. 103.66.169.3 (talk) 19:36, 26 July 2024 (UTC)