Wikipedia:Village pump (proposals)
Policy | Technical | Proposals | Idea lab | WMF | Miscellaneous |
The proposals section of the village pump is used to offer specific changes for discussion. Before submitting:
- Check to see whether your proposal is already described at Perennial proposals. You may also wish to search the FAQ.
- This page is for concrete, actionable proposals. Consider developing earlier-stage proposals at Village pump (idea lab).
- Proposed policy changes belong at Village pump (policy).
- Proposed speedy deletion criteria belong at Wikipedia talk:Criteria for speedy deletion.
- Proposed WikiProjects or task forces may be submitted at Wikipedia:WikiProject Council/Proposals.
- Proposed new wikis belong at meta:Proposals for new projects.
- Proposed new articles belong at Wikipedia:Requested articles.
- Discussions or proposals which warrant the attention or involvement of the Wikimedia Foundation belong at Wikipedia:Village pump (WMF).
- Software changes which have consensus should be filed at Phabricator.
Discussions are automatically archived after remaining inactive for nine days.
Proposal to change portal links on the Main Page[edit]
- 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.
There is a weak consensus to add the language switcher button to the newly freed space in the upper right corner (3). Many editors did not mention this element of the proposal, with most focusing on the portal elements, while among those who did there were decidedly mixed feelings. Concerns expressed included questions about whether this tool should be so prominently displayed and technical concerns about implementation. These technical concerns should be taken seriously as this RfC is implemented and it may be discovered that subsequent discussion, or a follow-up RfC, is needed around the language switcher.
A few editors also expressed procedural concerns about this RfC, suggesting it lacked neutrality. There was some pushback on this noting that the RfC question asked was neutrally phrased and to the extent that the background was not neutral that it was located after the neutrally phrased question. This latter view is supported by WP:RFCNEUTRAL and given the use of the RfC tag, the holding of the discussion at a prominent location (a Village pump), and the inclusion of the discussion at CENT, there appears to be insufficient procedural reason to not honor and implement the consensus found in this discussion. Barkeep49 (talk) 19:45, 14 April 2022 (UTC)
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)
Background[edit]
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)
Proposal[edit]
We propose the following related changes:
- Remove the portal links from the top banner and center-justify the
Welcome to Wikipedia
message. - 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.
- Add the language switcher button to the newly freed space in the upper right corner.
- Mockups
Proposed addition of portals contents link to {{Other areas of Wikipedia}}
Best, {{u|Sdkb}} talk and JBchrch talk 01:19, 15 March 2022 (UTC)
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)
- 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)
- Support looks good and cleaner. We could increase the size of "Welcome area" to lessen white area.Moxy-
02:00, 15 March 2022 (UTC)
- 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)
- 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)
- 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)
- 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)
- @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)
- @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)
- 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)
- ??? 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)
- 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)
- ??? 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)
- 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)
- @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)
- @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)
- Support, great idea and much better looking. A. C. Santacruz ⁂ Please ping me! 06:58, 15 March 2022 (UTC)
- 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)
- Support, looks much better. Cavalryman (talk) 09:49, 15 March 2022 (UTC).
- 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)
- 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)
- 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)
- Procedural oppose. Per my extended comments below, this RFC is extremely non-neutral and so invalid. Thryduulf (talk) 12:43, 15 March 2022 (UTC)
- 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)
- 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)
- 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)
- 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)
- 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:
- 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.
- 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).
- 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)
- Support Much better than outright removing them. NW1223 <Howl at me•My hunts> 15:22, 15 March 2022 (UTC)
- Support. Ruslik_Zero 20:27, 15 March 2022 (UTC)
- 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)
- 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)
- 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)
Support ― Qwerfjkltalk 07:05, 16 March 2022 (UTC)
- Support
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)
- This clearly has become the RFC and so I'm striking my procedural oppose in order to to comment on it. With the evolution of search, portals are not a used way to find info and so disproportionate emphasis on the main page should be corrected. North8000 (talk) 13:16, 12 April 2022 (UTC)
- 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)
- 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) - 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)
- 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)
- 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)
- 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) - 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)
- 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)
- 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)
- Support Long overdue. --Jayron32 13:30, 21 March 2022 (UTC)
- Support. ---CX Zoom(he/him) (let's talk|contribs) 09:40, 23 March 2022 (UTC)
- Support If it's moved somewhere, then sure. --99.227.9.86 (talk) 17:00, 24 March 2022 (UTC)
- 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)
- 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)
- Support looks better, cleaner, and the language switcher would help users access other languages easily. Itsquietuptown ✉️📜 02:05, 29 March 2022 (UTC)
- 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)
- 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)
- 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)
- 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)
- 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)
- So, I Support P1 per Background cited. Weak Support P2, Analyzing the most popular portals Massviews , without the main page portals, I realize that the portals have an excellent potential for a “not encyclopedically rigid content”. This is good, instead of a link to the monotonous
Content portals
it could be a link to a new Portal:portal page, more visual, free and fun. And Oppose P3, the language switcher button doesn't look better to me than a blank space.Guilherme Burn (talk) 19:13, 7 April 2022 (UTC)
- So, I Support P1 per Background cited. Weak Support P2, Analyzing the most popular portals Massviews , without the main page portals, I realize that the portals have an excellent potential for a “not encyclopedically rigid content”. This is good, instead of a link to the monotonous
- 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)
- 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)
- 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)
- 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)
- Support -- It looks to be a well founded proposal to me. -- Dolotta (talk) 22:39, 31 March 2022 (UTC)
- 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)
- 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)
- Oppose, 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)
- Support. Portals are just generally low-quality and don't reflect how Wikipedia is used today; we should be sunsetting them completely on every level and at every opportunity. The argument that people are somehow still using them in significant numbers or that they somehow provide some sort of useful function seems entirely speculative, while their low quality is obvious at a glance. Worse, their very nature tends towards WP:OR and WP:SYNTH - they date back to a much older time when the idea of having such "conversational" things that essentially use their structure to educate readers in the voice of editors was not so clearly unacceptable. Complete removal from the main page would be ideal and should still be pushed for in the long term - even the "other ways to navigate" isn't ideal; portals should not be linked anywhere at all in any context and should ultimately be tagged as depreciated, since they no longer reflect or fit into the goals of the project - but this is at least a vast improvement over the current situation. --Aquillion (talk) 07:25, 8 April 2022 (UTC)
- Oppose. I'm clearly out of step with the community on the question of portals, but I genuinely dislike the proposed design. I don't think including the language picker is a good idea at all: it's not in the matching style, gives a very difficult to use way of navigating to a different language, isn't something that many readers reaching the English Wikipedia are likely to want to use, and would give three different ways of accessing different language versions. It feels like an ill-thought-out dummy item to address the objections in the previous RfC to replacing portal links with blank space. I also much prefer a left-aligned welcome message. Espresso Addict (talk) 02:12, 9 April 2022 (UTC)
- Support I do not believe portals should be featured so prominently, though I do strongly believe they should be retained. The language switcher is to me a great idea; I find the current way of switching between languages to be quite cumbersome. Ljgua124 (talk) 09:14, 12 April 2022 (UTC)
- Support - It looks more professional. I don't believe portals are important enough (they're still important!) to be one of the first things a reader sees when they open Wikipedia. — Golden call me maybe? 10:33, 13 April 2022 (UTC)
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)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)- 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)
- 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
- 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)
- 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)
- I have to agree that this is a manifesto rather than an RfC. To pick just one point, I don't see how
only
and2000–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)- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- I think that, given the fairly overwhelming nature of the consensus so far, it is extremely unlikely that changes to the wording of the RFC could shift the result enough to alter the outcome. Especially given that this concern was raised early on and has clearly failed to sway participants, it feels like procedural stonewalling to object to such an overwhelming RFC result on procedural grounds - it's pretty obvious from the discussion here that the position of portals on the main page is not sustainable. Asking for another month-long RFC with different wording just so it can inevitably reach the same result is not reasonable. --Aquillion (talk) 07:37, 8 April 2022 (UTC)
- @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)
- @ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ, 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)
- 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)
- @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)
- 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)
- 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)
- 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)
- 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)
- Although I expressed support to remove Portal links from the top, I think they deserve a separate section towards the bottom, with somewhat detailed explanation, say, "Explore the world of Science, visit the Science portal (newline) Other portals: (there goes a brief list), (then comes) [link:See all portals]". The portal name on the first line will be shown at random using {{random item}}. Thoughts? —CX Zoom[he/him] (let's talk • C • L) 14:06, 7 April 2022 (UTC)
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)
- Support seems more clear than current version. signed, 511KeV (talk) 15:42, 16 March 2022 (UTC)
- Support, but change "do not" to "does not" for grammatical reasons. ― Blaze WolfTalkBlaze Wolf#6545 16:08, 16 March 2022 (UTC)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
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:
- in-depth (not just passing mentions)
- reliable
- secondary
- independent of the subject
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)
- Seems good. – AssumeGoodWraith (talk | contribs) 23:45, 17 March 2022 (UTC)
- However, it should say like “not just passing mentions about the subject” – AssumeGoodWraith (talk | contribs) 23:59, 17 March 2022 (UTC)
- 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)
- 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)
- @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)
- @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)
- 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)
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)
- 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)
- 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)
- (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)
- 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)
- 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)
- 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:
- Voyage to the Stars – C-class
- Seaborn Wright – Stub
- Reading 2100 – C-class
- Choi Jae-seo – C-class
- Pleasant Hill Historic District (Macon, Georgia) – Start-class
- 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):
- Draft:Amityville Gas Chamber – no independent sources; I have no idea if it meets WP:NFILM. Probably Start-class.
- Draft:Pixpro Software – four sources cited, one of which might be an independent (but probably also lower-quality) trade rag. Probably Start-class.
- Draft:Lloyd Business School – All India Council for Technical Education-approved school = would almost certainly survive AFD. Stub.
- Draft:Pop Danilo – 17th-century painter with a book for a source = would almost certainly survive AFD. Start-class.
- Draft:Mini Me Dolls – No independent sources. Product likely non-notable. Barely Start-class.
- 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)
- 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)
- 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)
- @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)
- @AssumeGoodWraith, I think that sentence is clearer without "Additionally". 73.127.147.187 (talk) 10:57, 9 April 2022 (UTC)
- 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)
- 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)
- @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)
- 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)
- 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)
- 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)
- 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)
- 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)
- Oppose AssumeGoodWraith's proposal; Support Femke's version, as I like the WP:42-esque clarity. — Mcguy15 (talk, contribs) 18:05, 8 April 2022 (UTC)
Inverted colors; "Dark" version[edit]
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)
- @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)
- 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)
- 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)
- What's Vector ? - Joaquin89uy (talk) 16:36, 31 March 2022 (UTC)
- On of the "skins" available in Special:Preferences#mw-prefsection-rendering. — xaosflux Talk 17:09, 31 March 2022 (UTC)
- Ah! I see. Thanx. Now I know. - Joaquin89uy (talk) 11:57, 4 April 2022 (UTC)
- On of the "skins" available in Special:Preferences#mw-prefsection-rendering. — xaosflux Talk 17:09, 31 March 2022 (UTC)
- @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)
- What's Vector ? - Joaquin89uy (talk) 16:36, 31 March 2022 (UTC)
- 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)
- 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)
- @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)
- @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)
- Nice. - Joaquin89uy (talk) 11:58, 4 April 2022 (UTC)
I'm just amazed that anybody finds that "easier on the eyes". Gives me a headache trying to make out the text.--User:Khajidha (talk) (contributions) 19:38, 7 April 2022 (UTC)
- @Khajidha It depends on your screen resolution. On certain screens, it doesn't work well. There's a discussion regarding a possible fix at Wikipedia_talk:Dark_mode_(gadget)#Interface-protected_edit_request_on_17_December_2021, though it has gotten stale. You can test the proposed fix by adding to your common.css. Let us know on the linked thread if it works. – SD0001 (talk) 08:13, 11 April 2022 (UTC)
html.client-dark-mode * { text-shadow: 0 0 0; }
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)
- Oppose: A no is a no CafeGurrier66 (talk) 15:33, 2 April 2022 (UTC)
- ---CX Zoom(he/him) (let's talk|contribs) 16:07, 2 April 2022 (UTC)
- In principle, 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.
- 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.
- 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)
- @Sdkb: If so, couldn't the page be noindex'ed? ― Qwerfjkltalk 21:00, 2 April 2022 (UTC)
- @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)
- @Sdkb and @Qwerfjkl There isn't currently any way to do this, but see phab:T24251 for a long-outstanding request to add this functionality. Thryduulf (talk) 10:40, 14 April 2022 (UTC)
- @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)
- @Sdkb: If so, couldn't the page be noindex'ed? ― Qwerfjkltalk 21:00, 2 April 2022 (UTC)
- I mark any cross-namespace redirect as egilible for speedy deletion. - CafeGurrier66 (talk) 09:58, 4 April 2022 (UTC)
- @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)
- Support, assuming Sdkb's concerns are able to be overcome. It feels like there should be a way to exempt pages from the NV search, and if there isn't, it should be a feature added to New Vector. I support the idea, since there's no reason a reader or editor would be harmed by Main Page/sandbox redirecting. Also, the talk page is Talk:Main Page, not Wikipedia talk:Main Page, so Main Page/sandbox feels more consistent. — Mcguy15 (talk, contribs) 21:09, 12 April 2022 (UTC)
- Oppose Having Main Page/sandbox redirect to Wikipedia:Main Page/sandbox isn't the same thing as having both Main Page and Wikipedia:Main Page. Typing "Wikipedia:" at the beginning of any Wikipedia namespace page has been standard (at least since before I signed up). Cross-namespace redirects are superfluous to the redirects that we already use for the Wikipedia namespace (such as WP:MP and WP:SB. If we're going to make more redirects to Wikipedia:Main Page/sandbox then it should probably be something like WP:MP/SB or simply WP:MPSB. But a cross-namespace redirect isn't it and is just an excuse to make more cross-namespace redirects.—Mythdon (talk • contribs) 05:15, 15 April 2022 (UTC)
- Also invoking IAR should be a matter of common sense and doesn't need to be laid out as an exception in any Wikipedia policy/guideline. "If a rule prevents you from improving or maintaining Wikipedia, ignore it." itself covers every exception to Wikipedia policy to involves IAR. Ignoring rules to improve or maintained Wikipedia is something that should be broadly construed and each and every exception doesn't need to be explicitly mentioned. This proposal is more or less pedantry in that it seeks process just for the sake of process. There's no need to fix what's not broken or try to rewrite policy over a proposal that is itself pedantic and based purely on semantics.—Mythdon (talk • contribs) 05:15, 15 April 2022 (UTC)
- Oppose because 1. That is not what IAR is and 2. Why hasn't anybody created WP:MPSB yet? Let me do that right now casualdejekyll 05:53, 15 April 2022 (UTC)
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)
- 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)
- There is also already a place for new/inexperienced users to seek a mentor (WP:AAU). 331dot (talk) 15:22, 2 April 2022 (UTC)
- 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)
- 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)
- There is also now WP:Growth Team Features, with mentors. Happy Editing--IAmChaos 04:49, 4 April 2022 (UTC)
- 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)
- 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)
- 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)
- 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)
See meta:IP Editing: Privacy Enhancement and Abuse Mitigation for where developers are actually looking to take things. It's no use talking about other ideas here. Uncle G (talk) 07:08, 9 April 2022 (UTC)
- That's really a different issue, though it may result in a change to the level of IP vandalism which requires us to rethink our approach to allowing IP edits. Of course, if we choose to prevent anonymous editing altogether, the fancy new software to obscure IP addresses will never execute. Certes (talk) 12:16, 9 April 2022 (UTC)
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)
- Not what Wikipedia is for. AndyTheGrump (talk) 18:47, 2 April 2022 (UTC)
- @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)
- 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)
- 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)
- 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)
- @AndyTheGrump: To be fair, there are a shitload of arguments here about music genres, and even a special warning template for people who change them without citations. It's certainly one of the things Wikipedia is for... jp×g 06:53, 11 April 2022 (UTC)
- Citing what actual experts say about genre (such as musicologists and music journalists) is useful at Wikipedia. Vanishingly close to 0% of the actual edits to articles that add or change genres to music articles actually bother to do so. --Jayron32 13:37, 12 April 2022 (UTC)
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)
- 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)
- @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)
- 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)
- 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)
- 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)
- OOOOO. Me likey. Glad I saw this thread. --User:Khajidha (talk) (contributions) 12:35, 13 April 2022 (UTC)
Resonant trans-Neptunian objects[edit]
Follow up at CFD as needed. — xaosflux Talk 11:05, 14 April 2022 (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 think those categories are misnamed.
- "category:1:3 resonance" should be "category:1:3 resonance with Neptune"
- "category:1:4 resonance" should be "category:1:4 resonance with Neptune"
- "category:1:6 resonance should be "category:1:6 resonance with Neptune"
- "category:1:9 resonance" should be "category:1:9 resonance with Neptune"
etc.
There are many resonances in the universe, those categories only apply to resonance with Neptune.
Perhaps, the is a wrong place for this discussion.
--Io Herodotus (talk) 14:24, 12 April 2022 (UTC)
- @Io Herodotus: feel free to list at Wikipedia:Categories for discussion. — xaosflux Talk 15:02, 12 April 2022 (UTC)
- Thank you. --Io Herodotus (talk) 15:12, 12 April 2022 (UTC)
Making the post-move message more concise[edit]
Hi there! I propose changing the current post-move message
from:
The page "$3" (links | edit ) has been moved to "$4" (edit | history | links | revert | log) (move log)
![]() | Please clean up after your move:
|
to:
The page "$3" (links | edit ) has been moved to "$4" (edit | history | links | revert | log) (move log)
![]() | Please clean up after your move:
|
This change:
- removes the note about double redirects. Multiple bots already work to fix this task automatically; see this section. Per WP:BOTDEF,
After launching the bot, an assumption can be made that there is no further need for human decision-making.
- removes the non-free fair use rationale note. Per the non-free use rationale guideline,
A redirect pointing to the page where the non-free content is intended to be used is acceptable as the article name in the non-free use rationale. If an article is...renamed later on, there is no need to update the fair use rationale
(trimmed). - tweaks the link to the disambiguation fixer to change to an interwiki link, to avoid using an external link. This is an almost-cosmetic edit.
This change makes the template more concise, and reduces banner blindness by only showing the most crucial messages. A diff of the changes can be viewed here. Thank you for your consideration! 🐶 EpicPupper (he/him | talk) 22:00, 14 April 2022 (UTC)
- Concise is good, but I've a couple of concerns. As the last line notes, moving a page can be a prelude to reusing the old title ($3) for another page such as a dab. In that case, we do want to fix the rationales and the double redirects, which would otherwise lead to the new page on a different topic. Certes (talk) 22:12, 14 April 2022 (UTC)
- That's a good point. I would also support moving the two pages under a "if you're turning it into a double redirect" bullet point if needed, e.g.
- If you turn "$3" into a disambiguation page or into a redirect that targets a disambiguation page:
- (disambiguate links)
- (fair use)
- (double redirect) 🐶 EpicPupper (he/him | talk) 02:05, 15 April 2022 (UTC)
- If you turn "$3" into a disambiguation page or into a redirect that targets a disambiguation page:
- That's a good point. I would also support moving the two pages under a "if you're turning it into a double redirect" bullet point if needed, e.g.
Make New Vector the default skin[edit]
NON-VIABLE IN THIS FORM | |
As Curbon7 says, someone could create a viable proposal for this idea, but this isn't it. Closing now before it becomes a timesink. CafeGurrier, please read WP:RFCBEFORE, which generally applies here even if you didn't label this as an RfC. Please also read WP:NOTAVOTE. More generally, please consider spending some more time familiarizing yourself with the community before diving in with WP:CENT-worthy proposals. -- Tamzin[cetacean needed] (she/they) 23:15, 15 April 2022 (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.
Some Wikimedia projects and Wikipedias uses the new Vector by default, should we have the new Vector set by default in the English Wikipedia. - CafeGurrier66 (talk • contribs) 19:14, 15 April 2022 (UTC)
- @CafeGurrier66: just to clarify, default for ip editors and new editors? or for all users regardless? – robertsky (talk) 19:23, 15 April 2022 (UTC)
- For all users, like in MediaWiki. Furthermore, it still can be changed in the user preferences. If you support, type in #Support if not, type in #Oppose. - CafeGurrier66 (talk • contribs) 19:29, 15 April 2022 (UTC)
Survey[edit]
- Oppose – "Legacy" Vector has the advantage of using the right side of the screen for content, rather than inserting a sidebar like ad-infested websites do. If this changes then I'll just change it back in my preferences, but unregistered editors don't have this ability and occasional editors may not find it. Certes (talk) 22:41, 15 April 2022 (UTC)
- Oppose Our friends over at French Wikipedia and a few other language projects have new vector enabled by default, so this could be a legitimate proposal if built correctly. However, I think the current proposal is skipping way too many steps to be tenable. Such a fundamental change likely needs pre-discussion to hash out elements like what specific wording will be used; seeing as the current proposal is incredibly confusing, it's obviously that hasn't happened yet. I would not necessarily be opposed in principle to this proposal in the future (though I would still oppose as I find new vector to be unwieldy), but there are a lot of steps still needed to get this to the point of broad community discussion. Curbon7 (talk) 23:02, 15 April 2022 (UTC)
Discussion[edit]
My attitude to change is very much of the "if it ain't broke then don't fix it" school. Could someone please tell us what is broke in the current default, and how this proposal fixes that? Please note that I do not accept that the statement, "some Wikimedia projects and Wikipedias uses the new Vector by default", contributes anything useful to this discussion. Phil Bridger (talk) 21:01, 15 April 2022 (UTC)
- The Desktop Improvements project should probably be notified of this discussion. 🐶 EpicPupper (he/him | talk) 21:38, 15 April 2022 (UTC)
- To those who feel the need to change things… please change broccoli. Blueboar (talk) 22:49, 15 April 2022 (UTC)
"Sibling networks" definition[edit]
I’ve seen various television network pages having related networks featured on the infobox, but is there any sort of definition or requirements that these should be added. With some of Warner Bros. Discovery-owned television networks, there hasn’t been any clear guidelines for what should be listed there since it’s combining two companies that own a lot of networks that some of them overlap in the genre or theme that the networks have, which can cause some confusion. Hopefully any input here can clarify everything. Thanks Paramount1106 (talk) 02:19, 16 April 2022 (UTC)