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.
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)
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)
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."
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.
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.
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)
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)
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)
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?
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)
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(tc)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(tc)01:51, 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.
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(tc)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. Sdkbtalk03: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)
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:
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(tc)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 Albury12: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(tc)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)
"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):
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. — xaosfluxTalk07: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.
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. — xaosfluxTalk14: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(tc)09:29, 14 September 2024 (UTC)
"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.
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)
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)
Summary and count. Pageviews link
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:
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, Rosguilltalk16:27, 21 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)
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.)
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)
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).Sdkbtalk07: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.
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)
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! — xaosfluxTalk14: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? — xaosfluxTalk14:12, 1 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)
@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. — xaosfluxTalk22: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. — xaosfluxTalk22: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
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.
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. — xaosfluxTalk20: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.
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.
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)
These may be localized by changing these interface messages. However, if we don't have it reported to the page it is being reported to on mediawikiwiki, we should not expect that the software developers and project team will monitor the reports. — xaosfluxTalk23:28, 5 October 2024 (UTC)
^ This. Think about whether it's more important to you to have the page structured your way, or more important to have the dev team look at the feedback. Tradeoffs are a fact of life. It's IMO likely that they'd appreciate some improvements to the format, but it's also possible that this is what works best for them (e.g., perhaps omitting sigs solves them a privacy hassle if they import the feedback to a different system? I doubt it, but Chesterton's fence suggests that we shouldn't assume that there is no reason for the unusual format). WhatamIdoing (talk) 00:48, 6 October 2024 (UTC)
@Xaosflux: I don't think the software team has looked at any of the reports in a while anyway. It looks to be mostly left up to the community. They did some at the start of the dark mode beta, but as the most important features were taken care of, the more minor templates and pages were left to the community. —Matrix(!) {user - talk? - uselesscontributions} 09:35, 6 October 2024 (UTC)
I agree that the reports from all the wikis should end up in one centralised place so the developers only have to look at one wiki, but I'm not so sure about the status icons. Developers have to be able to read English to make sense of the reports, so can't their status be in English too? Phil Bridger (talk) 11:07, 6 October 2024 (UTC)
Dark mode isn't just for English Wikipedia, so archiving the page on the Mediawiki wiki and making the communities of all other wikis come to English Wikipedia to make reports isn't ideal. isaacl (talk) 01:37, 6 October 2024 (UTC)
@Isaacl if we changed the report link here, it would only be for users of enwiki - anyone on the hundreds of other projects would still go to mediawikiwiki unless their project also overrode the default. — xaosfluxTalk02:33, 6 October 2024 (UTC)
That's really secondary, but sure if these go somewhere else those could be copied over and a note could just be left there. — xaosfluxTalk11:44, 6 October 2024 (UTC)
Thanks for the clarification. I do agree with the others who have expressed a preference for a centralized location for error reporting. isaacl (talk) 16:33, 6 October 2024 (UTC)
I'm reminded of the early visual editor rollout where there were some editors (including at least one WMF employee) spent some considerable time and effort translating user reports left on a page on en.wp into phabricator tickets, often after more testing to verify reports and give details more useful to developers. I'm not involved in the dark mode at all (and I don't personally use it) but if there are volunteers to do something similar then giving people the option of reporting locally with those reports being copied over might work. Thryduulf (talk) 17:12, 6 October 2024 (UTC)
This is a fundamentally different situation in that, while any Visual Editor issues would generally manifest everywhere, no matter which installation reported the problem, with dark-mode issues the overwhelming majority of cases are addressed by making local content changes (to a specific article or template). A vanishingly small percentage of the reported problems are in any way generalizable beyond the immediate context of the initial report. (So, I agree, it's a bit odd to exfiltrate the reports to a different wiki in the first place; issues with local content — which these are — need to be, and ultimately will end up being, handled locally.) FeRDNYC (talk) 20:38, 6 October 2024 (UTC)
Hey everyone - wanted to a give a quick reply from the team's perspective. In short - this is totally up to whatever the community finds easier/more comfortable. We had initially set up the system to be more centralized as we did not want to presume which local page each wiki would find more comfortable. That said, we have no concerns with wikis making the change to a local page if preferred, and a few wikis have so far chosen to do this with good results. Some more information on how to do this is available at the top of our general reporting page. Hope this is helpful! OVasileva (WMF) (talk) 19:47, 8 October 2024 (UTC)
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:
Support as proposer: Most of the people actually tackling dark mode issues aren't WMF developers now, but volunteers. Dark mode issues are a local issue per FeRDNYC and therefore should be handled locally on this wiki for best results. We can also change the system to something better in the process (including signatures, using archive templates instead of emojis, etc.). —Matrix(!)ping onewhen replying {user - talk? - uselesscontributions} 16:28, 9 October 2024 (UTC)
@Pppery: It is broken though - the page has no archiving, there are no signatures so replying is slow, the current emoji system for responding to issues is substandard, and it's hidden in an obscure location so no one can find it to help fix issues. Also, since there are no signatures, it's a nightmare chasing people to get further details of issues. What part of that isn't broken? —Matrix(!)ping onewhen replying {user - talk? - uselesscontributions} 11:35, 13 October 2024 (UTC)
Just because issues are getting fixed, doesn't mean it's happening efficiently. The current system is very inefficient, even if issues are getting fixed. It is still creating lots of friction preventing new users from fixing issues. —Matrix(!)ping onewhen replying {user - talk? - uselesscontributions} 18:19, 17 October 2024 (UTC)
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:
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).
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. — xaosfluxTalk11:43, 13 October 2024 (UTC)
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)
Yes. Also, there is a broader need to distinguish better between AWB GENFIX tasks that are cosmetic and those worth triggering anytime. Sdkbtalk12:37, 22 October 2024 (UTC)
@Thryduulf I have posted this here to gain some consensus about my proposal. Also, as some might see me, I can be considered a not ready to be a bot op. I personally think I am capable, but please place your opinions.
@Sdkb I plan to enable Skip if only cosmetic in AWB, so as to skip any edits which are only cosmetic as the ref list has been added, but CheckWiki reports it as not fixed. Bunnypranav (talk) 13:07, 22 October 2024 (UTC)
I looked through some of his contribs, to see if there was a significant risk that "missing reflist" meant "vandal blanking the bottom half of the article", and I found no evidence of that. What I mostly found was newer editors adding the first Wikipedia:Inline citation to those articles. It's rather encouraging to see, actually. WhatamIdoing (talk) 17:40, 23 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)
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!
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 Sidewaysfrom this world ..... today00:15, 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. — xaosfluxTalk13: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 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.
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! Sdkbtalk04: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 Albury13: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 Albury14: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):
[From 2000] The racial makeup of the city was 95.67% White, 3.29% Native American, 0.17% from other races, and 0.87% from two or more races.
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.
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.
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.
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.
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).
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:
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.
Many people would try out their new permissions, but most would drop out.
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).
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 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)
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. — xaosfluxTalk13:53, 17 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.
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 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)
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.
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)
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.
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. Sdkbtalk02:24, 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)
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)
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)
...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)
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)
(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)
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)
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 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)
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)
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)
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)
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.
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)
The cliche is “Size doesn’t matter," but it does in many things — paintings, sculptures, jewelry, crystals, anything larger or small than usual and even if it’s the usual size if readers don’t know what that it. It makes a difference if a painting is 2” by 3” or 2’ by 3’. Especially in TPOD, because more people will see it, but really everywhere. I suggest that writers be encouraged to provide the relevant size in the text or caption of every photo where it’s necessary and that the editors working on TPOD be strongly encouraged to give the size whenever possible. If the size is not given in the text being referenced, that information is often in the photo's "details," in addition to the editing history. Wis2fan (talk) 04:51, 9 November 2024 (UTC)
Firstly, excuse my ignorance, but what is TPOD? Secondly, I don't see any clear proposal here. Yes, size is often important, but what do you think we should do about it? We can cajole editors into providing size, but we shouldn't reject images without it. Phil Bridger (talk) 13:48, 9 November 2024 (UTC)
Sorry I got the abbreviation wrong — POTD. Today’s (11/10/2024) POTD is an example of what I’m talking about. The reader knows a bark beetle is tiny, but why not give the actual size? It’s not that the information isn’t available. I clicked on the photo, then on "details." The description of the photo says the adult male is 4.0 mm to 5.5 mm long. I came back to the post and clicked on the name. The linked article includes the same information. The information is there this time. I agree, it’s not always either place. But when it is, it should be provided to be complete. Wis2fan (talk) 04:54, 10 November 2024 (UTC)
A picture caption is finite, it does not need to (and indeed in most cases cannot) include every detail about an image and its subject. Therefore it should only include information that is most relevant, and that will not always include the size. For example the POTD for 8 November was an 1860 photograph of John Tarleton (Royal Navy officer), is the size of the print really the most relevant information or is it the size of the subject what you want to know? It's fine to encourage people to put the size of the image and/or subject in the caption where that is relevant, but it is not always going to be, so a one-size-fits all rule is not going to be appropriate. If you want to know, just look at the extra details. Thryduulf (talk) 14:37, 10 November 2024 (UTC)
Thryduulf is absolutely correct, the size of the object in a photo is unimportant when it is a human. The size isn’t necessary for today’s POTD (11/11/2024). But I still think it is important when it is a bark beatle. And many other things. I also think that a writer should anticipate a reader’s questions and provide the answers. Suggesting that if a reader wants the size of an object they should look at the extra details is not helpful. I’d bet most readers don’t know how to find them. Wis2fan (talk) 04:29, 11 November 2024 (UTC)
I vaguely remember I suggested something similar at commons once, requesting that more people who post photos consider including a scale-bar if it's the sort of subject that would benefit from one (biological specimens, museum artefacts whose size is likely to be unclear to a general reader). I think I got shot down in flames for general naivete. My opinion is: In any situation where a reference book would use a scale bar, or indicate prominently by caption or other means, the size of an illustrated object, we should do the same, so far as we can. This would probably include articles about most species (birds, insects etc.) and articles about things where the size is central to the article (an article on miniaturisation of transistors, for example, should show the size of the transistors in its photos). Elemimele (talk) 13:52, 12 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.
I propose that extended confirmed users should be allowed to get users from the IP address that they are currently logged onto because to see and disclose on Template:User shared IP address. Extended confirmed users are trusted (30 days and 500 edits) and the CheckUsers can see the log to see who's outing. 1.144.109.84 (talk) 21:08, 15 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.
Artist collective infobox
Hello! I have made an infobox for artist collectives (inspired by my own frustration trying to use the regular artist one for graffiti crews) and would like feedback from the community before publishing it. The old infobox proposal page is now defunct and suggests posting here instead.
Personally, I'd much rather not see this, or anything like it, used. Almost everything in it will be disputable or disputed, or is really vague. It seems a classic example of where an infobox is just unhelpful clutter, and will displace or make too small an image that would be more helpful. Are you asking at the VA project, & if not, why not? It's not really for here. Johnbod (talk) 05:03, 12 November 2024 (UTC)
I think we should have infoboxes for rituals and cultural practices, as studied in anthropology and religious studies. Parameters like associated culture, associated religion, purpose, origin, place, whether or not it is extinct, and when it is observed could be included. Examples of articles that could benefit are Akazehe, Savika, Sikidy, Haka, Bar Mitzvah, Quinceañera, Nggàm, and Hajj. ꧁Zanahary꧂19:17, 14 November 2024 (UTC)
I agree, there’s not really enough fields they’d have in common. Although I personally believe that every article that has an applicable infobox should use it, there’s also many articles that work best without them. novovtalkedits10:38, 15 November 2024 (UTC)
Yes, infoboxes work best when there are a number of basic uncontroversial factual characteristics that are shared by a group of articles. That's very far from the case here. Johnbod (talk) 14:06, 15 November 2024 (UTC)
Johnbod said it well. To that I would add info that easily reduces to a short factoid. North8000 (talk) 14:11, 15 November 2024 (UTC)
Unless it's been changed recently, we don't have a policy that infoboxes have to exist on any page, so I don't think we can put into policy for a specific subset. Lee Vilenski(talk • contribs)13:38, 16 November 2024 (UTC)
@Lee Vilenski Even the most diehard of infobox supporters recognise that infoboxes don't work on every page (broad, abstract concepts like Love and Existence for example) and that is one reason why we don't have (and never will have) any requirement for every article to have an infobox. That doesn't in any way preclude setting a policy that specific subsets of articles where they are uncontroversially useful (e.g. countries and NFL teams) must have an infobox if we wanted to. Some of the types of articles mentioned could have useful infoboxes (Hajj already does for example) not all of them can, so the OP's suggestion would not be a good set for such a policy, but that's not an argument against any set being appropriate. Thryduulf (talk) 20:58, 16 November 2024 (UTC)
A recent attempt to impose an all-infobox policy failed emphatically, reinforcing the long-standing position the they are not compulsory. And in many areas, the approach using a specific template will not be suitable, for the reasons I gave above. If many "helpful" editors see a template with blank fields, they will attempt to fill them, regardless of appropriateness. Johnbod (talk) 17:22, 17 November 2024 (UTC)
In re "editors see a template with blank fields, they will attempt to fill them": I think I see less of that these days than I used to. I'm not sure why (infoboxes are less empty? Fewer stray fields are listed? The visual editor hides the 'missing' lines from new editors? I dunno, but it's been a long while since I noticed someone filling in all the blanks on any article in my watchlist.) WhatamIdoing (talk) 00:43, 18 November 2024 (UTC)
Possibly. Or even if they're not filled in the wikitext, I think there's a certain amount of content that feels "normal", and if it displays some low but still normal-ish amount when reading, then people don't think that something's missing, so they don't try to "improve" it. WhatamIdoing (talk) 01:48, 18 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.
Re-instating this proposal, I want to make the icons look more clear and sleek; I will eventually add on more to the icons (such as good articles, audio articles, etc.) I also want to add region-based letter shackles, so for example 拡 (拡張, Kakuchō) would be the Japanese extended-protection icon, same with 満 (満杯, Manpai) for full-protection.
Agree with others that these new icons look dated. However, if we are discussing changes to lock icons, then I must say the the purple for upload protected is incongruously gaudy. Cremastra — talk — c20:23, 17 October 2024 (UTC)
Oppose. I think the gradients or bevels make these icons less clear and sleek, at least in their current iteration. The icons also become less readable at smaller resolutions since the shackle part of the padlocks takes up more space, making the actual symbol inside smaller.
Pretty strong oppose trying to run a geolocation script on every load to try to make dynamic labels here. If anything (which I also don't like) labels should follow user interface language. — xaosfluxTalk17:39, 16 October 2024 (UTC)
I understand the differences, I was just suggesting (because I don't really speak any other language you could propose a specific version) Also, I will later add the letters on the shackles.
Oppose making the primary (only) differentiation be color, as that gives out less information then the current scheme and is useless for those without color viewing abilities. — xaosfluxTalk17:41, 16 October 2024 (UTC)
Agree with Xaosflux on this one. Furthermore, the two issues of the old icon scheme (color and "realistic" shading that doesn't look great on small icons), which were the reasons for the change to begin with, are present on this one too.Regarding the region-based symbols, it would make more sense to display them based on the language edition, and, since each language edition already sets its own standards for this stuff, there isn't much more we can do. Chaotic Enby (talk · contribs) 18:13, 16 October 2024 (UTC)
Agree, but only slightly. If you added the letters, it would be better. Also, a solution to your region-basing could be to do a Language-based (like "O" for "Office" would become "S" for "Schoolhouse" in a theoretical "Reversed English") The Master of Hedgehogs(converse)(hedgehogs)14:33, 17 October 2024 (UTC)
I thought we were using "shackle" as the word to describe a thing by a single aspect for the purposes of avoiding conflation with protecting/locking editing. Aaron Liu (talk) 18:13, 2 November 2024 (UTC)
Well, we shouldn't, because as @WhatamIdoing noted, the shackle is one part of a padlock. And simply using the word "padlock" avoids conflation, without calling things the wrong thing. (It's even the exact same number of letters.) FeRDNYC (talk) 03:55, 3 November 2024 (UTC)
Per WP:WIKICLICHE we've been asked to not say this quite as much, due to supply chain issues – if we use them too much we could see a huge shortage down the road. But I hope I'm not generating more heat than light with this comment, or throwing the baby out with the bathwater. Cremastra — talk — c20:22, 17 October 2024 (UTC)
Never throw the baby out with the bathwater. This will contaminate your greywater collection system. Like other meats, babies are not compostable, so they should be sorted into the landfill waste stream unless otherwise advised by your municipal waste management authority. Folly Mox (talk) Folly Mox (talk) 20:46, 17 October 2024 (UTC)
The pseudo-3D shading looks dated compared to the current flat icons. Most modern design systems (including codex, which is the new design system for Wikimedia wikis) are built around flat icons. --Ahecht (TALK PAGE)18:36, 17 October 2024 (UTC)
Just for funStill feel like a step backwards. The current "Good article" icon, on top of having less of a distracting shading and being more readable, is in a consistent style with a lot of our other icons. The current "Featured article" icon, although not consistent with the others, is pretty unique and recognizable in design, while this one looks like a generic star.Just for fun, I did once make a "Good article" star in the style of the FA one – not meant for any official implementation beyond my personal script of course, but it's neat to see how it would look like. Chaotic Enby (talk · contribs) 22:14, 17 October 2024 (UTC)
Have you ever looked at the Featured Article icon, full-size? (If not, check it out at File:Cscr-featured.png. I'll wait.) ...Like or lump @Chaotic Enby's GA star, it's actually of a fairly harmonious style with the current FA star, which is (as noted) currently not consistent with anything else anywhere. Arguably it's well-known/recognizable — Chaotic makes that argument, anyway — but TBH I have a feeling the great majority of readers never see it larger than head-of-a-pin-scaled, and wouldn't even recognize the actual, full-sized image AS our FA icon. FeRDNYC (talk) 04:10, 3 November 2024 (UTC)
I have seen the full FA icon; the GA star is just straight out of Cthulhu (...positively). It is fun, but I think GA should be more inline with the rest of the article-rating icons because of the kinda lesser rigor. Aaron Liu (talk) 13:26, 3 November 2024 (UTC)
To be fair, it's definitely a concept design rather than an actual proposal. If anything, I far prefer having the current GA icon as our official one, as it is more harmonious with basically anything that isn't the FA star. Chaotic Enby (talk · contribs) 22:18, 4 November 2024 (UTC)
These are not visual improvements whatsoever, unfortunately. They are clear regressions in design, and the current icons are fine. Our system is particular to the English Wikipedia, so it's perfectly appropriate for their design to be relative to the English language.Remsense ‥ 论19:29, 17 October 2024 (UTC)
Color me baffled. By starting with Re-instating this proposal, you make me think you want to reinvigorate some failed proposal. But then I follow your link and see that the proposal led to the implementation of new padlock icons, which; I guess, you mean to reverse. I also fail to understand what you mean by region-based letter shackles; do you mean for articles about, e.g., Japan? Or articles viewed by somebody we're supposed to have guessed might be in Japan? Or somebody with the Japanese language listed in a userbox on their User page? It's English Wikipedia, so I can't see the last two being useful options, and the first one will only lead to arguments and confusion and we've got that already. The current icons seem clear enough to me, although I don't know how to measure "sleek", I guess. In summary: baffled. — JohnFromPinckney (talk / edits)12:15, 18 October 2024 (UTC)
I mean region-based letter shackles basically like the letters on shackles but different regional translations. (This'll probably not work because of @Chaotic Enby's post.)
So (just to see if I understand it finally), you're proposing on English Wikipedia that Japanese Wikipedia use icons with Japanese symbology, and Spanish Wikipedia use some Spanish-language indicator on the padlock, etc. Yes? — JohnFromPinckney (talk / edits)22:30, 18 October 2024 (UTC)
Oppose for now. Status quo is fine. It's really cool that you're contributing your graphics skills to the movement though. I'm sure there's some less high profile areas that could really benefit from your skills. –Novem Linguae (talk) 03:55, 23 October 2024 (UTC)
Oppose: New proposals are nice but I personally like the style of the old ones better, and flat icons also seem more up-to-date to me. Regional shackles sound like a good idea, but don't appear to be in this proposal, so I'll just say I support those (maybe in the old design-style in my preference). Mrfoogles (talk) 20:22, 23 October 2024 (UTC)
Oppose per Remsense. The new 3D icons look like something from the early days of the internet. Plus the shadowing makes the icons appear unnecessarily "bulky" (not sure how to say this). Nythar (💬-🍀) 22:33, 25 October 2024 (UTC)
Oppose here as well. It's not about status quo or resistance to change, I vastly prefer the current icons to the proposed replacements. (Admittedly subjective) points in favor of the current icons over the new ones:
The flatter look will render better at small sizes (since these icons are actually shown at a fraction of the size they're displayed in this thread)
Ditto the blockier font
Ditto the thicker shackle arcs
The skinny shackles and rectangular body give the proposed replacements the appearance of handbags, not padlocks
The letter placement is more uniform and precise in the current icons; the proposed replacements appear to have been "eyeballed". IMHO SVG art of this sort is best hand-coded (if not from scratch, then at least as a finalization pass to clean up the code), with all of the dimensions precise and uniform.
I appreciate the effort, and I'm sorry to be critical, but I'm just not into them at all. The current set, OTOH, are actually fairly well-designed and optimized for their purpose, which is an important consideration in designing functional artwork of this sort. It's puzzling to me that anyone would be looking to replace them, as there's surprisingly little room for improvement IMHO. FeRDNYC (talk) 13:19, 26 October 2024 (UTC)
I think the proposed sets may been cool at the time of the previous proposal. Those locks would be more appropriate for something like in 2008. It's for the same reason why traffic lights are always (from top to bottom) red yellow green. And why train doors on British trains need doors to have sufficient contrast to the rest (see PRM TSI). In other words, using colour alone for distinguishing isn't enough.
Oppose - not a fan of the proposed icons (see also Nythar's comment), and the current locks work quite well. however, I would be supportive of a redesign of the GA/FA icons (/the various icons of the same style) in a style similar to the current locks. Rexo (talk | contributions) 20:30, 29 October 2024 (UTC)
What if we kept the shackles and good icon, get a new featured icon, and make a built-in feature that allows shackles to be compatible with dark mode? 2I3I3 (talk) 03:07, 2 November 2024 (UTC)
That's still not a shackle. (And, to Rexo, I don't see why quality article symbols should imply protection and locked editing.) Aaron Liu (talk) 17:07, 2 November 2024 (UTC)
(to clarify: the style used by a lot of icons across the wiki (including FA/GA) feels dated, and the locks have a cleaner look that I think could be used as a basis for further redesigns. I don't think that would inherently lead to the quality symbols implying protection.) Rexo (talk | contributions) 13:54, 4 November 2024 (UTC)
I don't think the Norro or FA icons are dated, and using padlocks to indicate quality just makes no semantic sense. We adopted padlocks because it showed that the article was locked from editing. Aaron Liu (talk) 14:07, 4 November 2024 (UTC)
@Aaron Liu I don't think Rexo means using actual padlocks; I think she means developing a flatter design inspired by and similar to our protection icons. Cremastra (u — c) 20:56, 4 November 2024 (UTC)
I'm confused - the locks look fine to me on (Vector 2022's) dark mode? the Office one's background is a bit hard to see, but the rest look fine to me. Rexo (talk | contributions) 13:56, 4 November 2024 (UTC)
Just so we're all on the same page, terminology-wise:
Our article Shackle says "A shackle is also the similarly shaped piece of metal used with a locking mechanism in padlocks.[1]". Some here seem confused, but anyone using "shackle" to refer to the handle part of the handbag-looking icon is correct. Anomie⚔21:18, 2 November 2024 (UTC)
\o/ I'm technically correct, "The best kind of correct!" (You might be surprised how infrequently that happens, sadly.) FeRDNYC (talk) 03:43, 3 November 2024 (UTC)
I've updated the section heading to not be confusing (except, I guess, to one person whose idiolect equates locks and shackles, which is rather like calling your door a "handle" or "knob". — SMcCandlish☏¢ 😼 21:21, 15 November 2024 (UTC)
Ah yes, because when people want to cause trouble on Wikipedia, they immediately think "I'm going to change the wikipedia article for Shackles so that anyone who wants to know anything about them will be confused! Archer87643 (talk) 00:27, 20 November 2024 (UTC)
Oppose. While I personally favor skeuomorphism in electronic interface design and am not fan of the last decade or so's fashion for making everything flat and same-looking, we cannot sensibly re-inject a cluster of skeuomorphic design elements and leave the rest anti-skeuomorphic. Design and user-experience do not work like that. PS: The actually-named-a-shackle part of the lock depicted in the proposed new icons looks farcically thin and weak, like those on the pretend-security of luggage locks, so even if WP went with a skeuomorphic design (for everything) again, these icons in particular should not be used. — SMcCandlish☏¢ 😼 21:33, 15 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.
Require 2FA for bureaucrats
Heya, I noticed a couple of weeks ago that while interface administrators and central notice administrators need 2FA, bureaucrats, who can grant interface admin don't need 2FA. To me this seems a bit weird, because if you wanted to compromise an account with access to interface admin tools, bureaucrats may not all have 2FA. Hence, I'm proposing requiring all enwiki bureaucrats to enable 2FA as a precaution. Zippybonzo | talk | contribs (they/them) 09:24, 12 November 2024 (UTC)
I see non-restricted adjacent bugs T242553 and T242556 were both created on 12 Jan 2020. Would it be accurate to describe this as an evaluation which has been unresolved for about 5 years? -- zzuuzz(talk)13:58, 12 November 2024 (UTC)
Support per pppery and zippybonzo - should be a requirement locally. Waiting for phab tickets could take years while I imagine a RFC would pass pretty quickly. BugGhost🦗👻19:44, 12 November 2024 (UTC)
The fact that 'crats can assign interface admin (a role which requires 2FA) but are not required to have 2FA personally enabled is wild. Support a local rule (and hopefully the largest WMF project implementing such a rule will encourage others to make such a change). HouseBlaster (talk • he/they) 00:43, 15 November 2024 (UTC)
Definite support. I am personally in favor of a 2FA requirement for any privileged group, but it is something I doubt will happen anytime soon. Crats should absolutely have it enabled. EggRoll97(talk) 01:51, 15 November 2024 (UTC)
Question. How are you going to check whether the user enabled 2FA or not? This information is not public. Only WMF can confirm this. Ruslik_Zero20:02, 15 November 2024 (UTC)
Yes, stewards can check this, and we periodically audit this for compliance on projects. Also, 'crats will very likely soon be able to check this as well - just some paperwork in that way right now (primarily so they can check it before assigning intadmin to others). — xaosfluxTalk10:29, 16 November 2024 (UTC)
Oppose, because the last time I checked, WMF's self-developed version of 2FA was not really fit for purpose. It's not like they're using Duo or Google or something. If anything, I'd support removing it from the roles requiring it now. --Floquenbeam (talk) 20:16, 15 November 2024 (UTC)
It works OK, but is certainly not ready for large-scale deployment due to the support model and capacity. Staff is generally responsive to recovery requests for those that WMF requires enrollment though. — xaosfluxTalk10:30, 16 November 2024 (UTC)
Support in theory - I use 2FA as a crat. Makes all the sense to me. As Xaos says above it's not ideal how it's setup. If it was just a "should this user group use 2FA", then I think yes. And, I'd argue administrators should as well. I can't support the technical solution we currently have being rolled out further without more Dev time. Lee Vilenski(talk • contribs)13:37, 16 November 2024 (UTC)
Support now. This is an security oversight. Regardless of the issues with WMF's 2FA this is still a flaw in the current security model since an attacker could gain interface admin without bypassing 2FA Chess (talk) (please mention me on reply)00:44, 19 November 2024 (UTC)
Oppose per Floq, plus it's not clear how we're enforcing this: either we're revoking permissions (in which case several crats will lose the bit on inactivity alone) or we're not (in which case we're no more secure than before). A much better solution would be to just put the stewards in charge of adding/removing intadmin. Extraordinary Writ (talk) 06:13, 21 November 2024 (UTC)
I mean, I support implementing phab:T282624, which would make IA a steward-only thing. 2FA for interface admins is required by WMF, and only stewards can check whether the requirement is being followed. Letting 'crats check whether 2FA is enabled is stuck in phab purgatory, though there has been some movement in 2024. HouseBlaster (talk • he/they) 05:25, 22 November 2024 (UTC)
Proposal to change behavior of navigational tabs on redirects
Add AI translation option for translating from English to non-English article.
AI certainly improved a lot by now. It can translate to many non-english language better than traditional translators . My suggestion is to add AI translation option for translating from English to non-English article. User will review the AI translation to see if its correct. It will increase the translation quality. I dont suggest using AI for English article, that could have a devastating impact. Dark1618 (talk) 18:50, 7 November 2024 (UTC)
That's out of scope here, and would need to be asked on each and every individual language-edition of Wikipedia, as those would be the ones dictating policy for translations into their respective languages. —Jéské Courianov^_^vthreadscritiques19:10, 7 November 2024 (UTC)
Why would a translation into English be devastating, but a translation from English into any other language be acceptable? English just happens to be that most used language in the world by some measures: beyond that it has no special status. Anyway, we can not decide here what is appropriate for other language Wikipedias. Phil Bridger (talk) 19:33, 7 November 2024 (UTC)
Good Idea! That’s actually what I was going to propose but you took it. To add to your amazing proposal, I suggest that every wiki translation must be approved by a speaker. Like If someone translated an article from English to Arabic, the translated article goes to an Arab speaker, by algorithm when the person would press a button that says “send for approval” or something like that, and the Arab person who gets the translated article will read the Wikipedia page and look for any errors, then the Arab corrects it and it gets published to the world. And why can’t the opposite happen, when an article gets translated to say french To English the same thing happens the French person machine translates the article, it gets sent to approval, a fluent English speaker goes and corrects it, then it gets published. If it is an extinct language, a person who is a professional in the language will correct it, and as for rates, I mean Wikipedia has at least 1 person who knows the language. Anyway have a good day! Cheers! Datawikiperson (talk) 10:10, 10 November 2024 (UTC)
I'm not sure of the technical backend for that tool, but I do see at English Wikipedia a constant inflow of articles translated from sister projects, usually without proper attribution, sometimes with broken templates.Some of these translations are pretty good, up to idiomatic phrasing; others have the appearance of raw machine translation, with errors no one fluent in the target language would leave in.As to the original proposal / idea, a flow of machine translations from this project to sister Wikipediae, that is indeed out of scope here, and would have to be brought up individually at each language project. Except maybe Cebuano Wikipedia. Folly Mox (talk) 14:49, 10 November 2024 (UTC)
I occasionally translate from English to Chinese and vice versa, and take on some bits from Japanese and Korea projects to be translated on to here if the information and sources can be used on here. And I strongly discourage automated AI translations from English to other languages, which you are proposing, without further inputs from the targeted language projects. AI translations to other languages from English are not perfect and can have the same devastating impact you don't want to see on English Wikipedia. – robertsky (talk) 14:30, 11 November 2024 (UTC)
Machine translation from English to most other languages is already enabled (and where it isn't it is a choice of the to project, not of the English Wikipedia). I don't think there is anything for us to do about this proposal? — xaosfluxTalk10:33, 16 November 2024 (UTC)
Oppose see also WP:CXT. We should never be using AI to translate works; always humans. Yes AI is good, but just by the nature of how LLMs and neural networks work, they can't necessarily be better than humans. AI does not have any understanding of context, cultural norms, and so much more that humans do have, it just finds patterns in data to see what comes next. AwesomeAasim19:17, 23 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.
Yeah, why not; I didn't really see the point back then, I'm not sure, honestly, that I do now, but enough people have said it's useful work that who am I to deny it? And Graham87's obviously both good at it and committed to it. Support this proposal. SerialNumber5412912:42, 20 November 2024 (UTC)
(edit conflict) Support. Importers are editors who are highly trusted to undertake a very specialised role and it makes sense that they be given the rights needed to fully do the job properly. Thryduulf (talk) 13:09, 20 November 2024 (UTC)
Support obviously – thanks, wow, did not expect this and I didn't know this would be feasible. As I said at my RRFA, I have my own issues with this tool (which explain why I didn't use it so much), but access to it is way better than no history-merge access at all. Graham87 (talk) 13:25, 20 November 2024 (UTC)
Support if technically feasible. I really opposed the RRFA because Graham87 was asking for a role we didn't have. If they can do their importing/merging work without being able to block users, I would support that. (Normally I wouldn't support a one-off solution like this but, given the rareness of this, I think it makes sense here.) Note that I would also favor further unbundling admin powers beyond this nom. - RevelationDirect (talk) 13:35, 20 November 2024 (UTC)
Support sure. This is super niche, but basically: if someone can be trusted to be able to do an xmlimport, this is related and much less dangerous. If we're going to touch it I'm find also adding it to transwiki importers as well (even though we don't have any currenty) for parity. transwiki import is less dangerous, and most of the WP:RFPI items are able to be done that way -- in case any non-admins were looking to work in that area. — xaosfluxTalk13:44, 20 November 2024 (UTC)
Support If somebody is a importer, they can be trusted with not messing up the databases any further while apply (merge-history). Sohom (talk) 13:58, 20 November 2024 (UTC)
Support. This seems like a bit of an exceptional case, but I do think that it's worthwhile to allow importers to merge histories for practical reasons. And the role is so restricted that I don't have trust issues here. — Red-tailed hawk(nest)15:53, 20 November 2024 (UTC)
I got to support Graham's importer request once upon a time. Pleased to support this request as well. Even setting aside the direct impetus, this is a logical bundling of the tools that does not raise the required trust level for this small user group. -- Tamzin[cetacean needed] (they|xe) 17:53, 20 November 2024 (UTC)
Support. Let's at least permit Graham to continue his archaeological work. No one else does this, and it requires the mergehistory perm. Folly Mox (talk) 11:15, 21 November 2024 (UTC)
Support, obviously, this is invaluable work and it would be a clear negative for it to stop being done, which is effectively what would happen otherwise. Gnomingstuff (talk) 01:51, 22 November 2024 (UTC)
Support My gut doesn't like this (mergehistory feels like a distinct permission from importer), but I do trust Graham87 to use the tool and think the chance of us ever getting any other non-admin importers is negligible, so I guess I support this. * Pppery *it has begun...01:54, 22 November 2024 (UTC)
Support Importers are already highly trusted and it is granted by a steward, so this would be a narrow unbundling that would probably satisfy any WMF legal requirements. And I would trust Graham87 with this tool. Abzeronow (talk) 20:58, 22 November 2024 (UTC)
Support Importers already can fuck with the page history a lot more than someone with history merge rights can. I see no reason to not allow importers to merge history. ThatIPEditorTalk · Contribs02:04, 23 November 2024 (UTC)
Support because if this enables work to be performed that much easier for one editor, then chances are increased for other editors to follow suit or pick up the mantle later on down the line. Thanks. Huggums537voted! (sign🖋️|📞talk)06:50, 25 November 2024 (UTC)
Support. I don't see a reason why not. This seems relevant to the importer group, and I'm surprised this permission isn't already included. – Epicgenius (talk) 14:31, 25 November 2024 (UTC)
Because importing is importing a bunch of revisions into the history of the page. It's quite similar and often needed. Those two users are the only ones who maintain this area critical to Wikipedia, and that's the system, which has persisted due to their being able to merge history; now that Graham's been stripped of history merging, half of his duty and thus a quarter of this system, we need to rectify it or risk destabilizing of the system. Aaron Liu (talk) 16:37, 20 November 2024 (UTC)
The system is only two people doing this work, and we're otherwise taking away half of what one of them does. I don't see any reason not to do this. Aaron Liu (talk) 20:36, 20 November 2024 (UTC)
@RevelationDirect yes, criteria is basically a user-specific RFC. This is a super niche area; though I'd be open to expanding this permission to the less dangersour transwiki-importer group -- which also requires a per-user rfc to add too, but with a lower bar to entry. — xaosfluxTalk13:46, 20 November 2024 (UTC)
@Graham87: Since the topic has come up, I've actually wanted to jump into importing for a while (I'll be quite honest, probably transwiki importing, given it seems like a better place to start out at than XML import), but how does one really get into that line of work? I presume the common answer would probably be the direction of WP:RFA, but that seems like a bit much given a right already exists that is outside of the sysop group. EggRoll97(talk) 20:54, 20 November 2024 (UTC)
@EggRoll97 transwiki comes with admin, so most people that want to deal with it go that route, WP:RFA. It is possible to add transwiki in isolation - to do so start a discussion (suggest over at Wikipedia talk:Requests for page importation). The discussion will need to be well advertised (WP:AN and WP:VPM are good places), run for a reasonable time to allow feedback (about a week), be well attended, and show a good consensus of support (someone else should 'close' the discussion with such showing). The bar for transwiki is generally less than for sysop, while the bar for importxml access is generally higher than sysop. At that point, it would get processed over at m:Steward requests/Permissions#Miscellaneous requests. — xaosfluxTalk11:51, 21 November 2024 (UTC)
@Xaosflux: Yeah that. @EggRoll97:, I did notice your ping, but I wasn't sure how to respond (given that no-one,, especially a non-admin, has asked such a question before) then got distracted by other things. If you have a good idea how/where you'd like to use the import tool, feel free to float your proposal as noted in the message above. Graham87 (talk) 15:52, 21 November 2024 (UTC)
It is, and no. The only way we can assign permissions is to add the permissions to a group, then users can be added to the group. It would be possible to create an entirely new group that has this permission - but that seems overkill here unless it was going to do a whole lot more (like a "technician" group that had a bunch of other sub-admin permissions). — xaosfluxTalk13:49, 20 November 2024 (UTC)
@Compassionate727 those are certainly case-by-case. Sometimes historymerge is the right tool for the job. Any complicated merge/imports that require deletion are going to have to be handled by admins unless we want to make some new sub-admin technician group in the future (the community has repeatedly rejected such proposals though) which could have extra tools (like delete/undelete and others) but only be permitted to use them for certain purposes. — xaosfluxTalk14:09, 20 November 2024 (UTC)
Graham believes that the MergeHistory tool is inferior simply because it doesn't log a merge on the target page. I see no problem with this view. Aaron Liu (talk) 14:11, 20 November 2024 (UTC)
I've started an RfC below regarding this issue; I do think it would be useful to have community input if there is any desire to ever build this functionality. — Red-tailed hawk(nest)15:52, 20 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.
End dates in office, for presidents & vice presidents of Brazil
Which dates do we use for when a president or vice president of Brazil's term ends. As I understand it, their term of office (barring a military coup) ended at midnight. GoodDay (talk) 14:22, 25 November 2024 (UTC)
I'm brazilian, so I think can answer this for y'all. The term ends the day the next president/governor is inaugurated. So for example, Jair Bolsonaro's term ended 1 January 2023, and Lula started 1 January 2023 (same day).
The new term starts at the time the inauguration takes place. So as an example, if the inauguration takes place at 1400, Bolsonaro was president until 1400, when Lula became the president.
The fact is we will never have an answer because the Constitution is ambiguous. It states the date when the term begins, but also states that the president must take the oath of office.
As this has never been brought before the Supreme Court to rule upon because there have never been any issues with deciding who the president is between midnight and 10 a.m. of January 1, the ambiguity will likely remain unresolved.
That said, the public perception is that the incoming president becomes president on the morning of the 1st, when they receive the sash from the outgoing president (when the outgoing president is gracious enough to take part in the ceremony). For that alone I would suggest that the term be said to end on January 1. Zelani (talk) 02:27, 26 November 2024 (UTC)
This covers all the presidents & vice presidents of Brazil. So if we go with January 1? We'll have to also go with November 15 & March 15 for the earlier presidents & vice presidents. GoodDay (talk) 02:42, 26 November 2024 (UTC)
@GoodDay The fact is that "terms end at midnight" just isn't a thing. Nobody's looking at their watches saying, "Ten seconds until Jurandir becomes mayor!" Jurandir's team isn't waiting at the door of Paçoquinha do Norte City Hall just waiting to barge in at midnight to take the reins to municipal administration.
Transfer of power is (ideally) a smooth handover of power.
If the Constituent Assembly had intended for there to be an exact time, they would have written it into the document.
That argument wouldn't go far, concerning Mexico presidents or New York governors & lieutenant governors. Terms in some places, do end at midnight. GoodDay (talk) 11:59, 26 November 2024 (UTC)
My point is, you're splitting hairs over an issue that is irrelevant outside of Wikipedia. It has no bearing in the real world.
Anyway, the Constitution is clear in one respect:
"Art. 78. O Presidente e o Vice-Presidente da República tomarão posse em sessão do Congresso Nacional, prestando o compromisso de manter, defender e cumprir a Constituição, observar as leis, promover o bem geral do povo brasileiro, sustentar a união, a integridade e a independência do Brasil."
This, to me, leaves no margin for doubt. The President's term begins when they take the oath of office in the session in Congress.
Yeah, I forgot to mention the ambiguity in the constitution. But for most matters, January 1st is the day.
If there happens to be something that the supreme court might intervene, that'd be settled, but for now I think we should just take the most used answer. Eduardo G.msg-contrib02:47, 26 November 2024 (UTC)
Yes, this is basically saying that to have an article, the subject must meet GNG. There is an example in the article deletion discussion I mentioned above where NBAND was argued as an exception to GNG.--3family6 (Talk to me | See what I have done) 16:07, 18 November 2024 (UTC)
A single discussion where somebody argues something that does not gain consensus is not evidence of a problem, let alone evidence that the proposed change would solve that problem. Thryduulf (talk) 16:26, 18 November 2024 (UTC)
This is a feature, not a bug; "or" does not mean "and". That WP:BAND currently circumvents WP:GNG is either trivially true (as creating subject-specific notability guidance outside of the GNG is the whole point of a WP:SNG) or arises from a fundamental misunderstanding of the purpose of the subject-specific notability guidelines. — Red-tailed hawk(nest)16:50, 19 November 2024 (UTC)
or arises from a fundamental misunderstanding of the purpose of the subject-specific notability guidelines. That might actually be what is at issue - there seem to be two different understandings of what SNG's are - supporting GNG or an alternative to it.--3family6 (Talk to me | See what I have done) 18:17, 19 November 2024 (UTC)
Some SNGs take one approach; others take different approaches. WP:SNG was written to allow for the diversity of approaches represented by the current SNGs. Newimpartial (talk) 22:10, 22 November 2024 (UTC)
I posted this in the other village pump thread, but while I'm generally fine with this proposal, I don't think it's coming from a place of understanding.
Basically, there's an assumption happening that record labels work off some kind of predictable tier system, where the Big 3 labels are home to the most famous artists, indie labels are home to the semi-famous ones, and everyone else is a non-notable bottom feeder. That's not how it works. One of the more notable albums of the year is Cindy Lee's Diamond Jubilee, which was self-released. Meanwhile, there are artists on the Big 3 who I would guess probably don't have significant coverage. This is because music journalism is dying, no one has staff and no one has money, and the range of artists being covered has shrunk dramatically. See this Columbia Journalism Review article for further on that.
So in other words, I don't think criterion 5 in NBAND is good or useful, but for the opposite reasons that this proposal suggests. The problem is not that people's random garage bands will be considered a "label." The problem is there is less and less correlation between being signed to a label and having significant coverage. (Ironically, the "albums" criterion is probably the more stringent one, because labels are less and less likely to put out a full-length album by an artist that isn't already established via singles and streaming tracks.)
I don't know what to do with that. (I honestly think the collapse of journalism and the shrinking scope of what gets reported on is a ticking time bomb for notability criteria across the board, but that's a whole other topic.) The most straightforward solution is to use WP:GNG, but I think it's important to have a correct understanding of exactly what musicians we're talking about here. The bar is way, way, way higher than "run of the mill non-notable items" now. The bar is one or two tiers below Sabrina Carpenter. Gnomingstuff (talk) 21:26, 19 November 2024 (UTC)
Addendum: One way that this criterion could have value is to serve as a reminder that one Google search is not a sufficient WP:BEFORE check, because artists on notable labels are likely to have received coverage in print. (Another way this proposal is misinformed
- removing NBAND #5 will primarily affect older bands, not newer ones.) But alas, people do not do thorough checks even when they're reminded. Gnomingstuff (talk) 21:33, 19 November 2024 (UTC)
I'd love to make BEFORE specifically include looking where sources are most likely to be found and explicitly state that looking at the first few pages of Google do not constitute a proper check. This always gets shot down in howls of protest at how dare I require people nominating pages for deletion to do more work than they imagine it took to create a three line sub-stub. I don't know how we get past this. Thryduulf (talk) 21:45, 19 November 2024 (UTC)
I mean, it already does: The minimum search expected is a normal Google search, a Google Books search, a Google News search, and a Google News archive search; Google Scholar is suggested for academic subjects. The problem is that WP:BEFORE is not considered binding so there are no consequences to ignoring it. Gnomingstuff (talk) 21:51, 19 November 2024 (UTC)
Your proposal operatively eliminates the SNG for bands. And also creates an even tougher GNG requirement than GNG by requiring that GNG compliance be demonstrated. I would like there to be some at least partial demonstration requirement added to GNG, but that's a whole 'nother issue and a secondary one in this case.
It also sort of misses the main point discussed at the linked pump discussion which was eliminating one or two items / "ways in" in the SNG.Sincerely, North8000 (talk) 18:04, 18 November 2024 (UTC)
in line with this, NBAND can be eeaily fixed to makes sure that the idea that the criteria are a presumption of notability is added. I do not see any language like this though the intent seems to be there. That would quickly resolve one conflict. Mind you, deprecating or time gating criteria that do not make sense in modern music distribution is also a reasonable step though I would not remove them outright for historical purposes. Masem (t) 19:02, 18 November 2024 (UTC)
I was amazed by how much our guidelines were written with Western popular musicians in mind when I started editing 17 years ago and it seems that nothing has changed since. It is so much easier for such a person to have an article about them than for other types or nationalities of musician. This is so obviously caused by Wikipedia's demographics that I hesitate to say anything further. Phil Bridger (talk) 19:18, 18 November 2024 (UTC)
I wonder what effect imposing GNG would have on that. I've heard from some African editors that much of the real news for music and pop culture is posted on social media (i.e., actually posted on Facebook itself, not some website that's sorta kinda social media-like). So if you take away an objective but non-source-oriented criteria and substitute 'must have the kind of sources that are usual enough in the US and UK but are unusual in Nigeria', will that tip even further towards overrepresenting Western popular musicians?
My impression of the two albums/two films kinds of rules from back in the day is that the advice had more to do with WP:Build the web than with writing full articles. The expectation was that (if there weren't significant sources to justify writing more), the articles would usually be very brief ("Joe Film is an American actor who appeared in Film and Example" or "The Band is a British band who released Album in 1998 and Cover album in 2001") but that we'd still be able to provide non-red links in related pages and still not have to duplicate information. Consequently, I think the traditional thinking is closer to how we think of spinning off a list or splitting a long article, than about trying to justify the subject as "worthy" of a full, stand-alone article via extensive sourcing.
I could imagine people opposing this merely for fear of the resulting red links, and of course the idea of going beyond the GNG to require "demonstrating" it will turn off other editors. WhatamIdoing (talk) 19:36, 18 November 2024 (UTC)
If it is established that reliable third party sources covering African music are going to include posts on social media rather than print or web publishing, then we should work to accomodate that so that we are more inclusive, rather than expect the more traditional forms of media. Masem (t) 20:05, 18 November 2024 (UTC)
speaking for myself, I never had issues with using a third party posting via something like Facebook. I've always considered that to be a statement by that third party, they're just using Facebook as the medium. Am I understanding this example correctly?--3family6 (Talk to me | See what I have done) 20:18, 18 November 2024 (UTC)
A statement by the band('s representatives) on the band's official facebook page is no more user-generated content and no less reliable than if that same statement was made by the same people was posted on the band's official website or quoted verbatim in a newspaper. Thryduulf (talk) 20:55, 18 November 2024 (UTC)
Yes, Thryduulf, that's partly what I'm referring to. Schazjmd, I am indeed familiar with that guideline. In fact, my first edit on Wikipedia was removing content that I had generated as a user on another site. I'm referring to established media outlets posting something on Facebook. Like, say, Salon posted a story on Facebook rather than on their official site. It's gone through an editorial process, they just are using Facebook as a publishing medium.--3family6 (Talk to me | See what I have done) 21:00, 18 November 2024 (UTC)
There isn't a wiki-requirement for the type of source that sources used, or even that they have sources. Of course such things still matter regarding regarding actual/ real world reliability of of the source. North8000 (talk) 21:36, 18 November 2024 (UTC)
So keeping in mind that I have never had a Facebook account and have no experience with social media, my impression from these editors was that when they say they get news on Facebook, it's not necessarily the band that's posting (which wouldn't be Wikipedia:Independent sources) or even news articles being shared. Instead, it could be an ordinary comment by someone whom their followers believe is knowledgeable but who is not necessarily "official". For example – and I completely make this example up; the African editors who told me about this dilemma two years ago are welcome to disavow and correct anything I say – imagine a post by a professional DJ: They'll know things about music and bands, and they'll probably know more than a magazine writer assigned to do a piece on pop music in that city/country. They are "reliable" in the sense that people "rely on" them every day of the year. But it's outside the kinds of formal structures that we use to evaluate official sources: no editor, no publisher, no fact-checker, no peer review, etc. WhatamIdoing (talk) 05:33, 20 November 2024 (UTC)
I'm all for adapting guidelines and policies for geographic and cultural considerations. However, I don't think this would get far, because it's essentially a using self-published sources for BLPs issue, and that's going to be a steep climb to weaken that policy.--3family6 (Talk to me | See what I have done) 12:55, 22 November 2024 (UTC)
Yeah, I don't see any easy solution here. Even if it's not BLP-related, it relies on already knowing which accounts are the trustworthy ones, and there's no impartial way to evaluate an unfamiliar source. The post could say something like "This village is best known for cloth dyeing" or "The bus service there doesn't run on Sundays", and you'd still have to know whether that source is a good source of information. What if one person posts that the bus runs on Sundays and another person posts that it doesn't? An outsider would have no way of knowing which to trust. WhatamIdoing (talk) 23:28, 22 November 2024 (UTC)
I always thought the the reason "two or more" was specified was that if there was only one the name could be redirected. Since that time there seems to have developed a dislike for stubs. I don't know where that came from (most articles in most traditional encyclopedias only consisted of one or two sentences, if that) but in order to satisfy that dislike maybe criterion 6 should be an encouragement to create a disambiguation page (or maybe a set index page, if you want to be pedantic) for the title. Phil Bridger (talk) 19:43, 22 November 2024 (UTC)
I think that is correct. If there's only one, then you could:
Have an article about the album
Redirect the band's name to it
Put the little bit of information you have about the band in the album article
but if there are multiple albums, then:
You can have an article about each album
But which one do you redirect the band's name to?
And do you duplicate the information about the band in each of the album articles?
So it seemed easier to have an article. Now, of course, when the median size of an article is 13 sentences and 4 refs, and when we have a non-trivial minority of editors who think even that is pathetic, there is resistance to it. WhatamIdoing (talk) 23:33, 22 November 2024 (UTC)
Comment I am interpreting this section as an RfCBEFORE, and contributing in that spirit.
Having briefly reviewed the linked discussions, I do not see a problem with NBAND itself that would justify deprecation (rather than revision). And turning NBAND into a predictor of GNG rather than a standalone SNG seems to me essentially akin to deprecation. Fixing specific criteria seems much more appropriate to me, given the issues raised to date.
There are what seem to me to be evident reasons why NBAND operates according to the same logic as NCREATIVE, which is explicitly excluded from WP:NOTINHERITED. These SNGs reflect the reality that creative people produce creative works, and that therefore the people creating those works gain encyclopedic relevance directly from having created them.
In addition, it seems to me that there are practical, navigational reasons (having to do with the affordances of hypertext, Wikipedia's list system, and Wikipedia's category system) to offer more consistent treatment rather than leaving each individual musician, each musical group and each album up to the vagaries of WP:NBASIC, WP:NORG and the WP:GNG.
There may be problems with specific NBAND criteria and the way they are sometimes used at AfD, but it seems entirely incommensurate to deprecate the whole SNG based on such marginal concerns. Newimpartial (talk) 20:31, 18 November 2024 (UTC)
IMO the Wikipedia norm for a "just barely made it" band has sourcing that meets a slightly lenient interpretation of GNG, and the decision is influenced by somewhat meeting an SNG criteria, thus being more conducive to artists than for example a for-profit corporation. And the "norm" means that is is how Wikipedia as a whole wants it. There are folks out there who are at the extreme deletionist end of the spectrum and they will typically say that the above is not the case and piece together an unusually strignent "letter of the law" demand, even adding some things from essays saying that three sources that 100% meet GNG is the expectation. And so while I really think that the burden should shift to providing some GNG-ish sources (vs. just saying "they are out there" without actually supplying any) I'm loath to shift the balance too much, keeping the folks at the deletionist end of the spectrum in mind.
The pump discussion started with talking about how being signed by a label is no longer as indicative as it used to be and to remove it as being a key to the city of SNG compliance. I think there was support for that.
I agree with everyone else above that this proposal would gut WP:BAND, which I am not okay with. If you want to remove some criteria of WP:BAND, like #5, which I agree is a little opaque and outdated, fine. But this seems like a sneaky way of demolishing WP:BAND without openly saying so. Toadspike[Talk]21:36, 18 November 2024 (UTC)
I like the point North made, that our notability rules are set up to be more conducive to artists than for example a for-profit corporation. I've never thought of our guidelines on artists as particularly lax, but I know that NCORP is purposely stringent and that is the way things should be. Toadspike[Talk]21:41, 18 November 2024 (UTC)
I'm not disappointed at the consensus emerging here, and hopefully it might help clarify discussions. there does seem to be some consensus to ditch criterion 5. I'm happy to amend it to that particular criterion disappearing and everything else stays.--3family6 (Talk to me | See what I have done) 21:48, 18 November 2024 (UTC)
I wonder if the most practical thing with criterion 5 (the one about releasing two albums on a label) would be to give it an end date. It was a useful criterion in the pre-streaming music world, so why not say "two albums on a label before 2010", or at whatever point editors decide that labels became less relevant? WhatamIdoing (talk) 16:42, 19 November 2024 (UTC)
I think this is a good idea but the cutoff should be earlier. The iTunes music store was founded in 2003, Spotify was founded in 2006, sometime around there would make more sense. Gnomingstuff (talk) 21:39, 19 November 2024 (UTC)
I cheerfully leave the determination of the date to someone else, but I note that Spotify#History says that Spotify reached the US market in July 2011, so I'm not sure that it had much effect in 2006. WhatamIdoing (talk) 05:37, 20 November 2024 (UTC)
If we are specifically concerned about self-published labels (again, I think the "more important indie" labels part already rules that out anyway, but whatever), the digital distribution companies making that happen DistroKid in 2012 and CDBaby in 2004. But even those had their main impact by partnering with Spotify and iTunes respectively. Gnomingstuff (talk) 17:32, 22 November 2024 (UTC)
WP:DELPOL allows for deletion of "articles for which thorough attempts to find reliable sources to verify them have failed" – isn't that sufficient? – Joe (talk) 06:50, 20 November 2024 (UTC)
AIUI the problem there isn't that deletion isn't one of several available options according to policy; instead, the problem is that other editors do not agree to delete it. DELPOL allows such deletions, but it does not require them, and if I want to delete the article for being IMO undersourced, but other editors show up at AFD saying things like "qualifies under NBAND 5", then the article won't actually get deleted. WhatamIdoing (talk) 22:18, 21 November 2024 (UTC)
That's what I thought. The rules don't result in the deletions "I" want; therefore, we must change the rules so other editors can't prevent the deletions "I" want. WhatamIdoing (talk) 23:36, 22 November 2024 (UTC)
Strongly opposed to the proposal as written by 3family6 as it's written at Wikipedia:Band_notability_proposal now, because it still contains the same text from #5 and #6, which are the two criteria from NBAND that I am objecting to that SNG's presence in the first place. I am unfamiliar with proposal process, but 3family6 went ahead and put it together on his own and doesn't want anyone editing it now. As I said, I don't know how proposals work, but if one user puts it together and quickly puts it out for a vote, is it off limits to editing? Graywalls (talk) 22:09, 21 November 2024 (UTC)
Making criteria 2-11 contingent on also meeting criterion 1 is a much larger (and seemingly unnecessary) change compared to removing or reformulating 5 and 6. Newimpartial (talk) 13:08, 22 November 2024 (UTC)
I often remove redlinks from dab pages per WP:DDD. I recently did this on the Sylvester page and was pleased to see at the top of the editing page Attention editors! No red links. Every entry in this list must have an article written in the English Wikipedia ... else it will be removed without warning. I assumed this must be a new feature for dab pages, but I haven't been able to find it anywhere else so far. Some dab pages do have a notice at the top of the editing page explaining their purpose, but with no mention of redlinks, and many dab pages have nothing like this at all. Can/should they all be flagged with an appropriate notice about redlinks? Or at least all flagged with an explanation of dab pages? Shantavira|feed me10:00, 26 November 2024 (UTC)
Having an editnotice for name articles as @Shantavira suggests seems like a good idea. It should definitely be centralized and automatically added, so that we can ensure it represents best practices/consensuses and reduces the workload.
The deletion discussion boards (AfD, RfD, etc..) are riddled with socks. You can see in old AfD pages, how many accounts were later banned as socks (strikethroughs). It would be interesting to analyze this data to quantify how bad the sock situation is. IPs are some of the worse abusers. Deletion of content by straight vandalism is hard, but aggressively and maliciously voting delete while using socks? That's kind of fun and "legal" (if you don't get caught). This misbehavior could be better managed with some simple rules. One Example:
IPs are not "banned", but IPs are limited to a certain number of deletion votes per week. It's good faith self-monitored restriction that can be enforced if needed.
Such a rule would force frequent IPs to either register, which makes sock detection easier; or force them to use dynamic IPs, which is more difficult and costly for them. Legitimate IP editors who frequently vote in deletion discussions need to register or do something else, I don't believe this category of editors will be a large number.
The consensus discussions, particularly deletion, are frequently abused by sock accounts not operating in Good Faith. We can take simple low-friction steps to make things more difficult for them, and easier for us to detect. -- GreenC16:44, 23 November 2024 (UTC)
I don't think limiting IPs to a certain number of votes would be helpful. It would restrict participation from legitimate users who might not wish to create an account, while encouraging abusers to use even more socks when voting. Also, many people already have dynamic IPs, which is more often a function of the ISP/network they are using than any costly choice (to take an extreme example, an IPv6 user can have the second half of their address vary between 264 possibilities in their device's assigned /64 range). This would automatically put static IP users and dynamic IP users on unequal grounds, and make it even more enticing to sock/use multiple IPs.It is easy to make proposals raising the bar for prospective editors to participate, in the name of defending the wiki from socks/bad actors/etc., but each step we take in that direction brings us further from our ideal of "the encyclopedia that anyone can edit", and we should be very careful about this. Chaotic Enby (talk · contribs) 16:55, 23 November 2024 (UTC)
I've been closing a lot of AFDs lately and, while some socks are caught in some discussions, I have not personally seen a serious issue with block-evading IP users. This proposal seems like it is assuming bad faith if IP users wish to particpaite at AFD. Just Step Sidewaysfrom this world ..... today18:58, 23 November 2024 (UTC)
As IPs may not be a single person over time, a soft participation limit doesn't work. It is at any rate up to closers to evaluate an AfD on its merits, not as a vote count. CMD (talk) 01:51, 24 November 2024 (UTC)
"It would be interesting to analyze this data to quantify how bad the sock situation is." Then do so, before proposing a policy based on it? Gnomingstuff (talk) 05:43, 24 November 2024 (UTC)
Without any idea of the statistics, we don't have any way to know if the problem is serious enough to justify restricting anons on this. When gathering data, exclude any CTOPs where anons are already disallowed, as these are more likely to reflect the CTOPs than AFD. Other CTOPs may also suffer from this, so probably list those separately. Animal lover|666|12:39, 24 November 2024 (UTC)
I routinely discount low-activity IP's in discussions, on the argument that there is an absence of a basis for determining whether they understand the purpose of the encyclopedia and its policies. BD2412T15:08, 24 November 2024 (UTC)
The problem with that is that it's impossible to tell the difference between a newcomer IP, an anon who edits on a wide range of IP addresses and has perhaps hundreds of edits, and a long-time registered user who got logged out without realizing it and decided after expressing their opinion to let it stand as an anon vote. Animal lover|666|16:33, 24 November 2024 (UTC)
@Animal lover 666: I am aware of that, but the problem runs both ways. It is equally impossible to tell if an IP is really another editor already involved in the discussion; or a COI editor, or the like. If an IP makes a persuasive argument backed by evidence, their argument should be able to persuade non-IP participants in the discussion, whose opinions will be weighted more heavily. BD2412T17:03, 25 November 2024 (UTC)
Disclosure in advance, I do periodically participate in XfDs, though not as often as I should as they can be time-consuming to do right, especially AfD.
That out of the way. It's not clear to me what this is trying to accomplish or why it matters whether someone is registered or unregistered. If someone is blindly spamming keep or delete across many discussions that is disruptive and the user should be blocked, at least from projectspace, account or no. If they are putting in low-effort JUSTAVOTE type stuff, then the closer should ignore them. If they are putting in high-quality, well-researched, PAG-based rationales that demonstrate careful consideration, then that's a good thing and we should encourage them to participate more because XfDs of all kinds are chronically understaffed, and its a time-consuming and thankless task.
If a sock is persistently disrupting XfD(s), then report them to AIV or SPI as appropriate depending on the complexity of the case. However, merely being prone more to deletion !votes than keep ones is not in itself a concern; remember delete is by a significant margin the most common AfD result so someone who most frequently !votes for deletion should not automatically be judged thereby a sock, or even a deletionist, but simply normal.
Sidenote, registration makes socks harder to detect, as the only difference is one less piece of information. Disruption from someone who remains unregistered is almost invariably easier to handle, and I don't think anyone with years of RCP time is going to differ much on that assessment.
In the larger view, troublesome editors who can employ bureaucratic and social skills waste more of the community's time than vandals. I'm not saying IPs can't become vested, and sometimes we do, after our own fashion, but in practice the people who have caused the most trouble have accounts. 184.152.68.190 (talk) 18:23, 28 November 2024 (UTC)
I'm not sure IP editors are the biggest problem sock-wise. Usually what I've seen is some account that's built up 100 to maybe just under a thousand edits through some semi-automated (e.g. IA bot) or otherwise very quick edits, sometimes a few months before they start editing again, and then almost exclusively editing AFD pages thereafter. I'm not sure there's much we can do policy-wise or technically, my expectation is that we need to rely on the experience of closers. However, XFDs that do end up with a number of socks picked up after the fact should probably be brought to review. Alpha3031 (t • c) 03:28, 29 November 2024 (UTC)
If the page is kept, it's probably best just to RENOM and explain that you are ignoring the usual time limits in order to have a discussion without sock disruption. If deleted, then DRV is needed, but I expect a speedy restore and send back to AfD would be uncontroversial.
IP and non EC editors are not permitted to participate in consensus forming discussions if the subject matter is a CT, which are probably(?) the worst affected areas. If my assumption is wrong and the problem is extensive beyond CT, then perhaps consider a similar rule across the board, why not. It is not clear to me how such editors even find these discussions.Selfstudier (talk) 15:22, 24 November 2024 (UTC)
For some context, see this comment by GreenC, where he makes an unprovoked casting of WP:ASPERSIONS with no evidence. Also worth noting is that the actual sock in this case, TeapotsOfDoom, had an account, and wasn't editing unregistered. Also also worth noting, is that yes, while socking is disruptive generally, Teapots's activity at RFD was overall quite productive, bringing a lot of bad redirects to the forum's attention. If he's reading this, I hope he follows the WP:SO approach and is able to return. Also also also worth noting is GreenC's characterization as "malicious", which is completely uncalled for. I would highly urge you to reconsider your words and strike your aspersion at the RFD in question. 35.139.154.158 (talk) 16:11, 24 November 2024 (UTC)
It was because TeapotsOfDoom had an account that checkuser was able to work. It doesn't work with IPs. That's the point. There is a loophole that gives IPs an easy bypass of checkuser and SPI. They have an advantage over registered accounts, when it comes to socking. -- GreenC22:55, 25 November 2024 (UTC)
That's not accurate, the details are at mw:extension:checkuser, but you absolutely can use Special:Investigate or Special:Checkuser on IPs or CIDR ranges, and this is done routinely. It is true that functionaries will not publicly connect accounts to IPs unless the account owner expressly allows this, but that does not prevent them from sockblocking IPs which also happens routinely, or prevent the filing of AIV or SPI reports, simply do not request use of the checkuser tool in those SPIs.
I don't keep tabs on other IP editors like I used to, even the ones that do RCP, and I'll admit I struggle far more to find scent trails than in past years. But 35.139.154.158 does not have a strong LTA/sock sniff and the insinuation was uncalled for. Good-faith users can disagree whether WP:RFD#D8 or WP:RFD#K3 is more applicable in that discussion without personalizing the dispute. 184.152.68.190 (talk) 18:44, 28 November 2024 (UTC)
This is also not quite true: we routinely connect IPs with accounts, and IP editors with other IP editors, just not publicly. And on English Wikipedia we are not permitted to check an account just because the owner asks, nor to reveal an account's IP at the owner's request (though it's fairly simple for them to do so themselves). Ivanvector (Talk/Edits) 18:48, 28 November 2024 (UTC)
I wasn't referring to that but to the somewhat unusual case where an account has already been privately connected to IPs by a functionary, and the owner agrees to discuss them as part of a public appeal. 184.152.68.190 (talk) 18:56, 28 November 2024 (UTC)
Reply - It's like 3RR or anything else, you have the option to warn them, it's all voluntary there is no hard rule that stops them from editing. If nobody sees their editing as a problem then it won't be a problem. The issues are that it can be very hard to prove at SPI because IPs have natural immunity from checkuser. IPs are often used in deletion discussions for that reason. -- GreenC23:06, 25 November 2024 (UTC)
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 
Resolved
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)
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 
Liechtenstein flag template (it only detects the relevant wikitext)) Aaron Liu (talk) 17:02, 2 November 2024 (UTC)
.jpg)
.jpg)
White
Silver
Blue
Pink
Gold
Red
Green
Skyblue
Purple
Turquoise
Black
Agree, but only slightly. If you added the letters, it would be better. Also, a solution to your region-basing could be to do a Language-based (like "O" for "Office" would become "S" for "Schoolhouse" in a theoretical "Reversed English") The Master of Hedgehogs (converse) (hedgehogs) 14:33, 17 October 2024 (UTC)
