Jump to content

Wikipedia:Village pump (proposals)/Archive 214

Add links
From Wikipedia, the free encyclopedia
Village pump (proposals) archive  

This page contains discussions that have been archived from Village pump (proposals). Please do not edit the contents of this page. If you wish to revive any of these discussions, either start a new thread or use the talk page associated with that topic.

< Older discussions · Archives: A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S, T, U, V, W, X, Y, Z, AA, AB, AC, AD, AE, AF, AG, AH, AI, AJ, AK, AL, AM, AN, AO, AP, AQ, AR · 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214

Mass renaming of articles in Category:Attacks on supermarkets in the United States

Hi all. I am proposing the mass renaming of articles in Category:Attacks on supermarkets in the United States to bring them in line with pages in other categories pertinent to attacks in indoor places in the United States, per WP:TITLECON. Pages in this category tend to be named after the year and city/town the attacks take place in, (e.g., 2022 Buffalo shooting, 2024 Fordyce shooting, 2019 El Paso shooting, 2021 Boulder shooting) which does not align with how it tends to be in other categories.

When looking at other categories for attacks on indoor places in the United States, the vast majority either include the name of the business or the type of venue in their name. For example, see the following where the majority of titles include the names of the businesses or type of venue: Category:Attacks on shopping malls in the United States (16 out of 21), Category:Attacks on office buildings in the United States (9 out of 12), Category:Attacks on nightclubs in the United States (14 out of 15), Category:Attacks on hotels in the United States (7 out of 7), Category:Attacks on hospitals in the United States (6 out of 12), Category:Attacks on restaurants in the United States (17 out of 26), Category:Attacks on churches in the United States (13 out of 17) and Category:High school shootings in the United States (50 out of 51). On average, 79.3% of articles include the place name or type in titles, based on those listed above.

Category:Attacks on supermarkets in the United States is an outlier, where only two pages out of ten have the name of the business or type of place in their title, even when reliable sources may commonly refer to the attacks as such, seemingly due to WP:TITLECON within the category. Including the type of place as well as year and location in some article titles will also better suit WP:NCWWW.

Proposed Renames (Based on naming conventions from reliable sources)

Macxcxz (talk) 14:16, 17 September 2024 (UTC)

This should really be done through WP:RM, which then tags the pages and adds them to relevant reports that editors watch. Gonnym (talk) 14:23, 17 September 2024 (UTC)
I know that is typical protocol, but I wanted to discuss it in a singular place first. Multiple discussions over multiple RMs would be confusing. Macxcxz (talk) 14:38, 17 September 2024 (UTC)
Generally speaking, this should only be done with a consensus on the talk page of the article concerned. Mass renaming without a requested move discussion is likely to be reverted.--♦IanMacM♦ (talk to me) 14:39, 17 September 2024 (UTC)
I know, I just want to discuss it. Macxcxz (talk) 14:41, 17 September 2024 (UTC)
RM has a procedure in place for multiple pages as well. You should go read up on it. Gonnym (talk) 15:13, 17 September 2024 (UTC)
Oh I see, I didn't know that was possible. Still, I'd prefer to discuss it here without any actual actions taken first. Macxcxz (talk) 16:33, 17 September 2024 (UTC)
WP:TITLECON is an essay, it's about WP:CONSISTENT, which is just one of the five WP:CRITERIA for titles, and it's the last one, because it's the least important one. I get nervous whenever anyone endeavors to "make all titles consistent."
There are basically two categories of titles based on my understanding of how WP:AT policy is applied: those with a WP:COMMONNAME and those without. For those with a common name, we use that name, regardless of whether it's consistent with anything else. So, Columbine High School massacre is not called "1999 Columbine shooting," and "Pulse nightclub shooting" is not "2016 Pulse shooting" or "2016 Orlando shooting". So for each one you want to change, you'd have to check whether the current title is the common name or not.
For those that don't have a common name, there are four other equally or more important criteria: WP:PRECISE, WP:CONCISE, WP:NATURAL, and WP:RECOGNIZABLE. So, for example, "2019 Jersey City shooting" is certainly as precise, and more concise, and in my view, more natural and recognizable, than "2019 Jersey City kosher supermarket shooting". In my view, if it doesn't have a common name, it should be as short (WP:CONCISE) as possible, using only those descriptors that are needed to be precise. So: "[date] [place] shooting" is fine unless there were two shootings in that year or place. In fact, "[place] shooting" would be better in my view, unless there were multiple shootings at [place].
I don't see any value in adding the word "supermarket" to a title unless it's needed to disambiguate [place].
I don't think we should ever add the brand name of the private business ("Walmart", "Buffalo Topps") where a shooting occurred, unless it's part of the common name (as with the Pulse shooting). It's not nice or necessary to associate the business with a shooting that happened at one of its locations.
My 2c. Levivich (talk) 15:07, 17 September 2024 (UTC)
To clarify, my proposed renames are also based on WP:COMMONNAME, sorry if I didn't make that clear. In regard to 2019 Jersey City shooting, I do note that the page's current name does reflect common name so a rename may not be necessary. The same goes for the 2011 Tucson shooting, hence why I did not propose a rename for that page.
The main reason I even proposed this was because I attempted to rename the 2019 El Paso shooting to 2019 El Paso Walmart shooting based on WP:COMMONNAME, but two people responded (the only people to respond) objecting on the basis of WP:CONSISTENT. I wasn't aware WP:CONSISTENT was considered less important than any of the other criteria, and actually I can't find anywhere that says such a thing, perhaps you know where.
In regard to adding brand names/private businesses, this is already a well-established concept both on Wikipedia and in reliable sources. The vast majority of school shooting articles will include the name of the school, which I'd argue is far more damaging than just naming "Walmart". Certainly regarding the El Paso shooting, "Walmart" is part of the common name based on RS, but as I said before it was apparently a consistency issue to propose that rename.
So, I'm pretty confused. Does common name take priority? I've heard different things from different people now. Macxcxz (talk) 16:21, 17 September 2024 (UTC)
Yeah... welcome to Wikipedia, where if you ask three people, you'll get six answers. There are very few clear black-and-white rules regarding article titles (or anything else on Wikipedia). Does common name take priority? Yes, usually. As WP:COMMONNAME explains, Wikipedia generally prefers the name that is most commonly used ... as such names will usually best fit the five criteria listed above. So common name will usually take priority because it usually fits the 5 article title criteria the best. That doesn't mean always follow the common name, but it does mean the common name is a very strong factor in this multi-factorial analysis.
As for consistency being low priority, that's more my opinion, or my analysis of how these things usually go, than a "rule" or policy. WP:CONSISTENT itself is written with some rather weak language and caveats, e.g. To the extent that it is practical. And should be consistent does not mean "must be the same." Even "consistent" doesn't mean "the same." WP:CONSISTENT continues, there has been a history of consensus among editors regarding several areas where consistency does not control titling, and the first example given is Disambiguation, which is what you're talking about. The example given in WP:CONSISTENT says just because Georgia (country) has the (country) disambiguator doesn't mean every country article must have one, even though that would be consistent. I think there is a direct analogy here to "Walmart": just because some articles identify the name of the business doesn't mean all articles should identify the name of the business.
But ultimately, titles are decided very much on a case-by-case basis (in large part because a common name analysis is a case by case analysis), so who knows what the consensus will be at that particular RM about the best title for that particular article. Right now I see it's split 2-2. I'd argue with the votes that say that that article shouldn't have "Walmart" in the title because other articles don't, as that argument seems like it directly contradicts the "disambiguator" part of WP:CONSISTENT. Ultimately, it depends on what the consensus will be as to whether, for that particular article, in the inclusion of "Walmart" would better match title criteria, e.g. because it's part of the common name. So there's no clear "right answer," it's a matter of how the people participating in the discussion will weigh the various competing factors involved. Levivich (talk) 16:46, 17 September 2024 (UTC)
welcome to Wikipedia, where if you ask three people, you'll get six answers – I disagree, Levivich! You usually get four answers from three people, unless one of them is socking, in which case you'll get five. WhatamIdoing (talk) 19:07, 17 September 2024 (UTC)
Overall, I like the idea of a slightly more informative title. After a while, they all blur together ('No Way to Prevent This,' Says Only Nation Where This Regularly Happens), and having some little hint would sometimes be helpful. The use case I'm specifically thinking of is when you're searching for an article. However, I don't feel strongly about this, and I oppose making them all match just for the sake of matching. WhatamIdoing (talk) 19:13, 17 September 2024 (UTC)
A lot of these are just random crime news that don't need their own articles to begin with. Except for the ones that saw major coverage after being resolved, I'd say merge them all into a list. Thebiguglyalien (talk) 20:01, 18 September 2024 (UTC)

Font options

Wouldnt it be great to look at articles in like comic sans WikipedianAncientHistorian (talk) 23:26, 16 September 2024 (UTC)

WP:CSS explains how to install your own custom CSS. Switching to a different font should be relatively straight-forward. RoySmith (talk) 23:38, 16 September 2024 (UTC)
Thanks for the tip honestly wasn't aware it existed WikipedianAncientHistorian (talk) 19:30, 17 September 2024 (UTC)
Wikipedia doesn't specify the font being used for article text; it uses whatever you have configured in your browser for sans-serif text. So feel free to configure your favourite font for use in your browser. isaacl (talk) 00:24, 17 September 2024 (UTC)
oh makes sense thanks WikipedianAncientHistorian (talk) 19:30, 17 September 2024 (UTC)
What if I don't want a sans serif font? Can I set things up to use a serif font in article text? --User:Khajidha (talk) (contributions) 12:54, 19 September 2024 (UTC)
If you change your browser configuration, you can set up any font you want to be used when a web page uses the generic sans-serif CSS property. If you want to do something specific to English Wikipedia, see the web page to which RoySmith referred. isaacl (talk) 18:29, 19 September 2024 (UTC)

Page views link in the Tools menu

The Tools menu.
Same menu, but with an extra "Page views" link.

Last month, {{Annual readership}} was nominated for deletion. The Graph extension which the template used was turned off on 18 April 2023 due to a security issue. After that, the Annual readership template was changed into just a text with a link to pageviews.wmcloud.org.

Annual readership is currently used on 53,510 talk pages. The consensus on the TfD appears to be that the template should be kept, but noincluded and made invisible, pending a solution for the Graph extension.

In the same TfD, I proposed a "Page views" link in the tools menu as an alternative of sorts. See the included screenshots. Right now, the link to the page views tool is carefully hidden in: Tools -> Page information -> scroll all the way down -> External tools -> Page view statistics. Could we perhaps make the page view link appear more prominently?

I know there are scripts like User:PrimeHunter/Pageviews.js, but it would be nice if the button appears by default, regardless of whether a user is logged in or not. Cheers, Manifestation (talk) 18:34, 7 September 2024 (UTC)

For more info see:
Wikipedia:Templates for discussion/Log/2024 August 25#Extra link in the tools menu?
Few editors, and fewer average readers, are aware that the page views link is on the "page information" page:
Tools menu > Page information > Page views.
--Timeshifter (talk) 19:41, 7 September 2024 (UTC)
For me, the length of the Tools menu makes it harder to find specific items that I'm looking for. Thus I prefer that the page view link remain grouped under the page information menu item. isaacl (talk) 21:18, 7 September 2024 (UTC)
I think the "Print/export" section of the the tools menu could be consolidated and be put on a page called "Print/export". So that would consolidate 3 lines in the tools menu to one link. That would leave room for a page views link on the tools menu. --Timeshifter (talk) 11:04, 8 September 2024 (UTC)
A link to page views is also available in the "External tools" bar near the top of the history page. Thryduulf (talk) 21:21, 7 September 2024 (UTC)
That's a pretty obscure location for the average Wikipedia reader. --Timeshifter (talk) 09:58, 9 September 2024 (UTC)
I don't feel that Page views is that much more important than the other external tools linked in page information and page history. Personally, I use Revision history statistics more. Obviously adding them all would be too much clutter though, so I wouldn't propose that as an alternative. ― novov (t c) 03:12, 8 September 2024 (UTC)
So you feel that "page views" is a little more important? So then it should replace something less important.
Concerning revision history, I assume you are talking about the "View history" link at the top of nearly all pages? I agree that is very important. But we are not asking for the page views link to be put at the top of pages. --Timeshifter (talk) 10:54, 8 September 2024 (UTC)
I'm talking about the Revision history statistics tool, which is also in the page information. What I'm saying is that there's no reason why page views should be added to the tools menu when it's not been proven that it's "special" compared to the other things, and page information is in there anyway. ― novov (t c) 01:51, 9 September 2024 (UTC)

The average Wikipedia reader is more interested in page views than those arcane statistics. --Timeshifter (talk) 09:58, 9 September 2024 (UTC)

I now support the tools menu over other locations to add a pageviews link. But it would require moving many of the links to submenus as with the page menu discussed below. That means scrolling would no longer be necessary to see all the links in the tools menu.
Also, The tools menu is currently on nearly all pages whether one is logged in or not. That is a big advantage over Xtools and the page menu which require enabling gadgets in preferences. And enabling Xtools by default for logged-in users might unduly increase server load. --Timeshifter (talk) 03:06, 15 September 2024 (UTC)

Put page views link in talk header template too

I say do both. But if not in the tools menu, let's start here in the talk header template. We could remove {{annual readership}} from all talk pages, and use this location instead. This way the number of links to page views on talk pages goes from around 53,000 to 726,000 talk pages.

{{talk header}} is on around 726,000 article talk pages out of 6,911,991 articles. {{NUMBEROF|ARTICLES|en|N}}. That is around 11% of articles.

Note that there is room on the left side for a page views link. --Timeshifter (talk) 11:42, 8 September 2024 (UTC)

This talk page header already has a lot of clutter. I am against adding anything else to it; if anything, it should be simplified. ― novov (t c) 01:54, 9 September 2024 (UTC)
{{talk header}} has been developed over a long time. There is agreement on what is there now. So I think you are in the minority on that. Adding a page views link there justifies hiding or deleting {{annual readership}}. So that means less stuff on the talk page. --Timeshifter (talk) 09:51, 9 September 2024 (UTC)
It doesn't help anyone else, but if you personally want a more concise talk page header I recommend adding to your user style:
#talkheader tr:has(> td > .talkheader-body) { display:none; }
this cuts most of it out but leaves the search box. –jacobolus (t) 15:42, 9 September 2024 (UTC)
It is true that the content in the white box isn't at all relevant for experienced editors. I'd be interested to consider a proposal not to display it for those editors. Sdkb talk 03:37, 12 September 2024 (UTC)
Sdkb, proposal not needed, just a doc update. That box (like most else) is already classed, this as .talkheader-help and all you have to do is add .talkheader-help {display:none} to your common.css, and that should do it. (If it doesn't, please ping me from Template talk:Talk header.) Mathglot (talk) 00:42, 13 September 2024 (UTC)
I'm interested in improving the interface for everyone, not just myself. A personal CSS hack doesn't do that. Sdkb talk 07:47, 13 September 2024 (UTC)
Oh, I see; should be pretty straightforward with a new param. If only we had a magic word for the id of the user reading the page, instead of the last one who saved it, we could do it without a param, but alas. Mathglot (talk) 07:54, 13 September 2024 (UTC)
I have recently come to the conclusion that promoting page views information to editors is a bad idea. Here's why: the page views for most articles are very low.
I pulled the page views counts for all of 2023 for a random set of 10,000 articles. 90% of articles get less than 10 page views per day. 70% get less than 1 page view per day. Almost 40% of them get less than 1 page view per month.
Please imagine for a moment that you have created an article, or you decided to improve it. Then you look on the talk page and discover that the number of page views is far lower than you expected. A metric that never really mattered to you before has been put in your face, and now you feel discouraged. Metrics that might align better with your own values (e.g., how grateful a reader was to find information on such an obscure topic) are not available and will not be surfaced to you. We're just going to tell you that 40% of your articles are probably pointless. Or 70%, if you thought one reader a day was enough. Or 90%, if you'd hoped your efforts would help "only" 10 readers a day. My point is, for most articles, this is not a feel-good metric. This is a feel-bad metric, and we should be cautious about promoting it indiscriminately.
BTW, if you'd like to figure out how your favorite page compares, then here are a few key numbers:
  • 100K page views per year: top 1%
  • 10K page views per year: top 5%
  • 1K page views per year: top 20%
  • 100 page views per year: top 40%
WhatamIdoing (talk) 06:23, 12 September 2024 (UTC)
Though I agree that page views can be surprisingly low sometimes, I think your methodology is possibly flawed; editors don't just edit random articles. I would imagine that articles that are edited more tend to get more views, as there is most likely some overlap between reader interest and editor interest. ― novov (t c) 06:54, 12 September 2024 (UTC)
I agree that editor interest is non-random, but that means it will be worse than average for some editors. If your niche happens to be an unpopular one, then you could find yourself looking at evidence of its unpopularity very frequently.
The opposite is also true: if you happen to be impressed with the page views an article is getting, then you might feel the stakes are much higher. There can be no compromise when so many people are going to read this, right? Everything's got to be perfect. Don't be bold; be very, very, very careful. The next thing you know, editors are thinking about the fact that almost a million people read Cancer a year. Someone could die! (I'm going to die. We're all going to die.) We need editors thinking about the work that needs to be done, rather than being focused on the popularity of the page. WhatamIdoing (talk) 07:12, 12 September 2024 (UTC)
I actually do pay attention to page views for articles I work on, but I am comfortable going to the page history to access them. Very low page views for a given article can be disappointing, but every once-in-a-while something in the news will cause a hundred- or thousand-fold spike in page views for such an article, and I then take satisfaction in knowing that we had some background on the topic available to the reading public. Donald Albury 12:18, 12 September 2024 (UTC)
I find this condescending to editors and readers: "We need editors thinking about the work that needs to be done, rather than being focused on the popularity of the page." You, or some committee, shouldn't be determining what is important to editors and readers. I assume now that this is why page views has been made so inaccessible to regular readers and editors. I make decisions on what and how I edit based on numerous factors, including page views. Maybe you have unlimited time to edit. I don't, and so I want to edit what I think makes a difference, and what matters to me. If I have a choice between a popular and unpopular page, and both matter to me, then I will probably edit the popular page more. --Timeshifter (talk) 00:45, 13 September 2024 (UTC)
I doubt that's why Page views isn't that visible; most likely it just wasn't considered that important.
And by definition, any user interface design makes a determination of what's important or not important. People use Talk more than, say, What links here, so it makes sense that the former is more prominent. In such a wide-ranging and community-focused project like Wikipedia there's always going to be a variety of opinions on what exactly that order is.
The closest thing to letting people decide for themselves would be if we just make every action associated with a page buttons of the exactly the same size that are always visible, which would be unbearably cluttered and intimidating to newcomers. ― novov (t c) 02:36, 13 September 2024 (UTC)

novov: Now your veering into ridiculousness. As I previously said average readers and editors are more interested in page views than other statistics. And elsewhere you said you want page views in a separate template, and not as 2 words (Daily pageviews) added to {{talk header}}. Many people do not want a separate template. So that leaves few choices if you really want pages views to be more accessible to average readers and editors. --Timeshifter (talk) 21:57, 13 September 2024 (UTC)

Strong oppose. I am a strong supporter of accessibility of page views information on Talk pages, but this is not he way to go. I won't repeat the reasoning I already gave at Template talk:Talk header, I will just say that I am coming up with a stopgap, template-based replacement for {{annual readership}} until a more permanent solution can be found, and will expose it here shortly for discussion. (I've added DNAU so this doesn't get archived in the meantime.) Please stay tuned. Mathglot (talk) 23:04, 12 September 2024 (UTC)
You haven't stated whether you oppose or support a page views link in the tools menu. Please say so in the previous talk section above. --Timeshifter (talk) 22:09, 13 September 2024 (UTC)
@Timeshifter, where is the evidence for your assertion that average readers and editors are more interested in page views than other statistics? I don't think we have any the evidence that "average readers" are interested in any statistics at all, and what we can reasonably predict about editors is that some will appreciate it and others won't.
It is very easy to assume "I want this; therefore almost everyone wants this". I'm telling you: I don't want this, and because of the page-view distribution curve, I think it is very bad for Wikipedia's future to promote page views. You are proposing that 90% of talk pages carry "proof" that those articles are unimportant. That will not make editors feel happy. It will not make them feel like contributing more. In some cases, it will scare them away from editing. Cancer has a self-contradiction in it. It's hard enough to get someone to edit that article. I don't need "help" in the form of you scaring away editors because you've made sure that they know how many people will see that edit. I very much need "editors thinking about the work that needs to be done, rather than being focused on the popularity of the page", even if you think it's condescending ("an attitude of patronizing superiority or contempt") of me to want editors to WP:Be bold and fix the problems in that article and not to be scared off by your reminder that the page gets read 1.5 times per minute. Editing articles is an anxious business for some people.
Putting the page views on all the pages will make editors feel like someone else (i.e., you) has told them that they should care about this factor. In fact, you think they should care about page views so much that you are trying to force them to see the numbers (or, for now, a link to the numbers) whenever they venture onto a talk page.
You should get to pick the articles that you want to work on. I suggest to you that a page like Wikipedia:WikiProject Politics/Popular pages would be a more efficient way of finding popular articles than clicking on each talk page, but if you like clicking on each page individually, then feel free to click away. What I'm saying is: Don't force your preference on everyone else. WhatamIdoing (talk) 04:19, 14 September 2024 (UTC)
We appear to have a WP:TALKFORK at Template talk:Talk header#Put page views link in talk header template. WhatamIdoing (talk) 04:30, 14 September 2024 (UTC)
The XTools PageInfo gadget, as seen when viewing the Jimmy Wales article.

See: Special:Preferences#mw-prefsection-gadgets. Appearance section:

  • "XTools: dynamically show statistics about a page's history under the page heading."

It lists the number of editors, watchers, and pageviews. It names the page creator, and has a link to "full page statistics" that goes here (it is filled in automatically):

For example:

The statistics bar is below both article and talk pages. There are separate stats for the talk page.

Only logged in users see the statistics bar. Turning it on by default would allow all logged in users to see it. If they don't like it they can always turn it off. But if they never turn it on, they will not know that it has a page views link. That is why it should be turned on by default.

I think this should be done, and after people see that the sky will not fall by giving editors this info, then it should be turned on by default for both logged-in users, and all readers. --Timeshifter (talk) 07:32, 14 September 2024 (UTC)

  • I don't think this is a good idea, forcing all editors (and even all readers) to make client-side calls to a volunteer project on every page load is asking a lot, also this gadget causes a screen jump as it waits to load then inserts itself in to the header. — xaosflux Talk 07:44, 14 September 2024 (UTC)
The screen jump doesn't bother me. Pages have screen jumps for other reasons too. People can turn it off if they don't like it. And it is not much of a screen jump. A line or 2.
We can start with logged-in users first and see how that goes. If it is too much of a load on the servers, then set it to only update the numbers once a day.
https://xtools.wmcloud.org is part of Wikimedia, and so I think its servers can handle it if tweaked as needed. --Timeshifter (talk) 08:01, 14 September 2024 (UTC)
Sure it doesn't bother you - and that's why you and others can opt-in to it. A jumpy interface isn't very nice for causal readers. — xaosflux Talk 14:30, 15 September 2024 (UTC)
I don't think these statistics are relevant to the average reader. Or average editor really, I can count the amount of times that I've looked up any of these statistics for the last twenty pages I've edited on zero hands. The same is most likely true for the last two hundred.
To be quite frank, even before it became hidden {{Annual readership}} wasn't on most talk pages. For those pages, the situation was identical to how it was now, so I don't get why this is such a huge issue. ― novov (t c) 09:29, 14 September 2024 (UTC)
It's important to the many people who liked {{annual readership}} while it had the graph of pageviews. Apparently, that does not matter to you. --Timeshifter (talk) 09:36, 14 September 2024 (UTC)
Screenshot of the Analysis menu of the Page dropdown.

See: Special:Preferences#mw-prefsection-gadgets. Appearance section:

  • "MoreMenu: add Page and User dropdown menus to the toolbar with links to common tasks, analytic tools and logs".

Unless the tools menu gets some submenus, then I like this solution best of all so far. It avoids any possible server problems (see previous talk section) since it does not show the statistics. And the page menu is short. So there is room for a pageviews link.

The pageviews link needs to be added to the page menu, or the "analysis" submenu.

This way logged-in editors have access to pageviews without having to open another page first (if they even know about it), and then scroll around, and then click the pageviews link.

Since it would be in a menu or submenu, editors are likely to see it as they look at all the menus on pages over time. They don't have to leave the page to click the pageviews link. ----Timeshifter (talk) 22:16, 14 September 2024 (UTC)

No opinion yet on whether or not this proposal should be implemented, but could you please explain why The pageviews link needs to be added to the page menu, emphasis in original? Folly Mox (talk) 23:15, 14 September 2024 (UTC)
I don't know if you have read the previous talk sections. But the goal is to make the pageviews link more accessible. {{annual readership}} has been hidden from view on all pages it is on. So that accessible pageviews link is gone.
Adding the link to the page menu is one solution. --Timeshifter (talk) 01:08, 15 September 2024 (UTC)
The previous talk sections clearly show that this goal is not one that everybody supports, indeed some people have actively opposed adding links to the page menu. There is currently no consensus that we should increase the accessibility of the page views tool at all, nor for a specific way to do that. Thryduulf (talk) 01:13, 15 September 2024 (UTC)
Time, Can you clarify what it is you actually want? A great deal of words have been expended here about adding a *pageviews link*, as in your message just above and many other parts of this multi-section discussion, but is a link what you really want? Or would you rather just have the page views chart itself on the Talk page? I suspect your underlying goal is the same as mine, as I get the impression that you'd rather have the chart but have given up on that idea because it hadn't worked in over a year and was finally hidden recently.
But as I mentioned above (diff), there may well be a way to have a pageviews chart on the Talk page. If you'd rather have the link, then carry on, I guess, but it looks like you are running into a lot of opposition to that approach. My impression is that by continuing to grind away at it, you are doing yourself a disservice and possibly pushing your goal of having easy access to a chart even further away. The more you insist on a link, the more you may also gin up opposition to having the chart, and I haven't raised that idea more formally yet because this discussion has sucked up all the oxygen in the room about this topic and may have also poisoned the well a bit. Please don't make things worse than they already are. I think you are more likely to get what you want, if you let it be for a while, or at least, wait and see if there's a groundswell of support here for your links ideas, which so far has not materialized. Mathglot (talk) 01:50, 15 September 2024 (UTC)
Mathglot. I now prefer a pageviews link in a submenu of the Tools menu that is currently found on all pages whether logged in or not. I like how submenus condense the page menu. The tools menu has no submenus and one has to scroll down the page to see all the contents. So it solves 2 problems to add submenus to the tools menu. {{annual readership}} is only on less than 1% of all article talk pages (53,000 / 7,000,000 articles). I support your efforts to make it work again. But I want more. I hope to contact whoever is involved with the Tools menu directly. That may be more productive. The feedback from this discussion has been useful in seeing what will work. For example, I don't want to add any more server load. Adding a link to a submenu of the tools menu adds no server load. --Timeshifter (talk) 02:17, 15 September 2024 (UTC)
I hadn't read the previous sections as it happens: the edit summary on my watchlist made it appear as if this were a new topic. I'm afraid I'm inclined to agree this doesn't have consensus, and just wondering why this is a need as distinguished to a "nice-to-have, for some people". Personally I think I'd find readily accessible pageviews more demoralising than anything, but if I'm curious Special:PageInfo is right there. (And, for many, and a slightly different application, Special:Impact.)
As an aside, this Xtools menu gadget has no effect on mobile. Folly Mox (talk) 01:51, 15 September 2024 (UTC)
Folly Mox. Special:PageInfo and Special:Impact are not direct links to pageviews for a page. I meant "need" in the sense that for this to work, the pageviews link "needs" to be on the page view menu or submenus. Currently, it is not there. Thanks for the info about the Xtools menu gadget not being on mobile. Another reason not to use Xtools as the means to make a pageviews link more accessible. See my reply to Mathglot a few paragraphs up for more info. --Timeshifter (talk) 02:28, 15 September 2024 (UTC)

Stop

User:Timeshifter, you seem to be suffering from a severe case of IDHT, so to get through to you I need to be a bit more blunt than I like to be. The goal of making pageview links more easily accessible has been rejected by most people commenting above. To you these links are very important, but to most people they are not. Stop trying to find ways of forcing these links on people who don't want them and just find a way to have them yourself. Phil Bridger (talk) 08:26, 15 September 2024 (UTC)

With all due respect to Timeshifter's volunteer passion about this, as well as his good-faith effort to sum up opinions in the next subsection, I have to agree with Phil Bridger here. I think we are well into WP:SATISFY territory, and it's probably time to let it go and choose your battles. At best, try again in a year or so, after the situation with the non-working charts bug (T334940) has been (hopefully) resolved. As for me, I've contributed here all I can, and I am withdrawing from this discussion now, as further comments would either be counter-productive, or prolong it unnecessarily. Best of luck, Mathglot (talk) 21:12, 15 September 2024 (UTC)

Phil Bridger wrote: "The goal of making pageview links more easily accessible has been rejected by most people commenting above." As a point of fact that is incorrect. Most people haven't expressed an opinion. 3 people support the link in the tools menu. 3 are opposed. But I agree that discussion here seems to have petered out. Mathglot, you asked me: "Can you clarify what it is you actually want?" I answered that. I asked you: "whether you oppose or support a page views link in the tools menu." --Timeshifter (talk) 22:27, 15 September 2024 (UTC)

Yes, you did; noted. Mathglot (talk) 22:57, 15 September 2024 (UTC)
It's not about me. That's projection on the part of you two. But hey, I've said what I've got to say. I made some suggestions. I answered questions. I answered your question. I wasn't sure you had seen my question. Of course, you don't have to answer mine. I didn't badger others to answer my questions. I made other suggestions. That's not badgering. What happens next is up to others. I don't edit the tools menu. --Timeshifter (talk) 01:43, 16 September 2024 (UTC)

Many people support {{annual readership}} graph working again including me.

I learned a lot from this discussion which I wouldn't have learned without the discussion. I now only support making the pageviews link more accessible through the tools menu (if submenus added to shorten the menu). The other options were not as good (see reasons in the discussions).

For tools menu:

  • Manifestation
  • Timeshifter
  • jacobolus (in another thread).

Supports talk page editors deciding whether to add a pageviews link in comment, banner, or box. Generally opposed to making it more accessible than that:

  • WhatamIdoing (in another thread).

Unknown as to tools menu with submenus:

  • isaacl
  • Thryduulf
  • Sdkb
  • Mathglot - opposes it in {{talk header}}.
  • xaosflux - opposed to making XTools default.
  • Folly Mox
  • Phil Bridger

Against any better access:

  • novov - (against {{annual readership}} too).
  • Donald Albury - comfortable going to page history for it.

I hope I got everybody's views correctly summarized. --

Note: If you want a pageviews link in your own tools menu see User:PrimeHunter/Pageviews.js. For a pageviews link below all article and talk page titles turn on XTools at the bottom of the appearance section of these gadget preferences. --Timeshifter (talk) 21:57, 16 September 2024 (UTC)

New Page: Snakes Of Egypt

Resolved

I have to find the snake endemic to Egypt for a project, but there doesn't seem to be one? Can someone kindly add it? Btw not a problem anymore no one needs to reply to this. Irindu10 (talk) 16:19, 21 September 2024 (UTC)

New pages aren't generally proposed, they're just created (i.e. someone could start editing Snakes of Egypt at any time). This isn't likely to happen on a timescale that would be useful to your assignment, and would probably defeat the purpose of the assignment. I'd recommend you try searching for "snakes" "Egypt" on Google Books and seeing what comes up there. If you find anything substantial, maybe you could start the article yourself. signed, Rosguill talk 16:27, 21 September 2024 (UTC)
@Irindu10 If you want, you can take a look at other pre-existing pages listed at Lists of snakes to see how they are structured, as well as the template {{Species table}} for a fancier look. Chaotic Enby (talk · contribs) 16:56, 21 September 2024 (UTC)
Thanks! Irindu10 (talk) 13:58, 22 September 2024 (UTC)
@Irindu10, you can also ask questions about real-world facts (not really about how to edit Wikipedia) at the Wikipedia:Reference desk.
To get you started, you might look into Indotyphlops braminus ("Common Blind Snake", which is a very small snake [a third the length of the common earthworm] that gets its common name from tiny eyes that can realistically see only light/dark) and Walterinnesia aegyptia ("Egyptian Black Cobra"). If your project is literary in nature, then Cerastes vipera is often given as Cleopatra's asp. WhatamIdoing (talk) 17:07, 21 September 2024 (UTC)
There has never been a Category:Snakes of Egypt under Category:Snakes by country, and Category:Reptiles of Egypt was upmerged in 2020 into Category:Reptiles of North Africa, although a list article still exists at List of reptiles of Egypt, consisting entirely of unannotated links, including section headings. Folly Mox (talk) 17:40, 21 September 2024 (UTC)

Ethiopic fonts

Could we add "Abyssinica SIL" to the list of display fonts for Ethiopic script? The supplemental blocks display as tofu for me despite me having a supporting font installed. The only one I can see is Extended-B, which is the one not supported by Noto. (And I do have Noto installed.)

For comparison, wikt:Appendix:Unicode/Ethiopic Extended etc. display in Abyssinica SIL on my browser.

(Abyssinica is free and covers all 5 Ethiopic blocks.) — kwami (talk) 21:57, 19 September 2024 (UTC)

You forgot to link to the page where you experienced a problem. —TheDJ (talk • contribs) 03:09, 20 September 2024 (UTC)
Sorry, the tables in Geʽez_script#Unicode and the pages they link to, e.g. Ethiopic Extended.
The table for Ethiopic Extended-B displays correctly. Ethiopic (Unicode block) is mostly good, but has a bit of tofu scattered in it, e.g. for ሇ. Note that the tofu in the basic block is covered by Noto, as are the extended blocks up to Extended-A, so it almost seems as if Noto is the problem: Both the characters that are not handled by Noto (Extended-B), and those that are handled by more limited system fonts (most of the basic Ethiopic block), display correctly. The ones where Noto might kick in (I'm guessing) display as tofu. But they display fine if I set them to Noto in a text doc. — kwami (talk) 03:28, 20 September 2024 (UTC)
Interestingly, most of these are working for me even though I don't recall installing special Ethiopic fonts. The exception is Ethiopic Extended-B, which for me is a sea of tofu with no characters displaying. Double sharp (talk) 08:42, 20 September 2024 (UTC)
Same goes for me Ca talk to me! 04:33, 24 September 2024 (UTC)

Rethink the extended confirmed right?

Withdrawn as a site-wide proposal per requester below. — xaosflux Talk 22:47, 4 October 2024 (UTC)

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

I originally posted this on WP:VPT but got sent here by Izno. My original message was: Either have a user right that is given only to trusted people without any additional rights attached to it (and with a matching level of protection) or make extended confirmed be given manually. There are too many people gaming the system to be hateful pricks on editors' user pages or to push a POV on CTOPs. LilianaUwU (talk / contributions) 22:34, 30 September 2024 (UTC)

This is barely a proposal at this point. But it is a bad idea, so rather than suggest a further run-around I will explain why here.
I don't believe there is a problem that people are making 500 non-trivial and non-vandal edits just to be "hateful pricks" on talk pages. But, if they are, that seems like a largely-acceptable tradeoff; they can be easily blocked and everybody can move on.
As far as the existence of people pushing a POV on contentious topics; that will never ever stop no matter what the requirement is (at least as long as this is "The Encyclopedia Anyone Can Edit"). Whatever idea you have for "trusted" will also be gamed. It will not help. 500 edits is already a lot (outside of bots and gaming-the-system). And the various "ANI/ArbCom are understaffed" discussions demonstrate that a surplus of volunteers is not a luxury we can assume when designing policies. Walsh90210 (talk) 23:29, 30 September 2024 (UTC)
On top of the issue of it adding a new massive backlog, I'll quote Goodhart's law: "When a measure becomes a target, it ceases to be a good measure". Even if it is only given to trusted users, the users who will care the most about asking for the user right might not be the users that we would want the most, and edits on non-contentious topics won't give a perfect idea of the behavior they might have in more contentious environments. Chaotic Enby (talk · contribs) 08:03, 1 October 2024 (UTC)
This is still not the right forum (and Izno did not explicitly send you here). Please note the header that clearly states This page is for concrete, actionable proposals. Consider developing earlier-stage proposals at Village pump (idea lab). Sdkb talk 07:31, 1 October 2024 (UTC)
But since the discussion has already been moved once, we might as well stick with it here. The downside to choosing VPPR over VPIL, of course, is that we can all weight in with "* Oppose" votes instead of at least pretending to explore the idea.
On the subject matter, I sometimes think we should reduce the 500+30 down to 300+30. There's little statistical difference between 300 and 500 edits; people who make 300 will usually manage the second (whereas people who manage one or two edits usually don't manage 10).
I have seen a small number of editors claim that unnamed[*] others are gaming the system. I have personally seen no convincing evidence of this. Additionally, having fewer folks involved in an ever-greater number of articles violates the principle that "many hands make light work". Something we don't need is a greater percentage of skilled wikilawyers, which is what a manual system will give us.
Something we do need is people with enough self-awareness to realize that, even if we stipulate that my own views are always correct, etc., if I'm running into constant POV pushing around a subject, that could be a sign that the articles are not complying with WP:YESPOV. YESPOV means that the articles need to acknowledge the existence of significant differences in opinions, including in CTOP articles. To name a few of these POVs, consider "some people think abortion shouldn't be described as 'safe' because the baby dies" or "some people think that Israel is perpetrating genocide" or "some people think Donald Trump was the greatest president ever" or "some people think that private citizens shouldn't be allowed to own guns" or "some people fear demographic changes in their society" or "some people think it was unfair to restrict liberty during COVID-19 pandemic just to prevent the virus from spreading". You don't have to agree with any of these to realize that these comments and edits are feedback on how well an article meets people's actual needs. Donald Trump should acknowledge why his supporters think he's great, even though I don't agree with them. Face masks during the COVID-19 pandemic should acknowledge that some people (e.g., lip readers) were harmed by mask use. Writing a decent article that respectfully describes and (when appropriate and WP:DUE) explains the flaws or limitations in these viewpoints really can help, occasionally dramatically. Forcing one POV out of the article, or treating it in a derogatory fashion, is going to produce a steady stream of complaints and attempts to "fix" the perceived problem.
[*] This is not a suggestion to name/shame any individual editors here. WhatamIdoing (talk) 08:37, 1 October 2024 (UTC)
Gaming definitely happens (obvious example), but maybe you mean more that it's not happening as much as is often suggested. Firefangledfeathers (talk / contribs) 12:45, 1 October 2024 (UTC)
Regarding "I have seen a small number of editors claim that unnamed[*] others are gaming the system. I have personally seen no convincing evidence of this."...not that it makes any difference, but gaming the system is not unusual for people trying to tunnel through the EC barrier into the WP:PIA topic area, and Wikipedia kindly provides several tools to help them. This is probably the most impressive example I've seen, but there are plenty of other examples. The topic area is apparently rather good at attracting new editors and people pretending to be new editors. Sean.hoyland (talk) 12:48, 1 October 2024 (UTC)
Regarding "if I'm running into constant POV pushing around a subject, that could be a sign that the articles are not complying with WP:YESPOV", while this is possible hypothetically in a world of rational rule-based agents, in PIA the arrival of large numbers of new users and the amount of POV pushing can often be connected to influence operations on social media and partisan media coverage. It is apparently extremely easy to manipulate people and send them to Wikipedia. Sean.hoyland (talk) 13:17, 1 October 2024 (UTC)
  • Gaming of the extended confirmed restriction is extremely common. It's easy enough to find straightforward examples just by searching the ANI archives, where they usually get reported, and the AN archives, where people often go to request it back when an administrator removes it; often this results in EC being revoked or the user being blocked as a sock (remember, slowing down socks is part of the purpose of EC protection.) Most recently the PIA topic area has produced a lot of it, since the recent conflict has attracted a lot of new editors with strong POVs who are eager to "fix" what they see as problems in its articles, and since it has attracted rampant socking; but it's a universal issue that occurs whenever an EC topic area attracts attention. --Aquillion (talk) 13:40, 1 October 2024 (UTC)
It is probably worth mentioning that while "slowing down socks" is certainly one of the objectives of EC, for the PIA topic area at least where ECR was introduced on 2019-12-20, it does not appear to have had a significant impact in terms of revision counts by identified socks. Sean.hoyland (talk) 15:32, 1 October 2024 (UTC)
The overwhelming majority of ECP articles are per arbcom remedies - if we just decide to weaken ECP threshold what I think is going to happen is: arbcom will just change their remedy again (creating another sweeping broken problem that causes all admins to try to scramble around to enforce it). Now, do we really need all these pages so protected -- good question that could be asked to candidates running for arbcom this year! — xaosflux Talk 14:22, 1 October 2024 (UTC)
Certainly for ARBPIA, in practice, the vast majority of articles covered by ECR are not EC protected. Enforcement is carried out by people and is quite expensive. As far as I can tell, answers to the question "do we really need all these pages so protected" appear to largely depend on the extent to which editors are grounded in the day-to-day reality of a topic area. The more time they spend active in the topic area dealing with non-EC edits/editors, the more likely they are to regard the restrictions as necessary/helpful etc. Sean.hoyland (talk) 15:00, 1 October 2024 (UTC)
This is confusing, "only to trusted people without any additional rights attached to it (and with a matching level of protection)"- if they have no permissions, then what is the point of yet another protection level? — xaosflux Talk 14:12, 1 October 2024 (UTC)
It's so I don't get another transphobic pile of trash vandalizing my user page again. LilianaUwU (talk / contributions) 01:02, 4 October 2024 (UTC)
I see that your userpage been vandalized a lot, and I'm sorry that extended-confirmed protection wasn't enough to stop it. In the absence of a stronger protection level (that you're still able to edit through), I think the following approach should be able to simulate one:
I know this is kludgy, and doesn't completely address the reasons behind your proposal, but I hope it might help you. jlwoodwa (talk) 18:53, 4 October 2024 (UTC)
...this is a 200 IQ play right there. I'll get to it later today. LilianaUwU (talk / contributions) 21:00, 4 October 2024 (UTC)
@LilianaUwU So aside from the workaround above, you still haven't explained much about this project-wide proposal. You want us to create some sort of user group, that contains no permissions (which we can't really do but we could make it contain something like 'read pages') and then also make some new protection level. So what would the point of this new protection level be? What changes are you proposing to the protection policy for its use? It sounds like what you are proposing is to create yet another protection level, and permissions for editing this 6th (more like 8'th) protection level -- and creating a new group that does have permission to make edits at this new level. In which case, this is also a seriously premature proposal. I suggest you close this down, go workshop up all of your new group and protection level suggestions on their own draft pages, then pop back here to get people to provide you feedback on the workshopping, then eventually come back here and propose it for community acceptance.
Now if what you are really after is something along the lines of: My userpage keeps getting vandalized, please help - the suggestion above is an option, or that is something you can ask for help over at WP:AN that wouldn't require a very complicated new scheme. — xaosflux Talk 22:12, 4 October 2024 (UTC)
I'm not sure why I even came here to ask about this when I could've went to AN, honestly. My main thing was about my user page being vandalized. Is there a way to close the proposal? LilianaUwU (talk / contributions) 22:14, 4 October 2024 (UTC)
Marked as archived - this is a huge place, easy to end up in the wrong forum. If there is a continuing problem, please do let us know at WP:AN -- if the admins can't figure out a way to manage disruption they will also know other people that can be brought in. — xaosflux Talk 22:47, 4 October 2024 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Request for check user is meant to be for request for permission

This is not a concrete, actionable proposal. Information on the topic has been provided. — xaosflux Talk 20:33, 5 October 2024 (UTC)

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

OK 132.147.192.240 (talk) 02:21, 28 September 2024 (UTC)

Hi! Wikipedia:Requests for checkuser is inactive, and has been replaced by Wikipedia:Sockpuppet investigations. Also, while the names might be confusing, it isn't a request for permission, as it wasn't to request to become CheckUser, but rather to request assistance from a CheckUser in a specific situation. Chaotic Enby (talk · contribs) 02:25, 28 September 2024 (UTC)
Requests for checkuser access are handled by the Arbitration Committee, see Wikipedia:Arbitration Committee/CheckUser and Oversight for details. It's worth noting here though that it is one of the most restricted rights on the project (for good reason) and cannot (by both policy and technical restriction) be granted to IP editors. Thryduulf (talk) 02:34, 28 September 2024 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Editing Sri Lankan Election 2024 page

This is not a concrete, actionable proposal. The content edit was already made and information on how to discuss content improvements has been provided. — xaosflux Talk 20:35, 5 October 2024 (UTC)

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Could someone edit this page to show that AKD won. Idk how to edit elections Irindu10 (talk) 15:22, 22 September 2024 (UTC)

Looks like it has already been done. In the future, it is better to ask this on the article's talk page (here, Talk:2024 Sri Lankan presidential election), as it is more likely to be seen by editors more knowledgeable on this specific topic. This page here is for more wide-ranging proposals, rather than to request specific edits. Chaotic Enby (talk · contribs) 02:30, 28 September 2024 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

RfC on In the news criteria

There is a request for comment on the In the news criteria at Wikipedia:Village pump (policy) § RfC: In the news criteria amendments. voorts (talk/contributions) 23:01, 7 October 2024 (UTC)

Bring dark mode reporting on-wiki.

The current system is very convoluted. Being on a fourth level subpage on a different wiki with 90% of the comments not being signed, and using an emoji system for distinguishing resolved/unresolved issues makes it a nightmare for a) finding issues, b) responding, and c) asking for more details. It would be easier to have a page like Wikipedia:Dark mode reports so more editors could help fix issues. We should import the page here and archive the MediaWiki wiki page. Thoughts? @SCP-2000, FeRDNYC, and I Am Andumé: as editors involved there on fixing issues (if I've missed someone feel free to ping them). —Matrix(!) {user - talk? - uselesscontributions} 14:42, 5 October 2024 (UTC)

Survey (dark mode reporting)

Following the response from WMF, I think it's a good idea for a survey to check if we want to proceed further. @Xaosflux, FeRDNYC, SCP-2000, Isaacl, Phil Bridger, WhatamIdoing, and Thryduulf: and any other people, please state your position briefly:

Implementation

Okay, the consensus is the people fixing dark mode issues can decide the location, and FeRDNYC has also expressed the current issues with the current system. Dark mode issues are ultimately usually a local problem, and WMF has also said this is technically possible. We would need to do a few things:

  1. Import the MediaWiki page to enwiki with the options "Copy all the revisions for this page" and "Assign edits to local users where the named user exists locally" (this is important for archiving later).
  2. Use User:ClueBot III archiving (User:lowercase sigmabot III relies on signatures which won't work out)
  3. Repoint MediaWiki:Vector-night-mode-issue-reporting-notice-url and make MediaWiki:Vector-night-mode-issue-reporting-preload-content include signatures
  4. Archive the MediaWiki enwiki page.

I think we can start working on this. —Matrix(!) ping onewhen replying {user - talk? - uselesscontributions} 08:57, 12 October 2024 (UTC)

I'm fine doing the transwiki import for this when ready, but I'm not seeing a consensus in the discussion above yet. The "assign local" part is not needed; I doubt anyone at mwwiki will care about that page, we're not going to delete anything there but can just slap a cross-wiki redirect on it. So what next? Someone that hasn't !voted on this above should eventually close this discussion with a result. For the xmlimport part, feel free to ping me at that time. — xaosflux Talk 11:43, 13 October 2024 (UTC)
Fair enough. I'll wait for consensus to develop (I just got impatient since no once was participating). —Matrix(!) ping onewhen replying {user - talk? - uselesscontributions} 11:49, 13 October 2024 (UTC)

Check Wiki error fixing AWB Bot

Hello everyone!

I, Bunnypranav, wish to create a bot that intends to fix Check Wiki errors on the affected pages. For now, I consider focusing only on CW Error #3: Reference list missing, but later am willing to expand on to other errors, especially High Priority errors which can be fixed automatically using AWB. A majority of my AWB edits were fixing this error, and I did not find a single wrong suggestion by AWB

I intend to keep Auto Tagging and RegexTypoFixing on, but OK with turning it off if consensus says so.

I know that there are couple other bots fixing Check Wiki errors (Yobot, MenoBot), but I feel the project can do with another bot. I request everyone to give their opinion on my proposal, and I am willing to accept any feedback (including about my readiness of being a bot operator). Bunnypranav (talk) 11:59, 22 October 2024 (UTC)

Discussion at Wikipedia:Edit filter/Requested § Warn on inline image usage

 You are invited to join the discussion at Wikipedia:Edit filter/Requested § Warn on inline image usage. Aaron Liu (talk) 00:54, 24 October 2024 (UTC)

Enabling SecurePoll elections with the electionadmin right

The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.
WP:SNOW: unanimous support to have the ability to hold local SecurePoll elections, including enabling the electionadmin right on enwiki. An RFC to determine how the new right should be distributed can be launched at any time; it may be advisable to advertise that RFC on WP:CENT. Levivich (talk) 14:48, 27 October 2024 (UTC) Levivich (talk) 14:48, 27 October 2024 (UTC)
Tracked in Phabricator
Task T301180

Hello! My name is Joe Sutherland and I'm on the Trust and Safety team at the Wikimedia Foundation. In the past, your community has shown interest in holding elections with SecurePoll — perhaps you already have through votewiki. We are now looking into making this available to local communities to run elections themselves. This will require the "electionadmin" right to be enabled on your project, which is a right that allows access to sensitive information.

As such, it is likely that you will need to run a Request for Comment (or similar process) to ascertain consensus for the implementation of this feature. To help guide such a discussion, we've put together a Meta-Wiki page with more information about what enabling the right will mean for your community.

If your community does discuss and decides to move forward with this, T&S would like to support you — please let us know via email ( ca@wikimedia.org ) if and when consensus is reached. Thank you!

P.S., this might be better suited for the technical village pump, so feel free to move it there if you like. Joe Sutherland (WMF) (talk) 20:07, 17 October 2024 (UTC)

  • Support enabling. This seems like a perfunctory step needed to facilitate the administrator elections that we have found consensus to conduct. Whether this separate RfC is even needed is debatable, but I think it'll be easier to just get consensus than to debate whether it's necessary. Sdkb talk 20:17, 17 October 2024 (UTC)
    Sorry, I wasn't totally clear - this would be for future (admin/ArbCom) elections that the community would like to run. The elections scheduled to start soon will use the existing votewiki system. Joe Sutherland (WMF) (talk) 19:43, 18 October 2024 (UTC)
  • Support. This isn't a requirement holding for admin elections, arbcom elections (or any other type of elections) but (if I've understood correctly) it will reduce the amount of support we need from the WMF when we do hold them. I agree completely with Sdkb's last sentence. Thryduulf (talk) 20:35, 17 October 2024 (UTC)
  • Support. This would help us host local administrator elections and arbitration committee elecitons that aren't so dependent on the limited bandwidth of the stewards (scrutineers) and WMF T&S (for vote.wikimedia.org setup). By the way, are electionadmins basically checkusers within the SecurePoll tool (being able to see IP information for voters)? So we'd need to make sure that folks that receive that permission are a functionary and/or sign an NDA? –Novem Linguae (talk) 20:35, 17 October 2024 (UTC)
    P.S. Is there a ticket on Phab to separate election checkuser capabilities from election creation/editing capabilities? This might be worth looking into. The person that sets up polls doesn't necessarily need to be the same person that checks all the voters. And it may make sense to have a division here. For example, someone technical can set up SecurePoll, and existing checkusers could do the scrutineering. –Novem Linguae (talk) 20:39, 17 October 2024 (UTC)
    I did some research and it looks like any admin can create a poll, but only electionadmins (scrutineers) can edit a poll or view checkuser-like data on voters. This split is a bit odd, as I think it'd be better if admins could also edit polls that they were added to when the polls were created, so I've filed phab:T377531 to explore that idea a bit further. –Novem Linguae (talk) 23:56, 17 October 2024 (UTC)
  • Support to help us implement administrator elections in a more practical way for both us and the WMF. However, will electionadmins be a new user group? They seem to combine characteristics of checkusers and bureaucrats, and I'm not sure whether it would work to bundle the right into either by default. On the other hand, Novem Linguae's proposal of splitting the user right could work better, with a technical-minded crat setting up the poll, while checkusers get the scrutineering right. Chaotic Enby (talk · contribs) 22:20, 17 October 2024 (UTC)
    If I'm reading the code right... yes, electionadmin would either need to be a new user group, or the permissions for it (securepoll-create-poll, securepoll-view-voter-pii) added to an existing user group such as the checkusers. The latter might be simpler than creating a whole new appointment process for electionadmins.
    At first glance, I don't see a relationship between bureaucrats and electionadmins. Electionadmins can't grant any user groups, unlike bureaucrats. Again, if I'm reading the code right, any admin can create a poll. –Novem Linguae (talk) 00:01, 18 October 2024 (UTC)
    For the relationship between bureaucrats and electionadmins, it's more to have the same group in charge of regular RfAs and admin elections, and to decouple checkusers from this additional responsibility. But that might be too redundant, and having any technical-minded admin able to do it could be enough, although it would be a major responsibility to give to any admin and might make it more difficult for potential candidates to gain the voters' trust. Chaotic Enby (talk · contribs) 13:14, 18 October 2024 (UTC)
  • The technical village pump is for questions about how to do X, whereas how to grant the electionadmin right requires a proposal for a policy, so this page is the appropriate place. Since the right provides access to voter information (as per meta:SecurePoll/Local elections § What does the electionadmin right do?), a process is needed to establish who is trusted with this access. The options I can think of are by consensus discussion, by election, or by appointment (which would push the question up one level on how to decide what group does the appointing). Being part of an existing trusted group, such as those with the oversight right or the checkuser right, could be a requirement to become an election admin. isaacl (talk) 23:35, 17 October 2024 (UTC)
    It might be simplest to grant the permissions securepoll-create-poll and securepoll-view-voter-pii to the checkusers. That way we don't need the overhead of a separate user group or separate appointment process. I think you have to specifically be added to a poll by the poll creator to see its PII, so there shouldn't be any security risk from giving all the checkusers the ability to be added to polls by the poll creator. –Novem Linguae (talk) 00:03, 18 October 2024 (UTC)
  • This feels like a major oversight. The admin elections are modeled after WP:ACE but apparently nobody thought about the scrutineers that need to be approved and tooled up each year for ACE. I'm presuming this means the elections are on hold until we clear this up? Just Step Sideways from this world ..... today 00:15, 18 October 2024 (UTC)
    No, I think the admin elections are going to proceed using the old process (of voting being done on VoteWiki) and this is only about the future. * Pppery * it has begun... 00:20, 18 October 2024 (UTC)
    Scrutineers have been identified for the trial admin election (see Wikipedia:Administrator elections § Tallying). isaacl (talk) 00:32, 18 October 2024 (UTC)
    Well, that's a relief. It's been such a prolonged process to get here I can't say I followed every part of it. Just Step Sideways from this world ..... today 06:56, 18 October 2024 (UTC)
  • Support If we're going to be doing regular admin elections it makes sense for the infrastructure to be local. Pinguinn 🐧 00:24, 18 October 2024 (UTC)
  • Locally, we have a few options that we could consider if we decide to do polls. First, we don't HAVE to encrypt the database, it doesn't make the votes readily available - but a developer could access them, so that is something to consider (also means not having to deal with key escrow to finalize the election). Additionaly, we don't have to let SP collect private info. We would still have the usernames - it would just prevent using the checkuser info on the securepoll votes. These are all just things to consider if we set up polls - point is that there are options. — xaosflux Talk 13:41, 18 October 2024 (UTC)
  • Support Local communities should have the autonomy to conduct elections when they see fit, and not be so dependent on a certain WMF team that has a tight calendar. Also, the inability to conduct separate elections on multiple sites at the same time is a big limitation of the current system that would be addressed by this. – SD0001 (talk) 08:55, 19 October 2024 (UTC)
  • Support -- Per SD and Xaos above, I think deploying SecurePoll locally so that individual communities can conduct elections in a autonomous and decentralized manner at the tradeoff of some confidentiality is a good idea in general. Sohom (talk) 14:26, 19 October 2024 (UTC)
  • Support As it gives the community an option for future polls. How it should be used can be shorted out later. -- LCU ActivelyDisinterested «@» °∆t° 20:28, 19 October 2024 (UTC)
  • Support This will help host the elections more frequently, reducing the expense of WMF staff. Bunnypranav (talk) 11:52, 22 October 2024 (UTC)
  • Support An RFC will definitely be necessary to determine who can scrutineer. I imagine we have a few options, the first two I can think of being either assigning the CheckUser group (or perhaps a different set of users?) the electionadmin right, or just creating a new usergroup and having Stewards go ahead and assign it to the relevant scrutineers a week or so before an SP is scheduled to occur, then remove it afterwards. EggRoll97 (talk) 03:33, 23 October 2024 (UTC)
  • Support I have organized Wikimedia elections for affiliate organizations and after trying open processes, have found that commercial software is the only practical option. The Wikimedia community loves democratic process and elections, but has never had tools to support that. Making an option for SecurePoll has been a longstanding community request since at least 2016 when meta:SecurePoll was set up. Bluerasberry (talk) 15:05, 26 October 2024 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

I've filed phab:T378287 to action this RFC close. –Novem Linguae (talk) 15:13, 27 October 2024 (UTC)

2020 US Census update bot

Discussion has moved to WT:CITIES. Let's centralize further comments there to avoid a talk fork. Sdkb talk 18:05, 28 October 2024 (UTC)

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

I frequently edit articles about small towns in Iowa. When the 2020 US Census results were released, the vast majority of these articles had multi-paragraph summaries of the 2000 and 2010 Census results, usually under the heading "Demographics". The 2010 summaries appear to have been made by a bot, which is no longer active. The 2020 Census results have been available for several years now, and no bot has run through these articles and inserted 2020 Census summaries. For a few of the larger cities in Iowa, editors had added 2020 summaries, but for the vast majority of cities, towns and CDPs, the articles only had 2000 and 2010 summaries. So I updated the 974 articles for the Iowa towns with no 2020 summary, manually (I didn't clobber any exisiting 2020 summaries, unless they had fewer than 3 sentences). I spot checked the situation for other states, and found a similar situation. There may be as many as 40,000 articles that have this issue (for example: Northfield, Minnesota).

I think a case could be made that these articles really don't need extensive summaries of the census results. But I don't think many people would think that these articles should have extensive summaries of past censuses, but not the most recent one. Surely the most recent census is the most relevant. Having the summaries end at 2010 makes the article look abandoned.

Before I edited all those Iowa city articles, I made a Python script that called the US Census Department servers' API, to fetch the data, and the script produced a text block formatted properly for Wikipedia. I think it would be useful to to make a bot to update the articles for other states, but there are tricky issues, and I have never made a Wikipedia bot. Is there anyone who would be willing to work with me to make a bot to do these updates? If this is the wrong place to be asking that, can someone direct me to the correct place? Thanks for any info! PopePompus (talk) 01:51, 27 October 2024 (UTC)

@PopePompus, you're definitely correct that census data for U.S. cities is a very lacking area.
I'd start by reviewing the discussion here from 2020 — as you'll see toward the end, my view is that we very badly need to be converting this information into template form, rather than copying and pasting it (which is a large part of what has created the mess). I'd then open new discussion at WT:CITIES to get a sense of where current consensus is at. You may also want to look at what information Wikidata has and whether that can be of use. Once you've established consensus there to make changes, bot approvals go at WP:BOTREQ.
Overall, this will certainly be a major project, given the complexity of the information involved and the wide scale at which changes are needed. Good luck! Sdkb talk 04:12, 27 October 2024 (UTC)
I will just add that a bot created almost all of the articles about places in the US that were enumerated by the US Census in 2000. Many of those articles for years consisted of very little more than the demographic section. I believe that most of the 2010 census data was added manually, generally attempting to follow the 2000 bot-created format. Adding the 2020 census data has been piecemeal, at best. A bot to handle this sounds good, but getting agreement on the format for the data in articles may require some discussion. Donald Albury 13:26, 27 October 2024 (UTC)
I think the mass creation of the articles by a bot was a very good thing. At least in the case of Iowa, most of the articles have accumulated non-bot content. Since the barrier to entry for editing an existing article is far lower than creating a new one, it's safe to say that most of the post-bot content would not ever have appeared absent the bot. I agree with Sdkb that a template is the way to go. I had not seen the 2020 discussion he pointed to, and I found that discussion somewhat disappointing, because a lot of the discussion was about details, rather than focusing on what I think are the major issues: Template or not, should old results be retained in the main body of the text, and perhaps most importantly who's gonna do it. PopePompus (talk) 13:53, 27 October 2024 (UTC)
Consistency of the Demographics sections across articles about (Census enumerated) populated places in the US is desirable. Unfortunately, I have no experience with bots, and have fallen into the hole of trying to expand articles about almost 80 species in a genus. Donald Albury 14:32, 27 October 2024 (UTC)
I would like to see a bot add this information. Adding the same thing as last time is okay with me, though a complete re-write might eventually be desirable. It looks like Yellowcard has done some work at getting the US census numbers into Wikidata. Perhaps he has the needed skills, or at least is familiar with the format of the database?
(In terms of a complete re-write, imagine that an exact replica would result in these three sentences in the article (in separate sub-sections):
Would it be possible to combine this into a single statement like:
  • The racial makeup of the city was 88.5% White, 0.5% African American, 1.5% Native American, 1.5% from other races, and 8% from two or more races, representing a decline in <name listed groups with significant change> and an increase in <name other groups> since the 2000 census.
WhatamIdoing (talk) 19:49, 27 October 2024 (UTC)
Also, TheWeeklyIslander added the 2020 census data to Mulberry, Kansas, so perhaps they know of some tools to do this. WhatamIdoing (talk) 19:50, 27 October 2024 (UTC)
Thanks @WhatamIdoing for the ping. We (a interested user group in the German Wikipedia) have invested a lot of time and effort by extracting the data from the US Census Bureau website/database and uploading it to Wikidata. This is done for data like population, number of households, area, water area, per capita income (which comes from the ACS) etc. The population data is available for the 2010 and 2020 census.
Creating a bot that fetches the information from the Census Bureau's website and creates plain text (!) is a horrible idea to me. The data is available on Wikidata and usable for Wikipedia already (and has been since 2021). The project on German Wikipedia has a bit stopped due to real-life timing issues, but could be restarted. For the German Wikipedia (where article creation by a bot is rejected, for whatever reasons), we use the data in the infoboxes for all US cities that have an article. The data is so reliable that we even have removed the parameters for population and household counts in the infobox - they are fetched from Wikidata no matter what. No manual updating of Census information in the article necessary nor possible any more.
Articles in German face the same issue as in the English Wikipedia - totally outdated, bot-generated and therefore boring Demographics paragraphs. There is a clear consensus that we will not make this mistake again. Data like this should go into the article via templates, not via plaintext. Yellowcard (talk) 16:06, 28 October 2024 (UTC)
Some editors at the English Wikipedia distrust Wikidata, so relying entirely on Wikidata isn't accepted. They worry that vandalism (or innocent mistakes) will go unnoticed and uncorrected. We also have a substantial group of editors who believe that paragraphs are preferable to infoboxes, or necessary in addition to infoboxes. Between them, I think the most likely outcome is plain old paragraphs. WhatamIdoing (talk) 17:43, 28 October 2024 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Sortition for elevated permissions

Proposal for trial: assignment to a small random group of editors to elevated permissions for a fixed short term by sortition.

  • Test 1: Selected extended-confirmed editors, who have edited in the past 100 days, get AfC and/or new page reviewer, which have backlogs. They still have to read the instructions. (PCR is too weak for a practical experiment imo.)
  • Test 2: Selected auto/confirmed editors, who edited recently, get bumped into extended-confirmed.
  • Rules: Any admin can strike for any behavior at any time; one strike and you're out; no extension of term; no exceptions. Also: you cannot refuse permissions, and your editing or sanction history (but not block history) has no bearing on whether you get or don't get permissions. Every admin and editor with equal permissions capable of oversight will have a readily-accessible list of test editors. (It's not difficult to deduce otherwise.)
  • Numbers: As a conservative estimate for a first experiment, maybe 200 editors on both tests simultaneously for 6 months, depending on the activity level of those in the sample -- if 20 editors substantially increase their activity in response, that's measurable and manageable.

The purpose is to increase engagement by somewhat active editors across the spectrum, and perhaps even motivate requests for permanent permissions and adminship down the line. In that spirit, if a test editor loses permissions in the one-strike rule, it should have minimal or zero bearing on requesting permissions in future. This is a learning and motivational experience. That permissions here are ultimately reversible and have oversight means that, on balance, if an ill-behaved editor now ends up being able to credibly seek permissions in future, this model, should it be causative, was indeed a success.

Research and benefits and cautions

Sortition literature addresses both issues that have zero bearing on WP governance, and issues that are quite important. Additionally, I believe there are issues unique to WP that sortition may address that the literature has not yet done. Review: (TG Bouricius 2013 "Democracy Through Multi-Body Sortition: Athenian Lessons for the Modern Day").

What is proposed is called partial governance by sortition with rotation and mandate (Owen and Smith 2018 "Sortition, rotation, and mandate"). Known and possible benefits and cautions:

  1. Random selection is more likely to give demographic and ideological representation (Ebadian et al 2022 "Is Sortition Both Representative and Fair?"). While WP editors are not representative of general populations, our adminship is even less representative (in Corple 2016 "Beyond the Gender Gap" p.25: 6% vs 15%+).
  2. A high barrier to entry of WP adminship and some permissions, combined with thanklessness of tasks and relatively low social prestige, means that we are probably below rate-of-replacement on adminship, and there are backlogs for areas needing permissions. Sortition, if it results in participation, relieves this burden. It also increases representative fairness and ideological diversity to those who would handle the content and administrative backlogs. (Afaik this is a WP-unique issue.) In Polish Wikipedia the exclusionary effect on new candidates of acquaintancy among admins was studied (Spychała et al 2014 "Does the Administrator Community ... Acquaintance Relation?"); so if a similar phenomenon exists in all permissions then sortition would help disrupt it.
  3. If there is admin corruption (and some editors have claimed as such), sortition is suggested to reduce it (Bagg 2024 "Sortition as Anti-Corruption"). It also potentially is a check against administrative subversion (Sutherland 2011 "What sortition can and cannot do") by cabals of editors, as exposed recently in Croatian Wikipedia.
  4. On the effects of granting priveliges/power: In (Sassenberg et al 2014 "Power corrupts: revisited"), the relationship of elevated power and a sense of communal responsibility vs individual corruption (whether one is elevated as opposed to the other) is complex with contradictory results in the literature. In general, if people are in a socially-oriented environment and goals, which I'd suggest epitomizes WP editing, then power would orient them toward the former. However, the review also suggests that the perception of power as an increase opportunity or promtion, rather than just increased responsibility, is a big part of the increased motivational effects, which would suggest that since sortition may lower the prestige of elevated priveliges, it would have a negative effect on motivation; but this seems again highly social-context- and goal-dependent in the literature.

My brief literature stroll suggested possible routes for future investigation on WP; for further on power and motivation is Pappas APA 2021; and in particular we might push hard to raise the social prestige of elevated priveliges on WP, as well as their associated social responsibilities, per management papers like (Friedrichs 2023 "The benefits of prosocial power motivation in leadership"). Also while it's tempting to consider, if this experiment is successful, a radical future proposed sortition of admins, akin to the admin-for-a-day proposed in 2012, but per WMF this is not legally doable, the prohibitive priveliges being rollback and deleted material. SamuelRiv (talk) 22:39, 7 October 2024 (UTC)

I have trouble imagining us (i.e., those of us who have achieved a measure of power and control in the current system) being willing to give up control over permissions, no matter how slight this might be.
That said, I think that both Test 1 and Test 2 would be worthwhile experiments, and I specifically suggest considering selecting candidates for Test 2 from among those who are nearly EXTCONF anyway (e.g., they have the time but they're short 100–200 edits, or they have the edits, but they're short 1–2 months).
In terms of the size of the experiment, that really ought to be determined by a Power (statistics) analysis. WhatamIdoing (talk) 17:22, 9 October 2024 (UTC)
Even if there's an element of power and status to them, the vast majority of what people with advanced permissions do is just drudgery. It seems really unlikely to me that somebody randomly assigned NPP or even admin is actually going to want to use them. And one of the main functions of the perm system is to reduce the attack surface these rights offer by only giving them to people motivated enough to ask for it.
Also, yes AfC and NPP are backlogged, but 'reviewing the reviewers' is also work and there are very few admins doing it. This would massively increase that workload - who's going to pick up the slack? – Joe (talk) 17:58, 9 October 2024 (UTC)
I imagine that an editor who receives a note saying something like "You've been given this permission temporarily. Please read up and use it if you want" might use it a few times, at least to try it out. If they have a positive experience, they might request to the perm later through the usual channels.
Giving a perm only to those motivated enough to ask means that a higher percentage of the requesters is improperly motivated. Undeclared paid editors will be more motivated to ask for the permission than an ordinary volunteer. WhatamIdoing (talk) 18:20, 9 October 2024 (UTC)
I think "checking up on whether people did the thing correctly" and "doing the thing" are really different actions. So while I think it's obvious that this would increase the amount of "checking up on each other" work, I'm not sure it's the admins at AfC and NPP that will be shouldering that work, though I'm sure we probably would do so somewhat disproportionately. -- asilvering (talk) 21:44, 25 October 2024 (UTC)
I am quite a fan of sortition for filling real-world positions, both where it is used in many countries (mainly for selecting juries) and for some other positions. A few thoughts on its applicability to Wikipedia:
  1. I doubt that many people would devote much time to the task, because they have to earn a living, and paying the people selected would cause many other issues.
  2. Many people would try out their new permissions, but most would drop out.
  3. There need to be clear success/failure criteria. Too many things are tried here, then clearly fail, but continue to be used because of the sunken cost fallacy (I know this is controversial, but I would class draft space as being one of these).
I'm sure I could come up with loads more points, both for and against, but I have to go now. Phil Bridger (talk) 19:49, 9 October 2024 (UTC)
Clear criteria are highly desirable. Unfortunately, I'm not sure that a single metric works (e.g., we don't want to lose these randomly selected editors and we don't want WP:UGLY articles in the mainspace), and it's entirely possible that doing the jobs correctly would result in the selected editors quitting. For example:
  • Existing AFC promotions have a very low rate of deletion at AFD. (I believe that the normal rate is about 75%.) Given that they're supposed to promote articles that are likely (i.e., 51%, not 90%) to survive AFD, this means that they are underpromoting and overrestricting.
  • If the new AFC people collectively promote articles that get deleted only 40% of the time, that's a sign that they're doing it correctly (still underpromoting, actually), even though theirs are getting deleted more often than older AFC folks. Thie AFD metric would show success.
  • But: if each AFD, or the run up to those AFDs, comes with recriminations and complaints about how they're being too "lenient", then the yelled-at editors might quit. The editor-retention metric would show failure.
If we get mixed results, what should we do? WhatamIdoing (talk) 21:50, 9 October 2024 (UTC)
If the new AFC people collectively promote articles that get deleted only 40% of the time, that's a sign that they're doing it correctly (still underpromoting, actually)
Not necessarily. If they promote articles with a chance to survive AfD above 50%, and we assume they are uniformly distributed in probability, the average promoted article would have 75% of chance to survive AfD, or in other words get deleted 25% of the time. If they get deleted 40% of the time, there might be a level of overpromotion going on. Chaotic Enby (talk · contribs) 16:38, 16 October 2024 (UTC)
(I love people who can math.)
I think it depends on your underlying assumptions about the distribution. If you have 10 articles, each with a 51% chance of surviving AFD, and you promote them all, and all 10 get sent to AFD, then you'd expect five to get deleted – and they were all still correct promotions. WhatamIdoing (talk) 16:55, 16 October 2024 (UTC)
That definitely depends on our hypotheses about the distribution, indeed. If the 10 articles range from 51%, 56%, ... up to 96%, then you'd have a lower expectation of deleted articles (2.65 if I mathed correctly). But there's also a hidden assumption in here, in that an article with 96% chances of surviving an AfD will probably not be sent there to begin with, meaning the deletion rate of articles being sent at AfD will naturally be higher than the total deletion rate.
All in all, it would be interesting to have more statistics about both the deletion chance of AfC articles at AfD, and how much AfC articles are underrepresented at AfD to begin with. Chaotic Enby (talk · contribs) 18:18, 16 October 2024 (UTC)
Deletion stats are difficult to measure retrospectively. It might be something that we need to study prospectively. There's also the complication of experience: people submitting articles through AFC are not going to have the same deletion rate as people like you and me. WhatamIdoing (talk) 18:51, 16 October 2024 (UTC)
Complicating this, I don't think most AfC reviewers go for "50% likelihood of AfD survival" so much as "I'm more than 50% sure this would survive AfD" - not quite the same thing. I think I'm one of the more lenient AfC reviewers (well, of those among us who aren't socks), and if 25% of my accepts went to AfD I'd be shocked. Also I think people would be telling me to resign. -- asilvering (talk) 21:42, 25 October 2024 (UTC)
I suspect that you're correct. Just having more than a small number of articles sent to AFD, even if they were all kept in the end, would raise some eyebrows. WhatamIdoing (talk) 22:26, 25 October 2024 (UTC)
  • Also while it's tempting to consider, if this experiment is successful, a radical future proposed sortition of admins, akin to the admin-for-a-day proposed in 2012, but per WMF this is not legally doable, the prohibitive priveliges being rollback and deleted material. That doesn't necessarily have to prevent it; the WMF doesn't set an actual bar for the community review. Therefore, we could have a much lower-pressure, lower-stakes community review of every editor who meets a certain threshold of edits and age to determine eligibility for one day obtaining those rights via sortation, with the sole focus being "is this person likely to abuse rollback or access to deleted material?" (which would almost always lean towards acceptance, since it is automatic, done for everyone, and doesn't directly grant adminship.) Only arguments and rationales specifically related to that question would be allowed and considered by closers when closing such discussions, not general discussions of whether they'd make a good admin in other ways; and they wouldn't require bcrat closures or anything. This would then allow admin status to be granted to those editors via sortition because they'd previously passed a community review on the aspects the WMF cares about. --Aquillion (talk) 19:12, 16 October 2024 (UTC)
    the prohibitive priveliges being rollback and. Rollback doesn't seem very dangerous. I doubt wmf would put their foot down about handing out that one too easily. Agree that wmf would object to handing out view deleted though for legal reasons. This has been well discussed before. –Novem Linguae (talk) 19:19, 16 October 2024 (UTC)
    I don't think that the WMF cares about Wikipedia:Rollback (which doesn't even get used much, because Twinkle and other scripts can mimic the same effect). The legal problem is viewdeleted. They have consistently said that they want proof that the community trusts the people who have that particular right (e.g., we trust them not to restore copyvios or re-post uploaded revenge porn to another site). The process of community vetting can change, but there must be a community vetting process. WhatamIdoing (talk) 19:43, 16 October 2024 (UTC)
    (e.g., we trust them not to restore copyvios or re-post uploaded revenge porn to another site). I've never heard that. WMF's stated reason for viewdeleted being sensitive is that they want to be able to say in court that when something is deleted, it is well and truly deleted, and that only vetted individuals will have access to it, rather than it being easily accessible. The vibe I'm getting is to make sure BLP, libel and defamation, etc. stays deleted and that they can argue it is truly deleted in court. –Novem Linguae (talk) 20:40, 16 October 2024 (UTC)
    If someone is restoring the inappropriate here or posting it on other websites, then that's not "staying deleted", and nobody could argue that it is, even around the dinner table. We need to be able to trust that admins won't do that. WhatamIdoing (talk) 21:59, 16 October 2024 (UTC)
  • Either way, though, my point is that we can have a more lightweight vetting process focused specifically and exclusively on whether someone is likely to abuse the specific tools the WMF is worried about. Whenever alternative approaches to adminship come up, people bring up that WMF concern, and it's easily addressed. The WMF isn't worried about people abusing blocks, or unblocks, or weighing in at WP:AE, or AE enforcement actions; and the (perceived, at least) high risk associated with those things under the current system is what actually makes people reluctant to promote admins and which therefore makes RFAs hard. This is also self-perpetuating in that the fewer admins there are the more impact each one has, raising the stakes of RFA in a way that risks breaking it. The community and the WMF are worried about different things. --Aquillion (talk) 22:34, 16 October 2024 (UTC)
    I agree. This is a solvable problem. Also, it doesn't have to be solved in the first iteration. We could test the system on a couple of other userrights, and circle back to test some others later. WhatamIdoing (talk) 23:09, 16 October 2024 (UTC)
Wouldn't revenge porn etc. be oversighted, not just deleted? jlwoodwa (talk) 04:57, 17 October 2024 (UTC)
Yes, but admins often revdel serious problems first, before reporting to the oversighters. (Also, that's not usually uploaded locally.) WhatamIdoing (talk) 05:02, 17 October 2024 (UTC)
WMF doesn't care about rollback. We could even auto-promote users to some "been around a while" group that includes all of Autopatrolled, New page reviewer, Page mover, Pending changes reviewer, Rollback and they wouldn't care. — xaosflux Talk 13:53, 17 October 2024 (UTC)
Honestly, at least when it comes to NPP/AfC, I'm into it. -- asilvering (talk) 21:46, 25 October 2024 (UTC)
For those two in particular, I think a metric worth checking is whether anyone requests the permission permanently afterwards. WhatamIdoing (talk) 22:27, 25 October 2024 (UTC)
I'd be tempted to do it slightly the other way around - go ask the editors whose sortition perms are about to expire if they want it taken away, and leave it otherwise, so long as they used it non-disruptively. -- asilvering (talk) 22:32, 25 October 2024 (UTC)
I think the idea about temporary permissions is that you can't build a fiefdom. Do the work for a designated period of time, and then your turn's up, and someone else takes over to do their best. WhatamIdoing (talk) 02:13, 26 October 2024 (UTC)
I wonder if we could do this in reverse. Specifically, I worry that the regulars at ANI and COIN (in particular) see so much bad behavior that they develop a distorted view of the community and its goals. For example, if you see an endless parade of accusations about undeclared paid editing because the complainant believes the content to be 'promotional', then you'll start seeing UPE scammers behind everything, even when it's just an ordinary person, not fully aware of our house style[*], trying to write about a subject that interests them. Could we pick a random set of 'regulars' and invite them to take a break for three months? And invite, say, 10x as many uninvolved folks to step up to take their places?
[*] For example, our house style declares that "offices in 26 countries and as of October 2024 in the process of opening offices in two more countries" is okay, but "offices in more than 25 countries" is culpable promotionalism, and the maintenance cost of the first style is unimportant.
WhatamIdoing (talk) 19:32, 27 October 2024 (UTC)
I think this is extremely true. -- asilvering (talk) 20:03, 27 October 2024 (UTC)
I like this. /genuinely Aaron Liu (talk) 22:34, 1 November 2024 (UTC)
I don't like proposal 1. NPP and AfC are the most important roles to encourage new editor–retention. Overzealous deletion/declines can drive new editors, content, and ideas out. (Speaking personally, it also doesn't seem very nice to have your fun revoked after making just 1 goof. The strike thing would be agonizing to enforce. Admins may get angried against for "why did you strike this patroller just because they were too officious, jargony, and laconic and scared a newbie away?". Meanwhile, I see no better alternative to the 1-strike system, therefore I do not like proposal 1.) I don't really see the purpose of proposal 2 as pretty much only editing contentious topics directly without edit request relies on this (who would be autoconfirmed and run for administrator?), and such experience is quite essential towards editing such flamewar-inducing pages directly, but I could be fine with it, I suppose. Aaron Liu (talk) 22:34, 1 November 2024 (UTC)
Are you assuming that someone new to NPP and AFC would be more likely to delete/decline new articles than the existing folks? I'm not sure that would be true, honestly. WhatamIdoing (talk) 00:38, 2 November 2024 (UTC)
I'd be very prepared to believe that it is, but have nothing but anecdata to back this up. -- asilvering (talk) 02:57, 2 November 2024 (UTC)
I don't think this will work. Firstly, we need to at least attempt to establish that someone understands the rules and instructions before we give them these rights. Secondly we don't expect perfection from admins, so one strike and you're out is excessively harsh - particularly as that strike will count against them if they ever want to apply for advanced permissions in the future (whether it should nor it, it will). It will be a big disincentive to actually use the tools, particularly if they have shown no interest in the job (and not using the tools when they had them will be something they have to defend at RFA if they stand). Thryduulf (talk) 03:07, 2 November 2024 (UTC)

Warn on inline image usage

Moved from Wikipedia:Edit filter/Requested/Archive 21 § Warn on inline image usage
 – Aaron Liu (talk) 11:27, 25 October 2024 (UTC)
  • Task: When an edit adds an file link without "|(\s*)?frameless" or "|(\s*)?thumb" within it, warn the user and tell them they probably wanted to put a |thumb in. Still allow them to save the edit. Can also scan for every format supported if wanted.
  • Reason: Prevent accidential and improper usage of images. I don't see a use case for inline image usage here.
  • Diffs: The one before Special:Diff/1251723553: accidentally forcing browsers to load a 0.7GB image.

Aaron Liu (talk) 04:12, 19 October 2024 (UTC)

Needs wider discussion but until then, {{EFR}}. The basis for this request is on one accidential removal of a colon. This seems more like something that might be raised at Phab if nothing else, but I don't think we need a filter to warn people to use thumb. EggRoll97 (talk) 23:52, 23 October 2024 (UTC)
This was created as a result of and linked from a VPI topic, but sure, I've notified VPR. Aaron Liu (talk) 00:55, 24 October 2024 (UTC)
Coming from VPR. I'm not sure what our standards are for edit filters enough to be able to comment on the appropriateness of one for this. But I can say that I've certainly been guilty of forgetting to add thumb and not previewing, resulting in situations exactly like the linked diff.
If this isn't found appropriate for a filter, we should certainly add it to mw:Edit check/Ideas so that PPelberg (WMF) et al can take it up. Cheers, Sdkb talk 01:17, 24 October 2024 (UTC)
I think edit check is a much better place for this than abuse filters which prevent the entire edit from saving. * Pppery * it has begun... 01:33, 24 October 2024 (UTC)
Edit filters can warn on first submit and let it save on second submit. Aaron Liu (talk) 02:09, 24 October 2024 (UTC)
Sounds like a good idea! Aaron Liu (talk) 02:09, 24 October 2024 (UTC)
Actually, no, I'm not sure if edit check applies. Its project page defines it as a set of improvements for the visual editor, where I highly doubt editors make this mistake. Aaron Liu (talk) 02:19, 24 October 2024 (UTC)
Ah, true, I forgot that. In that case, we might want a different sort of warning, perhaps akin to the disambiguation link added one. Sdkb talk 02:24, 24 October 2024 (UTC)
That takes a lot more development than a regex. Aaron Liu (talk) 11:41, 24 October 2024 (UTC)
Might be a good idea for community wishlist more than anything else. I don't think an edit filter is really the best way to go here. Even on a warn-only, it will be catching good-faith edits, and (temporarily) slowing down these contributions. This isn't to say this isn't a problem, just that edit filters may not be the best way to solve it. EggRoll97 (talk) 04:39, 25 October 2024 (UTC)
I see absolutely no good faith reason why someone might want to use an image inline. Aaron Liu (talk) 11:27, 25 October 2024 (UTC)
Technically a lot of the formulas in maths articles are inline images (see e.g. series (mathematics)). These are generated rather than transcluded, but it wouldn't surprise me if there is some edge case where an image is transcluded inline for a similar purpose. Thryduulf (talk) 11:39, 25 October 2024 (UTC)
Such cases where one can't use MathJAX are probably incredibly rare and less than the amount of times people inline on accident. Aaron Liu (talk) 11:53, 25 October 2024 (UTC)
There are certainly articles containing inline images for discussing symbols (which may not have straightforward Unicode character representations), e.g. rare historical letter glyphs or musical notation elements (see Archaic Greek alphabets or Mensural notation, to name just two that I happen to have worked on). Yes, I guess articles like these are few, but if an article requires them, it will require them numerous times. Fut.Perf. ☼ 11:59, 25 October 2024 (UTC)
We could whitelist, maybe Aaron Liu (talk) 12:02, 25 October 2024 (UTC)
I don't think that will be scalable, given the number of potential articles and the number of potential images. What might work would be something in the syntax to say "I am intentionally using this image inline" Thryduulf (talk) 12:05, 25 October 2024 (UTC)
It seems that inline images in tables are actually not that uncommon (see e.g. History of the alphabet, Glagolitic script#Characteristics and Playing card suits#Comparisons between suits) so whitelisting definitely wont work. Thryduulf (talk) 12:21, 25 October 2024 (UTC)
...could adding an extra, empty pipe work? We could have the regex abort if the relevant inline file embed ends in |]] Aaron Liu (talk) 19:54, 25 October 2024 (UTC)
From testing in my sandbox it seems to me that this would work in all cases where there isn't a caption being used as alt text (#10) as that removes the alt text. Glagolitic script#Characteristic uses captions in this manner.
However, when I tabulated the results (Special:Permalink/1253409176) any double pipes were interpreted as table syntax, even inside the file link, so broke things. Which makes things complicated. I'd also like to know if this breaks anything for users of screen readers.
An explicit inline=yes parameter (which AIUI would be ignored by the parser) might work, but I've run out of time to test that. Thryduulf (talk) 20:58, 25 October 2024 (UTC)
We could also do [[File:Slinky shrewsbury.jpg|inline|]] [[File:Slinky shrewsbury.jpg|inline|caption]] for case 1 (no caption) and case 2 (w/ caption). Regex would scan for |inline|. Aaron Liu (talk) 21:04, 25 October 2024 (UTC)
As long as that didn't get interpreted as alt text or otherwise confuse screen readers that might work. Thryduulf (talk) 21:09, 25 October 2024 (UTC)
Also, we'd need to make sure it doesn't conflict with any syntax-fixing bots (or humans). Thryduulf (talk) 21:10, 25 October 2024 (UTC)
Another thought is that we'd need to get VE to insert this parameter too, otherwise it would trigger the warning for the next person to edit the source, with the potential for confusion and lost edits. Thryduulf (talk) 01:19, 26 October 2024 (UTC)
My impression is that edit filters can be configured to only check paragraphs changed. Aaron Liu (talk) 18:06, 26 October 2024 (UTC)
(edit conflict) I agree with both those suppositions, but I don't know if there are other uses than maths articles. However my main point was that good faith reasons for using an inline image, however rare, almost certainly do exist and so there needs to be some provision for allowing them. Thryduulf (talk) 12:00, 25 October 2024 (UTC)
There are lots of templates that use inline images, so be careful. I general I would say, please don't make too many assumptions about how people should NOT use wikicode. People are for more inventive with the syntax than you expect :) —TheDJ (talk • contribs) 12:05, 25 October 2024 (UTC)
Yes, anything restricting inline images would have to apply only to the article (and draft?) namespace Thryduulf (talk) 12:06, 25 October 2024 (UTC)
It's used in a lot of tables, especially for Wikipedia:Featured lists. See List of Mercedes-EQ vehicles and List of masters of Trinity College, Cambridge as recent examples in TFL. WhatamIdoing (talk) 00:33, 26 October 2024 (UTC)
Thanks for the examples. However, I think we all should refocus the conversation onto the |inline| override idea proposed above. With the override idea, editors adding new inline images can see how to stop the message from popping up again and go on on their merry way. Aaron Liu (talk) 00:52, 26 October 2024 (UTC)
While I agree with @Aaron Liu in thinking this particular issue seems specific to people working in wikitext and, as a result, out of scope for Edit Check, thank you @Sdkb for making the connection between this request and Edit Check!
What you're modeling here – thinking about how a policy/convention could be programmed into editing experiences – is precisely the kind of practice we're intending Edit Check to inspire.
I hope you all will continue pinging me as ideas of this sort surface... PPelberg (WMF) (talk) 19:47, 25 October 2024 (UTC)
I like and support this idea for that very example you state (geez that was a big image). My one concern related to the warning message encouraging the usage of these parameters, however, is that it needs to be very clear upfront that |frame, |frameless, and |thumb may NOT be used in any combination together since these three are contradictory parameters. When these conflicting parameters do appear together on a single image, it triggers a Bogus/Invalid Image Option syntax error, a Wikipedia tracked error that sprouts a dozen or so new cases daily. I and another editor teamed up this summer and finally eliminated the existing backlog of the 7000+ cases of active Invalid Image Options, and is one of a few error types our little community has caught up with and are keeping mowed down so that it doesn't resprout and grow wild again. My main concern is that if Wikipedia is not clear up front that these cannot be used together, people might think to there is no issue in just adding all the options and being done with it, (a "Heck with it all" reaction) leading to a higher rate of repopulation of this error type. Would stating use only one (to discourage combinations) be effective, or might a second/subcheck message be reasonable on (re)submission in these cases? Zinnober9 (talk) 05:53, 28 October 2024 (UTC)
A proposed override for the edit filter above is introducing multiple captions, which is also a linter error. Do you know if there's a way to configure the linter extension so that the override is an exception? Aaron Liu (talk) 12:52, 28 October 2024 (UTC)
That is well beyond my knowledge. Jonesey95 knows more than I do, they might know, but I'd suspect that's more of a question for WMF. If multiple captions were introduced, I'm concerned with how that would work and how are the controls for determining which caption displays. I think the current WP:EIS syntax is fairly straight forward, and people make all sorts of unintended messes with it now. Zinnober9 (talk) 15:50, 28 October 2024 (UTC)

If multiple captions were introduced, I'm concerned with how that would work and how are the controls for determining which caption displays.

The software currently handles this well: by always only displaying the last caption, as you've probably seen at Thryduulf's sandbox. Aaron Liu (talk) 16:58, 28 October 2024 (UTC)
I have, as that's how I learned about this discussion. (see discussion User talk:Thryduulf#Image syntax). Multiple captions, while "handled" in the way you expect, are not error-free syntax in current WP:EIS code, and Thryduulf's current sandbox example has four cases demonstrating multiple captions, which are each causing invalid image errors (Lint report page) (cases 10 and 16, 11 and 17). These reported errors from the EIS syntax usage are the objection I have have in regards to this proposal. 22:11, 1 November 2024 (UTC) Zinnober9 (talk) 22:11, 1 November 2024 (UTC)
Yeah, I understand. Would you have any objections if only adding "|inline|" before another caption would not trigger a linter error? Aaron Liu (talk) 22:23, 1 November 2024 (UTC)

I'm coming to this discussion late, so forgive me if I misunderstand. I read through it twice, and I don't get it. The proposal is to stop people from inserting File:/Image: calls unless they have thumb or frameless? If that is the proposal, I don't see how it is reasonable. People insert such images all the time and have done so for decades, and things are generally fine. I did a semi-random search for insource:/\[\[File:/ -insource:/thumb/, and I got List of world sports championships, Nephrozoa, Filozoa, Countries of the United Kingdom, Papua New Guinea at the 2015 Pacific Games, PubChem, and more than 100,000 other pages that do not appear to be causing any trouble. I think there may be an XY problem here. – Jonesey95 (talk) 15:31, 28 October 2024 (UTC)

Not stop completely, give a warning for new additions through an edit filter that won't stop them if they save a second time or include some kind of override. Aaron Liu (talk) 16:54, 28 October 2024 (UTC)
But why stop or warn at all for a completely valid usage that appears in more than 100,000 pages without a problem? What is wrong, for example, with the image used in the infobox at PubChem, which is not an inline image and does not use thumb or frameless? What is wrong with the image used at Short story, which uses neither thumb nor frameless and is not inline? What is wrong with the map images at Political divisions of Bosnia and Herzegovina, which use neither thumb nor frameless and are not inline? These are just three easily accessible examples from well over 100,000 pages. – Jonesey95 (talk) 03:45, 2 November 2024 (UTC)
In the PubChem case, I'm not sure if the image was correctly added, as from what I recall the file name should be given directly as a parameter in infoboxes. However, basically every article with a phylogenetic tree, a series template, or a list of countries with flagicons would be affected, which isn't great. Chaotic Enby (talk · contribs) 04:22, 2 November 2024 (UTC)
Would this stop occur when someone adds a template using {{ambox}} or a similar message box to a page? Those templates use images that are not inline, frameless, or thumbnails. I think this idea may need a significant re-think. – Jonesey95 (talk) 04:39, 2 November 2024 (UTC)
Looking back the original issue was accidentally transcluding very large (in terms of dimensions) images at full size, which is an issue, but one that is very significantly narrower in scope than the proposed solution would address (and I agree that is not practical). Adding a warning only when the image exceeds say 2000px wide or 1200px high (larger than standard 1080p resolution) is unlikely to inconvenience many pages. My gut feeling though is that this would need to be done in software as whatever generates the warning would to get image dimensions from Commons as part of the parsing of the wikitext. Thryduulf (talk) 04:49, 2 November 2024 (UTC)
On second thoughts maybe only the width criterion is needed, as something long and thin will just vertically scroll without too much disruption? Most very wide images should probably be using {{wide image}} or thumb. Thryduulf (talk) 04:52, 2 November 2024 (UTC)
That could work, but, if we wish to tackle the narrow issue of wide images, I am not sure whether an edit filter alone would work. As far as I know, regex can't go in the file page and check its metadata? (Or maybe the edit filters have more capabilities I don't know about) Chaotic Enby (talk · contribs) 15:24, 2 November 2024 (UTC)
I don't know enough about edit filters to be certain, but I agree it is unlikely it is something they can do. Thryduulf (talk) 15:42, 2 November 2024 (UTC)
As you've said, that would require quite a bit more work than an edit filter. The issue is also that valid new usages of inline images without a template are quite little. Aaron Liu (talk) 17:05, 2 November 2024 (UTC)
The issue is also that valid new usages of inline images without a template are quite little. Are you sure about that? There are lots of examples noted in just this thread? How often are problematic (i.e. extremely large) images added inline accidentally? Unless it is significantly more than valid uses of inline images then it's not going to be worth it. Thryduulf (talk) 17:11, 2 November 2024 (UTC)
How often are valid images added inline? Anecdotally, it happens quite occasionally enough. In fact, its usage at NCAA Division III—one of the results on the first page of search—was a mistake that had been there for 4 years before I fixed it today.
I was preparing a paragraph that evaluated the first page of the search results when I realized that I can't find any guidelines on using non-small inline images instead of frameless images within infoboxes and tables, therefore, half of my basis for this proposal may be incorrect. Aaron Liu (talk) 18:09, 2 November 2024 (UTC)
For the short story case, could you explain which image? If your concern is the sidebar, I'm pretty sure we can exclude the template namespace, which also tends to have arcane wizardry.
(Also, the edit filter would not warn just for existing usages. It would only warn on additions and new usages that don't use some e.g.  Liechtenstein flag template (it only detects the relevant wikitext)) Aaron Liu (talk) 17:02, 2 November 2024 (UTC)

New vandalism abuse filter

Should we add an abuse filter that blocks the string "peepeepoopoo" and variations such as adding spaces, this is guaranteed vandalism, see these edits TheWikipede (talk) 22:34, 5 November 2024 (UTC)

This was apparently requested in 2020 at Wikipedia:Edit filter/Requested/Archive 16#Peepee poopoo and variants, although it received no responses. Possible issues include the existence of PooPoo PeePee Tour, and the fact that "peepeepoopoo" has historically often been used as "example" vandalism in project discussions. Chaotic Enby (talk · contribs) 22:48, 5 November 2024 (UTC)
There is a dedicated page for edit filter requests, Wikipedia:Edit filter/Requested (WP:EFR), where the people most knowledgeable about relevant considerations and any previous requests/discussions are most likely so see it. Thryduulf (talk) 22:55, 5 November 2024 (UTC)
Filter 46 (hist · log) ("Poop" vandalism") already exists. WP:EFN is probably a better place to post about this. C F A 💬 23:48, 5 November 2024 (UTC)

Censor NSFW/ NSFL content

A perennial proposal which has not a snowball's chance of being implemented due to clear policy and technology limitations. CaptainEek Edits Ho Cap'n!⚓ 06:21, 7 November 2024 (UTC)

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Okay, to make this clear, The content should NOT be taken down. NSFW and NSFl content needs to be shown because Wikipedia is a censor free website. No content should be treated over the other and NSFW and NSFL content needs to be treated the same as all the others. Now the proposal I will make is that since a lot of kids use Wikipedia to learn stuff and they may come across these things. For the sake of safety, gory, offensive and sexual content should have a blur or a black screen, and in order to view the image, they have to click the image and click I am over 18 or something like for example, they come across the Russo-Ukrainian war. In this article there is a gory picture. What there should be instead is a blur or a black box, the description of the picture still stays, and in order to view the content they have to press the picture, and it will ask for verification, like when you press the picture it says, this picture has gore in it or something like that, then it says you have to be 18 to view the image or something like that, then there is a button saying I am over 18 or something like that, then to view the content just press the button. If this somehow doesn’t work at least have a disclaimer at the top saying there is bad stuff in it. So yeah, here is my suggestion. Datawikiperson (talk) 11:11, 6 November 2024 (UTC)

As a start let me link you to: WP:NOTCENSORED and Wikipedia:Offensive material. And here's a way to help not seeing stuff: Help:Options to hide an image. Lectonar (talk) 11:19, 6 November 2024 (UTC)
What makes you think kids would not lie and just click "I'm 18"? Also see Striesand effect. 331dot (talk) 14:23, 6 November 2024 (UTC)

This has been proposed many times previously. It has failed for multiple reasons, including what should be censored being highly context and culturally (and even subculturally) dependent - for example person A might wish to blur a photograph of a woman breastfeeding but not a photograph of a gunshot wound, while person B might wish the exact opposite. If you take the view that anything anybody wants to be blurred should be blurred, even if others do not, but that would lead to extremes like all images of people being blurred. A second reason is that there is no practical reason to apply the setting en-masse. At first glance, images in Commons:Category:Sex and subcategories would seem to be fairly uncontroversial, but that falls apart very quickly when you see what sort of images that would catch, for example:

So it would have be to set for at least each category, without subcategories, and there are at least thousands of them on Commons. At the individual image level you are looking at over 110 million. And that's assuming you can get agreement (per above). Thryduulf (talk) 11:57, 6 November 2024 (UTC)

I agree with what Lectonar and Thryduulf have said above. If this was implemented it would (since most of our editors are American) be as a very Americo-centric view of what is not safe - it would be Thryduulf's person A's view, not mine. The only way to guarantee safety is to block all images using one of the approaches on the page mentioned by Lectonar, Phil Bridger (talk) 13:17, 6 November 2024 (UTC)
People have created mirrors like Hamichlol, that is an option for those who want. Gråbergs Gråa Sång (talk) 14:43, 6 November 2024 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

"Wikipedia:Redirect sandbox"

A sandbox for testing redirects, which redirects to Wikipedia:Sandbox and has a sandbox notice when you click for more information about that sandbox. It can be redirected anywhere and is automatically reverted like all other sandboxes.

I propose this because we are not allowed to redirect the sandbox, not even what redirects there, so i was obligated to propose something like this. 67.209.128.161 (talk) 08:28, 8 November 2024 (UTC)

What is there to test that this would be good for? If you make a mistake while creating a redirect, you can just fix it. Remsense ‥ 论 08:42, 8 November 2024 (UTC)
Additionally, if you create an account you can experiment with redirects in your userspace as much as you want. Thryduulf (talk) 11:10, 8 November 2024 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(proposals)/Archive_214&oldid=1257990479"