Wikipedia:Village pump (proposals)

From Wikipedia, the free encyclopedia
Jump to navigation Jump to search
"WP:PROPOSE" redirects here. For propose for deletion page, see Wikipedia:Proposed deletion and Wikipedia:Deletion requests.
 Policy Technical Proposals Idea lab WMF Miscellaneous 
Shortcuts

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

Discussions are automatically archived after remaining inactive for nine days.


Proposal to change portal links on the Main Page[edit]

Should the proposal to change portal links on the Main Page described below be adopted? {{u|Sdkb}} talk and JBchrch talk 01:19, 15 March 2022 (UTC)[reply]

Notified: WP:CENT, WT:Main Page, WT:Usability, WT:PORT. {{u|Sdkb}} talk 01:19, 15 March 2022 (UTC)[reply]

Background[edit]

Current location of the portal links on the Main Page

Wikipedia's portals have long suffered from low readership and poor maintenance. There have been numerous efforts to curtail them in recent years, some of which garnered substantial support, and the community has chosen to delete many hundreds of unmaintained or unread portals. In contrast to this tenuous state, portals enjoy extremely prominent positioning at the top of the Main Page, where eight of them and the portal contents page is linked in the very top banner, above even the TFA and ITN. The specific portals receive only 2000–5000 pageviews per day, less than well-performing DYK hooks which appear much farther down and often more briefly. The portals contents page does marginally better, with a daily average of 11,800 views.

Separately, the Desktop Improvements Team has introduced a new button for switching between language editions, and has been discussing on Phabricator how it might appear on Main Pages.

Last October, JBchrch made a proposal to remove the portal links from the Main Page, per the web usability principle that underutilized links should be cleared out to reduce clutter. It received 30 !votes in favor and 17 opposed, but was closed as no consensus because it did not offer clear-cut choices and thus did not manage to elicit clear-cut responses. After discussion on the closer's talk page and a challenge at the administrators' noticeboard, the close was left standing. Last month, the closer launched a follow-up discussion asking broadly whether the display should be kept or changed, but it was withdrawn after procedural objections in part about its lack of specificity. {{u|Sdkb}} talk 01:19, 15 March 2022 (UTC)[reply]

Proposal[edit]

We propose the following related changes:

  1. Remove the portal links from the top banner and center-justify the Welcome to Wikipedia message.
  2. Move the link to the portals contents page to the {{Other areas of Wikipedia}} section lower on the Main Page, adding Content portals – A unique way to navigate the encyclopedia.
  3. Add the language switcher button to the newly freed space in the upper right corner.
  • Mockups

  • Top banner proposal: portals links removed and language switcher added

  • Proposed addition of portals contents link to {{Other areas of Wikipedia}}

Best, {{u|Sdkb}} talk and JBchrch talk 01:19, 15 March 2022 (UTC)[reply]

Survey (Portal links)[edit]

  • Support as co-proposer. Our Main Page should not be featuring so prominently links that are barely ever used, that don't represent our best work, and that clutter its design. The other areas section is a suitable new home for the portal contents page, offering a middle ground that allows us to avoid complete removal. The language switcher is a helpful feature for the Main Page that will fit nicely in the newly freed space. {{u|Sdkb}} talk 01:19, 15 March 2022 (UTC)[reply]
  • Support as co-proposer. The proposed changes are an improvement on the current design of the main page. They modernize the interface by cutting down on bluelinks and helping the reader focus on more representative parts of the project, such as TFA. The language switcher is not only a functional tool, but also serves as a symbol for the global nature of the Wikipedia project. Access to the portals is relocated in a manner that's proportional to their importance and readership. JBchrch talk 01:53, 15 March 2022 (UTC)[reply]
Support looks good and cleaner. We could increase the size of "Welcome area" to lessen white area.Moxy-Maple Leaf (Pantone).svg 02:00, 15 March 2022 (UTC)[reply]
  • Support, the "Welcome" message is centered which looks much nicer, and having a language switcher front and center when a user goes to the main page of Wikipedia can be very helpful. I only have one critique and that is how the language switcher looks, however it's very minor and not that jarring compared to how much nicer the main page looks in the mockups. ― Blaze WolfTalkBlaze Wolf#6545 02:12, 15 March 2022 (UTC)[reply]
  • Support It looks nicer, more professional, and more modern. Plus, Portals should not be the focus of readers. We have a lot better work to show off. CaptainEek Edits Ho Cap'n!⚓ 02:33, 15 March 2022 (UTC)[reply]
  • Support, I like the new proposal, and portals, while an interesting idea for their time, just never really have quite worked out. Seraphimblade Talk to me 03:27, 15 March 2022 (UTC)[reply]
  • Support, whatever the importance and relevance of portals, it is certainly not enough to warrant the prominence of their current inclusion. Having our welcome and main title pushed so far to the left (so close to the icon!) is unproductive and generally bad design. This is a definite improvement. Aza24 (talk) 03:47, 15 March 2022 (UTC)[reply]
    @Aza24: It doesn't push it over at all. Try viewing at (say) 1280px wide (or zoom out a few steps) - there's a big gap between the three "Welcome to Wikipedia," lines and the three rows of portal links. --Redrose64 🌹 (talk) 09:26, 15 March 2022 (UTC)[reply]
    @Redrose64: I was referring to the literal Wikipedia logo (the globe) in the corner being so close to the "welcome to wikipedia", making both feel redundant. Since I am on a standard laptop, viewing the page as many people do, if I have to adjust my screen to see a more desirable layout, that is an issue. Aza24 (talk) 23:16, 15 March 2022 (UTC)[reply]
    I don't mean that you should zoom out permanently - just long enough that you can see that no pushing is going on. --Redrose64 🌹 (talk) 21:15, 16 March 2022 (UTC)[reply]
    ??? By pushing, I mean the existence of the portals prevents the "Welcome to Wikipedia" from being in the middle, and thus pushes it to the left by necessity. Aza24 (talk) 02:01, 6 April 2022 (UTC)[reply]
    With MonoBook skin, on narrower screens (less than 892px wide), it automatically rearranges so that the portal list is rearranged horizontally (like a WP:HLIST) and is entirely below the three lines of which "Welcome to Wikipedia" is the first. This doesn't happen in Vector. --Redrose64 🌹 (talk) 18:08, 6 April 2022 (UTC)[reply]
  • Support, great idea and much better looking. A. C. Santacruz ⁂ Please ping me! 06:58, 15 March 2022 (UTC)[reply]
    Actually, maybe it would be best to change the wording on the other areas as "Navigate the encyclopedia by topic". Still support whatever phrasing ends up gaining consensus. A. C. Santacruz ⁂ Please ping me! 10:23, 15 March 2022 (UTC)[reply]
  • Support, looks much better. Cavalryman (talk) 09:49, 15 March 2022 (UTC).[reply]
  • Strong support: this is mostly a formality after the previous discussion, and my comment in that discussion still stands. I also agree with much of what others have written. — Bilorv (talk) 10:26, 15 March 2022 (UTC)[reply]
  • Support: I can maybe add something here insofar that I would like to say that as a fairly long-time reader / passing visitor, I don't recall a single instance of my having clicked any of these portal links before today. This seems like a clear improvement and may even result in these pages functionally becoming more visible to people looking to learn some more about this place, as this proposal would group them up with some of the more dynamic starting points for doing that. Dr. Duh 🩺 (talk) 10:39, 15 March 2022 (UTC)[reply]
  • Support portals aren't used that much, and don't need to feature so prominently on the main page. Joseph2302 (talk) 10:42, 15 March 2022 (UTC)[reply]
  • Procedural oppose. Per my extended comments below, this RFC is extremely non-neutral and so invalid. Thryduulf (talk) 12:43, 15 March 2022 (UTC)[reply]
    I also oppose on the merits. This proposal would significant inconvenience thousands (at least) of visitors without bringing any benefits to those people who do not use the links, nor does the vague proposal to replace it with nothing or a language switcher come remotely close to providing a similar benefit to a similar number of people. Thryduulf (talk) 17:27, 17 March 2022 (UTC)[reply]
  • Procedural oppose and speedy close per Thryduulf. This proposal is rehashing a proposal already made last autumn, and which had no consensus because it didn't propose a clear alternative. We asked you to explain how the space freed up by the portal removal would be put to better use, and this has not been answered. Please come up with a concrete proposal, and we can consider it.  — Amakuru (talk) 12:47, 15 March 2022 (UTC)[reply]
    Just to add to this, and what I think would make the difference, would be to move the line about "the free enyclopedia that anyone can edit" and the article count over to the right-hand side, while leaving "Welcome to Wikipedia" on its own on the left, and then reduce the overall vertical space of that banner so that the featured sections of the main page are more prominent on first load. I'd support removal of portals if a benefit like that could be demonstrated, but not otherwise. Adding the language dropdown and moving the welcome banner to the centre just makes the issue worse, IMHO. Why are links to foreign-language sites which are external for us more useful to a reader than portals, which are gateways into our own content? Doesn't make sense.  — Amakuru (talk) 12:53, 15 March 2022 (UTC)[reply]
    You are of course free to express a view on the proposal, but I would ask you to please not convert it into a procedural argument. This proposal is materially different from the two previous discussions and is not a rehash. Your advice that efforts should be concentrated on the creation of a new, consensual [1][2] and specific [3] proposal was not overlooked, I can assure you of that. The design approach adopted here may not be exactly the one you suggested (there were many), but that does not invalidate the proposal from a procedural standpoint. JBchrch talk 14:56, 15 March 2022 (UTC)[reply]
  • Weak support. Those portal links get a surprisingly high amount of traffic for static links. Perhaps not enough to justify being right at the top of the page, but enough to be on the page somewhere. Nevertheless this proposal does improve the design and I expect the language button would get more use than the current portals list does. Three caveats:
    1. If we put a language button in such a prominent location, we should remove the 'Wikipedia languages' section at the bottom of the page, to avoid duplication.
    2. The 'unique way' wording is poor and uninformative. I would prefer something like 'browse by topic' or 'content organised by topic' (though the latter has ENGVAR issues).
    3. Implementation clearly has to wait until the language button has been thoroughly tested and is ready for millions of users. The page on Meta still refers to May 2021 as if it's in the future, so is presumably very out of date.
Modest Genius talk 13:12, 15 March 2022 (UTC)[reply]
  • Support Much better than outright removing them. NW1223 <Howl at me•My hunts> 15:22, 15 March 2022 (UTC)[reply]
  • Support. Ruslik_Zero 20:27, 15 March 2022 (UTC)[reply]
  • Support as an incremental improvement over the status quo, per nom and other support voters above, and per my comments and others' in the last RFC as to what's wrong with the status quo (low clicks, prime screen real estate, etc.). I also support Amakuru's suggestion to, instead of having the language toolbar, move the logo to the left and the tagline to the right, and reduce the vertical size of the entire grey box at the top. That would be another incremental improvement. I see no problem with the neutrality of the RFC statement, the "proposal" section, or the "background" section (and the last one doesn't need to be neutral anyway, as it's just an extension of the proposer's proposal). Levivich 20:32, 15 March 2022 (UTC)[reply]
  • Support anything to get the portal links off the top of the page, even though I agree with the Modest Genius about the misuse of the word unique in the proposal. I don't care what happens with the language switcher. I also agree with Levivich in saying that this RFC isn't unreasonably, deceptively, or confusingly non-neutral. Perfection is not required in an RFC question. WhatamIdoing (talk) 03:50, 16 March 2022 (UTC)[reply]
  • Strong support - a solid step in the right direction. Cleaner, clearer, more useful. Good point from Modest Genius regarding making sure the language button is 100% ready before this is implemented. Retswerb (talk) 05:07, 16 March 2022 (UTC)[reply]
  • OOjs UI icon add-constructive.svg Support ― Qwerfjkltalk 07:05, 16 March 2022 (UTC)[reply]
  • Good idea but procedural oppose Biased RFC, and respecting the process matters. Suggest a do-over because this is a good well founded idea. North8000 (talk) 13:11, 16 March 2022 (UTC)[reply]
  • Support Given most of the previous blockers to actually doing anything have been satisfied. I fully expect more goalpost moving however - its getting to the point of being actively disruptive. Only in death does duty end (talk) 13:29, 16 March 2022 (UTC)[reply]
  • Support in any form, though I concur with adjusting the description to be more informative and to match the rest of the box, for example Portals –Topic-by-topic overviews of Wikipedia's content. Ninepointturn (talk) 15:11, 16 March 2022 (UTC)[reply]
  • Support in theory though I think the execution is a little off. I'd prefer the "Welcome to Wikipedia" bit be larger to fill some of the white space. The language menu seems out of place too. Calidum 21:55, 16 March 2022 (UTC)[reply]
  • Support. Basically, though not the fine details. The portal links space is quite unjustified, and improvements to the Main page should proceed without a requirement for a Village Pump RfC written-in-stone detail for every increment. Yes, move the Portal links as proposed. However, do not lock in decisions on a "language switcher button" or the "unique way" wording that needs copy-editing. In 5 seconds I suggest "Contents portals for navigation", but after typic it am leaning to "Contents portals". If portals do have value, why would the link have to explain them? --SmokeyJoe (talk) 04:38, 17 March 2022 (UTC)[reply]
  • Support - can be twiddled in the details, but moving portals out of the prime real estate makes sense all round. I like the the language selector up top, but that's definitely secondary to getting the under-maintained portals out of the spotlight. --Elmidae (talk · contribs) 14:03, 17 March 2022 (UTC)[reply]
  • Support - there's value in whitespace -- not every pixel has to be filled. That said, I'm not a huge fan of the "unique way" wording -- a content directory by category is hardly unique and has been a web staple for 25 years (see DMOZ or Yahoo! Directory). --Ahecht (TALK
    PAGE    ) 15:14, 17 March 2022 (UTC)[reply]
  • Support Frankly I would like to see Portals go the way of the dodo and the Book: namespace, but this is a step in what I believe is the right direction casualdejekyll 01:16, 18 March 2022 (UTC)[reply]
  • Support with the caveat, mentioned by others, that the wording on the new Content portals blurb could be improved. Ganesha811 (talk) 20:05, 19 March 2022 (UTC)[reply]
  • Support moving Portal links from top of Main Page. The new grey banner with language switcher looks more modern. ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 07:56, 20 March 2022 (UTC)[reply]
  • Support Long overdue. --Jayron32 13:30, 21 March 2022 (UTC)[reply]
  • Support. ---CX Zoom(he/him) (let's talk|contribs) 09:40, 23 March 2022 (UTC)[reply]
  • Support If it's moved somewhere, then sure. --99.227.9.86 (talk) 17:00, 24 March 2022 (UTC)[reply]
  • Support per previous discussions. I'd rather they be removed entirely but this is a step in the right direction. SnowFire (talk) 03:40, 26 March 2022 (UTC)[reply]
  • Support per previous. No objection to iteration on the wording in the "other things you can do" part of the main page. The language switcher may or may not come (hopefully it does). I am happy to implement on the main page if/when this is closed in support of the change. --Izno (talk) 17:21, 27 March 2022 (UTC)[reply]
  • Support looks better, cleaner, and the language switcher would help users access other languages easily. Itsquietuptown ✉️📜 02:05, 29 March 2022 (UTC)[reply]
    No, the language switcher makes other languages harder to access: they'll be two or three clicks away rather than one. I understand the desire to prevent readers from discovering portals and congratulate the supporters on their tenacity in finally making them invisible, but replacing them by the language switcher would just make another useful feature less accessible too. Certes (talk) 11:50, 29 March 2022 (UTC)[reply]
    The language switcher is coming whether we want it or not, though whether it takes this form on the main page is an open question. See phab:T293470. Izno (talk) 19:37, 29 March 2022 (UTC)[reply]
  • Comment - After the end of this RfC, I suggest individual discussion about the language switcher button. I didn't see clear benefits for readers in replacing links to portals per links to other Wikis. If the initial goal was a clean layout, this change doesn't make much sense.Guilherme Burn (talk) 19:41, 29 March 2022 (UTC)[reply]
    Seconded. Part of the case for removing the portal links is that the space is needed for something else, and the language switcher is a convenient "something else" to propose, but we should only adopt it if it's beneficial, not just to fill space. Certes (talk) 21:59, 29 March 2022 (UTC)[reply]
  • Support: About the same view as SmokeyJoe and others. The portal links should be removed from such a prominent place, the language switcher looks kind of awkward, and we really don't need to be so extreme about proposal wording or process in order to make changes. Sdkb: when will this discussion be closed? --MZMcBride (talk) 05:32, 30 March 2022 (UTC)[reply]
    The standard RfC length is 30 days. I could see an argument for closing when it's snowing this heavily, but given the impact, I could also see an argument for letting it run its course just to be sure there's no doubt. Whatever the uninvolved closer prefers is fine with me. {{u|Sdkb}} talk 07:52, 30 March 2022 (UTC)[reply]
  • Support: We can better use the space at the top of the page than linking to portals. Allowing readers to change to a different language edition without having to scroll down is one possibility.-gadfium 07:36, 30 March 2022 (UTC)[reply]
  • Support -- It looks to be a well founded proposal to me. -- Dolotta (talk) 22:39, 31 March 2022 (UTC)[reply]
  • Weak Oppose I disagree with the notion of removing the list of portals entirely from the main page. I agree the language changer should be added, but the links to the separate portals should be retained lower in the page. — Mcguy15 (talk, contribs) 01:48, 6 April 2022 (UTC)[reply]
    To add, DYK is dynamic and uses sentences to specifically entice readers to click on the articles. Making the comparison to DYK pageviews is not equivalent. They serve different purposes, and the portal page views are certainly substantial and shouldn't be tossed aside. — Mcguy15 (talk, contribs) 01:51, 6 April 2022 (UTC)[reply]
  • Oppose completely removing portals from the main page, a conclusion I come to rather to my surprise. I have barely used portals myself and never edited any of them and came into this debate thinking I was going to say support: portals have stagnated compared to other areas of Wikipedia and the required quality of portal content is far below DYKs and especially ITN and FA items. But examining them I think here we run into the question of what people want to use Wikipedia for: I think it's a legitimate use case that someone, especially younger editors and people without a very extensive education, comes onto Wikipedia without really knowing what they want to look for but knowing they want to know more about (say) history and explore Wikipedia's articles on it. When I want to look for something I normally know what article I'm looking for and if I don't I keyword search. I imagine that's true of a lot of older editors. But I think there will be users for whom this isn't the case, who haven't had a full education, who want to browse the diversity of articles Wikipedia has on a topic without really knowing what they want to look at. Blythwood (talk) 04:05, 6 April 2022 (UTC)[reply]

Discussion (Portal links)[edit]

This RFC has one of the least neutral background statements I've read in a long time with lots of value judgements and disputed statements such as:

  • Wikipedia's portals have long suffered from low readership - this has been disputed in every discussion about portals on the main page, with the figures used by those claiming this actually demonstrating the opposite.
  • There have been numerous efforts to curtail them in recent years, some of which garnered substantial support and all of which also garnered substantially opposition and none of which achieved consensus to curtail them.
  • the community has chosen to delete many hundreds of unmaintained or unread portals. True but completely irrelevant to the portals on the main page.
  • In contrast to this tenuous state what tenuous state?
  • portals enjoy extremely prominent positioning at the top of the Main Page, where eight of them and the portal contents page is linked in the very top banner, above even the TFA and ITN. There is no neutral explanation of why this is seen a problem?
  • The specific portals receive only 2000–5000 pageviews per day, less than well-performing DYK hooks which appear much farther down and often more briefly. The portals contents page does marginally better, with a daily average of 11,800 views Once again, there is no neutral explanation of why this is a problem.
  • Separately, the Desktop Improvements Team has introduced a new button for switching between language editions, and has been discussing on Phabricator how it might appear on Main Pages. So?
  • Last October, JBchrch made a proposal to remove the portal links from the Main Page, per the web usability principle that underutilized links should be cleared out to reduce clutter. It received 30 !votes in favor and 17 opposed, but was closed as no consensus "because it did not offer clear-cut choices and thus did not manage to elicit clear-cut responses." And also because there was no consensus that there was a problem that required solving.

Given all of this, I'm not convinced that this RFC can be seen as valid. Thryduulf (talk) 12:42, 15 March 2022 (UTC)[reply]

I'm not going to try and dismiss your comment, however you have said that it's not neutral, but haven't attempted to show how it could be made neutral. ― Blaze WolfTalkBlaze Wolf#6545 13:52, 15 March 2022 (UTC)[reply]
I'm not the one making the proposal, so it's not my job, but it would need to be completely rewritten without the emotive language, without the irrelevancies and based completely on undisputed facts, with a clear statement of what problem has been identified, why that is a problem (again based on facts and acknowledging that everything subjective is disputed), what is being proposed to fix this problem and how this fix will be an improvement. It is not possible to make this neutral with small tweaks. Thryduulf (talk) 14:58, 15 March 2022 (UTC)[reply]
Alright then. I was merely saying that because I feel that showing exampled of how it could be made neutral might help with making it more neutral in the future if this is indeed closed due to not being neutral. ― Blaze WolfTalkBlaze Wolf#6545 15:00, 15 March 2022 (UTC)[reply]
  • The proposal itself is neutral… the “background” section is not. Would it help to move that into the survey? Blueboar (talk) 15:56, 15 March 2022 (UTC)[reply]
    Not really to be honest as it's already irrevocably invalidated this RFC and even if that weren't the case it would be inappopriately long and out of place in the survey section. It would be distinctly odd at best in the discussion section given that it's written to be a background to the RFC not a response to it. Thryduulf (talk) 18:19, 15 March 2022 (UTC)[reply]
    meh… It represents the nominator’s opinion of what led up to this RFC, and so is a factor in explaining his/her opinion as to the outcome. If you think it is flawed, you can always write an “alternative-background” expressing your take on the situation. In any case, I do think that the basic question was neutral. Blueboar (talk) 19:02, 15 March 2022 (UTC)[reply]
    There is no requirement that any remarks posted by the OP be neutral beyond the initial question.
    Also, I think it's important not to fetishize neutrality for proposals. If you're proposing a major change, you should be in favor of it. You should not waste our time with a proposal that you oppose or that you don't care about one way or the other. WhatamIdoing (talk) 03:45, 16 March 2022 (UTC)[reply]
    They've given their remarks highly prominent positioning above the actual proposal. Normally when starting an RfC, people put their arguments in the survey section. Chess (talk) (please use {{reply to|Chess}} on reply) 14:19, 20 March 2022 (UTC)[reply]
    If they put exactly the same words under ===Survey=== instead of under ===Background===, their words would still have "highly prominent positioning". The RFC question (=the thing that needs to be neutral) is "Should the proposal to change portal links on the Main Page described below be adopted?", and that's above both the ===Background=== and ===Proposal=== subsections. WhatamIdoing (talk) 20:14, 21 March 2022 (UTC)[reply]
I have to agree that this is a manifesto rather than an RfC. To pick just one point, I don't see how only and 2000–5000 pageviews per day belong in the same sentence. That's about a million visits annually for each portal. Do we really want to frustrate that many readers? (The proposal's title suggests that adding a language button isn't the main goal.) Certes (talk) 23:32, 15 March 2022 (UTC)[reply]
The main page gets 5.5 million daily views (that's over two billion a year). I don't think our readers will be frustrated if we move links that are clicked on less than 0.05% of the time (1 million out of 2 billion). Levivich 14:42, 17 March 2022 (UTC)[reply]
The issue is that we would be inconveniencing the readers who use the links without providing any benefit for those that don't. Thryduulf (talk) 17:24, 17 March 2022 (UTC)[reply]
Of course it would provide a benefit to those that don't (declutter, more attractive interface, etc.), otherwise why would so many of your colleagues support it? Levivich 17:45, 17 March 2022 (UTC)[reply]
If something is clicked by 0.05% of visitors, there is a not-unreasonable chance that half that traffic is bottraffic which we are unable to detect as bot traffic... We know that ppl use proper user agents for their bots and we thus have undetected bots. And if I wrote a bot, I too would start by going through all the links on the main page, so anything linked from the main page has a high chance of getting such automated traffic. The point being that it is very hard to estimate if such traffic is significant, without looking at several other elements listed. —TheDJ (talk • contribs) 14:46, 29 March 2022 (UTC)[reply]
Main Page from mobile on 20 March 2022.jpeg
  • @Sdkb and JBchrch: do you have a screenshot of what the new design will look like in Mobile wikipedia? Would be interesting to see where and how much space the language switcher would take. The current one has portal links after the welcome block and takes up 10-15% of screen height. ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 08:37, 20 March 2022 (UTC)[reply]
@ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ, for the portal link farther down, you can go here on mobile. I don't have a mobile screenshot of the top, but I'm sure someone else could make it fairly easily. {{u|Sdkb}} talk 18:08, 20 March 2022 (UTC)[reply]
  • Question: I haven't seen this "language switcher" in action. Do I understand that this dropdown will have 300+ entries? Can we see a copy in motion? That sounds difficult to use... BusterD (talk) 18:12, 6 April 2022 (UTC)[reply]
    @BusterD, go here, and you'll be able to test out the switcher (you can also change your skin to Vector 2022 here; it includes a bunch of other modifications which are not part of this proposal). {{u|Sdkb}} talk 18:20, 6 April 2022 (UTC)[reply]
    You can see the language switcher top right on any article of Portuguese Wikipedia, though it has been moved to bottom right on the main page. It was also on other Wikipedias such as French but seems to have been removed. Certes (talk) 18:21, 6 April 2022 (UTC)[reply]
    Thanks, folks. Any special reason fr.wikipedia dropped the switcher? I don't like it for lots of reasons but partly because it's unlike any other visual element on the page. 300+ entries on dropdown seems ridiculous and unweildly. I still think this is a solution is search of a problem, but that position has been discounted by those who just don't like portals... BusterD (talk) 18:30, 6 April 2022 (UTC)[reply]
    One version of the language switcher had only a few popular languages appear initially, and revealed a further button to show the full set. I don't know why frwp removed the switcher, though I agree with their decision. There was an intermediate version where frwp main page looked like ptwp does now, i.e. frwp tried the language switcher top right, then moved it to bottom right before removing it completely. The language switcher is worth considering but we mustn't adopt it simply as an excuse for hiding portals; that proposal seems to be passing without the need to find something to fill the resulting gap. Certes (talk) 20:29, 6 April 2022 (UTC)[reply]

Proposing a change to the notability declining message in AFC[edit]

From:

This submission's references do not show that the subject qualifies for a Wikipedia article—that is, they do not show significant coverage (not just passing mentions) about the subject in published, reliable, secondary sources that are independent of the subject. Before any resubmission, additional references meeting these criteria should be added (see technical help and learn about mistakes to avoid when addressing this issue). If no additional references exist, the subject is not suitable for Wikipedia.

to:

This submission's referencing do not show that the subject qualifies for a Wikipedia article. See an explanation for our inclusion guidelines here.

In summary: the sourcing in this article does not demonstrate significant coverage (not just passing mentions) about the subject in published, reliable, secondary sources that are independent of the subject. Before any resubmission, additional references meeting these criteria should be added (see technical help and learn about mistakes to avoid when addressing this issue). If no additional references exist, the subject is not suitable for Wikipedia.

I think less people will be confused about the decline message then. – AssumeGoodWraith (talk | contribs) 02:35, 16 March 2022 (UTC)[reply]

  • Support seems more clear than current version. signed, 511KeV (talk) 15:42, 16 March 2022 (UTC)[reply]
  • Support, but change "do not" to "does not" for grammatical reasons. ― Blaze WolfTalkBlaze Wolf#6545 16:08, 16 March 2022 (UTC)[reply]
    I would also change "Before any resubmission, additional references meeting these criteria should be added" to "Make sure you add additional references that meet these criteria before resubmitting". Less aggressive but still gets the point across. ― Blaze WolfTalkBlaze Wolf#6545 16:13, 16 March 2022 (UTC)[reply]
  • I think it's important to make it more clear, thanks for the proposal :). The wording is still relatively academic: long sentences, difficult words. Would it work better to use bullet points for the sourcing requirements? This may make it easier to mentally tick the boxes. I may be wrong, but I thought the best convention now is not linking words without meaning (like here). I like Blaze's Wolf suggestion about softening the language. Femke (talk) 20:45, 16 March 2022 (UTC)[reply]
  • I'm feeling daft - is the only difference here adding a hard return after the main statement with some minor formatting tweaks? (please ping on reply) Primefac (talk) 09:10, 17 March 2022 (UTC)[reply]
  • Support highlighting the key statement is key to getting many to read anything in these notices. Lots of these templates could be improved with some minor tweaks. Regards KylieTastic (talk) 09:35, 17 March 2022 (UTC)[reply]
  • Oppose at the moment. In the future I suggest proposing things like this at WT:AFC, or at least leaving us a note on that talk page. By proposing this here I kind of feel like you left WikiProject AFC out of the discussion. Anyway, here are my concerns: 1) This seems to add vertical whitespace. I would suggest removing the line breaks. 2) This links yet another policy page for the draft writer to read. There's a danger of information overload. If anything we could look into making this more concise. –Novem Linguae (talk) 15:18, 17 March 2022 (UTC)[reply]
  • Trying to address information overload, bringing out the four criteria for sources (which a large portion of new editors struggle with), and cutting out the least helpful link (most people understand how to add a source at this point, the 'verification' decline message can provide technical help if they struggle). On a side note, we don't do that well explaining notability before submission. The Article Wizard has a great short and easy explanation how to use sources, but the notability explanation is a bit vague.. Femke (talk) 17:35, 17 March 2022 (UTC)[reply]

This draft's references do not show that the subject qualifies for a Wikipedia article. In summary, the draft needs multiple published sources that are:

Make sure you add references that meet these criteria before resubmitting. Learn about mistakes to avoid when addressing this issue. If no additional references exist, the subject is not suitable for Wikipedia.

Femke (talk) 17:35, 17 March 2022 (UTC)[reply]

Seems good. – AssumeGoodWraith (talk | contribs) 23:45, 17 March 2022 (UTC)[reply]
However, it should say like “not just passing mentions about the subject” – AssumeGoodWraith (talk | contribs) 23:59, 17 March 2022 (UTC)[reply]
I agree. This is a lot simpler compared to the current message, which contains 7 links (compared to the 5 of Femke's proposed message) and takes up 4 lines on my screen size (1366x768). This also gives the reader the main issue in bold so that if they don't want to read the rest, they can see the issue with their article quickly and easily. IF the reader does continue reading, the bullet-points listing what the sources should be make it easy to know what they should be looking for in sources. ― Blaze WolfTalkBlaze Wolf#6545 00:09, 18 March 2022 (UTC)[reply]
I like this a lot, it breaks up the wall of text and draws attention to the important points. Rusalkii (talk) 18:14, 18 March 2022 (UTC)[reply]
@Rusalkii: You pretty much just said the exact thing I did, except in a lot fewer word and it makes more sense than what I was saying. (nothing bad about either of our responses, I just found it kinda funny how we basically said the same thing, but I just chose to go into more detail) ― Blaze WolfTalkBlaze Wolf#6545 18:46, 18 March 2022 (UTC)[reply]
@Femke, I suppose the proposed notability message will be applied downstream on the specific SNG notability messages as well? (see {{AfC submission/comments}} for the full list of the messages possibly applicable) – robertsky (talk) 07:20, 21 March 2022 (UTC)[reply]
Support; Femke's version of the message is a clear improvement to the current one. Much more clear and concise. LunarisTFM (💬 • 📝) 15:10, 28 March 2022 (UTC)[reply]

This basically says the the sourcing-GNG is the only way in. If you want it to be accurate you'd need to instead say that it's the best way in. (SNG's being the other).North8000 (talk) 19:07, 18 March 2022 (UTC)[reply]

I'm fairly sure SNG's basically just build off of GNG. If an article follows GNG it should also be following SNG's, and if it fails GNG I don't think it would be supported by SNG's. ― Blaze WolfTalkBlaze Wolf#6545 19:10, 18 March 2022 (UTC)[reply]
There are some SNGs that are alternatives to GNG, like WP:NPROF. We have a separate decline message for those (which in the case of an academic not showing notability, doesn't put enough emphasis on the SNG, but that's for another day). I don't think I've changed the meaning here from the old decline message. Femke (talk) 19:14, 18 March 2022 (UTC)[reply]
(edit conflict) That's a complicated topic. But the wiki standard is that a new article just needs to meet either the sourcing GNG or the SNG. Why use a different standard at AFC? North8000 (talk) 19:17, 18 March 2022 (UTC)[reply]
My concern with all of these versions is that they assume that the AFC reviewer correctly declined the submission, which is not always the case. I remember one BLP declined with this message, and when the editor inquired with the reviewer, the answer amounted to "Oops, nobody ever told me that WP:NONENG sources were okay." Presumably this is not the usual experience, but in that case, what was needed was just a re-submission (to get a reviewer who happened to know the actual rules) instead of adding more sources. WhatamIdoing (talk) 20:18, 21 March 2022 (UTC)[reply]
I don't see that as a problem with the text of these messages, but as a problem of screening / providing info for new reviewers. If I'm not mistaken, scrutiny for new reviewers has increased? A second solution to that problem would be to do random checks, and give feedback to reviewers when they make mistakes. Femke (talk) 20:27, 21 March 2022 (UTC)[reply]
I think there's a pretty significant ratchet effect at AFC. Nobody wants to be the reviewer who followed the long-standing written directions, because you could be accused of being a lax reviewer who is passing anything with a decent chance of surviving AFD (which is what the AFC directions say all reviewers should do, but...), and that's unpleasant. So the articles that get accepted through AFD are the highest quality ones, and that means the "normal" accepted article is very good, so you want to accept only articles that are better than average, so...
If the trend continues, then of course eventually we'd want to merge FAC and AFC, because the standards would be the same. I don't think we'll get to that point, but we're getting pretty high. Here are the five most recent articles accepted at AFC, with their ORES ratings:
The median rating for English Wikipedia's articles is "Stub". C-class and above is the top 10% of all articles. Why aren't most AFC articles also stubs at the time they're accepted?
Here are the five most recently declined drafts (I can't get ORES ratings for drafts, so I add my own comments):
So you can see, I hope, that I agree more often than I don't, but since two notable subjects were declined in this group, I suspect that the AFC reviewers are looking for a "nice" article or an "above-average" article, instead of an article that is likely to survive AFD on the grounds that the subject is notable.
This gap is what makes me wonder whether these instructions should be written more like ClueBot's warnings: Hey, this is just one person's opinion, and that person could be wrong, but that person thinks you need more/better sources. WhatamIdoing (talk) 20:43, 22 March 2022 (UTC)[reply]
From what I've seen so far, I think I agree about the standards at AfC being a bit too high. Maybe a reminder on WT:WikiProject Articles for creation about common mistakes? A change to the wording here is unlikely going to change that culture.
I'm open to make the reviewer more visible in the text. Do you have a wording proposal? Atm, I'm only able to come up with quite ugly long sentences. Something like "A volunteer has reviewed the draft. They determined that the references do not show that the subject qualifies for a Wikipedia article It semi-duplicates the "Title" of the decline message, which already gives the information that this is a decision by one person. Femke (talk) 20:51, 23 March 2022 (UTC)[reply]
Maybe an “Additionally, if you think this review is wrong, contact the reviewer or go to the help desk.” – AssumeGoodWraith (talk | contribs) 23:20, 23 March 2022 (UTC)[reply]
@AssumeGoodWraith, I like that suggestion. If the AFCH script could automagically put the correct username in the link, then that would be terrific. WhatamIdoing (talk) 00:07, 25 March 2022 (UTC)[reply]
All of the pressure I've felt to be more strict has come from outside AfC (NPPs draftiying and coming to complain about my acceptance on my talk page, harsh AfDs, etc). No one's done anything wrong, in fact the criticism was often founded, but it's stressful enough to be on the receiving end of that I've been leaving some borderline accepts for another reviewer and generally tightened my criteria.
Though it should be noted that AfC as it was explained to me has as a criteria not "the draft will survive AfD", but "the draft will survive AfD on the strength of existing content", i.e. we explicitly do not do our own checks for sources or other notability criteria. That's a manpower problem, not a culture problem. Rusalkii (talk) 13:03, 24 March 2022 (UTC)[reply]
I'm a bit apprehensive about creating more work for reviewers. A large chunk of declined drafts are corporate spam, and those already take up quite a lot of reviewer time. Will they take up a disproportionate fraction of "appeals" too? If we want to tackle overly strict declines, I think a conversation needs to happen at AfC talk, not in these messages. Femke (talk) 17:24, 24 March 2022 (UTC)[reply]
@Rusalkii, I think it's a culture problem. First of all, AFD has never had a rule about "on the strength of existing content", so why would anyone impose that non-rule on AFC? WP:DEL#REASON says nothing like that, and the Deletion policy is unquestionably the one that matters at AFD. We should probably correct that AFC page.
Second, why should anyone be complaining on your talk page or posting harsh AFDs? Sure, if someone believed that the draftification of notable subjects is a way to improve visible article content (by hiding all the "bad" articles), or if they think it's a great way to extort extra edits from any interested editors, then I could see that it would be annoying to have someone disagree with them by supporting the long-standing, written policies and guidelines – but the problem is that other editor, and our culture ought to back you up for putting notable subjects into the mainspace.
Ditto for actual mistakes: All of us make mistakes, so all of us should respond with the same kindness and gentleness that we want to receive when we screw up. More relevantly than that, we have different interpretations and different knowledge. A subject that you think is "obviously" notable, because of your own outside knowledge, is one that might be WP:NEVERHEARDOFIT for me (which, you'll recall, is an invalid argument for deletion). So if I were to reject what you think is an notable subject, it would make more sense for me to at least wonder about whether you know what you're talking about, than for me to yell at you for daring to hold a different opinion. That's the culture change that I think we need: To assume that experienced editors who are following the written policies and guidelines are doing the right thing, even when the right thing means putting an "embarrassing" or "overly positive" article in the mainspace. WhatamIdoing (talk) 00:04, 25 March 2022 (UTC)[reply]
  • I think it important to note that an AFC “decline” is a temporary status, pending further improvement, and resubmission. Reviewers who decline are not rejecting the submission, they are merely stating that the article is not YET ready to be moved to mainspace. Blueboar (talk) 15:30, 28 March 2022 (UTC)[reply]
  • I have not read all the comments but I just want to make sure the notability guideline will link to the correct guideline based on the reviewer's selection as it does today. Also, the guidelines are different for WP:NCORP for depth (WP:SIGCOV vs. WP:CORPDEPTH) and independence of the sources (WP:INDY vs. WP:CORPIND) so that needs to be taken into consideration in the message. I agree the bullet-pointed message is better than we have to today because I think the relevant guideline is buried. S0091 (talk) 23:54, 1 April 2022 (UTC)[reply]

Highlight the syntax highlighter with a ONE OFF message when we open the source editor[edit]

Tracked in Phabricator
Task T305424

I have been editing for years and only just found out by chance that there is a syntax highlighter. It seems that https://phabricator.wikimedia.org/T288161 will probably turn it on by default for new accounts. But that it won't be obvious for existing users https://phabricator.wikimedia.org/T174145

When someone opens the source editor but has syntax editing turned off could a ONE TIME message be displayed to ask whether we want to turn on syntax highlighting? Chidgk1 (talk) 07:04, 23 March 2022 (UTC)[reply]

This might be feasible, but I don't know which team would work on it. Let me ask around for a few days... Whatamidoing (WMF) (talk) 00:12, 25 March 2022 (UTC)[reply]
  • @Whatamidoing (WMF): Are we still in the asking around "for a few days" frame? The idea seems worthy of consideration and shouldn't be archived (nine days) for lack of traffic if still being pursued. -- Otr500 (talk) 06:42, 2 April 2022 (UTC)[reply]
    I'd definitely like to see some movement on this. The community has made clear we like this feature, and the ball is now in the technical folks' court to either implement something or send a specific proposal for us to consider. {{u|Sdkb}} talk 06:54, 2 April 2022 (UTC)[reply]
This section should be excluded from archiving while this is being worked on. -- Otr500 (talk) 08:25, 2 April 2022 (UTC)[reply]
Sorry about the delay. We have some progress (phab:T305424) but no promises of real action. This is one of those small requests that no team is actively assigned to handle. I haven't encountered any significant opposition to the idea, but I also haven't found anyone volunteering to make sure that it happens soon. Whatamidoing (WMF) (talk) 02:44, 5 April 2022 (UTC)[reply]

Dissociate Fiction from Non-Fiction on the Wikipedia platform[edit]

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.

While fiction-related articles, such as motion pictures, books, comics & animation in general are readily available on the en.wikipedia.org domain, which is very useful for various people, the proposal is for them to be migrated on another domain of Wikipedia, perhaps on another server as well, so that they do not get mixed up during a search, and also to better distinguish the objective nature of Wikipedia from the fiction-oriented one. — Preceding unsigned comment added by Barracuda stew (talk • contribs) 09:45, 23 March 2022 (UTC)[reply]

  • I propose that folks who make proposals here sign their own posts first. ;-) BusterD (talk) 09:54, 23 March 2022 (UTC)[reply]
  • Is it not possible to write objectively about fiction? Phil Bridger (talk) 10:48, 23 March 2022 (UTC)[reply]
  • I approve, but only if we start with the Bible and Hamlet. ;) —TheDJ (talk • contribs) 11:00, 23 March 2022 (UTC)[reply]
  • Don't see why this is needed. Fictional articles should be written in a way that clearly portrays that they're fictional, if not then they should be tagged for cleanup. Joseph2302 (talk) 11:47, 23 March 2022 (UTC)[reply]
Please, don't feed the trolls
The following discussion has been closed. Please do not modify it.
  • Please include articles that are poorly referenced, unreferenced, or with unverified references. They are also fiction. 68.173.76.118 (talk) 11:54, 23 March 2022 (UTC)[reply]
    • No they aren't- they're articles on factual things that need improving.... Joseph2302 (talk) 11:58, 23 March 2022 (UTC)[reply]
      • And how is one to know these things are factual? That's supposition. The fact is, absent proof they're fiction. 68.173.76.118 (talk) 12:01, 23 March 2022 (UTC)[reply]
        • It is trivially easy for an article to be both poorly referenced and proven factual. For example an article that is supported only by non-independent sources and makes no un-attributed subjective claims. We can't say it's notable, but we can certainly say it's not fiction. Thryduulf (talk) 14:17, 23 March 2022 (UTC)[reply]
          • ??? an article that is supported only by non-independent sources and makes no un-attributed subjective claims = article that has no independent sources and makes subjective claims (attributed to these non-independent sources) = that is somebody's fictional (opinion/imagination/etc-based) take. Non-fact (ie POV) dressed up in "references". 65.88.88.93 (talk) 16:01, 23 March 2022 (UTC)[reply]
            That doesn't follow at all. Non-independent sources can be used to verify objective statements and to verify attribution of claims. For example, say the article is about XYZ Ltd and the sources are (1) the company website, (2) a company press release and (3) an advert for the company in a major newspaper, the article also contains three photographs showing (a) the company headquarters, (b) one of their products ("XYZ Super") with branded packaging, and (c) a celebrity (Fred Bloggs) using one of the products. The claims in the article are (i) that there is a company called XYZ Ltd, (ii) with a CEO called Jane Doe, (iii) that is headquarted in Anytown, (iv) that makes a product called "XYZ Super", (v) that is advertised as being "The greenest on the market", and (vi) that it is used by celebrities including Fred Bloggs.
            Claim i is verified by sources 1-3 and photos a-c, claim ii is verified by 1 and 2, claim iii is verified by 1 and a, claim iv by 1-3, b and c, claim v by 3, and claim vi by c. i.e. everything is factual. Notability is not demonstrated, but that's entirely different. "Non-fact" and "POV" are not synonyms, non-independent is not synonymous with either "non-fact" or "POV". "Opinion" and "fiction" are not synonyms either. Thryduulf (talk) 18:51, 23 March 2022 (UTC)[reply]
            What you demonstrated in the first paragraph is an example of using primary sources to establish certain facts about the sources themselves, an appropriate and narrow application. This is not contested, and it was not part of the argument made in this section.
            The problem is parts of the second paragraph. Facts are not points of view. They are whole, not just the aspect(s) one knows about or the aspect(s) that one prefers. A fact implies the full view, not one's limited perspective. There is no such thing as "almost factual". That is a an easy way out, an attempt at making something partial and limited equal to the whole. Maybe this kind of mediocrity is accepted because the alternative is really hard work. But unfortunately, in any mix of fact and fiction/opinion/theory/POV the latter wins out. The mix produces yet more non-fact. I leave it to your judgement to decide whether any non-independent position or source can ever substitute or even relate to facts which are by definition independent of perspective. And if they are not facts, they are opinions, POVs and non-facts.
            This shouldn't be so hard. After all there are very few facts compared to the hyperinflation of opinions. But the overabundance is not the reason opinions are worthless. They are inherently worthless, because they have a limited perspective. That is a useful fact to know. You can proceed more realistically from there, perhaps even produce a better encyclopedia. 65.88.88.57 (talk) 19:53, 23 March 2022 (UTC)[reply]
            Most of that is meaningless. There are no points of view in the sample I wrote, other than those which are clearly attributed (i.e. it is factual that the company claims this, it is not relevant whether the claim is true). An article which relies solely on primary and non-independent sources is poorly sourced. My point is to demonstrate that not all poorly sourced articles are fiction (which is what you were claiming). You also claimed that unsourced articles are fiction - it is entirely possible to write an entirely unsourced article that is self-evidentially factual not fictional - for example an article listing the conversions of 1 metre into various other units of length. Thryduulf (talk) 21:55, 23 March 2022 (UTC)[reply]
            As pointed out, the sample you wrote which utilized primary sources, is not contested. What is contested is eg an article supposedly listing length conversions without any sources to prove that the conversions are in fact correct. An article like that is a work of fiction as far as anyone can tell. 98.7.206.190 (talk) 22:04, 23 March 2022 (UTC)[reply]
            You are still not getting that "Unreferenced" and "Fiction" are not synonyms. If I could change fiction to fact just by adding a citation, I could therefore change fact to fiction just by removing a citation. The world doesn't work like that. Thryduulf (talk) 22:07, 23 March 2022 (UTC)[reply]
            We are talking about Wikipedia, a platform of anonymous contributors with unknown credentials and expertise, whose audience is the general reader, another quantity of unknown credentials and expertise, individually and in aggregate. The prudent and rational approach is to assume/presume nothing else about both groups. In such situations, unverified claims are no different from fiction. Without a proper reference, there is no prior or implied guarantee that they are factual. A reader may justifiably think they are just things somebody came up with, and very easily posted in some online platform. And let the buyer beware. 68.173.76.118 (talk) 00:05, 24 March 2022 (UTC)[reply]
            • I don't think this is relevant to the proposal, which was clearly concerned with fiction as an art form, rather than anything to do with whether articles have independent reliable sources. Phil Bridger (talk) 19:31, 23 March 2022 (UTC)[reply]
              The point was that articles that are not verified as having independent reliable references are works of "art". Fiction, for all a reader knows. Maybe they belong in a fiction-publishing platform instead. This is said in all seriousness. The harm that half-truths and opinions can do when presented as facts is great. The proper usage of primary sources was noted above, and is not part of this. 65.88.88.57 (talk) 20:01, 23 March 2022 (UTC)[reply]
  • Reject - there is no purpose served by this suggestion. The fictions which entertain us are part of our big, complex global culture, as much as our history, politics and religious/philosophical systems. As has already been pointed out, any article about a fiction which does not make it clear from the first sentence that this is fiction, is a junk article. --Orange Mike | Talk 13:24, 23 March 2022 (UTC)[reply]
  • Reject While I agree that it would be nice to be able to tune search so that whole genres could be omitted, and the people looking for Mercury from respectiely an astronomy, chemistry, religion and space flight perspective could more easily find what they want; I don't see further subdivision of Wikipedia as a good way to do this. Our strength is in being a general interest encyclopaedia, and that means covering the topics that don't interest each of us individually as well as the ones that do. This particular proposal also suffers from boundary issues, many religions might be glad to categorise other religions as fictional, but incensed if that was done to them. The same sort of thing would apply if we tried to spin off sport as something separate, just imagine the arguments as to whether darts, golf, chess, professional wrestling or even punt jousting were real sports. ϢereSpielChequers 11:09, 24 March 2022 (UTC)[reply]
  • Question: How often do readers end up on an article about a work of fiction when they are searching for something non-fictional? Some examples might help us determine whether this is a serious issue (or not). Blueboar (talk) 11:35, 24 March 2022 (UTC)[reply]
  • Agree with those above suggesting a can of worms when it comes to mythology and religion and folkloric history. Hyperbolick (talk) 12:45, 24 March 2022 (UTC)[reply]
  • Reject - fiction exists, it is a "real world" thing. We should, and do, strive to present any work of fiction from a real-world perspective, with limited and (hopefully) clearly demarcated "in universe" material. Also, to take the OP's idea to the extreme, if we do not cover fiction (ie novels, films, tv shows, comic books, etc), then the articles about the people who create these fictions and the companies that distribute them and the fan communities that celebrate them, etc. would be pretty scant at best. --User:Khajidha (talk) (contributions) 14:24, 24 March 2022 (UTC)[reply]
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.

Proposal for Template:Template help[edit]

Hi everyone, I realise that we have templates such as {{Help me}} & {{Admin help}} that categorises the pages where it is used, so that other editors/admins can respond to their queries. Now, I also realise that even unprotected templates (& template styles/modules) can sometimes be very complicated for the average editor to understand or edit. Currently, for them to seek help or suggest a reasonable change, they'd have to ask other editors directly on their talk page. I think a template {{Template help}}, like Admin help would be much efficient & useful for such editors seeking help. Thanks! ---CX Zoom(he/him) (let's talk|contribs) 07:14, 26 March 2022 (UTC)[reply]

They can ask at the technical village pump. Graham87 09:09, 27 March 2022 (UTC)[reply]
I believe it's better to separate mere requests for help from technical village pump, the way we separate requests for admin help from Administrator's noticeboard. Thoughts? ---CX Zoom(he/him) (let's talk|contribs) 09:27, 27 March 2022 (UTC)[reply]
An interesting idea. It would neatly identify and collate the request, and ping the watchlists of those who maintain that template. On the other hand, it would take the request off VPT which is watched by many people who could help and might not monitor the category. Certes (talk) 11:46, 27 March 2022 (UTC)[reply]
This is not me opposed to the idea, but what's wrong with using {{help me}} in these situations? Primefac (talk) 12:21, 27 March 2022 (UTC)[reply]
Great idea. Articles can be edited by almost anyone, whereas editing most templates requires skill in coding. I used to use {{edit request}} on templates (as instructed in the header of protected templates) and was often rejected as 1. establish consensus (even for non-controversial changes) or 2. failure to say "change x to y" (which requires specialized coding skill). I've since learned to look though the history for an TE that has recently worked on the template or ping someone I know is likely/willing to make the change. It would never ask for this kind of help at VPT, and {{help me}} is similarly general. I'm sure a specific cat for template help would be monitored by prolific template editors with the right skills and interests. MB 17:03, 27 March 2022 (UTC)[reply]
  • Instead of a new template it would be good to have a mechanism to alert users that questions can be asked at WT:WPT (WikiProject Templates). That way, multiple people will see the question and be able to respond. Johnuniq (talk) 22:13, 27 March 2022 (UTC)[reply]
    I think that's a better option; I have too many cats to keep track of as it is, and honestly the only reason I'm able to respond to {{help me}} requests is because there's a bot in the -helpers IRC channel that pings whenever someone's used it. Primefac (talk) 09:37, 28 March 2022 (UTC)[reply]
    I understand that this would add to the number of tasks many editors have to keep an eye on. But, as Certes notes above, this system would ping the template's maintainers' watchlists to review the requested changes themselves, allowing them to review the requested change. Maybe we can add one more task to the bot which pings the IRC if there is some backlog, say 5 requests, using this template. Or when, a request is unanswered for, say 5 days, a bot automatically moves it to WP:WPT or WP:VPT. ---CX Zoom(he/him) (let's talk|contribs) 21:05, 30 March 2022 (UTC)[reply]

Adding no-wrap to hatnote links: low-involvement testers needed for proposed change[edit]

We need some volunteers at Template talk:Further#Volunteer sign-up to help assess a proposed change to hatnote link wrapping. This will take very little of your time. A proposal at Template talk:Further#Adding nowrap calls for no-wrapping links in hatnotes to prevent undesirable line breaks in the middle of a link, such as:

Further information: World War II, Events preceding World War II in Europe, and Causes of World War
II

This currently may happen in a hatnote link such as in template {{Further}} where a link happens to bump up against your window's right margin, or a right-floated sidebar or other element. Implementation would involve a simple change to Module:Hatnote, but as this represents a change to the current behavior of a high risk template, we don't wish to make such a change lightly. Fortunately, the module already has an optional class which permits this to be tested in situ with a simple addition to your common.css, as follows:

.hatnote a {white-space: nowrap;} /* Test for nowrap hatnote links */

We are seeking volunteers to add this line to your css, and then just go about your business as before. In around a month or so (or whatever period seems right), we'll ping you and ask for your comments, and if feedback is supportive, we'll make the change to the module. If you can help, please add your name at Template talk:Further#Volunteer sign-up so we can contact you later for your impressions. Thanks, Mathglot (talk) 20:09, 27 March 2022 (UTC)[reply]

Sounds to me like it would give undesirable horizontal scrolling for people on mobile devices when links are long. Anomie⚔ 21:36, 27 March 2022 (UTC)[reply]
That's the first thing I thought as well. ScottishFinnishRadish (talk) 21:58, 27 March 2022 (UTC)[reply]
I presume that one of the reasons for this testing is to show whether that issue commonly arises. Phil Bridger (talk) 08:12, 28 March 2022 (UTC)[reply]
Probably the better final implementation (I make no comment on whether preventing nowrapping in hatnotes is desirable) would be to use nowraplinks already defined in Common.css. Mobile.css is more generous with how it treats that class which would take care of the mobile concern. Izno (talk) 23:27, 28 March 2022 (UTC)[reply]
@Anomie and ScottishFinnishRadish:, The first thing I though of, too; but the mobile issue turns out not to be a problem; please see the discussion. @Phil Bridger:, yes, exactly. @Izno:, yes, it is; this is only the test phase; please see the linked discussion. Please do have a look and sign up; it would really help. Thanks, Mathglot (talk) 09:46, 29 March 2022 (UTC)[reply]
I see nothing in the linked discussion that indicates it's not a problem. Your claim near the start that it's "already the default behavior on mobile" is confused by the fact that your example is in a fixed-width box. Anomie⚔ 11:22, 29 March 2022 (UTC)[reply]
nowrap is bad. It's a webpage, they are supposed to wrap flexibly and you cannot predict all the content and all the widths that this content is rendered at. Every time ppl introduce more nowrap, it is just waiting for the next report where it has broken something else. In my opinion it should never be used for anything over say.... 10 characters long. —TheDJ (talk • contribs) 09:48, 30 March 2022 (UTC)[reply]

Android related question for developers[edit]

Moved to WP:VPT#Android related question for developers. --Izno (talk) 23:31, 28 March 2022 (UTC)[reply]

Science Photo Competition 2022 Russia targeting CentralNotice banner[edit]

On April 2, the «Science Photo Competition 2022» started, traditionally the photo marathon is being held jointly with the Nauka television channel, it will be interesting. We invite everyone who is interested in science and who is able to hold a camera in their hands. The rules of the contest are very simple, prizes have a place to be! Colleagues, to attract external participants, we proposed a banner of the competition through CentralNotice. JukoFF (talk) 19:33, 28 March 2022 (UTC)[reply]

Inverted colors; "Dark" version[edit]

Tracked in Phabricator
Task T26070

Does Wikipedia have a button / option, as does for example Youtube, where you can invert colours so it's not as bright? I think it would be a big improvement to add it, if it doesn't have one. - Joaquin89uy (talk) 12:45, 31 March 2022 (UTC)[reply]

@Joaquin89uy: in Special:Preferences#mw-prefsection-gadgets look for dark mode toggle - is that what you are looking for? — xaosflux Talk 12:53, 31 March 2022 (UTC)[reply]
Yes! Thanks. It shouldn't need enabling though, it should appear to everyone from the get go, imo... (also it's a bit too dark, but that's a detail i guess lol). - Joaquin89uy (talk) 13:03, 31 March 2022 (UTC)[reply]
I agree that everyone including IP editors should also have access to the gadget, but I think we should hold this proposal until the default skin is switched to Vector 2022, as Dark mode doesn't go well with Vector legacy's (current default skin) sidebar and footer. ---CX Zoom(he/him) (let's talk|contribs) 13:40, 31 March 2022 (UTC)[reply]
What's Vector ? - Joaquin89uy (talk) 16:36, 31 March 2022 (UTC)[reply]
On of the "skins" available in Special:Preferences#mw-prefsection-rendering. — xaosflux Talk 17:09, 31 March 2022 (UTC)[reply]
Ah! I see. Thanx. Now I know. - Joaquin89uy (talk) 11:57, 4 April 2022 (UTC)[reply]
@CX Zoom There's no such known issue with dark mode in vector legacy. If you're seeing an issue, please post to WT:Dark mode (gadget) with details and screenshot. – SD0001 (talk) 14:45, 1 April 2022 (UTC)[reply]
Dark mode gadget used on Vector legacy on Android
@SD0001 Thanks for letting me know. I think this issue happens only when Dark mode is used in conjunction with Vector legacy on Android browsers (Chrome/Edge) (see the picture), which is the platform I most often use. After your comment, I used dark mode on Vector legacy on Edge on Windows to confirm, and yes it works perfectly fine there. Also, on Android, dark mode works perfectly with just any other skin but not Vector legacy. ---CX Zoom(he/him) (let's talk|contribs) 11:03, 4 April 2022 (UTC)[reply]
@Joaquin89uy and CX Zoom: the "dark mode toggle" gadget we have here is a community supported js/css gadget - a more official darkmode option is being tracked in : phab:T26070. — xaosflux Talk 15:24, 31 March 2022 (UTC)[reply]
Nice. - Joaquin89uy (talk) 11:58, 4 April 2022 (UTC)[reply]

Template to request page translation from English to another language[edit]

Apologies if this exists in some form but I have been unable to find it if it does. I know there are editors who translate pages from one language to another and there are ways to request expanding English pages using translations from other language Wikipedia pages. However, my proposal is for the creation of a template that can be added to articles requesting the page be translated from English to another language. The English language Wikipedia has far more pages than any other language version of Wikipedia and there are many pages about organisations or subjects that have strong ties to a specific country that may be non-English speaking, whereby it would make sense for the page to have a translated version in that country's native/official language if one does not exist already, which is the case with many pages. For example, the page Great Legalisation Movement India has an English language version but no Hindi language version. Therefore, it would be beneficial to be able to add a template to this page requesting a Hindi language version of the page be created. Helper201 (talk) 20:18, 31 March 2022 (UTC)[reply]

Why should we care whether out articles are translated into other languages? This is the Hindi Wikipedia's issue, not ours. * Pppery * it has begun... 20:53, 31 March 2022 (UTC)[reply]
This would be best done on the destination wiki, most people that come across our article are unlikely to be able to write in the foreign language. Check out wikidata:Q13308814 for some examples of "requests for translation" on other projects. — xaosflux Talk 21:10, 31 March 2022 (UTC)[reply]
Some Wikipedias have a page to request articles, not necessarily as translations; we have Wikipedia:Requested articles, and the matching page at Wicipedia Cymraeg is Erthyglau a geisir, where I once made this request, despite not speaking that language. Just over three years later, I was rewarded with Deddf Cynulliad Cenedlaethol Cymru (Ieithoedd Swyddogol) 2012. --Redrose64 🌹 (talk) 21:05, 1 April 2022 (UTC)[reply]
For an article which isn't going to have huge readership in another language, I generally think running the English-language article through Google translate would work best (assuming translation to and from your language works OK, I don't know if that's the case). English language articles are much more frequently updated than other languages in many cases, I've seen cases where a translation preserved the content of an article exactly as it was in say 2019, the article has been massively expanded since and the foreign-language article has stagnated with no improvements. Google translate on the English article is more likely to be up to date. Blythwood (talk) 04:10, 6 April 2022 (UTC)[reply]

Moving "Sitting Bull" to "Tatanka Iyotake"[edit]

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.

We need to known the real name, not the nickname. Please do this treatment to other languages of Wikipedia. — Preceding unsigned comment added by CafeGurrier66 (talk • contribs) 10:31, 1 April 2022 (UTC)[reply]

No, we don't. We use the most common name, which in this case is "Sitting Bull". Not only that, but the name you want to use is literally the fourth and fifth words of the article at Sitting Bull, moreover, Tatanka Iyotake redirects to the article at its current name. I suggest you close this section, as it's very unlikely to go anywhere. Happy days ~ LindsayHello 11:31, 1 April 2022 (UTC)[reply]
Also, the proper process for move requests is WP:RM, not here. Iffy★Chat -- 11:50, 1 April 2022 (UTC)[reply]

Help[edit]

Use Support if you agreed or Oppose if you disagreed

Support[edit]

If you agreed, type your rational here

Oppose[edit]

If you do not agree, type here your rational CafeGurrier66 (talk) 10:31, 1 April 2022 (UTC)[reply]

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.

Allow emails from brand-new users[edit]

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

The word "brand-new users" in the preference should be wikilinked to "WP:AUTOCONFIRM". (Context at Wikipedia:Village_pump_(technical)#"Allow_emails_from_brand-new_users") Venkat TL (talk) 13:16, 1 April 2022 (UTC)[reply]

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.

Proposal to extend April Fools Day[edit]

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 we sadly have less than half an hour left before April Fools Day ends and we all have to go back to be super serious editors. Given the unquestionable positive impact April Fools Day has had on our project and community, I consider this to be a shame. Further, like most years this April Fools Day fell over a school/work day, meaning many of our editors barely got to participate. In light of all of this, I think some changes are in order: we should extend the April Fools Day tomjerryfoolery to cover the entire month of April! Let me know what you all think please. Spirit of Eagle (talk) 23:35, 1 April 2022 (UTC) [April Fools!][reply]

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.

Proposal: Make an IAR exception to the no cross-namespace redirects rule to redirect from Main Page/sandbox to Wikipedia:Main Page/sandbox[edit]

This is a redirect that I think would be useful when it comes to the sandbox for the main page. Normally, we are against cross-namespace redirects, but I think this is one that would be useful. Interstellarity (talk) 13:48, 2 April 2022 (UTC)[reply]

  • Oppose: A no is a no CafeGurrier66 (talk) 15:33, 2 April 2022 (UTC)[reply]
  • 1. In principal, I'm against the very existence of Main page in mainspace, and wish it were in the project namespace, like some other English language projects (wiktionary:) already do.
    2. If Main page remains in mainspace, it only makes sense that it's subpage-seeming pages also redirect to relevant pages in Wikipedia namespace, and thus I support this proposal. ---CX Zoom(he/him) (let's talk|contribs) 16:07, 2 April 2022 (UTC)[reply]
  • Comment I was initially inclined to support this, as there's no reasonable way a reader would naturally navigate to the sandbox page. But then it occurred to me that creating this redirect might cause the page to appear in search suggestions (a feature in New Vector) when someone starts to type "Main Page", introducing potential confusion. If that's true, it moves me toward opposition, as reader needs should come first. {{u|Sdkb}} talk 16:51, 2 April 2022 (UTC)[reply]
    @Sdkb: If so, couldn't the page be noindex'ed? ― Qwerfjkltalk 21:00, 2 April 2022 (UTC)[reply]
    @Qwerfjkl, as far as I know, search engine indexing affects Google searches (which I'd presume would be smart enough to hide the sandbox) but not suggestions that pop up while you're typing in the Wikipedia search bar (which is what I'm thinking about here). {{u|Sdkb}} talk 21:23, 2 April 2022 (UTC)[reply]
  • I mark any cross-namespace redirect as egilible for speedy deletion. - CafeGurrier66 (talk) 09:58, 4 April 2022 (UTC)[reply]
    @CafeGurrier66: Not all cross-namespace redirects are eligible for speedy deletion. The R2 speedy deletion criterion only covers redirects from the mainspace and does not cover redirects to Category, Template, Wikipedia, Help, or Portal namespaces either. Sdrqaz (talk) 09:58, 5 April 2022 (UTC)[reply]

What if accounts are created by administrators[edit]

One day, I looked in the block list that there are many blocked newcomers and my propositions are: 1. Make an email adress to request for an account once the Create account button for unregistered (anonymous) users will be gone 2. Edits from newcomers (non-autoconfirmed users) will need moderation from automoderated users. Is this good for Wikipedia? CafeGurrier66 (talk) 15:18, 2 April 2022 (UTC)[reply]

There is already a method to request an account(WP:ACC). I'm also not clear on what your solutions actually have to do with the problem you describe. 331dot (talk) 15:21, 2 April 2022 (UTC)[reply]
There is also already a place for new/inexperienced users to seek a mentor (WP:AAU). 331dot (talk) 15:22, 2 April 2022 (UTC)[reply]
I am looking at an email adress to request for an account. This proposition can reduce vandalism as I want that the Create account option be removed so that accounts are created using an email adress CafeGurrier66 (talk) 15:25, 2 April 2022 (UTC)[reply]
See Wikipedia:Perennial_proposals#Prohibit_anonymous_users_from_editing. There are good arguments for this, but trying to convince people that change is needed will require a lot of work. AndyTheGrump (talk) 15:32, 2 April 2022 (UTC)[reply]
It would increase vandalism, not reduce it. Vandals could use throwaway email addresses to obtain accounts over and over. 331dot (talk) 23:46, 2 April 2022 (UTC)[reply]
There is also now WP:Growth Team Features, with mentors. Happy Editing--IAmChaos 04:49, 4 April 2022 (UTC)[reply]
Making accounts harder to obtain would certainly deter some bad edits, but would also deter some good edits. We've discussed this several times and many editors support preventing anonymous edits. However, the consensus is that, on balance, we should keep the current process. Newcomers' edits can be made to await moderation using Pending changes but this is only applied to a few pages where vandalism has been a frequent problem. A current proposal to hide IP addresses may make unregistered vandals so hard to deal with that we are forced to limit editing to registered users, but details are still unclear. Certes (talk) 00:00, 3 April 2022 (UTC)[reply]
I thought this was more than a proposal- that they were doing it(the IP thing). 331dot (talk) 01:11, 3 April 2022 (UTC)[reply]
If I were detered from editing when I didn't even have an email account, I'd probably never create an account and edit here, as to me, it would've felt a bit hostile place. ---CX Zoom(he/him) (let's talk|contribs) 01:00, 3 April 2022 (UTC)[reply]
Yes, I have encountered IP editors in the past who did not want to create an account because they thought they were required to provide an email address. I've also encountered editors wishing to edit through an IP block but did not want to provide an email to request an account. 331dot (talk) 01:12, 3 April 2022 (UTC)[reply]

Music genre discussion thread[edit]

I'd like a forum where you can post a song and have people discuss its genre. If this already exists, just link me to it. Wtoteqw (talk) 18:26, 2 April 2022 (UTC)[reply]

Not what Wikipedia is for. AndyTheGrump (talk) 18:47, 2 April 2022 (UTC)[reply]
@Wtoteqw: See WP:NOTFORUM; and because you posted this in other places as well, see WP:MULTI. --Redrose64 🌹 (talk) 19:02, 2 April 2022 (UTC)[reply]
Wtoteqw If you just want to discuss music in general, that's what social media is for. If you want to discuss how to classify Wikipedia articles about songs in terms of their genre(often a contentious business from what I see), you should use the article talk page of the relevant song's article. 331dot (talk) 01:14, 3 April 2022 (UTC)[reply]
Any discussions regarding statements about music genres on article talk pages must be based around what reliable sources say. We aren't the slightest bit interested in contributors own opinions... AndyTheGrump (talk) 03:31, 3 April 2022 (UTC)[reply]

Proposal: issue a notice when an edit creates a File: redlink[edit]

A common problem with bulk spelling/case/punctuation fixes is accidentally applying them in filenames, turning them to redlinks. This should be easy to detect and notify about, similar to how you get a message when you create a link to a disambig page. Can we get such notices, at least as an option? Dicklyon (talk) 01:05, 4 April 2022 (UTC)[reply]

Seconded. I've almost created quite a few such errors using JWB etc. DPL bot may be a useful model: it issues a polite user warning when we link to disambiguation pages. Certes (talk) 10:28, 4 April 2022 (UTC)[reply]
@Certes, I presume that Dicklyon is referring (correct me if I'm wrong) to mw:Help:Extension:Disambiguator, which is even better than DPL bot, as it alerts you in real time. {{u|Sdkb}} talk 04:24, 5 April 2022 (UTC)[reply]
Both might be useful. An immediate alert in WikiEditor is a good idea and should reduce such errors in manual editing. I assumed from the term "bulk" that Dick's suggestion applied instead to errors created with tools such as AWB and JWB, where editors might preview just a sample rather than every page, and possibly by bots. Unless we're going to change that software then an alert after the fact may be the best we can do there (but see xeno's filter comment below). Certes (talk) 10:26, 5 April 2022 (UTC)[reply]
Is this covered at all by WP:Edit filter/Requested/Archive 13#File name changes? –xenotalk 14:56, 4 April 2022 (UTC)[reply]
This is another excellent idea for how to apply the pop-up box framework. I've discussed it before with @NRodriguez (WMF) and the community at Wikipedia:Village pump (technical)/Archive 194#Adding a new edit filter trigger action: pop-up box. More work is needed on the technical end before this will be ready, but it would be fantastic, so I really hope it gets taken on. {{u|Sdkb}} talk 04:26, 5 April 2022 (UTC)[reply]
I think both the realtime pop-up and the after-the-fact notification would be useful. I was thinking more of the lattter, for AWB or bot edit error catching. It's easy to fix after the fact if the errors are noticed (e.g. by another small AWB batch for a commonly used filename that got messed up in a big batch; I've done this for errors someone noticed, but then that someone is already annoyed). Dicklyon (talk) 18:44, 5 April 2022 (UTC)[reply]

Diff colours[edit]

After years of squinting, I just became the 400th editor to fix the appearance of diffs so that added and deleted text is clearly visible. Is it time to change the default colours? Certes (talk) 14:15, 5 April 2022 (UTC)[reply]

Yes. I would have changed it for myself many years ago if I had known how, but that only affects one editor. Nearly all would benefit from a change to the default. Phil Bridger (talk) 14:49, 5 April 2022 (UTC)[reply]
@Certes I think several changes have been done to these, are you using Vector 2022 as your skin, it should have the "latest" updates. — xaosflux Talk 14:58, 5 April 2022 (UTC)[reply]
Ah, you're right: I'm using Legacy Vector. (I prefer article text to occupy most of the screen, rather than just the bottom right corner.) The new skin does make diffs clearer than before, but small portions of deleted text are still hard to spot so I'll keep my CSS hack. Certes (talk) 18:16, 5 April 2022 (UTC)[reply]
mw:Visual diffs offers another way to look at it. The team never settled on a good color scheme, though, so I warn you that it's all intense red and green. Other aspects of the approach might be handy, though, and you can toggle back and forth between the two modes. It's in Beta Features, if you want to try it out. (It'll remember whichever mode you used most recently.) Whatamidoing (WMF) (talk) 19:56, 6 April 2022 (UTC)[reply]
Thank you, that's a useful backup for when I just can't spot the dot that's been replaced by a comma in the middle of a full-page paragraph. Certes (talk) 20:37, 6 April 2022 (UTC)[reply]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(proposals)&oldid=1081334632"