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 clear consensus to remove the portal links from the top banner and center-justify the Welcome to Wikipedia message (1) and to move the link to the portals contents page to the Other areas of Wikipedia section lower on the Main Page (2). Some editors expressed a concern about the wording of "Content portals – A unique way to navigate the encyclopedia" as part of 2. There was enough support in the RfC that this language can be used when initially implementing these results, but further discussion/editing may lead to superior wording (with no subsequent RfC required to change it).
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)[reply]
Should the proposal to change portal links on the Main Page described below be adopted? {{u|Sdkb}}talk and JBchrchtalk 01:19, 15 March 2022 (UTC)[reply]
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.
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
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
Top banner proposal: portals links removed and language switcher added
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. JBchrchtalk 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- 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. CaptainEekEdits 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. SeraphimbladeTalk 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]
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. JBchrchtalk 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:
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.
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]
SupportGood 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]
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)[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 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]
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)[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]
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, 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]
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)[reply]
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)[reply]
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)[reply]
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. — Goldencall me maybe? 10:33, 13 April 2022 (UTC)[reply]
Discussion (Portal links)
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]
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)[reply]
@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]
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)[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.
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]
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)[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]
@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)[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]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
Oppose because "Meh". --Jayron32 12:49, 21 April 2022 (UTC)[reply]
Support The deletion policy clarified that redirects from mainspace to Wikipedia namespaces are not egilible for speedy deletion. - CafeGurrier66 (talk • contribs) 09:41, 22 April 2022 (UTC)[reply]
Diff colours
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. — xaosfluxTalk 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]
Follow up at CFD as needed. — xaosfluxTalk 11:05, 14 April 2022 (UTC)[reply]
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.
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.
combines the notes regarding non-free fair use rationales and disambiguation links, making them more concise and precise to the exact case where fixing is needed (a change in the content of a page).
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. Protected double redirects can be fixed through human decision making later on through Special:DoubleRedirects or a database query.
Makes the non-free fair use rationale note more precise. 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. removes the link to the disambiguation fixer as it is often down and fixing the links manually or via another semi-automated tool like AutoWikiBrowser or JWB is enough.
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. See this 2020 post for more context and an earlier proposal. Thank you for your consideration! 🐶 EpicPupper(he/him | talk) 22:00, 14 April 2022 (UTC)[reply]
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)[reply]
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:
General support, provided that Certes' concerns and any others others bring up are addressed. This is another good opportunity to address banner blindness. Ideally, I'd like to see it adapt to the particular circumstances of a given move: e.g. include a message about subpages only if there are actually subpages (and if so, say "there are subpages" rather than "there might be subpages"). {{u|Sdkb}}talk 14:00, 18 April 2022 (UTC)[reply]
The subpage idea is interesting, but unfortunately I think that's not possible to do in wikitext or Lua AFAIK. 🐶 EpicPupper(he/him | talk) 18:40, 19 April 2022 (UTC)[reply]
Restructure the last point. Yes, a rewrite of this message was definitely needed. However, the greatest need for change is in the last point: currently, it's restricted to the case of dab pages, which is only one subset and where we already have several layers of redundancy in the mechanisms for tracking and dealing with the links. What we need instead is more general advice that will also cover the ground that we can't otherwise easily observe (all changes of primary topic that don't involve moving a dab to the base title: like, moving a dab away from the base title, making one article primary instead of another, turning the old title into a redirect to a different place, etc.). The clean-up work that all of these cases entail is: 1) checking all incoming redirects (and ideally, links) and retargeting as appropriate – otherwise, these can end up pointing to the wrong page; and 2) updating any fair-use rationales – otherwise these would break. When do these actions need to be performed? Certes above is on the right track. What all these cases have in common is that the old title will become something other than a redirect to the moved page. So how about Unless "$3" remains a redirect to the moved page, make sure the incoming redirects and links point to the correct target, and update fair use rationales if there are any.? – Uanfala (talk) 17:52, 19 April 2022 (UTC)[reply]
Agreed, I think this is an elegant way of framing it. Colin M (talk) 18:21, 19 April 2022 (UTC)[reply]
Thanks for the feedback! I've tweaked the message based on your feedback. Cheers! 🐶 EpicPupper(he/him | talk) 18:33, 19 April 2022 (UTC)[reply]
I support the broad outlines of this proposed rewrite (though the last bullet still needs some tweaking - I think Uanfala's proposed wording is the best so far). I wonder if it would be worth wikilinking somewhere in the message to WP:RMCI#Cleaning up after the move, since it goes into a lot more detail on post-move cleanup procedures, with examples and some further corner cases (though it does suffer from some awkwardness and bloat of its own). Colin M (talk) 18:26, 19 April 2022 (UTC)[reply]
Thanks! I've added the link at the top. 🐶 EpicPupper(he/him | talk) 18:37, 19 April 2022 (UTC)[reply]
Oh, yes, a pointer to the more detailed documentation is definitely a good idea. I do agree that that documentation needs work: it's split, unreasonably, between WP:POSTMOVE and WP:RMCI#Cleaning up after the move, and it's a bit hairy in places. – Uanfala (talk) 19:08, 19 April 2022 (UTC)[reply]
Make New Vector the default skin
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)[reply]
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)[reply]
@CafeGurrier66: just to clarify, default for ip editors and new editors? or for all users regardless? – robertsky (talk) 19:23, 15 April 2022 (UTC)[reply]
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)[reply]
Survey
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)[reply]
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)[reply]
Discussion
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)[reply]
To those who feel the need to change things… please change broccoli. Blueboar (talk) 22:49, 15 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.
"Sibling networks" definition
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)[reply]
I think, in general, just rely on the same terminology at use in your source texts. If source texts widely describe two entities as "sibling networks", and the evidence is clear that the usage is widespread and commonplace, then feel free to do the same for those two entities. If the terminology is not widely used, or even more relevantly, if you can't find clear and abundant examples describing two specific networks that way, don't use the terminology. --Jayron32 14:37, 20 April 2022 (UTC)[reply]
So you're a child and want to look up Anaheim, California because Disneyland. You go to Wikipedia on your mobile device, enter "ana" in the search box and are instantly presented an image of a penis in an anus. That's.. rather inappropriate. The issue has been reported on Phabricator, but you know the response time of the WMF is typically measured in years. Maybe the thumbnails can be disabled with a configuration change, but if not there's always CSS. See screenshot for an example, the file page description has some CSS to play with. Proposal: we disable thumbnails in ajax search results where we can until the search learns to respect MediaWiki:Bad image list. — Alexis Jazz (talk or ping me) 17:22, 18 April 2022 (UTC)[reply]
Wait, you want us to make a local script-hack to disable all images on search results? No thank you, follow up at phab. — xaosfluxTalk 17:41, 18 April 2022 (UTC)[reply]
Xaosflux, if there's configuration option for this that would be used instead, but if there isn't, well, what other way is there? And hey, when phab:T306246 is resolved it can be re-enabled. Maybe enwiki disabling it will make the WMF developers work harder on it. If the WMF didn't have a reputation for routinely ignoring tasks this proposal likely wouldn't exist. If the WMF committed itself to resolving the task in a matter of days, this proposal wouldn't be needed too badly, but I don't see that happening. The way I see it, this would be a deployment blocker for this feature if it had been caught sooner. Typing three letters in a search box should never result in NSFW pictures unless you're on a porn site. — Alexis Jazz (talk or ping me) 18:11, 18 April 2022 (UTC)[reply]
If those images aren't encyclopedic, they can be fixed editorially - no? The bad image list is designed to stop vandalism, not as some sort of "NSFW" content filter; though I do think that possibly integrating with MediaWiki:Pageimages-denylist could be useful, but that also isn't meant to be some sort of "NSFW" filter. — xaosfluxTalk 18:35, 18 April 2022 (UTC)[reply]
Of course, these are just my initial thoughts - if a community consensus to not use images on this page emerges we can further explore technical options. — xaosfluxTalk 18:36, 18 April 2022 (UTC)[reply]
@Alexis Jazz: Correct me if I'm wrong, but isn't the solution as simple as transcluding {{MediaWiki:Bad image list}} into MediaWiki:Pageimages-denylist? Or does the extension not parse the page before grabbing the list of images? --Ahecht (TALK PAGE) 20:18, 18 April 2022 (UTC)[reply]
a) it doesn't work like that; b)the search results doesn't seem to be using 'pageimages-denylist' (since it doesn't seem to be using the pageimages utility). — xaosfluxTalk 20:23, 18 April 2022 (UTC)[reply]
@XaosfluxIf you say it's not using pageimages I'll believe you, but if it were why wouldn't it work like that? Looking at the source of pageimages, it's doing a dbquery to get the pagelinks from the denylist, which should include any links in transcluded templates. --Ahecht (TALK PAGE) 20:53, 18 April 2022 (UTC)[reply]
@Xaosflux As a follow-up, per the source of MobileFrontend, it looks like it's asking the API for the pageimages property of the search results, which is supplied by the pageimages extension. --Ahecht (TALK PAGE) 21:23, 18 April 2022 (UTC)[reply]
I was misled by some of the phab comments! — xaosfluxTalk 23:37, 18 April 2022 (UTC)[reply]
Frankly, the image quality on those thumbnails is so embarrassingly bad (since they take a low-resolution thumbnail and stretch it to the height of each row) that disabling them makes the search results look SO much better and more professional. --Ahecht (TALK PAGE) 19:56, 18 April 2022 (UTC)[reply]
Partial Support We should have an option to disable thumbnails in the user preferences. - CafeGurrier66 (talk • contribs) 13:01, 22 April 2022 (UTC)[reply]
This is primarily a reader-facing item, and most readers don't have "preferences" to set. — xaosfluxTalk 13:11, 22 April 2022 (UTC)[reply]
Commented at the Phabricator task. I like the images in search results, so I don't want to see them go away, but this should absolutely be a blocking issue. {{u|Sdkb}}talk 21:20, 23 April 2022 (UTC)[reply]
Wikipedia Needs to Support Ukraine
OP blocked, nothing to see here--Jayron32 14:35, 20 April 2022 (UTC)[reply]
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.
As we all know, there is currently a terrible war in Ukraine. I think that the Wikipedia should immediately change the colour scheme of it's layout to Blue and Yellow (These are the two colours on the flag of Ukraine, for those who may be unaware) in support of Ukraine. What do you all think? The140IQProfessor (talk) 19:12, 18 April 2022 (UTC)[reply]
As much as I agree that support on ukraine is needed, Changing the cholor scheme is way too much of a change, and wikipedia is designed to be neutral. On wikipedia, we do not choose "Sides" of anything, We simply list the facts, no matter what they are. Also a color scheme change would require a LOT of program adjustments and would be too complicated. PerryPerryDTalk To Me 19:21, 18 April 2022 (UTC)[reply]
Bawl with the background set to File:Flag of Ukraine.svgThe140IQProfessor, seems like a bit too much, but I actually thought about something along these lines for my script, Bawl. Essentially because of this I added a custom background option to show your support for something. Originally it was going to be just the flag of Ukraine, but being customizable made more sense in the end. Set Flag_of_Ukraine.svg as the background image in the options and you'll get this. (see image) — Alexis Jazz (talk or ping me) 19:47, 18 April 2022 (UTC)[reply]
I think that people need to stop trying to rebrand Wikipedia as a soapbox, no matter how strong, and seemingly justifiable, their moral conviction is. 65.88.88.93 (talk) 20:27, 18 April 2022 (UTC)[reply]
Many people on Wikipedia have been actively supporting Ukraine recently. Myself and numerous others I know of have been prolifically active in improving content related to Ukrainian culture, people and topics. This is a venue that is quite literally available to everyone, and results in meaningful content being made! Perhaps explore this route, rather than imposing personal guilt onto others. Aza24 (talk) 20:40, 18 April 2022 (UTC)[reply]
The TS has been blocked as a sock, so I do not think we should discuss this seriously.--Ymblanter (talk) 20:47, 18 April 2022 (UTC)[reply]
Also we literally just went through this kit-and-caboodle a few weeks ago with the Signpost "scandal" lol. Curbon7 (talk) 11:54, 19 April 2022 (UTC)[reply]
Oppose: @The140IQProfessor: Also, you are already blocked as you are clearly not here to contribute to build the encyclopedia. - CafeGurrier66 (talk • contribs) 10:41, 20 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.
We should find a way to increase awareness of internet addiction among Wikipedians
Wikipedia can be addictive. Have you ever felt that you missed something important to do, just because of an article or a discussion at WP. Internet addiction and more specifically WP addiction as a big issue and we should inform and protects ourselves and others. By what means, I can not tell. Maybe ask for expert advice as a community. Let 's talk about it. Do you fell it is an issue we should be concerned? I think if we find a way to increase awareness, it would be an important step that highlights we are a community and even we do not know each other, we care. Cinadon36 10:16, 19 April 2022 (UTC)[reply]
I've been kind of back into my Wikiholism and doing virtually nothing else lately; Wikipedia is like a vacuum you get sucked into. So much to get caught up in, between editing articles, fighting vandalism, keeping up with policies/guidelines and participating in discussions, that it just sucks you in. The time I've spent on Wikipedia lately is time I'd normally spend watching videos or playing video games. Not sure when or how I'm going to come out of it, but Wikipedia addiction is most definitely a thing and I haven't been this addicted in awhile. —Mythdon (talk • contribs) 11:02, 19 April 2022 (UTC)[reply]
Very ironic timing as I am currently on Wikipedia procrastinating from doing an online exam lol. Curbon7 (talk) 11:04, 19 April 2022 (UTC)[reply]
In seriousness, it seems like an ebb-and-flow thing for me. This month I've been chilling with edits, but in February I was definitely spending way too much time on here. To some extent it probably has something to do with seasonal affective disorder, as now that it's warm and bright out I haven't been editing as much, though I'm still active daily. Curbon7 (talk) 11:07, 19 April 2022 (UTC)[reply]
Wikipedia itself is not for increasing awareness of any topic, which is considered promotional, even for good causes. (anti-suicide measures have been proposed before) WP:RGW is also relevant. There may be ways to work with the Foundation on this topic. 331dot (talk) 11:05, 19 April 2022 (UTC)[reply]
This could be something interesting to toss to the researchers if they haven't done this before, but yeah this is not in-scope for this page. Curbon7 (talk) 11:10, 19 April 2022 (UTC)[reply]
We have an article on Internet addiction disorder… which is marked as needing more work. I would suggest that a great way to make people aware of the issue (one that IS within the scope of WP) would be to improve that article. Blueboar (talk) 11:47, 19 April 2022 (UTC)[reply]
This is very true. I have my board and joint just round the corner. They happen to be the most important exams in a students life here. Even the slightest bad performance there sends you into a black hole, as you can't get into cheaper goverment colleges,(many aspirants, less vacancies) and have to spend millions in private colleges, whose affordability is somewhat difficult for our family. Yet, here I am, addicted to Wikipedia, replying to a random VPPR. —CX Zoom[he/him](let's talk • C • L) 11:48, 19 April 2022 (UTC)[reply]
So awareness of internet addiction is best pursued by posting on the internet? Let's have a smoke while discussing addiction to tobacco. 71.247.146.98 (talk) 12:00, 19 April 2022 (UTC)[reply]
This is totally wrong. "Have you ever felt that you missed something important to do, just because of an article or a discussion at WP" - no, never, why or how? If there is something more important to do just leave Wikipedia and start doing it otherwise it's serious mental problem not related to Wikipedia. Leave mental problems for hospitals. If you ask questions about "addiction disorder" in such a way this is trivializing the problem of addiction disorder so should footbal stadiums help to increase awareness of footbal addiction among footbal fans or should television help to increase awareness of television addiction among audience? Eurohunter (talk) 12:16, 19 April 2022 (UTC)[reply]
Casinos aren't in the mental health business, nor should they. Yet casinos offer information about gambling addiction. Maybe for some, the important step of recognizing the problem, needs to come from the source of the addiction. (says someone who scored a 163 on this test) --DB1729 (talk) 14:05, 19 April 2022 (UTC)[reply]
Thanks for your comments friends, but I would like to clarify that I wasn't talking about raising awareness among general public, which would be against WP policy. I am suggesting we introduce something (a policy or a guideline maybe?) for healthy editing. Like a rule of conduct, maybe just like Wikipedia:Civility. Cinadon36 13:43, 19 April 2022 (UTC)[reply]
Have you ever seen something like this in any book, television, zoo, gym or whatever? Leave individual mental problems for hospitals. Eurohunter (talk) 14:16, 19 April 2022 (UTC)[reply]
Mental health has quite a range, and most of the situations do not need a hospital. Have you ever heard of a frustrated person counting to 10 before replying? That's a mental health strategy. Do you go for a walk outside when you're having a bad day? Mental health strategy. Watch a funny movie when you're feeling down? Mental health strategy.
@Cinadon36, the "story" about internet addiction changes every few years. The newest version is that internet addiction is a symptom, not a disease. That means that (for example) depressed people want to spend all of their leisure time watching videos, not that watching videos makes you depressed. This makes sense: YouTube will autoplay a stream of videos, and you don't have to go to any effort. However, that doesn't help your mental health as much as positive interactions with other people would.
To use a more Wikipedia-specific example, if you are feeling "addicted", it can be useful to figure out whether you're getting sucked into the outrage machine (turning into "our most moralistic and least reflective selves", in the words of this recent article). If you are, you might have a happier life if you spend less time on things like reverting other people's efforts, getting into arguments on talk pages, or trying to enforce rules, and more time on building something that interests you and you find to be pleasant (e.g., clearing out a small backlog, making sure your favorite subjects have decent articles, or encouraging editors). WhatamIdoing (talk) 23:39, 20 April 2022 (UTC)[reply]
Thanks @WhatamIdoing: for your input. I feel addiction is a problem that some wikipedians have, and lots of them at are risk. They can be a manifestation of an underlying disease, or it can appear in an otherwise healthy individual. The "DSM-IV-TR Criteria for Substance Abuse and Substance Dependence" can be found here. [4]. In any case, my proposal was based on the idea that we have a moral responsibility to care for each other, and protecting each other from addiction could be useful. It is like saying to your loved one: "hey mate, you are too much consumed on this issue, are you ok?" How we do this, if we decide to act, we should first consult the experts. But unless we act, it is like WP is becoming a thing, that is produced based on mental illness. The analogy could be diamonds, that are products based on child slavery. As diamond sellers should make sure they do not use slavery, WP should make sure that the final outcome (articles) is not the result of mental health problems, nor any problems were caused during the "production period". Cinadon36 07:14, 21 April 2022 (UTC)[reply]
If someone has a mental health situation, and they use it to improve a Wikipedia article, then why would that be considered a problem? We have editors with mental health conditions such as autism and (actual, not movie-style) OCD. This can lend motivation and focus to their editing, and I have trouble imagining why this would be a problem. If you really like having all the Star Wars articles properly categorized or ordered into a list, then what's the problem with that? We'd never tell an editor, "Oh, hey, sorry, your desire to set up a logical cat structure is at least partly motivated by a mental health situation, so you're not allowed to help out with something that we all agree needs to be done. You sit on the side lines and watch while the rest of us slog through this tedious work that you'd be very happy to do." That would be both discriminatory against the editor and ineffective for the project.
There are some limits. Someone wrote Wikipedia:Wikipedia is not therapy many years ago, because we sometimes have people who are trying to use Wikipedia as an actual type of medical treatment. They might be practicing their computer skills (a type of Occupational therapy) or practicing social skills by contacting other editors. If, and only if, this activity is disruptive (e.g., they keep accidentally vandalizing articles), then we block them even if they say "but I need to keep editing for my health program!" This is really rare, though. WhatamIdoing (talk) 19:38, 21 April 2022 (UTC)[reply]
We have an article on this already, Problematic social media use. Social media addiction is a thing, and Wikipedia, despite WP:NOTFACEBOOK is social media. [5][6][7] I'm not saying there's really anything that can be done about it here, but to act like it's some bonkers thing is bonkers in and of itself. To say things like no, never, why or how? If there is something more important to do just leave Wikipedia and start doing it is to ignore the psychological effect of addiction. Many places and products that are addictive have signage and programs to help those with problems, so it's not a wild idea that's never been heard of. ScottishFinnishRadish (talk) 14:21, 19 April 2022 (UTC)[reply]
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.
Xayahrainie43 is too long to type and remember, I proposed to create a short-cut for them as WP:LTA/X43, this name came from Chinese wikipedia and also used on meta-wiki for SRG. PAVLOV (talk) 09:43, 20 April 2022 (UTC)[reply]
Not every sock master is an LTA. And LTA pages should by and large be deprecated. CUPIDICAE💕 12:24, 20 April 2022 (UTC)[reply]
Support. This will be helpful for hard and/or long usernames. - CafeGurrier66 (talk • contribs) 16:17, 20 April 2022 (UTC)[reply]
I can't think of any potential conflicts or confusions. If you think it's the most appropriate shortcut, I'd say just go ahead and add it. -- zzuuzz(talk) 16:36, 20 April 2022 (UTC)[reply]
Done Thanks a lot for approval. PAVLOV (talk) 16:58, 20 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.
Fortis and lenis are both terms that have inconsistent definitions and are rarely used in comparison to voiced/voiceless in every context, it seems, other than Wikipedia pages for phonology; this is needlessly confusing and voiced/voiceless should be enforced over them. There are two different reasons one may argue against this proposition. Firstly, one might say that fortis and lenis mean voiced and voiceless themselves. In this case, fortis and lenis, as the rarer terms, should not be used for the sake of recognition. Otherwise, one may propose an alternative definition for fortis and lenis; it is the strength of a consonant, or the length, possibly something even more exotic. These simultaneous arguments, when viewed together, show why this fails; there is no consistent definition of fortis and lenis! In fact, there exist consonant inventory tables which use fortis and lenis in place of voiced and voiceless, despite the fact that plenty of pages for phonology, including Portuguese phonology and Spanish phonology, are entirely comprehensible without mentioning either word once, even in their many sources. In conclusion, fortis and lenis are dated and ambiguous terms that should be replaced with voiced and voiceless. Additionally, I might add that unvoiced should be replaced with voiceless in every linguistic context due to the fact that they are synonyms and voiceless is much more prevalent, but this proposition is not relevant at the moment. (This has been moved to Wikipedia talk:WikiProject Linguistics#Standardise voiced/voiceless over fortis/lenis)
(I'm not sure if this is a proposal or a policy suggestion) — Preceding unsigned comment added by 169.241.63.173 (talk) 18:25, 21 April 2022 (UTC)[reply]
Ok, should I remove it from here once I post it there? 169.241.63.173 (talk) 20:35, 21 April 2022 (UTC)[reply]
Yes, you can just copy your post to Wikipedia talk:WikiProject Linguistics, and then either remove the whole of this thread here or leave it in place with a pointer to the other discussion. – Uanfala (talk) 21:56, 21 April 2022 (UTC)[reply]
Top banner proposal: portals links removed and language switcher added
02:00, 15 March 2022 (UTC)
Support ― Qwerfjkltalk 07:05, 16 March 2022 (UTC)
The page "$3" (links | edit) has been moved to "$4" (edit | history | links | revert | log) (move log)
