also, currently the only 2 given news sources nyt and ap are both american organisations. by adding the 4 below, there will be 3 american vs 2 british and 1 global, which will be less usa-centric as a whole.--RZuo (talk) 15:19, 24 November 2023 (UTC)Reply[reply]
consensus seems to be against adding these sources. theleekycauldron (talk • she/her) 22:26, 25 December 2023 (UTC)Reply[reply]
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Oppose in favour of a general custom search engine that searches for all reliable outlets, something WP:WRS was supposed to offer before being abandoned. I proposed a mock-up here, but I will listen to all your suggestions. {{search for}} is great! Szmenderowiecki (talk) 20:24, 25 November 2023 (UTC)Reply[reply]
Neutral: Reuters is ok to add but I'm not sure we need many more links. Nemo 07:12, 29 November 2023 (UTC)Reply[reply]
Oppose per Sdkb, remove individual news outlets. Eddie891TalkWork 15:31, 29 November 2023 (UTC)Reply[reply]
Oppose per SdkB, remove all individual news outlets as source recommendations. GenQuest"scribble" 07:15, 4 December 2023 (UTC)Reply[reply]
support because bbc news is probably the most reputable among the most visited news websites, and the most visited among reputable news websites. and it's free, no login and whatnot.--RZuo (talk) 15:19, 24 November 2023 (UTC)Reply[reply]
Oppose in favour of a general custom search engine that searches for all reliable outlets, something WP:WRS was supposed to offer before being abandoned. I proposed a mock-up here, but I will listen to all your suggestions. Szmenderowiecki (talk) 20:24, 25 November 2023 (UTC)Reply[reply]
Oppose in favor of something more WP:WRS-like, as suggested just above. We don't have links to individual scientific journals; why should we have links to individual news outlets? XOR'easter (talk) 17:52, 28 November 2023 (UTC)Reply[reply]
Oppose: BBC is usually ok but it's even more prone to the political winds of one country; not suitable. Nemo 07:12, 29 November 2023 (UTC)Reply[reply]
Oppose per Sdkb, remove individual news outlets. Eddie891TalkWork 15:31, 29 November 2023 (UTC)Reply[reply]
Oppose per SdkB and echoing XOR'easter, remove all individual news outlets as source recommendations, we don't do journals or magazines, so there's no need for profit-driven newspapers either. GenQuest"scribble" 07:29, 4 December 2023 (UTC)Reply[reply]
Oppose in favour of a general custom search engine that searches for all reliable outlets, something WP:WRS was supposed to offer before being abandoned. I proposed a mock-up here, but I will listen to all your suggestions. {{search for}} is great! Szmenderowiecki (talk) 20:24, 25 November 2023 (UTC)Reply[reply]
Oppose — the WSJ hard paywall makes the site impractical to use for a large number of editors, and it goes against Wikipedia's free-content ideals. —pythoncoder (talk | contribs) 04:15, 27 November 2023 (UTC)Reply[reply]
Oppose in favor of a general custom search engine, as suggested above. We go through the trouble of identifying "generally reliable" sources; we might as well benefit from all that work. As to the point about controversies raised above, plenty of those at the NYT have been about its editorial positions rather than its reporting, and, well, the WSJ is no stranger to that, either. I don't see why circulation is relevant in this context. XOR'easter (talk) 17:44, 28 November 2023 (UTC)Reply[reply]
Oppose per Sdkb, remove individual news outlets. Eddie891TalkWork 15:32, 29 November 2023 (UTC)Reply[reply]
Oppose per SdkB, remove all individual news outlets as source recommendations (we don't do journals or magazines, so there's no need for profit-driven newspapers either). GenQuest"scribble" 07:31, 4 December 2023 (UTC)Reply[reply]
Oppose in favor of removing all individual news outlets, per Sdkb; because the WSJ has a hard paywall; and because its web archives only go back to the late 1990s. Epicgenius (talk) 16:57, 12 December 2023 (UTC)Reply[reply]
support because The Times is better than nyt. for example, a company has created an archive of it for scholars to study it. do you see people doing that for nyt? as the most important newspaper of a country that once ruled many countries around the world, it reported a lot more on news around the world for a much longer period, compared to the usa-centric nyt.--RZuo (talk) 15:19, 24 November 2023 (UTC)Reply[reply]
Oppose in favour of a general custom search engine that searches for all reliable outlets, something WP:WRS was supposed to offer before being abandoned. I proposed a mock-up here, but I will listen to all your suggestions. {{search for}} is great! Szmenderowiecki (talk) 20:24, 25 November 2023 (UTC)Reply[reply]
Oppose, it seems even more paywalled. Nemo 07:12, 29 November 2023 (UTC)Reply[reply]
Oppose per Sdkb, remove individual news outlets. Eddie891TalkWork 15:32, 29 November 2023 (UTC)Reply[reply]
Oppose per SdkB, remove all individual news outlets as source recommendations (we don't do journals or magazines, so there's no need for profit-driven newspapers either). GenQuest"scribble" 07:32, 4 December 2023 (UTC)Reply[reply]
Oppose in favor of removing all individual news outlets, per Sdkb. Epicgenius (talk) 16:57, 12 December 2023 (UTC)Reply[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Participants strongly supported this proposal. They argued that including individual news outlets clutters the template, that search engines can provide links to many different publications at once, and that inclusion of individual outlets gave undue weight to them and the regions they represent. They also highlighted how inclusion could create various unwanted precedents in future discussions.
A small number of contributors in opposition asserted that including well-known examples of reliable sources in the template was important. Supporters refuted this position by noting that it would be difficult to provide a geographically-balanced list of individual publications.
The proposer of the change used JSTOR as an example of a search engine rather than an individual source. One participant commented that they see JSTOR the opposite way (as an individual source rather than a search engine) and suggested removing it. Overall, there was little discussion of the website, so any future changes in its regard would need additional discussion.
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Yikes. Let's take a step back here. As background, the module we're talking about is what produces the links seen mainly at the bottom of the 700k instances of {{Talk header}}. The goal is to help make it easier to find sources on a topic. However, that needs to be balanced with the imperative to keep the links in Talk header as minimized as possible to combat the notorious banner bloat on talk pages. So when we're thinking about which links to include or exclude, the frame should not be "might a few people find this helpful?" but rather "is this essential?"
In light of that, let's consider how people use this template. When I'm searching for sources for a Wikipedia article, I'm not interested only in what The New York Times, or Reuters, or the WSJ, or any other individual news outlet has to say on it (since Wikipedia articles are supposed to summarize all the reliable sources on a topic, not just a single source). So the main link I want to find news coverage is the Google News search, which will turn up those outlets as well as any others. And lucky me, that link already exists in the list, along with other links to places that collect works from many different publications (like JSTOR). The NYT link long stood out as the sole link to an individual source, and frankly including it was a mistake from the beginning. The way to remedy it is to remove it, along with the recently added link to AP, not to add more and more links to try to achieve some sort of balance.
What we're seeing above is the start of a path we don't want to go down, where we establish a new "worthy of Find sources inclusion" tier of source reliability and spend countless hours debating which sources to include in it and end up listing every newspaper of record across the globe to avoid the (legitimate) fears of geographic bias. Let's turn back from that and establish a simple standard that avoids all that ugliness and comports with how people actually do search: Find sources is for collections of sources, not for individual news outlets.
Support as proposer. {{u|Sdkb}}talk 17:02, 24 November 2023 (UTC)Reply[reply]
Support: hell, same. jp×g🗯️ 20:39, 24 November 2023 (UTC)Reply[reply]
that's exactly my point when i raised my objection to nyt back on 13 July 2023 Wikipedia:Village_pump_(proposals)/Archive_203#Replace_nyt_with_reuters. there had never been any argument for why it's chosen over all other sources. yet it took 125 days(!) for enwp to come to a conclusion of adding AP and not removing nyt, and no one has over the 125 days come up with argument for why nyt was chosen over other organisations but only some (Personal attack removed) kept lecturing me.
so here they go, to balance out the 2 american sources, at least 2 non-american must be added. :) RZuo (talk) 07:12, 25 November 2023 (UTC)Reply[reply]
This is why I created {{search for}} to be a comprehensive suite of searches that one can pull out the type of searches that one wants from. And if there's something useful to add to it, we can certainly consider it.
But {{find sources}} isn't the same thing. In the event that the multiple searches of {{search for}} are needed, simply replace {{find sources}} with {{search for}}, which is definitely the workman's multitool here. Otherwise {{find sources}} really should be focussed upon a few broad search engines. It's a spork to the multitool.
It's somewhat questionable that it gives such prominence to Google, which is another reason that {{search for}} exists, but the very reason that I designed {{search for}} as a series of collapsing boxes is that if you add everything in a single line it becomes enormous. I tried that with {{search for}}.
Something that is a single line mid-dot-separated list needs to be minimal, and if you keep adding more and more useful specialist searches to it you'll end up reinventing {{search for}} but badly.
@Uncle G:somewhat questionable that it gives such prominence to Google - see Searx + Startpage.com, as per my comment below. Boud (talk) 13:19, 25 November 2023 (UTC)Reply[reply]
I can imagine Search for replacing Find sources. In fact, I think you could make the tool even better by integrating some tools like WP:WRS, by expanding the scholarly articles section, by integrating the subject-specific recommendations or by emphasising you may get help to find your source. But that one is very good and practically fulfills the same purpose. Szmenderowiecki (talk) 23:25, 25 November 2023 (UTC)Reply[reply]
Comment. I just spent at least three or four minutes at maximum zoom trying to figure out whether bits three and seven (from the left) in the "multitool" photo are star drive, and I can't tell and it's upsetting my professional sensibilities. Even if they are, with only two included you're bound to run into screws you can't undo, either T15 or T20. Folly Mox (talk) 09:41, 26 November 2023 (UTC)Reply[reply]
Support but replace the privacy-violating Google link by a link to either the Searx meta-search news link at Openxng.com, Searx.be and/or Priv.au (alternatively, it should be possible technically to set up a round-robin selection from the best-rated Searx instances listed at https://searx.space), or to Startpage.com (though I don't know of how to directly link to the News section there). Startpage also protects privacy, so would satisfy UCOC, but it does do some advertising, so that would count as advocacy conferring financial benefits, as in the case of Google, with a financial motive for search engine bias in its search results, affecting the neutrality of our finding sources. Boud (talk) 13:16, 25 November 2023 (UTC)Reply[reply]
Support and I see no issue in a longer but more informative template. I only see the use of replacing Google with other browsers if they offer a comparable quality of search or it's slightly inferior but otherwise usable and respects privacy better. Privacy isn't a goal in and of itself, so we must weigh tradeoffs. Szmenderowiecki (talk) 20:24, 25 November 2023 (UTC)Reply[reply]
Yeah, and we already have (sorta defunct) WP:WRS, which was supposed to be a one-stop tool to search all news.
Keep the number of links at the minimum, maximise searching within one custom search engine.
It's not really possible with peer-reviewed articles, but we have Google Scholar and equivalents for that and anyway we should strive to use the best sources we have, right? Szmenderowiecki (talk) 21:10, 25 November 2023 (UTC)Reply[reply]
@Szmenderowiecki:Browsers are not search engines. Google's version of its web browser is getting worse and worse in terms of privacy violation, but that's an independent issue.Boud (talk) 16:31, 26 November 2023 (UTC)Reply[reply]
Support for reduction of clutter. — Bilorv (talk) 20:25, 25 November 2023 (UTC)Reply[reply]
Support per proposer, reduces clutter Sohom (talk) 20:55, 25 November 2023 (UTC)Reply[reply]
Support strongly, especially since there's no reason to emphasize news sources by including many of them - for the vast majority of uses of {{find sources}} news sources might not even be right (let alone US based ones). Galobtter (talk) 21:00, 25 November 2023 (UTC)Reply[reply]
Neutral: ok to remove individual outlets but it doesn't help much when there's a link to Google News which contains all sort of trash. Also support removing JSTOR as another individual outlet that has no business being here alone. Support replacing the links to NYT and AP with a search engine which contains them (preferably with a small manual selection of outlets rather than an automated crawling of news-like websites). Nemo 07:21, 29 November 2023 (UTC)Reply[reply]
Support. Less is more. This is used very widely via templates, and what gets included in it should be of exceptionally broad and global applicability. There should only be tools to actually "find sources" and not any individual source or publisher. Adumbrativus (talk) 04:19, 30 November 2023 (UTC)Reply[reply]
Support per Sdkb. This is a slippery slope. Retswerb (talk) 01:31, 1 December 2023 (UTC)Reply[reply]
Strongly support per nom, Galobtter and particularly the desire to reduce banner bloat. Remagoxer(talk) 15:30, 1 December 2023 (UTC)Reply[reply]
Very Very Strong Support per SdkB, remove all individual news outlets as source recommendations (we don't do journals or magazines, so there's no need for profit-driven newspapers either). GenQuest"scribble" 07:36, 4 December 2023 (UTC)Reply[reply]
Support - per nom and above. (I trust I don't have to individually oppose the other sections if I'm voting support here.) Levivich (talk) 16:52, 4 December 2023 (UTC)Reply[reply]
Support per nom's criticism of banner bloat. The overall proposal rightfully recognizes America-centrism in a widely used template, but the solution cannot be adding the top English publications of each country BluePenguin18 🐧 ( 💬 ) 18:50, 4 December 2023 (UTC)Reply[reply]
Support to avoid inappropriate product placement and because I doubt anyone actually needs these links to find sources. – Joe (talk) 13:28, 5 December 2023 (UTC)Reply[reply]
Support Only including certain RS and not others violates NPOV, and the generic links are good enough for this purpose. QuicoleJR (talk) 14:19, 6 December 2023 (UTC)Reply[reply]
Support - Honestly, I don't think we should be giving any outlets any undue attention, as it may violate NPOV as mentioned above. Also, as others have mentioned, this will reduce link clutter as well. Epicgenius (talk) 16:57, 12 December 2023 (UTC)Reply[reply]
Support. It's prejudicial toward certain corporate "voices" in the news sphere (and certain countries' news), plus it would just continue to grow into an increasingly long list of such news outlets, which ultimately are redundant with the Google News link (though I wouldn't mind seeing that replaced by something that isn't subject to Google's own skewing, and using Microsoft's or Yandex's equivalent wouldn't help but just shift the problem of whose skew we're buying into). Maybe replace all these Google search types with DuckDuckGo ones, if we trust DDG more. — SMcCandlish☏¢ 😼 21:41, 18 December 2023 (UTC)Reply[reply]
Oppose. I think picking representative examples is very important—it seems totally useless to force a less useful presentation solely to create an appearance that information need not come from anywhere in particular. We don't get to freely choose where information we can use comes from or how we can get it. Yes, you can characterize a mention of a particular entity as promoting it, sometimes obviously, sometimes only in an abstract sense—but no one can actually take the reasoning here to its logical conclusion. It is uncomfortable that we rely on certain outlets to create Wikipedia, but I'm sorry to say that there is no intellectually honest remedy for this discomfort, only ways to obscure it. This change is arbitrary; the generic links only push the problem people seem to have back a singular step. Remsense留 21:56, 18 December 2023 (UTC)Reply[reply]
Oppose and I am in full agreement with Remsense. The sources in the module are helpful as the results from those links are narrowly-focused to meet the reseach needs of editors of this project, namely to provide independent, reliable source. We are frequently advised that this project does not right great wrongs, whether in terms of political or societal issues, nor in this case about the dominance of corporate voices in our media landscape. --Enos733 (talk) 00:36, 19 December 2023 (UTC)Reply[reply]
I don't really understand how this came to be a right-great-wrongs issue. We don't dispute NYT or AP is good, but if you need coverage from, say, Serbia, Poland or Canada, then using NYT or AP is kinda suboptimal compared to using local reliable outlets, which obviously cover local stuff better. Also, the framing about "corporate voices" is simply misguided. This is not the problem. The problem is that we choose to advertise only one voice among hundreds that are valid, and which WP:RSP recognizes are valid. It is also about creating a more versatile search tool. If among all sources they decide to choose NYT, we can't help it, but we should first offer a choice we don't really give right now. Instead we are suggesting "use NYT and AP". Adding individual outlets will just make the template needlessly bloated. Szmenderowiecki (talk) 10:37, 23 December 2023 (UTC)Reply[reply]
If you look at the discussion, there are several people who support removal to remove corporate voices or that somehow listing any outlet is a POV issue. - Enos733 (talk) 12:40, 23 December 2023 (UTC)Reply[reply]
I acknowledge that. As I said, for me the "corporate voices" thing is misguided. I can potentially agree with POV concerns for listing individual outlets if we are speaking about WP:SYSTEMICBIAS, which this diversification could help combat if only a little (the ultimate choice of sources still rests with the editors, and the source of that bias is mostly editors). Szmenderowiecki (talk) 16:20, 23 December 2023 (UTC)Reply[reply]
What I could agree with, if this could be implemented easily, is a way to personalize the search links. - Enos733 (talk) 01:29, 24 December 2023 (UTC)Reply[reply]
What do you mean by "personalise"? Doing Google's work all over again is not feasible. If you mean something like a dropdown list where you could tick the relevant boxes, I'm not sure Google's custom search engines can do that but maybe there are other techniques.
Probably the best would be to sort these outlets by regions (North America, Latin America, W Europe, Central-Eastern Europe, Middle East, Indian subcontinent, E Asia, Australia and Oceania, Arab Africa, Central Africa, S Africa; and a general one). I think it would be beneficial for editors to see all news outlets and not simply let them cherry-pick the ones that align with their preconceived notions and POV, or for that matter only choose the most famous ones at the detriment of others thst also do good journalism. Szmenderowiecki (talk) 18:36, 24 December 2023 (UTC)Reply[reply]
Support news outlets are not good general sources, full stop. (t · c) buidhe 02:17, 27 December 2023 (UTC)Reply[reply]
Support removing all individual outlets, those present are too America-centric. Stifle (talk) 14:25, 3 January 2024 (UTC)Reply[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
In this discussion, participants established a rough consensus against replacing the generic link for search. Participants who supported replacing it cited concerns about user privacy, potential systemic bias of Google's search engine, and some alternative websites were suggested. Those in opposition to the generic link being replaced argued that Google is the best overall search engine presently out there, that no suitable replacement to Google that is of comparable quality exists, and that the tradeoff here in terms of usability weighs in favor of maintaining google. Some participants noted that they would approve of adding links of general search engines in addition to the generic Google link (rather than in replacement of the generic Google link), though no affirmative consensus to do so was reached in this discussion. — Red-tailed hawk(nest) 05:54, 12 January 2024 (UTC)Reply[reply]
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
The generic link to Google violates Wikipedians' privacy (storing detailed private data for the purpose of sales to advertisers), which is contrary to the spirit of UCOC; like any individual search engine, it is subject to search engine bias that biases our selection of sources, and it uses filter bubbles targeted to each individual, tending to amplify existing demographicbiasesin Wikipedia. We could either give a link to list of search engines or choose a meta-search engine that gives high-quality general search results while protecting user privacy, reducing the bias to any particular engine, and avoiding filter bubbles. Boud (talk) 13:48, 25 November 2023 (UTC) Clarify: this section is only for the generic link, not for the specific links for news, books or scholarly sources. Boud (talk) 16:10, 26 November 2023 (UTC)Reply[reply]
Support as proposer. Suggest either (1) list of search engines, or (2) the Searx generic link at Openxng.com, Searx.be and/or Priv.au, or if a pseudo-random generator can be linked up to the module (should not be difficult with e.g. /dev/urandom, which is fast), use a round-robin selection from a list of e.g. 10 of the best-rated Searx instances listed at https://searx.space), or (3) Startpage.com. The round-robin solution with Searx would keep the link compact (5 characters) and would statistically reduce the bias of any individual Searx instance implicit in the way it is configured and run. Boud (talk) 13:48, 25 November 2023 (UTC)Reply[reply]
Given that Searx is not longer maintained, security vulnerabilities would not be widely reported and addressed in a timely manner. Furthermore, with such low market share, the Searx links you have provided would undoubtedly scare editors into suspecting they have been redirected to malware. While the random assignment to Searx instances increases privacy, this approach is unfamiliar to the average editor that expects links to consistently route them to the same specific site BluePenguin18 🐧 ( 💬 ) 19:11, 4 December 2023 (UTC)Reply[reply]
@BluePenguin18: The main development of Searx shifted to Searxng, which is actively maintained; currently there are 882 closed bugs vs 183 open bugs and the master branch is updated every few days or so. Searx.space only lists Searxng instances. Education of editors is worth the price of protecting their privacy; those who actually check URLs are likely to know enough to be able to search further for an explanation and learn. There's also the option of Wikimedia techies running a searx instance: https://searx.wikimedia.org. Boud (talk) 02:28, 10 December 2023 (UTC)Reply[reply]
@Boud Thanks for the clarification on Searxng! I would support a Wikimedia instance of Searx being offered alongside Google Search to comply with WP:ASTONISH, providing curious editors an opportunity to learn about and choose meta-search engines while still offering the currently dominant option BluePenguin18 🐧 ( 💬 ) 05:10, 10 December 2023 (UTC)Reply[reply]
Oppose. Google Search has plenty of problems that make it non-ideal, but it has over 90% market share. At that level, it's what editors expect, so providing anything else would go against WP:ASTONISH. Google also leverages its market dominance to provide better results in some cases, and editors' familiarity with it makes it easier for them to use. The metasearch engine idea is intriguing, but I wasn't impressed when I tested it just now. Searching for "Wikipedia" and navigating to the news tab produced results like this. Linking to the list of search engines is a nonstarter. The entire point of these links is to make searching for sources easier (to encourage more people to do it or just to add convenience). The current setup goes instantly to the Google results for the topic, whereas linking to the article would then require people to navigate to the search engine they want, click through to its article, click the external link to its site, and then re-enter the search term. At that level of inconvenience, people are just going to type the search query into their browser instead, bypassing the template and making it useless as a convenience aid. {{u|Sdkb}}talk 17:34, 25 November 2023 (UTC)Reply[reply]
Just to check what the actual arguments presented here are against the Searx proposal. They seem to be: (1) Google is dominant and it's what people expect; (2) anecdotal evidence. Boud (talk) 16:26, 26 November 2023 (UTC)Reply[reply]
As of September, Searx's github repo is no longer maintained. I'm not real familiar with the project, but surely that's bound to be an issue moving forward if we were to use it as the sole replacement for Google search? Any replacement for the sole link should be something with staying power. Retswerb (talk) 01:29, 1 December 2023 (UTC)Reply[reply]
See above: Strictly speaking, Searx is closed, replaced by Searxng. When I said "Searx" above, formally speaking I was referring to Searxng software and instances. Boud (talk) 02:30, 10 December 2023 (UTC)Reply[reply]
Oppose. Privacy isn't a goal in and of itself. I want to see the balance we trade between utility and privacy. If otherwise equal, obviously switch from Google but prefer utility in the balancing equation. Szmenderowiecki (talk) 20:24, 25 November 2023 (UTC)Reply[reply]
If we balance between utility and privacy, then privacy is a goal (among others). Boud (talk) 16:33, 26 November 2023 (UTC)Reply[reply]
A goal that I believe is secondary to utility, which is the primary goal (find as many sources as you can). You can believe we should prioritise privacy even to the detriment of utility, which is fine but I think few people will share your view.
Also, {{search for}} already includes a couple of search engines outside Google. You can suggest a couple more there. Theoretically if there is independent confirmation that startpage.com is equivalent to Google but is more privacy-friendly, why not? We can change the link.
But my testing of relatively obscure topics I mentioned (e.g. reasons why few people live in Tasmania) showed that most alternatives simply performed worse. Now whether Google (or Microsoft, Apple or whatever) abused its market dominance is basically irrelevant for me, because the point is to find data and (hopefully) let users exercise best judgment in choosing.
I need to see that any of the SearX, Mojeek or other search engines are good enough to use. This also applies to searches in languages other than English, so if the engine is optimised for English but sucks in Russian, it's not good enough. Szmenderowiecki (talk) 18:41, 26 November 2023 (UTC)Reply[reply]
In principle, OK to let users exercise best judgment in choosing, but the search engine bias in the results that the users have to choose from only makes it easy for them to use judgment within that biased selection. A mix of biases (via a meta-search engine) should tend to reduce the overall bias.Searx is not a search engine, it is a metasearch engine. Mojeek is a search engine.As for other languages, given that in English a very sort of notorious example is when the Google search engine was categorizing black people as monkeysper a Princeton engineering interview, the case of Timnit Gebru's exit from Google, and the Santa Clara University advice Search engines and artificial intelligence are neither neutral nor free from human judgment, I see no reason to trust Google to be better in non-English languages than in English. Financial reasons suggest the opposite: paying fluent speakers of small-population languages of poor countries won't contribute much to Google/Alphabet advertising revenue. Boud (talk) 19:35, 26 November 2023 (UTC)Reply[reply]
Oppose This proposal feels a bit wikilawyery especially bringing up the UCOC which has nothing to do with this proposal. Given everything being equal, I would definitely support using alternative engines (or atleast giving users the options to do so). However, this is not the case, instead results from other engines tend to be inferior or outright non-existent for certain search terms. Additionally, a geographical bias can actually sometimes help editors who live in specific regions find better sources (Annecdotally, I have a easier time digging up sourcing about Indian topics if I switch to my Indian registered internet connection when I am in other countries.) -- Sohom (talk) 21:09, 25 November 2023 (UTC)Reply[reply]
If there's consensus to continue violating UCOC - and in fact I expect that there will be consensus to continue to at least partially violate UCOC by keeping at least one or two Google links - then we'll find that out. WMF will have to fight us if it wishes to fully implement UCOC. Recommending that other Wikipedians violate their privacy is disrespectful and risky, e.g. it's inconsistent with ensuring that the Wikimedia projects are productive, pleasant and safe spaces, and contribute to the Wikimedia mission. It's not safe to be encouraged to violate your personal privacy. To make an analogy: suppose you're invited to a Wikimedia community face-to-face workshop and on entry to the room, there's someone at the door who asks you to take off all your clothes. Whether Google's privacy invasion into your mind - your browser history and browser parameters - is worse or better than a violation of your bodily privacy is a matter of judgment, but both cases are privacy violations. Boud (talk) 19:57, 26 November 2023 (UTC)Reply[reply]
@Boud You've lost me at the analogy. Giving up ones privacy is not akin to sexual harrasment, linking to the UCOC's harrasment clause and giving examples of sexual harrasment as a analogy is not going to change that fact.
The {{find sources}} template links are just suggestions/convinience links for good places to find sourcing, you are welcomed to ignore it completely and use your own search engines (in fact I do so myself most of the times, even when using Google). I would liken it more to being offered a milk-coffee at a Wikimedia event, when I myself am lactose intolerant (I am not, but hypothetically speaking). Sohom (talk) 14:07, 30 November 2023 (UTC)Reply[reply]
Oppose Google search/news/scholar/books are very good for finding sources and any replacement has to have similar quality. Galobtter (talk) 21:11, 25 November 2023 (UTC)Reply[reply]
Oppose. A pretty normal WP:BEFORE would probably include Google news, Google books, and Google scholar. Removing links to Google would make this workflow inefficient. At a minimum, equivalent search engines that search news articles, books, and academic papers should be proposed. A general "let's get rid of Google" with no suggested replacement, in my opinion, is not the way to go. –Novem Linguae (talk) 02:00, 26 November 2023 (UTC)Reply[reply]
This proposal is only for the generic link. That is independent of the specific links for news, books and scholarly sources. The above section (so far) seems to be only about news links. Boud (talk) 16:10, 26 November 2023 (UTC)Reply[reply]
Support replacing Google search with (pretty much) anything else. Linking Google means we're letting advertisers decide what ends up used as source in Wikipedia, an obvious source of systemic bias. If people think a direct link to a web search is needed for people's workflows, DuckDuckGo would be an improvement on the current state. DuckDuckGo introduces less systemic bias because it generally doesn't personalise results based on user fingerprinting and doesn't serve automatically generated prose or other non-sources into the "search results" page. Nemo 07:12, 29 November 2023 (UTC)Reply[reply]
This is misguided. By not personalizing, all users would get the same search results for the same query, reducing the variety of sources used on Wikipedia. While Wikipedia faces systemic bias for its disproportionate share of cis, white, and male editors, the diversity that does exist generates alternative advertiser profiles to see unique sources BluePenguin18 🐧 ( 💬 ) 19:11, 4 December 2023 (UTC)Reply[reply]
So this argument is that by violating Wikipedians' privacy in tracking and recording their habits (in some cases) as being non-cis-white-male, these Wikipedians will select from sources that help create source diversity, but will to the same degree statistically out their gender/social-group profiles, whether they wish it or not. This makes the UCOC violation even worse: it's not just that Wikipedians are encouraged to give their browsing habits to an organisation known for tracking this to great detail, but those browsing habits risk being (statistically) revealed in their choice of sources. Machine learning applied to Wikipedians' selection of sources could suggest their likely Google gender/group profiles. For Wikipedians living in some countries and editing en.Wikipedia, this puts them at risk of prison or death. Boud (talk) 02:54, 10 December 2023 (UTC)Reply[reply]
I might be misunderstanding this argument, but are you suggesting that oppressive regimes will be targetting Wikipedians living under their rule by trawling through contributions and compiling a list of sources added per account name, and then reverse engineering those accounts' possible google profiles based on the sources they've added? Folly Mox (talk) 04:24, 10 December 2023 (UTC)Reply[reply]
Not will, but could; and not trawling by hand, but rather intelligently doing analysis using a mix of software and human thinking. Actions such as the Saudi infiltration of Twitter - or Google - will not always work and they risk embarrassment. To the extent that Google's filter bubbles characterise Wikipedians' profiles and improve diversity in the selection of sources (the point made by BluePenguin18), there would, in principle, be a signal, by definition.Suppose that Wikipedian X is LGBT, that the Downtown Post Daily Times strongly promotes LGBT content, as well as news content unrelated to LGBT issues, and is accepted as a WP:RS in Wikipedia, but X is unaware of the LGBT aspect of the DPDT (it's not obvious in the name). Then Google often gives X sources from DPDT (which buys lots of Google ads), and X often uses them in Wikipedia, unaware that other Wikipedians get DPDT links from Google much more rarely. Boud (talk) 13:47, 10 December 2023 (UTC)Reply[reply]
Even when machine learning models become capable of identifying editors' characteristics based on their choice of sources, it would simpler and more accurate to surveil their list of top edited pages. When the Saudi government infiltrated the Arabic Wikipedia's administrator community, they took the simplest approach to content control by looking at what specific editors were writing. BluePenguin18 🐧 ( 💬 ) 20:02, 10 December 2023 (UTC)Reply[reply]
Some editors may deliberately attempt to hide their interests by editing Wikipedia in a way that hides their (in this hypothetical case) LGBT profile, but some of their general non-Wikipedia searches will be for LGBT material. We get back to the case of our hypothetical editor unintentionally using DPDT as a source for a non-LGBT Wikipedia article, unaware that this is a statistical clue to being LGBT. Whether or not this is the best way to identify people to for arbitrary arrest and torture, it's available in the record. Boud (talk) 18:52, 13 December 2023 (UTC)Reply[reply]
@Boud: You gotta stop bringing up the UCOC thing. It's not helpful. I try not to inject myself in every conversation involving the UCoC, but I won't be able to sleep tonight if I don't correct the absolute absurdity that is your reply: If there's consensus to continue violating UCOC - and in fact I expect that there will be consensus to continue to at least partially violate UCOC by keeping at least one or two Google links - then we'll find that out. WMF will have to fight us if it wishes to fully implement UCOC. I've spent hours of my life having discussions with the WMF and the community about the UCOC. What you are suggesting is so far removed from anything a rational person would even consider when enforcing it. There is zero possibility of anyone of applying it to this case; most especially not the WMF. Your logic here is so twisted and nonsensical that I'm embarrassed to even feel the need to respond. –MJL‐Talk‐☖ 06:55, 13 December 2023 (UTC)Reply[reply]
I don't see any arguments here explaining why encouraging Wikipedians to violate their privacy and thus put themselves at increased risk of harm is consistent with the spirit of UCOC; absurdity ... twisted ... nonsensical are not arguments. Boud (talk) 18:52, 13 December 2023 (UTC)Reply[reply]
The amount of logical assumptions you have to make to get where you are at is indeed absurd, twisted, and nonsensical. Adding a link to a Google search is not encouraging Wikipedians to violate their privacy (as has already been explained to you). Even if it was, the spirit of the UCoC (if there can be such a thing) which you keep referring to would not be violated nor enforced. I know this because I co-wrote the enforcement guidelines. –MJL‐Talk‐☖ 18:55, 14 December 2023 (UTC)Reply[reply]
Support the idea of replacing the generic google link with some sort of list of search engines. We already do this when providing links to ISBNs and co-ords. Rather than picking what search engine people use, we can present them with a list of options. I'm not convinced any Google alternative is actually good enough to fully replace the link to google, especially recognizing its sheer market dominance (it will be what many people expect to find and use). Eddie891TalkWork 15:36, 29 November 2023 (UTC)Reply[reply]
Oppose replacing Google: The top searches on Bing, and likely most other search engines is "Google". Meet the reader where they're at. Mach61 (talk) 05:41, 30 November 2023 (UTC)Reply[reply]
Oppose As much as I dislike the corporation, it is the best overall source of sources. O3000, Ret. (talk) 19:38, 1 December 2023 (UTC)Reply[reply]
Whether or not a search template not used in article content contains a hyperlink to Google has nothing at all to do with verifiability. Even if this template didn't exist at all, stuff could still be verifiable. Uncle G (talk) 14:56, 11 December 2023 (UTC)Reply[reply]
Oppose - As much as Google may have plenty of privacy issues, that is a separate matter from whether it is useful, which it is. Thus, I don't see a reason to remove it at this time. I would support adding different search engines like Bing or Yahoo if there were consensus for it, though. Epicgenius (talk) 16:57, 12 December 2023 (UTC)Reply[reply]
Support adding links to other search engines; the current google search engine is deeply flawed. The list of search engines should continue to include google -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 15:13, 13 December 2023 (UTC)Reply[reply]
Oppose The generic search link can be valuable to editors. There is no replacement in this proposal, just removal. --Enos733 (talk) 12:44, 23 December 2023 (UTC)Reply[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
There are two orthogonal issues here, reliability and coverage of sources (which is core encyclopedia stuff) and search engines' respect for privacy (which is a user preference). This is unlikely to lead to a productive conversation. Personally I think we should recommend source-finding techniques on a per-wikiproject basis. We need to look in different places for sources for a contemporary American biography, a 20C New Zealand law, a 19C Malay biography, an 18C German political scandal, a 17C book and an ancient Middle Eastern location. Seems likely to me that we can come up with a per-user preference for generic search engine privacy and then parameters to help find specific content (bot-assisted based on cats and wikiprojects). Stuartyeates (talk) 19:14, 25 November 2023 (UTC)Reply[reply]
It's true that there are two orthogonal motivations, and you are probably right that a tech solution may be able satisfy both. The idea of a per-user preference parameter for search engine privacy, that would be used by the module to switch between privacy-violating and privacy-respecting search engines and meta-search engines, is good. This would need techie willingness to implement it. There would also be the question of which setting should be the default: should selecting privacy be opt-in or opt-out? Boud (talk) 20:13, 26 November 2023 (UTC)Reply[reply]
If we think this is going to be a popular subject (~50 editors?), please copy/paste it to a subpage before adding an RFC tag. This page was recently nearly a million bytes long, and that makes it very difficult for people to read (especially on smart phones). The most popular title is Wikipedia:Requests_for_comment/YOUR-THING-HERE (see examples), but it's okay to do Wikipedia:Village_pump_(proposals)/YOUR-THING-HERE if you prefer. WhatamIdoing (talk) 18:59, 24 November 2023 (UTC)Reply[reply]
I think this first should have an RfC tag before we move it to a subpage of VPR. People won't know of this discussion if we hide it in a subpage. Szmenderowiecki (talk) 21:12, 25 November 2023 (UTC)Reply[reply]
If it's an RFC, people will know about it no matter where it happens. The Wikipedia:Feedback request service posts personalized messages to editors' talk pages about RFCs in subject areas that interest them. But I agree (and, more importantly, so does WP:RFC) that it would be good to keep a link here, especially if the discussion starts here and gets moved. WhatamIdoing (talk) 23:20, 26 November 2023 (UTC)Reply[reply]
Maybe this should be done reactively rather than proactively. That is, wait for sections to get big, then put them on a subpage. –Novem Linguae (talk) 02:05, 26 November 2023 (UTC)Reply[reply]
@Novem Linguae, do you have a preferred number for "big"? There are already more than 50 comments in this section. WhatamIdoing (talk) 23:22, 26 November 2023 (UTC)Reply[reply]
Exactly how many news sources are deemed reliable by Wikipedia & which ones are they? GoodDay (talk) 16:28, 23 December 2023 (UTC)Reply[reply]
RfC: disallowing new signatures obsolete tags[edit]
The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion.A summary of the conclusions reached follows.
There is clearconsensus in favor of the proposal. Any remaining technical questions can be worked out during implementation. (non-admin closure) {{u|Sdkb}}talk 20:40, 24 December 2023 (UTC)Reply[reply]
Background/details (disallowing new signatures obsolete tags)[edit]
In 2020, as part of the DiscussionTools project, signature validation was added to MediaWiki. Since its implementation, users have been unable to save an invalid signature in Special:Preferences (invalid signatures saved beforehand are still allowed). Currently, the validator disallows every WP:LINT error except for obsolete-tags. (The most commonly used obsolete tag is <font>...</font>, but <tt>...</tt>, <center>...</center>, and <strike>...</strike> are also obsolete.) This proposal would eliminate that exception. Pre-existing signatures would not be affected by this proposal.
Survey (disallowing new signatures obsolete tags)[edit]
Support as proposer. Bots (and humans) are currently fixing obsolete-tags en masse, and this was backed by community consensus in February. I believe this change should appeal to people on both "sides" of that debate. If you support fixing obsolete tags, the benefits are obvious. If you oppose fixing obsolete tags, fixing them is already backed by community consensus. This change would help limit the amount of lint that bots need to fix.Additionally, WP:SIGFONT is already part of the signature guidelines. This would simply enforce that section techincally. HouseBlastertalk 01:10, 3 December 2023 (UTC)Reply[reply]
Support, if bots are already fixing them what's the point in allowing them? — Alexis Jazz (talk or ping me) 01:18, 3 December 2023 (UTC)Reply[reply]
Support, these are already deprecated in terms of browser support, and the day will come that support for them is dropped entirely. This is a good step to ensure those who may not know that are not negatively impacted by such a change, and eliminating the need for linter bots to make needless edits fixing them. SeraphimbladeTalk to me 04:35, 3 December 2023 (UTC)Reply[reply]
Support, use of obsolete tags cause too much drama. BilledMammal (talk) 05:03, 3 December 2023 (UTC)Reply[reply]
Support When saving edits, edits that contain lint errors should be blocked too Killarnee (talk) 14:23, 3 December 2023 (UTC)Reply[reply]
Support: Seems like a no-brainer to me. It's just real signature validation, plus this'll reduce needed resources by bots as there'd probably be less signatures that need fixing. Aaron Liu (talk) 16:03, 3 December 2023 (UTC)Reply[reply]
Support I'm kind of iffy on the whole fixing obsolete tags thing (I kind of doubt browsers will ever drop support for it), but we should what we can to prevent new additions of these. Galobtter (talk) 16:32, 3 December 2023 (UTC)Reply[reply]
Weak SupportEhhh - this should be dealt with WMF-projects wide or not at all. — xaosfluxTalk 18:56, 3 December 2023 (UTC)Reply[reply]
I assume the response to a global proposal would be "not without enwiki consensus", and there's nothing in this proposal preventing a later global one. ~ ToBeFree (talk) 22:56, 3 December 2023 (UTC)Reply[reply]
OK sure, don't think this is that big of a deal but if it's going to reduce bot edits then sure. — xaosfluxTalk 10:56, 4 December 2023 (UTC)Reply[reply]
Support as someone who spends a lot of time fixing Linter errors. It has been frustrating to watch new errors introduced into pages when we have such a huge backlog (3.6 million listed errors currently). Turning off the flowing tap of obsolete tags in signatures is a way to stem the flow when the bathtub of errors is overflowing. – Jonesey95 (talk) 23:28, 3 December 2023 (UTC)Reply[reply]
SupportWe should definitely prevent new additions, I'm surprised that this is not already the norm.Sohom (talk) 01:41, 4 December 2023 (UTC)Reply[reply]
Support Anything to reduce pointless addition of deprecated syntax, with subsequent time-wasting fixes, would be good. Johnuniq (talk) 04:07, 4 December 2023 (UTC)Reply[reply]
Support - regardless of how one feels about the urgency of fixing existing obsolete tags, it makes sense for Wikipedia to stop adding new obsolete tags to its pages. Long overdue, thanks for proposing this, HB. Levivich (talk) 05:23, 4 December 2023 (UTC)Reply[reply]
Support - My signature formerly used those tags to get under the maximum length. While as a web dev I knew they were outdated, I thought they were relatively harmless in this context (as browsers will continue to support them for compatibility) and didn't realise they were discouraged on enWP until another user gave me a heads up. If bots are already changing these tags the proverbial ship has already sailed regarding their usage. ― novov(tc) 02:38, 7 December 2023 (UTC)Reply[reply]
You could subst the font template to cut down on some chars to maybe make it fit. Aaron Liu (talk) 12:09, 7 December 2023 (UTC)Reply[reply]
Aaron Liu, surely that would be bypassing the signature limit (WP:SIGLENGTH: please be careful to verify that your signature does not violate the 255-character length limit when the templates are expanded, as the software will not do this automatically). — Qwerfjkltalk 18:35, 7 December 2023 (UTC)Reply[reply]
Support. We are already fixing these sigs (which was also approved in a recent RfC). Disallowing new ones to be introduced will reduce the amount of work needed and the "watchlist spam" issue some editors were complaining about. --Gonnym (talk) 12:30, 7 December 2023 (UTC)Reply[reply]
Support. I'm not convinced on the necessity of fixing lint errors on old talk pages, but stopping new ones seems more worthwile. -- LCU ActivelyDisinterested«@» °∆t° 19:05, 7 December 2023 (UTC)Reply[reply]
Support, as long as there is a crystal clear error message linking to mw:Help:Lint_errors/obsolete-tag or similar that can be understood even by someone who started editing yesterday and has tried to emulate the non-compliant signature of their favourite long-term editor. Certes (talk) 12:15, 8 December 2023 (UTC)Reply[reply]
Support Good idea Isla🏳️⚧ 13:20, 10 December 2023 (UTC)Reply[reply]
Support Since we should be designing Wikipedia for browsers that almost all people use (Chrome/Edge 120, Firefox 120, Safari, etc.). We should aim for modern web compliance including HTML5 and ES6 compliance. AwesomeAasim 15:40, 12 December 2023 (UTC)Reply[reply]
Discussion (disallowing new signatures obsolete tags)[edit]
@HouseBlaster: Please add a couple more words to the RFC question. It could be read as preventing me from changing my signature to one that has an obsolete-tag lint error, or it could be read as preventing a current user who has an obsolete-tag lint error from signing a new comment. I know the background explains that, but a word or two more might help. Johnuniq (talk) 01:16, 3 December 2023 (UTC)Reply[reply]
I just pinged you because you participated in the earlier discussion; this change would not impact you at all. HouseBlastertalk 21:56, 3 December 2023 (UTC)Reply[reply]
HouseBlaster, I thought Q1 was going to go first, did I miss it? — Alexis Jazz (talk or ping me) 01:21, 3 December 2023 (UTC)Reply[reply]
Oops. Mentally I had this one going first... my bad. I think this order is better because this one does not require mass messages (because it only impacts people in the future). That brings two benefits: one, we only have to generate a list/write a message/etc. once. Two, people whose signature are both invalid under the current criteria and contain <font>...</font> tags would not be double mass-messaged. HouseBlastertalk 21:56, 3 December 2023 (UTC)Reply[reply]
FRS recipient: My main question is how exactly would that work? If someone included <tt>...</tt> in their signature, would they just get an error message, or would it prompt them to replace the tag with {{mono|}}? Seeing as this could be one of the earliest things someone does after creating an account, we absolutely do not want to make them dive into the wikipedia help documentation to track down accomplishing their preferred signature, especially if they see existing accounts' signatures still using the deprecated functionality before they've been fixed by bot. VanIsaac, GHTVcontWpWS 03:10, 3 December 2023 (UTC)Reply[reply]
I see nothing wrong with shoving headlong into formatting syntax documentation any newcomers whose first orders of business on the website include fancy sig customisation. Folly Mox (talk) 04:19, 3 December 2023 (UTC)Reply[reply]
The issue is when syntax that a new editor sees working for someone else won't work for them. The deprecated html tags work just fine when they make a comment, but for some reason there is an exception when it comes to their signature, but not anyone else's. That's a distinctly WP:BITEY behavior for the interface. VanIsaac, GHTVcontWpWS 08:27, 3 December 2023 (UTC)Reply[reply]
Aren't bots already fixing such signatures with deprecated tags? Aaron Liu (talk) 16:03, 3 December 2023 (UTC)Reply[reply]
@Vanisaac, if you have a disallowed sig (and this RFC proposes to expand what's considered disallowed by software), and you leave a note on the talk page, it will just use the normal, default sig (e.g., like mine, like Folly Mox's, like Johnuniq's). It won't bother you about it; it'll just ignore your disallowed sig and quietly substitute the default.
If you notice it and try to update your prefs, it will not let you save an improper custom sig. It will give you an error message then. Consequently, one approach is that you just try to fix it until you hit upon something that the system will accept. If solving it by the trial-and-error method seems unappealing, then the editor can ask for help. Most people do this at Wikipedia talk:Signatures or Wikipedia:Village pump (technical) or a friend's page.
So that seems like the most unhelpful functionality imaginable. VanIsaac, GHTVcontWpWS 08:27, 3 December 2023 (UTC)Reply[reply]
Why? The options are:
Don't restrict anything in software, or
Restrict invalid sigs in software, and if you happen to have an invalid sig, then prevent you from using talk pages until you fix it (e.g., throw an error message after you have already typed a comment), or
Restrict invalid sigs in software, and if you happen to have an invalid sig, then keep letting you use talk pages with a known-valid sig.
Interfering with normal use of the wikis until you debug your sig would be my candidate for a "worst approach" prize.
As Alexis Jazz corrects below, the first step is to stop people from adding new invalid sigs to their prefs. We could stay in that state for years. WhatamIdoing (talk) 20:18, 3 December 2023 (UTC)Reply[reply]
No, the options actually are:
Do nothing.
Restrict new non-standard sigs, but provide instant feedback on what the problem is and a direct link to a tool tip or the section on the help page that shows you how to accomplish what you are trying to do using current standards and has updated content that would let that user know that some of the solutions won't be valid in signatures.
Restrict new non-standard sigs, providing the same feedback and help AND at some time implement a system to require old editors with non-standard formatting to also update those sigs, providing the same helpful guidance thereby lessening the workload on lint fixing bots.
Restrict new non-standard sigs but implicitly say by your omission of any help or suggestions "ha ha, you saw something somebody else did that you want to do, but we don't allow that any more, but only for new guys, and we're not going to tell you what you did wrong or how to fix it. So fuck you as you try to track down what it is that you did wrong and how to fix it, or you can just give up and become disillusioned with a site that is so massively hostile to new contributors."
If the choice is between fuck you and do nothing, doing nothing is vastly superior as a choice. VanIsaac, GHTVcontWpWS 18:55, 6 December 2023 (UTC)Reply[reply]
The linter already will provide you with a help page to the relevant error when it detects lint errors. In this case, it’ll probably direct you to mw:Help:Lint error/obsolete-tag. I don’t see why you think it’s a choice between whether or not to “fuck you”.I just tested, and it should say “Your signature contains invalid or deprecated HTML syntax” along with a list of problems with a “learn more” link button for each. Aaron Liu (talk) 19:54, 6 December 2023 (UTC)Reply[reply]
Well, the "fuck you" option is what Folly Mox gave me when I specifically asked about how this proposal would be implemented. So maybe you need to get your ducks in a row and give me a straight answer on how this proposal will be implemented. What exactly does the linter tell you? When does it tell you? How does it tell you? How can we make more useful information available? Should we have a validation wizard that would output code fixing linter errors that we could point these new signature editors to? If the intent is to not give a "fuck you", then we need to actually back that up with our actions. VanIsaac, GHTVcontWpWS 20:18, 6 December 2023 (UTC)Reply[reply]
Firstly, I think Folly Mox meant just giving them a link to the relevant doc page when they said shoving. Secondly, just look at this screenshot I found by simply searching "signature lint" on commons (though there has been a very minor difference: instead of bullet points, the extension uses a numbered list now.) Aaron Liu (talk) 23:06, 6 December 2023 (UTC)Reply[reply]
The behavior depends on what stage things are at. In the stage that prevents the creation of new bad sigs, you get instant feedback. That feedback may or may not be understood, but it is instant and provided in bold-faced red letters. In the stage in which old bad sigs are no longer accepted, it silently switches to the default, known-good sig. WhatamIdoing (talk) 07:21, 10 December 2023 (UTC)Reply[reply]
The latter stage seems like a separate RfC. The former's feedback seems pretty clear to me. Aaron Liu (talk) 16:48, 10 December 2023 (UTC)Reply[reply]
After the conclusion of this RfC (regardless of if it is successful or not), I plan to propose that we apply the signature validation rules retroactively (after affected users are mass messaged with pertinent info). Both of these proposals are a simple config change; the retroactive option would default invalid signatures to MediaWiki:Signature, e.g.
This is an example message with a default signature. Example (talk)
How would you know which users to mass message? Aaron Liu (talk) 12:19, 7 December 2023 (UTC)Reply[reply]
Quarry; you can see a partial report at toolforge (note that sig-too-long-post-subst and some of Line breaks would not be affected).HouseBlastertalk 00:15, 8 December 2023 (UTC)Reply[reply]
Wait, that signature length detection is possible and disabled‽ Aaron Liu (talk) 11:57, 8 December 2023 (UTC)Reply[reply]
No, they are not detected/disabled. That's why they would not be affected.HouseBlastertalk 16:55, 8 December 2023 (UTC)Reply[reply]
No, I mean that the substituted length detection is disabled. I really wonder why. Aaron Liu (talk) 17:49, 8 December 2023 (UTC)Reply[reply]
WhatamIdoing, looking at Note that the scope of this proposal has been narrowed to only impact newly saved signatures. it seems users who already have obsolete tags in their signature can continue to substitute that signature on talk pages, they just won't be able to adjust it in their preferences. But presumably if this passes we'll see another proposal down the line to end that grandfather clause. Unless the number of signatures that bots need to adjust ends up being really really low, in which case it could be a non-issue. — Alexis Jazz (talk or ping me) 10:05, 3 December 2023 (UTC)Reply[reply]
Out of curiosity, how would one set one's username's font in their signature without the font tag? — Red-tailed hawk(nest) 05:55, 4 December 2023 (UTC)Reply[reply]
To save people the click: <font face="foobar"> can be rewritten as <span style="font-family:foobar;">.HouseBlastertalk 13:34, 4 December 2023 (UTC)Reply[reply]
Another curiosity: whilst HTML 3.2 allowed the <font> tag to have either or both of the color= and size= attributes, it noted Some user agents also support a FACE attribute which accepts a comma separated list of font names in order of preference. This is used to search for an installed font with the corresponding name. FACE is not part of HTML 3.2.HTML 4 formally added the face= attribute to the syntax, but immediately deprecated it along with the element itself. --Redrose64 🌹 (talk) 11:27, 5 December 2023 (UTC)Reply[reply]
Query: Is <strike>depreciated in favour of <s> or is there another, more convoluted way? Adam Cuerden(talk)Has about 8.6% of all FPs. 23:39, 5 December 2023 (UTC)Reply[reply]
[1]: Use the <del> tag to define deleted text [...] Use the <s> tag to mark up text that is no longer correctAaron Liu (talk) 00:03, 6 December 2023 (UTC)Reply[reply]
And if you want a strikethrough without semantic connotations, you can use <span style="text-decoration:line-through;">.HouseBlastertalk 00:09, 6 December 2023 (UTC)Reply[reply]
Why stop there? We could make everything so much simpler by using <span class="mw-signature-struckthrough mw-signature-nonsemantic-strikethrough" title="nonsemantic-strikethrough" id="struckthrough-nonsemantic-qghlm11j" onclick="" style="font-size:100%; font-family: san-serif; filter: hue-rotate(0deg); text-decoration: line-through; display: inherit; text-align: inherit;" alt="Non-semantically struckthrough signature"></span>. jp×g🗯️ 13:13, 9 December 2023 (UTC)Reply[reply]
This outcome is looking pretty snowy, and discussion seems to have reached a natural conclusion. – Jonesey95 (talk) 20:44, 15 December 2023 (UTC)Reply[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Post RfC: disallowing new signatures obsolete tags close[edit]
@Gonnym open a site configuration request in phabricator. — xaosfluxTalk 10:18, 26 December 2023 (UTC)Reply[reply]
In T140606, matmarex wrote: I updated the patch to include a config variable $wgSignatureAllowedLintErrors. It defaults to [ 'obsolete-tag' ] (which allows <font> tags etc.), and you can file a task to change this config to an empty array [] whenever the community of English Wikipedia (or any other wiki) agrees to that. I have filed T354067 to make that request, based on the RFC consensus listed above. If I have made any technical errors, feel free to weigh in with comments or corrections. – Jonesey95 (talk) 00:36, 28 December 2023 (UTC)Reply[reply]
It seems the patch for this has stalled because nobody asked someone on Wikitech to add it to the deploy calendar (see the unresolved comment). Is there a process for asking? Could someone do that? Aaron Liu (talk) 16:50, 10 January 2024 (UTC)Reply[reply]
Hi. I was unexpectedly out of town for a while; I will try to get this done within the next day or two.HouseBlastertalk 19:43, 11 January 2024 (UTC)Reply[reply]
It seems like the patch is finished now. Thanks! Aaron Liu (talk) 22:00, 11 January 2024 (UTC)Reply[reply]
in my signature, and I got an error saying that I was using an obsolete tag. This is good progress. HouseBlaster, is it time for phase 2 of this RFC? As a Linter error fixer, it can't happen soon enough for me. – Jonesey95 (talk) 23:23, 11 January 2024 (UTC)Reply[reply]
Increase default thumbnail size from 220px to 250px[edit]
Example at 220pxExample at 250pxExample at 300px
Way back in 2009, English Wikipedia decided to change its default thumbnail size from 180px to 220px (which became the default for all wikis). It's been 15 years since then, and the most common screen resolution is now 1920x1080,[2][3] which makes 220px seem rather small. The Swedish, Norwegian, and Finnish Wikipedias have already switched to 250px and the Dutch Wikipedia switched to 260px(!). Since there are already other wikis using 250px, the impact on the thumbnailing services and thumbnail storage should be manageable (as the most commonly requested thumbnails will already be available in 250px). A 2014 proposal to increase the default size to 300px failed to reach consensus, which is why I'm trying the more modest proposal of 250px (which is the next size up in wgThumbLimits). Nosferattus (talk) 19:00, 5 January 2024 (UTC)Reply[reply]
Support as proposer - After wondering why thumbnails are so tiny on Wikipedia (especially compared to other websites), I finally figured out I could change the default in my preferences, which made me wonder why the default is so small, which led me to research the history of the issue. Seems like a bump in the size is overdue. Nosferattus (talk) 19:04, 5 January 2024 (UTC)Reply[reply]
Support - I've always thought that Wikipedia has frustratingly small thumbnails. 4.16.149.14 (talk) 20:01, 5 January 2024 (UTC)Reply[reply]
Oppose In many case images aren't just used on their own, but side by side with other images (the multiple images template for example). This already leads to cramped text on none desktop screens, and this propodal only makes that worse. Thete is also the issue of |upright= to think of, as this would effect the size from which images are scaled. If images appear to small a setting for larger base size is available in preferences. -- LCU ActivelyDisinterested«@» °∆t° 20:33, 5 January 2024 (UTC)Reply[reply]
The common screen size of phones have also increased. In most cases where the multiple images template is used, it's on its own line instead of sharing with text. IP editors and readers should also be accounted for, and I don't see what considerations upright adds to thumbnail sizes. Aaron Liu (talk) 21:45, 5 January 2024 (UTC)Reply[reply]
Sorry but In most cases where the multiple images template is used, it's on its own line instead of sharing with text is the opposite of my experience. -- LCU ActivelyDisinterested«@» °∆t° 22:01, 5 January 2024 (UTC)Reply[reply]
You're right - the one line ones are "mini-galleries", which are vastly preferable to multiple images, which are used far too often. Johnbod (talk) 04:12, 7 January 2024 (UTC)Reply[reply]
Yep with this increase all horizontal multiple images templates will immediately become to wide. Mini-galleries are definitely a better idea. -- LCU ActivelyDisinterested«@» °∆t° 12:49, 7 January 2024 (UTC)Reply[reply]
Template:Multiple image is used in less than one percent of articles. It has a hard-coded default of 200px and therefore should not be affected by this change at all. WhatamIdoing (talk) 18:30, 7 January 2024 (UTC)Reply[reply]
I still don't see what considerations upright adds to thumbnail sizes. Aren't the considerations of that exactly the same as those for changing the thumbnail sizes? Aaron Liu (talk) 21:36, 9 January 2024 (UTC)Reply[reply]
Upright is scaled from the base image size, so any images that have been set as a specific size using upright will increase in size based on this change. -- LCU ActivelyDisinterested«@» °∆t° 22:57, 9 January 2024 (UTC)Reply[reply]
The same goes for every other iamge. Aaron Liu (talk) 23:11, 9 January 2024 (UTC)Reply[reply]
No. If an image is set to 300px it won't change, but if it's set to 1.36 upright it will increase in size proportional to this change. -- LCU ActivelyDisinterested«@» °∆t° 23:17, 9 January 2024 (UTC)Reply[reply]
So will images not set to any px. Uprights are meant to be relative, I don’t see the problem here. Aaron Liu (talk) 00:45, 10 January 2024 (UTC)Reply[reply]
Then obviously I have failed to explain the point in a way you can understand. -- LCU ActivelyDisinterested«@» °∆t° 13:27, 10 January 2024 (UTC)Reply[reply]
Support - 220px is tiny, especially on a 4K monitor which are becoming more common. I think it would be useful to increase the size, especially since other Wikis already have. 30px isn't much in the grand scheme of things and hasn't caused any issues for me when putting images in infoboxes. --StreetcarEnjoyer (talk) 20:46, 5 January 2024 (UTC)Reply[reply]
Support 220px looks tiny on my screen. I can set my default up to 300px but prefer to see what the readers are seeing. Or not, given the small size on their 4K monitors. Hawkeye7(discuss) 23:02, 5 January 2024 (UTC)Reply[reply]
Meh Personally, despite my screen being 1920×1280, I seldom maximize my browser. Also keep in mind how Vector 2022 shrinks the content area. Anomie⚔ 00:29, 6 January 2024 (UTC)Reply[reply]
As a staunch supporter of V22, I don't think the larger Earth image looks wrong here. (Not sure if that means we should do it though, so I'm neutral.) Aaron Liu (talk) 12:51, 7 January 2024 (UTC)Reply[reply]
@Nosferattus: isn't 360×800 the most common screen resolution (a very quick check showed readership of TFA today at about 2:1 mobile web to desktop web). — xaosfluxTalk 00:41, 6 January 2024 (UTC)Reply[reply]
@Xaosflux: Yes, I think you're correct and 250px (or 300px for that matter) works great at 360×800, as the mobile layout puts images on their own line. Nosferattus (talk) 01:31, 6 January 2024 (UTC)Reply[reply]
Isn't mobile configured separately? I'm pretty sure that we can change the desktop size without changing the mobile size. WhatamIdoing (talk) 04:41, 7 January 2024 (UTC)Reply[reply]
Support. It's not 2009 anymore, and the images look way better bigger. Relativity 02:56, 7 January 2024 (UTC)Reply[reply]
Comment I don't fully understand the importance of screen size here, as I thought WP:VECTOR2022 specifically constrains article width by default. Could anyone with a super-wide monitor clarify? CMD (talk) 03:39, 7 January 2024 (UTC)Reply[reply]
It does by default. But the people !voting here probably either use a different skin or have clicked the button to un-constrain it. Anomie⚔ 04:29, 7 January 2024 (UTC)Reply[reply]
Given the resistance to the community wish of making unconstrained the default, it would be best to make decisions considering restricted width as the most likely one to be encountered by desktop readers. Having a look myself, I don't think 250px creates an issue within the constrained width (and I believe the latest zebradesign has been implemented), but worth keeping this default look in mind. CMD (talk) 14:31, 7 January 2024 (UTC)Reply[reply]
Support I feel like I have to squint to look at images pretty often. This should be an RfC advertised on WP:CENT tho. Galobtter (talk) 03:47, 7 January 2024 (UTC)Reply[reply]
Strong Support Hardly any images except photos of faces can be properly read at 220px. As per Relativity, except even in 2009 our images looked too small. Johnbod (talk) 04:10, 7 January 2024 (UTC)Reply[reply]
Support. I'd prefer jumping straight to 300px (and I think mw:Ops would, too), but 250px is fine and an improvement over what we have now. Somewhat bigger images are easier for people to see (e.g., if you're old enough to use reading glasses, which I'm sure I set down somewhere just a minute ago), but they also make the pages seem more interesting. I set mine to 300px last year, and I've never regretted it, and you can, too: go to Special:Preferences#mw-prefsection-rendering-files and change the thumbnail size. As noted above, several other communities have made this change already, and I'll add that AFAIK no community has ever switched to a bigger number, regretted it, and then asked to be switched back to a smaller size. BTW, because the English Wikipedia is the largest wiki in the history of the world, etc., the actual switch is something that requires a bit of planning. This is not difficult – in fact, on our end, it's really quite easy – but we should not be surprised, e.g., if we get an official request to manually set the images in the very most popular articles (probably on the order of the top 0.01% by page views) to the new size in advance of the official switchover. We can send a bot around to do this (and also to undo it after the switch is made), and that will take some of the strain off the servers on the magical day (plus give both editors and readers a way to see the change in action before it happens everywhere). Let's do this. WhatamIdoing (talk) 04:55, 7 January 2024 (UTC)Reply[reply]
Support per WhatamIdoing. I've had a default size of 300px for a couple of years now, and it's hugely improved the desktop reading experience. MichaelMaggs (talk) 11:09, 7 January 2024 (UTC)Reply[reply]
Oppose We still also must consider mobile screens, and going above 220 px will put a strain on those readers. If you are on desktop, you can set the default size through a registered account to handle this. Masem (t) 18:32, 7 January 2024 (UTC)Reply[reply]
Why would it? As mentioned above, since images are put on their own line in mobile, having bigger images is nice and causes no issues. I just increased my thumbnail size to 300px and it looks great - a lot of images are a lot easier to see that way (Special:Preferences#mw-prefsection-rendering-files also affects mobile, so you can test it for yourself). 250px is not going to cause any issues for mobile. Galobtter (talk) 18:53, 7 January 2024 (UTC)Reply[reply]
I disagree, I find larger thumbs on mobile to be too large for a reasonable reading experience. Masem (t) 20:13, 7 January 2024 (UTC)Reply[reply]
I'll also add that there is an issue with anything larger than 220px for a large chuck of non-free images, which we have constrained to 0.1MP. Many portrait non-free images like movie posters end up with image sizes around 400 x 225 px to stay within the 0.1MP. Thumbnail sizes over 220 px will implicitly and incorrectly imply that non-free images can be uploaded to larger sizes, which will not happen. Masem (t) 20:19, 7 January 2024 (UTC)Reply[reply]
Is there any actual legal basis for 10% of a megapixel? My impression is that this was more or less a random number pulled out of somebody's. jp×g🗯️ 15:42, 8 January 2024 (UTC)Reply[reply]
No, it’s just something we picked. The legal precedent is only that the usage has to be ‘minimal’. If u have a retina screen in many cases u already get noticeably pixelated thumbnails for non free images. Upping the thumbnail size would increase that problem. —TheDJ (talk • contribs) 21:35, 9 January 2024 (UTC)Reply[reply]
Also, 250x400 px = 0.1MP exactly, so we could have the same height on a vertical image. US theater posters have a ratio of 27:40, so we'd be expecting to see uploads at 250x370px. WhatamIdoing (talk) 02:16, 10 January 2024 (UTC)Reply[reply]
Support, especially for mobile. I've got a tiny screen for a mobile, and default thumbnail has a lot of ugly white around it. On desktop it's a no-brainer; I usually set upright=1.35 to ensure images/graphs are easy to see. By choosing a better default, fewer people will need to rescale. Many people rescale using the px parameter, which causes accessibility issues, so another plus if that is avoided. My guess is that a default of 300px or 260px would be even better. —Femke 🐦 (talk) 18:58, 7 January 2024 (UTC)Reply[reply]
Support - Sensible suggestion. I would even support 300px in the future. Schierbecker (talk) 19:07, 7 January 2024 (UTC)Reply[reply]
Support Looks good, more accessible, and none of the concerns raised bother me. ~ F4U (talk • they/it) 19:12, 7 January 2024 (UTC)Reply[reply]
Support as a longtime smartphone user. My phone can easily handle the larger images. Cullen328 (talk) 19:13, 7 January 2024 (UTC)Reply[reply]
Support Jeez, I remember it was pulling teeth to get the thumb size bumped up years ago, and now it's been more than a decade? I think we are hitting the useful limits of thumbnail size at 250px, given that a) lots more reader use is mobile, which is width-restrained, and b) the WMF's Vector redesign harms screen horizontal real estate for the vast majority of readers and it's likely even if they're browsing full-screen at 1920x1080, they don't necessarily have correspondingly more content area, but I think the small bump proposed here is sensible. Der Wohltemperierte Fuchstalk 19:24, 7 January 2024 (UTC)Reply[reply]
The mobile width of an average mobile screen is 360 to 440 ‘non-retina’ pixels. With margins removed that’s about 300 to 360 web pixels. Above that width, the skin will scale down the image. —TheDJ (talk • contribs) 21:39, 9 January 2024 (UTC)Reply[reply]
Support. This is less of an issue with Vector 2022, which makes the horizontal area much smaller, but I still recommend it be done. I myself have manually set the thumbnail size to 400px so I can see more in Vector 2017, which is the skin I use. SWinxy (talk) 19:45, 7 January 2024 (UTC)Reply[reply]
And, yes, I would also support 300px thumbnails too. SWinxy (talk) 18:03, 9 January 2024 (UTC)Reply[reply]
Support I set my personal default to 400px some time ago and that's fine so even 250px is small. And I'm not using anything special – mostly a 1920 x 1080 laptop or a smartphone. Andrew🐉(talk) 21:09, 7 January 2024 (UTC)Reply[reply]
Support: aesthetically, I like the current size better, but that's no reason to oppose, just my opinion. I am convinced by supporter's arguments above. 🌺 Cremastra (talk) 22:41, 7 January 2024 (UTC)Reply[reply]
Support. I do not see downsides to this proposal. Screens are significantly larger than they were a decade ago, so they should be able to handle slightly larger thumbnails just fine. For non-free media, that means the media will likely be smaller than the proposed new default, but that is only a minor issue. Conversely, I think 250px default thumbnails would be a significant benefit for both desktop and mobile users, especially seeing how many articles already use images that are 250px or larger in their infoboxes. – Epicgenius (talk) 23:28, 7 January 2024 (UTC)Reply[reply]
The "0.1 megapixels is an ironclad rule we bot-enforce" definition of "low resolution" is something else that probably needs revisiting in a separate discussion. Der Wohltemperierte Fuchstalk 01:00, 8 January 2024 (UTC)Reply[reply]
Yeah that seems like a very arbitrary rule we could relax without issues. Galobtter (talk) 14:56, 8 January 2024 (UTC)Reply[reply]
In that case, I don't think there are any other issues with upscaling the default thumbnail size to 250px. Although I definitely see why there is a size limit for non-free media, I agree the 0.1 megapixel limit seems arbitrary (for example, why can't it be 0.11 or 0.12 megapixels, which would allow non-free media to be slightly wider?). – Epicgenius (talk) 19:56, 8 January 2024 (UTC)Reply[reply]
Strong support - sane defaults make the world go round. There's always option for templates and or individuals to hard-code other sizes. ~ 🦝 Shushugah (he/him • talk) 23:59, 7 January 2024 (UTC)Reply[reply]
Support, a really good idea. Now hopefully somebody will get around to increasing the default text size, probably small enough that it was designed for 18-year-olds with the eyesight of eagles. Randy Kryn (talk) 00:32, 8 January 2024 (UTC)Reply[reply]
Support Reading and commenting from mobile to say that this looks better on the mobile version of the wiki and doesn't raise any issues there. CoconutOctopustalk 12:20, 8 January 2024 (UTC)Reply[reply]
Support going straight to 300px; I am almost kind of reticent to support going to 250px because we might end up stuck there for another fifteen years. 300px is, I'd say, close to an absolute minimum for things being legible. 220px is so mindbogglingly tiny I can't even explain it without using language from the old country:
>220px thumbnails
>2011
I seriously hope you guys don't do this
All else aside, this is a great idea and overdue. jp×g🗯️ 15:33, 8 January 2024 (UTC)Reply[reply]
For reference, here is a screenshot of this page on a 4K monitor at 100% zoom level lol.Please sir may I have some more pixelsjp×g🗯️ 15:38, 8 January 2024 (UTC)Reply[reply]
The default skin has limited width, not to mention most use 1080p monitors. You may make it 300 for yourself. Aaron Liu (talk) 15:42, 8 January 2024 (UTC)Reply[reply]
The default skin was not handed to us on tablets from heaven; it was made by designers in accordance with the constraints of the project, one of which was that thumbnails were 220 pixels wide. This seems like a rather circular problem: we can't increase the thumb resolution because the skin wasn't designed around them, and the skin won't be designed around larger thumbnails because we don't use them? jp×g🗯️ 20:45, 8 January 2024 (UTC)Reply[reply]
Hmm, I've searched a bunch of places and I can't seem to find a place that says V22 was designed on the basis of 220px thumbs. Aaron Liu (talk) 20:59, 8 January 2024 (UTC)Reply[reply]
Expecting the WMF to react to changing thumbnail sizes on a single project (even the main one) seems unlikely, and the default fixed-width page layout is how the vast majority of users will experience the site. (As an aside, one reason for the page width limits is that the longer lines go, the harder it is to read, hence one reason why you never ended up with extremely horizontal books. I dunno who is browsing Wikipedia at full-width and full 4K resolution, but that's objectively a worse way to experience it, and we shouldn't be considering those edge cases when making decisions for the majority.) Der Wohltemperierte Fuchstalk 16:14, 9 January 2024 (UTC)Reply[reply]
I use limited width and even then the width is wide enough to justify 250px thumbs. Aaron Liu (talk) 16:43, 9 January 2024 (UTC)Reply[reply]
Weak support. It's a marginal change, but apparently important enough to end up at CD. Oh well – I kinda like bigger images anyway. I can't support this beyond personal opinion on aesthetics, but I'd be willing to put a Weak Support on it. InvadingInvader (userpage, talk) 15:57, 8 January 2024 (UTC)Reply[reply]
Support per WhatamIdoing given that the screen resolutions of both computer and mobile screens has increased since 2009 designation. BluePenguin18 🐧 ( 💬 ) 16:35, 8 January 2024 (UTC)Reply[reply]
Support per WAID. Personally, I use 300px, which works fine also on my phone. —Kusma (talk) 18:21, 8 January 2024 (UTC)Reply[reply]
Strong support - Increasing to at least 250px (if not 300px) makes sense in relation to more advanced mobile phones and desktop screens. As a visual thinker and learner (as opposed to a "word person") this change would also increase literacy for those of use who are visually dominant. Therefore I see it as an accessibility issue as well. Netherzone (talk) 18:36, 8 January 2024 (UTC)Reply[reply]
Support Just like with money inflation, keeping as the relative same as 15 years ago would be about 500px and 250 is a tiny step in comparison. North8000 (talk) 19:04, 8 January 2024 (UTC)Reply[reply]
Support as web design best practice. I broached this idea back in 2020, and given the response here it seems I shouldn't have let myself be talked out of it. I've had my personal preference set to 250px ever since then — it's nice, and I'd like to give readers that same experience. I find the opposes generally unconvincing (Masem's fair use concerns seem at least a bit valid, but as TheDJ notes, a bit of pixelation is already happening on high-resolution devices, which are becoming more common over time, so it's water under the bridge; and I don't have any problem with people uploading larger fair use images that then get automatically reduced, nor with us exploring raising the 0.1MP standard). {{u|Sdkb}}talk 00:24, 10 January 2024 (UTC)Reply[reply]
Support without prejudice against further increases. – Teratix₵ 04:30, 10 January 2024 (UTC)Reply[reply]
Support And wouldn't be opposed to something larger than 250px too -Fastily 22:48, 10 January 2024 (UTC)Reply[reply]
Support: I've previously thought 220px was too small on desktop, and an increase to 250px seems reasonable even considered the limited width of Vector 2022 (which improves readability and skimming). — Bilorv (talk) 23:48, 13 January 2024 (UTC)Reply[reply]
Support Yes please, it would be a much more sensible default! Leijurv (talk) 21:40, 15 January 2024 (UTC)Reply[reply]
Support Good size and looks better on bigger screens Isla🏳️⚧ 00:36, 17 January 2024 (UTC)Reply[reply]
Even though there is overwhelming consensus to increase resolution, 250px is a very small jump and in my opinion it should be increased to 300px. In the 2000s, the most common screen resolutions are 800x600 and 1024x768. Now, the most common resolution are 1080p, which is 1920x1080. 1920/1024 = 1.875, so in theory we should scale the image to 400px, but that's too large because New Vector has a fixed width for content. So, I made a test to determine whether 300px is truly the optimal image size. In one page, I opened Earth in default New Vector and preview it in 300px. In another page, I opened the same article in the Internet Archive as it looks like in 2008 and use a browser tool to set a 1024x768 resolution and then scale the page until both article's text looks at around the same width. Indeed, in both pages, the image looks almost exactly in the same proportion. I'm uploading screenshots of my test to Wikimedia Commons for others to see. CactiStaccingCrane (talk) 10:53, 9 January 2024 (UTC)Reply[reply]
Also, I would like to add that increasing picture resolution helps with printed and offline version of Wikipedia where there is no option to browse the full-res picture. That's why I consider 250px to be too small of a change. CactiStaccingCrane (talk) 02:52, 10 January 2024 (UTC)Reply[reply]
Oppose. The scaled version is definitely closer to 250px. The picture of Earth is a square image, while a lot more images are landscape. In my experience, for such images, 300px covers up way too much text. Aaron Liu (talk) 12:41, 9 January 2024 (UTC)Reply[reply]
It's not too helpful an image as the Earth image appears to be in an infobox that maintains its width, however as the pixel scaling is horizontal a landscape image would cover up less text than a square image. CMD (talk) 14:10, 9 January 2024 (UTC)Reply[reply]
Could we have an example with regular image thumbs instead? Aaron Liu (talk) 14:32, 9 January 2024 (UTC)Reply[reply]
I'm a bit tired today, so can someone else make the example pic? CactiStaccingCrane (talk) 16:47, 9 January 2024 (UTC)Reply[reply]
300px covers up way too much text – Um, it doesn't cover up any text. Bigger images do take up more vertical space, but if it's actually overlapping with the text, then you should probably be at the Wikipedia:Help desk or Wikipedia:Village pump (technical) with a screenshot showing how the image prevents you from seeing all the words on the page. WhatamIdoing (talk) 02:23, 10 January 2024 (UTC)Reply[reply]
Bigger images will cause words to run away from the image, which is what I meant by "cover up", not literally overlap. Aaron Liu (talk) 03:16, 10 January 2024 (UTC)Reply[reply]
Support as the inevitable outcome. We will someday do this. Why not now? WhatamIdoing (talk) 02:23, 10 January 2024 (UTC)Reply[reply]
Because current popular screen sizes aren't fitted for such large image sizes. One day your local wages will inflate, but that doesn't mean we should inflate them now. Aaron Liu (talk) 03:16, 10 January 2024 (UTC)Reply[reply]
Support, that's what I use and it is great both on my laptop and on my smartphone. (I rarely use ultra-wide screens). —Kusma (talk) 13:32, 10 January 2024 (UTC)Reply[reply]
Oppose per my rationale above. Were default Vector not restricting width I would possibly feel differently, but it is what it is, and given image/template sandwiching issues a more conservative default is a bit less ungainly in edge cases. Der Wohltemperierte Fuchstalk 13:59, 10 January 2024 (UTC)Reply[reply]
Support Also fine with this. Johnbod (talk) 18:59, 10 January 2024 (UTC)Reply[reply]
Support Per above, this is also fine. -Fastily 22:50, 10 January 2024 (UTC)Reply[reply]
Support but note significant work --> a change from 220px to 250px will mean that some images with be a bit on the large size (with upright=1.35 for instance), but not too ugly. When we change it to 300px, a lot of images with upright=1.35 or upright=1.5 will have become too big. We may want to find consensus to change the upright parameter automatically under certain conditions (f.i. upright>1.35.. ). —Femke 🐦 (talk) 17:55, 12 January 2024 (UTC)Reply[reply]
This was part of my reasoning for opposing both changes, if the default is increased any images set with upright will become the wrong size. Some kind of automated correction would certainly help. -- LCU ActivelyDisinterested«@» °∆t° 21:00, 12 January 2024 (UTC)Reply[reply]
Oppose. 300px simply looks too big on my laptop screen (effective resolution 1280×800, using Vector Legacy). Even worse on my smartphone (also using Vector Legacy which I understand is an edge case), where the image takes up about 40% of the page width. —pythoncoder (talk | contribs) 21:18, 12 January 2024 (UTC)Reply[reply]
Support I set my personal default to 400px some time ago and that's fine so even 300px is small. And I'm not using anything special – mostly a 1920 x 1080 laptop or a smartphone. Andrew🐉(talk) 09:05, 16 January 2024 (UTC)Reply[reply]
On Vector 2022, with both toolbars floating? Aaron Liu (talk) 12:34, 16 January 2024 (UTC)Reply[reply]
Oppose seems to be too big on smaller devices like phones and has some issues with Vector 2022 right now I might support in the future if Vector 2022 is fixed Isla🏳️⚧ 00:32, 17 January 2024 (UTC)Reply[reply]
Erm, fixed? The design of max. width + toolbars is not gonna change and is a feature, not a bug. Aaron Liu (talk) 02:12, 17 January 2024 (UTC)Reply[reply]
Can't we use something that depends on the actual current width of the page? Vector 2022 allows that to change with the click of a button; why shouldn't the images become larger if the screen is larger? Maximum and minimum values, and even the height of the screen, can be calculated freely and automatically. For example, we could define that an image's maximum width is the minimum of: 20% line width, 100% view height, 400px. ~ ToBeFree (talk) 19:04, 12 January 2024 (UTC)Reply[reply]
What about mobile, where images need to be on their own line? Aaron Liu (talk) 19:10, 12 January 2024 (UTC)Reply[reply]
This can all be specified in stylesheets. If "mobile" refers to a mobile design, at MediaWiki:Mobile.css. If "mobile" is Vector 2022 on a mobile screen, by using media queries or universal definitions (such as my "minimum of" example above). ~ ToBeFree (talk) 23:35, 12 January 2024 (UTC)Reply[reply]
Dynamic scaling of content, not just images, should be the way forward. This would ultimately allow for a single page style regardless of screen size or aspect. -- LCU ActivelyDisinterested«@» °∆t° 20:55, 12 January 2024 (UTC)Reply[reply]
As I understand it, somewhere in the server infrastructure, the thumbnail images have been generated and cached for fast delivery (thus WhatamIdoing's suggestion that the size be manually changed for high-traffic articles in advance of switching the default, to take the load off the servers from generating images on-demand until the cache has been re-generated). Thus having the thumbnails with different pixel sizes based on each user's window size would have a significant impact on performance. It is theoretically possible to specify a maximum limit for the space in which the thumbnail is rendered, though, so it won't take up more than a certain amount of the available content space regardless of the pixel size of the image. I've never looked closely at how it works under the hood, though, so am not sure how much rework might be needed. Cases where editors have used an {{{upright}}} scaling factor > 1 to deliberately exceed the usual horizontal space allocated would have to be accommodated, which might be tricky. isaacl (talk) 21:47, 12 January 2024 (UTC)Reply[reply]
Ah, thumbnail caching is a point I hadn't thought about. But if we use the "minimum of: 20% line width, 100% view height, 400px" example, we can serve 400px thumbnails and they'll never have to be upscaled. Or, taking "upright" into account, the limits could be "20%*upright width, 100% width, 100% height and 400px*upright", with 400px*upright thumbnails, I guess. ~ ToBeFree (talk) 13:06, 13 January 2024 (UTC)Reply[reply]
Yes, as I said, it would be possible to limit the space in which the image is rendered while serving it at a specific size, though I am uncertain about the amount of changes required for implementation (it could require work both in the MediaWiki code as well as the wikitext source). As any applied scaling factor isn't a fixed value (or one of a fixed set of values), however, accommodating it with a CSS rule would require custom CSS to be generated for each instance and targeted for the specific image. Given how the cascade works, I'm not sure if the template can cleanly manage this on its own (though I suppose as a kludge it could manually replicate a common rule while adding additional constraints). (Javascript code could apply an appropriate rule, but this would result in layout shifts, as well as requiring the user agent to support Javascript.) isaacl (talk) 17:51, 13 January 2024 (UTC)Reply[reply]
Improvement to how Wikipedia handles multiple citations of the same source.[edit]
Currently multiple citations to the same source are handled reasonably well, with a number appearing in superscript in the body multiple times, with the same number appearing just once in the references list, with letters (a, b, c, etc) after the number allowing you to return to the exact place in the article that you were up to, however, the reader won't necessarily know whether they were up to a, b, c, or whatever. Sure, it's usually not too hard to find your place, but it could be made easier if the in-text superscript said for example, 8a, 8b, 8c, etc rather than just using the same repeated numeral for multiple citations of the same source. MathewMunro (talk) 05:38, 7 January 2024 (UTC)Reply[reply]
When clicking the numbered link to get to the ref, the ref becomes highlighted. Maybe the specific 'a', 'b', etc. could be specially denoted there? That would be an extension with consistent behavior. Changing the way the footnote marker is written in the text seems more confusing to readers, since it suggests that either there are different refs ('8a' vs '8b') or that there are different subparts of ref 8 (some refs do bundle multiple entries). DMacks (talk) 05:50, 7 January 2024 (UTC)Reply[reply]
Sure, the reference becomes highlighted, but whether you have to click on 'a' or 'b' or whatever to get back to where you were is not clear, whereas if the superscript in the body of the article said '8a' or '8b', it would be pretty clear which one you were up to. An alternative would be to differentially highlight the 'a' or 'b' after the '8' or whatever number & letter it was in the references after you click on the superscript number in the body of the article, so you know which letter to click on to get back to where you were, or some similar means of making it stand out so that people know which one is the one to click to get back to where they were. MathewMunro (talk) 10:23, 7 January 2024 (UTC)Reply[reply]
It sounds like you are objecting to my proposal of do exactly what you later wrote as your alternative:) To wit, I wrote "clicking the numbered link to get to the ref...the specific 'a', 'b', etc. could be specially denoted [in the ref after clicking]". DMacks (talk) 14:11, 7 January 2024 (UTC)Reply[reply]
Sorry, I didn't understand what you meant by 'Maybe the specific 'a', 'b', etc. could be specially denoted there?', but I'm on the same page now :)
And yes, that would be a smaller and for some a less confusing change. Highlighting the specific 'a', 'b', etc in a different colour would be one effective way of specially denoting which hyperlink to click on to get back to where you were. MathewMunro (talk) 14:39, 7 January 2024 (UTC)Reply[reply]
This seems like it would be confusing in combination with T100645, which IMO would be far more useful than this. Particularly since it seems to me that the browser's back button is more convenient than trying to figure out whether 'a' or 'b' or whatever is the right tiny link to click to get back, assuming someone isn't just using the Reference Tooltips gadget in the first place. Anomie⚔ 14:05, 7 January 2024 (UTC)Reply[reply]
That phab task looks like it would be a software replacement for {{rp}}? That sounds helpful. I agree that the idea floated here, of adding letters to the citation numbers[2b] would be more confusing than anything else, and imply a seperate work or portion of work supporting the cited claim despite actually being the same.[2a] Seems like it might also interfere directly with the citation style of some articles, which use ref groups to generate citation numbers with a similar format.[C 2]I'm not necessarily against a software patch to use javascript to change the metrics of the hopback link followed to make it easier to guess, but: the tiny sliver of the userbase that actually interfaces with citations probably reads them through an on-hover or single tap, without clicking through to the reflist; whenever I guess wrong, I tap "back" in the browser and guess again; most multiply cited sources shouldn't have so many different loci of citation that it's a difficult or tedious process to find the correct hopback link; and those that are cited that many times will probably be recognisable based on their oft repeated citation numeral, negating the need to click through to it after the initial few appearances. Folly Mox (talk) 14:29, 7 January 2024 (UTC)Reply[reply]
Thanks for the tip. I didn't realise just using the browser's back button would take me back. Although I noticed that when using the back button, the reference will be somewhere on the page, depending on where it was (top, middle or bottom of the page) when you clicked on the reference, but clicking the correct 'a', 'b', 'c', etc hyperlink in the references will set the relevant line in the body of the article to the top of the page, making it easier to find. I realise that most people can find a reference that's somewhere on the page pretty easily, but it is easier to find it in my opinion if it's at the top of the page.
I accept that there are drawbacks of using a 1a, 1b, 1c, etc referencing style, and so forget about that. How about instead we do either one or preferably both of the following:
1. Make the back button take you to the place you were, but with the line containing the reference set to the top of the page; and
2. After you click a citation superscript numeral in the article's body, highlight & bold the relevant 'a', 'b', or 'c', etc in the references that you have to click on to get back to where you were?
Although, I just noticed that if you click the little '^' symbol in the references, it does exactly what I want it to do, and the hover works well too, so maybe it's just a matter of learning how to use it properly :) although, there's nothing wrong with having multiple ways of accomplishing the same thing. MathewMunro (talk) 14:49, 7 January 2024 (UTC)Reply[reply]
Neither of these is a good idea. We should not attempt to change how the browser's "back" button behaves. Some websites do this, by various means including server-side immediate redirection, client-side immediate redirection, and Javascript that actually modifies the botton's action. It can mean that you get trapped on that website with no way of getting back to where you came from - this might of course be intentional, but it's not what we want for our readers.
When you follow a link from a superscripted ref marker to the ref itself, or from the backlink on the ref to the superscripted ref marker, the place that you reach gains a pale blue background; this is due to a CSS rule:
The first selector (ol.references li:target) goes for a whole list item in the references section. To pick out an individual backlink within that list item could be possible, but would mean that the individual backlink would need to be the target of the link from the superscripted ref marker, and since this is not the whole ref, the pale blue background would be less visible. Such changes - even if agreed on here - would need to be requested through phab:. --Redrose64 🌹 (talk) 18:18, 7 January 2024 (UTC)Reply[reply]
Agreed modifying the back button behaviour would be bad if it had any kind of spill-over effect trapping you on a page. I certainly don't know enough about web-programming to know whether or not it could be done in a way that only does what it's supposed to do on all browsers & devices. And if you had to choose between highlighting the whole reference and highlighting just the relevant 'a' or 'b' or whatever, you would certainly be better off just leaving it the way it is, especially seeing as clicking the '^' symbol takes you back to where you were even if you don't know whether it was reference 'a' or 'b' or whatever. But if you could differentially highlight both the whole reference and the relevant 'a' or 'b' or whatever, (or change the text colour of the relevant 'a' or 'b' or whatever in addition to highlighting the whole refernece) that would be ideal, but again, this would only be a very very marginal improvement. I'm happy to let it go :) MathewMunro (talk) 21:07, 8 January 2024 (UTC)Reply[reply]
Please see this discussion for a proposal to enable archiving of discussions at pages like WP:Help desk that have level-one headings to group discussions by date in the Table of Contents. Afaict, Help desk archiving currently happens N days after the *first* message of the day was posted, regardless of how recent the last message was. Mathglot (talk) 00:25, 10 January 2024 (UTC)Reply[reply]
One idea I propose on how to shorten them is to rewrite the banner article template in three sentences, each in one line at normal text size, just like {{Afd}}:
Stated rationale for deletion
Link to contest speedy deletion
Encourage editors to improve the article and link to speedy deletion process in general
Ok, that's quite a lot of templates. I think it would be much better for individual editors to be bold and edit the templates directly, after this discussion resulted in a consensus of action. CactiStaccingCrane (talk) 15:51, 11 January 2024 (UTC)Reply[reply]
The problem is they're all template-protected, and highly used. I think it'd be better to try to hash out at least the rough wording for each beforehand – just to reduce lots of subsequent edit requests, there doesn't have to be a big discussion of each one or anything. – Joe (talk) 15:53, 11 January 2024 (UTC)Reply[reply]
This would mean that the unbolded message at {{db-meta}} template would needs to be drastically shortened, the user notification request and the "last edited at X" be removed. {{AfD}} has proved that we don't really need these in the banner. CactiStaccingCrane (talk) 16:04, 11 January 2024 (UTC)Reply[reply]
@CactiStaccingCrane, CENT-listed discussions tend to go better when there is a concrete, fully defined proposal for editors to !vote on. I'd suggest holding off on listing until you have finished crafting the proposed changes at the subpage. {{u|Sdkb}}talk 16:29, 11 January 2024 (UTC)Reply[reply]
This template may meet Wikipedia's criteria for speedy deletion{{{1}}}.See [[Wikipedia:Criteria for speedy deletion#{{{CRITERION}}}|CSD {{{CRITERION}}}]].
If this template does not meet the criteria for speedy deletion, or you intend to fix it, please remove this notice, but do not remove this notice from pages that you have created yourself. If you created this page and you disagree with the given reason for deletion, you can click the button below and leave a message explaining why you believe it should not be deleted. You can also visit the talk page to check if you have received a response to your message.
[button]
Note that this template may be deleted at any time if it unquestionably meets the speedy deletion criteria, or if an explanation posted to the talk page is found to be insufficient.
[timestamp]
And here's my proposal:
This template may meet Wikipedia's [criteria for speedy deletion{{{1}}}.] [link directly to the specific criterion for speedy deletion]
You are welcome to contest this speedy deletion by leaving a message at [link to contest speedy deletion].
Feel free to improve the article, but do not remove this notice if you have created this page. For more information, see the guide to speedy deletion.
I would contest that change. You're making significant change to the guidance to (non-creator) users which is contrary to the text of the actual policy. Anomie⚔ 13:28, 14 January 2024 (UTC)Reply[reply]
Could you mention specifically what policy is being violated? I'm just trying to make speedy deletion templates follow {{Article for deletion}} templates since the AfD banner is already well-accepted by the community. CactiStaccingCrane (talk) 13:31, 14 January 2024 (UTC)Reply[reply]
CSD tags are generally allowed to be removed by anyone except the creator. Your changed wording suggests that everyone has to go to the link to contest it. Anomie⚔ 13:43, 14 January 2024 (UTC)Reply[reply]
In 2020, as part of the DiscussionTools project, signature validation was added to MediaWiki. Since its implementation, users have been unable to save an "invalid" signature in Special:Preferences. A "valid" signature must:
link to the user's userpage, talk page, or contributions
not abuse template substitution in specific ways (namely, no forging signatures and no adding line break characters)
These changes have been in place since 2020, but they only prevent someone from saving a new signature. Invalid signatures from pre-2020 are still permitted by the software. If implemented, users with invalid signature preferences would have the standard signature (MediaWiki:Signature: [[User:Example|Example]] ([[User talk:Example|talk]])) applied when signing until such time as they update their signature preference. Affected users would be warned a month in advance of this change.
Technical implementation: this would be implemented by setting $wgSignatureValidation to disallow, after sending a MassMessage to all affected users at least a month in advance.
Support as proposer. There are many reasons this is a good thing. The most obvious is that invalid signatures are A Bad Thing, and getting rid of them is thus A Good Thing. All invalid signatures violate WP:SIG in some way, so this cuts down on problematic signatures. Additionally, I would argue it is unfair that this validation is only applied to new editors. HouseBlastertalk 03:47, 12 January 2024 (UTC)Reply[reply]
Support. I do not see the harm in this, as signatures are mostly an aesthetic thing, and the reasons given are practical. Practicality should usually outweigh aesthetics. ― novov(tc) 10:08, 12 January 2024 (UTC)Reply[reply]
Support Definitely a positive change, best to phase out invalid signatures that might be causing software issues. Sohom (talk) 15:47, 12 January 2024 (UTC)Reply[reply]
Support As with my comment in the last RFC as long as editors are running round fixing these errors we should avoid making new ones. -- LCU ActivelyDisinterested«@» °∆t° 15:48, 12 January 2024 (UTC)Reply[reply]
Support, this will reduce the need for linter bot edits, and a month's notice is more than sufficient for people to either correct the issues, or ask for help doing so if they need it. The proposed notice should point them to where they can ask for technical help if they're not sure what they need to fix or how to do it. SeraphimbladeTalk to me 15:48, 12 January 2024 (UTC)Reply[reply]
Support. In addition to disabling bad or broken syntax this will also reduce the need of editors and bots to fix these, this reducing watchlist spam and angering other editors. --Gonnym (talk) 16:23, 12 January 2024 (UTC)Reply[reply]
Support. It has been more than three years since the new rules went into effect. They should be applied to everyone at this point, with no grandfathering effects. – Jonesey95 (talk) 16:37, 12 January 2024 (UTC)Reply[reply]
Strong support all but obsolete tags and Plain fancy signature, which I’m neutral to as forbiddance of the former were only implemented yesterday and the latter doesn’t actually do harm. I’ll switch if somebody can demonstrate that there aren’t much people using the former and the latter won’t be reset. It’s also disappointing the subst thing isn’t checked. Aaron Liu (talk) 16:50, 12 January 2024 (UTC)Reply[reply]
Support - the HTML Wikipedia publishes today should comply with today's HTML standards. Levivich (talk) 16:53, 12 January 2024 (UTC)Reply[reply]
Support as a practical measure. Grandfathered users do not deserve any special exemption. I forecast white fluffiness and encourage someone to close this once it's been up for a few days. {{u|Sdkb}}talk 17:00, 12 January 2024 (UTC)Reply[reply]
Oppose I don't see the point of locking older users out of signing pages because they use the font tag --GuerilleroParlez Moi 09:57, 13 January 2024 (UTC)Reply[reply]
from the way I see the RfC , the users will not be locked out from signing pages. The RfC is basically about resetting the signature output to default if they don't fix/update their signatures by a set time. – robertsky (talk) 10:04, 13 January 2024 (UTC)Reply[reply]
Editors will be able to sign their posts. The RFC says "users with invalid signature preferences would have the standard signature ... applied when signing". – Jonesey95 (talk) 14:57, 13 January 2024 (UTC)Reply[reply]
Support. I recall a couple times where editors decided to edit war to retain <font> tags in their signatures. This will at least reduce or eliminate new signatures with linter errors. I hope the advance warning includes a link to instructions on how to update signatures with deprecated tags. Philbert2.71828 18:49, 13 January 2024 (UTC)Reply[reply]
Support per Levivich HTML standards. SWinxy (talk) 19:35, 13 January 2024 (UTC)Reply[reply]
Support: an uncontroversial rollout of existing technical decisions (which, in turn, enforce existing guideline/policy/good practice/common sense). — Bilorv (talk) 23:52, 13 January 2024 (UTC)Reply[reply]
Support. This will reduce invalid signatures and be a more consistent application of rules. Hanif Al Husaini (talk) 00:03, 16 January 2024 (UTC)Reply[reply]
I believe the report linked immediately above lists only people who have posted to any talk spaces in the last three months. That catches most of the people whose signatures would be causing errors in current discussions, but there are no doubt thousands of inactive editors with invalid signatures. There are also thousands of editors with font tags in their signatures; those editors are not listed on the above report. It is an open question as to whether they will really be "affected" if they are inactive, but I'll leave that one to the philosophers. Importantly, no existing pages will be edited or changed as a result of this RFC. It affects only editors' saved signature preferences. – Jonesey95 (talk) 16:39, 12 January 2024 (UTC)Reply[reply]
Note that 102 of these are simply signatures without wikitext that have the "treat as wikitext" box ticked. Aaron Liu (talk) 16:50, 12 January 2024 (UTC)Reply[reply]
@HouseBlaster: I was not notified by the above. Please edit this section to delete your comment, then save. Then edit again to add the same comment but with a new signature. Johnuniq (talk) 04:50, 12 January 2024 (UTC)Reply[reply]
We may want to notify the people who this would affect. Is there any objection if I were to drop a note on their talk pages? — Red-tailed hawk(nest) 15:45, 12 January 2024 (UTC)Reply[reply]
Once again, please note that the "sig-too-long-post-subst" editors should not be notified, because they will not be affected by this change. Also, editors whose only error is using obsolete (font or tt or strike) tags in their signatures should have their signatures reset, but they are not listed in the report linked above. We will need to scrape some database or other in order to find them. – Jonesey95 (talk) 16:43, 12 January 2024 (UTC)Reply[reply]
I don't remember participating in these discussions?—CYBERPOWER(Around) 14:30, 14 January 2024 (UTC)Reply[reply]
There was just a reference that you would have been personally impacted, as it was reported that at the time you were on this list. — xaosfluxTalk 14:44, 14 January 2024 (UTC)Reply[reply]
I was? I haven't changed my signature in years though. I wonder what changed? —CYBERPOWER(Around) 15:05, 14 January 2024 (UTC)Reply[reply]
Possibly whatever that report does was confused by the amount of substing in your signature, or possibly it saw some issue with whichever time-specific signature happened to be in use at the time. Anomie⚔ 16:23, 14 January 2024 (UTC)Reply[reply]
@Cyberpower678:User:InternetArchiveBotis on the list because the report does not recognize [[:en:User:InternetArchiveBot]] as a non-interwiki link. The validator itself is smart enough to realize it is, in fact, a local link.HouseBlaster (talk · he/him) 21:04, 14 January 2024 (UTC)Reply[reply]
Ah, well that's an easy fix, for when I get an opportunity to sign in as IABot at some point. —CYBERPOWER(Message) 03:37, 17 January 2024 (UTC)Reply[reply]
RFC on the mass-draftication on stub-class Olympian articles[edit]
Should the list of stub-class articles published at Quarry query 76969 (generated by @BilledMammal) be mass-moved to draft space, subject to auto-deletion after 36 months instead of the normal 6 months? InvadingInvader (userpage, talk) 18:28, 12 January 2024 (UTC)Reply[reply]
Support as proposer. We still haven't fully cleaned up the mess that are the Lugstubs. A vast majority of these articles, if not all of them, solely reference to Olympic databases, no indication alone of fulfilling GNG. While there are some articles which can notable, a vast majority of them fail WP:NOLYMPIC, though to give a chance for them to be reviewed and remaining on Wikipedia, instead of mass-PRODification, akin to the passed WP:LUGSTUBS and WP:LUGSTUBS2, I propose that these over 22,000 Lugstubs, as part of LUGSTUBS3, be moved to draft space with a 36-month expiration date to give enough time for the good ones to be submitted to AFC and reviewed. This I believe is an appropriate concession between those who wish these article stay, and those who wish these articles be delete. InvadingInvader (userpage, talk) 18:28, 12 January 2024 (UTC)Reply[reply]
Hold on now, @InvadingInvader: - would you be willing to delay this for a little longer? I had intended on doing at some point soon a contest to cleanup articles like these, but was waiting for BilledMammal to get me a few lists. I had hoped to see if it would give any success before doing something drastic like this. BeanieFan11 (talk) 18:34, 12 January 2024 (UTC)Reply[reply]
Also, I think this would deserve more workshopping as there is almost for sure to be false positives in a massive 20,000+ article list generated by bot; the previous lugstubs discussions that were workshopped and were 25 times smaller still had many errors. BeanieFan11 (talk) 18:38, 12 January 2024 (UTC)Reply[reply]
This is why I suggest mass drafting. That way, those who wish to work on these articles as well as potential false positives would be saved and returned, whilst the truly unnecessary Lugstubs would be purged. You can still hold your contest. InvadingInvader (userpage, talk) 18:48, 12 January 2024 (UTC)Reply[reply]
Hat ~30 posts of circular back-and-forth repeating the above. Ajpolino (talk) 21:17, 12 January 2024 (UTC)Reply[reply]
@InvadingInvader: But there is no way anyone can work through 25,000 articles in that timeframe. Would you be willing to just temporarily withdraw this, do some workshopping, maybe hold the contest and re-propose at a later date? This would be a major disaster as it stands. BeanieFan11 (talk) 18:51, 12 January 2024 (UTC)Reply[reply]
How would it be a disaster? The last two LUGSTUBS proposals were successful. InvadingInvader (userpage, talk) 18:51, 12 January 2024 (UTC)Reply[reply]
@InvadingInvader: I think we need more time to work everything out before diving straight into drastic measures. There are sure to be many false positives in this and this would result in the catastrophic removal of tens of thousands of articles. I suggest trying out the contest and seeing how that works first, and if it is unsuccessful, then we could resort to this. BeanieFan11 (talk) 18:53, 12 January 2024 (UTC)Reply[reply]
Think of it this way - as it stands, 95% of these articles would never be found in draftspace and would be soon deleted. If we run the contest and it is successful, we could continue to do every so often it and work our way through in a more beneficial way that does not remove tens of thousands of potentially notable articles / that actually improves them. BeanieFan11 (talk) 18:55, 12 January 2024 (UTC)Reply[reply]
They're not being removed. They're being sent to draftspace. Remember that there are about 110,000 active users on the English Wikipedia. That's (at a minimum) four users per one article. Even if it was only one user per draft, there would be time to save these articles if they meet the GNG. I'm proposing a 36-month deadline. That is more than enough time to find sources for these articles. And hey – if they end up being deleted, but more SIGCOV comes five years later, they can EASILY be re-created. InvadingInvader (userpage, talk) 18:55, 12 January 2024 (UTC)Reply[reply]
95%+ of users here do not work in the Olympic area. This deadline is not long enough (also, see WP:NODEADLINE) and would likely have 95%+ of the articles deleted. My suggestion is the contest, which, if successful, could be repeated every so-often and would result in them being improved rather than deleted. BeanieFan11 (talk) 18:59, 12 January 2024 (UTC)Reply[reply]
Move them to draftspace then to do it. Or userfy them. They don't belong in the mainspace until there is proof that they fulfill the GNG. InvadingInvader (userpage, talk) 19:00, 12 January 2024 (UTC)Reply[reply]
Until such sources are found, move them to draftspace. InvadingInvader (userpage, talk) 19:02, 12 January 2024 (UTC)Reply[reply]
That directly contradicts the notability policy I cited above. We are not required to draftifiy everything that does not at this very moment pass GNG with the current sourcing. BeanieFan11 (talk) 19:04, 12 January 2024 (UTC)Reply[reply]
Seems closer to comparing apples to oranges. We aren't required to draftify everything, but we should. If something can't fulfill GNG, don't include it in the mainspace. That's why draftspace exists: to work on articles and get them into compliance. InvadingInvader (userpage, talk) 19:07, 12 January 2024 (UTC)Reply[reply]
(edit conflict) You say that we should, but draftify policy is that "Older articles should not be draftified" (90-day cutoff). If something can't fulfill GNG, don't include it in the mainspace – the thing is, a large portion of these are notable... I agree with Folly Mox below. BeanieFan11 (talk) 19:09, 12 January 2024 (UTC)Reply[reply]
Why should these articles remain in the mainspace before we can find GNG-fulfilling coverage? InvadingInvader (userpage, talk) 19:08, 12 January 2024 (UTC)Reply[reply]
Past consensus disagrees. Per the discussions at LUGSTUBS and LUGSTUBS2, the community has agreed that these articles in most of their current state belongs in the draftspace, or at the very least not the mainspace. InvadingInvader (userpage, talk) 19:12, 12 January 2024 (UTC)Reply[reply]
Those both passed by the skin of their teeth and affected much smaller quantities of articles. This proposal is too rushed and needs workshopping. BeanieFan11 (talk) 19:13, 12 January 2024 (UTC)Reply[reply]
Quote the closure of LUGSTUBS2: a stronger consensus that they should not be left in mainspace. Skin of your teeth? InvadingInvader (userpage, talk) 19:15, 12 January 2024 (UTC)Reply[reply]
Also from the closure: However, I would urge the proposers not to charge headlong into the draftification process without further thought. A lot of people are uncomfortable with the large number of articles—a list of 1200 people from different eras and different nations is very difficult for humans to parse and I would urge the proponents to break it down. BeanieFan11 (talk) 19:16, 12 January 2024 (UTC)Reply[reply]
Would you rather have 22000 AfDs, or 22000 drafts? InvadingInvader (userpage, talk) 19:18, 12 January 2024 (UTC)Reply[reply]
I would rather us go through them in a sensible and non-rushed way (WP:NORUSH), such as holding contests to improve the notable ones while steadily nominating others for deletion. BeanieFan11 (talk) 19:19, 12 January 2024 (UTC)Reply[reply]
Why not do it in draftspace then for the time being? That's where articles are meant to be improved to be better than stub class InvadingInvader (userpage, talk) 19:22, 12 January 2024 (UTC)Reply[reply]
Because draftspace makes it a rush and imposes a deadline (WP:NODEADLINE). Articles can be improved in mainspace too, you know. BeanieFan11 (talk) 19:23, 12 January 2024 (UTC)Reply[reply]
That's why I proposed an extended deadline for drafts. Also that allows us to spare tens of thousands of AfD debates. InvadingInvader (userpage, talk) 19:25, 12 January 2024 (UTC)Reply[reply]
It is still a deadline that is way too short; we do not have enough editors to go through nearly 1,000 tough-to-research articles a month. BeanieFan11 (talk) 19:26, 12 January 2024 (UTC)Reply[reply]
You can always recruit more editors. Request a mass-messenger to send a mass message out. NPP does it all the time. InvadingInvader (userpage, talk) 19:27, 12 January 2024 (UTC)Reply[reply]
Three years should be enough time anyways. If you want five years I'll give you five years. InvadingInvader (userpage, talk) 19:28, 12 January 2024 (UTC)Reply[reply]
Or we could just improve them in mainspace, which means that editors can work at their own pace without a imposed deadline that will result in mass deletion... You've been systematically PRODing and AFDing Olympians - I support your efforts there - but not 25,000 all at once. BeanieFan11 (talk) 19:29, 12 January 2024 (UTC)Reply[reply]
@InvadingInvader: Would you be willing to withdraw this for now so it can be workshopped and the terms discussed further (maybe hold the competition(s) and see how it goes, etc.)? BeanieFan11 (talk) 19:46, 12 January 2024 (UTC)Reply[reply]
Probably not productive to relitigate LUGSTUBS2 with a 70% shorter G13 immunity window. Needs workshopping, preferably at a dedicated page. Folly Mox (talk) 18:56, 12 January 2024 (UTC)Reply[reply]
I've removed the RfC tag since this is clearly premature. Galobtter (talk) 22:17, 14 January 2024 (UTC)Reply[reply]
very strongly oppose. This has all the problems identified at the previous proposal (which only barely had consensus), only worse because of the vast number of articles that have not even been attempted to be pruned for false positives, etc. Thryduulf (talk) 11:05, 15 January 2024 (UTC)Reply[reply]
RfC: allow soft deletion of unopposed nominations[edit]
If a nomination has received few or no comments from any editor, and no one has opposed deletion, and the article hasn't been declined for proposed deletion in the past, the closing administrator should treat the XfD nomination as an expired PROD and follow the instructions listed at Wikipedia:Proposed deletion#Procedure for administrators.
This proposal would remove the requirement that an article be eligible for PROD to be "soft deleted". In effect, this would mean poorly-attended but unopposed deletion debates can be closed as WP:REFUND-eligible soft delete.
Survey (RfC: allow soft deletion of unopposed nominations)[edit]
Support as proposer. In December, there were 46 deletion nominations ultimately closed as delete after being relisted as "ineligible for soft deletion": 1, 2, 3, 4, 5, 6, 7, 9, 10, 11,[a]12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 30, 31, 32,[b]33, 34, 35, 36, 37, 38,[c]39, 40, 41, 42, 43, 44, 45, and 46.In fairness, there were four (4) articles that are still bluelinks because they were ineligible for soft deletion: 1,[d]2, 3,[e] and 4. But I don't think that a redirect, a stub, a non-neutral REFBOMB mess, and No Pants Day justify the volunteer time rubber-stamping nominations. WP:OFD2023 shows that ~15% of AfD nominations are closed as keep, which is ~twice the 8% survival rate of the "ineligible-for-soft-deletion" December group. This suggests that editor time is better spent rescuing other articles.Finally, I will note that this change would still allow for WP:REFUNDs of the affected articles. HouseBlastertalk 01:15, 13 January 2024 (UTC)Reply[reply]
I want to add a little bit to my rationale: this proposal would result in PROD and soft deletion being treated differently, and that is the point. A well-advertised-but-unattended discussion is not the same thing as a banner staying atop a page for a week. Arguing against this proposal because it would treat soft deletion and PROD differently is textbook circular reasoning: treating them the same way is A Good Thing because they should be treated the same way. Respectfully, why should fundamentally different processes have the same outcome?I would also point out that the status quo is the 46 articles from December are "hard" deleted: you either need some showstopping sources to show the closer/an admin at WP:REFUND or else must make your case at WP:DRV to get them undeleted. This proposal would result in all of them being REFUND-eligible. HouseBlaster (talk · he/him) 03:29, 14 January 2024 (UTC)Reply[reply]
Strong support no irreversible harm. Potential abuse/misuse is mitigated by a single user and in worst case, a guaranteed WP:REFUND is always possible. ~ 🦝 Shushugah (he/him • talk) 01:36, 13 January 2024 (UTC)Reply[reply]
Support Makes it easier to restore deleted articles and discourages drive-by/rubber stamp !votes. Seems like a net-positive. -Fastily 01:54, 13 January 2024 (UTC)Reply[reply]
Support but caveats: The nominator must make a clear delete rational; the nominator must declare that they have followed WP:BEFORE, and say why the BEFORE options, especially WP:ATD are not suitable. I assume that this can override a previous PROD removal. —SmokeyJoe (talk) 05:29, 13 January 2024 (UTC)Reply[reply]
Oppose I have always held that soft deletion at AfD is simply a procedure where we pretend that the nominator, instead of nominating the article for AfD, tags it for PROD instead. So there should be no difference in the rules for soft deletion vs. PROD IMO. However, I am open to considering introducing an expiration for PROD declines, such that an article which has not been declined for PROD in, say, the last five years becomes eligible for both PROD and soft deletion. The reason why declined PRODs are ineligible for PROD is the same reason why we discourage edit warring - you shouldn't be able to get the last say just by being more obstinate at forcing your changes through. However, five years is long enough to presume that the original decliner may have forgotten about the article; they can always maintain their opposition by re-removing the PROD or !voting keep at AfD. -- King of ♥ ♦ ♣ ♠ 06:19, 13 January 2024 (UTC)Reply[reply]
Strong support as outlined by nominator. Makes perfect sense. Best Alexandermcnabb (talk) 09:02, 13 January 2024 (UTC)Reply[reply]
Support. It took me a bit to parse the proposal, which boils down to "can articles be soft deleted if they've had a contested PROD?". Q for nom: would this change mean that after a single week a decision would be made, or would the normal relisting cadence happen? I'm with King of Hearts in an alternate solution where a soft deletion would only be blocked if the PROD was less than some number of years ago. Eight years, perhaps? Ten seems too long (2014 was a decade ago) but 5 feels too soon (2019 was just a few days ago). SWinxy (talk) 19:22, 13 January 2024 (UTC)Reply[reply]
I envisioned it being a tool in the closer's toolbox: namely, if they feel relisting would be productive, relist. If not, it would be eligible for soft deletion. HouseBlaster (talk · he/him) 22:33, 13 January 2024 (UTC)Reply[reply]
Oppose per King of Hearts. If someone nominates an article for PROD, which is contested, and then immediately renominates it for AfD, just because the person who opposed that PROD didn't show up to the discussion, doesn't mean the article should be deleted. Also open to allowing PROD again after 10 years or something like that, but soft deletion is just applying PROD rules to AfD. Galobtter (talk) 19:31, 13 January 2024 (UTC)Reply[reply]
Oppose. This proposal would effectively allow an article to be PRODed twice. If a PROD has already been removed once, the nomination is controversial. If the person who removes the PROD states in his edit summary that the article should not be deleted, or that the grounds for deletion are erroneous, or that the article satisfies GNG, or the like, I can only infer that the AfD is not unopposed, and that making a comment like that amounts to opposition. James500 (talk) 02:53, 14 January 2024 (UTC)Reply[reply]
This proposal is also explicitly based on the assumption that changing the rules of AfD will not change the behaviour of AfD participants described by the statistics cited. It is not obvious that the assumption is true. This proposal might result in an increase in the number of nominations being made in the first place. Nominators might decide to send every declined PROD to AfD in the hope of getting a soft deletion while no one is watching. This proposal might also result in more keep !votes being made in the first place, if deprodders cannot just wait for an unattended AfD to be closed as no consensus. I also notice that the statistics cited are for December (the time of year when we have the fewest active editors), and do not take into account any seasonal variation that might exist. James500 (talk) 18:06, 14 January 2024 (UTC)Reply[reply]
Fair enough point about seasonal variation. I pulled the statistics for June 2023 (chosen as halfway through the year): 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 30, 31, 32, 33, 34, 35,[f]36, 37,[g]38, 39, 40, 41, 42, 43, 44, and 45.Bluelinks: 1, 2, 3, 4, 5, 6. There is also Wikipedia:Articles for deletion/Log/2023 June 16#Explore Learning, which I am not sure which category to put in. It was closed as "delete", but is currently a redirect to ExploreLearning (without a space). That article appears to be on an entirely different company. At the very least, the two articles (Explore Learning and ExploreLearning) coexisted for a period of time—maybe there was a WP:CONTENTFORK? I'd appreciate it if someone with admin goggles could take a look.Finally, the behavior changes you cite seem to be positive changes. The point of any discussion is to find consensus, which logically means "no consensus" closes are not an ideal outcome. We allow speedy renomination of no consensus closes for a reason, after all. Thus, I would argue that discouraging dePRODers from seeking a "no consensus" close is a good thing. I also take issue with the assertion that Nominators might decide to send every declined PROD to AfD in the hope of getting a soft deletion while no one is watching. First, I would hope that people would not attempt to game the system. But holding a full-blown AfD is absolutely not while no one is watching. There is a banner atop the page (which was evidently enough to attract the dePROPer), it is listed on the daily AFD log, and there is literally an entire WikiProject dedicated to ensuring other interested participants see the discussion. HouseBlaster (talk · he/him) 22:13, 14 January 2024 (UTC)Reply[reply]
Oppose there is often low participation at AfD so waiting a second week for comments is reasonable. Also the deprodder would be rushed into responding when they may be offline for a period. This suggestion would unnecessarily speed up deletion without any consensus in my view, Atlantic306 (talk) 22:48, 14 January 2024 (UTC)Reply[reply]
Oppose. If an article is ineligible for PROD then it is, by definition, controversial and is thus completely unsuitable for deletion without an active consensus to do so. Thryduulf (talk) 11:01, 15 January 2024 (UTC)Reply[reply]
Oppose, although well-motivated, this proposal would open the door to deletion of articles that just don't happen to be interesting to the handful of editors who regularly visit AfD, even when the nomination is obviously spurious or misguided. Admins should be both allowed, and expected, to use their discretion to relist, or otherwise ensure that deletion is for policy-based reasons, not just because no one could be bothered that week. Elemimele (talk) 12:10, 15 January 2024 (UTC)Reply[reply]
Oppose may open door for misuse. I see these cases as no consensus to delete which if anything should default to keep. Well-meaning proposal but defies conventional wisdom. --PeaceNT (talk) 04:36, 16 January 2024 (UTC)Reply[reply]
Support. If nobody cares enough about an article to make a brief comment on an AFD, it does not have enough support to exist. Stifle (talk) 09:52, 16 January 2024 (UTC)Reply[reply]
Support. If nobody can rebut the argument for deletion then we shouldn't be keeping the article, per WP:CONSENSUS. BilledMammal (talk) 11:44, 16 January 2024 (UTC)Reply[reply]
Meh This RFC seems poorly written, as it fails to note that very section the nomination links to goes on to offer several options for when it was an opposed prod, one of which already is soft deletion. It's unclear to me whether "supports" will be interpreted as supporting the status quo or as calling for something more strict, and I could see some opposes actually supporting the status quo too. I see there was a better-worded RFC on this topic at Wikipedia talk:Deletion process#Clarifying NOQUORUM Soft Deletes that didn't get many responses.Personally I think we can afford a relist or two before soft-deleting, even if the de-PRODder didn't notice the AFD to oppose there too, per WP:NODEADLINE. But leaving it open to admin discretion (i.e. the status quo) is ok with me too on the assumption that admins will save immediate soft deletion for clearer cases. Anomie⚔ 12:12, 16 January 2024 (UTC)Reply[reply]
Oppose For similar reasoning as King of Hearts. I would not necessarily be opposed to this in cases with a multi-year gap between PROD and AfD, but I do not like the idea of essentially being able to PROD an article twice in a short period of time. As for a timeframe, leave it to admin discretion. Curbon7 (talk) 12:24, 16 January 2024 (UTC)Reply[reply]
Oppose - a week is nowhere near enough time, a lot of articles for deletion are likely to be on more obscure topics, that we possibly should have articles about, but that most editors will not be familiar with. A week is not enough time to be seen by someone who might be able to expand the article or explain it's importance. If there's an automatic deletion cut-off it should be closer to a year. Irtapil (talk) 15:11, 16 January 2024 (UTC)Reply[reply]
Procedural Oppose per Anomie. There is a lot of context missing from this RfC, such as how that sentence got added to the process and the conflict with another part of the same section, i.e. it may already be an option. I put forward a discussion at Wikipedia talk:Deletion process#Clarifying NOQUORUM Soft Deletes to try and discuss some different wordings and options that could be used in a proper RfC per WP:RFCBEFORE. It would be advisable to close this discussion, workshop the wordings on that talkpage, and come up with a more comprehensive one since the current wording is self-contradictory. The WordsmithTalk to me 20:52, 16 January 2024 (UTC)Reply[reply]
I take this proposal to be stating that we should strike and the article hasn't been declined for proposed deletion in the past, which I think would resolve the contradiction. voorts (talk/contributions) 04:01, 17 January 2024 (UTC)Reply[reply]
Discussion (RfC: allow soft deletion of unopposed nominations)[edit]
So to be clear and article like MIKTA would be deleted even though the rationale doesn't make sense?Moxy- 22:42, 13 January 2024 (UTC)Reply[reply]
No, because someone expressed opposition to deleting the article in the discussion. (If that comment had not been made, the article would be eligible for soft deletion under the current rules.) HouseBlaster (talk · he/him) 22:54, 13 January 2024 (UTC)Reply[reply]
So not comment then default deletion ..... do those involved in deletion at least look for sources...as in is there an common sense or effort involved if noone comments? Moxy- 04:48, 14 January 2024 (UTC)Reply[reply]
If people are not looking for sources before !voting, I would argue that is a problem beyond the scope of this proposal.HouseBlaster (talk · he/him) 02:42, 15 January 2024 (UTC)Reply[reply]
MIKTA is just a case of a really bad nomination by a user who clearly sent an article to AfD without Googling its title. Lazy nominations are a problem with or without soft deletion. Pichpich (talk) 04:35, 15 January 2024 (UTC)Reply[reply]
But soft deletions make the effects of lazy nominations very significantly worse. Thryduulf (talk) 11:02, 15 January 2024 (UTC)Reply[reply]
Perhaps, although I'd be counting on the closing admin to review the deletion rationale before actually soft-deleting the article, just as I'd expect admins to close PRODs as deletions only after performing the usual and basic WP:BEFORE checks. Am I just being naïve here? Pichpich (talk) 12:58, 15 January 2024 (UTC)Reply[reply]
Am I just being naïve here? unfortunately you are. While the worst offender that I know of was desysopped, there is no shortage of deletions being done without proper checks. Thryduulf (talk) 14:56, 15 January 2024 (UTC)Reply[reply]
I know for a fact at least some admins don't look at articles at all when closing deletion discussions, so no. (And TBF deletion closers have a lot of work to do without replicating the participants work) Mach61 (talk) 16:49, 15 January 2024 (UTC)Reply[reply]
Notes
^with the relist comment Not eligible for soft-deletion (due to contested prod back in 2006 (!) ...)
^a batch nomination of seven was relisted because one had been dePROD'd
Restoring the lists of contents under the lede[edit]
Why not restore the lists of contents of pages under the lede and in bold as it was before?
Now, to see the lists you have to click on that symbol to the left of the page's title. It took me several months to discover that the lists still existed and how I could make them appear by clicking on that god**** symbol. I'm convinced that, like me, zillions of occasional readers will not realize that the lengthy article they're reading actually has a useful list of contents hidden somewhere. To fulfil their purpose lists of contents should be user-friendly, that is, instantly visible, not discreetly tucked somewhere. Lubiesque (talk) 20:49, 13 January 2024 (UTC)Reply[reply]
On most screens the table of contents is visible by default on the sidebar, but on narrow screens it is not. Are you viewing on a narrow screen (or did you accidentally hide it - you can unhide it by hitting the "move to sidebar" button). Galobtter (talk) 21:09, 13 January 2024 (UTC)Reply[reply]
Maybe this varies by skin. I am using the legacy vector 2010 skin and the TOC appears below the lede. RudolfRed (talk) 21:11, 13 January 2024 (UTC)Reply[reply]
I realize I should have looked around more.. After all, it was unlikely that the lists of contents would be gone for good.--Lubiesque (talk) 21:50, 13 January 2024 (UTC)Reply[reply]
Lubiesque this occurred when the WikiMedia Foundation changed the skin of Wikipedia against the wishes of the community. You can go into your settings and switch from Vector 2022 to Vector 2010 if you want to change it back. There's also an ongoing discussion about the change where you can leave your feedback. Thebiguglyalien (talk) 23:45, 13 January 2024 (UTC)Reply[reply]
Note that the closers of the RfC initiated before the rollout determined that participants expressed overall...positive reception to the changes. — Frostly (talk) 23:25, 14 January 2024 (UTC)Reply[reply]
Because the Wikimedia Foundation refused to do so, instead deciding to suddenly roll out a major UI redesign with little notice and significant issues. See WP:V22RFC2. InfiniteNexus (talk) 04:43, 15 January 2024 (UTC)Reply[reply]
Color Bars are used on nonpartisan election articles which are located on the bottom of the where the political party would be located if the election was not nonpartisan
Some Wikipedia editors have removed the Color bars and replaced the colors with political party as a good faith edit on the election articles, and concerns and objections have been put forward. Removed the Color bars and replaced the colors with political party as a good faith edit Assuming that the candidate is in a politicil party with out displaying the name which can cause issues add disruptions to nonpartisan election articles. I propose Color Bars should not be used at all on Infobox election of nonpartisan election main page articles in The United States DLCY89* (talk) 02:28, 16 January 2024 (UTC)Reply[reply]
After reviewing this thread, the linked diffs and talkpages, and the requested closure above, I'm supremely unimpressed with the conduct of a number of people in this topic area. It certainly isn't just one person, incivility is rampant throughout the area. In order to break the back of this problem, I'd propose General Sanctions be authorized for the Darts topic area, text below copied from WP:GS/PW. The WordsmithTalk to me 02:04, 17 January 2024 (UTC)Reply[reply]
Any uninvolved administrator may, at his or her own discretion, impose sanctions on any editor working in the area of conflict if, despite being warned, that editor repeatedly or seriously fails to adhere to the purpose of Wikipedia, any expected standards of behavior, or any normal editorial process.
The sanctions imposed may include blocks of up to one year in length, bans from editing any page or set of pages within the area of conflict, bans on any editing related to the topic or its closely related topics, restrictions on reverts or other specified behaviors; or any other measures which the imposing administrator believes are reasonably necessary to ensure the smooth functioning of the project.
Prior to any sanctions being imposed, the editor shall be given a warning with a link to this decision and, where appropriate, should be counseled on specific steps that he or she can take to improve his or her editing in accordance with relevant policies and guidelines.
Sanctions imposed may be appealed to the imposing administrator or at the appropriate administrators' noticeboard.
Support. The AN thread is quite revealing of how editors interact in that topic area. voorts (talk/contributions) 04:11, 17 January 2024 (UTC)Reply[reply]
.jpg)
Courtesy link: User talk:Σ#Archiving in the context of a page that uses level-one headings as dividers
22:42, 13 January 2024 (UTC)
04:48, 14 January 2024 (UTC)