Jump to content

Wikipedia:Village pump (proposals)/Archive 203

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

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

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

A section to propose new pages

Hello, I'm Key of G Minor and I would like to propose an internal page for people to suggest pages. It could be for a variety of reasons, i.e. not wanting to break WP:NPOV, not knowing how they would do it (limited or payment required information, limited knowledge of the afc process), etc. The process would go as follows:

  1. User puts in suggestion entry
  2. Discussion takes place around it
  3. Editing either starts or doesn't start in accordance with consensus. During this process, discussions about its usefulness could be raised once again. If it is useful, editing either resumes. If not, editing halts.
  4. Either it goes through WP:AFC, or discussion about whether or not its quality is that of a article
  5. If so, it is published. If not, editing either resumes or halts.

Thank you for reading my proposal and have a good day. Key of G Minor (talk) 18:18, 12 June 2023 (UTC)

You mean like Wikipedia:Requested articles? DonIago (talk) 19:26, 12 June 2023 (UTC)
Could be interesting if there was a tool assisted process to go from RA to draft (then back to RA again if whoever it is loses interest and the draft gets G13'ed). Maybe could collect and organise potential references as well, and keep track of any assessments made of their usefulness. Latter half is possibly excessive scope creep though. Alpha3031 (t • c) 13:55, 13 June 2023 (UTC)
I would consider appropriate source identification integral to the scope of any discussion about whether an article should be written on a topic. Kinda like AfD in reverse? Folly Mox (talk) 18:08, 13 June 2023 (UTC)
Yeah. It would be a sort of collaborative thing, whereas most drafts are one person doing all the work. With this process, it's spread out across multiple people. Sincerely, Key of G Minor. Tools: (talk, contribs) 18:50, 13 June 2023 (UTC)
Sort of, I suppose. But it's more collaborative. Sincerely, Key of G Minor. Tools: (talk, contribs) 18:51, 13 June 2023 (UTC)
I think this could potentially be a good Wikipedia:WikiProject. Not sure how many people would be interested, but well worth a try IMO. Alpha3031 (t • c) 13:12, 14 June 2023 (UTC)
There is already Wikipedia:Articles for improvement, perhaps they'd be interested in collaborative drafting. CMD (talk) 13:25, 14 June 2023 (UTC)

Hello, I think the names of certain geographical features (water bodies, state/national parks, etc...) should be included in Template:Maplink. Currently, the only labels shown are human settlements and roadways. I understand those are the pages that use it the most, but its also used by pages other than that. In general, the single green color for protected areas and blue color for water bodies do both blend into two, single colors, which can be a problem when there are areas with multiple different park/water bodies that are close together. Thank you and have a great day! DiscoA340 (talk) 19:45, 15 June 2023 (UTC)

MOS discussion on definingness in lead sentences of biographies

There is a proposal at Wikipedia_talk:Manual_of_Style/Lead_section#Proposal:_first_sentences_should_be_defining which would benefit from some wider community input. Barnards.tar.gz (talk) 08:15, 16 June 2023 (UTC)

I recently made a dumb error when trying to access an internet link that had been transferred to archive.org - I clicked the words "the original", thinking this would lead to the original document from which the quote was taken, and then when it failed got the impression that the link was not working. I think it is misleading that a dead link is presented in the same format as a working one. For the benefit of users who are not fluent in the Wikipedia presentation, could the template that implements these links be modified to show the words "the original" in red rather than blue, to be similar to other dead links? The particular link that confused me is the James Randi link 11 in section "Criticism" of the article "Skinwalker Ranch". 203.221.25.134 (talk) 17:57, 7 June 2023 (UTC)

Red is used only for Wikipedia pages which don't exist, e.g. No such article. External links to other sites are always blue; they may return useful content, a HTTP 404 page or nothing. The external site may change this response depending on the visitor's location, logged-in status, time of day or whatever they choose. Sadly, it would be impractical for Wikipedia to keep track of all such changes. Certes (talk) 18:17, 7 June 2023 (UTC)
I don't think it's entirely impractical to alter the text metrics within citation templates. url-status= already determines whether the link to the original is the target of the link title (url-status=live), the target of "the original" in the text "archived from the original" (url-status=dead), or not at all (url-status=usurped or unfit). It's definitely not possible to keep track of when the url-status changes state, but using that parameter to determine how citation templates display is already in production. Folly Mox (talk) 19:16, 7 June 2023 (UTC)
Yes. Compare these examples, the only difference between them is the value passed into |url-status=:
  1. British Transport Commission (1963). "The Reshaping of British Railways – Part 1: Report". Her Majesty's Stationery Office. Archived from the original on 19 October 2010. Retrieved 25 November 2006 – via The Railways Archive.
    This one has |url-status=live. The title is linked to the original web page, and the word "Archived" is linked to the page at the archive site. It is used when the original page still supports the cited content, but has been pre-emptively archived.
  2. British Transport Commission (1963). "The Reshaping of British Railways – Part 1: Report". Her Majesty's Stationery Office. Archived from the original on 19 October 2010. Retrieved 25 November 2006 – via The Railways Archive.
    This one has |url-status=dead, but |url-status=deviated and |url-status= behave the same (as does omitting the parameter). The title is linked to the archived web page, and the words "the original" are linked to the original web page.
  3. British Transport Commission (1963). "The Reshaping of British Railways – Part 1: Report". Her Majesty's Stationery Office. Archived from the original on 19 October 2010. Retrieved 25 November 2006 – via The Railways Archive.{{cite web}}: CS1 maint: unfit URL (link)
    This one has |url-status=unfit, but |url-status=usurped behaves the same. The title is linked to the archived web page, but there is no link to the original web page. It is used when the original URL has been usurped for the purposes of spam, advertising, or is otherwise unsuitable.
Which one you use depends primarily on what happens when you follow the link to the original page. --Redrose64 🌹 (talk) 21:47, 7 June 2023 (UTC)
So, is the question whether to make "the original" a red link in example 2? And if so, what's the answer? It doesn't sound too difficult, if it's desired. (By "red", I mean "in the reader's chosen style for links with missing targets", which may be fluorescent lime or some audible clue rather than actually red.) Certes (talk) 22:08, 7 June 2023 (UTC)
I believe that is the question, but I think the answer should be no. A link to an external site that is red, but clickable, but which may lead to websites in various states of disrepair doesn’t make much semantic sense to me. The better solution may be to actively tag more urls as unfit (or some other word), or to just not display the link to the original url when marked dead (ie the same as unfit). But until someone very clever comes along to rethink the problem, I think the current system is fine. Worst case scenario, the user has to return and click the title link after wondering why the url was “archived from the original” in the first place… perhaps the original was in need of archiving for some reason. — HTGS (talk) 12:27, 8 June 2023 (UTC)
I am sure that everyone who has up to now commented on this request is a longtime WP user who does not have to even think consciously to realise the difference between the different blocks of blue text in a link such as Example 2 (and thank you for the explanation which made me aware of differences that I previously had no idea of).
But please give some weight to the situation of an inexperienced user who might have the mistaken impression the the detailed blue text at the start of that kind of link is only some kind of formal statement of the details of the document, and that the succinct words "the original" (which are in blue and seem on a par with any other valid link in WP) are the way to get to the original document. A person with this misunderstanding may NOT realise that "I only have to click the other link", but instead come away with the belief that the link is broken.
On reading the previous comments above and going through the steps that confused me before, I now think that a change of colour might not be the best choice (although if you don't want to use red, brown seems to me to give a suitable impression), so could you perhaps change the wording to say "the original link", to better suggest that although it's the original link, it might not lead to the original document? 194.193.133.100 (talk) 17:26, 9 June 2023 (UTC) (Former 203.221.25.134)
There has been no further comment on this suggestion, and no explicit acceptance or rejection. Will it just die from lack of interest? My final comment: I think that appending the word "link" to "the original" in Example 2 references would be a minor programming task, an utterly negligible extra load on the ongoing running of the system, only a small burden on the sensibilities of long-term users who are used to seeing it the way it currently is, and a minor but positive contribution to lessening misunderstanding by new users, ie: I still think it is worth doing. 124.170.20.251 (talk) 06:50, 18 June 2023 (UTC) (Former 203.221.25.134)

Adding dark mode

the web version of wikipedia needs dark mode as the light mode makes it harder to read. This feature is already implemented on the mobile version of wiki and it would make sense to see it on the web version Abo Yemen✉ 15:15, 20 June 2023 (UTC)

See Wikipedia:Dark mode for currently available options. isaacl (talk) 15:37, 20 June 2023 (UTC)
there should be a dedicated button to switch from light mode to dark mode Abo Yemen✉ 15:51, 20 June 2023 (UTC)
@Abo Yemen, there is, with the gadget. — Qwerfjkltalk 15:58, 20 June 2023 (UTC)
but what if a new wikipedian wants it but doesn't know what a gadget it? Abo Yemen✉ 16:03, 20 June 2023 (UTC)
Good point; it should be much easier to discover. I would make a button/link visible by default, even to unregistered users. Certes (talk) 16:14, 20 June 2023 (UTC)
With the way the gadget works, you can't make it available for unregistered users in a way that the preference "sticks" after navigation to another page. At least not without giving them FOUCs. Nardog (talk) 19:41, 20 June 2023 (UTC)
I remember @Alexis Jazz had done some work on this, and it sticks somehow. Visit https://commons.wikimedia.beta.wmflabs.org/wiki/Main_Page > Tools tab > Gadgets option > Dark mode. Enable it and now go to any page on the wiki or refresh it as many times you wish, and it sticks without any flashes, even when you are not logged-in. —CX Zoom[he/him] (let's talk • {C•X}) 23:15, 20 June 2023 (UTC)
Because the server can't return different pages for unregistered users based on their user preferences (as they don't have any), configuration changes stored in the cookies or local browser storage for individual unregistered users can only be applied by Javascript after or during the initial page load. As I understand it from Wikipedia:Village pump (proposals)/Archive 194 § Survey (showing a gadget menu to logged-out users) and a very quick check on the site you referenced, Alexis Jazz's approach after visiting the initial page is to rewrite the URLs on the page to add a "withgadget" URL parameter. As discussed in the archive, it's not a universal solution: you'll be able to surf from Wikipedia page to Wikipedia page and the URLs will be rewritten, but if you come from an external site, such as from an external search engine, the original URL will be requested and delivered to your browser. isaacl (talk) 00:44, 21 June 2023 (UTC)
As you may have seen on Wikipedia:Dark mode, this has been requested in the past, including at meta:Community Wishlist Survey 2023/Reading/Dark mode, and the WMF web team is working on it. As I understand it, implementation is challenging as a lot of the layout, colour, graphics, and so forth are controlled by the editing community, and so it will have to be involved and learn how to design for both light and dark modes. In the meantime, you can try some of the options described on the dark mode page. isaacl (talk) 21:03, 20 June 2023 (UTC)
  • I came to support this on the assumption no such thing ever existed here (occasionally I'll use a Chrome extension), I would certainly support making this button more obvious as I've been here 10 years and was none the wiser that this even existed. –Davey2010Talk 23:22, 20 June 2023 (UTC)

"Default summary" gadget flexibility for WikiProjects

The "Default summary" gadget (first gadget under the "editing" section of the "gadgets" tab in the user preferences) allows you to quickly and easily select common edit summaries. But if you're making changes in the name of a WikiProject, chances are you've got your own set of project-specific default edit summaries (like "Fix misspelling found by Wikipedia:Typo Team/moss – you can help!" for Typo Team/moss). The gadget should allow you to add custom default edit summaries. 110521sgl (talk) 15:08, 22 June 2023 (UTC)

@110521sgl: There is a user script that offers similar functionality, see User:Enterprisey/CustomSummaryPresets (I haven't tried it, though). —Kusma (talk) 15:17, 22 June 2023 (UTC)
Your web browser probably "remembers" your previous edit summaries. Usually, all you have to do is start typing an edit summary, and see what it suggests. WhatamIdoing (talk) 08:22, 24 June 2023 (UTC)

Putting captions in {{multiple image}} galleries in infobox

There were some discussions in Wikipedia talk:WikiProject Cities about this, but I thought that a proposal here is more appropriate because a lot of articles outside of cities articles will be affected by this. Currently, here are two options for putting the captions in {{multiple image}} galleries in the infobox:

  • Option 1, caption per image
    Option 1, caption per image
  • Option 2, caption at the footer
    Option 2, caption at the footer

It would be unwise to force all articles to follow either way to arrange captions in the infobox, but I think that there might be a consensus on what option is preferred in specific situations.

Here are some advantages of both approaches:

Option 1

  • Less confusing caption placement, no need for awkward "In clockwise" captions
  • Easier maintenance for editors

Option 2

  • More compact, take up less valuable vertical space, especially for multi-line captions
  • Allow usage of custom galleries

CactiStaccingCrane (talk) 08:02, 25 May 2023 (UTC)

Pinging people in the WikiProject Cities discussion: Dkriegls, Sdkb, WeaponizingArchitecture, Xeror CactiStaccingCrane (talk) 08:06, 25 May 2023 (UTC)
Whatever you do, avoid "clockwise from top left" as it becomes incorrect on narrow screens (at least in some skins). —Kusma (talk) 11:53, 25 May 2023 (UTC)
It's also not accessible. Always use actual order. —TheDJ (talk • contribs) 12:32, 25 May 2023 (UTC)
What do you mean by "actual order"? I get that it's not good if it can dynamically change (but then that's potentially an issue with any description, e.g. two lines of three becoming three lines of two) but if it can't (e.g. it's a single image file) what is wrong with "clockwise" if that is how they are arranged? Thryduulf (talk) 13:14, 25 May 2023 (UTC)
The order (in the document) of these images is left to right and top to bottom for each line. Like a (western) book. Clockwise is a visual description that goes left to right, top to bottom, right to left and then bottom to top. That does not match the document order and thus should not be used, as screen readers will only convey document order and it's also not resilient against reordering in different visualizations like for instance on mobile. —TheDJ (talk • contribs) 14:46, 25 May 2023 (UTC)
It's taken me a couple of times reading what you wrote, but I understand it now. Thank you. Thryduulf (talk) 20:57, 27 May 2023 (UTC)
  • This seems a function of stuffing too many decorative images into the infobox, contrary to WP:GALLERY. A better option than either is not to create the problem in the first place. CMD (talk) 11:32, 25 May 2023 (UTC)
  • New York City has ten! tiny infobox images. Four captions spill over two lines, and there's an extra empty line below each. The gallery alone takes more than one screen on my 7" smartphone (60% of readers come from mobile). One caption, three images max would be my recommendation in this case. Ponor (talk) 11:55, 25 May 2023 (UTC)
    NYC should definitley be shortened WeaponizingArchitecture | scream at me 12:00, 25 May 2023 (UTC)
    Personally I think that a picture of a skyline is enough. But people kept arguing that urban skylines are kinda samey, so let's add a notable place to the infobox. And another, and another, and another, ... CactiStaccingCrane (talk) 12:04, 25 May 2023 (UTC)
    I perfer option 2 personally. I never found it too hard to grasp (this might be different for others), and i believe it makes the infobox look a lot cleaner (there's a noticeable gap between a caption and the image below said caption). WeaponizingArchitecture | scream at me 12:08, 25 May 2023 (UTC)
  • I don't understand why we would want (or need) to say anything other than either option is allowed, because (as the OP notes) which is better depends on the specific situation. If one genuinely is preferred in some situations (and the OP gives no examples) then we don't need the guidance because it's already preferred. Thryduulf (talk) 12:08, 25 May 2023 (UTC)
    I said so because there are many broad concept articles such as Physics or Ancient history that use a gallery because the subject it is talking about is too broad. Should these articles be treated the same as the consensus for galleries in city articles? CactiStaccingCrane (talk) 12:13, 25 May 2023 (UTC)
    I think you misunderstand my comment - I'm not saying the consensus for one topic area should apply to another, indeed exactly the opposite - sitewide guidance should simply state that either option is allowed. It's completely irrelevant whether different types of articles most commonly use the same or different options, and equally irrelevant which options those are. If most e.g. city articles use e.g. option 1, then we don't need to say that option 1 is preferred for city articles, because that's the status quo. If a specific city article uses option 2 but someone would prefer it to use option 1, then either be bold or propose a change on the talk page. Thryduulf (talk) 12:30, 25 May 2023 (UTC)
    Certainly not, especially if that would mean pressure to include such images where this isn't actually such a great idea. The article Chemistry wisely avoids starting with lots of somewhat-relevant images, while Physics displays a screenful of unexplained example images (at least on my phone) before even telling me what the article is about, and would be better without a lead image (in my personal opinion). Unifying this across all Wikipedia articles is at best an exercise in futility, but more likely actively harmful. —Kusma (talk) 13:57, 25 May 2023 (UTC)
  • Cities are a better fit for infobox collages than many other articles, but they're often done poorly and overstuffed with too many images. I agree with Thryduulf that there's nothing for us to do at the pump here because it's contextual. However, the extra space that option 1 takes up is really a big cost, especially for infoboxes that are already overlong (as many of the ones with galleries are) — just how much longer they make the collage would be more obvious if the examples used the same city rather than different ones. Other factors that might influence which option is better are how obvious the images are and therefore how likely readers are to seek out the captions (if very likely, option 1 could be better), and whether or not it's possible to shorten all the captions to what will be a single line on most devices. Also, as an additional downside for option 1, I don't like how it breaks up the visual cohesion of the collage.
    And as I said at the last discussion, I think ultimately captions that appear on hover like the packed-hover gallery tag option could give us the best of both worlds. Is there any way to get that to work for {{Multiple image}}? {{u|Sdkb}} talk 18:04, 25 May 2023 (UTC)
    The one thing I really care about with collages is that we not use just a single file, as this makes it more difficult to modify the set of images (e.g. if a new better option becomes available, or if one is deleted), and results in an inferior experience for readers (where clicking on an image does not make it full-screen but rather just makes the collage full-screen). {{u|Sdkb}} talk 18:09, 25 May 2023 (UTC)
    I think that this would break mobile and print compatibility... am I right though? CactiStaccingCrane (talk) 15:03, 30 May 2023 (UTC)
    You're referring to the packed-hover thought, I presume? Packed-hover currently displays as "packed-overlay" for mobile, it seems. If we designed the feature well, we could handle those issues. {{u|Sdkb}} talk 15:19, 30 May 2023 (UTC)
    Yeah exactly. But still for print media this isn't ideal... CactiStaccingCrane (talk) 15:26, 30 May 2023 (UTC)
  • Avoid, or greatly reduce, collages/mosaics completely. Johnbod (talk) 02:25, 28 May 2023 (UTC)
    Should be encouraging the reduction of images of this nature. Moxy- 11:19, 29 May 2023 (UTC)
  • Agree with Johnbod and Moxy, especially for infoboxes. Regular galleries are fine Smallbones(smalltalk) 02:13, 5 June 2023 (UTC)
    Article like Detroit with 11 files in the lead are a scrolling nightmare. New York City even worse ....15 files for 4 paragraphs of info....so long need to scroll 3 times before any prose....most will never even read the first paragraph before moving on - data Moxy- 02:12, 6 June 2023 (UTC)
  • Option 1 is better; don't make the reader struggle to figure it out. I also agree that fewer images are probably a good idea.  — SMcCandlish ☏ ¢ 😼  06:21, 7 June 2023 (UTC)
  • Option 1 - I was introduced to this design a couple months ago and I agree, it is the best option here. Yes, option 2 is more compact, but the confusion caused by finding and locating which goes to which. It makes more sense to have the caption right under the image rather than a bunch of bluelinks at the bottom. Have a great day! DiscoA340 (talk) 19:30, 15 June 2023 (UTC)
  • Comment: I'm against making a deciding bureaucratic default option about this preference. Continue to leave it up to the editors to decide. If there is pushback on these problematic articles, then it sounds like a possible ownership issue or maybe editors think what is being called a problem really isn't one. Huggums537 (talk) 20:30, 15 June 2023 (UTC)
  • Option 1, but more importantly, encourage a reduction in the number of images used. Perhaps say something like "galleries for cities are easiest to view when limited to 1 skyline image and 2 to 4 landmarks.". Or something broadly along those lines. — Preceding unsigned comment added by Dkriegls (talk • contribs) 03:29, 21 June 2023 (UTC)
  • Option 1 makes it easier for readers to identify each image, but I would also prefer fewer images for infoboxes that are already quite long. With city articles where the history section of these is near the beginning it can leave little opportunity to place any historic images beside the related text and this has become more of an issue with vector 2022 repositioning the TOC. Examples being Reading, Berkshire where on my laptop the map of 1611 is pushed down to the end of the twentieth century, Northampton with an iron age picture beside prose on medieval history, and Cardiff where in order to illustrate the early history section the images have been placed on the left thereby sandwiching the text. EdwardUK (talk) 17:01, 24 June 2023 (UTC)

Notifications of articles

Hi all, I get link notifications of articles I have created. I can turn them off, but no-one else gets them. At least I don't know how to apply to get notifications of articles I didn't create. Could someone apply to receive the notifications of the articles I created? And can I apply for notifications of articles I did not create? Paradise Chronicle (talk) 19:06, 22 June 2023 (UTC)

I am not aware that this functionality exists, but it would have many useful applications. —Kusma (talk) 20:37, 22 June 2023 (UTC)
@Paradise Chronicle I think this is phab:T70060/phab:T66090? 192.76.8.66 (talk) 10:56, 23 June 2023 (UTC)
You are right. From 2014. But they have good ideas and I hope they can do it. Paradise Chronicle (talk) 15:09, 23 June 2023 (UTC)
See https://phabricator.wikimedia.org/T58362; after this is implemented, a bot might be able to do what you ask. Frostly (talk) 21:18, 25 June 2023 (UTC)
I hope, but I am not sure; they discuss around user created notification and for one issue discussed there since 2019, I already have a solution. To get notified of a new article in a category, I watchlist the category. I believe user created notifications are good for wikiprojects. Paradise Chronicle (talk) 21:50, 25 June 2023 (UTC)

Galleries

Ten years ago, galleries were updated. Whereas before, the only option for galleries was this:

Now, you can choose from four other gallery modes, of which "packed" rapidly became the default.

At the time, it was assumed that the default style - what would be used if no parameter was set - would likely be changed to packed after a while.

We then... forgot about this.

So, I propose that, perhaps after a bot is used to add a mode=traditional to all remaining unspecified galleries to minimise any potential disruption, that we go ahead and finally make packed the default. I'd also suggest making the default heights parameter for packed images be 200px, because, well that seems to be the default nowadays. Rare I see a gallery that's not mode=packed and a height around 180-250. I believe the default is still 120px, which is way too small for modern high-resolution monitors in pretty much every case (seen below)


Adam Cuerden (talk)Has about 8.4% of all FPs. 05:32, 24 May 2023 (UTC)

Sounds like something that should be changed with a serverside configuration option, and not by making changes to thousands and thousands of pages. —TheDJ (talk • contribs) 12:29, 25 May 2023 (UTC)
  • Support changing the default type to "packed" and default size to 200px, per nom. The traditional mode looks awful, with huge margins that decrease the size of the images themselves. I'd say that in 90% of cases, it's used only because it's the default. Regarding the details of implementation, to TheDJ's point, I'll leave that to technical folks familiar with the area. But disagreement about that shouldn't stop us from moving forward with the overall idea. {{u|Sdkb}} talk 19:20, 25 May 2023 (UTC)
  • Support, though not sure how best to implement. This is overdue IMO. Garuda3 (talk) 20:07, 25 May 2023 (UTC)
  • Extremely strong oppose I'm amazed at this proposal. I'd strongly deny that packed mode has become the default. It is common for articles on cities etc, but not for those on art, history etc. There was a lengthy discussion a couple of years ago (can anyone find it?) with various examples tested, which concluded that this was generally not a good option for art, especially because the images clash and "bleed" into each other. Can't you be bothered to find out what the default height now is? Please do so before proposing to change it. I agree it is too small, but so is the main default at 220 px. Much better to change that. Johnbod (talk) 03:49, 29 May 2023 (UTC)
    Perhaps Talk:Paul Signac#Use of packed gallery? DanCherek (talk) 03:58, 29 May 2023 (UTC)
    Thanks, that was it - the Rfc bit below. Note that this was a formal Rfc (which this should probably have been), that found no consensus to use "packed" at that article. The conclusion has often been extended to other art articles. Johnbod (talk) 04:06, 29 May 2023 (UTC)
    I don't care what the default is; I care what it ought to be. The situation seems to be that pretty much everyone agrees that packed mode is best in many circumstances. For art articles, as at the linked RfC, it appears that (as of 2015) slightly more than half preferred packed and slightly less preferred the old mode with tiny images and gigantic margins. Nothing about that is persuasive to me.
    Note that this proposal would not change the gallery type on existing articles, e.g. it would not override the 2015 RfC. What it would do is change the default going forward. So if editors at a particular article want tiny images and gigantic margins in order to give images more "dignity", they will continue to be able to do so. But defaults are powerful, and editors should be steered toward the modern packed format by default. {{u|Sdkb}} talk 04:29, 29 May 2023 (UTC)
    @Johnbod: This will, by no means, forbid articles from using a traditional style gallery, indeed, I even suggested that a bot could be used to add parameters to all galleries currently used that don't already have parameters to keep them in their current state.
    This is a discussion about what the default should be, a.k.a. what happens if a user just creates a gallery with no other parameters going forwards. It's not meant to override decisions on a particular article, it's meant to decide what should happen if no decision is made. Adam Cuerden (talk)Has about 8.4% of all FPs. 19:03, 29 May 2023 (UTC)
    If we change the default state, that will affect all articles presently using a gallery with no options specified (and probably those with certain options specified). There's no "going forwards", it's retrospective. That is what default implies. --Redrose64 🌹 (talk) 20:42, 29 May 2023 (UTC)
    @Redrose64, you're ignoring the suggestion of a bot, which Adam laid out clearly both in the proposal and directly above. {{u|Sdkb}} talk 20:53, 29 May 2023 (UTC)
  • Support Tiny images that you can't see are no good. Excessive margins are no good. Leijurv (talk) 06:37, 29 May 2023 (UTC)
  • Oppose per Johnbod. Visual art pages are a major user of galleries, and when Johnbod says that he's an 'Extremely strong oppose' then I consider that he's pretty much speaking for almost all of the editors who edit visual arts pages. Randy Kryn (talk) 23:47, 29 May 2023 (UTC)
    @Randy Kryn and Johnbod: I don't think either of you are understanding the proposal: This isn't to disallow the current default style; it's to make it use <gallery mode=traditional>, instead of being the default when you just put in <gallery> A bot can readily be used to make sure that no pages change by adding that mode=traditional in to all galleries in use that don't have mode= set before we change the default over. Adam Cuerden (talk)Has about 8.4% of all FPs. 04:25, 30 May 2023 (UTC)
  • Oppose, while I generally like packed mode, I don't think the convenience of not having to choose packed mode is worth the hassle and the breaking of the layout of old revisions. Templates could be used to achieve similar convenience without configuration changes. —Kusma (talk) 06:01, 30 May 2023 (UTC)
    I'd argue it's not just about convenience, but rather has an effect on content. Editors, and particularly newer editors not versed in all the options, very often just go with the default. Retaining the old giant-margin format as the default means in practice that it will be used a lot more frequently. {{u|Sdkb}} talk 06:11, 30 May 2023 (UTC)
    I'm fine with increasing the default size, and also finding ways to explain the many options available to new editors. Johnbod (talk) 15:02, 30 May 2023 (UTC)
    What's your proposal for better explaining the options to newcomers? {{u|Sdkb}} talk 15:33, 30 May 2023 (UTC)
    I don't have one, but you seem to know everything, so what's yours? We should also explain the various options for fiddling with the sizes and shapes in "traditional galleries. Johnbod (talk) 03:12, 5 June 2023 (UTC)
    I don't think there is a good one. Every explanation that we add contributes to banner blindness. The easiest system for newcomers is one that chooses a good option by default. Thus why I support the proposal. {{u|Sdkb}} talk 01:55, 6 June 2023 (UTC)
    I think new editors are likely to copy what they find elsewhere or to use buttons on their editor. Could various editors (Visual?) have gallery buttons that default to packed mode? I don't use edit toolbars so I don't remember what they can do. —Kusma (talk) 22:53, 5 June 2023 (UTC)
    The visual editor has a dialog box with an "Options" tab, and you can try out the different ones. Try User:Whatamidoing (WMF)/sandbox#Gallery if you want to see what it looks like. I think everything except the Slideshow setting displays correctly inside the editing window. Whatamidoing (WMF) (talk) 03:28, 6 June 2023 (UTC)
    I saw the gallery, but where is Uranus? (Please, don't say something silly such as; "it's located between the buttocks".) Thanks. Huggums537 (talk) 17:16, 15 June 2023 (UTC)
    Aww, why did you so nicely take the bait and provide the set-up if you're not going to let her use the punch-line she's got prepared? — JohnFromPinckney (talk / edits) 20:01, 18 June 2023 (UTC)
  • Support, the packed mode is obviously better for most uses. With the bot adding "mode=traditional" art pages will not be affected. Really, all current pages will not be affected. It's only new pages that will be affected, and those who like having a traditional gallery on a new page can have it easily enough (just add "mode=traditional") Smallbones(smalltalk) 02:07, 5 June 2023 (UTC)
  • Support The default gallery makes the images way too small, creating accessibility issues. Packed mode is better in its use of space. Carpimaps talk to me! 03:01, 5 June 2023 (UTC)
    It's unfortunate that this proposal conflates two issues, "mode" and size. In the current default (whatever that is, which no-one seems to know) the images are too small, and the margins too wide. That could (and should) be fixed as a separate thing. I'd imagine packed mode has its own accessibility issues, with the images butted up tight. We should explore that aspect. Johnbod (talk) 03:12, 5 June 2023 (UTC)
  • Comment. There is also the issue of default size of images. WMF denied Wikivoyage's request to increase the project-wide default on image sizes, as that would add a server load of creating and storing thumbnails of most used images in that size. This implies default image sizes should not be changed by project, but for all projects using Wikimedia's servers. I don't know how common galleries are, but I suspect that the want for larger images is not restricted to galleries. Ergo, one should talk to the technical folks at WMF, and use their advice in getting forward, instead of passing a decision that cannot be implemented because the power is by other people. There should probably also be a discussion on Meta, where one should involve the other projects and language versions. –LPfi (talk) 09:43, 5 June 2023 (UTC)
    As I understand it, it would actually be easier on the servers if they migrated wiki by wiki, starting with smaller ones (=fewer pages/fewer images), instead of switching everything all at once. (The problem isn't really disk space itself, but the need to re-parse everything all at once.)
    Also, while the English Wikipedia is a huge challenge, I understand that it is feasible with some advance preparation. I wouldn't be surprised if they asked for all image sizes in the ~top 1,000 most popular articles (or even the top 10K) to be manually switched to the goal size weeks in advance, but it could be done.
    BTW, slowly increasing the size from one to the next to the next is not at all desirable. If you want the default image size increased, this is definitely a "rip the bandage off" task. Think about the size you'll want ten years from now, remember that it will be a big change that will take people a few weeks to get used to, and switch straight to that. Whatamidoing (WMF) (talk) 19:50, 5 June 2023 (UTC)
    At the moment (and for many years past) any fixed size above the default is highly likely to be reverted, whether it used the "upright" system or specifies fixed pixels. This I think goes beyond what MOS:IMGSIZE says ("As a general rule, images should not be set to a larger fixed width than 220px (the initial base width), and if an exception to this general rule is warranted, the resulting image should usually be no more than 400px wide (300px for lead images) and 500px tall, for comfortable display on the smallest devices "in common use" (though this may still cause viewing difficulties on some unusual displays).") but is the reality. That would need changing first. Johnbod (talk) 21:09, 5 June 2023 (UTC)
    Of course. But I think we could set this temporarily, until the servers adjust. Other wikis have done it in the past to get bigger images by default, and while we are unique here, we aren't incapable. It would take a certain about of effort to warn the obvious folks (e.g., AWB users), but it's all feasible. A bot run with a clear edit summary usually works for "counterintuitive" changes to wikitext, and then run the bot again to remove all the |300px settings a month after the switch is made. The open question is: Do experienced editors want to request the change? If we do, the worst they will say is "no, not this year". Whatamidoing (WMF) (talk) 03:25, 6 June 2023 (UTC)
  • These three versions all look basically identical on my device. There's transparent boxes around each image in the top version and the images are slightly larger in the middle version. I'm not sure what this proposal is aiming at accomplishing. Folly Mox (talk) 05:16, 6 June 2023 (UTC)
    It would remove the transparent boxes around each image. Whatamidoing (WMF) (talk) 02:18, 8 June 2023 (UTC)
  • Strong support raising the default resolution, that's something I've been meaning to propose for ages (200px sounds fine). 120px is fine for galleries of, say, flags, very simple clear images, but terrible for anything with any detail whatsoever like photographs. No opinion on packed vs. traditional - as Johnbod notes, I'd certainly consider traditional better for topics like art. But I suppose "packed" is better for small galleries of just 2-4 images. Maybe make it conditional on that, where it's packed for short galleries, traditional otherwise? But it could be argued that would be overly complicated. SnowFire (talk) 16:28, 10 June 2023 (UTC)
  • Support proposal. Much better as a default in the vast majority of situations, and easily overidden by any specialist editor who wants or needs the old version for a particular purpose. MichaelMaggs (talk) 16:38, 10 June 2023 (UTC)
  • Oppose per Johnbod and the bleeding/clashing issue. I have confirmed this. This issue is not present with the current default. It is a tradeoff. The current one isn't as visually pretty as packed, but it is more stable. Huggums537 (talk) 17:53, 15 June 2023 (UTC)
  • Support, galleries have been needing this for quite some time DimensionalFusion (talk) 08:29, 24 June 2023 (UTC)
  • Oppose. This would change what has been the default behavior for a long time. Any editors who have been using galleries have likely forgotten any old discussions of this issue, and expect it to remain the default behavior. Image gallery layout in articles has been optimized with this in mind; packed format does not work best for everything, and there are some examples where it would look atrocious (example: Order of the British Empire § Vestments and accoutrements). Anyone who wants the packed behavior can still achieve it with the simple addition of a keyword. This is not the sort of thing we should change on a whim based on a long-forgotten discussion, with absolutely zero analysis of how many articles it would affect (at least tens of thousands by my estimate) and whether it would be a net benefit or a detraction from the quality of those articles. —David Eppstein (talk) 00:25, 25 June 2023 (UTC)
    I urge the closer to discount !votes that are not !voting on the proposal. {{u|Sdkb}} talk 03:14, 25 June 2023 (UTC)
    The proposal to change the default mode of galleries, which my comment is entirely about? Why have you left this as a response to my comment? —David Eppstein (talk) 19:12, 26 June 2023 (UTC)

The Wikipedia:Welcoming committee—among other things—maintains a set of a set of welcome templates aimed at new users. Many of these templates include a list of helpful links. A proposal to drop links to Help:Your first article has been opened; your feedback would be welcome at WT:Welcoming committee/Welcome templates#Proposal: drop 'first article' link from all templates. Thanks, Mathglot (talk) 18:36, 28 June 2023 (UTC)

Input requested for merge proposal

If you'd like to share your opinion at Wikipedia talk:WikiProject Bosnia and Herzegovina#Merger proposal lists of dukes of Bosnia, that would be cool. Nederlandse Leeuw (talk) 21:48, 28 June 2023 (UTC)

Citing multiple portions of single source

Sometimes it is appropriate to quote from multiple locations within a single source. There is currently no convenient way to do this. Possible solutions include

  • Add parameters to {{sfn}}, e.g.,
    • |quote=
    • |section=
    • |section-url=
  • Add, e.g., |quoten=, |section-urln=, to CS1 templates
  • Provide templates for hierarchical citations

The last is the most desirable, but the first two would be easier to implement. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 12:24, 29 June 2023 (UTC)

I don't understand what you are looking for. Can you be more specific, maybe with a concrete example? {{sfn}} includes parameters for single page (p=), multiple pages (pp=), and location (loc=) which can be used for chapters, sections, etc. How would what you're suggesting differ from these? -- Random person no 362478479 (talk) 17:24, 29 June 2023 (UTC)
For the first option, |section-url= would eliminate the need to wikilink the location and |quote= is currently not available.
<ref> </ref>
{{sfn curIPCS
 | section     = Address processing parameters
 | section-url = https://www.ibm.com/servers/resourcelink/svc00100.nsf/pages/zOSV2R5sa231382/$file/ieac500_v2r5.pdf#page=41
 | page        = [https://www.ibm.com/servers/resourcelink/svc00100.nsf/pages/zOSV2R5sa231382/$file/ieac500_v2r5.pdf#page=44 24]
 | quote       = With read authority to facility class BLSACTV.SYSTEM, IPCS can look at the following storage (in addition to those storage areas it can access with no special authority): - • The ABSOLUTE storage - • Other ASIDs - • The data spaces owned by other ASIDs
 }}
...
{{sfn curIPCS
 | section     = Address processing parametersSETDEF subcommand - set defaults
 | section-url = https://www.ibm.com/servers/resourcelink/svc00100.nsf/pages/zOSV2R5sa231382/$file/ieac500_v2r5.pdf#page=257
 | page        = [https://www.ibm.com/servers/resourcelink/svc00100.nsf/pages/zOSV2R5sa231382/$file/ieac500_v2r5.pdf#page=259 239]
 | quote       = ACTIVE, MAIN, or STORAGE specifies the central storage for the address space in which IPCS is currently running and allows you to access that active storage as the dump source. You can access private storage and any common storage accessible by an unauthorized program.
 }}
...
{{cite manual
 | title        = z/OS 2.5 - MVS Interactive Problem Control System (IPCS) Commands
 | id           = SA23-1382-50
 | ref          = {{sfnref|curIPCS}}
 | date         = 2023-05-12
 | url          = https://www.ibm.com/servers/resourcelink/svc00100.nsf/pages/zOSV2R5sa231382/$file/ieac500_v2r5.pdf
 | publisher    = [[IBM]]
 | access-date  = April 6, 2022
 }}
For the second option, 
<ref>{{cite manual
 | title        = z/OS 2.5 - MVS Interactive Problem Control System (IPCS) Commands
 | id           = SA23-1382-50
 | date         = 2023-05-12
 | page1        = [https://www.ibm.com/servers/resourcelink/svc00100.nsf/pages/zOSV2R5sa231382/$file/ieac500_v2r5.pdf#page=44 24]
 | page2        = [https://www.ibm.com/servers/resourcelink/svc00100.nsf/pages/zOSV2R5sa231382/$file/ieac500_v2r5.pdf#page=259 239]
 | quote1       = With read authority to facility class BLSACTV.SYSTEM, IPCS can look at the following storage (in addition to those storage areas it can access with no special authority): - • The ABSOLUTE storage - • Other ASIDs - • The data spaces owned by other ASIDs
 | quote2       = ACTIVE, MAIN, or STORAGE specifies the central storage for the address space in which IPCS is currently running and allows you to access that active storage as the dump source. You can access private storage and any common storage accessible by an unauthorized program.
 | section1     = Address processing parameters
 | section2     = SETDEF subcommand - set defaults
 | section-url1 = https://www.ibm.com/servers/resourcelink/svc00100.nsf/pages/zOSV2R5sa231382/$file/ieac500_v2r5.pdf#page=41
 | section-url2 = https://www.ibm.com/servers/resourcelink/svc00100.nsf/pages/zOSV2R5sa231382/$file/ieac500_v2r5.pdf#page=257
 | url          = https://www.ibm.com/servers/resourcelink/svc00100.nsf/pages/zOSV2R5sa231382/$file/ieac500_v2r5.pdf
 | publisher    = [[IBM]]
 | access-date  = April 6, 2022
 }}
</ref>
Suggesting |section= as an alias of |loc= is just for consistency with other templates. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 19:19, 29 June 2023 (UTC) -- Revised 13:54, 30 June 2023 (UTC)
Can't all this be achieved with the existing |loc= as described here? Either way you may want to post at Template_talk:Sfn to make sure the people maintaining the template find your proposal. -- Random person no 362478479 (talk) 19:52, 29 June 2023 (UTC)
There are a number of ugly hacks that will work, but I'm looking for something that is automated and doesn't require repurposing parameters. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 13:54, 30 June 2023 (UTC)
Makes sense. -- Random person no 362478479 (talk) 22:35, 30 June 2023 (UTC)
The |ps= field was deprecated because it causes an issue when the {{sfn}} templates try to aggregate in the reflist, this will only make that problem worse. The current suggestion of using the |loc= field allows unlimited free text including wikilinks and urls. Two other points; short form references and meant to be short, once they are this big you may as well use a normal reference; and secondly you can't use {{sfn}} templates inside <ref> tags, it just causes a cite error, you must instead use one of the {{harv}} templates ({{harvnb}} or {{harvp}} for instance).
Another solution is to use one of those {{harv}} templates inside <ref> tags, and then include anything else outside the template but before the closing ref tag. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 20:38, 29 June 2023 (UTC)
{{r}} is pretty full featured and integrates well with existing template families. That might have the functionality the OP is seeking. Folly Mox (talk) 22:07, 29 June 2023 (UTC)
That's actually a good fit, especially as there's no method for linking the short form ref and cite on the example given. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 22:09, 29 June 2023 (UTC)
Personally I hate seeing the cryptic [1]:123 that {{r}} produces. I'm glad to see that m:WMDE Technical Wishes/extending references indicates someone is working on a real solution again. Anomie⚔ 11:01, 30 June 2023 (UTC)
I hope they're planning some way of warning editors who try to remove a ref that has extensions, and how it will behave when transcluded. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 11:05, 30 June 2023 (UTC)
I agree that that is both ugly and un-intuitive. Every time I see it I first think something is broken until I realize what it means. -- Random person no 362478479 (talk) 22:34, 30 June 2023 (UTC)
The {{r}} template has several issues, e.g., it requires manual construction of backlinks. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 13:54, 30 June 2023 (UTC)
The <ref>...</ref> around {{sfn}} was a typo and I have removed it. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 13:54, 30 June 2023 (UTC)

Edit menu to insert wrapped characters

There are many cases where a character, e.g., =, {, }, [, ], |, cannot be used directly but must be wrapped in a template, e.g., inserting an = requires {{=}}. Some of the templates, e.g., {{!(}}, are far from obvious, and a drop-down menu, for both edit and visual edit, would make inserting them less tedious. Menu support for wrapping templates, e.g., {{braces}}, {{brackets}}, {{tl}}, would also help; the menu item for, e.g., brackets would change the selected text foo to {{brackets|foo}} (rendering as [[foo]]). -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 13:45, 3 July 2023 (UTC)

RfC: Add selected births and deaths in year articles

Going to this RfC, it was passed to have the births and deaths split from year articles. However, I suggest some births and deaths listed, but some significant only. See this sandbox and another sandbox and yet another one for examples. What do you think? RMXY (talk) 11:10, 2 July 2023 (UTC)

What criteria did you use to determine which births and deaths were “significant” (and which were not)? Blueboar (talk) 11:20, 2 July 2023 (UTC)
@Blueboar: Significant is highly-covered worldwide, and long-term impact, like the death of Michael Jackson and assassination of Shinzo Abe. RMXY (talk) 11:24, 2 July 2023 (UTC)
Meh… not a hard “no”… but I think that criteria is somewhat subjective, and will lead to endless arguments. It will be less contentious to just say: ALL births and deaths should go in the separate “births and deaths by year” sub-article. Blueboar (talk) 11:35, 2 July 2023 (UTC)
The only deaths that may make sense would be the death of a prominent world leader (who was in office at the time of their death, i.e. Franklin Roosevelt, Queen Elizabeth). --Enos733 (talk) 19:18, 3 July 2023 (UTC)
But even then, those deaths would probably appear in the main timeline, not a separate section. - Enos733 (talk) 19:20, 3 July 2023 (UTC)
I remember Years articles being super contentious, and splitting birth and death events into separate articles having ameliorated that somewhat. I think if there's a standalone non-stub article about an individual's death, it could go in the main timeline per User:Enos733 above, but I doubt reintegrating a contentious subset of the birth and death subarticles into Year articles is likely to lead to positive outcomes. Folly Mox (talk) 19:34, 3 July 2023 (UTC)

WP:PRIMARYTOPIC Move Request

There's currently an ongoing move request that would benefit from wide community input and then a formal closure. Thanks! - Nemov (talk) 14:20, 5 July 2023 (UTC)

The use of AI in writing and editing Wikipedia articles

My colleagues and I are increasingly coming across articles and parts of it that have the signature of being either produced by something like ChatGTP or a really inexperienced writer. What I mean are articles that are written in perfectly good English, but make only limited to no conceptual sense as well as lacking a clear logical structure. An example is the article on Vitellogenesis, Not sure AI produced articles are objectively detectable and can be flagged to avoid corruption of the information landscape. In fact this non-sense is self-amplifying since this non-sensical text will be added to the input to more "language" models. THIS IS A GREAT DANGER TO THE INTEGRITY OF THE WIKIPEDIA PROJECT! Gpwagner54 (talk) 19:05, 3 July 2023 (UTC)

Gpwagner54, I share your concerns about AI and Wikipedia, but the example you chose, Vitellogenesis, is not a good one. That article was first written in 2006, and at least ten separate editors have worked to expand it over the years. Cullen328 (talk) 19:21, 3 July 2023 (UTC)
A spot check of the references shows that they are legitimate. Cullen328 (talk) 19:24, 3 July 2023 (UTC)
Could you point out which part of the article that seems to be the problem? Have a good day! ✠ SunDawn ✠ (contact) 04:05, 4 July 2023 (UTC)
Side topic -- We also need eyes open for bkf mirrors who have expanded to engaging in long discussions on borderline (ir)relevant topics on other boards. Can't make out those too. Lourdes 04:21, 4 July 2023 (UTC)
The article had a substantial revision on 27 November 2022 (a few days before ChatGPT was released). Prior to that revision, the lead sentence described vitellogenesis as a process that occurred in "lecithotrophic organisms". Now it is described as a process that occurs with "non mammalian vertebrates". Prior to that revision, as well as after, there is a little bit of content about vitellogenesis in insects (insects aren't vertebrates). There was also an unsourced sentence about vitellogenesis in mammals that was removed in that revision. Presumably that sentence pertained to monotremes (the only oviparous mammmals). The image in the article (both before and after the revision) depicts vitellogenesis in a flatworm (invertebrate). Given the timing, it's unlikely that AI is responsible for the content, but the article is now incorrect. Vitellogenesis is not a process that only occurs with non-mammalian vertebrates. Plantdrew (talk) 16:07, 5 July 2023 (UTC)
@Gpwagner54 Wikipedia:Large language models and its talkpage may be of interest to you. We've also encountered editors using ChatGTP or whatever on WP-discussion pages. Gråbergs Gråa Sång (talk) 09:44, 4 July 2023 (UTC)

Redirects for article titles ending in periods

I am proposing that we mass-create redirects for articles with titles ending in periods and some other punctuation characters, such as the one to Mail Boxes Etc. from Mail Boxes Etc

For background, and to give your views, please see or join the discussion at VPT. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:21, 8 July 2023 (UTC)

AFDs

This isn't really a proposal but I have no idea where to post this request. We really need a few more administrators and dozens of experienced editors to participate in article deletion discussions. Right now, there are a handful of regulars, who I appreciate greatly, but they have an outsized influence on what articles are Kept or Deleted on the project. An article can be deleted based on a nomination and one editor who agrees with the nomination. We really need to hear from more editors about what articles they believe deserve to be on the project. We also have seen a great many brand new editors and sockpuppets showing up to participate in AFDs and their lack of experience or their phoniness isn't always apparent to the closer. It's disheartening to see editors with a few dozen edits weighing in on an article's deletion when we have so many great content creators who know about the subjects under debate and the relevant sources. I know that AFDs can be a tense area to participate in and involves an investment of time and effort but we could really use your participation in a few discussions a week or more. Follow one of the deletion sorting topics to focus in articles of particular interest to you. Thank you for considering helping out in some capacity. Liz Read! Talk! 02:42, 14 June 2023 (UTC)

I should specify that this appeal is just coming from me and is based on my experience participating in the AFD area since January 2022. It seems like there used to be many more editors involved in this area but they may have gotten burned out. We need them back as well as some new blood! Liz Read! Talk! 02:44, 14 June 2023 (UTC)
The existence of this thread has a certain irony given that, just a few sections up, there is a discussion about AfD discussions from which the takeaway seems to be that a broad swath of good-faith participants -- one of whom has been an administrator since 2005! -- need to "stop participating disruptively at AfD." (As far as I can tell, those people do not seem to have been alerted to the fact that their supposed "disruptive" behavior was under discussion.) Gnomingstuff (talk) 03:11, 15 June 2023 (UTC)
Yes, okay, I will transclude it soon. jp×g 07:33, 16 June 2023 (UTC)
should article deletion discussions involve everyone or simply the writers of the article Pastalavist (talk) 19:18, 19 June 2023 (UTC)
@Pastalavist, all editors are welcome to discuss articles for deletion nominations. Schazjmd (talk) 19:26, 19 June 2023 (UTC)
  • In response to this request I am breaking my self-imposed exile from AFDspace and am making a goal of opining in at least 5 relisted AFDs per day (or if I run out of relisted ones, at least 5 AFDs) for the next 30 days. We'll see if I make it, but it's already been educational for me. In particular, focusing only on relisted AFDs (rather than my earlier practice of zeroing in on the noms that make me say "they nominated what?") is having some interesting effects on my perspective. (I am apparently less of an inclusionist than some nominators these days.) -- Visviva (talk) 01:06, 22 June 2023 (UTC)
  • @Liz: (and others), a general reminder that one of the best way to increase participation is to tag articles with WikiProject Banners, so they get reported through WP:AALERTS. Headbomb {t · c · p · b} 17:46, 2 July 2023 (UTC)
  • The night you posted this, I had begun my vacation xD So that wasn't doing any favors. I'll resume my participation shortly. SWinxy (talk) 13:23, 3 July 2023 (UTC)
    Side question Liz, have you noticed that relists and closures have been lagging behind the 7 day discussion period? I began closing and relisting at the start of June iirc, and there were a lot of articles that had not been closed or relisted for more than 8 days. SWinxy (talk) 13:32, 3 July 2023 (UTC)
  • Comment I've been a regular participant in AFD for the last year or so; the experienced editors that regularly participate has gone down in numbers. We see many that only show up when an article is being discussed that they were involved with creating. Any long-time editors are welcome to help, there are a few notability criteria to learn, but it's easy enough to get up to speed. Oaktree b (talk) 14:29, 8 July 2023 (UTC)

IPA pronuciation

Hello Wikipediaers

I love wikipedia! One of the few things I think that needs fixed is the sole use of IPA style for pronunciations. I think that you should have both IPA and a usable style. When I say usable, I mean something like what is used in most dictionaries. I realize the IPA style is more precise and defined, but it is also mostly useless unless you are one of the one in a million folks who have bothered to learn it (that is my best guess using the order of magnitude estimation method, I would also be willing to accept one in one hundred thousand, in other words almost no one). Also, IPA is an imperfect system at best. So why solely use a fairly flawed system that almost no one understands?

Bill Hicks 2601:548:C203:1F70:54FA:7FFF:E5C3:5E80 (talk) 12:26, 14 June 2023 (UTC)

I agree that the IPA can be sʌmwʌt kɹɪptɪk (somewhat cryptic, that is) but any simplified pronunciation would have to heavily regulated to ensure cohesiveness, not to mention actual usefulness. Interpretation of vowels varies widely not only between dialects, but between words themselves in the same dialects, (e.g., bit, bite), making any kind of simplified latin-alphabet pronunciation guide would be a very difficult task, to say the least. Edward-Woodrow :) [talk] 22:45, 14 June 2023 (UTC)
An IPA tool for speaking words is being worked on, but it is a hard project as it is relying on external pronunciations; some early mockups are at testwiki:Phonos. — xaosflux Talk 23:16, 14 June 2023 (UTC)
I think this will be the best solution. People may not know IPA, but they don't need to if they're able to listen to a recording. {{u|Sdkb}} talk 22:33, 25 June 2023 (UTC)
I would urge caution about the number of different things that aren't content that we put in the top inch of an article. Pronounciations, hatnotes ... all of which crowds the content further down the page.--Wehwalt (talk) 23:00, 14 June 2023 (UTC)
Agreed. revision 1159880420 of Hoelun is just one example of this, where pronunciations, dates, alternate names, and etymologies crowd out the meat of the lead. Edward-Woodrow :) [talk] 23:03, 14 June 2023 (UTC)
Yes. See MOS:LEADCLUTTER. —David Eppstein (talk) 19:08, 26 June 2023 (UTC)
The IPA template should be linked to a chart that will explain, and its symbols shouldn't be unfamiliar to those who want to learn exact pronunciation and aren't far from symbols used in dictionaries. However, there is also Template:Respell, which is for English words only and can be a more accessible way to convey such important things as which syllables are emphasized. Dhtwiki (talk) 23:26, 14 June 2023 (UTC)
This is a very American complaint. IPA is "what is used in most dictionaries" everywhere except the US and perhaps anglophone Canada, while Wikipedia is a global project. And as the table in Pronunciation respelling for English makes clear, there is no single standard or predominant style of respelling (so Wikipedia uses its own). Nardog (talk) 23:34, 14 June 2023 (UTC)
I'm someone who has never bothered to learn IPA, but I've also never had a problem following the link to Help:IPA/English and using the key to decode IPA symbols. Barnards.tar.gz (talk) 11:53, 16 June 2023 (UTC)
Hovering over each character also helps, giving a tooltip such as "/æ/: 'a' as in 'bad'" without having to open and pore over a table. Certes (talk) 15:48, 20 June 2023 (UTC)
We also have Template:Respell which might be what you want. SWinxy (talk) 13:05, 3 July 2023 (UTC)

Phhht. "its symbols shouldn't be unfamiliar to those [who are like me]". And ~2/3 of native English speakers are Americans. The IPA is gobbletygook to me and lots of other people. We're count too. But, the editor corps is kind of steeped in bourgeois snobbery, and it's heavy lifting to get editors to realize and correct for that. But we should should always try to improve. Herostratus (talk) 02:42, 9 July 2023 (UTC)

Following about six weeks of intensive discussion, some changes have recently been rolled out to the WikiProject banner shell template. An example is shown below. The design is very much open for further changes and improvement and we would welcome any comments (positive or negative) from editors at Template talk:WikiProject banner shell#Discussion about new design

— Martin (MSGJ · talk) 16:16, 9 July 2023 (UTC)

For everyone not in the know, there have been a lot of complaints (including from me) since this was rolled out after a local consensus decision to deploy this across all Wikipedia pages was made at the above location by 10 editors. These complaints include the color of the sectioning (which was pure white originally and just an assault on the eyes) and how the entire format just doesn't look as professional or useful, especially when you have several projects with class, importance, and other features included. It becomes a color attack. Furthermore, as I just mentioned, there's been a lot of consternation that this was deployed without actually involving the community in the first place and was just a decision made by a few people on a small template talk page. The response from those involved has largely been along the lines of "that's how we've always decided on template changes" and "it's already deployed, so we're not going to do anything about it". I have a massive problem with this being how "consensus" is determined for such a change that impacts all of Wikipedia. SilverserenC 16:22, 9 July 2023 (UTC)
"it's already deployed, so we're not going to do anything about it": I do not think this is true. White background and bright bubbles were deployed initially which were changed to cream background and pale bubbles, because in fact they did something about it. And so is here this notification. —CX Zoom[he/him] (let's talk • {C•X}) 17:04, 9 July 2023 (UTC)
You're emphasizing my point. I didn't mean "do anything about it" to be changing minor aspects of the deployment. I meant "do anything about it" as in reverse the deployment. Even now, I'd guess that all of the 10 involved in the deployment have no inclination to even allow a reversal decision to be made or discussed. Which is one reason why y'all keep trying to make it about "what needs to be changed", rather than about the entire idea of allowing the deployment at all. SilverserenC 17:53, 9 July 2023 (UTC)
A RfC on the new design has now been opened: RFC on WikiProject Banner shell redesign. All comments and suggestions welcome. SilkTork (talk) 18:04, 9 July 2023 (UTC)

Improved navigation between articles using Template:Excerpt

A proposal has been made to enhance Template:Excerpt to improve the navigation between source and target pages for those using the 'edit' link at the source page. If you are a fan of {{Excerpt}} or its underlying module, your feedback would be appreciated at Module talk:Excerpt#Proposal: pre-load a helpful preview editintro notice on clicking 'edit' in hatnote. Just a friendly discussion, no Rfc or even disagreement; just looking for ideas and support (or not) or anything we may have missed. Thanks, Mathglot (talk) 23:45, 9 July 2023 (UTC)

Infobox RfC on the biography of Richard Wagner

There's an ongoing discussion about adding an infobox to the biography of Richard Wagner. Community feedback is welcome. Thanks! Nemov (talk) 13:48, 11 July 2023 (UTC)

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.
RfC was proposed prematurely, Hence, it has been withdrawn. Prarambh20 (talk) 10:19, 7 June 2023 (UTC)


Should pages in the Category:Emotion and other related pages on human expression have a dedicated Infobox, either an existing one or a new Infobox (such as Template:Infobox emotion) specifically designed for emotions?

Currently, all the pages related to emotions, moods, and virtues do not include an Infobox. While it is true that the topic of "Emotion" is best expressed and explained through descriptive phrases, an Infobox can provide a concise overview of general information and characteristics of a particular emotion at a glance. Additionally, it may assist readers in understanding the basic features, specifications, and related groups of an emotion or expression. According to the MOS:INFOBOXUSE, no page is prohibited from having an Infobox, nor is it mandatory. Therefore, utilizing an Infobox could potentially enhance the presentation of information in a structured and easily understandable format.

To provide a basic idea, an Infobox about emotions could include parameters such as the extreme and mild versions of the emotion, synonyms, opposites, opposite extreme and mild emotions, dyads (based on the wheel of emotions), primary, secondary, and tertiary groups of the emotion, disposition or outlook, term meaning and origin, as well as general characteristics like symptoms, expression, causes, specialty, duration, evolution, treatment, diagnosis, coping mechanisms, and neurological or psychological factors. However, it's important to note that these are general ideas for the potential information that could be included.

In conclusion, considering the benefits an Infobox can provide in terms of presenting information in a structured and accessible manner, it is worth considering whether the pages in the Category:Emotions and related topics should have an Infobox.Prarambh20 (talk) 21:17, 6 June 2023 (UTC)

  • I think this RfC is premature without an example to go off of and then the WP:RFCBEFORE discussion to work out any problems. My main concern would be that anything in an infobox like this would be both simplistic and subjective. It's not like date of birth, for example, where it's a brief fact with a single correct answer. Thebiguglyalien (talk) 02:00, 7 June 2023 (UTC)
  • Tend to concur with Thebiguglyalien. This isn't really RfC-ready yet, and it's hard to not picture an infobox that is very subjective and thus not appropriate.  — SMcCandlish ☏ ¢ 😼  06:17, 7 June 2023 (UTC)
  • Infoboxes work best with concrete subjects and least well with abstract concepts, and topics like emotion and happiness are generally the latter. Having a look at a few random emotion articles, I'm struggling to see what useful information an infobox would contain but I'm not a subject matter expert and haven't spent long thinking about it, so I'm not going to say these articles should not have infoboxes without seeing specific examples. I also agree with Thebiguglyalien that you've gone to an RFC too early. Thryduulf (talk) 09:53, 7 June 2023 (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.

Provide template to wrap LaTeX markup

Currently wiki allows LaTeX within <math>...</math>. This works well as long as wiki does not support MATHML, but is confusing as soon as MATHML comes into the picture, since HTML uses <math>...</math> to wrap MATHML. I propose adding a new template (LaTeX?) for wrapping LaTeX and deprecating use of <math>...</math> for that purpose. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 12:34, 29 June 2023 (UTC)

Which wikis support MathML ? And do they do any sort of content validation to make sure they have not added massive security holes into the software ? —TheDJ (talk • contribs) 14:21, 4 July 2023 (UTC)
None that I know of. However, there have been discussions, and if it ever happens the current use of <math>...</math> will be an issue. --Shmuel (Seymour J.) Metz Username:Chatul (talk) 15:28, 4 July 2023 (UTC)
You know that the wiki math tag is already translated into mathml markup as part of the wiki-to-html conversion process, right? For instance <math>e^{2\pi i}=-1</math> gets translated into 
<span class="mwe-math-mathml-inline mwe-math-mathml-a11y" style="display: none;"><math xmlns="http://www.w3.org/1998/Math/MathML" alttext="{\displaystyle e^{2\pi i}=-1}"> <semantics> <mrow class="MJX-TeXAtom-ORD"> <mstyle displaystyle="true" scriptlevel="0"> <msup> <mi>e</mi> <mrow class="MJX-TeXAtom-ORD"> <mn>2</mn> <mi>π<!-- π --></mi> <mi>i</mi> </mrow> </msup> <mo>=</mo> <mo>−<!-- − --></mo> <mn>1</mn> </mstyle> </mrow> <annotation encoding="application/x-tex">{\displaystyle e^{2\pi i}=-1}</annotation> </semantics> </math></span><img src="https://wikimedia.org/api/rest_v1/media/math/render/svg/4c00cccd54f9cd968b3daf626140ed85cef3fad6" class="mwe-math-fallback-image-inline" aria-hidden="true" style="vertical-align: -0.505ex; width:9.716ex; height:2.843ex;" alt="{\displaystyle e^{2\pi i}=-1}"></span>
By default the first span with the mathml is hidden and the second span with the fallback image is visible but you could easily swap that with some custom css. So what exactly would this proposal accomplish, beyond that? —David Eppstein (talk) 05:42, 14 July 2023 (UTC)

New gadget: WikiEdit

Hi! I'd like to propose enabling a new gadget I'm developing. It basically adds a little pencil icon next to paragraphs, that when clicked, loads a small editor in place of the paragraph, without leaving the page. See mw:WikiEdit for the central documentation including a demo video, or add the following to your common.js or your global.js to test it out: 

mw.loader.load( '//www.mediawiki.org/wiki/MediaWiki:WikiEdit.js?action=raw&ctype=text/javascript' );

The gadget is already enabled in the Spanish Wikipedia. In future versions, I'd like to extend it to edit list items, table cells, image captions and talk replies. Support? Objections? Sophivorus (talk) 11:56, 8 June 2023 (UTC)

I think it may be superfluous considering we already have an option to add a button to edit a specific section, but I could be wrong. - AquilaFasciata (talk | contribs) 17:38, 9 June 2023 (UTC)
@Sophivorus for example: article. == career == has 3 paras: para1, para2 & para3. Do you mean this gadget will add pencil button for all 3 paras in career section/heading? i believe right now, there is only one pencil button for career section/heading. హరుడు (talk) 15:55, 12 June 2023 (UTC)
@హరుడు @AquilaFasciata Yes, but the new pencil icons don't load the section edit interface. That'd be superfluous indeed. Instead, they load a small editor in place of the paragraph, without reloading the page. Check out the video at mw:WikiEdit or add the code to your common.js or global.js to see for yourself. Sophivorus (talk) 16:08, 12 June 2023 (UTC)
Ah, I see. Brilliant idea! In that case I'm on board! - AquilaFasciata (talk | contribs) 17:26, 12 June 2023 (UTC)
Reminds me of User:BrandonXLF/QuickEdit. — Qwerfjkltalk 20:19, 12 June 2023 (UTC)
@Sophivorus Do you mean this gadget will add pencil button for all 3 paras in career section/heading? See screenshot [ what i meant is expressed in picture ]:
wikiedit screenshot: pencil icon for each paragraph [ green circle ]
@Qwerfjkl Does quickedit do same thing? హరుడు (talk) 02:14, 13 June 2023 (UTC)
@హరుడు, see File:QuickEdit screenshot.png. — Qwerfjkltalk 11:11, 13 June 2023 (UTC)
@హరుడు Yes, the gadget will add a pencil button for all 3 paragraphs in the section, as your screenshot shows. @Qwerfjkl The gadget is indeed similar to QuickEdit (in fact I thought of naming it QuickEdit first) but allows to edit with more precision (per paragraph instead of per section, and soon per list item, per reply, etc). Sophivorus (talk) 12:31, 13 June 2023 (UTC)
I've tried it for a few days now, and I quite like it! It speeds up minor fixes and has a simple interface. Edward-Woodrow :) [talk] 22:35, 14 June 2023 (UTC)
This seems like it would be a great tool for people like me who make a ton of spelling errors which they have to then correct... Will get back with feedback once I use it a bit. Captain Jack Sparrow (talk) 10:42, 16 June 2023 (UTC)
Preliminary Feedback - This works fine, but it would be much better if you were to add it to Talk page comments as well. Captain Jack Sparrow (talk) 10:48, 16 June 2023 (UTC)
@CapnJackSp, you can do that with scripts such as Factotum and CD — Qwerfjkltalk 10:31, 18 June 2023 (UTC)
@Qwerfjkl, Thanks a lot! Captain Jack Sparrow (talk) 11:21, 18 June 2023 (UTC)
Unlike section-edit, sounds like this idea allows editing of just a high-level section that has subsections, not also including the subsections. The standard editor is poor in that regard because it loads too much and therefore clutters the edit box and the preview. I know we've discussed that limitation years ago, can't find it:( DMacks (talk) 03:30, 25 June 2023 (UTC)
I decided to check this out, and while I do like the idea, could it be modified to allow syntax highlighting as well? Otherwise, very nice, very tidy. SilverTiger12 (talk) 22:35, 2 July 2023 (UTC)
This is a really cool tool – I read through the code too and it is really clean and easy to follow. I would like to report a bug though: the first paragraph of a random article I clicked contained a <br/> tag in the wikitext, and the edit window truncated the paragraph to that point. I haven't tried saving it, but I presume it would replace the paragraph with what is shown in the edit window. Here's the page I found the bug on: 2011 Challenger Banque Nationale de Granby – Women's singles (first paragraph). I believe the bug is due to getParagraphWikitext() only returning a single match, but I don't have a suggestion on how to fix it. Excellent concept though, and I'll probably keep using this despite this bug (just watch out for <br> tags!) – bradv 02:24, 4 July 2023 (UTC)
Interesting tool, but with me it only shows the pencil in the first section/or lead of an article. In the following sections not. I'll still use it though, as it is a pretty nice way of editing and I hope you can figure out why it only shows the pencil in the lead. Paradise Chronicle (talk) 13:12, 4 July 2023 (UTC)
Unfortunately, it looks like it interferes with the prosesize gadget (see discussion) and DYK check. If this could be fixed, that would be great. Edward-Woodrow :) [talk] 16:28, 5 July 2023 (UTC)
@Sophivorus I removed some scripts I don't really know when or if I use them and now it works also for me in all sections. Great script, thanks. If anyone has a similar concern as mine (I could only use it in the lead or first section of an article), this might be the answer. Paradise Chronicle (talk) 11:04, 15 July 2023 (UTC)

Hi, thanks for all the feedback and support! @Edward-Woodrow I found a fix for the issue with the Prosesize gadget, see here, and will try to figure out the DYK check issue next. @CapnJackSp I'd love the tool to be able edit talk page comments, list items, and possibly image thumbnails and maybe even table cells too! However, each is more tricky than the last (especially when deleting stuff) so I'd like to have this enabled as a gadget first and then do gradual improvements. @Bradv Glad you liked the code! :-) I did put a lot of ♡ in it. The <br> is actually very tricky to solve, I did a few tries but couldn't find a good workaround yet, so we'll have to live with it for a while I'm afraid. @Paradise Chronicle That's weird! Does it happen in every article? What skin do you use? What browser? Anyone else has the same issue? @SilverTiger12 I'd very much like to add some syntax highlight too, as well as live preview and maybe even a way to switch to the visual editor like with the reply tool! @AquilaFasciata @Qwerfjkl @DMacks @హరుడు & everyone: it's been a month since the proposal and although there're definitely things to improve (there always are), I feel there's mostly support for the tool in its current state. Can we enable it as a gadget then? If yes, then I'd be motivated to continue its development! PS, I created Wikipedia:WikiEdit to help move it forward! Kind regards, Sophivorus (talk) 00:15, 7 July 2023 (UTC)

So, there is User:Alexis Jazz/Factotum, there is User:BrandonXLF/QuickEdit, and there is now WikiEdit. Leave it to Wikimedians to implement the same thing thrice :-) For the record, I am not formally voting, since I am not really active in English Wikipedia, but I really don’t see how this tool is more useful than other alternatives to warrant its addition to Special:Gadgets. If anything, it is a really poor alternative to QuickEdit (since, for some reason, it loads far slower than that script). stjn 01:54, 7 July 2023 (UTC)
I too see little reason why this one in particular needs to be a gadget out of hundreds listed at WP:USL, some of which have far more users. Nardog (talk) 02:01, 7 July 2023 (UTC)
It's not really fair to compare userbases between established solutions and newly released ones. Folly Mox (talk) 02:06, 7 July 2023 (UTC)
That's my point. We should consider making it a gadget when it proves popular as a user script. Nardog (talk) 02:13, 7 July 2023 (UTC)
I see. That makes sense, thank you. Folly Mox (talk) 02:20, 7 July 2023 (UTC)
there is User:BrandonXLF/QuickEdit, and there is now WikiEdit
And there is also wikt:MediaWiki:Gadget-AjaxEdit.js... JWBTH (talk) 10:58, 12 July 2023 (UTC)
Personally I think I like to see a script get some adoption as an user script to show its utility, popularity, and quality. The usefulness of the "Gadgets" list is inversely proportional to how many gadgets are there, so only more useful and popular scripts should be there. Also once something gets added as a gadget it needs to be maintained for all of eternity, so it's good to show that the script has maintained utility for a while. The script does look neat though, but it would probably be better to wait for more adoption, and to see if people like it more than some of the alternatives mentioned.
(acknowledging that I've gotten two gadgets added, but one was IIRC the most popular user script to not be a gadget and the other had at least gotten >100 installs) Galobtter (talk) 02:30, 7 July 2023 (UTC)
As many others have said, wait until it has a clear user base. Also, would you consider changing the name? "WikiEdit" is a little vague, and could cause confusion with WP:WikEd. Why not something more appropriate for the service it provides, like "MiniEdit"? Edward-Woodrow :) [talk] 12:35, 7 July 2023 (UTC)
Also with WikiEditor. Nardog (talk) 12:40, 7 July 2023 (UTC)
We could choose a name which reflect the USP of editing a paragraph: ParaMedic, ParaPet, etc. Certes (talk) 14:10, 7 July 2023 (UTC)
I like the name MiniEdit, and I agree it's more telling and less confusing than WikiEdit. Changing names is quite a pain because I have to go around renaming so many things, but I'm willing to do so one of these days. @Certes Good to see you around! As to your name suggestions related to paragraphs, I should mention that the limitation to paragraphs is only temporary. The tool will soon be expanded to edit talk page replies, list items, image captions, perhaps table cells. Kind regards, Sophivorus (talk) 15:14, 7 July 2023 (UTC)
Hi @Sophivorus, sorry for the late reply. I use skin Vector2022 and the browsers Firefox and/or Safari. Interestingly in this very discussion I can apply the wikied/minied only to your first edit and the one, where you pinged me. For your last edit just above I can not perform a Miniedit ː). But then I also had some (a few) articles where the tool worked throughout the article. But usually it works only in the lead for me. Paradise Chronicle (talk) 07:04, 8 July 2023 (UTC)
  • Comment That does seem like a cool gadget, used when you only want to update a specific paragraph (spelling or adding a small bit of info). Good idea.Oaktree b (talk) 14:32, 8 July 2023 (UTC)

Presidential judicial nominees automatically notable

There is consensus against the proposal. Some argued that nomination does not guarantee that one has had the level of coverage required to meet GNG (though others argued that most nominees do meet GNG), and that a SNG is not necessary here. Additionally, there are concerns about creating a country-specific notability policy, and some have concerns with the specific wording of "automatically considered notable" (though there does not appear to be consensus for this proposal with the more standard "presumed notable", either). (non-admin closure) Tol (talk | contribs) @ 19:35, 17 July 2023 (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 would like to propose a Wikipedia rule change. Whenever the president of the United Stated nominates somebody to be a federal judge, I propose that person is automatically considered notable & allowed to have a page created. I base this on several reasons;

  1. Federal judges are the heads of one of the three branches of government. There are only approximately 860 judgeships authorized out of a country of over 330 million people. These are the most elite attorneys in the country & nobody will ever be nominated without having a notable career in the first place.
  2. When the president makes an announcement he is nominating federal judges, it is covered in a variety of media outlets all across the country in addition to the local media outlets the judge is being nominated for.
  3. Not allowing judicial nominees to be automatically presumed notable can lead to political reasoning for deletion request. Judges are a very hot topic & this can lead to certain nominees having deletion requested while others don't. To date, I do not believe any of President Trump's 230 federal judges ever had a deletion request put in for them. President Biden has nominated 176 nominees for federal judges yet only a dozen or so have had deletion request put in. This can lead to inconsistencies & unwarranted back & fourths in AFD's that I have personally seen turn ugly.
  4. There is immense interest in the judiciary at this point & time so anytime the president makes nominations, people want to learn more about the nominees. Wikipedia has been a great vehicle to learn about these nominees until recently due to a small number of users putting in deletion request.
  5. Once an attorney is nominated, they will in almost every case become notable. Either they will be confirmed & have a lifetime appointment on the judiciary or they won't be confirmed due to some controversy which certainly will make them notable.
  6. There are many Wikipedia users who often update the pages for judicial nominees. @Snickers2686, @Marquardtika & @Novemberjazz are a few that come to mind. Allowing all judicial nominees to automatically be considered notable will stop users from getting frustrated after putting in so much time & effort to create & update pages, only to have another user put in a deletion request & get the page deleted.
  7. I believe the justification for judicial nominees automatically being notable could fall under WP:Some stuff exists for a reason & WP:COMMON.

MIAJudges (talk) 05:11, 8 July 2023 (UTC)

  • Oppose. Nominees who are rejected by the Senate, withdrawn by the President, or for any other reason do not assume the position are not presumptively notable. Cbl62 (talk) 05:29, 8 July 2023 (UTC)
    nobody will ever be nominated without having a notable career in the first place Aileen Cannon, Brett Talley, Justin R. Walker, and Sarah Pitlyk, among others, disprove that assertion. Cbl62 (talk) 05:35, 8 July 2023 (UTC)
    WP:USCJN says otherwise: Nominees whose nomination is rejected by the United States Senate are inherently notable, as the rejection of a nominee to such a position is a rare and politically important event. Snickers2686 (talk) 16:34, 8 July 2023 (UTC)
    There's a vast difference between REJECTED and NOT YET CONFIRMED. A Presidential nominee should automatically be considered notable. Once they are confirmed, they obviously remain notable. If they are rejected by the Senate, whether they are notable or not depends on the reasons for the rejection and the politics involved. Beyond My Ken (talk) 20:27, 9 July 2023 (UTC)
    WP:USCJN appears to be a project's private notions on notability, with no more authority than any other essay. Ravenswing 22:48, 10 July 2023 (UTC)
    To you, is there no useful information in that virtually everyone who actually works on judiciary-related articles opposes the deletion campaign? This is just a fight between one faction asserting that nominations are important and the other asserting that they aren't, neither with any real reasoning, but at least one has experience. Iowalaw2 (talk) 04:33, 11 July 2023 (UTC)
    There are certainly a bunch of you who feel like your ox is being gored, but the useful information to keep in mind here is that outside of your cadre (and some anon IPs), this proposal has received near-unanimous opposition, as has the attempt to sanction someone at ANI over this. No one is suggesting that United States judicial nominations are unimportant; they simply are not prima facie evidence of being able to meet the GNG, and your faction has failed to provide the slightest shred of evidence to the contrary. This is exactly why proposed changes to notability guidelines go to the neutral and non-partisan community, rather than being dictated by the self-interest of small factions. Does it truly not get your attention that numerous veteran editors oppose this proposal, and have expounded as to why at length? Ravenswing 14:32, 11 July 2023 (UTC)
  • Oppose. Let's take these items one by one. For #1, as cbl62 noted, the concept that these are the "best attorneys" in the country is just your opinion and there is no real evidence to back up such a claim. For #2, again, it may be the case that the person in question is covered in some way by the press, but they still need to pass the requisite WP:SIGCOV to pass WP:GNG. Passing mentions and relisting the biography given by the WH does not cut it. As for #3, while this has been tossed around by many with little evidence, this is an example of WP:OTHERTHINGSEXIST which is not a reason for keeping any article. #4 is a clear case of WP:ILIKEIT and WP:FAN which are not reasons for keeping any article. Cbl62 already covered #5. As for #6, articles can be put in the draftspace so that editors can continue to work on them until they meet WP:GNG, like Charnelle Bjelkengren, or get confirmed, when they will meet WP:JUDGE. #7, simply WP:NOCOMMON. Let'srun (talk) 13:24, 8 July 2023 (UTC)
  • Oppose: I don't find the reasoning to amend WP:NPOL and WP:JUDGE compelling. This would also necessarily amend WP:ROUTINE to make an exception merely for judicial nominees regardless of whether they attain a position of notability. The difference here is a matter of weeks or months; given that there's no WP:DEADLINE, I don't find reason to make an end run around our existing guidelines. The OP cites avoiding deletion discussions and wastes of effort; that is what the draft space is for. There's nothing about this that isn't adequately handled already, especially with List of federal judges appointed by Joe Biden, which houses also pending nominations. Courtesy ping to @BD2412: the acknowledged major contributor to this field. I believe a courtesy notification to WP:USCJN is also in order. Iseult Δx parlez moi 17:07, 8 July 2023 (UTC)
  • I have been thinking about this for a very long time. I think that it is generally uncommon for a person to be nominated to a federal judgeship who can not already be found to meet the WP:GNG, but that raises the question of whether we need a nominee-directed provision if these articles can be sourced and kept without such a provision. BD2412 T 23:23, 8 July 2023 (UTC)
    That's where I am: if a person who is nominated for a federal judgeship is inherently notable for some reason, we ought to be able to establish that prior to actual confirmation, not merely through virtue of nomination. I don't see what's wrong with the current criteria. GNG stands. As for nominees rejected by the Senate, we ought to be able to make a difference between stonewalled privately as opposed to, say, the clock running out before the end of the term or session. The latter certainly confers no notability. To make a determination on the former is WP:CRYSTAL. Iseult Δx parlez moi 01:49, 9 July 2023 (UTC)
    I mostly agree with this, but every nominee is different and just asserting that a judicial nominee is notable without any additional justification seems like opening a can of worms which would lead to every Presidential appointee for every last agency receiving an article, even for the most trivial of roles where only primary coverage about the subject is readily availiable. @MIAJudges in particular seems in his arguments to fail the concept of WP:NOT, in that not everything needs a wikipedia article, and just because WP:ILIKEIT does not justify including articles about non-noteworthy subjects. As Iseult noted, articles can be moved to the draftspace when the person gets the needed GNG coverage as it is, or once they are confirmed, and there is no WP:DEADLINE.
    On another issue, what are your thoughts on the nominees for the D.C. courts such as the Superior Court of the District of Columbia? They receive much less coverage than even federal district court nominees do, in my experience, so I see no reason not to apply the current WP:USCJN district court guidelines there as well. Let'srun (talk) 15:18, 9 July 2023 (UTC)
    To the extent that we are speaking of federal judicial appointees who are nominated by the President of the United States, require approval by the United States Senate, and once approved remain in office beyond the term of their appointing president, I don't differentiate at the District Court/specialty court level (there is also a the Court of Federal Claims, the Tax Court, and the Court of International Trade, among others). BD2412 T 23:26, 11 July 2023 (UTC)
  • Oppose. For me, any proposal which includes "automatically notable" is a non-starter. RoySmith (talk) 15:23, 9 July 2023 (UTC)
  • Support @RoySmith: the notability standards are full of "automatically notable" provisions, although they are not specifically expressed with those words. Take WP:SPORTSPERSON, for instance: "A sportsperson is presumed to be notable if the person has won a significant honor and so is likely to have received significant coverage in reliable secondary sources that are independent of the subject. ..." The current proposal could easily be expressed by "A presidential nominee for a Federal judgeship is presumed to be notable if that person has received, before or after their nomination, significant national or local media coverage of their legal or political career in reliable secondary sources that are independent of the subject..." etc. This amounts to being the equivalent of "automatically notable". Let's not throw out a good idea due to some perhaps faulty wording. Beyond My Ken (talk) 02:59, 10 July 2023 (UTC)
  • Oppose - I think it highly likely that anyone nominated for a federal judgeship will have enough coverage to establish notability under GNG - but that is not the same as being automatically notable.
    What we perhaps need is a discussion about the type of coverage necessary. There may not be news coverage, but there may well be coverage in other types of sources. Blueboar (talk) 11:54, 10 July 2023 (UTC)
    I oppose for similar reasons, but the context here is that a couple of editors are trying (partially successfully) to wipe all of the articles for Biden's judicial nominees. I'd encourage those with similar thoughts to express their opposition to this campaign here. Iowalaw2 (talk) 19:53, 10 July 2023 (UTC)
  • Support - In the current political climate, a president's nominees are highly likely to be be confirmed and become a part of the judicial branch. The fact that a President is nominating them almost in and of itself means that the lawyer is notable for their previous experience. As another user said, it's similar to a draft pick by a sports team. They haven't played for the new team yet, but it is highly likely that they will and also highly likely that they have previous noteworthy accomplishments. 167.7.37.83 (talk) 15:47, 10 July 2023 (UTC)
    WP:CRYSTAL isn't a legitimate reason to have a wikipedia page for any individual. Let'srun (talk) 17:35, 10 July 2023 (UTC)
  • Support: Words have meeting. If a person being nominated to a lifetime position in one of the three branches of the Federal government is not "notable" and worthy of a Wikipedia page, but the Loch Ness monster is, then Wikipedia is a joke and the editors don't understand the meaning of "notable." The opposition to this proposal is a partisan attack on Biden's nominees, and taking down these pages reflects badly on Wikipedia and its so-called moderation of content. 2601:582:8502:4BF0:7985:A872:9F7B:4BE4 (talk) 20:02, 10 July 2023 (UTC)
  • Oppose For the above reasons plus a fundamental wording flaw. SNG's are worded to say that something that meets their criteria are presumed notable and that being a temporary presumption that GNG sources exist. In contrast to the categorical wording of this proposal. Sincerely, North8000 (talk) 20:11, 10 July 2023 (UTC)
    Why? Has an article on such a judge been deleted or been moved to draft space? Judges also of lesser courts have articles Paradise Chronicle (talk) 20:48, 10 July 2023 (UTC)
    A few have; see the related ANI thread. BilledMammal (talk) 21:12, 10 July 2023 (UTC)
    My point was not to hypothesize about things like that. It was to point out that the choice of wording (categorically declaring notability vs. "presumed notable") is in conflict with how SNGs are and need to be written. North8000 (talk) 12:53, 12 July 2023 (UTC)
  • Oppose. Not all judges are nominated because of a notable career, and nominations alone don't always result in the level of coverage required for notability. In other words, being nominated is not a good predictor of notability. BilledMammal (talk) 21:12, 10 July 2023 (UTC)
  • Oppose: Not only has the proposer provided no evidence that judicial nominees by that fact alone generally meet the GNG, but the findings in a majority of the AfDs currently in question are that they do not. Like BD2412, I expect that many such may well do so, but in those cases their articles can stand and fall on that.

    Moreover, this is not the United States Wikipedia. What makes US Presidential nominees presumptively notable, and political nominations from the President of Brazil (or the Philippines, or Russia, or South Africa, or ...) not? There would need to be a very strong argument, and a very strong injustice being done, for there to be such a unique carve-out for the actions of a single head of state, and nothing of the sort has been proffered. (One might think, for instance, that the political nominations of Narendra Modi, the head of government of a nation with a far larger English-speaking population's than America's, would be worthy of at least equal attention.)

    Finally, good grief! Proposing changing the language of notability criteria because there are a handful of users frustrated at the current standards? They are much better off learning to live with those standards. The nature of a consensus-driven environment is that sometimes you're going to be on the wrong side of consensus, in which case it's better to lose gracefully and move on. Ravenswing 22:54, 10 July 2023 (UTC)

    This is a page for proposals. It’s literally what this page is for. So yes, users will come here to make proposals as I have done. It has nothing to do with losing gracefully & moving on. Some of the pages I advocated keeping were kept. But even if every single article had been kept, this proposal is for setting a standard going forward.
    MIAJudges (talk) 23:02, 10 July 2023 (UTC)
    (cocks his head) For someone who repeatedly insists he's done talking to me, you seem to respond to my posts an awful lot. That being said, you're misunderstanding. You have every right to make proposals here, to whatever end you think best. But one of the most bizarre reasons possible for changing notability criteria is that there are a handful of editors put out by the existing wording. We propose changes in criteria because they'll better serve the encyclopedia and/or better reflect the GNG, not because there are editors who find following the existing guidelines a hardship. Ravenswing 23:12, 10 July 2023 (UTC)
    I am replying to you here because you implied crap about me such as I’m not losing gracefully and moving on. Had you stuck to the actual merit of the argument & not included shots at me personally, I would not have replied at all. So if you have nothing else to say about me or to me I certainly will respond in kind.
    MIAJudges (talk) 23:21, 10 July 2023 (UTC)
    (cocks his head) What gives you the impression I was referring to you with that? That comment was directed to those who -- as you said -- were likely to be frustrated because the notability guidelines are not already written to their liking. That's being very quick to take comments personally. Ravenswing 02:31, 11 July 2023 (UTC)
    Would it kill you to quit antagonizing MIAJudges? It's obvious what you're doing and it's obnoxious, not clever. Iowalaw2 (talk) 04:31, 11 July 2023 (UTC)
    MIAJudges has said repeatedly, and in several venues, that they're Done Engaging With Me. That lasts until the next time, and until the time after that. Would it have killed MIAJudges to not single out my response here to jump on? Ravenswing 05:58, 11 July 2023 (UTC)
    For me it's not really obvious what you're doing. For me it just looked like Ravenswing was answering direct responses. The part of Ravenswing's oppose that MIA took personally seems to be to point 6, that There are many Wikipedia users who often update the pages for judicial nominees...Allowing all judicial nominees to automatically be considered notable will stop users from getting frustrated after putting in so much time & effort to create & update pages, only to have another user put in a deletion request & get the page deleted. Ravenswing's point wasn't inappropriate: editors working outside of current policy is not a compelling reason to change that policy. Valereee (talk) 11:17, 12 July 2023 (UTC)
  • Oppose This is a global project and we should be leery of carving out county-specific guidance. Also I oppose with the same reasons as the other people commenting here, including North800, Ravenswing, and BD2412. --Enos733 (talk) 22:57, 10 July 2023 (UTC)
  • Support The American people have the right to know about federal judicial nominees. Judges are appointed for life, and many judicial nominees will become judges. Furthermore, people can write to their Senators about whether to support or oppose a judge, but they generally don't do that unless they know a bit about the nominee. Judicial nominees' Wikipedia pages are good places for learning about the nominees. If the judicial nominees' pages are taken down, the judicial nominations process will be less honest and transparent. Fluthy (talk) 05:14, 11 July 2023 (UTC)
    I agree that the American people have the right to know about nominees for Federal judgeships… but that does not mean that Wikipedia must be where they can find that information. Blueboar (talk) 12:49, 11 July 2023 (UTC)
  • Oppose The small group of editors who have pushed this topic area have done an absolutely piss-poor job of reflecting long-notable historical figures. Why should we give them ammunition to further the notion that Wikipedia is a current events or news site and that press releases signify notability simply because of where they emanate from? That's exactly what I see occurring whenever I see these articles appear. RadioKAOS / Talk to me, Billy / Transmissions 05:47, 11 July 2023 (UTC)
  • Oppose per North8000 and Ravenswing. Plus, we cannot assume nominees have significant coverage in reliable sources that are independent of the subject. starship.paint (exalt) 06:02, 11 July 2023 (UTC)
  • Support: The American people deserve to know who nominees for federal judgeships are, just like with major party candidates, no matter if you support the current president or not. From seeing the conduct of "Let'srun here, it is obvious that they have a bias which is blind to what makes someone truly notable. Someone above said that they were uncomfortable with carving out an exception to just the United States, and I would say why not have pages for judicial nominees in other countries? 137.99.94.240 (talk) 11:15, 11 July 2023 (UTC)
    I would say why not have pages for judicial nominees in other countries? - that’s because whether we have pages on any person is based on WP:GNG (significant coverage in reliable sources that are independent of the subject), and not whether any nationality of people deserves to know them. starship.paint (exalt) 12:13, 11 July 2023 (UTC)
  • Support: Anyone who was ever considered for a lifetime appointment is notable. Not all nominees that fail are for lifetime appointments but judicial nominees are lifetime appointments EPMen (talk) 01:39, 12 July 2023 (UTC)
  • Let me save you some time - On the English Wikipedia in 2023, any proposal to grant "automatic notability" to a subject is going to fail. It doesn't matter what the subject is. — Rhododendrites talk \\ 01:47, 12 July 2023 (UTC)
  • Waste of time - automatic notability is only really of use if we either think a) for the nature of this, we reduce the notability standards of GNG (GEOLAND is the main example of this) or b) we are confident there are sources, but they'll be tricky to get at (a few of the more niche NMUSIC criteria (not quite automatic, I know), but very rare these days with most sourcing online). If it's just "because they all have sources readily available", then, well, why not just add the sources? As a final addendum, a country-specific notability policy is an absolute no-go, and disturbingly america-centric by the creator. Nosebagbear (talk) 09:01, 12 July 2023 (UTC)
  • Note for closer This seems like headed for a clear no, but do note that there has been off wiki canvassing of this thread. — Preceding unsigned comment added by CapnJackSp (talk • contribs) 05:49, 17 July 2023 (UTC)
    Why am I not surprised, especially with the raft of anon IPs and other contributors with suspiciously low edit counts coming in to support. Ravenswing 06:28, 17 July 2023 (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 talk:WikiProject Hong Kong#Request for comment for Hong Kong or Hong Kong, China?

Please see Wikipedia talk:WikiProject Hong Kong#Request for comment for Hong Kong or Hong Kong, China? for an RfC regarding how to phrase the place of birth for people born in Hong Kong after the Handover of Hong Kong on 1 July 1997. Cunard (talk) 05:33, 13 July 2023 (UTC)

Please see Wikipedia talk:WikiProject Hong Kong#Request for comment: British Hong Kong or Hong Kong? for an RfC regarding how to phrase the place of birth for people born in Hong Kong before the Handover of Hong Kong on 1 July 1997. The RfC also discusses a bot request to modify all affected articles to comply with the new guidance. Cunard (talk) 04:58, 19 July 2023 (UTC)

Infobox RfC on the biography of Felix Mendelssohn

There's an ongoing discussion about adding an infobox to the biography of Felix Mendelssohn. Community feedback is welcome. Thanks! - Nemov (talk) 22:12, 17 July 2023 (UTC)

Comment: is it really appropriate that this is going on at the same time as the exact same question at Richard Wagner. If the truth is that some people like infoboxes in composer articles, others don't, for consistency shouldn't these two RfC's be amalgamated into one, addressing the underlying question properly? Otherwise we run the risk of misleading new editors who will fail to appreciate that the landscape they see is shaped by a multitude of long-forgotten individual debates, and that for magic reasons it is acceptable to give Bach an infobox, but not Gibbons. Elemimele (talk) 20:27, 18 July 2023 (UTC)
@Elemimele, the section header might be misleading. This is notification to the community that there is an RfC at Talk:Felix Mendelssohn, not an RfC here. Schazjmd (talk) 20:31, 18 July 2023 (UTC)
Yes, I understand, I wasn't sure where to point out that it's unhelpful to hold multiple small, near-identical RfC's when I felt this might be part of a larger dispute. Is there a better place to mention it? Elemimele (talk) 05:41, 19 July 2023 (UTC)
A recent attempt at creating a general guideline closed as no consensus; a lot of people felt that this should be decided on a case-by-case basis, which does necessitate a lot of near-identical RfCs. Sojourner in the earth (talk) 07:03, 19 July 2023 (UTC)
@Elemimele, my bad for not reading properly, sorry about that. Schazjmd (talk) 13:20, 19 July 2023 (UTC)
Many of these RfCs have editors pro/con that vote in a consistent block. To help break this deadlock it's helpful to get more community feedback. I spent a considerable amount of time attempting to create a modest guideline and many of the same editors opposed it. So unfortunately, this is the bureaucratic process necessary to find consensus. Nemov (talk) 13:45, 19 July 2023 (UTC)

Add "Random article" button to Home Page

Sometimes I get bored and I like to go onto Wikipedia and find a random article, but it's hard to actually get a random article that I am interested in. 2601:600:877F:1530:29:D645:40AD:6935 (talk) 04:40, 19 July 2023 (UTC)

If you are on a laptop, there is a random article link in the main menu on the the left (unless you've removed with some personal setting I guess). If you're on mobile view like [1], it's under the top-ish left hamburger. Gråbergs Gråa Sång (talk) 09:31, 19 July 2023 (UTC)
The keyboard shortcut (see Wikipedia:Keyboard shortcuts) of Alt-Shift-x (depending on browser and assuming you have a keyboard and not a mobile device) can also be useful for being able to more easily go through multiple random pages. Skynxnex (talk) 13:56, 19 July 2023 (UTC)
If you're struggling to luck into articles you find interesting from the standard functionality of Special:RandomPage, you might want to try out Special:RandomInCategory. Someone has also written a user script with even more functionality. If you register an account, you'd be able to install the user script, although I don't remember what it's called at the moment. Folly Mox (talk) 00:01, 20 July 2023 (UTC)

Add Scroll Down and Scroll Up buttons to Village Pump

I always have to scroll down to get to the most recent policies and proposals in the Village Pump, and also to get to the new policy or proposal typing box. Could someone add a scroll down and scroll up button to the Village Pump sections so I can quickly get to the most recent section (similar to the Teahouse)? 2601:600:877F:1530:4C53:4962:C485:D7E5 (talk) 01:02, 28 July 2023 (UTC)

Better would be for someone to create a user script or gadget so interested users can have it on all pages, and then for you to create an account so you can use it, rather than forcing big ugly buttons on everyone. Anomie⚔ 10:41, 28 July 2023 (UTC)
I would love this as a gadget and specifically for pages of a certain thresshold, so large pages like ANI, VPs, Teahouse etc.. on other hand for Teahouse specifically, requiring it to be installed as a gadget would mean most users without an account/default wouldn't benefit from it. So if it was made as a gadget, I'd support it as a default setting with option to opt out. ~ 🦝 Shushugah (he/him • talk) 10:48, 28 July 2023 (UTC)
Whilst a gadget would be useful, IP users wouldn't be able to use it, so it wouldn't help the thread poster. Joseph2302 (talk) 11:04, 28 July 2023 (UTC)
The new Vector skin also won't help IPs, but it does have this function via the left-hand ToC -- one of the reasons I've stuck with the new skin. Mike Christie (talk - contribs - library) 11:45, 28 July 2023 (UTC)
@Mike Christie, I'm curious, what do you mean by The new Vector skin also won't help IPs - help with what? — Qwerfjkltalk 22:13, 28 July 2023 (UTC)
Perhaps I misunderstood the OP, but they seem to want a quick way to do vertical navigation on a long page. I don't know what interface a logged out user sees, but now I think about it I guess they get Vector 2023, so they should have the left-hand ToC. That allows for very quick vertical navigation. As far as immediately scrolling to the top and bottom, though, there are even faster ways. I'm on an iPad at the moment using Chrome; to get to the top of any web page one just has to tap the bar above the tabs. There's no equivalent way to get to the bottom quickly, as far as I know. On a PC there are keystrokes for top and bottom; I don't recall them at the moment but my fingers know when I'm at the keyboard. Probably Ctrl-End and Ctrl-Home. Mike Christie (talk - contribs - library) 22:25, 28 July 2023 (UTC)
I quite like that left-panel situated ToC feature in Vector 2022. It's just the literally almost everything else about it that I don't care for! In all seriousness, does anyone know if there's a script for getting that effect with the other skins? I'd love to have it for my ride-or-die Monobook! SnowRise let's rap 00:10, 31 July 2023 (UTC)

Improve move page dialogue

There are three separate proposals here, based on feedback from my Village Pump (idea lab) to improve understanding/reduce mistakes when moving pages across different name spaces.

1. Within the move page dialogue interface rename the displayed namespaces. The motivation is to make it more clear what each namespace does. A common mistake is to mix up Wikipedia and Mainspace, because publishing on Wikipedia is not same thing as publishing in Wikipedia namespace.

  • (article) -> (article / main space)
  • Talk -> (article Talk page)
  • Wikipedia -> Wikipedia (project)
  • Wikipedia Talk -> Wikipedia Talk (project)

2. On mobile, when a user is moving a Draft to Article space, they need to scroll very high up, and are more likely to select wrong namespace then. So a solution would be to always move the highlighted option to the top OR move Draft / Draft talk options higher up, so that when someone is publishing a Draft they don't need to scroll up 18 different options before finding (Article) and Talk namespaces.

3. In the move dialogue, make a visual separation (by regrouping, as well as having a thick black line between the groups) between Project and Public facing pages. Project pages include Wikipedia, Wikipedia Talk, Categories, Categories Talk, Portal, Portal talk and public facing pages include (Article), Talk, File, File talk, Template, Template talk.

Feel free to vote on each of these separately and or use common sense to modify original proposal. ~ 🦝 Shushugah (he/him • talk) 15:00, 19 July 2023 (UTC)

I haven't read the former discussion so I don't fully understand why #1 and #2 are being proposed and what they do, but I would support a visual separation between Project pages and non-Project pages. However, I think we need a concrete proposal for what that visual separation would be; perhaps a slightly darker shade of a grey as the background? BilledMammal (talk) 15:19, 19 July 2023 (UTC)
BilledMammal thanks! I have edited original proposal to clarify that. ~ 🦝 Shushugah (he/him • talk) 15:25, 19 July 2023 (UTC)
Ah, I see what you are proposing now. I still support a general visual separation between project and public facing pages (it seems sensible to me), but considering your suggestions limited as they are to the move system they seem sensible and likely to make the system more intuitive and thus I would support them. BilledMammal (talk) 15:28, 19 July 2023 (UTC)
Something I forgot about at the VPI discussion is that people commonly publish from User: as well as from Draft:, so I'm not sure moving only "Draft" in the namespace destination list will fix enough of the issue. I do like the idea of always targeting the top namespace (mainspace) in the selection dialogue, which I think can be done in CSS or at least JavaScript.
As to the other two ideas / subproposals, a few words of explanation disambiguating namespaces 0 and 4 couldn't hurt, but I'm not sure grouping the namespaces can be accomplished technically using the current setup, although maybe it's possible to put an unselectable horizontal rule into a selection dialogue – I been outta the web dev game for decades.
Perhaps unsurprisingly, I'm somewhat partial to my own never responded to proposal to separate out the tasks on Special:MovePage into rename (same namespace as before), publish (namespace 0), and all other cross-namespace moves. Folly Mox (talk) 23:48, 19 July 2023 (UTC)
Categories should be considered public-facing pages; plenty are used for navigational purposes. Skarmory (talk • contribs) 02:51, 22 July 2023 (UTC)
@Shushugah At alternative idea - why don't we use an edit filter to warn non-extendedconfirmed editors moving pages from draft/user space to wikipedia space that they should check that they've got the namespace correct? 192.76.8.66 (talk) 12:26, 30 July 2023 (UTC)
I can support these changes. Instead of renaming projectspace, changing the wording of the page mover is a better idea. SWinxy (talk) 18:50, 1 August 2023 (UTC)

Proposal to split MOS:GENDERID from Wikipedia:Manual of Style/Biography

FYI
 – Pointer to relevant discussion elsewhere.

Please see: Wikipedia talk:Manual of Style/Biography#Proposal to split MOS:GENDERID from Wikipedia:Manual of Style/Biography, a proposal to move material out of MOS:BIO and the main MoS page, and to a new guideline page (the page currently exists as an essay).  — SMcCandlish ☏ ¢ 😼  00:58, 3 August 2023 (UTC)

Proposal to using the Transcription Rules of the Academy of the Hebrew Language

When I read articles that include transcription from Hebrew, I see many different transcriptions. For example, the letter ח is sometimes h or ch – both are wrong, and we should usually use H̱, ẖ, according the the Rules of Transcription!

My first suggestion was to change Holon to H̱olon, however, no answer was received.

As I kept reading English articles that involve Hebrew words, the inconsistency appeared more and more.

In the article about the Hebrew IPA, the letters and the names of our Nikkud (that is spelt Niqqud, which is wrong in this context) symbols are written weirdly, and should be changed to the Rules of the Simple Transcription.

Unless the article or the paragraph talks about a Hebrew word (its etymology, for example), we should use the Simple Transcription, not the Scientific Transcription. מושא עקיף (talk) 01:35, 3 August 2023 (UTC)

You need reliable sources for the transcriptions you want to change. Otherwise it's original research. Andre🚐 03:46, 3 August 2023 (UTC)

Disputed essay banner

I created User:Ca/sandbox5 to make a more specific version of Template:Disputed essay. However, an editor at Wikipedia:Requested moves recommended I get consensus first. My rationale for creating this tag is that some essays have gone through RfCs because its guidance was disputed. Eg) WP:VENRS Additionally, essays in Wikipedia namespace are open for editing by anybody. It is only natural that disputes may arise. I do not see how this banner is different than regular Template:Disputed in article space. It notifies readers of a discussion. Ca talk to me! 11:15, 2 August 2023 (UTC)

Pinging participants @Amakuru @UtherSRG Ca talk to me! 06:21, 3 August 2023 (UTC)
  • Every essay should be considered disputed by default. That's why there's a warning banner on the top that says it's not a policy or guideline. The problem isn't that some essays are disputed, but that some people seem to think that if you have a WP:FANCYLINK and you use it a zillion times, you can pretend it's official. And I'm not assuming bad father here. I've seen numerous discussions where someone says "Sure it's an essay, but it's been used a lot. So that's basically consensus." And then the other person is treated like a dummy for pointing out that that's not really how consensus works. It could very well just mean that there's a core group of people who really like that essay. GMGtalk 11:19, 3 August 2023 (UTC)
    There are unpopular essays that may present only a minority view. And there are essays that tell its readers to go against established WP:PAG. Such essays should be userfied or modified. Essays are of low significance, but there are truly terrible essays that require changes. I believe my template is great for notifying potential editors of the discussion. Ca talk to me! 15:36, 3 August 2023 (UTC)
    Try as you might, that pointy template will not end up on WP:NJOURNALS. Headbomb {t · c · p · b} 18:19, 3 August 2023 (UTC)
    Please assume good faith. I stopped caring about that essay close to a month now. And WP:NJOURNAL is not what I meant by "truly terrible" essays. Ca talk to me! 00:07, 4 August 2023 (UTC)
I agree that this is a pointy template and it will not end up on WP:NJOURNALS. Also, this template would be redundant if placed on an essay and therefore needless per Wikipedia is not a bureaucracy. ---Steve Quinn (talk) 19:53, 3 August 2023 (UTC)
Also, please note, there are plenty of places to notify people of a discussion such as Project talk pages, for instance, and some noticeboards. ---Steve Quinn (talk) 20:05, 3 August 2023 (UTC)

Modification

I took the "POINTY" concerns and I modified the template so that it looks less hostile. I'll be happy to hear what people think. Ca talk to me! 00:15, 4 August 2023 (UTC)

Invitation to participate in a research about Wikipedia's Main Page

Hello!

First of all, I would like to introduce myself, I'm Laura Fernández, a postdoctoral researcher of the Women & Wikipedia project at the University of Barcelona, Spain (https://www.ub.edu/wikiwomen/).

Our research group is currently working on the analysis of the Wikipedias in English, Spanish and Catalan's Main Page. In the case of Wikipedia in English, we are currently in a phase of interviews to learn more about the mechanisms that exist for the selection of the Main Page and we would like to interview Wikipedia volunteers (particularly those who are more familiar with the Main Page). We are sure some of you can guide us specifically on the subject, given your involvement in the community and your knowledge of the functioning of Wikipedia in English. We would like to delve deeper into the processes and mechanisms behind the programming of the main page from the point of view of communication theories.

I hope you find it interesting and have availability to participate with us. In that case, We will of course adapt to your needs, availability and time (we could do a written interview, call or videocall). Our ultimate goal in any case is to contribute to the improvement of Wikipedia through data and scientific knowledge, so we think we can learn a lot from the people who work continuously and are committed to Wikipedia.

If you prefer to continue this conversation by email, you can send an email to my university email address: laurafernandez[at]ub[dot]edu or get in touch with me through my Wikipedia user page. Do not hesitate to let us know if you have any doubts or questions about the research.

I look forward to hearing from you. Thank you very much in advance and best regards, Laura. Lauferagui (talk) 06:26, 18 July 2023 (UTC)

Can you help me edit it?

I referenced List of tallest buildings and added a map to List of tallest towers.

The map shows the location of towers over 400 meters tall.

However, I think I mislabeled the location of the towers.

Can someone please correct the label correctly? Ox1997cow (talk) 15:36, 6 August 2023 (UTC)

The best place to request assistance is at the Help Desk. This page is for discussion about proposing changes to Wikipedia itself. 331dot (talk) 16:09, 6 August 2023 (UTC)
I see. Ox1997cow (talk) 06:30, 7 August 2023 (UTC)

Proposal: add anchor with Rfc id when removing Rfc header

It's sometimes a bit hard to navigate to the proper discussion on a Talk page from a wikilink that uses "Rfcid", if the Rfc header has been removed; you end up stuck at the top of the page, staring at a "missing section" notice. Your feedback would be appreciated at User talk:Legobot#Proposal: add anchor with Rfc id when removing Rfc header. Thanks, Mathglot (talk) 00:22, 15 August 2023 (UTC)

Add Low German Wikipedia to the bottom of the main page of English Wikipedia in the section of 50,000+ articles

Hi dear Wikipedia users and admins!

I have a proposal. Can you add Low German Wikipedia to the bottom of the main page of English Wikipedia in the section of 50,000+ articles? This Wikipedia has 84K+ articles for now and is a huge Wiki. It is the Wikipedia edition of a West Germanic language spoken in most of Northern Germany and a large part of Netherlands.

I would thank you so much if you will take my request into consideration.

I have noticed that some Wikipedia editions in different languages have been added recently to the bottom of the main page of English Wikipedia and Low German Wiki, which is an important Wiki for a majority of people in Germany and Netherlands, is still missing.

Thanks FGRADO (talk) 20:46, 21 August 2023 (UTC)

We cannot do anything here. You need to raise this issue at Template talk:Wikipedia languages, where that template is maintained. Donald Albury 22:07, 21 August 2023 (UTC)

Proposal: Replace the Content portals link on the Main Page with a different link

I think that the content portals link on the main page needs to go since it is more focused on collections of articles rather than individual articles. I think a much better replacement would be the vital articles since they are Wikipedia's most important articles and I find that page to be easier to navigate than the portals page. If you think there are much better replacements for this one, please let me know. While I'm on the subject of Other areas of Wikipedia, the WP:News page should probably go as well since it is just a collection of sources discussing Wikipedia news. I would love to hear your thoughts on the Main Page and how we can improve it. Interstellarity (talk) 17:23, 15 August 2023 (UTC)

I would link Wikipedia:Contents/Overviews over a Wikiproject list that is just a random list over topics. Moxy- 17:34, 15 August 2023 (UTC)
Why not have both? Portals have already been severely marginalised last year after a long and bloody fight, mainly on the pretext of needing the space for something else (it remains blank to this day), and with a promise to move the link to the portals contents page to the Other areas of Wikipedia section lower on the Main Page as a pacifier. It seems inappropriate to kick portals in the teeth yet again. Certes (talk) 18:08, 15 August 2023 (UTC)
Maybe we could add WP:Contents where it's an overview of everything. The problem with WP:Contents/Overviews page is that it is more of a general outline rather than specifics. About a quarter of our articles are biographies, and I think putting something in there that captures Wikipedia's most important biographies would help a lot and I think vital articles fits the bill well. Overviews is just a general overview of some Wikipedia articles, but if you include vital articles, you can get specific articles like Isaac Newton, one of our most important biographies, and historical events, like the French Revolution. I think if we can't decide between the two, why not list both? That way we can capture both the generals and specifics of Wikipedia. Interstellarity (talk) 18:34, 15 August 2023 (UTC)
Problem with vital articles is that it seems just random....Kingston, Jamaica level-4 vital article? Where Wikipedia:Contents/Overviews simply links to our parent articles without kids graffiti. Moxy- 01:32, 16 August 2023 (UTC)
To be honest, I don't know about this. I personally jump straight to my watchlist articles, random article, VPPR, RFCs, and AFDs whenever I'm editing. I don't use the content portals as much. However, I do see that some people may absolutely need portals. I think this would be better reformed as a customizable Main Page for logged in users, where people can change what's in all four boxes, from ITN, DYK, TFA, OTD, AFD, RFC, CD, and every alphabet soup acronym we have. Not sure how we could technically pull it off, or if it would be worth it in the end though. We all know what happened to iGoogle. InvadingInvader (userpage, talk) 18:28, 22 August 2023 (UTC)
I suspect most viewers of portals are not registered editors, so we'd need to take care to maintain a good default for those not logged in. Certes (talk) 22:21, 22 August 2023 (UTC)

Global perspective on the main page

At this time the following US topics are on the main page:

  • the featured article
  • the first four DYKs, of eight
  • the featured list
  • the first, second and forth OTDs, of five

Only the featured picture is exclusively non-US and ITN gives a good summary of the major global news events right now. I appreciate that the largest number of volunteers by nationality are from the US and this is English Wikipedia, but can some processes can be put into place to reflect the rest of the world on the main page? 1.145.204.163 (talk) 23:41, 18 August 2023 (UTC)

DYK has rules which limit the number of US topics per hookset to no more than four, and no two of them adjacent. Looking at today's hooks, we didn't come close to breaching that quota, and certainly not "the first four". Perhaps we're not looking at the same set? I'm looking at Special:Permalink/1171087214. RoySmith (talk) 00:09, 19 August 2023 (UTC)
If you see this balance being violated, please report it at WT:DYK if it's still in a prep area or one of the early queues, or at WP:ERROR if it's currently on the main page or scheduled to be there in the next couple of days. RoySmith (talk) 00:15, 19 August 2023 (UTC)
Oh, our comments crossed just as we rolled over to the next 24 hour set. You must have been looking at Special:Permalink/1170916769, which did indeed violate both of the rules I cited above. Our bad. RoySmith (talk) 00:18, 19 August 2023 (UTC)
Thank you for your reply, perhaps yesterday was just an unfortunate coincidence. I think the new page is beyond criticism. I understand it is complicated by each aspect being coordinated independently, perhaps someone could run their eye over the whole with the authority to shuffle the order of constituent parts a little. 1.145.204.163 (talk) 00:58, 19 August 2023 (UTC)
It's worth noting that OTD and ITN are not movable - in the sense of "this day is the relevant day". FA and FL (to a much more limited degree) may have specific days most relevant to that content. So speaking as a non-American, days will come that just happen to have a significantly higher load. Nosebagbear (talk) 05:01, 19 August 2023 (UTC)
It's also worth noting that while OTD can to an extent choose which items to feature when there are many notable happenings on a given day in history, ITN has no such control. Sometimes all the major news relates to the US, sometimes none of it does. Thryduulf (talk) 08:34, 19 August 2023 (UTC)
IP user, in terms of ITN you are welcome to participate and nominate articles about events from other parts of the world, and support other nominations. 331dot (talk) 08:36, 19 August 2023 (UTC)
I'll second that. DYK suffers from an oversupply of US-centric and biographical articles. The folks who are building preps would love to have a greater supply of other topics, so the best thing folks can do to avoid overly US-centric hooksets is to contribute non-US nominations. RoySmith (talk) 14:52, 19 August 2023 (UTC)
Actually the DYK set Special:Permalink/1170916769 was worse than that! 4 all-American hooks, plus an American footballer who plays for Jamaica internationally, plus John Oliver, British-born but long resident (and pretty exclusively known) in the US. That's 6 out of 8. I'm dubious this was caused by a lack of non-US noms. Not to mention a really boring US picture was chosen, when others were available. In fact the hooks seem given in reverse order of interest, especially from a global perspective. Johnbod (talk) 16:51, 24 August 2023 (UTC)

Convert Special:Captcha to the Help namespace.

Self explanatory. I cannot see any benefit to having an all-text special page. 47.188.17.45 (talk) 00:10, 25 August 2023 (UTC)

Good idea. Special pages don't have talk pages, it would be better to move to Help namespace as it would allow editors to modify and discuss wording. Ca talk to me! 02:34, 25 August 2023 (UTC)
Admins can already modify MediaWiki:Captchahelp-text to change the contents of that page. * Pppery * it has begun... 03:27, 25 August 2023 (UTC)
Which is a vastly higher level of "protection" just about all information pages on Wikipedia have (other than templates) Mach61 (talk) 03:52, 25 August 2023 (UTC)
We can't do anything here to get rid of it, no matter what we do it will still be in the code.
FYI, it appears the special page serves two purposes: it is used to display the captcha image and it is used as the help link from various messages. Even if we change the English messages to point the help links somewhere else, it would still be used for other languages (e.g. a page viewed with uselang). Anomie⚔ 10:52, 25 August 2023 (UTC)
Ah, I see. Rescinding proposal. Mach61 (talk) 14:23, 25 August 2023 (UTC)
The messages need something that works in all languages and all instances of mediawiki installed globally. And that is why this uses Special:Captcha to link to this highly critical information. —TheDJ (talk • contribs) 11:20, 25 August 2023 (UTC)

Huh, I guess my IP got unblocked Mach61 (talk) 00:21, 25 August 2023 (UTC)

Checking the community's pulse...not an RfC

Astonishingly, we already have more heat than light and this thread just started. Spartaz Humbug! 17:26, 27 August 2023 (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.

Hi everyone. I'll come straight to the point. Apropos of the discussion at WP:ACN, where there is some discussion about whether Arbitrators should be discussing active cases on other online forums:

Is the community per se okay with Arbitrators discussing open and active cases on outside online forums?

As I mentioned above, this is just to feel the community's pulse, and not an RfC. Thank you, Lourdes 15:14, 27 August 2023 (UTC)

Discussing in what way? "Serious" discussion that could impact the closure of the case, or casual discussion that won't affect it? The latter is fine, the former should stay on WP. Edward-Woodrow :) [talk] 15:30, 27 August 2023 (UTC)
  • Depends on the forum… I do think arbitrators need to be able to discuss cases among themselves - free from being pressured by their fellow Wikipedians. And so, I have no problem with them setting up a (closed/private) chatroom - or similar - to facilitate such discussion. Discussing active cases on open (non-Wikipedia) forums is not. If they are inviting commentary by non-arbs, then that should be done on a Wikipedia subpage. Blueboar (talk) 15:41, 27 August 2023 (UTC)
    We have a mailing list and a closed wiki for those purposes. What Lourdes is getting at is that she doesn't like that I particpate in an offsite forum that discusses WP issues, and she wrongly believes I discussed the most recent arbitration case while it was still underway. This isn't really about policy, it's personal and you can probably just disregard it. Beeblebrox (talk) 17:19, 27 August 2023 (UTC)
  • I don't think I'll ever understand why saying the word "Wikipediocracy" has somehow become taboo. casualdejekyll 15:45, 27 August 2023 (UTC)
    There's a rumor going around that if you say it five times in a row in front a mirror, Jake will appear and make a long, sarcastic comment in your thread. Beeblebrox (talk) 17:17, 27 August 2023 (UTC)
  • This has come up repeatedly over the years, and the fact that people vote for the arbs who comment on Wikipediocracy (and keep voting for the arbs) means that it is acceptable to the community writ large. Der Wohltemperierte Fuchs talk 16:05, 27 August 2023 (UTC)
  • Frankly I've been more concerned with IRC and Discord, two venues with deliberately anti-openess rules and regular canvassing locations, than I am with arbs (former and current I might add) contributing to discussions on a forum that probably has less banned editors than either of the above venues... Only in death does duty end (talk) 16:43, 27 August 2023 (UTC)
  • So, once again, I did not discuss the case in public while it was active. I only commented after the result was clear and there was a majority of votes to close the case. So, Lourdes, maybe try and get at least the very basic facts straight before you come after me about this again. Or, you know, accept the fact that I was elected to the committee, twice, with my particpation there right out in the open and discussed during the WP:ACE process. Your refusal to just let this go is extremely tiresome. You don't think I should be an arb, I get it, as I don't think you should be an admin, but here we are. Beeblebrox (talk) 17:11, 27 August 2023 (UTC)
  • Request speedy close please this isn't about policy, it's about me, and the question as framed misrepresents the situation. Personal grudges are not a good foundation for policy discusiions. Beeblebrox (talk) 17:22, 27 August 2023 (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.

Mascot Pronouns

It's been 5 days since we had any comment on this, and consensus seems pretty clear that there is little appetite for creating any formal rules on this. The following general principles (which are not any different than any other article on any other subject) are sufficient: Follow reliable sources, use a little common sense, and in general the consensus is this is a kind of instruction creep that doesn't improve Wikipedia's already bloated guidance any. --Jayron32 12:40, 29 August 2023 (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 a standard format is created for determining the pronouns of mascots, such as Sports Mascots, and Company Mascots.

In too many articles, the “it” pronoun is used. I believe that this doesn’t sound right and should be changed at once. I therefore propose that the pronouns “he/him/his” and “she/her/hers” be adopted if the gender of the character is known or is obvious from the character’s design. If the gender cannot reliably be determined, then the pronouns “they/their/theirs” should be used, as this is standard for non-binary individuals.

I hope this is a good idea. Thank you. Pablothepenguin (talk) 20:20, 17 August 2023 (UTC)

I think it should be on a case by case basis depending on what the article's sources say. casualdejekyll 21:02, 17 August 2023 (UTC)
Indeed. For example, there is little convincing evidence that central heating boilers identify as non-binary. Certes (talk) 21:09, 17 August 2023 (UTC)
If the gender cannot be determined, then the character must be non-binary by definition. Pablothepenguin (talk) 21:47, 17 August 2023 (UTC)
But they aren't humans, generally, so gender identity doesn't apply. Gender is a human concept. Edward-Woodrow :) [talk] 21:49, 17 August 2023 (UTC)
Animal still have genders, actually. So gender being only a human thing is wrong. Pablothepenguin (talk) 22:26, 17 August 2023 (UTC)
There seems to be some confusion between Sex (physical) and Gender (social/cultural/societal/psychological). Read the leads of those pages. Of course animals have sex, but gender is a human social construction; the lead says as much.
Either way, I don't want to argue minutiae regarding the gender identity of mascots anymore. Bye. Edward-Woodrow :) [talk] 22:29, 17 August 2023 (UTC)
I would look at what the club/company uses. isaacl (talk) 21:11, 17 August 2023 (UTC)
Agree with the editors above: say what reliable sources say, say what the club says. I suspect "it" will continue to dominate and I don't really see a problem with that. Edward-Woodrow :) [talk] 21:41, 17 August 2023 (UTC)
It’s just not natural, though. I would prefer he/she is possible. Please understand that “it” is a very inappropriate word to refer to a person. This should include fictional individuals as well as non-fictional ones. Pablothepenguin (talk) 21:45, 17 August 2023 (UTC)
I thought mascots were generally animals... I think it's fine to refer to mascots as "it", but, again, we should only say what reliable sources say. Edward-Woodrow :) [talk] 21:47, 17 August 2023 (UTC)
I always use he/she for animals whose gender I know. Where such cannot be determined, I’ll probably use “they/them”. Pablothepenguin (talk) 21:49, 17 August 2023 (UTC)
I do the same, but I think mascots are different. Edward-Woodrow :) [talk] 21:50, 17 August 2023 (UTC)
I don’t think they are different, actually. Pablothepenguin (talk) Pablothepenguin (talk) 22:26, 17 August 2023 (UTC)
They're different in that they're lumps of cloth which won't be mortally offended if their pronoun preferences are infringed. Of course, there's a real person with feelings inside, but that might be a man one week and a woman the next depending who's available. Certes (talk) 22:58, 17 August 2023 (UTC)
Just wait till the right realizes that their favorite mascots may be cross-dressing [gasp] in front of children. -- Random person no 362478479 (talk) 23:47, 17 August 2023 (UTC)
I'll say largely the same thing here as I said in a recent discussion on pronouns for chatbots and AI. Mascots are largely fictional characters, the simplest solution to me seems to be to use whatever pronouns the mascot's creator uses when referring to them. If the creator uses he/him, then use he/him. If it's they/them, use they/them. And if she/her, use she/her. Where there are no statements from the mascot's creators, follow whatever pronouns reliable sources use when discussing it. Sideswipe9th (talk) 22:35, 17 August 2023 (UTC)
I know that this approaches WP:WHATABOUTISM, yet in terms of stylistic consistency, it's interesting to see that in an RfC as to whether or not to capitalize a certain term, the consensus was that the creator's wishes and reliable sources don't matter, at least not for that particular issue. Orange Suede Sofa (talk) 23:28, 17 August 2023 (UTC)
The difference in that case, as I see it, is that Wikipedia's manual of style has a general rule on capitalisation; that RfC was asking to carve out a specific exception to it, and people didn't find the arguments to institute an exception compelling. In this case, we don't as far as I know have a general rule on pronouns which applies to characters; in the absence of any Wikipedia-specific style rule we would normally refer to characters using the pronouns in the source material or used by reliable sources. Of course, we could introduce some other rule, but I'd like to see some evidence that this is a problem before writing such a specific guideline as which gendered pronoun to use for mascots. Caeciliusinhorto-public (talk) 08:19, 18 August 2023 (UTC)
Sometimes they make it easy for us: Albert and Alberta Gator. - Donald Albury 23:31, 17 August 2023 (UTC)
"Costumed in plush, Albert and Alberta are Florida representations of American alligators, which are commonly found throughout the state of Florida. He was named after Albert Einstein." Apparently they use "he" when referring to both. Then again, it's Florida. -- Random person no 362478479 (talk) 23:53, 17 August 2023 (UTC)
They may be in plush now. I remember when Albert (single, then) was a live alligator in a cage on campus. I'm not sure whether anyone actually knew what sex those alligators (I'm sure there was more than one over the years) were. And this is the first I've heard about the connection to Einstein. Donald Albury 00:19, 18 August 2023 (UTC)
That last sentence was vandalism (see [2] where it was added); I've removed it.
As for the rest of this discussion, it's not clear to me there is any existing issue here—looks like most mascots with clear gender identities are referred to by appropriate gender pronouns. @Pablothepenguin, do you have examples of articles where there is an issue here? Is there a reason this can't simply be fixed in places where "it" is wrong? Dylnuge (Talk • Edits) 14:46, 21 August 2023 (UTC)
If the mascot has verifiably expressed a preference regarding their gender and/or pronouns then we should absolutely follow that preference. In the absence of such we should follow what the reliable sources do, with a preference for more recent ones if usage has changed. Anything else risks engaging in original research. Thryduulf (talk) 00:33, 18 August 2023 (UTC)
I must make note of the following important points in considering this issue:
  1. Sentient beings, fictional or otherwise shouldn’t be referred to as “it” EVER. It just sounds unnatural and wrong.
  2. Usually fictional characters DO have a gender. Mascots are no different.
  3. Mascots are typically anthropomorphic animals, plants, foodstuffs, or objects, although these aren’t the only things they can be. Anthropomorphism is when human-like characteristics are given to an entity that doesn’t normally have them. This is generally understood to include gender.
  4. There should be no problem assuming gender if it is blatantly obvious.
  5. I tend to assume that all mascots are male unless they have something like eyelashes or women’s clothes. Yes this is old-fashioned, but it’s the best I’ve got.
  6. Have this officially codified in the MoS, it’s just a good idea.
I request that we proceed to proposing an amendment to the MoS for this matter. Do I have any objections? Pablothepenguin (talk) 22:27, 18 August 2023 (UTC)
I said I'd go away, but here I am again...
Just say what reliable sources say. That's what we always do; we really don't need some complicated MOS guideline about it. Also, I think it's fine to call mascots "it", even though I can't explain why. Also, are they sentient? They're just fictional characters.
Okay, this time I'm off for good (unsubscribing from this discussion). This is a pointless argument and a solution in search of a problem.
@Pablothepenguin: There really isn't much of a problem here; let's just do what we always do: SAY WHAT RELIABLE SOURCES SAY. That's our purpose; we just regurgitate what other people have said. And we don't need another finicky MoS guideline that will be ignored by 95% percent of editors and pointlessly and unforgivingly enforced by the other pedantic 5%.
Oh, and yes, I object. Edward-Woodrow :) [talk] 22:34, 18 August 2023 (UTC)
A fictional character is STILL sentient, people! Anyway, if I were to compile my head canon into several hundred volumes, and publish them on an internet blog, would that count as a reliable source? Pablothepenguin (talk) 23:09, 18 August 2023 (UTC)
No, it wouldn't. Schazjmd (talk) 23:20, 18 August 2023 (UTC)
A fictional character is not sentient. They have no facility of perception. Please read the room. No one is on board with your plan. Presumably, if someone else shows up who shares your perspective, they'll say something. Folly Mox (talk) 23:21, 18 August 2023 (UTC)
Where do you get your ideas from? Fictional characters are sentient, and the actors who portray them make sure to use good perception where appropriate. Pablothepenguin (talk) 00:23, 19 August 2023 (UTC)
The literal definition of sentient is able to perceive or feel things - a fictional item is definitely not able to do so. Anyone portraying them is using their own perception. More generally, go with sources, go with what their creators say, go with what seems directly obvious, and only then use "they" if a personified mascot or "it" if an object-esk mascot. Nosebagbear (talk) 01:24, 19 August 2023 (UTC)
We must be thinking of different things when we use the words "fictional character". I think of fictional characters as a collection of ideas their author thought up and subsequently wrote down or otherwise conveyed. A piece of artifice. I suppose I might characterise the definition I see you promoting here as an "in-universe" perspective. I'm really not certain how we got here from mascots though, so my input is probably not especially helpful. Folly Mox (talk) 01:25, 19 August 2023 (UTC)
Yes, I do have an in-universe perspective. Fictional characters do have sentience in that respect. This is something that should be reflected on this wiki. Perhaps the mascot articles need to be altered to sound more in-universe? Pablothepenguin (talk) 16:39, 19 August 2023 (UTC)
Are you familiar with Wikipedia:Manual of Style/Writing about fiction#The problem with in-universe perspective? Donald Albury 16:45, 19 August 2023 (UTC)
If you would like an example of the kind of change I’m trying to promote, you can find it at the 2023 FIFA Women's World Cup article. Can you see how the new text is simpler, more natural, and less weird-sounding? Can you see how it now sounds more like natural speech, and how the clunkiness has been reduced? That is why I request that change. Otherwise, the articles would sound a bit too cold and artificial. Wikipedia should not be written that formally, it should feel more casual and approachable. It also needs to work for people who have poor English skills or who are still only children. I hope you take this on board and realise how much better my method is. Thank you for your consideration and time. I remain Pablothepenguin (talk) 13:16, 20 August 2023 (UTC)
The cited source in that example consistently uses she/her pronouns to refer to the mascot, which simply reinforces what others have said previously in this discussion: follow the sources. Schazjmd (talk) 13:43, 20 August 2023 (UTC)
This should best be decided at the individual article level. Some pages may benefit more than others from this proposal if it was universally adopted. InvadingInvader (userpage, talk) 02:00, 21 August 2023 (UTC)
We have a lot of style guidelines already - is there a way we can get by without adding another? If we get too many rules we’ll turn into the internet’s Book of Leviticus.
—A. B. (talk • contribs • global count) 01:08, 24 August 2023 (UTC)

Bluntly, Pablo, this is a solution in search of a problem. Just because you have a WP:IDONTLIKEIT aversion to the use of "it" does not mean that a global project must change ongoing practices to accommodate your rather neurotic-sounding concern. --Orange Mike | Talk 16:11, 24 August 2023 (UTC)

WP:Wikipedia is not a bureaucracy would seem to be the most relevant policy here. We should be trying to reduce the amount of bureaucracy on Wikipedia not increase it. I'm not seeing a single argument in the whole of the above thread as to why this very niche issue needs its own rule as opposed to going by existing policy and following the sources. I could see a need for a rule if someone was going through them fixing them with cited edits and getting resistance. ϢereSpielChequers 16:34, 24 August 2023 (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.

Change some visa requirements on map when entering to Australia and/or New Zealand

Hello Wikipedia users and admins! I have a proposal for you to update some maps on the Visa requirement articles for some countries and Visa Policy of the countries that require or not visa for these countries. I have seen on Visa requirements for Uzbek Citizens that Australia is highlighted in light green which means that an Online Visitor e600 Visa is required for Uzbek citizens to enter Australia. So for Balkan countries that are in agenda to enter the European Union in the future (Albania, Bosnia and Herzegovina, Montenegro, North Macedonia and Serbia) in the visa requirements section Australia should be in light green on the map, since it also requires an Online Visitor e600 Visa for these countries. In addition, the countries that Australia requires this Online Visa Australia should be in light green.

For New Zealand, "Holders of an Australian Permanent Resident Visa or Resident Return Visa may be granted a New Zealand Resident Visa on arrival permitting indefinite stay (pursuant to the Trans-Tasman Travel Arrangement), subject to meeting character requirements and obtaining an Electronic Travel Authority prior to departure", I think you should consider highlighting New Zealand in light green for these countries (Albania, Bosnia and Herzegovina, Montenegro, North Macedonia and Serbia) that Online Visitor e600 Visa of Australia is applied for these citizens which can travel to New Zealand. And also for the other countries which Australia has the Online Visitor e600 Visa, consider New Zealand to be highlighted in light green.

Thanks EDASHI (talk) 00:36, 1 September 2023 (UTC)

Hi EDASHI, you should post these comments and the accompanying sources that you got these quotes from on the relevant article talk pages, where it is more likely that editors engaged with those topics will see them. Best, CMD (talk) 04:23, 1 September 2023 (UTC)

Time to rethink Rotten Tomatoes inclusion/centrality to film pages?

A recent article in Vulture describing both the manipulations of Rotten Tomatoes by film studies and the shifts in the review aggregation policies raises some serious questions about the site as a barometer of critical success. At the very least, the site that established itself widely on Wikipedia operates differently today and would have prompted very different conversations about its inclusion. Given how central these aggregators are to the "Critical Response" section of film wikipedia pages, is it time to rethink the idea that it is a reliable source? If so, what is an alternative? Infocidal (talk) 17:03, 6 September 2023 (UTC)

User:Infocidal, you may want to move this topic to WP:VPI or Wikipedia Talk:WikiProject Film. It's not really fit for purpose at this venue. Folly Mox (talk) 17:09, 6 September 2023 (UTC)
I was thinking that Wikipedia:Reliable sources/Noticeboard might be the appropriate venue for this. - jc37 17:11, 6 September 2023 (UTC)

Thank you for the suggestions! I'll move it there. Infocidal (talk) 17:30, 6 September 2023 (UTC)

Give NPR additional rights?

I was going through the requests for page mover this morning, and it occurred to me (as it usually does) that a large number of folks asking for PGM are New Page Reviewers who are looking to suppress the creation of a redirect during draftification in order to avoid an extra WP:R2 nomination. I guess my question is, would it be reasonable to assign suppressredirect to the patroller userright to allow them to do this by default? (please do not ping on reply) Primefac (talk) 08:32, 29 August 2023 (UTC)

  • Support in theory but I would be concerned that this might become a springboard further down the line for giving NPR reviewers automatic wider page mover rights, which would be a Bad Thing. Ingratis (talk) 08:58, 29 August 2023 (UTC)
  • I'm unsure. Included in suppressredirect is the ability to do round-robin moves, move editnotices, and do non-draftification-related redirect suppression, all of which are quite complex and unrelated to NPR; so I personally think the extra step of bureaucracy and the minor inconvenience of R2 nominations is warranted here. Curbon7 (talk) 09:07, 29 August 2023 (UTC)
    That's fair, and one of the reasons why I will sometimes decline requests like these. The current guidelines for granting definitely focus more on those aspects as well, as draftification was clearly not something that this was initially intended for. NPRs asking for the perm right now won't be using it in any of those manners either, though. Primefac (talk) 09:13, 29 August 2023 (UTC)
    An extendedmover's ability to move edit-notices should not be related to suppressredirect, but rather tboverride, since they're protected by MediaWiki:Titleblacklist. Sdrqaz (talk) 01:06, 30 August 2023 (UTC)
    Perhaps I'm confused. WP:Page mover#Flags granted states that tboverride lets you move, edit, or create editnotices, but according to WP:PMRC#8 suppressredirect also lets you Move an editnotice to a subpage of Template:Editnotices to marry the editnotice with its appropriate page, unless I am misunderstanding what that is referring to. Curbon7 (talk) 01:25, 30 August 2023 (UTC)
    Moving/editing an editnotice requires tboverride. WP:PMRC#8 is just saying that if you do move an editnotice, you're allowed to use suppressredirect and suppress the redirect. Extraordinary Writ (talk) 03:19, 30 August 2023 (UTC)
    Ah thanks, scratching that part. Curbon7 (talk) 03:39, 30 August 2023 (UTC)
  • Just wondering, noting most draftifications are slow pseudo-deletion, should draftification be wound into a draftprod process matching WP:PROD. With suppressredirect, draftification will be completely unilateral for the lowest level NPR. —SmokeyJoe (talk) 09:26, 29 August 2023 (UTC)
    Oppose, wrong direction, to make unilateral draftifications easier and quieter. Instead, propose WP:PROpDraftify, to work the same as WP:PROD. Currently, new article writers are not given enough information, such as AfC and DraftSpace are optional, and their right to WP:DRAFTOBJECT. I believe that their is no indication of bad intent by any current NPReviewer, but their were poor reviewers in the past, and but their are indications that the NPR draftification standard is different to the AfD standard, which I think is a bad thing.
    Where this proposal generates more problems than solutions, junk in mainspace sitting a seeker longer, I think the answer is to remove the ability of nonautoconfirmed editors to make new mainspace articles. Or, overwrite a redirect.
    Having a COI is a reason to mandate use of AfC and Draftspace or userspace. SmokeyJoe (talk) 22:42, 31 August 2023 (UTC)
    Instead of creating a whole new process and all the associated bureaucracy that entails, wouldn't it be easier and nearly as effective to add some version of the italicized text in {{prod}} to the various {{AfC submission}} subtemplates, and/or perhaps to {{Drafts moved from mainspace}}? "<span class="autoconfirmed-show">You may [[Special:MovePage/{{FULLPAGENAME}}|move this draft]] into the main namespace yourself if you improve the article or otherwise object to its removal from the main namespace for any reason. Although not required, you are encouraged to explain why you object... etc etc." —Cryptic 23:09, 31 August 2023 (UTC)
    I think it is a very positive feature for an article writer to be given seven days to respond to a criticism before the article is draftified. SmokeyJoe (talk) 03:41, 1 September 2023 (UTC)
    remove the ability of nonautoconfirmed editors to make new mainspace articles - this has been a thing since 2018. Primefac (talk) 07:20, 1 September 2023 (UTC)
    Thanks. I didn’t know it was actually implemented.
    Wikipedia talk:Autoconfirmed article creation trial/Request for comment on permanent implementation#ACPERM is now live. SmokeyJoe (talk) 14:16, 1 September 2023 (UTC)
  • CAT:R2 never seems to be significantly backlogged, so I'm not sure the slight increase efficiency is worth losing the sanity check from an admin. As Smokey alludes to, there is already a distinct lack of oversight of articles being moved to draft and then autodeleted. – Joe (talk) 09:35, 29 August 2023 (UTC)
    If that's the case (and I do suppose this is a question to ask at PERM) - should we (admins) be declining requests from NPR who are asking for Page Mover purely because they want to draftify without leaving a redirect? Primefac (talk) 09:39, 29 August 2023 (UTC)
    Good question. – Joe (talk) 19:23, 29 August 2023 (UTC)
    I don't think so, but we shouldn't be as quick to grant such requests when there is less experience (generally speaking) in knowledge of page titles demonstrated by particpation in RMs or at RMTR or in {{db-move}} requests etc. Sdrqaz (talk) 01:06, 30 August 2023 (UTC)
  • Moving an article to an obscure place outside mainspace can be a seriously abusive action. Does some bot or filter look for this? Without an attentive admin spotting it before R2 there can be problems. Thincat (talk) 10:21, 29 August 2023 (UTC)
    JJMC89 bot has a task for that issue, and makes reports on draftifications. I would say, however, that R2s are generally very quickly deleted, without much monitoring. When some of our administrators are active, pages very seldom stay in CAT:R2 for more than five minutes. I refuse on principle to delete those which I believe are inappropriate draftifications, but I think that's rare. I try to hold people accountable, but there is simply too many R2s and speedy deletions in general to be sufficiently comprehensive. Sdrqaz (talk) 01:06, 30 August 2023 (UTC)
  • Meh, they can just ask for both if they want it. Perhaps if there are some stats of how many patrollers are actually using move, vs just doing the other patrol functions? Just did a random check of 10 patrollers that are not xmovers, only one made a main->draft move in the last year. — xaosflux Talk 10:23, 29 August 2023 (UTC)
    I've made several in the last couple of weeks alone. I think in general NPP is reluctant to use draftification because of the issue of 'it's a back door to deletion' but right now the queue is rising fast and some harder decisions need to be taken. PROD is next to useless and AfD is overloaded, FWIW. There's a lot of stuff in the queue that really doesn't belong in mainspace and arguably isn't even fit for an AfD... Best Alexandermcnabb (talk) 14:21, 29 August 2023 (UTC)
    PROD is next to useless? Can you say more? If de-PRODed, do you take it to AfD where it gets kept? If so, this means that NPR is a tougher bar than AfD, which would be the root problem. SmokeyJoe (talk) 06:39, 30 August 2023 (UTC)
    It's an additional step - an article will almost invariably be de-PRODed unless the creator has been blocked or hit by a bus. AfD is, as I said, overloaded and you have the nagging issue of AfDs closing with no/minimal participation. AND you can only really send so many articles to AfD every day - with >10,000 articles (and rising fast) currently in the NPR queue... Best Alexandermcnabb (talk) 12:36, 30 August 2023 (UTC)
  • I think I understand the use here. But as "leaving no redirect" is essentially a form of deletion, I'm hesitant to group it with "new page reviewer". I also think, having it grouped with a "mover" user-right, makes clear what policies that the user is accountable to. While I have no doubt that you are thoughtful in giving these out, at rfp, how do we know that some random admin, merely looking at the user-right name, is going to know? I'm not trying to be difficult, I just would like to avoid unintended accidents and consequences. - jc37 10:27, 29 August 2023 (UTC)
  • Question. I often see the claim that draftification is a form of deletion. Do we have any numbers for how often an article moved to draftspace is G13ed versus moved back to mainspace or deleted for some other reason, like spam or copyvio or G5? Folly Mox (talk) 10:48, 29 August 2023 (UTC)
    I'm not sure there is a number, but speaking as someone who frequently checks the G13 queue, it is at least a significant majority. Curbon7 (talk) 19:56, 29 August 2023 (UTC)
    As an example, see Draft:Ladislav Karel Feierabend, a draftified article of an entirely notable person (cs:Ladislav Karel Feierabend) that is about to G13 expire. Curbon7 (talk) 01:52, 31 August 2023 (UTC)
    Does a minister of a government in exile pass NPOL? Personally, I'm not sure. If you're sure they do, feel free to move it to mainspace. –Novem Linguae (talk) 02:39, 31 August 2023 (UTC)
    I was thinking more in terms of WP:GNG than WP:NPOL. I just happened to see this particular example in today's User:SDZeroBot/G13 soon. Curbon7 (talk) 02:42, 31 August 2023 (UTC)
    Oh my gosh, can anyone who is good at formatting somehow apply a minimum width to the columns in the table at User:SDZeroBot/G13 soon? On my device, every column but "Excerpt" was squished down to the narrowest width allowable to display the sort arrows next to the column header (functionally, two to three characters). It's entirely illegible, and I still have to do a sidey scroll to see either the first or the last column, since exactly one is always outside the browser edge. Folly Mox (talk) 03:39, 2 September 2023 (UTC)
  • This is relevant reading on this issue. I think I still stand by my previous concerns about how outside the context of frequent draftifiers (who can simply apply for page mover), the fairly small benefit (saving admins time on R2s) is probably outweighed by the risk (handing out a right that can be used for much more than draftifications) in most cases, particularly given Xaosflux's comment above. Extraordinary Writ (talk) 19:11, 29 August 2023 (UTC)
  • I don't think it's really necessary. I mean, it's not like R2 is always on the brink of overflowing. Edward-Woodrow :) [talk] 20:36, 29 August 2023 (UTC)
  • No, I don't think so. I got extendedmover before patroller, but I got it mainly because of my draftifications instead of RM experience. I would be more receptive to this idea if we could (somehow – not holding my breath) make MediaWiki distinguish between mainspace moves to draftspace and other types, but I would still be against because often people use draftification as a means to just lower the backlog and to sequester things that they don't believe are notable (see Wikipedia:Drafts § During new page review for what is appropriate).
    This is before I start complaining about patrollers that move articles to draftspace minutes after people have published. Additionally, I think that people's understanding of what constitutes a implausible redirect is rather poor, and as people with suppressredirect can effectively unilaterally carry them out, widening the pool of people with that ability – when they aren't necessarily intimately aware of these policies – would not be a good thing. Sdrqaz (talk) 01:06, 30 August 2023 (UTC)
  • Support. Pro: Less work for admins having to delete CSD R2s resulting from draftification (and there's a decent number of these, and they just seem like admin busywork to me). Con: Slightly less oversight during the draftification process (I don't think reviewing the appropriateness of the draftification is required by WP:R2, but some admins like to do this anyway). Con: Potential for NPPs using this ability to suppress non CSD R2 redirects inappropriately.
    Weighing the efficiency of not clogging the R2 queue with the possible cons, I personally think it'd be worth it. It's good to make workflows more efficient. I understand if others arrive at a different conclusion though. –Novem Linguae (talk) 01:32, 30 August 2023 (UTC)
  • Oppose. I believe that redirects tagged for R2 can continue to benefit from a second set of eyes prior to deletion, as I have seen instances in which draftification was not appropriate or the criterion was used out of process. Also, in my experience, CAT:R2 is not a backlog for admins. Users trusted to handle potentially contested moves should have no issues requesting extendedmover separately. Complex/Rational 01:59, 30 August 2023 (UTC)
  • ComplexRational sums up my thoughts on this perfectly.Our usernames also sound somewhat similar! casualdejekyll 02:05, 30 August 2023 (UTC)
  • Support It's similar (IMHO) to autopatrolled - if an editor/patroller is experienced and has had no behavioural issues, and conferring the right reduces rote-work, I can't see the issue. I'm on my second 3-month trial through Primefac - surely the bar is high enough to stop badge collectors and troublesome editors but also let NPP send articles to Draft as part of the discretionary toolset that comes with the job? I'm already cautious about draftifying and would argue we should be sending more, not less, to draft actually... Best Alexandermcnabb (talk) 12:43, 30 August 2023 (UTC)
  • Oppose per ComplexRational. We should not be making incorrect use of draftication (whether intentional or otherwise) harder to detect, and there seems to be no evidence that R2s are causing any problems while there is evidence they can provide an additional level of checks. Thryduulf (talk) 14:55, 30 August 2023 (UTC)
  • Comment The nuclear "back door" to deletion is already available to millions of editors.....conversion to a redirect. Draftification is milder than this and AFD, it preserves the article and gives the editor to develop it. I'm really tired of seeing the volunteers who are doing the soul-crushing NPP work get insulted by making it sound like they are "up to no good" when they choose this mildest of the three main possibilities. Sincerely, North8000 (talk) 02:20, 31 August 2023 (UTC)
Old-now-but-best-we-have data on articles by new editors surviving 30+ days; breakpoint where Article Wizard began presenting AfC as the default (a couple months later it removed the option to publish to mainspace)
Oppose and oppose the practice of routinely granting PMR for this purpose. I have more I can write on the NPP-to-PMR pipeline -- PMR is an unbelievably janky right, easily the most awkwardly gerrymandered of the unbundles. The substantial proportion of people with it who use it primarily to draftify rather than to move pages obscures this by moving it away from its primary and most complex use case; this inhibits discussions about why PMR is like this, how to resolve it, and how we can move forward. (Examples of PMR Jankiness: it is very possible and not even especially rare to get tangled into multi-layered multi-page misplacements if two PMRs attempt to respond to a move request at once; it's impossible for PMRs to independently perform "move a draft to a redirect with significant (i.e. previously BLARed) history" without losing that history entirely, so admin workload does not decrease; PMRs cannot move through protection, so some substantial share of RMs at any given time are unclosable without added bureaucracy and admin work, because PMR-era RM has negligibly few admin patrollers.)
Data on draftspace and its impacts on article creation is sparse and difficult; the overlap between what research occurs on the Wikimedia Movement (sic) and what research is directly relevant to enwiki editors and readers is unspectacular. However, we have data from the early-mid-2010s changes (which substantially increased the prominence of AfC and draftspace) at m:Research:AfC processes and productivity. I've transcluded the image, because it's striking; there is an immediate, major falloff of articles by new editors surviving for a month when the Article Wizard begins strongly-implying or outright-saying you need to use AfC. This is not a consequence of AfC backlogs, at the time, because the same data says that back then they were short (we can expect that stats are much worse now). The issue is primarily some quality of draftspace itself.
It's not clear what part of draftspace drives this effect. The effect (we can trace from anecdata after our data ends) remains evidently the case, and several factors (e.g. AfC wait times) have gotten far worse. The hidden/"storage bin" status of draftspace seems clearly an element, as do the "another word for GAN" tendencies that come up at AfC sometimes. (SmokeyJoe alludes to the NPP equivalent re. "PROD is an extra step". I note my first article was prodded by a prolific NPPer, removed with a paragraph-long explanation, and taken to AfD with an identical justification to the prod. It was unanimously kept upon reposting of that explanation.) Other elements are more complicated. It's highly nonobvious to new editors that draftification is disputable, or that AfC is optional in the first place. PRODs are obviously disputable -- new editors are told clearly they can remove them -- but we do what I suspect is an intentionally poor job at telling people they're able to move a draftified page back (and that it can be reasonably taken as dispute grounds for an AfD, in the same sense as PROD). I suspect many people develop a preference for draftifying over prodding because it's less likely to be disputed. It is difficult to remember, sometimes, that disputes are a sign of a healthy process.
One sub-issue is that while R2 prescriptive-should be checked to make sure draftifications are at least defensible, it descriptive-isn't. Most "simple" CSD categories are processed rapidly (sometimes within seconds) by a small number of admins. R2 is generally treated as a "simple" category for these purposes, which is arguably a misplacement. There's a tricky problem here where many actions that should have some kind of external review, and are set up to permit some kind of external review, consistently fail to have it at multiple steps.
There's also another sub-issue that our inclusion standards are completely inside-out. "Notability" is a good enough concept for enough cases, but the WP:ATA-thumping holy-writ interpretation of various exactingly literal readings of it as the only appropriate benchmarks actively worsen Wikipedia. ("Quality and usefulness aren't relevant to our standards" is a great way to make something that's useless and low-quality.) Draftification exists in part as one way to handle "an ATA literalist might insist on the blatantly, obviously wrong outcome and I don't want to take my chances" (for the inclusionist-leaning equivalent to draftification's deletionist-leaning variant, see the keep arguments in any AfD for an article that's written in a way that by Wikipedia's policies can only be written from notability-passing sources, where the nominator thinks on some technical grounds it might not 'actually' be notable). This makes disentangling problematic and nonproblematic draftification difficult, and in general complicates the whole practice. It's not an argument against oversight, though -- if anything it's one for it. Vaticidalprophet 11:49, 31 August 2023 (UTC)

Refideas notification upon editing an article

I propose that whenever a user clicks "Edit" on any article that has the Template:Refideas on its talk page, that the user will see a small yellow text box above the editing area that says "There are suggestions for sources on the talk page that you may find useful."

I brought this idea up at Wikipedia:Village pump (idea lab)#Refideas notification upon editing an article[3] and received positive feedback from @Edward-Woodrow, @Donald Albury, @JimmyBlackwing, @A. B., @Folly Mox, @Timur9008, and @Freedom4U so I am bringing it for a proposal. See that discussion for more background. BOZ (talk) 17:51, 25 August 2023 (UTC)

I do support this idea and am unclear on the implementation details. Will this require a software change? Can it be implemented as an Editnotice? Would a bot-delivered usertalk message after an editor first edits the article, in the vein of User:Qwerfjkl (bot)#Task 17, be an acceptable fallback method? Folly Mox (talk) 18:01, 25 August 2023 (UTC)
I imagine it working somewhat similarly to how users get a notification of an existing draft page when an article of the same name that does not exist. For example, pulling a random draft: [4] I would not want anyone to get a talk page notification for this idea I had. BOZ (talk) 18:19, 25 August 2023 (UTC)
I'll admit I don't know much about how technical implementation works so I may not be able to answer questions about that. BOZ (talk) 18:21, 25 August 2023 (UTC)
Pinging two arbitrary very helpful technical users who seem to have a strong knowledge of the software: @PrimeHunter and Pppery: sorry to pick on yall, but what's the most realistic way this idea might be implemented? Folly Mox (talk) 18:01, 26 August 2023 (UTC)
Probably via an edit to Template:Editnotices/Namespace/Main (which any admin can do), although for historical (?) reasons the related Template:Disambig editintro and Template:BLP editintro use JavaScript code instead - those should probably also be moved into Template:Editnotices/Namespace/Main. * Pppery * it has begun... 18:16, 26 August 2023 (UTC)
Appreciate you, thanks.  :) BOZ (talk) 21:39, 26 August 2023 (UTC)
Support: pretty clear benefit to the project. Edward-Woodrow :) [talk] 19:46, 25 August 2023 (UTC)
I also support the idea, but have no insight on implementation. Donald Albury 20:56, 25 August 2023 (UTC)
I can get behind this. Refideas is something I have made use of in the past, in order to mention that I found useful articles for other editors (who have more experience in the subject area) to use. It's a shame they're not super prominent, because it's a really great feature! SWinxy (talk) 04:13, 26 August 2023 (UTC)
  • I would suggest at this point creating a template {{Refideas editnotice}} to the effect of {{Editnotice | image = [[File:Nuvola apps package editors.png|35px]] | style = background: #FFFAEF | text = There are suggestions for sources on the talk page that you may find useful.}}. It can be trialed manually with several pages (rather than all 17,000(?) pages that transclude Refideas) to see if people find it helpful. Placing the editnotice on a limited number of pages (say, with an expiry of 30 days) would just require the assistance of a template editor, page mover, or admin.
SilverLocust 💬 07:06, 29 August 2023 (UTC)
Ooh, I love how that looks. :) I'm also 100% open to suggestions if anyone can think of a better wording. BOZ (talk) 14:13, 29 August 2023 (UTC)
I kind of wish that the normal talk page banners (the "coffee roll" color) was lighter/higher contrast like this. WhatamIdoing (talk) 03:16, 1 September 2023 (UTC)
I think the crudest implementation would be via a bot. Is there a way for an edit notice to read the content of the attached talk page? Jo-Jo Eumerus (talk) 09:11, 29 August 2023 (UTC)
Um I think that might be possible if {{Refideas}} were edited to include code allowing for labeled section transclusion, which the editnotice could then transclude using the {{TALKPAGENAME}} magic word for the article it's being called from? But I'm not sure this is what you're asking, or why it would be desirable (to preview the reference ideas?).
I just reread Wikipedia:Editnotice, and it says that editnotices are kept in subpages of Template:Editnotices, like Template:Editnotices/Page/Cao Wei, so the act of adding the editnotice would just involve creating a subpage which calls a single template like User:SilverLocust's mockup above. I'm also not sure if this is what you're asking. I'm also not a particularly technical user, nor very smart in general. Folly Mox (talk) 02:56, 9 September 2023 (UTC)
Give yourself more credit, I wouldn't have even thought of those ideas. ;) Although it may be my idea as the genesis, it's really up to anyone in the community to find the best way for this to work for everyone. The example you gave makes a lot of sense; I also just recalled that we get a notice whenever we edit a BLP and I think the same could work when we edit an article with the Refideas template on the talk page. I feel this is coming together. BOZ (talk) 15:59, 9 September 2023 (UTC)
Namely, Template:BLP editintro BOZ (talk) 16:04, 9 September 2023 (UTC)

Proposal to a new login method, security login

Tracked in Phabricator
Task T321708

I've read about Microsoft's passwordless authentication for a while, normally hackers have your password, then crack into your account. F2A 2FA makes this harder but also cause burden to the normal user, for example, you need to request for right on meta wiki, taking out your phone and then logging in. Microsoft's passwordless authenitication comes up with a new way, they don't need password any longer, all you have to do is using another device to click "permission". Unless other ones have your device, this method is nearly the safest.

Is there any techincal burden for such a new method for Wikipedia? Is this proposal legitimate? I'm not sure and want to hear your advice. -Lemonaka‎ 12:24, 6 September 2023 (UTC)

Not everyone has "another device". Edward-Woodrow :) [talk] 12:29, 6 September 2023 (UTC)
So oppose. Edward-Woodrow :) [talk] 20:20, 6 September 2023 (UTC)
Unless "other device" includes a POTS land line, it will drive people away. In impoverished countries, even that might be an issue. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 13:44, 6 September 2023 (UTC)
Exactly. 2FA is bad enough. Edward-Woodrow :) [talk] 20:20, 6 September 2023 (UTC)
Chatul, I have no POTS landline. I can't get one at all as the service provider that used to offer it discontinued it, pushing existing users to their fiber solution. In several impoverished regions, mobile phones are actually more common because they never built the infrastructure for POTS, and a cell phone tower is probably cheaper than digging for miles to put copper into the ground.
Forcing the use of another device brings another problem: that "other device" will often be running some closed source code. Admittedly this is true for most computers (firmware is usually closed), but at least the software can be open. For that "other device" this is not the same. No major player sells a phone with Lineage OS or similar preinstalled and installing it yourself isn't nearly as simple as installing for example Ubuntu. And the suggestion from OP to hook into some proprietary cloud service isn't helping either.
Allowing users to enable 2FA if they want it, no problem. Making it a requirement, big no. — Alexis Jazz (talk or ping me) 02:03, 8 September 2023 (UTC)
Wll, if you have neither a land line nor a cell phone, then TOTP and VOIP may be your only options. Is either of those acceptable to you?
BTW, I wasn't suggesting that a land line be required, just that it be one of the options. -- — Preceding unsigned comment added by Chatul (talk • contribs) 13:51, 8 September 2023 (UTC)
Chatul, I can get phone service, just no POTS/Landline.
I don't like the idea or requiring users to use a phone service though. Phone service (unlike e-mail) can't be self-hosted and always costs money. While the same could be said for the internet (not counting places with free wifi), Wikipedia simply can't work without internet but Wikipedia can work just fine without 2FA. And with VoIP you'd be unable to log in when someone's on the phone!
In general SMS is a bit more accessible and practical, but who's gonna pay for it? And even then, when you are traveling it may not work. Wikimedia should not require 2FA. Making it easier to opt into (without having to request special rights) is obviously fine with me, but it should not be a requirement. Top of the Pops/E-mail is fine but should still not be a requirement. The terrifying thing about e-mail is that if you lose access to your mail address you'll lose access to many services as they rarely provide the option to enter a secondary mail address in case the primary address fails. This has been a reason for me to disable 2FA on some sites, so I won't be locked out if my mail address stops working. — Alexis Jazz (talk or ping me) 09:29, 9 September 2023 (UTC)
As an aside (as it doesn't really change your basic arguments), you can run your own VoIP PBX if you really want to, and a VoIP client on computing devices other than phones. isaacl (talk) 14:03, 9 September 2023 (UTC)
Isaacl, true, I think something like Asterisk (PBX) could be used to set up your own telephone network, but it wouldn't have a public number so wouldn't work for this purpose. As I was thinking about it, while you can technically self-host e-mail, it's not very practical as you'd have to mail an IP address instead of a hostname like "janedoe@[94.256.27.64]". Otherwise you'd still depend on a third party to obtain a domain or subdomain which at least partially defeats the purpose of self-hosting. Though anyone who has a domain could give away unlimited subdomains without asking questions, so even that part would still be easier and cheaper than obtaining a public telephone number. — Alexis Jazz (talk or ping me) 14:03, 10 September 2023 (UTC)
Yes; I was just pointing out that conceptually (leaving cost aside), running your own mail server or VoIP PBX can be done, with both requiring registration with an external network to receive messages/calls. isaacl (talk) 16:01, 10 September 2023 (UTC)
How is this less of a burden than regular 2FA? The difference between clicking a button and typing a code isn't that big a deal; the issue is having to deal with a separate 2FA device/system, and this has the same exact problem. Writ Keeper ⚇♔ 14:53, 6 September 2023 (UTC)
@Lemonaka think this should be withdrawn, not on the idea, but for venue. As logons are global, if this becomes available globally it will apply here - there is nothing for The English Wikipedia to decide here. There is already a feature request open, phab:T321708 for this concept. It would first need to become available for mediawiki software at all, then be accepted for use with Wikimedia Projects. — xaosflux Talk 15:19, 6 September 2023 (UTC)
Note: If T321708 doesn't fully encompass what you are proposing, you can file a feature request for the software team to further explore the idea as well. — xaosflux Talk 15:20, 6 September 2023 (UTC)
If I understand correctly what the OP is proposing is to adopt push-based 2FA, i.e. the "Approve Request" button in the Microsoft Authenticator app. AFAIK that would require Wikipedia to hook into Azure AD which is a nonstarter. But passkeys are the superior alternative anyway. DFlhb (talk) 15:29, 6 September 2023 (UTC)
I agree that wikimedia's authentication system needs modernizing. I'm neutral on specifically which technology(ies) should be suported, but I'm certain that anything that's proprietary is, as noted above, a non-starter. And, yes, this is the wrong forum for this. Either the phab ticket noted above, or perhaps someplace like mw:Manual:SessionManager and AuthManager or meta:Help talk:Unified login would make more sense. RoySmith (talk) 15:40, 6 September 2023 (UTC)
I'm neutral on specifically which technology(ies) should be suported I know this is the wrong place to answer, but since xaosflux is here:
  • expand TOTP 2FA to all users
  • add support for passkeys
  • add support for SMS-based 2FA (unfairly maligned, though would require WMF help)
would be the most well-rounded common-sense roadmap. Also, WMF, if you're listening, please start paying a salary to xaosflux, TheDJ, and all the others I don't know about who more than deserve it. DFlhb (talk) 16:13, 6 September 2023 (UTC)
@DFlhb the main problem we have with TOTP2FA expansion is that unlike with many other web services, recovery is a real hassle because we don't have strong identity information for our users. If you screw up your bank's 2FA - you can usually recover with some government ID that matches your profile with them, but we never collect this for privacy. We already use email for your password recovery, so using that for 2FA recovery defeats the "2nd factor" (as a single compromised email account would defeat both). SMS2FA could be a component, and there is some very slow development about that available here: phab:T150902. — xaosflux Talk 16:46, 6 September 2023 (UTC)
What are passkeys? I'm not up to date on the various methods. Edward-Woodrow :) [talk] 20:22, 6 September 2023 (UTC)
Passkey (authentication). FWIW, the big issue I see with modern authentication systems is that people don't understand them.
In the old days, people locked things up with physical keys) and more or less understood the risks involved. Most people knew that you could make a copy of a key and if you gave that to somebody else, you were giving them access to what was behind the lock. Most people, even if they didn't understand how it worked, knew that a sufficiently skilled person could open the lock without a key. And most people understood that drills, crowbars, and other familiar objects could defeat the lock a different way. In short, people had a semi-reasonable grasp of how much security various mechanisms afforded, the sorts of real-life attacks that could be used to defeat them, and how to defend against those attacks.
On the other hand, with today's crypto-based security, most people don't have a hint of a clue. They go to a website (which could be anything from movie reviews to your retirement account) and blindly follow the instructions. As a result, they are defenseless against most attacks.
In the old days, if somebody said to you, "Let me borrow your wallet for a few minutes", you'd have to be extraordinarily naive to hand it over. Yet my local bodega used to have a tap-to-pay terminal set up so you couldn't see the screen and they asked you to hand over your debit card for them to insert into the machine. And everybody just handed it over. At least until I refused to comply one day, made them show me the screen and do my own tapping. I once chewed out the checkout person at my local supermarket who, while I was pondering the total displayed and trying to figure out if they had charged me the right amount, reached over and pressed the "approve" button on the customer keypad. I think they honestly didn't understand that what they had done was effectively reach into my wallet and taken out some cash. I'm sure they were just annoyed that I was holding up the line and was trying to speed things up.
So we've got people on both sides of most transactions being totally ignorant of how these things work. Which leaves everybody at the mercy of those who do understand the technology and wish to take advantage of you. RoySmith (talk) 21:00, 6 September 2023 (UTC)
After having a read on Phab, I believed that what I wanted to say have been already said there. -Lemonaka‎ 22:24, 6 September 2023 (UTC)
Speedy close as out of scope - something like this probably is better for an RfC on m:Wikimedia Forum rather than here. I completely agree that there should be passwordless options, but this is not the right venue to discuss this. Aasim - Herrscher of Wikis ❄️ 15:38, 11 September 2023 (UTC)

Redirect all Battle for Dream Island pages to "GO TO FANDOM"

SNOWBALL CLOSE
For the original question provided by the original poster, the answer is an unequivocal "no". However, the question of linking Battle for Dream Island as an interwiki to Wikidata might be a subject for a future proposal. I am also considering that this proposal was made by a new editor who might not entirely be familiar with Wikipedia's guidelines, and how such redirects are generally not welcome here. The original proposer Another Wiki User the 3rd might want to work on this idea of where to point this non-notable topic with other more experienced editors in Wikipedia:Village pump (idea lab) before proposing again, if such proposal would not waste other editor's time. (non-admin closure) Aasim - Herrscher of Wikis ❄️ 17:30, 11 September 2023 (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.


So, I had made a page sending people to FANDOM for an article on BFDI (the web series)

Option 1: Redirect all potential pages to the FANDOM Wiki

Option 2: Use my page

Thanks, Another Wiki User the 3rd (talk) 16:23, 7 September 2023 (UTC)

We don't normally publicise non-notable topics in that way, and I don't see why this one is exceptional. Certes (talk) 16:41, 7 September 2023 (UTC)
It is only exceptional in that one of the fanboys defending the article was an administrator. I hope the editor is not now, as this is an encyclopedia for people who live in the real world, rather than the virtual. Phil Bridger (talk) 18:31, 7 September 2023 (UTC)
Timwi still is an admin, although they've only used the tools twice since the incident, both times to delete a page in their own userspace. * Pppery * it has begun... 18:45, 7 September 2023 (UTC)
WP:BFDI sort of says that, but with more words. Gråbergs Gråa Sång (talk) 18:34, 7 September 2023 (UTC)
And there is a dispute on whether to include a hatnote to that essay in mainspace on it's talk page. I'm on the "no" side, as I feel it defeats the entire point. * Pppery * it has begun... 18:45, 7 September 2023 (UTC)
As on BFDI? I'm with you, I think, hatnotes are for article-space stuff. Gråbergs Gråa Sång (talk) 19:57, 7 September 2023 (UTC)
Where exactly is in mainspace on it's talk page? We already have Talk:BfDI#Should I create an article for Battle For Dream Island? A hatnote in the actual article is usually reserved for cases like Orphan where the title clashes with a term of art used widely within Wikipedia, rather than Wikipedia's treatment of the off-wiki topic itself. Certes (talk) 22:12, 7 September 2023 (UTC)
I was referring to Wikipedia talk:Why is BFDI not allowed on Wikipedia?#Linking to this essay in Federal Commissioner for Data Protection and Freedom of Information, although I admit that my word order there does attract confusion, and There is a dispute on that essay's talk page on whether to include a hatnote to it in mainspace would have been clearer. * Pppery * it has begun... 22:15, 7 September 2023 (UTC)
How about a {{soft redirect}} to d:Q66121500? — Alexis Jazz (talk or ping me) 21:42, 7 September 2023 (UTC)
That just adds Wikipedia talk:Manual of Style/Archive 204#New RFC on linking to Wikidata to the pile of problems without solving any. * Pppery * it has begun... 21:48, 7 September 2023 (UTC)
Pppery, if we allowed this in general it would add the RFC you linked to the pile, but we could instead vote to make an exception to the outcome of that RFC on a case-by-case basis, as this kind of case where something is highly popular yet not covered by any reliable source is hopefully not that common. So in this case, we'd create a proposal to make Battle for Dream Island specifically a soft redirect. I believe this would be an improvement in several ways: anyone who looks it up to find out what it is or more information about the show is directed to the information on Wikidata, which actually includes a link to Fandom. Second, for people looking to create an article in good faith, who might assume the title blacklisting is a technical error or that it was simply a case of WP:TOOSOON but it's obviously (...) notable now, we can explain in more detail and with better accessibility (a small-font log in a box may be glanced over) why there's no article on this popular subject. — Alexis Jazz (talk or ping me) 01:24, 8 September 2023 (UTC)
I'll obviously respect any consensus the community comes to, but I would oppose that - it feels like giving people an inch and trying to stop them from taking a mile and also effectively allows the masses to make an unjustified exception to Wikipedia's standards, which is generally not done. You can probably achieve some of what you want via a protection editnotice and/or a custom error message on the title blacklist, but I'm not convinced of the need for going any further than that via a one-off exception. * Pppery * it has begun... 01:30, 8 September 2023 (UTC)
No. Fandom is not reliable. Edward-Woodrow :) [talk] 22:42, 8 September 2023 (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.

Shortening US Township names

For townships that are unnecessarily disambiguated by county and state, there is a clear consensus to mass move them to a naming scheme that only names the township and state. As this discussion did not include a list of such townships if there are reasonable disputes over whether this consensus applies to a specific article please do not edit war over it; either bring it to me for assessment or open an RM. BilledMammal (talk) 01:33, 14 September 2023 (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.


So there's quite a few US township names which I would recommend that we shorten. The present naming scheme is X township, X County, X state, but in a lot of cases where there is only one township in such state, we shouldn't need to further complicate and disambiguate beyond necessity. I would propose mass-moving these township articles to a naming scheme that only names the township and state, and only disambiguating with the county when there are multiple townships in a state.

As an example, it makes sense to have this naming scheme for Peters Township, Pennsylvania, as one exists in Washington County and one more in Franklin County. However, the name for Upper St. Clair Township shouldn't be as long as its present incarnation, Upper St. Clair Township, Allegheny County, Pennsylvania, as since there's only one Upper St. Clair in the entire state (not to mention the entire country), we don't need to disambiguate further. A relatively giant addition to giant text containing the county in the title when not needed is a major inconvenience and a waste of time; we have infoboxes and article body space which can do the same thing much more efficiently.

If examples outside of Pennsylvania are needed, more can be found. Blendon Township, Ohio only exists in Franklin County, so we don't need to add a giant Franklin County to the title for the only township of its name in Ohio. Likewise, there is only one Aitkin Township in all of Minnesota. And only one South Loup Township in Nebraska. Michigan townships already do this (see Beaver Township, Bay County, Michigan and Holmes Township, Michigan) disambiguating only when multiple townships of the same name exist like with Beaver Township in Newaygo and Bay counties. Michigan's naming scheme seems to have worked out well, so isn't it about time we expand this to the rest of the township-having United States? InvadingInvader (userpage, talk) 12:47, 11 August 2023 (UTC)

Support. This is natural disambiguation and shorter article titles are better whenever possible. casualdejekyll 16:11, 16 August 2023 (UTC)
  • Support. I also agree with ModernDayTrilobite. Rocfan275 (talk) 15:00, 21 August 2023 (UTC)
  • Support With the caveat that "X Township" in one state may be named just "X" in another state; in some states, Townships are minor administrative divisions, like a second-order county and should be named "Anywhere Township, Foo"; in other states townships are municipalities, and should be treated as such, and the name "Anywhere, Foo" is appropriate. I agree that, if only one township exists in a state, there should never be the county name used, but nomenclature varies from state to state, and we should reflect usage rather trying to force a consistency into Wikipedia that doesn't exist in the world. --Jayron32 15:51, 21 August 2023 (UTC)
  • Comment - the nature of sub-county entities varies across the United States.
In New Jersey, county government does little, if anything. NJ townships and boroughs provide local government functions.
90+% of adult North Carolinian don’t know their counties are technically divided into townships. These NC townships serve no purpose, have no authority and no administrative organization.
Alaska has boroughs in some areas but sort-of-maybe-a-borough in other places.
I don’t know how you get a uniform convention for 50 states. If you try, some good hearted, slightly OCD editor is going to go on a tear changing things in the wrong states to fit the rules. (No aspersions on slightly OCD editors- they’ve made Wikipedia great!)
—A. B. (talk • contribs • global count) 00:42, 24 August 2023 (UTC)
Just as a tiny correction to North Carolina; township names are used for land survey purposes among a few other uses; title deeds for example will list the township(s) that a plot of land is in when defining it. And a few townships are also used as the name of a local unincorporated place, but that really should be treated as two separate entities that coincidentally share a name. That being said, you're basically right, no one at all knows what township they live in in North Carolina. --Jayron32 12:44, 29 August 2023 (UTC)
  • Oppose as unworkable per my comment above. Also, we keep getting more and more rules. We should avoid adding more unless absolutely necessary. See our policy, ”Wikipedia is not a bureaucracy”
—A. B. (talk • contribs • global count) 19:43, 24 August 2023 (UTC)
I would challenge this – as mentioned above, Michigan townships do this already. InvadingInvader (userpage, talk) 17:05, 25 August 2023 (UTC)
@InvadingInvader, help me out, here. Maybe I'm misunderstanding the proposal.
Does this mean we end up with Concord, Township 2, Poplar Tent, North Carolina? Or maybe Concord, Township 3, Odell, North Carolina. Or one of several other dinky townships that Concord spreads across?
North Carolina has 1035 townships that are mostly vestigal. Our civil township article has a paragraph describing the role of NC townships but there's no citation given and I've never seen any of those uses for them. 90+% of North Carolinians probably don't even know they exist.
People in Concord just know they live in Cabarrus County, a strong local government unit that handles schools, EMS, taxing, zoning, law enforcement, etc.
Can we get a carveout for states where townships don't have substantive powers?
If a carveout is unacceptable, can you devise a good scheme for the many cities that spread across multiple townships? (As opposed to Concord, Township 2, Poplar Tent / Township 3, Odell / Township 12, Concord / etc., North Carolina)
Thanks,
--A. B. (talk • contribs • global count) 18:04, 27 August 2023 (UTC)
By the way, somebody has actually added a few township articles as denoted by blue links at List of townships in North Carolina. We don't need any of those articles.
--A. B. (talk • contribs • global count) 05:41, 28 August 2023 (UTC)
I think you're misunderstanding the proposal. The proposal is seeking to shorten article titles when possible, not make them longer. To use one of the nominator's examples: Blendon Township, Franklin County, Ohio is the only Blendon Township in the state, thus the title should just be Blendon Township, Ohio. You link to NOTBURO above; this proposal seems to be going against the overly-bureaucratic current naming convention for townships. Curbon7 (talk) 06:03, 28 August 2023 (UTC)
My mistake. You're right, I misunderstood. Thanks for setting me straight.
--A. B. (talk • contribs • global count) 16:20, 28 August 2023 (UTC)
I would agree with Curbon7 in his phrasing, and it's basically the same thing he said. Only disambiguate when necessary. For example, since there is only one Upper St. Clair Township in all of Pennsylvania, move it to Upper St. Clair Township, Pennsylvania instead of the current title at Upper St. Clair Township, Allegheny County, Pennsylvania. However, since there are multiple Adams Townships in Pennsylvania, keep the current naming scheme for them. InvadingInvader (userpage, talk) 15:37, 28 August 2023 (UTC)
InvadingInvader: If the need to disambiguate a township by adding its county was rare then I'd be less dubious about the proposal... but evidence shows it's actually very much the reverse, which is one of the reasons that in many states we include the county name for all those states' township articles.

For example, you earlier cited Blendon Township, Franklin County, Ohio, and you're right that it is the only township of that name in the state. But if we look at the rest of the townships in that county we see that all but one is repeated, sometimes a truly impressive number of times: Brown (8 times), Clinton (7 times), Franklin (21 times), Hamilton (5x), Jackson (37x), Jefferson (24x), Madison (21x), Mifflin (5x), Norwich (2x), Perry (26x), Plain (4x), Pleasant (15x), Prairie (2x), Sharon (4x), and Washington (43x), leaving just Truro as the only other unique one. All the rest have to be disambiguated with the county name no matter what.

Since this is the case for so many, adding it for all makes for a more consistent and predictable set, per the guidance at WP:CONSISTENT (which advises using similar patterns for similar articles "to the extent that this is practical"). ╠╣uw [talk] 20:04, 2 September 2023 (UTC)

If this query is correct, there are 13,890 township articles with 10,027 different town+state combinations, including 8,659 unique combinations. Certes (talk) 21:17, 2 September 2023 (UTC)
Across all minor civil divisions nationwide I'm sure that's correct, but per WP:USPLACE we're directed to make such determinations on a per-state basis — and states vary quite considerably in how they name such divisions. The number of townships with duplicated names in New Jersey, for instance, is only about 11% (28 out of 241), whereas in some others the repeated names are a sizable majority: in Ohio they're 65% (884 out of 1362); in Indiana over 70% (707 out of 1008); etc. One size doesn't sensibly fit all in this case, so I strongly recommend following the guidance in our geographic naming conventions to consider this at the per-state level, not nationwide. ╠╣uw [talk] 00:01, 3 September 2023 (UTC)
  • Support per obvious parsimony.
JoelleJay (talk) 00:18, 25 August 2023 (UTC)
  • Oppose. Per the minor civil divisions instructions at WP:USPLACE, changes to the convention for things like townships need to be approached at the state level, not unilaterally for the entire US, since minor civil division vary from state to state. I don't see any mention of this proposal at the Wikipedia:Naming conventions (geographic names), so I must assume this proposal will be raised there for input in due course, as well as at all affected state-level Wikiprojects.

    Also, for many states that have township divisions, township names are so frequently repeated that a majority would need the county name included regardless, so including it for all produces a set that's more predicable and consistent. For example, among the names of Indiana's 1008 townships, 707 names appear more than once within the state, and some are repeated literally dozens of times. (There are a staggering 47 Jackson Townships in Indiana; 46 Washingtons; 35 Unions, 28 Jeffersons, etc.)

    Further: while in some states townships share features with towns or settlements, in others they're just subdivisions of a county and are rarely if ever identified in reliable sources without reference to its parent county. In short, I think this proposal would not be helpful or advisable. ╠╣uw [talk] 15:04, 2 September 2023 (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.

mondonomo.ai should be blacklisted

mondonomo.ai is used on WP as if it was a reliable source. However, the website seems to be a mere content farm. Thus, mondonomo.ai should be blacklisted. Veverve (talk) 09:21, 12 September 2023 (UTC)

The correct place for proposals to blacklist sources is Wikipedia:Reliable sources noticeboard. As far as I can tell the source has not been discussed there previously so you'll be better to add a bit more background information than you have here. Thryduulf (talk) 10:00, 12 September 2023 (UTC)
If the goal is blacklisting, then please see Wikipedia:Spam blacklist#Requests for listing. If the goal is to list it at Wikipedia:Reliable sources/Perennial sources, then – assuming it's actually a source of "perennial" discussions, and not just one of the zillions of websites that is easily identified as undesirable – RSN will be the right place. WhatamIdoing (talk) 19:20, 14 September 2023 (UTC)
See the link search. Why not blacklist *.ai? Johnuniq (talk) 10:05, 12 September 2023 (UTC)
.ai is the TLD for Anguilla and thus there are many legitimate websites using it. Examples include gov.ai, fsc.org.ai, tennis.ai, shing.ai. Thryduulf (talk) 10:32, 12 September 2023 (UTC)

Replace nyt with reuters

i disagree with https://en.wikipedia.org/w/index.php?title=Module%3AFind_sources%2Ftemplates%2FFind_sources&diff=prev&oldid=722553515 . i propose to replace nyt with https://www.reuters.com/ .

reuters search link format is https://www.reuters.com/site-search/?query=Canton+Hong+Kong if keywords are "Canton Hong Kong". RZuo (talk) 20:35, 13 July 2023 (UTC)

Because...? Why do you disagree with that change from 2018? Why are you making this proposal? — JohnFromPinckney (talk / edits) 02:08, 14 July 2023 (UTC)
  1. there was no argument for why nyt was preferred over other news agencies to justify that edit.
  2. nyt is US-oriented. reuters is world-oriented.
  3. nyt has a paywall.
just any of AP, reuters or AFP is better than nyt. RZuo (talk) 21:50, 14 July 2023 (UTC)
Those sounds like "I don't like it", not an actual reason to change. Zaathras (talk) 22:18, 14 July 2023 (UTC)
I dunno, I think the paywall issue is a reasonable point. Schazjmd (talk) 22:22, 14 July 2023 (UTC)
I think all of them are reasonable points. --stultiwikiatext me 00:25, 12 August 2023 (UTC)
Reuters also has a paywall that kicks in after a few complimentary articles.
No reason we can't use both, though. We definitely should be suggesting both Reuters and AP. Masem (t) 22:47, 14 July 2023 (UTC)
If we were going to any more links, they should ideally be to non-paywalled articles. Reuters paywalls after a few articles, and NYT does similar. Joseph2302 (talk) 16:44, 17 July 2023 (UTC)
The Guardian begs for contributions, which apparently it sorely needs, but has been trying to stay solvent without a paywall (however non-subscribers will see a small, voluntary, "please contribute" box). It may not be quite so comprehensive as the AP, AFP or Reuters, and not everyone likes its political slant (any more than everyone likes those of The New York Times’ or The Wall Street Journal’s), but it's still (after 2 centuries) a sound source. —— Shakescene (talk) 20:50, 17 July 2023 (UTC)
  1. reuters has a registration wall.
  2. it can be easily bypassed by browsing incognito. hit the wall? close and open incognito again.
RZuo (talk) 21:12, 22 July 2023 (UTC)
Valid points. Reuters tends to write with less editorial bias than the NYT. The US orientation can be a useful aspect in regards to US specific things. UnironicEditor (talk) 06:25, 30 July 2023 (UTC)
I agree that Reuters maintains a more neutral approach, because they make money by supplying news to anyone who will buy it from them. Yet responding to other comments above, I have also observed that Reuters is slowly moving to a more aggressive paywall model to ensure that they do in fact get paid. For this reason, I give less credence to paywall arguments and more to neutrality arguments. Orange Suede Sofa (talk) 06:59, 30 July 2023 (UTC)
Replacing NYT with Reuters in the find sources default seems controversial, but adding Reuters (or AP) search to the module (specifically Module:Find sources/links) as a link code option for templates to use (which it currently isn't) seems uncontroversial and is a necessary precursor for replacement or addition of Reuters/AP to default source search options. I've put in an edit request to add both AP and Reuters to the link codes. Dylnuge (Talk • Edits) 00:27, 3 August 2023 (UTC)
I agree I feel if there can be three sources for any given citation or story, it is better to look as unbiased as possible, with non profit sources, at least one so nothing seems tainted Coopaloop1984 (talk) 02:59, 17 September 2023 (UTC)
  • This inappropriately centres a certain worldview and should be removed at once. Jack4576 (talk) 13:45, 11 August 2023 (UTC)
    Additional insight: NYT left-bias source 1, NYT left-bias source 2 non-biased alternatives --stultiwikiatext me 00:33, 12 August 2023 (UTC)
    Quoting from your own source about the NY Times:
    They are considered one of the most reliable sources for news information due to proper sourcing and well-respected journalists/editors.
    I see a lot of editors tossing out comments about NYT being left-biased which appear to fail to recognize a basic fact of the news business in the U.S., which is the separation of op-ed and editorial from the news side. As it happens, editorial and news at NYT are completely separate: if you work in editorial, you don't write news articles, and vice versa.(This article might enlighten.) Our WP:Verifiability for factual assertions should never be based on opinion or the views of the editorial board, but exclusively on reliable news reporting. That is one area where the NYT really shines, and is considered highly reliable for factual reporting by most observers, and in particular by your source. Searches such as most reliable newspapers in the world regularly turn up NYT in the top ten. The first result for that search happens to result in this Forbes article, which lists the New York Times as the #1 most reliable newspaper in the world. Reuters, AP, BBC, WSJ, The Guardian, C-Span, The Economist, and others regularly turn up on these "best of" or top ten lists as well. Mathglot (talk) 06:27, 15 August 2023 (UTC)
I realize I never actually expressed an opinion here, partially because I don't feel particularly strongly. There is extremely strong consensus that NYT is a generally reliable source (with the usual reminder that this does not mean "unbiased" or "lacks an opinion section", nor does it mean "all claims can be accepted uncritically in all circumstances" or "by using only this source, you can build a neutral and complete article"). Though there have been a few less RSN discussions, there is similarly strong consensus that Reuters is a generally reliable source (with the same disclaimers). Including NYT, Reuters, both, or neither in "Find sources" all seem like perfectly fine options.
Personally where I tend to start my source searches depends on what I'm looking for, but it's usually some form of aggregated search like Google News, newspapers.com, Archive.org book search, or Google Scholar. I also pretty much never use the template links though. Dylnuge (Talk • Edits) 00:12, 19 August 2023 (UTC)
nyt doesnt cover the world as much as the major agencies. for example:
https://www.nytimes.com/search?dropmab=false&query=Botswana&sort=newest
https://www.reuters.com/site-search/?query=Botswana
https://apnews.com/search?q=Botswana&s=1
enwp is about the world, not usa. RZuo (talk) 07:34, 22 August 2023 (UTC)
The agencies will often spin the same story with different slants so the buyers can choose which one is best for their audience ie. a right or left slant to the same story. -- GreenC 10:03, 22 August 2023 (UTC)
I agree with GreenC here. The NYT remains a generally reliable source, though its fact-checking and neutrality seem, subjectively, to have been declining lately. But it offers a distinctively US East Coast-centric view on the world. Reuters is not behind a paywall (yet), merely a registration wall, and probably offers a more neutral take on world affairs. Fiachra10003 (talk) 20:31, 22 August 2023 (UTC)
I don't understand why you agree with GreenC .. I said the agencies (Reuters etc) are not always neutral they produce multiple versions of the same story with different political slants so buyers can choose which is best for their local audience ie. The Texas Register might choose a version of the story that has a right-leaning slant, while the San Francisco Times might choose the version with a left-leaning slant. Same article, different emphasis for different readers. -- GreenC 17:04, 23 August 2023 (UTC)
Can you provide some sources for this claim?
The wire agencies started providing different leads some years back, but the difference was magazine-style vs traditional newspaper style, and it only affected the first sentence/paragraph. I have never heard of any of them offering a service for "slanting" the news. WhatamIdoing (talk) 18:15, 24 August 2023 (UTC)
Seconding request for sources regarding Reuters producing stories with varying perspectives that media partners can choose from. Are you sure what you're seeing isn't the wire customer's in-house staff "contributing" to the wire story by adding interpretations that cater to their subscriber base? I do note that Reuters offers content creation partnership, so you can contract with them to produce content that fits your bias, but that doesn't seem to include their wire stories, and it's not clear if they even host the partnered content on the reuters.com domain. Folly Mox (talk) 18:42, 24 August 2023 (UTC)
@GreenC, I would like to learn more about the claims you're making. WhatamIdoing (talk) 03:12, 1 September 2023 (UTC)

Remove nyt

look, if a so called consensus to replace nyt cannot be established after 2 months, remove it then.

there was no consensus to choose nyt over any other sources in the first place, before the edit in question was made. so, now that the edit is contested, revert it.

maybe then in future you will find a consensus to use one or more websites, or not, but as it stands, contested edits without consensus should be reverted.--RZuo (talk) 11:07, 31 August 2023 (UTC)

If we don't have a consensus to replace it (or to otherwise change it), why would we remove it? WhatamIdoing (talk) 03:10, 1 September 2023 (UTC)
@RZuo, I'm wondering if you mean that if consensus to keep NYT can't be established, we should remove? Valereee (talk) 15:43, 1 September 2023 (UTC)
point to the consensus for its addition https://en.wikipedia.org/w/index.php?title=Module%3AFind_sources%2Ftemplates%2FFind_sources&diff=prev&oldid=722553515 .
afaict, there's never such a thing.
yet there have been repeated questions and objections to using nyt. i'm not the first user to raise objection.
i offered an alternative. maybe users like or dont like reuters, it doesnt matter. the problem is using nyt and nyt alone was never endorsed. why nyt? why not one of the other List_of_newspapers_in_the_United_States#Top_10_newspapers_by_circulation, wsj, lat, wapo or the trib? (or List_of_newspapers_by_circulation#Top_newspapers_by_circulation, The Times of India?) the answer to that is obviously it was arbitrary and not discussed. RZuo (talk) 07:04, 2 September 2023 (UTC)
@Enterprisey, do you have any memory of the reasoning behind this, or whether there was discussion at the time? The edit summary doesn't provide any information on the rationale. Valereee (talk) 11:56, 2 September 2023 (UTC)
Agree to the reasoning above. --stultiwikiatext me 13:09, 2 September 2023 (UTC)
I don't know for sure, but I vaguely recall that it might've been because AfC wanted it for their submission template, because they were already linking to a NYT search. Enterprisey (talk!) 16:37, 3 September 2023 (UTC)
Without a clear consensus to change it (which I don't think we have yet) I think it should stay. If there were a newspaper source that was clearly regarded as more reliable it would be easier to get consensus but I can't imagine there's a single paper that someone won't object to. And as Mathglot says above, although the NYT's editorial stance is clearly left-leaning, their news reporting has as high a reputation as any in the country. They are a very reliable source for news and I see no reason to replace them here. Mike Christie (talk - contribs - library) 13:19, 2 September 2023 (UTC)
I do think that the NYT has become a bit more corporatized towards consumers, but I am not sure whether it's a good idea to go with Reuters instead. I would recommend maybe both NPR and BBC, as well as for non-Qatarian topics, Al Jazeera. InvadingInvader (userpage, talk) 17:01, 4 September 2023 (UTC)
A choice would be ideal, I see no reason to prefer NYT over AP, say.Selfstudier (talk) 17:33, 4 September 2023 (UTC)
I do think we should change NYT to something else. It's a fine source, but it's paywalled. AP and BBC might be my top two choices, but I would also support AFP, Reuters, Al Jazeera, or CBC. Folly Mox (talk) 16:43, 8 September 2023 (UTC)
Tracked in Phabricator
Task T346920

Please fix the problem described at WP:VPT#Strange linkages, piping through miscapitalized redirects. If clicking the link button would more prominently show a link through the selected text, editors would be less likely to select an inferior piping through a poor redirect. Dicklyon (talk) 03:31, 20 September 2023 (UTC)

That is not something that can be fixed by anyone on this page, it needs a software change. Per the instructions at Wikipedia:Visual Editor problems should be reported on Phabricator. Thryduulf (talk) 08:28, 20 September 2023 (UTC)

Intertranswiki reference bot

I was wondering if it would be possible when transwikiing articles from other Wikipedias that a bot could be programmed to convert the sources which use citation templates into English. If the sources could be copied directly from other wikis in their language, and a bot picks up on the foreign reference text and is able to reformat it in English this would save an enormous amount of time in drawing up sources. Obviously it is the duty of all editors translating content to check the sources and verify it, but this is one of the issues which puts off editors such as myself and others who transwiki content but don't do as much work as they want to because it is so time consuming having to draw up the sources from scratch in English. If we could have something to swiftly facilitate the transwikiing of good, sourced content this would be a great help. I think something which is able to put Spanish, German, French, Italian sources, and perhaps Portuguese and Dutch into English would be a good start. The bot would need to be coded to recognize the basic parameters of the citation templates on other wikis and what parameter corresponds to what in English. Obviously it wouldn't work for sources which don't use citation templates though.♦ Dr. Blofeld 12:27, 22 September 2023 (UTC)

AnomieBOT will substitute cites in other languages, see this edit for instance. You still need to check the output, as with any bot, as not all fields are used the same way across different language wikis but it does most of the work. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 18:17, 22 September 2023 (UTC)
Note AnomieBOT doesn't do anything very special there, people have created {{Lien web}} that substs to a proper invocation of {{cite web}} and flagged it for bot auto-substing. Only a few languages seem to have these templates at the moment, but I'd think the people over at WT:CS1 would help in creating more if there's a need. Anomie⚔ 20:50, 22 September 2023 (UTC)

Proposal to change the venue for new community-authorized general sanctions

There is a clear consensus to implement the proposal. The reasoning with the most support was that AN's main focus is on administrators' issues, not community issues such as these, and that threads at AN are archived too quickly to properly address the below program. starship.paint (RUN) 03:11, 23 September 2023 (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.

Should the venue for seeking consensus to establish a new general sanctions program, and amending or revoking existing general sanctions programs, be changed to the village pump for proposals (with a courtesy notification at the administators' noticeboard)? 21:46, 5 September 2023 (UTC)

Specifically, should the text at Wikipedia:General sanctions § Community sanctions be amended as follows?

The community may also impose general sanctions on all editors working in a particular area, usually after a discussion by consensus at the administrators' noticeboard ("AN") village pump for proposals (VPR), following a notice at the administrators' noticeboard (AN). While community-authorised discretionary sanctions are not bound by Arbitration Committee procedures and guidelines, they usually follow the Arbitration Committee standard discretionary sanctions model. Deviation or additions to these standards typically requires community consensus, unless purely clerical in nature. Requests for amendments, clarification, or revocation (if sanctions are no longer required) should also be discussed at the administrators' noticeboard VPR, following a notice at AN.

Background

The Wikipedia community may impose "general sanctions" upon an entire topic area. Current examples of active community-imposed general sanctions include:

The place that the community currently imposes these "general sanctions" schemes is at WP:AN, as provided by Wikipedia:General sanctions § Community sanctions:

The community may also impose general sanctions on all editors working in a particular area, usually after a discussion at the administrators' noticeboard ("AN"). [...] Requests for amendments, clarification, or revocation (if sanctions are no longer required) should also be discussed at the administrators' noticeboard.

This proposal, if enacted by the community, would change the appropriate venue to the village pump for proposals (WP:VPR) and require a courtesy notification of such discussions at WP:AN.

Discussion (GS authorization venue)

  • Support. AN is ill-suited for discussions that can set significant rules – sometimes extended-confirmed (500/30) editing restrictions – on entire broadly-defined topic areas that can last for years and years. AN threads are archived in a matter of days, and sometimes GS authorization threads at AN are prematurely archived and need to be unarchived.
    AN also doesn't have the right visibility for GS authorizations, which can be buried under the many threads that concern individual issues (not policy- or topic- level discussions) that AN sees every day. By contrast, VPR is better suited for discussions involving questions of broad application.
    I solicited feedback for this RfC at my talk page (permalink), and this proposal reflects changes in wording as a result of input there. Best, KevinL (aka L235 · t · c) 21:48, 5 September 2023 (UTC)
  • Support - I'll admit with some chagrin I misunderstood the original intent of the proposal as it was then written : ) - But I support this as written above if only because these are community-applied sanctions to a topic-area, not admin-applied sanctions to a topic-area. So having the discussion at the VP seems more appropriate than AN. - jc37 21:59, 5 September 2023 (UTC)
  • Support. AN is ill-suited for this purpose both because of its "admin-central" nature and its rapid archival process.  — SMcCandlish ☏ ¢ 😼  23:13, 5 September 2023 (UTC)
  • Support, I think this format makes more sense than the current model. Seraphimblade Talk to me 23:53, 5 September 2023 (UTC)
  • Support. (Summoned by bot) I find each of the OP's points rationale and compelling. That said, it may be wise to further emphasize the importance of the AN notice. It also would not necessarily hurt to make it clear that the business of applying / discussing purported violations of the sanctions themselves (whether its disruption of a community-validated CTOP area, or issues resulting from some other community-based GS restriction) remains an ANX affair. SnowRise let's rap 03:39, 6 September 2023 (UTC)
  • Support per jc37. These are community sanctions, not admin sanctions, so keep them in a community space. Edward-Woodrow :) [talk] 12:28, 6 September 2023 (UTC)
  • Support per all the above. Mike Christie (talk - contribs - library) 12:41, 6 September 2023 (UTC)
  • Broadly support - not sure if VPR is the right specific page (it deals with a lot of other stuff)… but I do agree with shifting this to Village pump space. Perhaps a new VP page, specifically dedicated to dealing with these discussions. Blueboar (talk) 12:54, 6 September 2023 (UTC)
  • Kinda support I'm not sure that VPR is the right venue, but it's less wrong than WP:AN, which is for administrator issues. Community sanctions are not an administrator issue (though, of course, administrators are part of the community too, and may participate in such discussions). --Jayron32 17:38, 6 September 2023 (UTC)
  • Weak oppose given that the status quo means it gets more eyeballs on it. I also think if we're changing this we should require CENT notification. Barkeep49 (talk) 22:58, 6 September 2023 (UTC)
    I agree that most of the time a CENT listing for GS discussions would be worthwhile, but anyone can make that notice happen. As a matter of bureaucratization, I'd rather not codify a mandatory CENT listing, especially considering that comparatively minor amendments and clarifications might not warrant a CENT listing. Best, KevinL (aka L235 · t · c) 19:25, 8 September 2023 (UTC)
  • Yes - I think ANB is great for discussing user conduct, but for discussing changes to policy such as authorization of community designated contentious topics, VPPR seems like a better venue. Aasim - Herrscher of Wikis ❄️ 14:02, 7 September 2023 (UTC)
  • Support per Jayron32 (summoned by bot), but agree with Barkeep49 on CENT notification for visibility. No objection to additional notifications at other places that might be relevant. I question the assertion that the status quo gets more eyeballs. Do we have data to support this? · · · Peter Southwood (talk): 06:20, 8 September 2023 (UTC)
    I think we have anecdata that could go both ways. As I linked above, a recent GS discussion at AN saw very little engagement at all and was archived before action; even after unarchiving, there were only two additional participants until the initiator of the discussion mass-pinged over two dozen other editors to the discussion. On the other hand, sometimes AN does see a lot of participation. I initiated the WP:GS/COVID discussion at AN (permalink), which received 15 supports before being closed less than three hours after opening (too soon, in my opinion, but that's another story). Best, KevinL (aka L235 · t · c) 19:21, 8 September 2023 (UTC)
  • Neutral. I mainly want to point out that AN is treated in many cases as a place where the whole community provides its opinion on matters that are related to administration. For example, it's a venue for challenging discussion closures and appeals of contentious topic blocks. There are many support rationales above that do not rely on the understanding of AN as being just for administrator issues, so I'm ultimately undecided. I do think there's a need to show that this move is worth the loss of page-watchers. Firefangledfeathers (talk / contribs) 19:35, 8 September 2023 (UTC)
  • Strong support per L235's concerns, which I strongly agree with, and indeed I think I've suggested this change in venue in the past. ProcrastinatingReader (talk) 12:48, 18 September 2023 (UTC)
  • Support. The venue for community input has usually been the village pump. This would help further centralize discussions which affect the wider Wikipedia project. AN is usually for incidents or stuff concerning mostly towards the admins. InvadingInvader (userpage, talk) 18:02, 18 September 2023 (UTC)
  • Support because AN is archived quickly and discussions there are easily drowned out by ambient noise from various dramahs. I also think a CENT listing is a good idea since the impacts of such sanctions are often far-reaching. — SamX [talk · contribs] 19:44, 18 September 2023 (UTC)
  • Support. I'm in favor of anything that helps to alleviate the present situation where ANI – a rather hectic, nasty place to begin with – is considered the "everything zone" and made even more inscrutable. Important decisions really shouldn't be happening in a place where the archive age is a couple days to a week. jp×g 00:51, 20 September 2023 (UTC)

Close

This feels like a nearly perfect example of If the matter under discussion is not contentious and the consensus is obvious to the participants, then formal closure is neither necessary nor advisable. from WP:RFCEND and suggest we close and implement as such. Barkeep49 (talk) 19:57, 22 September 2023 (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.
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(proposals)/Archive_203&oldid=1229203023"