Jump to content

Wikipedia:Village pump (proposals)

From Wikipedia, the free encyclopedia
(Redirected from Wikipedia:VPR)
"WP:PROPOSE" redirects here. For proposing article deletion, see Wikipedia:Proposed deletion and Wikipedia:Deletion requests.
 Policy Technical Proposals Idea lab WMF Miscellaneous 
Shortcuts

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

Discussions are automatically archived after remaining inactive for nine days.

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

[edit]

 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)[reply]

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)[reply]
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)[reply]
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)[reply]
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)[reply]
productive criticism? or Assuming Im not human?am I invited or nil?The Summum Bonum (talk) 12:19, 18 July 2024 (UTC)[reply]
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)[reply]
@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)[reply]

Request

[edit]

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)[reply]

@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)[reply]
Watchlisted. ——Serial Number 54129 13:17, 18 July 2024 (UTC)[reply]

The Khmer Wikipedia appears with the letters in Bold

[edit]

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)[reply]

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)[reply]
@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)[reply]
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)[reply]

Allow everyone to move pages in draftspace

[edit]

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)[reply]

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)[reply]
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)[reply]
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)[reply]
Please post the phab number here when you get one. RoySmith (talk) 16:47, 18 July 2024 (UTC)[reply]
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)[reply]
For now I just asked VPT to come here. Nickps (talk) 17:00, 18 July 2024 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
@RoySmith phab:T370471 has now been opened. Nickps (talk) 19:30, 18 July 2024 (UTC)[reply]
I would worry about draft hijacking. BD2412 T 02:18, 19 July 2024 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]

"0 days ago" in time duration calculation

[edit]

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)[reply]

Thanks for pointing this out. Nxavar (talk) 14:38, 19 July 2024 (UTC)[reply]
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)[reply]
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)[reply]
"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)[reply]

Legalize "subsection" parameter of template "imdb title"

[edit]

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)[reply]

{{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)[reply]

Does the community still want moved pages to be unreviewed

[edit]

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)[reply]

Taking my developer hat away, I personally don't think this should be implemented anymore. Sohom (talk) 07:54, 21 July 2024 (UTC)[reply]
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)[reply]
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)[reply]
@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)[reply]
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)[reply]
  • 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)[reply]
  • Strong oppose per nom and Josh. Reviewers already are swamped as it is. (t · c) buidhe 14:53, 21 July 2024 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • ??? 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)[reply]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(proposals)&oldid=1236083848"