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

Seconded. I've almost created quite a few such errors using JWB etc. DPL bot may be a useful model: it issues a polite user warning when we link to disambiguation pages. Certes (talk) 10:28, 4 April 2022 (UTC)

@Certes, I presume that Dicklyon is referring (correct me if I'm wrong) to mw:Help:Extension:Disambiguator, which is even better than DPL bot, as it alerts you in real time. ((u|Sdkb)) ^talk 04:24, 5 April 2022 (UTC)

Both might be useful. An immediate alert in WikiEditor is a good idea and should reduce such errors in manual editing. I assumed from the term "bulk" that Dick's suggestion applied instead to errors created with tools such as AWB and JWB, where editors might preview just a sample rather than every page, and possibly by bots. Unless we're going to change that software then an alert after the fact may be the best we can do there (but see xeno's filter comment below). Certes (talk) 10:26, 5 April 2022 (UTC)

Is this covered at all by WP:Edit filter/Requested/Archive 13#File name changes? –xeno^talk 14:56, 4 April 2022 (UTC)

This is another excellent idea for how to apply the pop-up box framework. I've discussed it before with @NRodriguez (WMF) and the community at Wikipedia:Village pump (technical)/Archive 194#Adding a new edit filter trigger action: pop-up box. More work is needed on the technical end before this will be ready, but it would be fantastic, so I really hope it gets taken on. ((u|Sdkb)) ^talk 04:26, 5 April 2022 (UTC)

I think both the realtime pop-up and the after-the-fact notification would be useful. I was thinking more of the lattter, for AWB or bot edit error catching. It's easy to fix after the fact if the errors are noticed (e.g. by another small AWB batch for a commonly used filename that got messed up in a big batch; I've done this for errors someone noticed, but then that someone is already annoyed). Dicklyon (talk) 18:44, 5 April 2022 (UTC)

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

Why should we care whether out articles are translated into other languages? This is the Hindi Wikipedia's issue, not ours. * Pppery * _{it has begun...} 20:53, 31 March 2022 (UTC)

This would be best done on the destination wiki, most people that come across our article are unlikely to be able to write in the foreign language. Check out wikidata:Q13308814 for some examples of "requests for translation" on other projects. — xaosflux ^Talk 21:10, 31 March 2022 (UTC)

Some Wikipedias have a page to request articles, not necessarily as translations; we have Wikipedia:Requested articles, and the matching page at Wicipedia Cymraeg is Erthyglau a geisir, where I once made this request, despite not speaking that language. Just over three years later, I was rewarded with Deddf Cynulliad Cenedlaethol Cymru (Ieithoedd Swyddogol) 2012. --Redrose64 🌹 (talk) 21:05, 1 April 2022 (UTC)

For an article which isn't going to have huge readership in another language, I generally think running the English-language article through Google translate would work best (assuming translation to and from your language works OK, I don't know if that's the case). English language articles are much more frequently updated than other languages in many cases, I've seen cases where a translation preserved the content of an article exactly as it was in say 2019, the article has been massively expanded since and the foreign-language article has stagnated with no improvements. Google translate on the English article is more likely to be up to date. Blythwood (talk) 04:10, 6 April 2022 (UTC)

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)

It would increase vandalism, not reduce it. Vandals could use throwaway email addresses to obtain accounts over and over. 331dot (talk) 23:46, 2 April 2022 (UTC)

There is also now WP:Growth Team Features, with mentors. Happy Editing--IAmChaos 04:49, 4 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)

I thought this was more than a proposal- that they were doing it(the IP thing). 331dot (talk) 01:11, 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)

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)

@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)

@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

html.client-dark-mode * {
  text-shadow: 0 0 0;
}

to your common.css. Let us know on the linked thread if it works. – SD0001 (talk) 08:13, 11 April 2022 (UTC)

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)

@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)

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)

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)

@Certes: de:Benutzer:Schnark/js/diff allows you to switch between colour schemes fairly easily. ― Qwerfjkltalk 09:41, 7 April 2022 (UTC)

Thanks, I'll try that out! I'm already using Schnark's excellent Search++. Certes (talk) 10:02, 7 April 2022 (UTC)

OOOOO. Me likey. Glad I saw this thread. --User:Khajidha (talk) (contributions) 12:35, 13 April 2022 (UTC)

The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.

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)

---

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)

Notified: WP:CENT, WT:Main Page, WT:Usability, WT:PORT. ((u|Sdkb)) ^talk 01:19, 15 March 2022 (UTC)

Background

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

We propose the following related changes:

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

• Mockups
• 
  Top banner proposal: portals links removed and language switcher added
• 
  Proposed addition of portals contents link to ((Other areas of Wikipedia))

Best, ((u|Sdkb)) ^talk and JBchrch talk 01:19, 15 March 2022 (UTC)

Survey (Portal links)

• 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 Wolf^Talk_{Blaze 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)

• 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:
  1. If we put a language button in such a prominent location, we should remove the 'Wikipedia languages' section at the bottom of the page, to avoid duplication.
  2. The 'unique way' wording is poor and uninformative. I would prefer something like 'browse by topic' or 'content organised by topic' (though the latter has ENGVAR issues).
  3. Implementation clearly has to wait until the language button has been thoroughly tested and is ready for millions of users. The page on Meta still refers to May 2021 as if it's in the future, so is presumably very out of date.

Modest Genius ^talk 13:12, 15 March 2022 (UTC)

• 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)

• 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)

• 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)

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 Wolf^Talk_{Blaze 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 Wolf^Talk_{Blaze Wolf#6545} 15:00, 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)

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)

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)

• 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)

• 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)

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.

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)

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)

Moved to Wikipedia talk:WikiProject Linguistics § Standardise voiced/voiceless over fortis/lenis

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)

I think this proposal would be better suited to a specialised venue, such as Wikipedia talk:WikiProject Linguistics, rather than a general-interest one such as this. Phil Bridger (talk) 18:42, 21 April 2022 (UTC)

Ok, should I remove it from here once I post it there? 169.241.63.173 (talk) 20:35, 21 April 2022 (UTC)

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)

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)

Wait, you want us to make a local script-hack to disable all images on search results? No thank you, follow up at phab. — xaosflux ^Talk 17:41, 18 April 2022 (UTC)

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)

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. — xaosflux ^Talk 18:35, 18 April 2022 (UTC)

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. — xaosflux ^Talk 18:36, 18 April 2022 (UTC)

Xaosflux, the images are encyclopedic (at least this one is), but it's on MediaWiki:Bad image list because "The images and other media files listed on MediaWiki:Bad image list are prohibited by technical means from being displayed inline on pages, besides specified exceptions." By searching for "ana", I see a penis in an anus on Main Page which is definitely not the Anal sex article for which an exception exists. Btw, no hard feelings. I personally feel it would be very irresponsible to wait a for years for the WMF to pick up that task. I created this proposal so at the very least I can say I tried everything within my power. This proposal is not to disable the thumbnails forever, just until the WMF fixes the issue. How long that'll take them is up to them. — Alexis Jazz (talk or ping me) 19:03, 18 April 2022 (UTC)

@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)

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). — xaosflux ^Talk 20:23, 18 April 2022 (UTC)

@Xaosflux If 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)

@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)

I was misled by some of the phab comments! — xaosflux ^Talk 23:37, 18 April 2022 (UTC)

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)

Partial Support We should have an option to disable thumbnails in the user preferences. - CafeGurrier66 (talk • contribs) 13:01, 22 April 2022 (UTC)

This is primarily a reader-facing item, and most readers don't have "preferences" to set. — xaosflux ^Talk 13:11, 22 April 2022 (UTC)

• 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)

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)

@Interstellarity: Redirects from mainspace to Wikipedia, Portal, Category, Template and Help namespaces are already IAR exeptions of this rule so we will close this soon. - CafeGurrier66 (talk • contribs) 11:05, 24 April 2022 (UTC)

• Oppose: A no is a no CafeGurrier66 (talk) 15:33, 2 April 2022 (UTC)
• 1. 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.
  2. If Main page remains in mainspace, it only makes sense that it's subpage-seeming pages also redirect to relevant pages in Wikipedia namespace, and thus I support this proposal.
  ---CX Zoom(^he/_him) (^{let's talk}|_contribs) 16:07, 2 April 2022 (UTC)
• 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)

• 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)
• Oppose because "Meh". --Jayron32 12:49, 21 April 2022 (UTC)
• 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)
• Making a proposal to invoke WP:IAR is 100% the opposite of IAR's purpose. —pythoncoder (talk | contribs) 22:48, 24 April 2022 (UTC)
• Comment It seems to me that Make an IAR exception is almost a contradiction in terms. IAR is about what doesn't get codified, so there is no need to formally codify an exception. Maybe you'd like to reword? There's so much cognitive dissonance from the summary that it gets in the way of considering the actual proposal. --Trovatore (talk) 18:04, 25 April 2022 (UTC)

Hi there! I propose changing the current post-move message

from:

Y The page "$3" (links | edit | delete) has been moved to "$4" (edit | history | links | revert | log) (move log)

Please clean up after your move: Check if the page's categories have a sort key, and update it as necessary. Check and update the magic words DEFAULTSORT and DISPLAYTITLE. $3 Please review the lists of subpages and talk subpages and consider moving them as well. If "$3" does not remain a redirect to the moved page "$4", make sure the incoming redirects and links point to the correct target, and update fair use rationales if there are any.

to: User:EpicPupper/sandbox/Movepage-moved

Additionally, I propose changing the Wikibase post-move message

from:

Your move should now be [$1 reflected in the Wikidata item] language link.

to:

User:EpicPupper/sandbox/Wikibase-after-page-move

This change:

• 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.
• adds a link to post-move cleanup instructions for more information if needed.
• removes the request to check if Wikidata interlanguage links are updated, as this is automated

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)

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)

• 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)

  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)

• 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)
  • See this 2020 post for more context and an earlier proposal. – Uanfala (talk) 17:57, 19 April 2022 (UTC)
  • Agreed, I think this is an elegant way of framing it. Colin M (talk) 18:21, 19 April 2022 (UTC)

  Thanks for the feedback! I've tweaked the message based on your feedback. Cheers! 🐶 EpicPupper ^{(he/him | talk)} 18:33, 19 April 2022 (UTC)

• 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)

  Thanks! I've added the link at the top. 🐶 EpicPupper ^{(he/him | talk)} 18:37, 19 April 2022 (UTC)

  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)

• General support Graham (talk) 04:11, 24 April 2022 (UTC)

I've reverted CafeGurrier66's close to allow for more discussion, see their talk page for context. Cheers, 🐶 EpicPupper ^{(he/him | talk)} 20:00, 25 April 2022 (UTC)

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)

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)

Very ironic timing as I am currently on Wikipedia procrastinating from doing an online exam lol. Curbon7 (talk) 11:04, 19 April 2022 (UTC)

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)

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)

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)

• 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)
• 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)

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)

• 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)

  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)

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)

Good grief. 50.75.226.250 (talk) 14:11, 19 April 2022 (UTC)

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)

I have literally never seen that. ScottishFinnishRadish (talk) 14:25, 19 April 2022 (UTC)

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)

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)

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)

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)

• There is a slightly humorous take on Wikipedia addiction at WP:ADDICTED. Meta has a research project (incomplete, not in English) at Meta:Research:Wikipedian and Internet addiction. If you feel you are addicted, spending too much time on Wikipedia, and need or want to take a WP:WikiBreak, there is a WikiBreak Enforcer script you can use. ~ ONUnicorn^{(Talk|Contribs)}problem solving 14:45, 19 April 2022 (UTC)
• I have User:力/scripts/timeclock.js which people might want to copy and experiment with. User:力 (powera, π, ν) 00:11, 24 April 2022 (UTC)
• Excellent post, Cinadon36, and thank you for making it. We need to pay more attention to this topic as a community. I like the idea of making a page with tips for healthy editing. We could also take a look at some of our processes and see if there's any way we could improve them from a mental-health point of view. Enterprisey (talk!) 21:26, 28 April 2022 (UTC)

I hope I chose the right forum. Presently, WP:Requests for undeletion exhibits a very large notice on top stating that the UNDEL is not the place to request restoration of pages deleted via deletion discussions, and such requests must be made at WP:Deletion review. While not elaborated by the notice, the notice seems to imply to include WP:FFD and the now-axed WP:PUF, as these are deletion discussion areas.

This becomes tricky for requesting restorations of files deleted due to freedom of panorama-related reasons, like cases of freely-licensed images of buildings deleted during the time ((FoP-USonly)) did not exist yet, or rare case of a country introducing commercial-friendly FOP in which deleted files here need to be restored for them to be moved to their almost-permanent home (Wikimedia Commons). For such cases undeletions can be made immediately.

This proposal was suggested by Hobit at Wikipedia:Deletion review/Log/2022 April 25, where I requested the restoration of three files of buildings (two from Cambodia and one from France). Since such discussions at WP:Deletion review can be impractical, as the reason for undeletion is crystal clear, the best option is the allowance of WP:Undeletion requests to accept requests on undeletion of files deleted via FFD and PUF but only for freedom of panorama reasons. This will reduce the bureaucracy on Wikipedia. JWilz12345 (Talk|Contrib's.) 08:14, 26 April 2022 (UTC)

I withdraw this thread. In light of a discouraging remark about me by an IP user at Wikipedia:Deletion review/Log/2022 April 25 (which simply isn't true!), I will no longer pursue this discussion. JWilz12345 (Talk|Contrib's.) 00:59, 27 April 2022 (UTC)

To give some more context for editors who don't know the intricacies of how freedom of panorama (FOP) works on Wikimedia projects: The Wikimedia Commons has a rule requiring that all uploads there be freely usable under the laws of both the United States and the country in which the file was created. The English Wikipedia has a different rule: we only require that content be free under US law. In the United States, photographs of any constructed architectural work (e.g. a building) can be freely distributed under the freedom of panorama rule in copyright law. Because of this, it is acceptable to upload any photograph of a building to the English Wikipedia, even if the building is located in a country that does not have freedom of panorama. According to User:JWilz12345/Deleted no FOP, it seems like there are a number of examples of cases where administrators have deleted photos of buildings on the basis that there was no freedom of panorama in the countries in which they were taken, but because there is freedom of panorama in the United States for buildings, those photos were actually okay to upload on the English Wikipedia (but not to the Commons). It's definitely a bit confusing, but on the whole, I think JWilz12345 has it right, and I am not opposed to their proposal here to make this something acceptable to bring to WP:REFUND. (If only they un-withdraw it...) Mz7 (talk) 02:23, 27 April 2022 (UTC)

I agree, we should make this easier by letting REFUND handle it. It's a good idea. BTW I totally get people throwing up their hands and walking away after a frustrating experience like what they just went through. I hope they come back. In the meantime let's fix this problem they've identified and reduce the frustration factor for others. Levivich 23:53, 27 April 2022 (UTC)

Thanks for some encouragement @Mz7 and Levivich:. I'll reopen my proposal. But from now on I won't request for restoration any deleted images of buildings that I may stumble upon soon, while browsing through PUF requests. The remark by IP has discouraged ne to some degree. I will only request restoration if ever freedom of panorama is introduced in our country, hopefully after the 2022 elections. JWilz12345 (Talk|Contrib's.) 14:48, 28 April 2022 (UTC)

Please don't let one anonymous remark put you off. Any act or idea, however good, will upset one person in seven billion. Certes (talk) 15:02, 28 April 2022 (UTC)

Thanks for the encouragement @Certes:. Now, back to the proposal. In accordance with the proposal, the large notice on top of WP:UNDEL must be modified to read like I suggest or something similar (the bolded passage is my suggested new addition):

Welcome. Please note that this page is NOT for challenging the outcome of deletion discussions or to address the pending deletion of any page. However, files that were deleted through Wikipedia:Files for discussion or Wikipedia:Possibly unfree files, due to freedom of panorama concerns, may be requested for undeletion here, provided that the reasons are valid.

_ JWilz12345 (Talk|Contrib's.) 16:08, 28 April 2022 (UTC)

Despite what the heading message says I restore all sorts of uncontroversial pages. If the requestor provides evidence to support their claim - perhaps a link to the policy, and info on the the affected file, it may be obvious that the earlier deletion should be overturned. There is a flow of images that have copyright expired in the last year or two, or that are too simple for copyright having their deletions reversed. Also many FFD file deletes are just nominated by one person and then never supported by anyone. You cannot call that a consensus, and the deletion is more in the way of a soft delete. The lead text instructions should probably reflect our policy, but don't make it too long, otherwise it will not be read or understood. Graeme Bartlett (talk) 10:39, 29 April 2022 (UTC)

I would suggest adding a new bullet point to the section of WP:RFU that says Instructions for special cases for US-FOP undeletes. I'm not sure exactly what the the bullet point should say, but something to the effect of US-FOP undeletes can be requested here, which gives some brief guidance/explanation about when these can be undeleted. Maybe something like "A file that was deleted based on lack of FoP can be undeleted at RFU if it is eligible for a ((FoP-USonly)) tag." Levivich 15:46, 29 April 2022 (UTC)

Oppose REFUND should be a formalistic venue, not making content decisions that certain files were wrongly deleted. * Pppery * _{it has begun...} 16:22, 29 April 2022 (UTC)

It's one of the more irritating things on Wikipedia, that when you are reading an article and then click on an image to view it, and then go back to the article and it has returned you to the start, top, of the page. Then you have to scroll down to find where you were, and it's very annoying when reading a long article. I guess this is something only programmers or people more deeply involved in Wikipedia could fix, but it would be a welcome fix. 2A07:A880:4601:1051:5AAD:6475:8E2A:7767 (talk) 06:40, 3 May 2022 (UTC)

This is more of a technical issue than a conscious decision by editors, although I am unaware of the specific phabricator ticket for this. — Ixtal ^{( T / C )} ⁂ Join WP:FINANCE! 07:30, 3 May 2022 (UTC)

Huh? That doesn't happen for me. Are you talking about the (horrible, no good, very bad, really just needs to be taken out and shot and buried in a deep, deep, DEEP grave and never spoken of again) mobile version? --User:Khajidha (talk) (contributions) 11:58, 3 May 2022 (UTC)

2A07:A880:etc., which browser are you using? I've noticed this with Internet Explorer, and is one of the (many) reasons that I don't use it. --Redrose64 🌹 (talk) 18:44, 3 May 2022 (UTC)

I'm the OP, and I use Firefox (for PC, not phone). 2A07:A880:4601:1052:F303:A2AF:ADC4:AF90 (talk) 13:13, 7 May 2022 (UTC)

FYI… this does not happen in Mobile View… nor when using Desktop view on a phone. So that is not an issue. Blueboar (talk) 15:13, 7 May 2022 (UTC)

Works for me, using desktop/monobook/firefox/without "media viewer": Went to a page, Alpine_transhumance, scrolled down, clicked the image, which my browser followed to the image description page, click "back" in the browser and was right where I started. — xaosflux ^Talk 18:36, 7 May 2022 (UTC)

Works fine for me as well, using Firefox 100 on Linux on a desktop PC. Phil Bridger (talk) 18:41, 7 May 2022 (UTC)

I suggest that portals be visible in default search alongside with articles (when the user reader does not actively choose namepaces).

Rationale: To increase portal pageviews and to increase awareness of the portals among readers. Not all users readers know about namespaces and what they are. Utfor (talk) 16:33, 3 May 2022 (UTC), edited by Utfor (talk) 18:45, 3 May 2022 (UTC)

I don't think a lot of readers would care to know what namespaces are since I bet the majority of people using the search function on Wikipedia are just trying to find a specific article. But if people think this is a good idea I don't object (but I don't really support it either). ― Blaze Wolf^Talk_{Blaze Wolf#6545} 18:57, 3 May 2022 (UTC)

My point is not that readers would want to know all about all namespaces, but if they search, they need to know what the portal namespace is in order to find portals in the search. Utfor (talk) 19:06, 3 May 2022 (UTC)

Well I honestly don't see why a reader would want to use the portal. If a reader is looking for a specific article they'll just search for it. ― Blaze Wolf^Talk_{Blaze Wolf#6545} 19:09, 3 May 2022 (UTC)

 Oppose - if a reader is searching for an article, why would they want a portal? ―  Qwerfjkltalk 19:27, 3 May 2022 (UTC)

You could shorten that to "why would they want a portal?". Seriously, just scrap the damn things. --User:Khajidha (talk) (contributions) 19:38, 3 May 2022 (UTC)

I believe we should just deprecate portals entirely.--WaltCip-(talk) 16:53, 4 May 2022 (UTC)

• Oppose, per above. Portal talk pages are dead, portal pages are dead, just desolate in general. Take the Formula 1 portal, it gets less pageviews than an article I wrote about a diabetes medication. I wouldn't be saddened at all to see them go. X-750 _{I've made a mistake, haven't I?} 03:01, 5 May 2022 (UTC)

• Support – If links to portals are not available anywhere to WP:READERS, then readers are left in the dark, then having no way of knowing about their existence. Omission of portals from searches on en-wiki is exactly why page views for some portals may be lower than they need to be; readers don't see links to them. Portals should not be censored from public consideration. Then, when more people actually learn about portals, because they can actually see links to them, more editors will naturally come along to improve them. North America¹⁰⁰⁰ 14:11, 6 May 2022 (UTC)

  But why would readers be interested in portals in the first place? If a reader is looking for a specific article, they wouldn't be wanting ot see results for a portal on a related subject. They would be looking for the article. ― Blaze Wolf^Talk_{Blaze Wolf#6545} 14:17, 6 May 2022 (UTC)

  Queue the portals to link below the main articles, creating an option, rather than no option being available. North America¹⁰⁰⁰ 14:28, 6 May 2022 (UTC)

  I don't see how that would make users click portals more. In fact it probably wouldn't make a difference since if a user starts typing the article title in, a bunch of different articles will pop up (probably more than can be displayed) before it reaches the bottom unless it's the exact article title or no other article title matches that, which in that case the portal wouldn't match what is typed. ― Blaze Wolf^Talk_{Blaze Wolf#6545} 14:42, 6 May 2022 (UTC)

• Oppose Can we just stop trying to beat life into the dying horse that is Portals? casualdejekyll 14:30, 6 May 2022 (UTC)
  • Your logic seems inversed, because providing readers with an option to actually see portals does not "beat life" into them. Rather, this would actually make them more visible to readers. Why should we "stop trying" to make an entire Wikipedia namespace readable? Many readers become editors, but readers cannot potentially improve hidden content. North America¹⁰⁰⁰ 14:46, 6 May 2022 (UTC)
    • Portals are a failed experiment, as outdated as webrings.--User:Khajidha (talk) (contributions) 18:44, 7 May 2022 (UTC)
• I dont know if IPs can vote but I would support this had I had a account--88.240.156.141 (talk) 14:13, 7 May 2022 (UTC)

Portal:COVID-19 Moxy- 14:17, 7 May 2022 (UTC)

• Oppose. The default search settings should, in my opinion, contain the minimum amount of pages required to get readers to what they are looking for. Cluttering up default search with pages of questionable usefulness in the name of "increasing visibility" makes searching for stuff a more time consuming and worse experience. Portals aren't useful for navigation because they contain a semi-random selection of snippets from articles and are often quite badly out of date - it's completely pot luck as to whether you'll find what you're looking for. Portals already have fancy bars, buttons and links in basically every major article on the site, that should be more than enough visibility for readers to realise they exist. 192.76.8.77 (talk) 10:50, 8 May 2022 (UTC)
• Weak support. I didn't know what a portal is until like 6 months ago. It's just hidden too deep inside. And it's a reader-facing namespace. Not something like Modules or MediaWiki pages. Portals are a really nice way to navigate Wikipedia, but people simply don't know about their very existence. —CX Zoom[he/him] ^{(let's talk • {C•X})} 14:05, 8 May 2022 (UTC)

Conditional support, oppose otherwise. I would support this only if this is part of a portal viability test which after x months (say 6 months) we check if portal traffic has significantly increased. If they haven't, the portal namespace finally gets deleted. There are voices that keep trying to revive this failed idea, when the evidence consistently shows no one cares but a very small group. Gonnym (talk) 17:10, 8 May 2022 (UTC)

No, we've already rejected deletion of the namespace multiple times. This discussion is about making them visible, particularly in the wake of main page unlinking which concealed major portals from 90% of visitors. Certes (talk) 20:01, 8 May 2022 (UTC)

• Oppose Portals are already searchable in the search engine, as is any namespace. There are already links to portals in the "see also" sections of many articles. Not only that, but portals are barely updated anymore. The last time Portal:United States was updated was April 9, last time Portal:The arts was updated was January 9, and so forth. Even from my own experience as a reader, in the 15+ years that I've used Wikipedia, I used portals a grand total of zero times. Trying to bring back portals is like trying to bring back the dinosaurs. It's not going to improve reader experience and sometimes its just better to let something that's dead stay dead.—Mythdon (talk • contribs) 17:39, 8 May 2022 (UTC)

  That is incorrect. The last edit to a portal page is not when it was last updated. Just like on Wikipedia's Main Page, portal updates usually come from elsewhere. See for example [8]: the United States portal is updated about every week. —Kusma (talk) 08:26, 9 May 2022 (UTC)

• Support Portals aren't good because of their low visibility. If portal visibility keeps getting suppressed by people because "Portals are bad," how are they expected to ever improve? They're worsening the problem they're blaming. — PerfectSoundWhatever (t; c) 03:50, 9 May 2022 (UTC)
• Oppose - An attempt to resurrect a dying concept. Let's focus on working on what already appears in the default searches - the actual articles which are the purpose of this project. -Indy beetle (talk) 07:30, 9 May 2022 (UTC)
• Support at least as a test. Portals are so hidden now that people only rarely stumble upon them. Any change to their view counts needs to come from outside of portal space; without either something like this or a way to make portal links in articles more visible, we should expect portals to continue to slowly die. We should not hide gems like Portal:Cheshire from our readers. —Kusma (talk) 08:26, 9 May 2022 (UTC)
• Oppose. Portal:Cheshire (given above as an example) is already linked from 1579 mainspace articles[9] and is viewed on average 6 times per day. Most people just aren't interested in them, and any effort spent on them is a waste of time. Perhaps Cheshire is a low-interest topic, but Portal:Covid-19 is also clearly linked from some 1600 mainspace articles, many of them very often visited (pages like COVID-19 pandemic and so on), and it gets only 84 pageviews per day. Portals just aren't what people are looking for here, very few people seem to be using portals as their entry point or seem to be returning to them on a regular basis. Sending more people to pages they don't really want is not useful. Fram (talk) 09:46, 9 May 2022 (UTC)

  The thing is, portals are technically "widely linked", but never in a place where I actually see the link (they are competing for my attention with far too many other things). In articles longer than two screens, I don't think the portal links do anything. I don't have a particularly good suggestion how to change that. To put the pageviews into some more perspective, the portals are more popular than outlines and indices: [10]. —Kusma (talk) 10:10, 9 May 2022 (UTC)

• Oppose as they are pretty useless. We should be moving away from Portals. Graeme Bartlett (talk) 10:15, 9 May 2022 (UTC)
• Question. Aren't categories reader-facing (and much more well-maintained)? Wouldn't this logic apply to them, too? –MJL ‐Talk‐^☖ 17:27, 9 May 2022 (UTC)
• Oppose portals have been dying a slow death for over a decade. Whatever use they may have once had, they are now basically moribund, and I see no reason to enact the proposal. --Jayron32 17:41, 9 May 2022 (UTC)

Did you know that the number of words in all wikipedia articles is 4,109,724,931.

The maximum size of a 32 bit unsigned integer is 4,294,967,295.

Should we have some recognition for that if it occurs?

2600:6C4E:1200:1E85:10CF:627A:ACF0:5728 (talk) 06:26, 1 May 2022 (UTC)

No. Only if adding more words causes an integer overflow and deletes the content. AndyTheGrump (talk) 12:27, 1 May 2022 (UTC)

Maybe that would break the Internet. Phil Bridger (talk) 13:15, 1 May 2022 (UTC)

One lives in hope... AndyTheGrump (talk) 14:56, 1 May 2022 (UTC)

I don't think the 32 bit integer limit applies to something like Wikipedia. I could be wrong though. ― Blaze Wolf^Talk_{Blaze Wolf#6545} 14:01, 2 May 2022 (UTC)

Why wait? Dust-off that old 16-bit PC and put this to the test. 50.75.226.250 (talk) 15:50, 2 May 2022 (UTC)

I don't think a 16-bit PC can have an internet browser. Also, I'm fairly sure we have gone beyond 32 bits, mainly since (For example) Minecraft's limit of normalness is the 256-bit integer limit (After that it still works but it starts breaking). ― Blaze Wolf^Talk_{Blaze Wolf#6545} 16:54, 2 May 2022 (UTC)

Well, it was supposed to be a joke that apparently misfired, apologies. Or you could make a perfect straight man :). Jokes aside, sure there were (and can be) internet browsers on 16-bit devices, including PCs, but that's another topic. 50.75.226.250 (talk) 17:02, 2 May 2022 (UTC)

Lynx (web browser) can run on 16-bit machines. Anyway, if there is a limit relating to MAXINT, it will either be the number of bytes in a file, or the number of files on a server. The number of words is totally irrelevant - in English, words are delimited by pinctiation and spaces, both od which are characters just like letters or digits. --Redrose64 🌹 (talk) 18:54, 3 May 2022 (UTC)

Please don't disillusion me like this. I was hoping that someone somewhere would break the Internet so we could all get back to a simpler life. Phil Bridger (talk) 20:23, 3 May 2022 (UTC)

A grandma managed to do it once so it is possible. ― Blaze Wolf^Talk_{Blaze Wolf#6545} 14:23, 6 May 2022 (UTC)

• the total number of words are from different pages, that is similar to different files. To be short, I dont think crossing that limit will cause anything to happen. If we include all the words from english subdomain only (enwiki), I think we would have the words at least 7-8 times more than the article-space. main talk, user, user talk, WP, WP talk, templates, and literally every text that exists on enwiki. Later, dewiki is subdomain, and technically still a part of "wikipedia" website. —usernamekiran (talk) 05:20, 10 May 2022 (UTC)

My name is Leana Ilagan, I’m an Speech-Language Pathologist from the Philippines, and currently on a post-graduate study program in Canada.

I want to express my appreciation and gratitude to Wikipedia, as you served us all with resources as well as legitimate facts across the world as time stand and fly by, and for that we thank you.

Wikipedia is known as the most famous online encyclopedia globally, may I suggest for us to promote May as Speech and Hearing month, to give more awareness to our fellow nations and people around the world. This will be provide an opportunity to raise awareness about hearing and communication health. Moreover, it can give attention to the importance of early detection and intervention in the treatment of communication disorders and hearing impairments, as well as recognize the role of health-care professionals in providing life-altering treatment for people to overcome and/or manage them.

I highly encourage Wikipedia to add this event for the special events celebrated and recognized for the month of May.

Thank you! — Preceding unsigned comment added by 174.92.15.169 (talk) 21:32, 11 May 2022 (UTC)

Wikipedia is not for promoting causes like that, no matter how worthy. Graham87 09:15, 12 May 2022 (UTC)

No, it is not for promoting such causes, but there is nothing to stop interested editors from improving relevant articles. I would urge the proposer to do so and encourage others to do so, whether in May or any other month. Phil Bridger (talk) 17:21, 12 May 2022 (UTC)

As a side-note. This is listed already under May#Month-long_observances —TheDJ (talk • contribs) 09:24, 12 May 2022 (UTC)

Wikipedia, by which I mean the community that is the English language Wikipedia, is serious about controlling undisclosed paid editing. That we know.

Wikipedia requires paid editors to disclose their status. See WP:PAID. It provides four levels of warnings to suspected paid editors (UPE) who have not made a proper disclosure:

• ((uw-paid1))
• ((uw-paid2))
• ((uw-paid3))
• ((uw-paid4))

Editors in good standing who suspect an editor of UPE are encouraged to use these warnings in good faith, at which point the system ends. There is no obvious, nor reliable, route forwards.

Instead, we have independent, committed editors and admins alike who try, and often succeed, in pursuing UPE either to a formal disclosure (good), or to an indefinite block (also good) should they not disclose and matter be proven.

But proven is a difficult word in this context. Proven by whom, and to what universal and agreed standard? Using what tools? Using what authority to use a putative toolset that may not even exist?

Were we investigating sockpuppetry then the route to opening an SPI is clear. We even have tools to assist us. We pass the task to a team of acknowledged experts, a team empowered within agreed limitations to investigate, and to act. We make the evidence based report, and stand aside, confident that experts will reach an evidence based conclusion. We trust the team.

For paid editing investigation we have a loose confederation of gifted amateur sleuths, Miss Marples if you will. Like Miss Marple, that loose confederation is susceptible to being accused of being interfering busybodies, perhaps being pilloried by accusations of bias, perhaps being accused of many other and more serious things, all from areas where they have acted in good faith and met a powerful Wiki-enemy. This can lead to our Miss Marples being driven away. 🇺🇦 Fiddle^Timtrent Faddle^Talk to me 🇺🇦 18:51, 9 May 2022 (UTC)

Proposal (UPE reporting)

To counter this I make a simple sounding proposal, one that will create a trusted core team of UPE fighting experts, very much along the lines of our Sockpuppetry team.

Those experts are to be provided with, or to create, or to cause to be created, such tools as will, with correct community consensus based approval, ease the work of identifying UPE beyond reasonable doubt.

The experts will start from a mixture of community reports (cf SPI) and their own initiative, always processing their work in as transparent a manner as does not create a WP:BEANS situation, and does not breach the legitimate privacy rights of editors who fall within the scope of their investigations.

As usual I hope the community will seek to improve on this very simplistic proposal. 🇺🇦 Fiddle^Timtrent Faddle^Talk to me 🇺🇦 18:51, 9 May 2022 (UTC)

Discussion (UPE reporting)

• This is wayyyyy overreaching imo and overly bureaucratic. As someone who works extensively in identifying UPE, this is a super myopic view/proposal and way too black and white, which UPE is not. It's more than just fiverrs and freelancers being hired and one off employees editing on behalf of their company. Further this is also somewhat redundant because it's already required by the terms of use, which isn't subject to enwiki's discretion (with regard to warnings, which are often ingnored as well as disclosure.) Creating a "trusted group" is also unrealistic imo. Who is to say who is trusted and who is not? A lot of UPE identification in terms of identifying the who/where they were hired can and is done off wikipedia and disclosing more than that would disclose a lot of tells and identifiers we use. PRAXIDICAE💕 18:59, 9 May 2022 (UTC)

  @Praxidicae I'm glad you said that, and I understand it, and thank you. You are one of the committed and gifted people I refer to. What I hope to happen is for the community to use this discussion as a spur to show people like me an approved route forward. I am not wedded to any of the proposal, but I feel that we must start somewhere for the ordinary editor. Counter proposals are more than welcome. 🇺🇦 Fiddle^Timtrent Faddle^Talk to me 🇺🇦 19:07, 9 May 2022 (UTC)

  @Praxidicae: Whats a fiverr? —usernamekiran (talk) 21:13, 9 May 2022 (UTC)

  @Usernamekiran: Fiverr[11]. PRAXIDICAE💕 21:17, 9 May 2022 (UTC)

  Honestly a lot of this proposal is just too much, it's like 9 solutions in search of a problem. Is the way we handle UPE the most ideal? No, but it's also not possible in some aspects to do any better because of our policies on outing and AGF, add to that, sometimes it's better not to disclose publicly what we do know because that's a tip off to some of the more damaging paid editing firms. Further, formalizing a "group" of individuals is a bad idea because it's going to become an issue of gatekeeping. I also worry that formalizing said group would result in more malicious harassment of editors (I can attest to this personally as I'm accused on a nearly daily basis here and off-wiki of "working for competitors") and we'll wind up with more blown-out-of-proportion ANI threads like the one targeting Celstina at ANI right now, especially when the particularly powerful paid editors with thousands of edits, which trust me, do exist, get rubbed the wrong way. PRAXIDICAE💕 19:12, 9 May 2022 (UTC)

  How do we protect the Celestina007s of our community?

  You are opening up very substantial areas for discussion. I am at the end of my expertise, and hope to learn, now. If the proposal is too much, then please prune it, refactor it, do what you believe needs to be done to it, because those who, like me, look up to those like you are unsure how to move forward. 🇺🇦 Fiddle^Timtrent Faddle^Talk to me 🇺🇦 19:21, 9 May 2022 (UTC)

• Isn't WP:COIN already a centralized board for handling conflict of interest? It suffers from low traffic (or at least, low uninvolved traffic), but IMO is the "next step" that this proposal asserts is missing, in that it's a centralized board for community review of COI concerns. _signed, Rosguill ^talk 19:02, 9 May 2022 (UTC)

  FWIW I don't consider COIN to be a particularly valuable part of identifying UPE since a lot of what we need to demonstrate to prove that an editor is a paid editor (outside of one off obvious accounts that get blocked at the start for spamming/paid editing) can't be posted on-wiki. PRAXIDICAE💕 19:04, 9 May 2022 (UTC)

  Me neither. As soon as it reaches coin its dead, they start to play up and fudge it. I suspect coin and board are pretty much dead. Its show the decay in Wikipedia that once vibrant board is now barely used. scope_creep^Talk 20:40, 9 May 2022 (UTC)

• I'm not clear on what is being proposed that requires community consensus. It sounds like you are proposing that some tools be created, but without specifics, it's unclear if this is something requiring access to private information. If not, then anyone can create tools using publicly available data. (I know there has been sensitivity in the past with things like building a notification system for a user's edits, but there is no way to prevent someone from using public data as they will.) isaacl (talk) 20:02, 9 May 2022 (UTC)
• I'm not sure that "prove" is a good word to use, unless we also specify the standard of proof required. I have always understood that the standard of proof required to take sanctions here to be (using terms from English law, which I am most familiar with) below the standard required in criminal cases (beyond reasonable doubt) but above that required for civil cases (balance of probabilities). Blocking, or other sanctions, are important enough not to be taken lightly, but we are not taking away anyone's liberty or money here, simply telling them not to edit a web site. Phil Bridger (talk) 20:09, 9 May 2022 (UTC)

  It's even better than that: we're taking away their money if and only if they're guilty. Certes (talk) 20:49, 9 May 2022 (UTC)

• I don't think the proposal is bureaucratic from what I interpret it to be. But it is a little loosely/vaguely defined. I think COIN is best suited venue for UPE, and related discussions. Like Praxidicae said above, there are PR/editing firms at play, these are way different than one-off, or overly obvious newbies/freelancers. UPE, and accusations of UPE requires (most of the times) off-wiki evidence, and providing that off-wiki evidence would be revealing our methodology/MO, which would help them improve, and would make finding UPEs difficult for us. Other issue here is about outing, and other related stuff. The best way to tackle this is to call it COI instead of UPE. That way, way have to provide less (on-wiki) evidence so that we can prove COI, and maintain the discreetness of our MO, and get that ediotr topic banned from the particular topic. I am not sure what tools you are thinking (to use/create) that could help identify UPE. I dont think thats even possible. But what we could do is, to make a subpage somewhere in COIN to list all the editors who are interested to work against UPE/COI. A procedure/guideline in case we come across UPE/COI to get blocked. If the evidence is solid, we can provide it to ARBCOM, and they can block the UPE/COI editor through role account to avoid being targeted/harassed. Praxidicae has also voiced my concerned about the team which I raised here. In short, NPP/R was not formed in a week, it is result of years. We can create an informal list in a subpage of COIN. We should create a standard guideline/procedure for course of action if COI/UPE is found. It would be better if the course of action somehow hides the investigator (arbcom/role account?). With time, this process might grow/develop automatically. —usernamekiran (talk) 21:13, 9 May 2022 (UTC)
• I'm trying to get my head around what this would involve. As far as private data goes, the two main types that assist with UPE would be CU and information about job ads and advertisements. The former is already handled in an existing system, and I fear that special "UPE CU" admins would risk creating too many new problems. I can see a case for expanding the use of CU in order to tackle prolific sockpuppeteers, but that could be handled in the existing CU framework. In regard to the latter, WP:OUTING has already been modified to both a) permit the linking to job ads on COIN even when there is a risk of identifying editors; and b) requiring paid editors to "self-out" by linking to their profiles on freelance sites from their user pages. As to what editors do off-wiki, such as watch job ads and known contractors, (which, in the interest of full disclosure, I do), I'm not sure how en.wiki can be involved. The issue is that ultimately, what someone knows from off-wiki data is irrelevant unless it can be shared, as in the end you can only block or request a block if you can support it with evidence, even if that evidence needs to be shared on COIN or with a trusted admin/arbcom per the existing COI procedures. Any other "tools" would only be to look at on-wiki editor behaviour, wouldn't involve private data, and therefore I don't think should be limited in access to a select group, as that is counter to our principal of transparency. To be honest, I think the only effective way of combatting most paid editing is to make Wikipedia less attractive for advertising by making the rules on businesses and individuals more restrictive, but I don't see that happening any time soon. - Bilby (talk) 23:15, 9 May 2022 (UTC)

  CheckUsers already handle nonpublic evidence of UPE sent to paid-en-wp@wikimedia.org – mainly advertisements on freelancing websites. Perhaps we need to clarify that this is preferred way of reporting over sending to individual admins (per WP:BLOCKEVIDENCE, individual admins should not act on nonpublic evidence because it leaves no paper trail) or ArbCom (who have enough on their plate and set up paid-en-wp@ for that reason). The instructions seem to be scattered all over the place and out of sync. – Joe (talk) 11:43, 10 May 2022 (UTC)

  It seems that there is some variation on this around - I'm very happy to see that clarified. Thanks! - Bilby (talk) 11:52, 10 May 2022 (UTC)

• If something needs to be changed, it's WP:OUTING. The policy section was never meant to protect people who are here to exploit our collaborative non-profit project for their own financial ends. It's part of the harassment policy, after all. The point is to protect people from being doxxed because they made controversial edits, blocked a popular user, or pissed off the wrong LTA. We should just expand the exceptions Bilby mentions to one of "accusations of pervasive conflict of interest in a user's editing". I don't get why we twist ourselves in knots defending those who want to hurt what we've built. -- Tamzin^{[cetacean needed]} (she/they) 08:45, 10 May 2022 (UTC)
• Those experts are to be provided with, or to create, or to cause to be created, such tools as will, with correct community consensus based approval, ease the work of identifying UPE beyond reasonable doubt. What kind of tool do you expect to be created that requires special permissions? Tools that rely on non-public data are already restricted to admins or checkusers. It seems a bit premature to setup a whole new process to authorize the use of some tools, when we don't seem to have tools to authorize in the first place. MarioGom (talk) 14:13, 10 May 2022 (UTC)

  Sorry, coming to this quite late, as I'd only noticed the parallel discussion at Wikipedia:Village_pump_(idea_lab)#Undisclosed_Paid_Editing. The wording here might be partly my fault, as I raised the concern at a current ANI argument, where a UPE-hunter has been accused of making unclear and exaggerated statements about the tools and powers available to them. I replied at ANI that I thought UPE-hunting was better done by a selected group who have whatever tools they need, and have procedures in place to follow: if we minions knew what rights UPE-hunters have, and how the decision is reached, UPE-hunters wouldn't have to justify their actions by claiming mysterious special rights and abilities, and we'd have been spared an outstandingly long and painful ANI. It may just be that we need better documentation of what processes already exist. But the ANI thread is strong evidence that we haven't quite got this right yet. Elemimele (talk) 12:29, 11 May 2022 (UTC)

  The problem I see with that ANI thread is that too many people were too happy to continue talking about non-existing special rights and non-existing secret tools even after receiving many technical explanations. And this is a good example of the FUD that, unfortunately, continues: if we minions knew what rights UPE-hunters have There're no "UPE-hunter rights". Any discussion that continues standing on this false premise is not going anywhere useful. MarioGom (talk) 17:50, 11 May 2022 (UTC)

  @MarioGom:, that was partly my point. With neither any special tools, nor with a duck-test for UPE, it's basically impossible to fight it without landing up at ANI, because there is no conceivable situation in which you can make an accusation of UPE without being accused of bad faith. You say they're doing UPE. They say they're not paid. And if you don't believe them, you're the baddie. If there were a duck-test, you'd at least be able to say "account is quacking"; if there were some technical way to match up the account to IP addresses previously found to be indulging in UPE, or that match organisations/people advertising their services as WP editors-for-cash, then someone could declare the editor a UPE (though this probably overlaps very heavily with SPI); and if there were a group given particular rights to reach the decision, the decision would look less like an individual piece of vindictiveness, and more like a community consensus. My feeling is that as things stand, it simply isn't sensible to go looking for UPEs precisely because there are no tools, definitions or special groups to do the job. I just can't decide which is better: abandon hunting UPE and just attack bad edits irrespective of their cause; or create structures/tools/definitions to legitimise UPE-hunting. Elemimele (talk) 12:19, 13 May 2022 (UTC)

Support (UPE reporting)

• ’’’Support’’’, as proposer. 🇺🇦 Fiddle^Timtrent Faddle^Talk to me 🇺🇦 18:51, 9 May 2022 (UTC)

Oppose (UPE reporting)

• Per Praxidicae; seems overly bureaucratic and a solution in search of a problem. firefly ( t · c ) 19:17, 9 May 2022 (UTC)
• This isn't something that can feasibly be done within policy or practicality, due to the concerns Praxidicae brings up. It's impossible to definitively determine whether a user is UPE without either self-outing or outright outing that is almost guaranteed to also have collateral damage, especially given the tendency of UPE editors to lie in an effort to not have to disclose. —Jéské Couriano v^_^v ^{a little blue Bori} 20:18, 9 May 2022 (UTC)
• COIN. Use it. casualdejekyll 22:03, 9 May 2022 (UTC)
• Per prax in the discussion section. Our processes for handling and documenting UPE could be improved, but bureaucracy and yet another pseudo-permission won't do that. This proposal should have been workshopped with people active in this area first (@Timtrent: did you see Wikipedia:Village pump (idea lab)#Undisclosed Paid Editing?) – Joe (talk) 11:38, 10 May 2022 (UTC)

  @Joe Roe Too late, unfortunately. 🇺🇦 Fiddle^Timtrent Faddle^Talk to me 🇺🇦 17:31, 10 May 2022 (UTC)

• Hell no. As soon as we are asked creating "trusted core" teams of "experts" to "fight" anything, we should run screaming in the other direction. Just. No. --Jayron32 14:06, 10 May 2022 (UTC)

  @Jayron32: I am not opposing you, but your "to "fight" anything" comment intrigued me a lot. Would you kindly elaborate on your (entire) comment? I mean, whats the reasoning behind it? —usernamekiran (talk) 22:00, 11 May 2022 (UTC)

  I don't find the battleground mentality a useful way to build an encyclopedia. We don't fight. We write articles and make them better. Also, since you said "entire", I also oppose empowering any centralized group with extra powers in this regard. --Jayron32 11:40, 12 May 2022 (UTC)

  I totally agree, with every point. I am glad that I asked for the clarification. Thanks for the response :-) —usernamekiran (talk) 20:11, 12 May 2022 (UTC)

• Strongest possible oppose in line with Jayron and Praxidicae. — Ixtal ^{( T / C )} ⁂ Join WP:FINANCE! 14:14, 10 May 2022 (UTC)
• Oppose Lots of nasty stuff with little prospect of helping. North8000 (talk) 17:52, 10 May 2022 (UTC)

Neutral (UPE reporting)

• Neutral so as not to pile on, and so as not to further set back the likelihood of doing something about UPE, because any more Opposes may be interpreted as opposing the need to improve the process of dealing with UPE. I am saddened that User:Timtrent decided to throw out a half-baked proposal, knowing that his objective was to avoid having a more detailed proposal torn apart, and so instead getting the whole idea torn apart. I had hoped to work out some idea about how to improve the UPE process at the Idea Lab, but this has probably left any such efforts dead for the next few months. COIN does not work consistently or well. We have two policies that interfere with each other, the rule against UPE, and the rule against outing, and we have given the wrong priority to the two, so that anonymity can be used for advertising. We have a good policy that isn't enforced, and we need better enforcement, and this idea has probably made discussion of better enforcement out of the question for a few months. Robert McClenon (talk) 16:55, 10 May 2022 (UTC)

  Perhaps Timtrent will withdraw this. Alanscottwalker (talk) 18:03, 10 May 2022 (UTC)

  @Alanscottwalker I think that this proposal may fail, but do not see how a failed proposal does not act as a catalyst for a better proposal. Nor do I understand why folk here seem unable or unwilling to modify the proposal or to create a counter-proposal.

  You or anyone else are welcome to accuse me of naïve thinking if that is what I have shown and if you wish to, but I have always though that we, the community, were better than this, and could and would discuss proposals to reach one that we would agree on. 🇺🇦 Fiddle^Timtrent Faddle^Talk to me 🇺🇦 12:53, 11 May 2022 (UTC)

  For what it's worth, I don't think this proposal failing is any set back for other well thought proposals on UPE or COIN. MarioGom (talk) 21:27, 10 May 2022 (UTC)

  @MarioGom Agree with you. Failed proposals can highlight a difficult area. A failure, which seems likely here, ought to act a catalyst for wiser heads than mine to create better proposals. I am wholly lost as an AFC reviewer. If I act in good faith over what I perceive as UPE I risk being pilloried for those acts at ANI as is happening to another editor at present. I have no formal route forward. I believe we need one, and a good proposal for one. Mine seems to be destined for failure, but so what? Better editors than I can create better proposals. 🇺🇦 Fiddle^Timtrent Faddle^Talk to me 🇺🇦 13:14, 11 May 2022 (UTC)

When I look at all of the Sonchus articles that have not been created, I feel like that something should be done to create all of the species in the Sonchus genus. What I think Wikipedia should do is either create a competition for the expansion or create a WikiProject for the Sonchus genus. I have already created Sonchus kirkii and Sonchus ustulatus but that is still not enough. 𝙷𝚎𝚕𝚕𝚘𝚑𝚎𝚊𝚛𝚝 (𝚃𝚊𝚕𝚔) 23:06, 12 May 2022 (UTC)

Have you tried asking for help at WP:TOL or any of the numerous subprojects? I don't know how active those are, but that would be the first place I would go for help. --Jayron32 18:03, 13 May 2022 (UTC)

• I am not really sure that having a competition would be consistent with the goals of Wikipedia. YTKJ (talk) 18:26, 13 May 2022 (UTC)

  There are quite a few competitions on Wikipedia, such as the WP:Wikicup and WP:The Core Contest, which stimulate friendly competition. I wouldn't say that's against the goals of Wikipedia at all. That said, it is difficult to find participants for competitions around small topic areas, like Sonchus, and seeking collaboration within a Wikiproject will likely be more fruitful. Femke (talk) 09:17, 14 May 2022 (UTC)

Recently, there was a discussion pointing out that the post-move cleanup guides need work. Wikipedia:Village_pump_(proposals)/Archive_189#Making_the_post-move_message_more_concise

I have merged the guides and placed the result on Wikipedia:Post-move cleanup. It would be fine to have some of you fellow Wikipedians to review it and edit it if you find something that can be improved. Utfor (talk) 19:50, 12 May 2022 (UTC)

Funny timing! I just spent the last couple hours working on a draft of the same thing. It's mostly written from scratch, because I think there are some major issues with the guidance currently at WP:MOVE and WP:RMCI:

• They over-emphasize certain cleanup tasks that are rarely necessary (e.g. fixing double redirects)
• They fail to mention certain tasks which are important, like updating the article prose (beyond just the first mention) and renaming subsidiary pages (including categories and related mainspace articles)
• There's some organizational kludginess. A bunch of cleanup tasks are only required when there's a change to topic structure, and they should probably be grouped together for that reason. Something like "Fixing fair use rationales" can be subsumed by the more general step of "Fix mistargeted wikilinks".

I think v1 of my draft should be done today - then maybe we can compare notes and decide which pieces to take from where? Colin M (talk) 20:38, 12 May 2022 (UTC)

Okay, I think my draft is at v1.0. Some notes on sections from the earlier guides which I deliberately did not include:

• "Fixing fair use rationales": This is subsumed by the broader task of fixing mistargeted wikilinks.
• "Address any technical restrictions": This comes up very rarely, and when it does cause issues, they're pretty easy to spot. Seems like it's not worth the WP:CREEP cost? If this is a thing that matters, we should give an example.
• "Fix double redirects": These are taken care of by bots. Nuff said.
• "Categorizing redirects": I don't really see this as an aspect of post-move cleanup. (Also not exactly a high-priority task.)
• "Update talk page notifications": No idea what this section is saying.
• "Wikidata update": I just don't understand this step. Under what circumstances is it necessary, and what are the benefits? Maybe an example would help here?
• "Categories and subcategories": No idea what this section is saying.

Colin M (talk) 21:29, 12 May 2022 (UTC)

I trust you fully; just make any changes you believe are improvements. Utfor (talk) 18:35, 13 May 2022 (UTC)

Okeydoke, for the sake of preserving history, rather than doing a cut-and-paste move, I've moved the merged old content you put together to userspace at User:Utfor/Merged postmove cleanup guidance and moved the version I started to Wikipedia:Cleaning up after a move. I'm going to go ahead and boldly update WP:MOVE and WP:RMCI with summary style links to this new page. Colin M (talk) 16:46, 14 May 2022 (UTC)

Years of experience as a reader of this wikipedia lead me to notice that the category system cannot replace the efficiency of a subject index.

Every time there is a need to search for a topic of minor consideration or whose article has not yet been written, the reader must search within countless articles and categories both related and very collateral to the topic to be investigated, the typical case of unnecessary lateral thinking.

A general thematic index system and by categories could complement the current system of categories and articles in the event that the topic to be investigated does not meet the corpus of text or the necessary relevance to have its own article, in addition to being able to link individual paragraphs. and sections within articles that cover a different topic than the topic they mention.

The new system could link both categories, complete articles, sections or even individual paragraphs, the creation of these entries can be given directly as an addition to the edition summary with similar requirements to the creation of articles.

Perhaps what I'm proposing already exists in a way that I hadn't thought of, but the closest thing I can think of is the internal search, which doesn't perform this task.

As for the operating system, one could go to an alphabetical page where the different topics are described and these in turn contain content links. It could also be searched by categories of thematic indexes. — Preceding unsigned comment added by Diosverde (talk • contribs) 20:36, 14 May 2022 (UTC)

I think that's what WP:OUTLINES were intended to help with, but I don't see them used much. Schazjmd (talk) 20:45, 14 May 2022 (UTC)

Er, I think that Portals were intended for this, but... --Redrose64 🌹 (talk) 21:23, 14 May 2022 (UTC)

Wikipedia:Contents/Portals is a partial subject index, though the inclusion criterion is portals surviving its MfD rather than topic importance. Certes (talk) 22:00, 14 May 2022 (UTC)

Would a subject index be any better than Google? Elemimele (talk) 16:29, 15 May 2022 (UTC)

Our current categorization system is definitely lacking. See also Wikipedia:Category intersection. Mz7 (talk) 18:51, 15 May 2022 (UTC)

A lot of these traditional approaches (categories, indexes, portals) had the problem that you had to discern the mentality/organization of the system (including what "lens" was used for navigation/ classification) to use them but were the only thing available. The advent of google type searches or Wikipedia's own search bar do not have that issue and IMO have rendered those imo older methods obsolete. North8000 (talk) 23:01, 15 May 2022 (UTC)

I have noticed a drastically sharp increase of vandalism on articles when they get added to "In the News". My suggestion is to automatically semi-protect these articles for a period of time, Likely about 30 days, That or Review Edit Protection to allow people to still contribute to the articles, but in a safer matter, again for about 30 days. PerryPerryD Talk To Me 14:44, 16 May 2022 (UTC)

PerryPerryD Have you discussed this with those at ITN, say WT:ITN? 331dot (talk) 14:57, 16 May 2022 (UTC)

I have not, Thanks for the advice, I'll go do that immedietly PerryPerryD Talk To Me 14:59, 16 May 2022 (UTC)

When we do not have an article about the primary meaning of a term, we sometimes have a disambiguation page for the term instead. Before an article about the primary meaning was craeted, for example, moonrise was a dab page. It is now moved to moonrise (disambiguation), and the moonrise entry is redirected to moonrise and moonset. When editors wanted to link to moonrise, linking to the dab page is discouraged, so linking to wikt:moonrise is an alternative. But after the primary meaning is covered by an article, we need to retarget those links to point to Wikipedia, not Wiktionary. What about creating a regularly updated bot-compiled list? Human editors may then only need to fix the links manually, not track them down.

Specifically: A bot would look for [[wikt:$1]] in articles, and if [[$1]] exists and is not a dab page or a redirect to a dab page, then the bot adds [[$1]] to the list. ($1 here represents a wildcard.) Utfor (talk) 19:56, 24 May 2022 (UTC)

• @Utfor: Here is a Quarry query which attempts to list the links. Certes (talk) 00:42, 28 May 2022 (UTC)

Some of these links could be deliberate and still be appropriate even if an article exists. —Kusma (talk) 13:29, 28 May 2022 (UTC)

Thank you for the efforts and the feedback! User:Certes: It seems like use of Template:Wiktionary also is listed, e.g. in A.C. Milan. User:Kusma: Thank you for pointing out a useful fact. Utfor (talk) 18:31, 28 May 2022 (UTC)

@Utfor: Yes, the query lists all links to Wiktionary, even if the [[wikt:?]] text is within a template rather than explicitly in the article. A. C. Milan already links to Milan, so the link (via template) to wikt:Milan doesn't add much and could be removed. Certes (talk) 22:37, 28 May 2022 (UTC)

@Certes, you might want to remove disambiguation pages, which often link to Wiktionary correctly. ― Qwerfjkltalk 10:07, 29 May 2022 (UTC)

@Qwerfjkl: Good idea. That reduces the count from 12862 to 7900. I've also removed cases where the Wiktionary entry matches the linking page or a redirect to it. Beware that some Wikipedia articles are about a different topic to the similarly named Wiktionary link. For example, 187 (slang) links to wikt:187 which defines the slang term, whereas 187 in Wikipedia is about a year. Certes (talk) 13:28, 29 May 2022 (UTC)

As a regular Wiktionary contributor, is this something it’s worth doing in a more coordinated fashion between both projects? We equally have a big backlog (and a similar degree of inconsistency) in linking to the appropriate Wikipedia page. It would be good to have a joint-project effort to keep them consistent (even if it’s just a small handful of people overall). Theknightwho (talk) 14:15, 31 May 2022 (UTC)