This page contains discussions that have been archived from Village pump (proposals). Please do not edit the contents of this page. If you wish to revive any of these discussions, either start a new thread or use the talk page associated with that topic.
Removing links to portals from the Main Page's top banner
This discussion was subject to a closure challenge which was closed and left the original close standing.
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.
(non-admin closure) Until the moment of closure, we've had 30 votes in favor of removing the portals and 17 in favor of keeping them. The reasons offered by the nominator are not based on Wikipedia policies or guidelines, but focus on the usefulness and relevance of these portals at the top of the Main Page. In brief, the proposal is based on (1) & (3) Lack of much use: “the pageviews of these portals is very low compared to the pageviews of the main page”, and “subjects in an encyclopaedia are used by readers who are looking for something specific, while a reader who would want to learn ‘something new’ would just read an article at random”, (2) Opposition to all portals: “portals are among the least well maintained and most outdated-looking parts [in Wikipedia]”, and (4) Inefficiency: “the net has largely moved on from the tendency of early websites to have 50 hyperlinks per square centimeter.” Those in support of Keeping the portals as they are object to the claim they are not used much. They also argue in favor of the status quo, on the basis of which they see no significant reason to change. (Arguments about the Main Page being the same way for "too long" have been offered by supporters of removing the portals.) In all, there is a significant number of editors against removal of portals, though they're a numerical minority. Arguing on the basis of #1 & #3 in support of removing the portals, “lack of much use”, were 9 contributors (Sdkb, Gog the Mild, Anarchyte, Retswerb, EpicPupper, CaptainEek, Jackattack1597, Firefly, Pldx1); on the basis of #2, “against all portals”, 8 contributors (Schierbecker, Vexations, SmokeyJoe, Izno, Sandstein, Guilherme Burn, Gadfium, Remagoxer); and of #4, “efficiency,” 12 contributors (Blueboar, UnitedStatesian, Ruslik0, Calliopejen1, AleatoryPonderings, Bilorv, Neil Shah-Quinn, Levivich, Aza24, Zero0000, SnowFire, Cavalryman). One supporter of removal (Moxy) did not provide a reason but their suggestion was counted, while another one (NightWolf1223) made an internally contradictory and thus invalid suggestion, i.e. by choosing “support per Kusma” while Kusma opposed. Editors using argument #2 are commenting on all portals and not specifically on these portals, although these editors might argue that they phrased their input in a more complex way. Clearly, though, the context of their suggestions revolves around the general worthiness of portals. If we're not arguing about portals in general, we can only discuss the ones on top of the Main Page. The combination of arguments #1, #3, and #4 calls essentially for an overhaul of these portals' design, place, and content, since as they currently stand, the argument goes, they are not used much and are inefficient. Logically, if they were designed differently, were placed somewhere "better" on the Page, and their content was improved, then they could stay up. However, this nuance gets buried under the binary choices offered, especially after initiator JBchrch added the choice to move the portals, instead of removing them entirely. Because of the confusion, we have suggestions to Remove which include the option to Move (elsewhere, mostly in the Main Page), while we also have editors favoring Keep that express also the need for an "overview" of the whole page, such as Certes, Godsy, and others. The discussion under the Survey section is, naturally, quite useful in identifying more clearly where the participants stand. Of obvcious and evident importance are the remarks from the initiator ("My impression—but I'm happy to defer—is that we are not likely to solve all of these question in this single survey"), as well as from other users (e.g. "We need to be wary of pitting one option against an alliance of the others as a binary choice."), which cannot but be taken into account. In conclusion, and despite the numerical majority of what appears to be removing the portals, this is an adulterated result and the decision seems clear: We have no consensus to move forward with altering the Main Page through this RfC because it did not offer clear-cut choices and thus did not manage to elicit clear-cut responses. For the time being, then, we should not remove the portals from the top of the Main Page. The way forward for editors keen to change this aspect of the Main Page could be a gradual one. #1 discuss about having portals in general or not having them at all in the Main Page. #2, in case the result of #1 is to keep portals on the Main Page, discuss where to place them. After this has been established, a new one, #3, may be initiated on the content of the portals themselves: Do we find them all useful? Or do we want some of them to be eliminated? And so on. The "way forward" part should be understood as only my humble advice; it's not part of the decision. -The Gnome (talk) 15:38, 10 December 2021 (UTC)
Survey (Portal links)
I propose that we remove the hyperlinks to eight portals and the "All portals" page that are currently in the main page's top banner. Instead, the top banner would simply say "Welcome to Wikipedia, the free encyclopedia that anyone can edit. 6,[xxx],[xxx] articles in English" (same as now, but centered). I have the four following arguments:
The pageviews of these portals is very low compared to the pageviews of the main page (low thousands vs. 5+ millions), which suggest that no one clicks on them they are not essential to the main page's function.
Portals are among the least well maintained and most outdated-looking parts of the project.
Portals are not essential to the mission of an encyclopedia, which are generally ordered alphabetically, and used by readers who are looking for something specific. A reader who would want to learn something new would just read an article at random.
In terms of graphic design, the Internet has largely moved on from the tendency of early websites to have 50 hyperlinks per square centimeter. Removing these hyperlinks would ever so slightly modernize the user interface.
Note: This proposal only argues for the removal of the links from the top banner. You are welcome to express views on whether they should be moved somewhere else on the main page, as some editors have already done. JBchrchtalk10:56, 28 October 2021 (UTC)
The page views of each of the top portals are roughly the same as those of typical Did you Know items, suggesting that people click on them reasonably often. —Kusma (talk) 16:44, 26 October 2021 (UTC)
Support with partial move of the "all portals" link to the "Other areas of Wikipedia" section. To give folks some data, here are the pageviews of the listed portals. Most range from 2000 to 5000 views per day, which would be decent to good for a DYK, but they're at the top of the page rather than in the middle so should be expected to do better. The "all portals" link, however, does significantly better at 12,400 per day. Broadly, portals as an idea have failed and ought to be mercifully put to rest, as they're not worth our effort to maintain. But until that outcome achieves consensus, it's not fair to kneecap them by totally removing them in places where they're relevant, which includes the main page. The other areas of Wikipedia section is pretty far down the page, so throwing in a line there along the lines of Content portals – A unique way to navigate the encyclopedia would be pretty innocuous (it would also help rebalance the section towards readers). {{u|Sdkb}}talk18:13, 26 October 2021 (UTC)
Strong support This would make the main page look much cleaner. Any incremental step to drag the page design into the 2020s (2010s?) is a good thing. UnitedStatesian (talk) 18:31, 26 October 2021 (UTC)
The Main Page is in need of some updating. The top portals are remnants of a "systematic" approach to content organisation that the world is too complicated for. We should consider linking to good portals (Portal:Cheshire, Portal:Japan) more prominently instead of focusing on those that seem important from an abstract top-down point of view. —Kusma (talk) 18:44, 26 October 2021 (UTC)
Well, quality control for portals is currently done through MFD, which isn't great. But that's a different discussion; I mainly wanted to point out that individual good portals still exist, despite the bad reputation of the namespace. —Kusma (talk) 13:29, 27 October 2021 (UTC)
Oppose any such change without a broader more centralized discussion. As an oft accused Portalista, I would be remiss if I did not accuse the OP of being a part of the war on portals. Sorry for the sarcasm, folks; had to throw down THAT gauntlet before anyone else. No offense User:JBchrch (who was not here during the portal wars); I was making a poor joke at my own expense. If in this thread a redesign of the main page is under discussion, what else is on the table? As an inhabitant of Planet PortalFan I must protest any removal of any link to any portal anywhere. Seriously, this cut would be pretty brutal on total portal views. Kneecapped. I'm not convinced that portals have gone the way of the dodo quite yet. Not everybody learns in the same way. The portals linked look good and seem well-maintained. I do very much like the turn of phrase by User:Sdkb: "A unique way to navigate the encyclopedia". BusterD (talk) 20:05, 26 October 2021 (UTC)
Regarding what else is on the table, we should limit discussion to the presentation of portals on the main page. Anything less focused will become a trainwreck without additional structure. VPR is pretty centralized, but portals folks should certainly be notified and this can be CENT-listed if needed. {{u|Sdkb}}talk20:13, 26 October 2021 (UTC)
@BusterD: No offense taken! In addition to Sdkb's comments, I just wanted to note that I have no strong views on placing the portal links anywhere else on the main page. I just think they are out of the place at the absolute top. I will now place a notice on WT:PORT. JBchrchtalk20:27, 26 October 2021 (UTC)
Comment: I do use the top-level portals from time to time. Providing multiple means of content navigation is definitely helpful. No objection to moving to a different part of the page but I'd strongly favor keeping all of the links somewhere on the home page above the fold. Seems more helpful than the "On this day..." or "Did you know..." content. - Wikmoz (talk) 20:39, 26 October 2021 (UTC)
There are some interesting Wikipedia home page redesignconcepts around the web. Short of broad consensus to remove, I think this one is in the hands of Wikimedia's staff designers. - Wikmoz (talk) 23:55, 26 October 2021 (UTC)
It's in the hands of the Wikipedia community. It's all done in wikitext; there's nothing in the MediaWiki software that requires or prohibits these links or restricts their position or appearance. German WP lists the portals more prominently with icons; French WP has a single link ("Portails thématiques") to its main portal. Certes (talk) 00:22, 27 October 2021 (UTC)
Just a note to point out that both of these design seem to rely on incredibly high-def pictures, which we rarely have (except for the occasional European painting). In the first link, for instance, the big Nelson Mandela picture is not on Commons as far as I can see. JBchrchtalk00:37, 27 October 2021 (UTC)
The second design link there prioritizes the portals in a very nice and logical way - if they were something that we as a community were really putting effort into and wanted to promote. Retswerb (talk) 06:34, 6 November 2021 (UTC)
Wow! Some of these redesigns are beautiful!!! Are these independent third-party mockups? Or anything that is actively being considered by WMF? Ktin (talk) 20:57, 1 December 2021 (UTC)
I could see moving the portal links below the featured picture (and above “Other areas of Wikipedia”). It would put the navigational parts of the main page together. Blueboar (talk) 20:46, 26 October 2021 (UTC)
Oppose complete removal but support a review of the Main Page layout. The portal list fits in a handy space of just the right size. If more widely used information could usefully fit into that prime real estate then let's move the portal list down to make way, but I don't see any great candidates to replace it. The two traditional ways to organise and access content are alphabetically and by topic. An alphabetical article listing is obviously impractical, but the search box does that job well. I think access by topic is still worth a couple of square inches somewhere above the fold. Certes (talk) 23:41, 26 October 2021 (UTC)
@Certes: I guess the graphic design argument would be to say that we don't need a replacement, since the most straightforward way to modernize the MP's design is precisely to remove stuff and to leave some prime real estate empty [1][2][3][4][5][6][7][8][9]. Such a wholesale proposal is obviously well beyond the scope of this particular VPR section, but the idea that a removal would require a replacement seems to run somewhat contrary to the emerging consensus that the main page needs to be modernized. JBchrchtalk00:10, 27 October 2021 (UTC)
Then I suppose it boils down to which better serves our readers: wikilinks, or white space. Personally I think it's no contest, but then I'm not a graphic designer. Certes (talk) 12:21, 28 October 2021 (UTC)
Support Portal links are not terribly helpful to readers and the Main Page could benefit from streamlining (this is a good first step). Calliopejen1 (talk) 21:51, 27 October 2021 (UTC)
Support, as a first step in the deprecation of the portal namespace. They serve no useful function that is not served by wikilinks generally. Portals are collections of links; articles are better, more helpful, and better maintained (as suggested above) collections of links. AleatoryPonderings (???) (!!!) 22:35, 27 October 2021 (UTC)
Oppose - Prominently displaying a manner to help readers navigate our content in a systemized manner is due. If there is a better way to do this in the current location, it should readily be considered. Until then, the current scheme suffices. That aside, perhaps our 'indexation' warrants maintenance or improvement as a whole. However, aesthetical considerations to appear modern or streamlined should never take precedence over form and functionality.— Godsy (TALKCONT)03:27, 28 October 2021 (UTC)
Support. Confusing noise, and portals fail to provide systematic navigation (categories do that, Portals do random and highly selective stuff). Portals belong under the Wikipedia:Community portal link in the Navigation frame, and they all belong in Wikipedia project space, because Portals if they can do anything, can draw in new editors. — Preceding unsigned comment added by SmokeyJoe (talk • contribs) 03:42, 28 October 2021 (UTC)
Oppose the first argument is flawed: very few people who go to the main page click on any of the links on it, and so this argument can be used for removing anything on it. For example Hoopoe starling, which was TFA two days ago and otherwise got very little traffic, got 30,000 hits when it was up there, a tiny fraction of the over 5 million people who viewed the main page yesterday. I think it's entirely legitimate to give readers a way of using Wikipedia from the main page other than a search box. I'm happy to consider moving the links somewhere else, but not removing them entirely. Hut 8.507:43, 28 October 2021 (UTC)
@Hut 8.5: This proposal is not arguing in favor a removing from the main page completely, but just removing them from the main page's top banner. It leaves completely open the question of relocating them somewhere else on the talk page, and you are of course welcome to express a view on that. But your !vote seems to indicate that you want the portal links to stay at the top of the main page, which does not seem entirely consistent with the rest of your answer. Is that your view? JBchrchtalk09:20, 28 October 2021 (UTC)
@JBchrch: your opening on this didn't make that very clear - of course anything can come up in discussion - but when you say "remove x from y" as opposed to "move x from y (to z)" from the start, that people think this is only about deletion shouldn't be too surprising. — xaosfluxTalk10:44, 28 October 2021 (UTC)
@JBchrch: I think it may help guide the discussion more (there was nothing defective about the preceding discussion, but the clarity may help those joining consider the option). — xaosfluxTalk11:02, 28 October 2021 (UTC)
Thanks; that's a lot clearer. I'd interpreted remove the hyperlinks as getting rid of them rather than changing their location. However, if we are to retain the links in a different location, that should happen in a single operation. It would be wrong to get rid of the links now pending further discussion to consider the possibility of a decision about finding a better place for them in the fullness of time. Certes (talk) 11:29, 28 October 2021 (UTC)
Yeah - as it stands this is a proposal to remove the links, and some of the supporters do want the links removed entirely. If I support it and it gets enacted then they will likely be removed completely. If they are to be moved somewhere else then that should happen as the result of a single discussion. I wouldn't object to a proposal to move them somewhere else. Hut 8.511:53, 28 October 2021 (UTC)
Comment - Interesting links to support this discussion:
Strong support: just a reminder that most of our readers are on mobile, even though almost all editors are on desktop. On mobile in particular, these portal links clog up the screen with links that put the interesting content we have to display a screen further away. Sdkb's partial move works fine to me (though they're referencing a panel I'd mostly remove in my ideal Main Page redesign). — Bilorv (talk) 13:08, 28 October 2021 (UTC)
I support full removal strongly as first choice per all previous discussion on portals and move to "Other areas of Wikipedia" per Sdkb as a second must-have-consensus choice (probably just with a link to Portal:Contents [why is that an entirely different portal system in Wikipedia space???]). If portals are honestly used, moving the ones on the main page will be a good test.
I thoroughly reject blocking this improvement on a "systematic front page redesign", which has not achieved a consensus revised look for 15 years. Incremental change seems the name of the game for at least this aspect. --Izno (talk) 14:36, 28 October 2021 (UTC)
Comment Well, it depends. Is there a benefit to those specific portals being where they are? Would anything be lost if removed? I guess the thinking behind it is that people would've went to the main page and went through these broad topics, turns out, this didn't really happen, especially because of the search bar. But there is no reason to totally remove the portals from there. Just keep a link to "All portals". I'm not so sure about moving it to "Other areas". If a move like that happens, there should probably be a notification of the change on the page for a few days. Or for any noticeable changes to the main page, really. Dege31 (talk) 15:25, 28 October 2021 (UTC)
Oppose, creates more useless whitespace. If the portal links are removed, the banner should not be full width. —Kusma (talk) 16:55, 28 October 2021 (UTC)
Any designer will tell you that an overly cluttered layout is absolutely a real problem (even if Wikipedia, unlike the rest of the modern web, sometimes has trouble acknowledging it). {{u|Sdkb}}talk20:01, 29 October 2021 (UTC)
Oppose If it would just mean leaving a blank space. If there something specific to go there, or if removal would allow some beneficial change, I'd be happy to reconsider. I'm not for removing things that are "not essential", nor for giving more help to readers looking for things "at random", nor for "slightly modernizing". Thincat (talk) 18:57, 28 October 2021 (UTC)
I'm curious too! Some layout change rather than a change of content. I like all of TFA, DYK, ITN and OTD. Personally, I'd like to see the featured picture without scrolling down but I've no idea how that could work. Thincat (talk) 20:47, 28 October 2021 (UTC)
Support. I don't think portals are a useful way to navigate the vastness of this Wikipedia, and they certainly aren't useful enough to merit such a prominent position. I support full removal from the main page or, failing that, moving them to a less prominent position. Having more blank space is not inherently a problem, and leaves us the option to add something better there in the future.—Neil Shah-Quinn (talk) 01:45, 29 October 2021 (UTC)
Support removal mostly a combination of "per" the support !votes above but also because I find the rationales for keeping the portal links quite unconvincing. Having more blank space is a good thing; that's basic layout and design principles. We don't want a "busy" or full front page. (Most readers are mobile anyway and there won't be blank space for them.) Just because "some" people find it useful isn't a good reason to keep it: given the scarcity/value of front page screen real estate, the threshold should be most not some. For browsing Wikipedia, only one link is necessary, and it should be to WP:Contents. (Most readers are coming for the search bar anyway, aren't they?) I don't think these links are used enough to justify the prime real estate (top of the front page) they occupy. Levivich06:33, 29 October 2021 (UTC)
Oppose The link someone posted above clearly shows [10] over a million people clicked on one of the portal links in the past 30 days. Some people do use them. Other things on the main page get fewer hits than these do. DreamFocus13:22, 29 October 2021 (UTC)
Thats not what that link shows. That link shows page views, not how many people clicked on the links on the main page. Over 300k or 30% of that million is to WP:Contents/Portals. And even still, a million over a month is tiny for a permanent link on the main page, which gets 171 million page views in a month. So we're talking just over one half of one percent. Other content on the main page might get fewer page views but other content isn't on the main page every day for a month, and it isn't at the top of the screen taking up prime real estate. Levivich14:05, 29 October 2021 (UTC)
Support removal Portals are an outdated mode of presenting knowledge. We need to have a serious, informed (by research) conversation about how to best do so. This is not that discussion. But: Our current implementation is similar to of Yahoo's early approach (basically a taxonomy) , which worked for a while, but no longer does. Arguments in favor of keeping the links because "people click on them" don't take into account that people will click on anything in the top right corner of a website. Clicks in not an argument. I'm hypothesizing that the main page gets so many visits because it has the shortest URL, and most people who go there a really just looking for the search function. It is far easier to type en.wikipedia.org than https://en.wikipedia.org/w/index.php?search=&title=Special:Search. Imagine the following: If instead of what we have now, Special:Search was the default and that page had it a link to Portal:Main, would that portal page still get 5 million views a day? — Preceding unsigned comment added by Vexations (talk • contribs) 15:30, 29 October 2021 (UTC)
Navigating content by category is outdated? Search definitely presents a great option for finding a specific topic but browsing is still very much a valid and widely-used alternative. Amazon, Britannica.com, Netflix, the New York Times, and most other content sites organize content by category so users can drill down to find content of interest. Search may be the ideal solution for many use cases but content hierarchies are not obsolete. - Wikmoz (talk) 06:26, 4 November 2021 (UTC)
Oppose As explained by Hut 8.5, the statistical argument is flawed. The argument about the space taken on the mobile interface sounded plausible but then I tried it. The portals appear after the strap line about "the free encyclopedia that anyone can edit" and read as a brief and simple high-level start for browsing the encyclopedia: The arts, Biography, Geography, etc. But what then takes all the space on the mobile view is the FA and its blurb which is comparatively huge and, today, is 1920–21 Cardiff City F.C. season. That comes across as a very random article of limited interest to 99% of our general readership. The daily readership for that article last year was just 3. Not 3 million, not 3 thousand, just 3! That's what's getting undue weight in the current format Andrew🐉(talk) 20:10, 29 October 2021 (UTC)
If look at what kind of pages people are finding through search engines, it appears that our most popular feature would be about recently deceased people. That wouldn't be my preference, but it would be relevant to our readers. Vexations (talk) 20:52, 29 October 2021 (UTC)
I agree with the rationale, but I don't really understand the !vote: if we want to base our decision on what our general readership is interested in (agreed [save for the fact that I love obscure TFAs]), how does it make sense to place the emphasis on portals? JBchrchtalk21:20, 29 October 2021 (UTC)
The Portal links make sense because they give a brief, broad-brush sweep of the encyclopedia's scope and this is appropriate as an introduction. Note further that JBchrch seems to be talking only about the desktop view when most of our readership uses the mobile view. In my mobile view, the first line is not "Welcome to Wikipedia...", it's "Welcome Andrew Davidson!" Any redesign needs to focus primarily on this mobile view, where space is precious. The desktop view is less important because, on a large monitor, there's lots of room for everything and it's good to use the space. Andrew🐉(talk) 07:10, 30 October 2021 (UTC)
Oppose This link is one of the only ways readers can get in touch with the Portal namespace. People argue... "We should delete them because readers don't look at them", but in reality, that's because access to the portal namespace from articles is low. There's only one tiny thing, a link at the bottom, that links main and portal namespace. However, most readers just read the lead and don't see the portal link. However the Main Page link is much more important because millions of people see the main page every day. The link provides easy access to portals. 🐔ChicdatBawk to me!10:22, 30 October 2021 (UTC)
Much above, seems rather contradictory: the main page is a portal page, and the links are (sub) main pages -- sure more people read the 'front' page, and the front page gets more attention, but there are lists of subsections too, tables of content, if you will. Alanscottwalker (talk) 17:53, 30 October 2021 (UTC)
Oppose removal unless some other use of the space is made. Removing links that thousands of people use to replace them with acres of white space seems counter productive. Espresso Addict (talk) 00:35, 31 October 2021 (UTC)
We could even add white space and keep the portal links! We're not a physical newspaper limited by the size of tabloid paper. I'll curse whoever adds the white space and write a Tampermonkey script to remove it, so I can see the content without constantly scrolling or shrinking the text to the size of a gnat's genitals, but technically it's easy. Certes (talk) 15:56, 31 October 2021 (UTC)
Oppose - We gotta fill that space up with something. Until we can think of another item, may as well keep linking to Portals. Note: This comes from a fellow, who supports the elimination of Portals. GoodDay (talk) 17:04, 31 October 2021 (UTC)
Um… no… we don’t need to “fill that space”. After all, should we decide to delete the links completely, we would also delete the “space” they appear in (and thus there would be nothing that needed filling). Alternatively, if we decide to keep the links, but move them elsewhere on the page, we would move the “space” as well. Or did you mean something else? Blueboar (talk) 20:06, 31 October 2021 (UTC)
@Blueboar: Perhaps they meant that it would be imprudent to leave such a forward-facing part of our main page top matter unfilled (a notion with which I would concur should that be the case). — Godsy (TALKCONT)08:04, 1 November 2021 (UTC)
Strong support – The Mainpage is inaccessibly overloaded with information, essentially akin to banner blindness. Of the eight portals listed, only two (Math and Science) have a "maintainer" listed (which I'm sure is a concept most people in this thread aren't even aware of), meaning that the 6 other portals are being continuously linked directly from our most viewed page without any regular oversight. This is the kind of change that will begin to improve the Mainpage. Those that think someone will create a radically new Mainpage design and have it approved are living in fantasy—that will never happen, there are too many people on Wikipedia obsessed with the status quo for the sake of itself (e.g. the "solution looking for an improvement" crowd). Actual reform to the Mainpage will almost certainly be small and gradual improvements such as this. Aza24 (talk) 23:34, 1 November 2021 (UTC)
Support removal. Whitespace is incredibly precious and helps make layouts readable and intuitive. Most of the good proposed redesigns of the Wikipedia Main page make it less busy, and doing that requires sacrificing what isn't important in favor of what is important. Filling every last square with text isn't ideal - blank spaces draw the eye to the relevant sections. And Portals just aren't relevant enough, for reasons discussed ad nauseum. A link to "All Portals" is fine and can stay somewhere, but remove the others. SnowFire (talk) 03:47, 4 November 2021 (UTC)
Remove but keep the "All portals" link with some meaningful name. All of us know what a portal is, but I doubt if the average reader does. Without the subject-specific portals there to give a clue, "All portals" becomes essentially meaningless. A better name would be "Browse by subject area". Zerotalk04:06, 4 November 2021 (UTC)
Strong oppose of entire removal. Removing access to portals from the main page will simply further orphan portals to a greater degree, and does nothing to provide diverse navigational means and content to Wikipedia's WP:READERS. I also echo the stances and concerns of BusterD, Wikmoz, Certes, Hut 8.5 and Amakuru here, among others that have provided meaningful oppose !votes.
An idea in lieu of the total removal of portal links is to move them to the end of Main page, perhaps encapsulated in the {{Portal bar}} template (see example below):
A very important issue is that the portal bar template does not appear in the mobile view of Wikipedia, so mobile users would not see the links. For example, for desktop users here, compare the portal bar at the bottom of the Sustainable development article and then notice how in mobile view the portal bar and links are nonexistent (link). So, if the portal bar were to be used on Main page, a new template or layout would need to be designed that appears for mobile users.
Many of the arguments here for the entire removal of portal links are based upon making the Main page look neater, cleaner or less cluttered, but this does nothing to provide diverse content to readers. Fact is, this would also dumb-down the Main page, providing less options for readers to learn about using portals as a means to navigate topics. If the portal links were to be removed entirely, portals will be used less, because people just won't see the option as often. Then at Miscellany for deletion, users that virtually exclusively opine for deletion of entire portals per low page views will have a very easy and convenient way to further their stances for deletion, which at times seems to actually be based upon a disdain of portals in general, using page views as a sort of "excuse" to "get rid" of them. The removal of portal links from the Main page would move Wikipedia in a backwards direction, not forward. North America100019:06, 4 November 2021 (UTC)
Support - not once in my six years of editing and several more browsing have I ever used those links. We could consider center aligning the "Welcome to Wikipedia" block. Anarchyte (talk) 06:25, 5 November 2021 (UTC)
Support relocation. Had to go visit the front page to even figure out what this discussion was about. Per the various arguments already made regarding usage, let's keep them somewhere on the front page for now. While we're at it, full support of re-labeling per @Zero0000. "Browse by subject area" would be much more meaningful to the average casual visitor. Retswerb (talk) 06:24, 6 November 2021 (UTC)
Support full removal, "per" the above. I find Levivich's argument quite convincing. Portals are like the bookmarks of editors; readers don't use them. I would suspect that the search function is used far more often. 🐶 EpicPupper(he/him | talk)02:51, 9 November 2021 (UTC)
Support as part of a portal space reboot. When clicking on one of these links, the reader experiences a “break” in the general layout of the WP and an absurd drop in quality content compared to the main page. I believe, a namespace that has failed to solve structural problems for over a decade (as demonstrated in my comment links above) does not deserve such privileged space on the Mainpage.Guilherme Burn (talk) 12:08, 10 November 2021 (UTC)
Meh it's hard to say that the current links are good, but they do seem better than blank space. I suppose the line-wrap in "Welcome to Wikipedia, the free encyclopedia that anyone can edit." could be removed, but I don't like that change aesthetically. We also could just link to the article Mathematics instead of Portal:Mathematics. User:力 (powera, π, ν) 20:04, 10 November 2021 (UTC)
Support removal (and, if that fails, support moving them elsewhere) - portals are a relic of a long gone era, and if nothing else they shouldn't clutter the MP with more links. A little whitespace (or, in this case, greyspace) can go a long way for making pages cleaner and clearer. Remagoxer(talk)21:51, 19 November 2021 (UTC)
Comment – In November 2021 Portal:History received a grand total of 133,559 page views, averaging 4,452 page views per day. How does this correlate with the statement that portals are not "widely used". The reality is that there is no correlation to the assertion. Quite the contrary exists, actually, whereby portals linked on Main page are actually used frequently daily, by thousands of WP:READERS per day. Do those links really "clutter" the Main page? If so, perhaps they could be moved and integrated into a graphical format, as I have suggested above. North America100012:20, 1 December 2021 (UTC)
This has already been gone over in detail in this thread. 4500 daily page views proves "not widely used" because 4500 is not a lot. The main page gets millions of daily page views. 99% of main page visitors do NOT click on the portal links. When 1% of our readers click on a link, that is not "widely used". Levivich13:17, 1 December 2021 (UTC)
That's true of almost all links from the main page. The portal links are amongst the most-clicked. The only reason to pick on them for removal, rather than some of the less-clicked non-portal links, is a dislike of portals, which is a separate debate. Certes (talk) 15:09, 1 December 2021 (UTC)
No, as we went over in this thread, what you're saying just isn't true. It is not true that the portal links are amongst the most-clicked. Your earlier argument about this compared the portal links ANNUAL page views, with things like TFA which are only on the main page for a day. But 4,500 is actually a very low amount of single-day page views for anything on the main page. TFAs and ITNs get tens of thousands of daily page views. For example, recent TFAs Jaguar got 55k, British logistics in the Falklands War got 65k. Orders of magnitude more. Please stop repeating the untruth that portal links are among the most-clicked, it's just not true. "The people who disagree with me just don't like it" is the most-tired, weakest argument that too many editors cling to when consensus doesn't agree with them. The truth isn't that people just don't like portals, it's that intelligent people are looking at the data and coming to a rational conclusion. There are no links on the main page that are less-clicked and as prominent (appearing at the top, every single day) as the portal links. Levivich15:59, 1 December 2021 (UTC)
Support removal of the links, which I doubt many people actually use. Blank space is not necessarily the enemy - there is no problem with having nothing in that space. firefly ( t · c ) 16:01, 1 December 2021 (UTC)
Oppose based on the evidence that they are well used by readers and the lack of any good reason to remove them. If they really do "clutter" the main page (for which there is no evidence) then move them elsewhere. Thryduulf (talk) 17:52, 1 December 2021 (UTC)
Support removal. Not really used, for a very, very good reason: portals are not so useful to navigate inside a topic. When you have tried some of them, "not worth the click" becomes your opinion. Pldx1 (talk) 18:07, 1 December 2021 (UTC)
Yeah but in this particular discussion there is no specific policy that we need apply, so IDONTLIKEIT is not an invalid argument. JBchrchtalk23:50, 6 December 2021 (UTC)
I'm not saying it's invalid, I'm saying it's fully balanced by the IDOLIKEIT arguments from other people and so carries no weight at all - it's just unhelpful noise compared to the arguments presenting evidence of widespread use (bizarrely including by some of those claiming the links aren't used). Thryduulf (talk) 01:08, 7 December 2021 (UTC)
Oppose. The link to the portals is a great way to showcase the breadth of what we have to offer. We will not be any richer nor will we be doing our readers any service by removing the links. Ktin (talk) 20:40, 1 December 2021 (UTC)
An issue that has been raised by some comments and !votes above probably deserves some meta-discussion: if this proposal gains consensus, when and how do we decide if we move the links somewhere else, remove them completely from the main page, or add some other type of link somewhere else on the main page? My impression—but I'm happy to defer—is that we are not likely to solve all of these question in this single survey. Accordingly, if this proposal gains consensus, we would have to launch a second proposal/RFC with several options to choose from. The main page should probably not be changed until this second survey closes. Tagging editors who have expressed some view related to this question: Sdkb, BusterD, Blueboar, Certes, Moxy, Cavalryman, Godsy, SmokeyJoe, Hut 8.5, xaosflux, Bilorv, Izno, Dege31. JBchrchtalk15:58, 28 October 2021 (UTC)
I suspect that "do nothing", "move elsewhere" and "get rid" each have substantial but minority support. We need to be wary of pitting one option against an alliance of the others as a binary choice. "Do nothing" vs "do something" risks throwing out the most popular of the three options for receiving fewer !votes than the other two combined, as would "get rid" vs "keep somewhere". A politician would have a great opportunity to gerrymander their preferred result here, but for a fair and collegiate consensus we need to tread carefully. Certes (talk) 16:15, 28 October 2021 (UTC)
I agree with this, if there's three options then the RfC should be about those three options, and trying to consolidate two of them can distort the outcome. For example if option A has 40% support and options B and C have 30% support each, then an RfC about option A only would eliminate it even though it's the most popular. Hut 8.517:40, 28 October 2021 (UTC)
I'm not sure if I completely follow the practical implications of the comments above, especially the reference to a "do nothing" option? For all intents and purposes, the do nothing/do something discussion is taking place right now, in the (now CENT-listed) discussion above. If "support" comes out as the result, I don't think that it would be very useful to relitigate the question by adding a "leaving at the top" option in a subsequent discussion/RfC about portal links on the main page. JBchrchtalk02:42, 29 October 2021 (UTC)
The practical implication is that, if leaving the links as they are is the most popular option but lacks a 51% majority, then a vague proposal to move, remove or otherwise change the links in an unspecified way would pass, neatly removing the most popular option and leaving the field clear for a less popular option to be chosen and implemented. Certes (talk) 11:28, 29 October 2021 (UTC)
Do we have a way to know the frequency with which all of the links on the main page are visited? Without comparative data, we can't tell what links are most popular. isaacl (talk) 14:58, 29 October 2021 (UTC)
@Pppery: Thanks for that. Just curious as you'd be the person to know: is there a faster way to pull the main-page links out of that 1.5GB Sep 2021 TSV, other than my writing a py script to do it? Like is there some tool that already exists (Excel and gsheets obv won't handle it)? Thx again. Levivich16:32, 29 October 2021 (UTC)
The last set of numbers counts clicks to the main page from various sources. The other-internal line probably includes a few readers navigating from portals to the main page. Sadly, clickstream doesn't seem to count clicks to portals (or any other pages outside mainspace), whether from mainspace pages such as the main page or from other sources. Certes (talk) 20:20, 29 October 2021 (UTC)
I've seen temporary redirects used from time to time to capture clickthrough data. Could capture the data for a week and multiply by 52 to get a full year estimate. = Wikmoz (talk) 21:15, 29 October 2021 (UTC)
I don't see any recent implementation of redirects for the portal links. Could be set up in 15 minutes or less (e.g. Portal:History mpclick with #Redirect [[Portal:History]]). We'd have the data in a week. - Wikmoz (talk) 04:43, 30 October 2021 (UTC)
If an argument is going to be made based on popularity, we need data on all links from the main page to judge the various sections against each other. I suspect the vast majority of main page views result in no links being followed, so having comparative stats is essential. isaacl (talk) 04:51, 30 October 2021 (UTC)
We could set up redirects for all the static links on the main page (so excluding things that change regularly like dyk) and see which are used and which aren't. Levivich05:09, 30 October 2021 (UTC)
I think we'd want to know on average how often links are selected in the "Did you know...", "In the news", "On this day", and other sections. I don't think a decision should be made solely on follow-through frequency, as the various links serve very different purposes and aren't directly comparable. The portal links are the only ones that offer navigation through content. The links in the colourful boxes expose articles to attract curiosity, links in the "Other areas" section aren't related to content, and links under "Wikipedia's sister projects" aren't related to this site. Plus we can choose to include a link with low follow through if we think it is sufficiently important. Nonetheless, having an idea of how often the different sections are used will help set background context to better frame discussion. isaacl (talk) 05:57, 30 October 2021 (UTC)
For most dynamic links (DYK, TFA, OTD... pretty much everything except ITN), we can see the spike that linking on the main page causes just from looking at the page views. For ITN I don't think it matters much either way, as that's a special case (we're not going to decide static links like portal links by looking at ITN clickthroughs). Portal links aren't the only links that offer navigation through content; there's also the "Contents" link. That's one of the static links we should track through redirects. It would be a PIA to redirect all the dynamic content--we'd need the cooperation of everyone who puts together the ITN, OTD, DYK, TFA, TFP, TFL, and I'm probably forgetting some. Hence why I think we should just put redirects on the static links and not the dynamic ones. As Wikmoz points out, we could do that right now and have data in a matter of days. Levivich17:24, 30 October 2021 (UTC)
Pageviews for the portals linked from the main page range from 2300 to 4800 per portal per day. [11] Similar figures for the other top-level portals listed in Wikipedia:Contents/Portals range from 120 to 320. [12] It seems reasonable to conclude that this change would prevent approximately 90% of visits to the listed portals, i.e. about 25,000 visits per day. Certes (talk) 18:22, 30 October 2021 (UTC)
Thank you; that's wonderful news which I'll repeat elsewhere. A lot of us have been waiting for that tool, but none of us had managed to discover WikiNav. (I've been using a crude hack on my PC but it requires a 1 GB download.) Certes (talk) 14:02, 18 November 2021 (UTC)
@Whatamidoing (WMF): Is there any way we can show more than the top ten sources and destinations? I see we can extend it to top 20 in one of the graphics, but it would transform the tool's usefulness if the final tables could list all incoming and outgoing pageviews with 10+ views, as given in the Clickstream data, not just the top ten. (The Chocolate example cuts off at 289 views.) Certes (talk) 00:28, 20 November 2021 (UTC)
We'd have to ask User:MGerlach (WMF) or User:Isaac (WMF) about the possibility of getting more results. Also, for the purpose of this discussion, it'd be really nice to have the Portal: namespace included.
The underlying clickstream dataset only includes the main namespace, so it might be challenging. I think including more namespaces would be a great thing, and very useful not only for this but for figuring out how users navigate Help and Policy pages. Thanks for pointing out WikiNav though, which is a much easier way to explore the data that we do have! the wub"?!"20:53, 22 November 2021 (UTC)
We don't know if those page views are coming in from the main page links or not though. That's what the proposed redirects would tell us. Levivich18:40, 30 October 2021 (UTC)
Correct. However, of the top-level portals listed in Wikipedia:Contents/Portals, every single one that's linked from the main page has over 2200 visits, while every single one that's not linked from the main page has under 330 visits. We don't need a statistical analysis to see that can't be coincidence. These links are clearly the oxygen supply of the portal system, through which 90% of visits occur. Certes (talk) 23:53, 30 October 2021 (UTC)
Which makes me wonder: why are we putting these links at the top of the screens of millions of daily readers if only a couple thousand readers are clicking on them? Levivich00:08, 31 October 2021 (UTC)
Because in total that's about ten million clicks a year. Collectively, the portals get more clicks than TFA, and they get them consistently every day rather than having 24 hours of glory. I can't imagine any other website deliberately making a change to turn away that level of traffic. Certes (talk) 00:19, 31 October 2021 (UTC)
How does that make any sense? Portals get trafic because they are on top of the main page, not the other way around. JBchrchtalk05:36, 31 October 2021 (UTC)
Right but you're confusing causation and correlation. For example, portals get more pageviews annually than a TFA because they're linked on the top of the front page. If you look at all TFAs annually, the readership dwarfs portals. For example, just the TFA you linked to, got over 20,000 page views on the day it was linked. 10x what the portals get. Think about it this way: should we keep links at the top of the page when we know that 99.9% of readers never click on them? I think a lot of websites would say "no". We also don't know that every main page link is the cause of page view spikes. The main page portals may be getting more page views than other portals not because they're on the main page, but because they have more inbound links than other portals (because they're top-level portals). We don't know how many of the portal page views are coming from the main page as opposed to elsewhere. For ITN stories, we know that not all the page views are from the main page: when a story is listed on ITN, it's also in the news, so a lot of readers are getting there via web searches. This is why ITN candidates that don't get support to post sometimes get more page views than the stories that are actually posted on ITN. It's a false assumption that the portal pageviews=main page clickthroughs, and it's faulty logic to suggest that the portals should be linked on the main page because they're getting 2k page views a day. Levivich15:35, 31 October 2021 (UTC)
The eight linked portals got 30,895 views on that date, very comparable with TFA's 20,000. Portal:History alone got 5,376. Bear in mind that regular visitors to the main page will have seen the portal links before but TFA is new for them, which will inflate TFA's clicks and suppress those for portals. A better comparison might be with other static links on the page. Certes (talk) 15:48, 31 October 2021 (UTC)
Not sure why you're combining the eight links together as if they were one link and then comparing those eight against one TFA link. That's just manipulating the statistics through addition to get to a number that makes it look like the portals are as popular as the TFA. A better comparison might be with other static links on the page. No kidding, if only someone had suggested that :-P Levivich16:03, 31 October 2021 (UTC)
Well, we should be able to get the info we want out of the web site logs, and not need to use wrapper redirects as a hack, but that's another story... Like I said, until we have stats to compare with, we don't have a standard for comparison. But additionally: followed-link count is one measure of success, but a low count doesn't necessarily invalidate the goal of the design, as it can result from a failure in the implementation. Plus the vast majority of readers reach Wikipedia directly from search engine results, so if just looking at pure numbers as a justification, the main page should just be a choice of search engine forms.
I think we should be looking at the end goal, and figure out the best way to achieve it. If we want to provide more prominent content navigation than a sidebar link in a small font size, is using the existing portals the best way? Should we use links to the Contents subpages? Or something else? isaacl (talk) 03:56, 31 October 2021 (UTC)
Given the lack of information on what parts of the main page are popular, I don't feel an argument can be made on removing any of them based on page views. (Portal page views might be low compared with main page views, but they could still be the most often selected links on the main page.) Other arguments for or against any sections can of course still be put forth. isaacl (talk) 04:51, 30 October 2021 (UTC)
At the risk of WP:OTHERSTUFF, perhaps we should look at other language Wikipedias. Eight of the top ten main pages link to the major portals in a similar way to enwp, and usually more prominently (icons, bold, etc.), though sometimes further down the page. The other two link to at least the main portal. A quick sample suggests that English portals are similar quality to those in other languages. It's not clear why they are being singled out for orphaning. Certes (talk) 19:42, 4 November 2021 (UTC)
After reading this discussion yesterday I got in the shower this morning and my eyes fell on my trusty bottle of Dr Bronner's. For all those wondering why more white space might be desirable - this is why. Retswerb (talk) 21:55, 6 November 2021 (UTC)
Yes, there are arguments for adding more white space to the main page. However, a consensus to add white space need not necessarily imply unlinking portals. We could remove some other feature instead, or simply make the page bigger. Certes (talk) 00:23, 7 November 2021 (UTC)
Correct, of course: whitespace does not have to come from removal of portal links. But there appears to be an argument being made by you and others that whitespace is always less valuable than content (Then I suppose it boils down to which better serves our readers: wikilinks, or white space / creates more useless whitespace / Oppose removal unless some other use of the space is made). While it is certainly true that whitespace without content is meaningless, I would argue that content without whitespace loses significance altogether. Whitespace is how we point out content that we care about - rather than the page becoming a meaningless wall of text, like Bronner's memorable but ultimately uninfluential label. Retswerb (talk) 08:02, 13 November 2021 (UTC)
Comment – First of all, this is not meant as any sort of personal criticism, so sorry if anyone takes offense, because that's not the point at all. However, some of the arguments supporting link removal make no sense. For example, above a user states that they have never used portals, but if one user does not use portals, why should thousands of users that do use portals have lesser access to links to them? It's like saying, "I don't read DYK articles, so links to them on Main page should be removed". This is purely personal-preference based and subjective, and doesn't take into account that many readers do use portals. Another user states that "readers don't use them", but this is not based in fact whatsoever, and is obviously subjective opinion lacking any basis in actual facts. For example:
Obviously, readers do use portals, and these figures are from only three of the eight listed on main page. Another user states that "portals are generally outdated and poor content", but those linked on Main page are quite the opposite. For example, Portal:Biography only displays Featured articles in its Featured biography section. Per the Featured articles page, it states, "Featured articles are considered to be some of the best articles Wikipedia has to offer". Portal:Geography provides another example, only displaying FA-class articles in its Featured articles and Biography sections. This is certainly not poor content, not in the least; rather, it is the best content. North America100023:07, 9 November 2021 (UTC)
Another user states that "readers don't use them", but this is not based in fact whatsoever, and is obviously subjective opinion lacking any basis in actual facts. It's based on math. The main page got 170 million page views in October. The portals, combined, got less than 1 million. If we assume all the portal page views come from the main page (obviously not actually true), that's still less than 1%. So, 99% of main page visitors do not click on the portal links.
To put it another way, we know from the page views statistics that when someone loads the main page, 99 times out of 100 they don't click on any portal link. Those links are very rarely used. Levivich23:41, 9 November 2021 (UTC)
We can be confident that 90% of traffic to these portals comes via the main page, because linked portals get ten times more views than unlinked ones. This report counts total views for pages linked from the main page. The portals rank between 18 and 32 out of 112. Every single portal is in the top 30% most popular targets. If we needed to remove links (which we don't) then there are many less popular pages which should be unlinked before considering the portals. Certes (talk) 23:51, 9 November 2021 (UTC)
Given it is incredibly unclear that most of the links are actually to portals, I am not sure page views are an accurate estimation of the utility people find from these links. People may be wanting to visit The arts and instead find themselves clicking on Portal:The arts|The arts. Further, we know from DYK data that being listed on the main page results in a massive spike in page views, are people visiting because of the prominence of these links or because they find them to be a really helpful navigational aid? Cavalryman (talk) 00:04, 10 November 2021 (UTC).
This is true. To really understand the utility of the Portal links we'd have to look at where users go next after clicking a Portal from the main page. Even then, utility is difficult to judge. Retswerb (talk) 07:42, 13 November 2021 (UTC)
Meh. I partially agree with Calidum- I think that if we are going to redesign the main page, we should do it as part of a broader discussion of Wikipedia's appearance. However, I do think that Sdkb's proposal to identify portals as a "unique way to view wikipedia" is worthwhile-portals can be useful and a clearer identification of their purpose would increase their usefulness; it could perhaps even revitalise them from their current *older* appearance. NANPLover47talk05:06, 29 November 2021 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Opting out of mass messages should not generate new messages of another kind
I just got a ping in my alerts that reads "Delivery of Bots Newsletter, December 2021 to User talk:Guy Macon was skipped because the target has opted-out of message delivery".
I propose that, as a general rule, when someone indicates that they don't want certain types of messages, this should never cause them to receive another kind of message such as a ping.
The obvious way to do this for mass messages is to have the log entries use Template:No ping, but I would like there to be a general rule for all similar situations so that opting out stops all messages and never generates any sort of "here is a message telling you that we are not sending you any messages" message.
Of course some talk page notices are required, but such notices already ignore the opting-out of message delivery entirely and thus would not be affected in any way.
@Guy Macon: the linking of users in the MMS failed delivery log is not being controlled by the sender, as such this is not something we can fix here on the English Wikipedia. I have filed phab:T297538 for this though, as it certainly sounds like something that would never be desired. — xaosfluxTalk03:28, 11 December 2021 (UTC)
I am hoping for a notification telling me that I didn't get the notification that I didn't get a notification because I opted out of notifications. :) --Guy Macon (talk) 18:08, 11 December 2021 (UTC)
(page unhelpfully refreshed by browser, causing me to have to retype the comment x5) @Guy Macon: hmm, I just tried to replicate this (by having a MMS deliver to my opted-out test alt) and got no ping. Leads me to believe that this is probably some bug and it wasn’t intended to happen. @Theinstantmatrix: did you get a ping like Guy did when the bots newsletter was handed out? —GMX🎄(ping!)08:44, 11 December 2021 (UTC)
sorry, I meant “did you get a ping, like Guy did, telling you that the bots newsletter was not delivered to you because you opted out”? —GMX🎄(ping!)08:47, 11 December 2021 (UTC)
Note that in my Preferences --> Notifications I have every "Notify me about these events" box set to "Web" (except "Login from an unfamiliar device", which can only be set to email). I assume that anyone who doesn't have the "mention" (Notify me when someone links to my user page) box checked will not get a ping from the mention in the mass message log. --Guy Macon (talk) 18:08, 11 December 2021 (UTC)
Wikipedia Fundraiser Suggestion - Useless Information Day
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.
Hello,
As a suggestion to raise awareness of the benefits of Wikipedia and to encourage donations, I think it would be beneficial to implement "Useless Information Day". One day a year, users are allowed to make changes to any Wikipedia page without moderation. (Obviously, obscene or violent or otherwise harmful changes would not be allowed.) Basically, users would be allowed to vandalize any page for the entire day for the purpose of creating jokes, etc. which are normally corrected fairly quickly. Especially interesting edits would gain news or viral interest. The unreliability of information on Wikipedia on this day would highlight the need for the service and hopefully encourage donations.— Preceding unsigned comment added by Jeepnut1 (talk • contribs) 12:13, 8 December 2021 (UTC)
That could lead to readers being seriously misled. There is also the problem of reverting the joke edits whilst retaining useful changes after the event. There is limited tolerance for jesting outside article space on April 1 each year, but even that is controversial. For those of us who fight vandalism, every day is Useless Information Day. Certes (talk) 12:47, 8 December 2021 (UTC)
I thought about that. I don't have enough Wikipedia knowledge to know what's possible and what isn't, so I can't speak to the difficulty of reverting. I assumed, possibly incorrectly, that everything could just be reset to what it was before the day started and that during the event, large banners could be placed at the top of the page to alert users to the fact that today, the information of Wikipedia should not be trusted and to donate to secure the future of the service.— Preceding unsigned comment added by Jeepnut1 (talk • contribs) 12:54, 8 December 2021 (UTC)}
Donations are paid to the WMF rather than to Wikipedia. The volunteers who detect and remove incorrect information are all unpaid. Certes (talk) 12:59, 8 December 2021 (UTC)
As stated above, this doesn't seem like all that good of an idea as it'll make users think that it's ok to vandalize Wikipedia which, if it were implemented, wouldn't be true. In fact, it basically goes against WP:DENY. If we were to dedicate an entire day on Wikipedia to allow users to vandalize we would be feeding any new trolls that come to Wikipedia on that day. ― Blaze The WolfTalkBlaze Wolf#654517:46, 8 December 2021 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
They are asking money for policy writing!
Sorry if it is not right place for this kind of post. This is not related to enwiki but i thought i should share. While browsing on meta, this rapid grant proposal caught my attention. They are asking money for policy writing on their wiki! It suppose to be created by community discussions and consensus by volunteers and not as paid job. If wmf fund this proposal, i guess, wmf should start paying all wiki (including enwiki) editors for on-wiki works like policy making you guys do here. --আফতাবুজ্জামান (talk) 15:12, 7 December 2021 (UTC)
Hello everyone, I am advising on this project in my volunteer capacity. My username has been changed to my volunteer account on the proposal itself.Also, this project is not about writing the policy by one person but rather helping coordinate with the community and experts to co-create various policies. Workshops with other community members to educate them about the policies and organizing further events is a major component of this project. Satdeep Gill (talk • contribs10:50, 14 December 2021 (UTC)
The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion.A summary of the conclusions reached follows.
After 22 days, I think it's time to close this one. First, I want to say a big thank you to everyone who participated—I learned a lot about accessibility and formatting throughout the process and particularly by reading all of your comments. I think it's fair to say that the general consensus was the proposal's clunkiness and bureaucracy outweighed possible accessibility upsides, given the prevalence and improvement of screen reader technology. Accessibility, to all who might not consider reading the best form of digesting information (including, but also supersedind, blind people), is a super important topic for the encyclopedia to address and I can't wait to see where we go to address it. Here's to the sparks of new ideas and to the saucer that cools the coffee—Cheers, everyone! theleekycauldron (talk • contribs) (they/she?) 06:56, 8 December 2021 (UTC)
Problem: The Main Page of English Wikipedia is regularly seen by 5.5 million people, of whom a significant number are visually impaired. While WikiProject Spoken Wikipedia exists to narrate existing articles, and has narrated hundreds of Featured Articles, users are currently not allowed to add recordings to sections of the Main Page. This lack of audio narration poses a barrier to not just the visually impaired who wish to view the works we want to spotlight, but also those with reading or learning disabilities, those too young to read large chunks of text comfortably and seamlessly, and those who simply are more predisposed to retain information auditorily rather than textually. Not every section of the Main Page is easily narrated—Did you know, On this day, and In the news, for example, are too unpredictable to have immutable recordings attached to them. Today's featured article (TFA), however, consists of a single thousand-character blurb generally updated only once a day, ideal for a spoken recording.
Proposal: In every nomination template for TFA, there should be an optional "narration" parameter that allows the nominator, or any other interested editor, to add a spoken recording of the blurb that is to appear on the Main Page. A sample narration on a past iteration of the Main Page can be found here to roughly illustrate how this may look and feel, although this will be changed as more experienced template editors than myself fiddle with the idea. No nomination will be required to contain a narration, but any recording that is attached to the nomination must be reviewed by an admin according to the guidelines laid out by WikiProject Spoken Wikipedia for technical quality, clarity, and accuracy before the recording can accompany the nomination to the Main Page. This proposal has the potential to help thousands in accessing the articles that Wikipedia is most proud of. Thanks for your time, and I hope I can count on your support! theleekycauldron (talk • contribs) (they/them) 06:54, 15 November 2021 (UTC)
Discussion (TFA blurbs)
I'm interested to hear from editors familiar with visual impairment whether spoken versions of articles actually help aid accessibility. I have a sense that text-to-speech software has improved dramatically in the past decade or so, which has limited the usefulness of spoken versions. If there's not a major advantage of having human narration, the costs in effort, inconsistency, and difficulty in updating may be reasons to reject this. {{u|Sdkb}}talk09:13, 15 November 2021 (UTC)
I'm not persuaded that there is a pressing need, particularly given the advances in text-to-speech technology since WikiProject Spoken Wikipedia launched. {{u|Sdkb}}talk02:13, 16 November 2021 (UTC)
In-principle, this is a very nice and innovative idea, which is definitely useful for visually impaired—in my opinion, a human narration is better than an automated one. But presently, the biggest issue I see with this is its inconsistency. "No nomination will be required to contain a narration ..." may not be a good idea, especially for the main page. To me, it will look odd if we have narrated version attached with the blurb for three days, but not for the fourth. Article featuring at TFA are scheduled well in advance. As of today (November 15), we have articles scheduled for all the dates till December 31! I was wondering if we can have a group of interested editors volunteering to create recordings in advance as to avoid this inconsistency. Thoughts? – Kavyansh.Singh (talk) 09:32, 15 November 2021 (UTC)
As a blind user, I wouldn't benefit from this at all personallly, but I'm one of the most un-audio-oriented blind people I know of. I don't know any other blind people this would benefit; people who are proficient at using screen readers tend to prefer using them, but not all blind people are (especially those who have recently lost their sight). As noted in the executive summary and at the idea lab discussion (which I noticed but chose to lurk in), this might also benefit people with other disabilities. Since the TFA blurbs are relatively short and the spoken version isn't a *requirement*, I'm basically meh on the whole idea. Also, many people who visit Wikipedia's Main Page don't read much or any of it and just use it as a search bar; we don't have exact figures but I highly doubt that 5.5 million people a day actually engage with the "Today's featured article" section, for example. Graham8710:12, 15 November 2021 (UTC)
I think it's worth a try, it does require both volunteers willing to record narrations and those to quality check the recordings - so being optional is necessary as either of those could fail to emerge. A probably-more-than-bikeshedding part to consider from VPI is how much screen real estate to allocate for this control. It could be anything from a small icon (topicon sized), a line of text, the full player control - or something else. — xaosfluxTalk11:00, 15 November 2021 (UTC)
I reiterate what I've stated elsewhere, in that this is a forward-thinking idea. Just consider all you access on the internet that comes with sound, some helpful and some not. But Wikipedia has no sound on its main page, possibly the first Wikipedia page that opens up for much of the global readership. In addition to the sight-impaired benefit, even if it's just a little two-sentence oral blurb, it enhances the reader experience. On a global media outlet where nothing is censored, there's an aspect to consider about whether or not we want it on every TFA. That could be decided on a one-on-one basis as the TFA process puts together it's individual blurbs. But I certainly believe it's a worthy feature we should enable. — Maile (talk) 11:31, 15 November 2021 (UTC)
I think this is a great idea. It calls attention to WikiProject Spoken Wikipedia with a minimum of effort: recording one blurb doesn't take long at all, and they can be prepared weeks in advance, so I don't think we need to worry about gaps. I'd also like to hear more about whether readers with visual impairments find these useful, but that shouldn't be the only consideration either. Lots of people just prefer listening or watching to reading and Wikipedia's overwhelmingly text-based front page is really starting to show its age in comparison to other websites. – Joe (talk) 12:18, 15 November 2021 (UTC)
There are some practical difficulties. We are scheduled until December 31, but that is because I scheduled December a bit early this month (I schedule the third month in each quarter) and often it's not until the 20th or so that the coordinator whose month it is competes work. "Nominations" (at TFA/R) account for perhaps five or six of the blurbs in a month, many of the remainder won't have prepared blurbs yet. Once a blurb is posted (whether by a coordinator or by one of the principal editors of the article), that is not a final version as there are several users who often go through some days in advance and offer suggestions or edit it directly. And, quite often, WP:ERRORS weighs in on the day or on the day before, and we wind up changing the blurb. Since the spoken word version needs to be finalized some time in advance of main page day to allow for review, one can expect variances between it and the written blurb.--Wehwalt (talk) 13:35, 15 November 2021 (UTC)
If there's a substantial difference, or an error of fact, the recording can be pulled (or even remade); but I think it's okay if there are more unimportant variances between the two. The recording still supplies the necessary information to the relevant people. I do agree that it's hard to make recordings so far in advance.theleekycauldron (talk • contribs) (they/them) 19:22, 15 November 2021 (UTC)
I wouldn't want to see variances, even minor ones. The main page is supposed to have the most refined content, and having a different blurb and spoken version is something that could cause mild confusion for readers or arguments among editors (over whether or not a variation is minor). {{u|Sdkb}}talk02:11, 16 November 2021 (UTC)
Oppose. Moving to a !vote since the discussion above has failed to articulate compelling reasons (accessibility-related or otherwise) that we would want to do this. The "meh, it doesn't seem useful but wouldn't do any harm either" position is tempting, but I can't buy that either. As we've been experiencing (sometimes painfully) with the book and portal namespaces over the past few years, even when editing/engaging in an area is optional, there are costs to having it around in maintenance, diverted attention, clutter, etc. Fundamentally, this is not worth it. {{u|Sdkb}}talk02:21, 16 November 2021 (UTC)
I don't think one can compare this to books or portals. Both of these need active maintenance, while the contents of this proposal seemingly do not. Dege31 (talk) 16:32, 16 November 2021 (UTC)
Lean oppose. This seems like busywork that we don't even know if there are people who'd volunteer for it. I think the option to add audio to the blurb is ok, but only if it's a cut from the existing spoken article, assuming the content matches. Otherwise, it's more work for very little gain. Dege31 (talk) 16:40, 16 November 2021 (UTC)
@User:Dege31Speculation. I believe there's only one way to find out, and that's to give it a try for a week or so, and then have people weigh in on the tangible results.Gallomimia (talk) 17:38, 28 November 2021 (UTC)
Oppose. Project Spoken Wikipedia, while done out of good faith, was largely a misguided way to direct volunteer time, and doing the same for blurbs would have the same problems. Most blind people who wish to listen to an article would actually rather hear the up-to-date version spoken by a controllable machine reader which can go at the desired pace, accent, and so on of the listener, not a snapshot made three years ago by an unknown speaker. I suppose the risk of "vandalism" would be less for the front page version, but this seems like misspent effort - very, very, very few people would be interested in this, yet it wouldn't really achieve much for accessibility. And unlike article recordings, these front page blurbs would be used one day and then never again. SnowFire (talk) 19:23, 18 November 2021 (UTC)
Oppose: I am not too familiar with this area and it seemed like a grand idea --- until --- issues were brought to light that derailed it. Unless there was some compelling solution to issues mentioned by Wehwalt then I can see some corrections not being updated in the audio resulting in "variances" as mentioned by Sdkb. I would imagine an editor making last-minute changes could (a stretch) simply remove the audio but consistency and convenience would seem to mandate it should be there all the time or not at all. -- Otr500 (talk) 03:31, 22 November 2021 (UTC)
Support (with caveats) - Wikipedia is one of the least accessible websites there is, making it more accessible is always a good thing. When I visit other websites, and they have a "Listen to this article" option, I always always use it rather than my screen reader. For me, a human voice is preferable over a machine translation. But, here's my caveat, if it's not going to be consistent on a day to day basis, what's the point? Readers shouldn't land on the main page one day, and see this new feature and think, oh wow, look at Wikipedia stepping up their game, and then come back the next day and not find it, thinking, I knew it was too good to be true. Be consistent or don't do it at all. This is good advice for the whole project, audio articles help retain readers.Isaidnoway(talk)13:57, 26 November 2021 (UTC)
Support - Volunteer I put forward that none of us will really know whether it is a great idea or a terrible idea until we get a few blurbs read aloud and hear them, gauge how much work is involved, and compare this to the benefits reaped. I thus volunteer to do several blurbs, as I have found this work very beneficial to myself personally. If it's no better than a screen reader, we can discontinue.Gallomimia (talk) 17:35, 28 November 2021 (UTC)
Oppose based on considered feedback of several above. First, if Graham87 doesn't see it as helpful, that is huge in my estimation. Second, the concerns raised by Wehwalt are very real and serious ... the blurb is changing even as it is on the mainpage, so this could be a very difficult wrinkle, and the TFA/mainpage/FA editors don't need another wrinkle to deal with on mainpage day. And I agree that doing all of this for a one-day event is misspent effort. Third, I agree that Spoken Wikipedia is well intended but quite misguided; I note how often even Featured articles have links to dated spoken versions on the article page. In the medical realm, this is really troubling, when we are linking to outdated info. So, I'm not really inclined to do something to advertise a project that isn't working as well as hoped. I could be persuaded otherwise if I thought this move would really benefit the visually impaired, but with Graham87 not on board, that pushes me definitively to oppose. SandyGeorgia (Talk) 17:47, 28 November 2021 (UTC)
Oppose. Better to rely on text-to-speech tech, in which big corporations are investing millions of dollars. Adds a lot of complexity to the TFA process which, while I'm not personally familiar with it, I don't think is a walk in the park. Also sharing Sdkb about diverting editors' attention away from more central missions of the project. JBchrchtalk22:23, 3 December 2021 (UTC)
Oppose as someone who makes Spokens. I would prefer only a few select ones that can be updated as time goes on for each user, of a high quality. Each blurb would most likely be rapidly made and quickly be outdated. I think Spoken Wikipedia may not serve an accessbility purpose anymore, as Graham has pointed out, but as just another format to absorb Wikipedia. If they are not of the quality and close to the date of the article it corresponds to, it really isn't useful to any listeners. And as a small tangent; SandyGeorgia, a lot of why the articles are old and outdated is that the project was dormant for a long time. I hope to get around to them at some point, but it is a serious problem. If they are that outdated, feel free to remove them I guess. Sennecaster (Chat) 19:19, 6 December 2021 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Good morning,
I a not a scientific but it is possible to have two articles. Cosmic Dawn matches several and many more results in Google in English. The french translation of Cosmic Dawn i.e Aube Cosmique matches more and more results. I will reading you. Thank's and best regards, Mike Coppolano (talk) 14:41, 12 December 2021 (UTC)
When using the Cite template forms, especially in the article text editor, submitting the URL should not only return title, author, but also a red, green, yellow, or blue, indicating its reliablity status, if known. .... 0mtwb9gd5wx (talk) 05:42, 13 December 2021 (UTC)
This probably should go in VPI for further fleshing out, as it doesn't propose a methodology, or how to handle cases where a source has heavily mixed reliability statuses, but would be an interesting add-on. Nosebagbear (talk) 09:15, 13 December 2021 (UTC)
Or WP:UPSD if you're interested in finding out about bad sources. Highlighting "good" sources in green is problematic, because no source is always reliable for all information. Headbomb {t · c · p · b}00:40, 14 December 2021 (UTC)
In addition, even the sources that are blacklisted are sometimes (albeit rarely) appropriate to use, for example in an WP:ABOUTSELF manner, and while you could hazard a guess that if the name of the source matches the name of the article that it's being used in that manner this isn't always the case, nor is that the only place ABOUTSELF may be used. Thryduulf (talk) 03:07, 14 December 2021 (UTC)
This is a very interesting idea, which is essentially asking for WP:RefToolbar to have some some (un)reliable source detection. The good part is that RefToolbar is a community-maintained gadget and so it can be implemented without any changes in mediawiki software (which are well known to take a lot of time to be implemented and approved). Any colour indicators would only indicate likely reliability or unreliability, so I don't see exceptions and edge cases as being problematic. – SD0001 (talk) 06:53, 14 December 2021 (UTC)
There is no source that is a priori reliable. There are sources with a history of prior reliability. This is entirely irrelevant when it comes to supporting a new wikitext claim. The fact that certain sources have been historically reliable in no way elevates reliability of a new, particular claim backed by the same source. Reliability trends do not predict the reliability of individual new claims any more than they predict the next outcome of a coin toss. And every citation must be reliable in its context. The aggregate or average or trend being "generally reliable" just won't cut it. Every wikitext claim must be reliably proven. A "reliability list" or "reliability algorithm" or "reliability bot" will not do. This is too important to be relegated. If you want to help the project, you, personally, have to do the work. There is an exception: when the exact same claim has been made in the past, and has been unambiguously proven correct using the exact same source. For that case only, the particular source is currently (per the available information) considered reliable. Until perhaps contrary information emerges. 74.64.150.19 (talk) 12:59, 14 December 2021 (UTC)
I think the OP has only suggested colour indicators to highlight general reliability status of the source. No one has suggested blocking inclusion of such sources by the software or bot. – SD0001 (talk) 14:20, 14 December 2021 (UTC)
There can be no such thing. As noted above, the reliability of the source is relative to the context of the citation and the corresponding claims made in wikitext. This is not a one-to-many relationship. Apart from the exception, also noted above, of a repeated claim supported by the same citation. 65.88.88.47 (talk) 15:21, 14 December 2021 (UTC)
Even if we all agree that the tool will "only indicate likely reliability or unreliability", it will be enforced by POV pushers and others as an absolute thing. Headbomb has spent put a lot of effort into the UPSD script, several of us have helped to make the documentation as clear as we can, and he still has to tell far too many experienced to stop blindly rejecting everything that the script highlights in its "50–50 chance" category. WhatamIdoing (talk) 21:54, 14 December 2021 (UTC)
Agreed. But I would tweak the terminology. There are sources proven reliable after the fact and sources likely unreliable before, with varying degree of unreliability. For any given citation, only unreliable sources have degrees or likelihoods. And for any given citation, reliable sources are just that. They are no more or less likely to be what they are. 71.105.141.131 (talk) 02:30, 15 December 2021 (UTC)
This basically isn't true. RSP says that the Associated Press is generally reliable, right? But if you cite any newspaper article from that highly reputable, officially-generally-reliable news source to support a sentence like "25% of cigarette smokers get lung cancer", then you'll be reverted because news media are not reliable sources for biomedical information. You can't say whether a source is reliable until you know what the Wikipedia content is. WhatamIdoing (talk) 19:04, 17 December 2021 (UTC)
The phrase "generally reliable" does not help one bit in elevating any citation. It means nothing, because the citation in question may not fall under such a "general" case, and there is no proper criteria to measure what constitutes "general" reliability. Past performance in no way guarantees the specific reliability of the next citation, unless one is gullible. You just have to work at it carefully, each time. Take a sentence like "25% of cigarette smokers get lung cancer" in wikitext. First, if it depends on a news source, it should be made clear. Say it is published in a general-interest high-circulation newspaper like the New York Times. Is this part of an opinion piece, an analysis, or is it straight reporting? Different types of news stories may employ different sources. A straight report may be based on an interview with a known, published expert in the field. A news analysis may be sourced from an official medical report. This is easy. You can easily ascertain whether the New York Times is reliable in this case, all you have to do is look at the primary source (assuming it is publicly accessible). You can do that in a million articles and prove the NYT reliable, and still, the next analysis/report may get the numbers or the quotes or the context wrong. If you state in wikitext "according to a New York Times analysis/report based on official medical records/interview with this expert etc. etc." this is a conditional statement, not a positive one. You give the wiki reader the option to accept it as relevant or accurate or neither, but it may be important in showing how general mass media may present the subject. Such a citation can be produced (and verified) easily. The gist of it is, "generally reliable" is a meaningless statement. Unlike say, "generally unreliable", which is a good starting point. 65.88.88.93 (talk) 20:25, 17 December 2021 (UTC)
In addition to WAID's points, we have sources listed at WP:RSP whose reliability varies by context, e.g. Fox News should only be used "with caution" for politics and science where it is regarded as a biased source, it is regarded as generally reliable for other news topics, and its talk shows "should not be used for statements of fact but can sometimes be used for attributed opinions." I don't know how any automated tool could correctly label a citation to FoxNews. The RSP entry for China Daily is going to be even trickier for a bot to parse let alone implement. Thryduulf (talk) 16:06, 21 December 2021 (UTC)
WP:RSPSS is worthless as a reliability predictor. It is a list based on historical data that assigns reliability based on past experience but also other considerations that are largely opaque to the reader. Its existence may induce confirmation bias in cases where editors 1. rely on it instead of doing proper context-based research of the source for a specific citation or 2. rely on it to engage in improper presentation. Any news organization that covers politics may have a declared or implied bias when it comes to such coverage. Mass commercial media such as CNN or Fox News cater to specific population segments representing opposing political opinions. This built-in bias is enough to make both likely unreliable in this area. This reliability-diminishing bias has to be made clear in wikitext describing political coverage: "according to liberal-leaning CNN/conservative-leaning Fox ..." etc. That is not to say that non-commercial political news sources are a priori reliable or unbiased. On the contrary. 65.88.88.47 (talk) 16:32, 21 December 2021 (UTC)
it will be enforced by POV pushers and others as an absolute thing That's a problem with the POV pushers. Every kind of technology can be abused. It's like saying we should not use the internet because hackers will then find ways to attack us. – SD0001 (talk) 17:53, 15 December 2021 (UTC)
It's also like saying that before we create and deploy a tool that we already know has a high potential for abuse, we should figure out whether it's going to cause more problems than it's worth. WhatamIdoing (talk) 18:59, 17 December 2021 (UTC)
The rationale regarding the tool's creation is wrong, not its usage. Proof of reliability is not conducive to automation. The proposal seems to treat sources as static items with uniform fixed qualities. This approach is already suspect, as one inviting confirmation bias. 65.88.88.93 (talk) 20:37, 17 December 2021 (UTC)
The IP is right. We have sources whose reliability depends upon the context in which it is used. Others are considered reliable up to a certain date. We have unreliable papers in reliable publications, or unreliable books published by reliable publishers. Doug Wellertalk14:29, 22 December 2021 (UTC)
We also have reliable sources published in unreliable publications (most commonly self-published subject matter experts). Thryduulf (talk) 16:34, 22 December 2021 (UTC)
What the people above me say. There are very few sources that are never appropriate to use in a cite web template; even something super unreliable like Breitbart can be useful as a source in particular circumstances. The reverse, too - super reliable sources sometimes are wrong in a given instance. Even aside from editors who may not draw the appropriate distinctions, automation bias will induce a lot of people to take the "reliability" the tool suggests as gospel even when it isn't correct. Jo-Jo Eumerus (talk) 16:45, 22 December 2021 (UTC)
Perhaps it would be better to replace the term "reliable sources" (relative to citations) with "currently reliable instances" (relative to specific citations). It is an ugly term, but just an idea.
The following is a likely example.
In December 2020, wikitext discusses the rate of mutation the Covid19 virus, stating "… the mutation characteristics of Covid19 are …" etc. The claims are backed by a recent official medical document. This is a verifiable claim from a reliable source.
In December 2021, the same wikitext is no longer true. The underlying official source has in fact been proven wrong. Recent official medical reports contradict the original report’s findings. There are several ways to handle this: the first is, throw out the original citation and wikitext. Rewrite with correct wikitext and citation. The second is more convoluted and involves discussing the evolution of medical ideas about the subject: "according to then-prevailing medical opinion, in December 2020 the mutation characteristics of the Covid19 virus were thought to be X." This is not good enough. You have to add the current prevailing opinion if you are to impart useful encyclopedic knowledge: "however this was wrong (avoid evasions such as "incomplete" or "superseded" or "amended" and call an apple an apple) - based on currently available data, the official medical opinion in December 2021 was that the mutation characteristics were Y". This should be good ... until the next official report. 65.88.88.93 (talk) 19:56, 22 December 2021 (UTC)
Add to above: notice that in the discussion of the evolving medical opinions, the wikitext relies on reliable sources for each claim: it is true that the December 2020 official report is a reliable source in discussing contemporary (late 2020) ideas about Covid19. It is also true that the December 2021 official report is also a reliable source in its context. 65.88.88.93 (talk) 20:12, 22 December 2021 (UTC)
There's a major problem with this, which is why I really don't like the idea of this in article text: reference sections are a common place for sneaky undetected vandalism, even in high-profile articles. This would become a ticking time bomb. Gnomingstuff (talk) 00:21, 24 December 2021 (UTC)
Changing the PROD process
I noticed a couple of problems with the PROD process in its current form. As useful as PRODs are (from experience), I identified a couple of issues with the way PROD is done.
There is no way to identify whether removal of a tag is an objection to the proposed deletion. Sometimes with PRODs I see a contributor make a bold edit and remove the PROD tag. It could be because of edit conflicts or it could be because the removal was by mistake.
There is no way to see the reason an editor objects to a deletion. Sure some editors use the edit summary to discuss objections to proposed deletion.
I think the following should change:
An objection to PROD should be clear. Some new creators may inadvertently remove the PROD tag without giving a reason for why they are removing it.
An objection to PROD should turn the PROD into an XfD. This kind of happens but not always.
Maybe the PROD templates are unnecessary. We could completely remove those templates and replace PROD with "listing at XfD, waiting for seven days to see if there are any objections to deletion to allow for debate, and then determining consensus". Aka merge PROD with the XfD process.
I'm not sure what changes you're proposing, but the ones I think you're proposing are ones I do not like. The editor who makes a PROD nomination is responsible for watching if there are objections, and nominating an AFD if they are not convinced by the objections. This works and there is no need to complicate it further. If you're suggesting completely removing the PROD process, you will need a clearer proposal. User:力 (powera, π, ν) 19:10, 29 December 2021 (UTC)
I think that WP:PROD is one of our processes that works very well. It leads to a lot of crap being deleted, but ensures that there is a discussion if there is any doubt about whether it is uncontroversial. I would urge the original poster to show evidence that the suggested changes would be improvements. Phil Bridger (talk) 19:42, 29 December 2021 (UTC)
An objection to PROD should turn the PROD into an XfD That should not happen. If I remove a PROD because I don't think that the deletion is uncontroversial, I am very likely not going to be able to provide a good rationale at AfD, other than what was provided in the PROD, which I disagree with. For example, If I de-PROD Jean Emile Oosterlynck, which has been nominated as "No evidence of notability found" but I happen to know that this is the same person as Jean Oosterlynck, who has an entry in Benezit, then I don't want to AfD that article. Vexations (talk) 21:21, 29 December 2021 (UTC)
Conversely, sometimes the de-PROD-er makes a solid argument and/or adds a number of sources, which will convince the PROD-er not to go to AfD. In other words, there's sometimes a good reason why an objection to a PROD does not result in an AfD nomination. JBchrchtalk21:33, 29 December 2021 (UTC)
I object to these changes because I feel they increase the administrative burden of the PROD process, and I do not see what benefit that is supposed to bring. Also I think the new labor proposed would fall to the person objecting to PROD, when instead I feel that the most labor and responsibility should fall to the person nominating the article for PROD. I support changes which assist anyone in transitioning a PROD to an AfD, but I like PROD for what it is now and AfD for the different thing that it is now. I do not wish to make PROD more like AfD. I do agree with the nominator that I wish we more often had easily accessible records of why users post PRODs or remove them, and I support changes which increase users giving this information, but I do not want users to feel additional pressure to use the process. Blue Rasberry (talk)21:28, 29 December 2021 (UTC)
For the newer editors here, we don't want to make the learning curve to operate here even more difficult. Also we don't need to increase the overhead work. SO I am not supporting the suggested proposals. One possible idea if a prod is removed without an edit summary is to put up a special pop up saying that the editor remove a proposed deletion template, and asking them why they did that, with a box for a better edit summary. (maybe edit filters can do this). Graeme Bartlett (talk) 21:45, 29 December 2021 (UTC)
I'm going to use an extreme example just to demonstrate the point. Let's say Donald Trump gets PRODed; he is obviously notable via multiple criteria, including WP:NPOL and WP:GNG among others. It would thus be rightfully contested. Why would we thus waste everyone's time by sending it to AfD? Merging PROD with AfD is fundamentally flawed, will be extremely difficult to implement, and will just increase administrators' workload. And in response to you 1st proposed changed for rationale, while we all wish all dePRODers use the edit summary, there is no functional way of enforcing this function. C'est la vie. Curbon7 (talk) 21:56, 29 December 2021 (UTC)
This proposal seems born out of a misunderstanding of what PROD is for. It is for uncontroversial deletions. It is deliberately designed to be easy to object to. If the PROD is removed, the burden is on the PROD proposer to decide whether to proceed to AFD. Merging the two processes is therefore a terrible idea. Beeblebrox (talk) 22:43, 29 December 2021 (UTC)
Good to see some feedback. I also see it as a way for uncontroversial deletions, but one of the problems I have seen with PROD is that I cannot identify whether a removal of a PROD template is an objection or the result of something else like an edit conflict or vandalism or what. Policy does not make this clear.
As for point #2 which I made earlier, I am also starting to see why it may be kind of a bad idea, but at the same time, the point of AfD is to discuss whether an article should be deleted or not, which is of course the reasonable next step after a proposed deletion.
And for adding something to the abuse filter, that is actually not a terrible idea. Although I am not sure if the filter will pop up in an edit conflict. That prob fixes point #1.
It is possible I posted in the wrong subforum, in which case someone is free to move it to idea lab or policy. Aasim (talk) 05:34, 30 December 2021 (UTC)
Even after your clarifications I'm strongly opposed. If the PROD template is removed and it isn't absolutely clear that the removal was vandalism then you must assume that the removal was an objection. A reason for objecting to a PROD is not required, nor should it be required. If you still think that the article should be deleted then you are the one who is responsible for listing it at AfD, it is not reasonable to require this of someone who does not think that article should be deleted. Thryduulf (talk) 12:48, 30 December 2021 (UTC)
The policy on removal of the tag is crystal-clear. It says, "If an editor's intent is unclear, an objection should be assumed." This is simply a procedure for deleting articles that everyone accepts should be deleted without a full discussion, an application of WP:BRD to deletion. If anyone objects then discuss, just as for any other change. Phil Bridger (talk) 19:46, 30 December 2021 (UTC) P.S. And please don't start a discussion somewhere else if you don't like the outcome of this one. Here is fine, and forum shopping is frowned upon. — Preceding unsigned comment added by Phil Bridger (talk • contribs) 19:52, December 30, 2021 (UTC)
Agreed. These are simply not viable proposals. A PROD is supposed to be a low overhead deletion process for uncontroversial deletions. Curbon7's "Donald Trump" example is a perfect counterexample to explain some of the inherent issues with the proposals. We should not be creating a backdoor method for users to effortlessly nominate things for XFD. Vandals would just love that. Meters (talk) 20:07, 30 December 2021 (UTC)
A few weeks ago, a discussion about portal links on the Main Page was closed as "no consensus", with suggestions for a way forward. A closure review at AN was archived yesterday. As I will not be shepherding this discussion further, I invite any interested editor(s) to pick up where I left off. This is not a protest against the closure, but simply a decision to focus on other things for the time being. JBchrchtalk11:15, 2 January 2022 (UTC)
Don’t annoy the 2% who give
I’m one of the above. I’ve just been berated multiple times in the last 5 minutes. A gentle nudge is sufficient. You have the technology to distinguish me from the 98%. Do that. — Preceding unsigned comment added by 216.106.102.52 (talk) 01:12, 12 December 2021 (UTC)
Regarding the general principle of providing customized experiences for readers who are not logged in, there is a significant number of people who dislike being tracked in this manner. In theory it could be used solely to disable fundraising banners, but I suspect the resistance to IP tracking will continue to be a barrier for acceptance. isaacl (talk) 16:35, 12 December 2021 (UTC)
I agree that tracking IPs and donations would be a bad idea, but couldn't we use a browser cookie to track dismissals like we do for watchlists notices? Imagine how pissed off someone needs to be in order to track down the village pump and post this; I think it might be worth figuring out a way to make the banners slightly less annoying for readers. — Wug·a·po·des00:42, 24 December 2021 (UTC)
The underlying technology is basically the same: using data in a cookie to correlate your past behaviour with your current action. In theory, maybe people could be convinced that this is only being used to disable fundraising banners. In practice, I'm dubious. isaacl (talk) 21:59, 29 December 2021 (UTC)
We already do that right ? At least that is how it used to work for years (can't check, I'm not in the geozone, but if someone else can, plz do check). I think Ppl are just complaining more this year because of increased privacy guards in various browsers blocking the cookies. I suspect. Or they just can't find how to dismiss, because the UX of the banners is so F'ed up? —TheDJ (talk • contribs) 13:59, 3 January 2022 (UTC)
Adding onto the above, if you don't already know, one easy way to disable the banners is to just create an account and log in, since they're not shown to logged in users. Cheers, {{u|Sdkb}}talk21:07, 13 December 2021 (UTC)
Welcome and thank you for your question about donations! To hide the fundraising banners, you can create an account and uncheck Preferences → Banners → Fundraising. The Wikimedia Foundation does not track the identity of IP addresses, so it doesn't know your age, income level or whether you donated in the past. None of the Wikipedia volunteer editors here who add and improve content in articles receive any financial benefit. We all simply contribute our time because we care about building a great encyclopedia for you and innumerable others around the world to use. If you cannot afford it, no one wants you to donate. Wikipedia is not at risk of shutting down, and the Wikimedia Foundation, which hosts the Wikipedia platform and is asking for these donations, is richer than ever. We are led to believe that users who allow cookies are less likely to see these banners on repeat visits (further information is available here), and you are welcome to communicate directly with the donor-relations team by emailing donate@wikimedia.org. Thank you!
Beeblebrox (talk) 22:39, 29 December 2021 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Sitting on the edge of a policyproposal I do think it belongs here though.
Wikipedia is said to be an unbiased, non-reliant and objective source of information. Yet it follows the remnant of 'our' (I'm European) religious and colonial past by presenting the years as BCE/BC and CE/AD. Wikipedia should be an inclusive platform, for all human knowledge, without a bias towards Christianity and its systems introduced often by means of oppression. Only about a third of all humans consider themselves Christian according to the wikipedia page on World Religion. More than half the population in my home country (The Netherlands) consider themselves as non-religious according to official CBS statistics in 2020. With the start of the new year 12022 HE I wanna start the discussion of introducing the Holocene calendar on wikipedia worldwide, as default yearnumbering system with the local dominant system only presented in between brackets if dates are named in an article. Let Wikipedia be a forerunner in the introduction of an inclusive calendar reform. What are your thoughts on this?
Grifo (talk) 13:29, 3 January 2022 (UTC)
Wikipedia follows the sources, it doesn't lead them. Convince most of the English-speaking world to start using a new Common Era and Wikipedia will follow. As it is, why should we use the "Holocene calendar" (which itself seems to be off by ~300 years) rather than declaring the current year as −72 BP? And why not rename the months to not be mostly named after old Roman gods and numbers that are off by two? Anomie⚔13:51, 3 January 2022 (UTC)
Can you define 'the sources' please? I thought Wikipedia was about following reliable, unbiased sources. Not some 6th century monk (Dionysius) who erroneously placed the birth of his religious frontfigure randomly along a timeline, which was applied as yearnumbering system ever since due to the makeup of contemporary society.
I'm ok with the BP calendar, but the HE is more practical. The years the Holocene calendar might be off compared to the assumed real onset of the Holocene is a minor issue. We will never know the exact year the Holocene started, nor will there ever be an historical neolithic event dated so precisely that the HE calendar needs a reform to allow that event to be fixed inside the calendar.
The 'standardized' Roman/Germanic name of months and days doesn't render the same effect of applying value to certain historic events likr yearnumbering does (i.e. before time began or after a certain local and subjective event took place: after time began), implying less importance to the events prior to year 1. With either the BP or the HE calendar, such exclusive subjectiveness of implied value of events is removed and is instead replaced by an objective marker having the same value for all citizens of the world as the event (Holocene/Nuclear Era) was omnipresent. Grifo (talk) 15:42, 3 January 2022 (UTC)
It seems there are several incorrect assumptions above. To see what Wikipedia actually is fundamentally, start with Wikipedia:General disclaimer. Then proceed to something like WP:NOT which, even though not as embedded as the first, is also pretty basic. And so on. What "Wikipedia should be" is an opinion, which anyone may embellish with moralizing of one sort or another without in any way affecting its factual validity. Other than that, I've no idea if what you suggest is technically actionable. 65.88.88.201 (talk) 16:01, 3 January 2022 (UTC)
This isn't about when Jesus was born, or even whether he existed. (There's at least as much doubt that the changes marking the Holocene epoch occurred in precisely 10,000 BCE.) The important thing is the WP:COMMONNAME of the current year, and most English speakers seem to call it 2022. Any campaign to change that should not start at Wikipedia. Certes (talk) 17:24, 3 January 2022 (UTC)
Grifo As noted, you are going to need to launch a worldwide campaign to persuade governments and people to adopt your preferred calendar, before Wikipedia can do so. 331dot (talk) 16:05, 3 January 2022 (UTC)
I have many articles about archaeological sites and cultures on my watchlist, many of which use BCE/CE. I see far more users who are not familiar with our guidelines trying to convert BCE/CE to BC/AD, than the other way round (and I don't recall anyone trying to convert the era designation to HE or BP). Even if there were a consensus to ignore the sources (overturning some core Wikipedia policies), I doubt there would be any consensus to use anything other than BC/AD as the default era designation. - Donald Albury17:35, 3 January 2022 (UTC)
Civil calendar states that most civilizations use the CE/BCE system with the Gregorian calendar - so even outside of what the sources may document dates in, it is the reference frame that English literate readers of our encyclopedia would expect when reading articles. — xaosfluxTalk18:34, 3 January 2022 (UTC)
More than half the population in my home country (The Netherlands) consider themselves as non-religious... but what calendar do they actually use? The Gregorian calendar. The vast majority of countries use the Gregorian calendar for at least some purposes and the few countries which don't will nevertheless be familiar with it. This is particularly true for English speakers, which are the target audience of the English Wikipedia. Switching to an alternative such as the Holocene calendar would just confuse people who aren't familiar with that calendar. Wikipedia generally follows the rest of the world (or at least English speakers) in matters like this, you should try convincing others first. Hut 8.512:59, 4 January 2022 (UTC)
But how to convince others when something grassroots like Wikipedia follows the dictate of past colonial society which implemented the Gregorian Calendar worldwide, disregarding any cultural heritage of oppressed peoples? Where to start when even Wikipedia does not follow its own standards? Wikipedia is based on reliable sources. The Monk I mentioned is not a reliable source at all, yet Wikipedia follows his yearnumberingsystem everywhere. I am NOT opposing the Gregorian Calendar though, I'm opposing the starting point of it. The starting points of the Holocene Calendar or the Carbon Dating Calendar (BP) are much better, much more inclusive, much more reliable, much less subjective to pre-Christian times and have a worldwide recognisable starting point. Something an encyclopedia should prefer, despite the inconveniance this might result in to alter all dates.Grifo (talk) 16:33, 4 January 2022 (UTC)
Apart from all other arguments against this given above; you are aware that the Holocene calendar is "directly" based on the same BC/AD calendar, but simply moves it back exactly 10,000 years? If you want to get rid of the influence of Christianity or the calculations of a monk, then using the Holocene calendar is not the solution at all. Fram (talk) 16:42, 4 January 2022 (UTC)
Because it would confuse the hell out of just about everybody. Everybody knows that it this year is 2022, and would think that 12024 HE is a typo. And just think for a moment about having to change almost every citation. Vexations (talk) 16:57, 4 January 2022 (UTC)
Let me ask a related question: "Isn't writing this in English a vestige of European colonialism?" The only reason a lot of people in the world speak English today is because a few hundred years ago, the English built boats and sailed to other continents where they conquered the native populations. The Spanish, French, Portuguese, Dutch, etc did a lot of that too. The only reason I speak English is because my great-grandparents left their homes and came to the United States, where they learned English (but didn't convert to Christianity). Isn't continuing to use those languages to write encyclopedias just following the remnants of our colonial past? Well, yeah, but as noted above, wikipedia's job is to collect and document information, not to be a leader for sweeping social change. We use CE dates not because we think they're best, but because that's what most of our sources use, and what our readers are used to. Looking at the home pages of the zh, hi, ar, and he wikis, I see they all use CE dates. Surely if CE dates are good enough for those wikis, it's good enough for enwiki. -- RoySmith(talk)17:25, 4 January 2022 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
New edit tags, for sockpuppets and other blocked users
Background: I recently opened a series of SPI investigations on some sockpuppets. As I look through their contributions, I realised that those were all created for the sole purpose of disruptive editing. A number of their edits are not reverted, and in a few cases happen to be the latest revision of a certain article. Now this certainly isn't an issue unique to my case, there would be lots of such issues lying around elsewhere within Wikipedia. How can we help editors working on specific projects/articles point out potential problematic edits?
Proposal: Should we establish new tags (list) that automatically appears on edits made by revealed sockpuppets? And another tag for edits made by users who are currently blocked for reasons like vandalism, disruptive editing, multiple test editing, etc. This would help editors skimming through edit history of a page identify potential problematic edits made by users who are blocked for violating WP rules. ---CX Zoom(he/him)(let's talk|contribs)22:32, 4 January 2022 (UTC)
It's not a bad idea. There are user scripts that automatically flag blocked accounts a number of ways with colors or strikethroughs. These should be standard IMO. -- GreenC22:38, 4 January 2022 (UTC)
markblocked, which you can enable in preferences, accomplishes roughly the same thing (you can hover over the blocked editor's username to see the block reason). Using tags to do this doesn't seem like a good idea. AFAIK this would require an admin (or adminbot) to add the tags whenever someone gets blocked, and remove them if they successfully appeal; the script, on the other hand, requires no additional maintenance work. The whole business of blocked users, sockpuppetry, etc. is also largely irrelevant to the average user, who only comes here to fix a typo once in a while. I think it's best to leave it as an optional gadget for those interested. Spicy (talk) 23:28, 4 January 2022 (UTC)
markblocked or similar sounds like a better idea, as it will update automatically whenever the [ir]responsible editor is blocked and unblocked. Tags are for properties of an edit, whereas this proposal is about the properties of a user. Good users occasionally make bad edits, and vice versa. Certes (talk) 02:18, 5 January 2022 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
About Preference, Gadgets: four codes are listed and described in the
Gadget legend: (D), (E), (S), (U). The descriptions appear in the list as {{abbr}} like (D), OK. Now, between the four the period (full stop) is alternating missing/present in the abbr tooltip text. Maybe could be smoothed?
(I personally do not think for this issueette the Project should be restarted from 20 year ago, but I do like to take my examples from high end quality webpages ;-) ). -DePiep (talk) 06:58, 7 January 2022 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
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 support for most changes proposed, and they may be rolled out. There is also support for the idea that most typical changes to cs1/2 are uncontroversial and don't need to undergo routine VPR RfCs to be rolled out.
The crux of the opposition, aside from the comments about the nature of the all-or-nothing RfC, centred on the removal of deprecated parameters. Although the argument in later comments, that we don't generally support old historical revisions, is strong in the context of TfD, its application to citation templates was disputed in the widely-attended Monkbot 18 RfC. So I think there is no consensus on removal of deprecated parameters in this discussion, and further discussion will be necessary to roll that part out. ProcrastinatingReader (talk) 16:45, 15 January 2022 (UTC)
Yes or No. Shall the Citation Style 1 / Citation Style 2 (cs1/2) Lua module suite be updated to reflect the changes that have accumulated in the module-suite's sandboxen?
This is an all or nothing rfc. In the event of a draw, cs1/2 shall be updated. §list of prospective changes gives brief descriptions of the individual changes and links to related discussions.
list of prospective changes to the cs1/2 module suite
The last update to the cs1|2 module suite was 2021-04-10 except where otherwise noted. This section lists the changes made to the cs1|2 module suite sandboxen since that update.
Strong oppose. There are far too many changes here for a single, all-or-nothing question, so I must oppose. Come back with a series of proposals that treat the community like adults and I will support the ones that will improve the encyclopaedia. Thryduulf (talk) 00:42, 29 November 2021 (UTC)
I object to the concept of this RFC being all or nothing so that controversial changes such as removal of support for parameters that there was no community consensus to deprecate let alone remove are being pushed through with proper review because it would hold up needed uncontroversial changes. That's WP:GAMING the system. Thryduulf (talk) 19:50, 29 November 2021 (UTC)
Re Headbomb's comment below: to be clear, there is at least one change in this set known to be contentious, so a procedural closure of this RfC should not be taken as a green light to roll out everything. Nikkimaria (talk) 01:01, 29 November 2021 (UTC)
The removal of support for the unhyphenated parameters is also contentious, given that the premise of the discussion that (is claimed to) be the basis of consensus for the changes explicitly ruled that out (according to my memory of the major RFC anyway). Thryduulf (talk) 01:24, 29 November 2021 (UTC)
The RFC established that the basis on which both sets parameters were deprecated did not have community consensus, or even a local consensus given that the course of action undertaken was explicitly ruled out as something that would happen. Wikilawyering about exactly what was covered by the RFC is also not a good look. Thryduulf (talk) 13:43, 30 November 2021 (UTC)
Support. This is a normal code update that has typically happened every few months. It contains bug fixes, minor enhancements, and small refinements. A larger number of minor changes than usual have accumulated because a small band of editors objected to the last regular update, and the volunteers who maintain the modules understandably decided to take a break from that drama for a while. Normally, notice of these updates would take place at Help talk:Citation Style 1 (418 page watchers, 125 recent visitors), where updates to these modules have been discussed for roughly a decade. Since there was drama last time, the updates are being vetted at this more-heavily-watched page (3,503 watchers / 554 recent). – Jonesey95 (talk) 02:24, 29 November 2021 (UTC)
Support—we're overdue for the quarterly update. These updates dump millions of articles into the job queue for processing, so the changes are bundled and applied at once. Imzadi 1979→15:24, 29 November 2021 (UTC)
Oppose removal of formerly valid parameter names, breaks old revisions for no good reason, was opposed at previous RfCs. Would probably support the rest, but in something as unwiki as an all-or-nothing RfC (Wikipedia usually operates by consensus), this is my only option. —Kusma (talk) 20:14, 29 November 2021 (UTC)
But that's not what Kusma (correctly) opposes for: the "deprecation" of parameters we used to allow is one thing, the "removal of support" from the code though means that all older versions of articles which did use these parameters will now give errors instead of just having a working (though no longer wanted) parameter. For parameters which were never widely in use, this may be acceptable; for parameters which where more widely used, this is problematic. Where the cutoff for "widely" should be placed is another kettle of fish of course. But that these parameters have been deprecated in February doesn't mean that one should support a change which now no longers supports them at all. Fram (talk) 09:15, 30 November 2021 (UTC)
Support all of these changes, including those identified as potentially contentious by Pppery below. I would also prefer a return to the previous approach of more frequent updates for minor changes, with RFCs reserved for changes that are likely to prove controversial, but am content for the editors that maintain the CS{1,2} templates to decide how they bring changes to the community to review. Wham2001 (talk) 08:01, 30 November 2021 (UTC)
Oppose. "It's an all or nothing" and you sneak in opposed changes which you happen to support? No thanks, if that's what you try then just abandon your maintenance of this please. I love the division created by a support vote between "a small band of editors" vs. "the volunteers who maintain the modules", a nice indication of a warped view of priorities there. Fram (talk) 08:42, 30 November 2021 (UTC)
Fram's last sentence is important. Those who maintain these modules are doing a service to editors who add citations to articles not the other way around and this needs to be remembered. If the people who use the templates say something is bad, disruptive or unwanted then it should not happen and/or be reversed without question. The encyclopaedia does not exist for the convenience of coders. Thryduulf (talk) 10:51, 30 November 2021 (UTC)
Those who maintain these modules are volunteers, not WMF employees, and they perform a complicated and very valuable service for the content creators. We are immensely grateful for the work they do. We appreciate and understand that a package of changes have been tested together and cannot easily be unbundled. Hawkeye7(discuss)03:52, 1 December 2021 (UTC)
No, you've been mislead to believe that. It would in fact be technically trivial to perform the rest of the update without changing the list of supported parameters. I'm becoming more and more inclined to oppose this RfC with every passing comment. * Pppery *it has begun...03:54, 1 December 2021 (UTC)
Those who maintain these modules are volunteers, not WMF employees yes, so?. they perform a complicated and very valuable service for the content creators. which is why they need to respect the community's wishes. Thryduulf (talk) 12:18, 1 December 2021 (UTC)
Support all changes per Pppery and Jonesey95 comments below. As an additional comment to this procedure, the module maintainers do a very complicated and ungrateful service and I find it pretty absurd that module updates now require RfCs and even more absurd are some of the opposers are on the grounds that there are too many changes (and I'm not one of the maintainers). --Gonnym (talk) 11:01, 30 November 2021 (UTC)
The issue is not that there are too many changes. The issue is that there are too many changes that we are being asked to approve as a single unit, and that unit includes changes that should not be made as well as changes that should. The module maintainers are giving the appearance that they care more about the module than they do about the reason the module exists: to support those writing an encyclopaedia. The only correct way to proceed in a situation like this is to swallow some pride and agree to separate the controversial and uncontroversial changes so that the former do not hold up the latter. The controversial changes than then be discussed on their merits and the consensus of the community listened to, whatever that consensus is, rather than attempting to bypass it. Thryduulf (talk) 13:40, 30 November 2021 (UTC)
Support, although I don't really like the format of this RfC (particularly, the "all or nothing" framing and "In the event of a draw, cs1/2 shall be updated"). I don't think that the RfC should be closed as flawed, but it should be evaluated based on consensus for each of the proposed changes rather than "all or nothing", and no consensus should lead to retaining the status quo. Tol (talk | contribs) @ 21:57, 30 November 2021 (UTC)
Oppose this RfC as stated but support unbundling the set and implementing the many non-controversial changes but not the controversial ones aka "common sense". Levivich05:18, 1 December 2021 (UTC)
Oppose I've come to realize what this RfC really is, an attempt towill do: falsely establish consensus for controversial changes by making them a rider to clearly-supported changes when they failed on their own merits. That sometimes works for legislation, but it should not work on Wikipedia. * Pppery *it has begun...22:36, 1 December 2021 (UTC)
Really? Really? Do you really think that were I trying to falsely establish consensus for controversial changes by somehow hiding them amongst a large number of other changes, I would have written this with its rather obvious markup which pretty much guarantees that anyone who merely scans the list could not fail to see it:
remove support for previously deprecated parameters |booktitle=, |chapterurl=, |episodelink=, |mailinglist=, |mapurl=, |nopp=, |publicationdate=, |publicationplace=, |serieslink=, |transcripturl=
You have accused me, and probably, by extension, the other maintainers of the cs1|2 module suite of malfeasance, of dishonesty, of lying. Produce the evidence or withdraw your accusations.
If this RfC passes (which might happen), then support for unhyphenated parameters will be removed.
If there had been a RfC solely on the question of whether support for unhyphenated parameters should be removed, that RfC would likely have failed for the same reason Option C passed at the previous RfC
Conclusion:
This RfC passing will result in a false consensus in favor of removing support for unhyphenated parameters, as a result of it being stuck in as a rider to a broadly-supported set of changes. It was incorrect to phrase it as an accusation of malicious intent, and I've reworded the above comment slightly, but that doesn't change the underlying situation.
No (equating to "oppose") as clearly mandated in the RfC's instructions, and almost entirely because of the RfC's instructions. Apparently, this RfC has to lean hard over to the "oppose" side, lest there be "no consensus", leading to to the same results as "Yes" ("support"). Then we can discuss the specific issues in an actual, properly formed RfC. — JohnFromPinckney (talk / edits)20:36, 4 December 2021 (UTC)
I am astonished, truly, I am. Usually the complaint is 'too technical' or 'too much detail'. Discussions about all of the proposed changes are linked in the collapsed box at § list of prospective changes to the cs1/2 module suite. Except for the most minor of changes, all changes to cs1|2 are always discussed so whatever detail you are seeking is likely in the related linked discussion. My word choice is not the subject of this rfc so a comment about that is erroneous here. (I'm not old enough to remember Middle English: boxen in everyday usage, but I am old enough to have used VAXen so it is not uncommon for me to also substitute boxen in its more modern sense anywhere that boxes might occur. I am not the only editor at en.wiki to do this)
Support. I support all changes. Most are minor and have strong consensus. The on that seems most controcersial is deprecation of certain unhyphenated parameters. Per the statistics bewlw, this will affect less than 1% of all pages using CS1/2, is easily fixed by bots, and a display will be displayed only when viewing old revisions. Not breaking old revisions has never been considered a strong argument at TfD and for the purposes of updating the module the reasons are the same. We don't hold supported templates hostage to faithful transclusions in old revisions. – Finnusertop (talk ⋅ contribs) 15:50, 14 December 2021 (UTC)
Support. I see no problems with the changes. It is correct that removing parameters will mess up with page history but we have made many other actions that does that. We can't keep a fully working page history forever. I think it is a good idea to keep old parameters for some time but I see no reason why we need to keep them forever. --MGA73 (talk) 23:22, 27 December 2021 (UTC)
discussion (update cs1/2?)
The only things here that seem plausibly controversial are:
add Category:CS1 tracked parameter: $1 properties tracking category; discussion (My observation: this doesn't actually add any new tracking categories, but merely adds code to populate such tracking categories if they are later needed)
FWIW, the deprecation of the above parameters happened in February 2021, more than nine months ago, all of the parameters were updated shortly thereafter, and any stray instances of those parameters have been generating error messages (and have been quickly fixed) since April 2021. This update would change the error message from "deprecated" to "unsupported" in the very rare instance that someone used one of these long-gone parameters. This change should not be confused or conflated with the objected-to deprecation of |accessdate=, which is still in wide use. – Jonesey95 (talk) 17:08, 29 November 2021 (UTC)
How long have they been used and how many old revisions will be broken by removal of these parameters? And what is gained by removing them? —Kusma (talk) 09:38, 30 November 2021 (UTC)
These parameter aliases were not commonly used. Hyphenated versions of them have been the standard since 2014. Dozens of unhyphenated multi-word parameters have been deprecated and removed from the CS1 citation templates over the past seven years with a minimum of drama (until the final six were proposed for deprecation back in April 2020, which is not something that is happening in this RFC). – Jonesey95 (talk) 14:19, 30 November 2021 (UTC)
For a sense of scale, Module:Citation/CS1 is used in just over 5,000,000 pages. 33,000 pages was a little less than 0.7% of the total page usage. That is why it was so straightforward and easy to deprecate and update the above parameters, as opposed to the six remaining unhyphenated parameters, which are more widely used. – Jonesey95 (talk) 23:00, 3 December 2021 (UTC)
OK, so the damage is middle sized (17000 broken chapterurls will create some annoyance). But removing these aliases still doesn't have any obvious advantages over not removing them. —Kusma (talk) 16:40, 7 December 2021 (UTC)
In the event of a draw, cs1|2 shall be updated. This isn't normally something an editor opening an RfC can unilaterally declare, nor is an RfC's all-or-nothing status. Per WP:Consensus, if there's no consensus, we generally retain the status quo. {{u|Sdkb}}talk23:33, 28 November 2021 (UTC)
It is totally inappropriate, and whoever closes this should ignore this made-up rule that has no policy-based support whatsoever. In the event of "no consensus overall", the changes that are supported by consensus should be applied and the changes not supported by consensus not applied. —Kusma (talk) 09:36, 30 November 2021 (UTC)
Waste of time RFC it's utter nonsense that we have to wait for months for CS1|2 updates to be rolled out, it's even more utter nonsense that we need RFCs to roll them out. If they're ready and have consensus, roll them out as soon as they've been tested in the sandbox and confirmed as working as intended. Don't delay, and don't plague us with pointless RFCs. If a particular issue is contentious, have an RFC on that issue, don't hold the rest of the updates hostage. Headbomb {t · c · p · b}00:45, 29 November 2021 (UTC)
I don't like the format of this RfC. It would be better done by a different method:
Propose these changes and see if anyone opposes one or more of them.
Unopposed (uncontroversial) changes can be immediately implemented or held until after the second part.
Opposed (controversial) changes would need consensus in part 2.
Obviously uncontroversial changes don't need to be included.
Open a multi-section RfC with a section on each controversial change, and let each section gain consensus individually.
Implement changes that were either uncontroversial in part 1 or gained consensus in part 2.
I don't think that the RfC should be closed as flawed, but it should be evaluated based on consensus for each of the proposed changes rather than "all or nothing", and no consensus should lead to retaining the status quo. Tol (talk | contribs) @ 21:57, 30 November 2021 (UTC)
The cynical view is because that's the only way the proposer(s) do not wish to test the consensus of the changes individually, possibly because some of the desired changes may not pass. You are not the first to ask the question, but none of the responses have provided a plausible alternative view, although malicious intent has been denied. Thryduulf (talk) 21:31, 3 December 2021 (UTC)
Changes to cs1|2 are not made secretly behind a veil; all editors are welcome, encouraged, to participate in the discussions about cs1|2 at Help talk:Citation Style 1. There is no need to re-discuss that which has already been discussed (see the discussion links in the collapsed box at § list of prospective changes to the cs1/2 module suite). Except for the most minor of changes, all changes to cs1|2 are always discussed, mostly at Help talk:Citation Style 1 and sometimes, at other locations (Help talk:CS1 errors and Template talk:Citation are common alternate-discussion locations).
In my experience – yours may be different – inconclusive RFCs result in the question: 'now what?' To avoid the 'now what?' question, I defined an action to be taken in the event that the community's opinion is not definitive. So now you know. The answer to the 'now what?' question for this RFC is: update.
There is no need to re-discuss that which has already been discussed (see the discussion links... But not all of those discussions reached a consensus in favour of the proposed changes. That suggests that either they do need to be re-discussed, or they should be removed from the proposal. Nikkimaria (talk) 00:03, 4 December 2021 (UTC)
@Trappist the monk:inconclusive RFCs result in the question: 'now what?' This could not have been an inconclusive RfC - either there is consensus for the changes or there is no consensus for the changes. In the first case the changes are implemented, in the second case they aren't. If the changes did not get consensus there is nothing stopping anyone who understands why they failed to get consensus addressing the reasons and asking the community about the revised proposal. Everywhere else on Wikipedia changes for which there is no consensus do not get implemented, and there is no reason for this to be any different. Thryduulf (talk) 11:32, 4 December 2021 (UTC)
The question asked by this RFC is simple: Yes or No, shall we update? If the community's answer as determined by the closer is predominantly Yes then we update; if the community's answer as determined by the closer is predominantly No, then we do not update. If the community's answer as determined by the closer is inconclusive then we update and avoid the 'what now?' question. Because it is stated in the question, all respondents to this RFC know what to expect in the event of a tie.
Lol ttm like that would ever fly. The initiator of this RFC knows what to expect if updates are pushed without consensus. Levivich14:06, 4 December 2021 (UTC)
If the answer as determined by the closer is "inconclusive" then anywhere else on Wikipedia the status quo would apply, which in this case would mean "we do not update". You have not explained why this RfC should be different to everywhere else. Thryduulf (talk) 18:06, 4 December 2021 (UTC)
How much of a maintenance burden would it be to keep the deprecated parameters around? I sometimes worry that while the desire to keep old revisions working is reasonable, keeping the old parameters around might create extra work when updating/maintaining/adding new functionality to CS1/2 templates and we might be neglecting this extra work. Jo-Jo Eumerus (talk) 10:42, 4 December 2021 (UTC)
In the last RFC, which found "There is a rough consensus that non-hyphenated parameters should not be deprecated in citation templates" (emphasis in original) the maintenance burden was brought up multiple times, but nowhere in the discussion could I find anywhere that detailed exactly what that burden is or why it is so significant that it was more important than the various benefits of keeping them around (not breaking old revisions, editor familiarity, ease of use, etc). Certainly none of the arguments about maintenance burden convinced people in opposition to deprecation to change their minds. Thryduulf (talk) 11:43, 4 December 2021 (UTC)
Some think it's okay to remove old parameters and some think we should keep them to preserve page history. Personally I do not think it is possible or needed to make sure that a page history will work forever. But I agree that it would be good to preserve page history for some time. So perhaps as a compromise there could be some time limit so parameters used on less than 1k pages could be removed faster than pages used on 1M+ pages? --MGA73 (talk) 23:33, 27 December 2021 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Proposal to upgrade search feature
Here is my idea for discussion. Often there is a variant when someone writes a word in the wrong font in the search bar, for example, he uses the Latina font, but Cyrillic is needed. In this case, Wikipedia can't find anything right now. It would be useful to implement a search function when Wikipedia suggests some variations of articles as if it were the correct font. For example: there was wrote "djlf", but you need "вода" ("water"). The feature was implemented in Google search many years ago.Дмитрий1515 (talk) 15:58, 13 January 2022 (UTC)
(talk • contribs) 19:09, 12 January 2022 (UTC)
I think that the Wikipedia search function is pretty useless on many counts as well as this one, so it is better to perform a site search with your favourite search engine anyway. This is just one of the features that would be useful to readers of this site and wouldn't cost much to implement, but the WMF prefer to spend the vast amounts of money that they receive from the public on expansion of their role and self-perpetuation. Phil Bridger (talk) 19:27, 12 January 2022 (UTC)
In the particular regard of the search bar, I think there is more of a persistent fear to do anything with it. The knowledge project had such dramatic outcomes that I suspect it's poisoned the well in terms of additional search functionality expenditure. Nosebagbear (talk) 13:41, 13 January 2022 (UTC)
I have no opinion as yet on whether this would be a good change, and am unlikely to form one unless you say why you are proposing it. Phil Bridger (talk) 08:24, 9 January 2022 (UTC)
Set index articles are not dabs, because dabs are not articles. However, they have many features in common and some SIAs might work better as dabs. (For example, Ministry of Defence is denied the benefit of our dab maintenance tools because its meanings happen to form a set.) It might be useful if some or all SIAs were more dab-like in ways that I'm struggling to define. Perhaps that means creating maintenance category(s) which include Category:All disambiguation pages and some or all SIAs, such as Category:Pages which should have no direct incoming links, and encouraging {{R from disambiguation}} redirects to its SIAs. Alternatively, it might mean allowing certain lists to be formatted as dabs instead of SIAs. I would also be interested to see more specific proposals. Certes (talk) 14:29, 9 January 2022 (UTC)
Set index articles exist as a concept distinct from disambiguation pages because there are topics/titles that need disambiguation but which cannot be made to fit within the strict formatting requirements of disambiguation pages (or the reader otherwise benefits from a different format). Given that the rigidity of the disambiguation page formatting seems to be desired by those who maintain the pages, I don't foresee any likelihood of a merge gaining consensus soon. Thryduulf (talk) 15:21, 9 January 2022 (UTC)
An important feature of Set index articles is that they may consist of redlinks, whereas dabs can not. For example, this set index article is certainly useful, since it contains a list of all localities with this name (and can be used, for example, to choose proper name for new articles and even for redlinks). If converted to dab, it is amenable to speedy deletion, since there is nothink to disambiguate. I have such articles on my watchlist being nominated for speedy deletion by users who do not understand the difference.--Ymblanter (talk) 19:04, 9 January 2022 (UTC)
I think there are (at least) two cases here. On the one hand, HMS Nonsuch is an SIA, a list of actual things, some of which have no article and even no WP:DABMENTION. It doesn't meet our standards for a dab and shouldn't be changed to comply with them because it is not a dab. (However, it is of use to someone who wants to read one article about a ship of that name and doesn't recall enough detail to guess its exact title.) On the other hand, Ministry of Defence acts as both a list and a dab; the only thing preventing it from being a dab is the unwritten rule that at least one dab entry must be unlike the others. (So if someone wrote Ministry of Defence (film), we could list it and call the page a dab.) Certes (talk) 16:53, 18 January 2022 (UTC)
No. Disambiguation pages are lists of articles with similar titles, which could describe different types of thing. e.g. St. Helen. Set Indexes are lists of things of the same type with similar names, some of which may never have articles, e.g. List of lakes named McArthur. Not the same at all. Aymatth2 (talk) 17:10, 18 January 2022 (UTC)
Leaning oppose. A set index can be a title to which a link is intended to point in reference to the things listed on the page. A disambiguation page is supposed to have no incoming links, except links with (disambiguation) in the title to signify that the link intends to point to the disambiguation page, for the purpose of indicating that it is a disambiguation page. BD2412T07:36, 19 January 2022 (UTC)
SIA or dab?
A side question: what do we do with pages which qualify as both SIA and dab, so could be either? For example, there's little difference between Aagaard and McGhee. Each is a list of both articles and actual "things" – mainly but not exclusively people. Certes (talk) 17:44, 18 January 2022 (UTC)
This is common when the name implies the type of thing, e.g. Round Lake or Big Mountain. If you have a list of things of the same type with the same or similar names, and they all have articles, disambiguation is the most common choice. If you want to add things that do not have articles to the list, or add some structure, make it a set index. Aymatth2 (talk) 18:11, 18 January 2022 (UTC)
About 200 infoboxes have a |native_name= parameter, sometimes accompanied by a |native_name_lang= parameter. There include widely used infoboxes such as {{infobox settlement}}, {{infobox person}} and {{infobox river}}. Validation and formatting is inconsistent, particularly when there is no |native_name_lang= parameter. Users struggle when there is more than one native name.
* {{lang|it|Repubblica dell'Isola delle Rose}}</small>}}
|native_name = {{native name|la|Regnum Hierosolymitanum}} {{native name|fro|Roiaume de Jherusalem}}
This has been discussed at Wikipedia talk:WikiProject Infoboxes#native name parameters, where the subject was brought up by Trappist the monk and comments were given by Ineffablebookkeeper, Gonnym, Moxy, MB and Jmcgnh. There was agreement that something should be done to make handling of native names more consistent across infoboxes and to improve validation. Trappist the monk has begun working on changes to a few of the infoboxes. This is to ask for comments in the correct approach from the broader community before we change a great many articles.
Two alternatives are described below, both of which would be implemented using standard code in all infoboxes that support |native_name=, with the validation and formatting code buried in templates such as {{native name}}, {{native name list}} or a new {{format native name}} so that global improvements can be made later. Aymatth2 (talk) 13:42, 16 January 2022 (UTC)
|native_name ={{native name list||tag1=lang|name1=name|tag2=lang|name2=name...}}
When rendering the result, display an error message if the |native_name= parameter does not appear to be correctly formatted
Alternative 2
The editor fills in the name and language in the infobox, which looks after formatting it. They may use a template for the more complex cases.
Add the |native_name_lang= parameter to those infoboxes that do not support it
|native_name =
|native_name_lang = <!-- 2–3 digit ISO code, e.g. de, fr -->
When rendering the result,
If |native_name_lang= has been specified, render {{native name|{{{native_name_lang}}}|{{{native_name}}} }}
Check for unlikely characters in {{{native_name}}} such as "(" or ":" and place the article in a hidden error category if found.
Otherwise render {{{native_name}}}, which the editor may have formatted using {{native name}} or {{native name list}}
Check that the rendered name appears to be correctly formatted using {{native name checker}}, and place the article in a hidden error category if not
Comments?
ALT2 is going to be easier for new editors to understand, some of whom have no problem "filling out the form" with an infobox, but struggle with other types of template. Aymatth2 (talk) 14:22, 16 January 2022 (UTC)
I'd like to see that alt2 can actually handle all incorrect usages with how you've described it to be working. Gonnym (talk) 14:59, 16 January 2022 (UTC)
@Gonnym: Neither ALT1 not ALT2 can detect all incorrect usages. With both, the validation / rendering logic will invoke {{native name checker}} to see if the result looks like a valid native name, but could be fooled by an ingenious editor. I doubt that anyone will try to fool it, though. Aymatth2 (talk) 15:12, 16 January 2022 (UTC)
Currently alt1 is using the system TTM has done with Template:Native name checker which works. You are proposing alt2 which has no backend validation (at least none that you presented). If the option you present is between a system that works and a system that does not exist, then I'll have to go with the one that works. Gonnym (talk) 15:17, 16 January 2022 (UTC)
@Gonnym: By "Check that the rendered name appears to be correctly formatted" I meant "invoke {{Native name checker}}". Both alternatives would have the same validation and formatting logic using existing templates/modules. But nothing can catch joke entries like {{native name|it|The Big Apple}}. Aymatth2 (talk) 15:32, 16 January 2022 (UTC)
The difference is that with ALT1 the editor is prompted for
| native_name = <!-- {{native name|<tag>|<name>}} or {{native name list |tag1=<tag>|name1=<name> |tag2=<tag>|name2=<name> ... }} -->
while with ALT2 they are prompted for
|native_name = |native_name_lang = <!-- 2–3 digit ISO code, e.g. de, fr -->
The ALT1 prompt may seem rather forbidding to a novice editor, while the ALT2 prompt is easier to follow (if they can work out what an ISO code is) and takes less typing. Also, there is no need to work through all the pages that use |native_name_lang= changing over to the new ALT1 style. Aymatth2 (talk) 16:46, 16 January 2022 (UTC)
I got involved in this topic because an editor asked for help. At this time the {{native name}} template accepts only a certain list of IETF language tags, while parameter |native_name_lang= accepts, among other things, a larger set of ISO codes, quite a few of which are not in the accepted list of IETF tags. Assuring that TTM's code would be at least as accommodating as |native_name_lang= would quiet my concerns about the latter going away, but so far the checker still states it is looking for IETF codes.
Given the need to allow for lists of names in different languages, ALT1 seems preferable to ALT2. I'd also prefer to see it as a scheme that encouraged systematically correct entries, putting aside worries about daunting novice editors. — jmcgnh(talk)(contribs)03:28, 17 January 2022 (UTC)
@Jmcgnh: Note that ALT2 is a superset of ALT1. That is,
an editor can code |native_name= using {{native name}} as with ALT1, and omit |native_name_lang=. They would use {{native name list}} for multiple languages.
or they can put text in |native_name= and an ISO code in |native_name_lang=, and the rendering logic will combine them using {{native name}}.
ALT2 does not sacrifice any rigor, since the same validations apply, but does help novice editors, and avoids the need for a mass conversion of articles that use templates like {{infobox settlement}} or {{infobox person}} and specify |native_name_lang=. Aymatth2 (talk) 12:44, 17 January 2022 (UTC)
At this time the {{native name}} template accepts only a certain list of IETF language tags, while parameter |native_name_lang= accepts, among other things, a larger set of ISO codes, quite a few of which are not in the accepted list of IETF tags. That is just not true. I thought that I answered the question at Talk:Mount Washington § Infobox help. There really is no definitive list of IETF tags because they are assembled from ISO 639-1, -2-, -3 language subtags, ISO 15924 script subtags, ISO 3166-1 alpha-2 region subtags, variant subtags defined by IANA, unicode subtags defined by Unicode, and here at en.wiki, private-use tags defined by us. How these are composited into a single IETF tag is specified in BCP 47. So:
{{native name}} accepts most properly formed IETF tags; unicode subtags are not supported
{{native name}} accepts all ISO 639-1, -2, -3 tags (even deprecated tags)
caveat lector: some of the language specification tags defined by MediaWiki are not valid IETF tags so those will not be supported in {{native name}}
I spend a couple hours every day cleaning up new errors in several infoboxes and see all sorts of incorrect changes. Editors commonly add images with [[File:imagename]] syntax even when the template says "|image = <!-- filename only, no "File:" or "Image:" prefix, and no enclosing [[brackets]] --> - and I don't mean the template documentation, I mean the actual article includes the instructions. I see commented instructions like <!-- use {{Birth date and age|YYYY|MM|DD}} -->, edited where the birth date is added within the comment in place of "YYYY/MM/DD" (I don't know what they think when their edit doesn't show up in the article). I'm quite confident if a template has |native_name=, we will get lots of cases of plain text (regardless of any documentation) put into that parameter and no indication of what the language is. I definitely supports TTMs efforts to improve native name handling, and believe there should be consistency across infoboxes. ALT2 provides a mechanism for handling multiple names while still making easy for novices to enter the name and language without templates. Even if they don't use a valid language code, something is better than nothing. MB04:02, 17 January 2022 (UTC)
We have examples of infoboxes that do not have a |native_name_lang= parameter such as {{infobox French commune}} (where native language may be br, oc, co, de, etc.) and of templates that have the parameter such as {{infobox settlement}}. It would be interesting to check the percentage of malformed native names with these different templates. If the quality is significantly better for the infoboxes with a |native_name_lang= parameter, it is surely wrong to remove it. Aymatth2 (talk) 15:30, 17 January 2022 (UTC)
Tentative recap of comments
Aymatth2 favours ALT2 on the grounds that it is easier for novice editors, requires less typing for experienced editors, and eliminates the need for mass conversion of articles that specify |native_name_lang= in an infobox.
Gonnym was concerned that ALT2 would not implement the full set of validations. As explained, it uses the same validation and formatting logic as ALT1
Jmcgnh felt that ALT1 was preferable as supporting multiple names. It was pointed out that ALT2 supports multiple names in the same way as ALT1
Jmcgnh also noted past concerns about language code support. These would apply to ALT1 and ALT2, but Trappist the monk points out they have been resolved
MB noted the difficulty novices have with infoboxes, and felt ALT2 would be easier, and would encourage novices to enter something in the |native_name_lang= field, even if it was not a correct code
There seem to be no strong feelings that supporting |native_name_lang= will cause more problems than it solves, and two out of four are very positive about it, so at this stage it seems that we should go ahead with ALT2. Aymatth2 (talk) 18:13, 19 January 2022 (UTC)
Expanded definition
Based on the comments above, following is an expanded version of the proposed approach:
All infoboxes that accept native name, including {{infobox settlement}} and {{infobox person}} will be modified to use the new parameters and formatting / validation logic
The template's usage notes will show:
|native_name = <!-- If more than one, use {{native name list}} -->
|native_name_lang = <!-- Use ISO code, e.g. "fr" for French -->
The standard rendering logic will look something like
|label5 = Native name |data5 = {{native name checker |{{{native_name}}} |{{{native_name_lang}}} |errordisp=cat |multi=yes}}
Otherwise, {{native name checker}} will check the syntax of {{{native_name}}}, and then format using {{native name |{{{native_name_lang}}} |{{{native_name}}} }}. The syntax checks are to catch common problems like names coded as |native name=''San Lorenzo'' (Italian)
If |errordisp=cat, {{native name checker}} will present errors or warnings as (e.g.) [[Category:Native name contains unusual characters]]. This is for use during the transition, to avoid flooding existing articles with red error messages. Once the bulk of the errors in the hidden categories have been cleared, the template can be changed to |errordisp=strict. {{native name checker}} will now generate red error messages like Saint Laurent(French), so editors see their mistake at once.
The parameter |multi=no may be needed to suppress support of multiple names in some infoboxes. {{Infobox settlement}} defines |native_name= as "Name in the official local language, if different from name, and if not English." This seems to imply that only one official name is allowed.
Before starting to convert articles using the major infoboxes, we should confirm on their talk pages that the overall approach is acceptable, and specifically that multiple names are allowed.
Support this proposal. However, I don't think we need to ever disallow multiple native names. The comment in IB settlement is contradicted with If there is more than one native name..., so I don't think there is a conscious statement here that "only one official name is allowed". If there is an exception in some other IB, which I think is unlikely, deal with it later. MB18:40, 19 January 2022 (UTC)
Fair enough. But {{Infobox settlement}} does not seem to do anything with |native_name_lang= apart from putting the name in a <div> with |lang="{{{native_name_lang}}}", which presumably has something to do with non-Latin characters. So we should check with the experts on {{Infobox settlement}} to make sure they are o.k. with the change in appearance. Aymatth2 (talk) 19:09, 19 January 2022 (UTC)
I was wanting help on the copyright of the Baldwin engine drawings because i am going to vectorize them and would like to be able to make them free to all
Mohs hardness, Neel temperature, quantum physics, and curie temperature
Hi. I was wondering if you could add the mohs hardness ratings of all the metals? There's a conspiracy to replace mohs hardness scale with other scales in order to sell the testing machine.
Also, please recreate the neels temperature page. (I think Linus Torvalds was being extra special again).
Add seebeck coefficient to all the metals' wiki page.
Err... Add curie temp or Neel temp too.
Redirect quantum physics pages to relevant particle physics/nuclear physics pages.
And niobium has been removed from the curie temperature page? It was the most significant metal on that page because of super conductors.
Not sure if we should be splitting the discussion from there to here, but I'll go ahead and repeat what I just wrote there: I agreed with Rusalkii that instead of having a bot outright decline unsourced submissions, let's have the bot list such submissions on a page so that human reviewers can more easily identify them to be declined. Mz7 (talk) 10:11, 23 January 2022 (UTC)
@SD0001: That's very cool! I'd certainly support making that warning message a little bolder, though (maybe make it orange or red, not just yellow, and add a box). {{u|Sdkb}}talk06:30, 24 January 2022 (UTC)
Non-diffused category checker
Large categories are often broken down into smaller ones. The parent category may be "diffused", meaning that articles are held only in the child categories, or "undiffused", meaning that articles are held both in the parent category and in one or more of the child categories. With undiffused categories there is always the possibility that an article may be added to a child category but not to the parent, or vice-versa. To help detect these problems, which can then be easily fixed, I have mocked up {{Parent cat}} a category-heading template that can hold links to canned PetScan queries. To avoid clutter, it can also take the functions of the {{cat main}} and {{All included}} templates.
The first list is mainly useful if the template is put at the top of a diffused category, where it could replace a {{Category diffuse}} template. In theory, the query results should be exactly the same as the contents if the parent category were not diffused. For a diffused category such as Category:Rivers of England it would look like:
This is a diffused parent category for categories like Category:Rivers of Bedfordshire. It should not hold pages that belong in the county-level categories, but may hold other pages such as lists.
For non-diffused categories, the "child not in parent" and "parent not in child" lists can be used by any editor who wants to do category maintenance. They may not know how write PetScan queries, but they can review and correct anomalies, an ongoing process.
Seems like a good idea to me. Readers who are unsure if they are really looking at every article subcategorized under a parent category, could use the link to help find what they're looking for. For editors like me, who hadn't heard of the tool until recently, we can now easily use the tool to help find items missing from categories they should belong to (or remove ones that don't). DB1729 (talk) 15:04, 22 January 2022 (UTC)
Good idea. We could even have a bot to populate the parent from the children (are sort codes a problem?), though probably not vice versa. Can we improve the wording to clarify that pages like Class A Wild Trout Waters belong in the parent category only? Populated with the same pages as the child categories might be misinterpreted to imply ...and no other pages. Certes (talk) 15:13, 22 January 2022 (UTC)
I have tweaked the wording to "It should hold all the pages in the child categories, and may hold other pages such as lists." A bot to add the parent category to all child pages seems possible. I don't see a sort problem if the child pages use DEFAULTSORT... but a bot is a different discussion. Aymatth2 (talk) 15:58, 22 January 2022 (UTC)
Aymatth2. In my experience, many pages in the types of categories we've mentioned, do not use DEFAULTSORT because many are custom sorted differently for each category they're in. List of rivers of California is an interesting example. Despite it (redundantly) containing a DEFAULTSORT, every category it is in has a custom sortkey overriding the default.
I suppose there are problems like Thames River / River Thames. If a bot were developed, it would have to decide on an approach. Aymatth2 (talk) 17:18, 22 January 2022 (UTC)
Also just to clarify, I'm understanding it would replace the existing {{All included}} or {{Category diffuse}} template banners on the category pages. This change will be done on large categories only, correct? How large? Is there a threshold you had in mind? DB1729 (talk) 16:53, 22 January 2022 (UTC)
I would see {{Parent cat}} replacing {{All included}} or {{Category diffuse}} to avoid clutter, but only where someone has taken the time to write the queries. They are mostly simple enough though. I did not see any particular lower or upper size limit. I suppose the larger the parent category the more likely it is to drift out of sync. With Category:Rivers of the United States (which is diffused) PetScan returns only the first 10,000 pages to the browser, although it will generate a complete file for download. Aymatth2 (talk) 17:18, 22 January 2022 (UTC)
I'm not involved enough with categories to weigh in on the details here, but we should absolutely have an automated system (probably a bot) handling category diffusion. It doesn't seem very complicated from a technical standpoint.
I'm glad to see that the discussion above is taking into account that category pages are (at least ostensibly) reader-facing. {{u|Sdkb}}talk06:23, 24 January 2022 (UTC)
A version of PetScan could present results of the "all child" query in a format identical to Wikipedia. Perhaps a template like {{unite|metacategory}} could automatically generate the list of child pages when the parent category is displayed, or when the reader clicks on a Show/hide sub-pages button, which would solve the maintenance problem. This may be a small step in that direction. Aymatth2 (talk) 13:40, 24 January 2022 (UTC)
Request for comment on template protection
Should the template protection cannot be applied to articles? Articles are rarely or almost never transcluded into another articles. Vitaium (talk) 01:15, 26 January 2022 (UTC)
Comment – Parts of articles are increasingly transcluded into other articles using {{Excerpt}} (examples). However, that doesn't make template protection appropriate, as they are still articles rather than templates. Transcluded text typically appears in only a few articles, whereas template protection is typically applied to pages with thousands of transclusions, such as Template:Excerpt itself. Certes (talk) 01:29, 26 January 2022 (UTC)
If an article were excerpted into enough articles that it would qualify for template protection if it were a template, then it should be template protected. But I fail to see how that situation could possibly occur. Let's close this speculative RfC and cross that bridge when we get to it. * Pppery *it has begun...02:15, 26 January 2022 (UTC)
@Vitaium: there are like three of them, and that's probably just due to misclicks. I really don't see why this needs an RfC, so I'm going to remove the RfC tag as none of the steps that are usually taken prior to a policy-changing RfC have been followed here. Elli (talk | contribs) 02:36, 26 January 2022 (UTC)
I noticed on Watertown (city), New York that after archiving all the references the reference section looks like a mess, how about there should be a tool where reference sections remove the Retrieved on and Archived on text, and only shows "Source name, Source Publisher. Archive."instead of this. It sounds like it might be pretty easy to make, just set all values with the name "archive-date" and "access-date" to hidden, right?Lallint⟫⟫⟫Talk23:37, 18 January 2022 (UTC)
No. This information (assuming it is entered correctly & justifiably) has semantic significance in verification. Both online sources and their online archives may be subject to change. These values are the only indicators of the consulted versions in Wikipedia's Citation System 1/2, and they should be evident. 68.173.76.118 (talk) 12:50, 19 January 2022 (UTC)
Wouldn’t it be possible to retain that semantic information but not display it, at least in certain circumstances? Example: certain site themes (e.g. mobile), or display via JS/CSS as a tooltip type display (similar to ‘efn’ popups?) Jim Grisham (talk) 12:47, 27 January 2022 (UTC)
Should the link to Wikipedia policies and guidelines in Template:Db-notice be changed?
(Original discussion here) Should the link to Wikipedia policies and guidelines be changed? Imagine this: You have joined Wikipedia a few hours ago. Your draft is deleted, for being a "test page" (or any other CSD criteria), and the only help available is this giant list.
Nice catch. I’ve been a casual editor for 15+ years now, and I can still get lost in the policies / docs / essays trying to find things… can’t even imagine coming in from scratch trying to get bearings.
(One of these days, I might make good on my threat to write a proposal for a global draft / clipping namespace, not tied to any one user and with no deletion time limit… a safe incubator for anonymous collaboration, like in the old days - it could be filtered out of normal maintenance tooling so as to not affect backlog, and maybe avert some issues like this as well)
Okay, a few actual ideas / thoughts:
maybe it could point less to a single link / page, but more of a tree or a FAQ-type document / set of documents.
Something like a chat bot flow, perhaps, (but less reductive)?
It’s probably worth asking someone who’s never edited Wikipedia before what questions they might have in this sort of situation… perhaps a retired middle-school language teacher, then a middle schooler herself.
Perhaps we could survey new editors after their first 1, 5, 10 edits, and after deletions?
(but not via User:Talk page templates or notifications, please - that’s another learning curve all together!)
An infographic or graphic novel policy introduction?
(Finally, it shouldn’t need to be said, but experienced Wikipedia editors are probably poorly-suited for this kind of task.)
Hi there. I made an infobox for alloys on Czech Wikipedia as requested there. What I found out is that a Wikidata link has been created and Czech Wikipedia is currently the only one that contains this infobox. Since I know English well enough to communicate and write, I decided that I'd like to translate the infobox to English. I normally translate articles from English Wikipedia to Czech, but I might as well expand this and translate also some templates, and even reverse the process - translate from Czech to English. It is difficult, not gonna lie, I had to double check every translation and had to actually look for exact translations. Since the infobox uses wikilinks to articles that describe what the field is about, I figured out that I might use the Wikidata links to my advantage. Anyway, the infobox is currently in my sandbox, currently lacks documentation, but my question is that if I should actually continue in making the infobox, if it is actually needed. It is used over on Czech Wikipedia, so I figured I would transfer it into English Wikipedia as well, properly translate it, and see. Because English comes in two major forms (British and American), I made a dual parameter that is used in a single one (with American variant being preferred one), you can even see it in the source code if you click Edit.
What I hereby propose is take a look at it, see for yourself, maybe suggest some improvements (maybe colouring would like to improve, overall styling, etc.), and decide wether this infobox is worth the inclusion in English Wikipedia. If not, I can simply remove the content in it and archive the page. — Polda18 (talk) 18:01, 31 January 2022 (UTC)
I looked at it, and according to link for Czech Wikipedia counterpart, it is used mainly for chemical compounds. An alloy isn't actually a chemical compound, it is mixture of different chemical elements or compounds, typically metals. For example Bronze is an alloy of Copper and Tin for the most part. Copper and Tin do not actually form a chemical compound together, they're still forming standalone structures, it's just it's a mixture of microscopic metal crystals of both types giving it the properties of Bronze. — Polda18 (talk) 07:47, 1 February 2022 (UTC)
I think that a vast majority of en-wiki infoboxes don't have colors for the labels & data, though a coloring for headings exist. I don't know if there's some kind of guideline on it or not. Otherwise, it looks really good & useful. ---CX Zoom(he/him)(let's talk|contribs)20:36, 31 January 2022 (UTC)
I can remove the colouring of labels and data (we do occasionally use them on Czech Wikipedia in some infoboxes, not all though), but I'd like to keep the colouring on sections heading and the infobox header itself. — Polda18 (talk) 07:37, 1 February 2022 (UTC)
Proposal to Change The Romanization of North Korean language in Wikipedia
Even though both Koreas have had their own romanization system, why do we still use the old romanization for North Korean when we use the new revised romanization for South Korean?펑홍한talk04:50, 1 February 2022 (UTC)
After starring at a particularly bright and shiny wiki (Hodge conjecture), it struck me that WP needs a dark mode, and maybe a couple more 'easy-on-the-eye' themes, e.g. research lighting, old-fashioned (mood setting) etc..
I find it absolutely astounding that anyone finds these "dark" or "solarized" modes to be "easy on the eyes". I find it nearly impossible to make out the text on those. --User:Khajidha (talk) (contributions) 03:26, 3 February 2022 (UTC)
Edit requests with canned "please get consensus first" responses are unhelpful to newbs
Most people making edit requests are inexperienced. If we're offering people a chance to make an edit request, responding to them with 'get consensus first' is unhelpful. They have no idea what that's even asking for, and in many cases we know it, and also that they probably aren't even coming back. IMO that response is, I'm sure unintentionally, just fobbing people off. We should be offering them instead a 'make a suggested edit' form that opens a discussion on the edit they're suggesting. This editor is correct. Courtesy ping to @OrewaTel. valereee (talk) 22:15, 24 January 2022 (UTC)
Wrong place or not, I agree. The issue is that the edit request queue is set up so it's supposed to be used only as a way to action resolved matters, not to prompt discussion. Maybe we could add a stage to the process that instead summons people to the discussion, and then if there's agreement, flip a parameter to turn it into a formal request in the queue. {{u|Sdkb}}talk05:33, 25 January 2022 (UTC)
Well, as someone who works the ER queue frequently, it depends what they are asking for. The ER process serves as an important check on the protection system. ER's that are not controversial (which are many of them) don't normally need a showing of consensus first. So perhaps updating the directions to give better guidance would suffice? — xaosfluxTalk11:39, 25 January 2022 (UTC)
The requested edit could have been made by any editor with ten edits. Answering an edit request shouldn't be gatekeeping. Answering an edit request should be, "If this edit had been boldly made by someone with 10,000 edits, would I even question it? Done." valereee (talk) 11:58, 25 January 2022 (UTC)
@Valereee: that's what I was saying - for uncontroversial edits (e.g. not an edit about content that is currently in dispute that led to the current protection) I assume the edit request is step one of WP:BRD and will make it, if in reviewing I think something is bad about it that I would have reverted on review, I decline and let the requester know that they are now at step three in BRD. But if the edit is about content in current dispute, that means that the material should already be in step 3 of BRD and a showing of consensus should accompany the immediate edit request. — xaosfluxTalk14:26, 25 January 2022 (UTC)
Specifically the discussion at Wikipedia talk:Edit requests/Archive 1#Requiring verbatim suggestions where there was discussion about elaborating on the templates used for answers. In the George Floyd instance, Also a second "needs consensus" reply that specifically states The subject of this article is controversial and content may be in dispute. As such this edit request will require consensus before being made. Or something along those lines. There's quite a few I've closed as needs consensus because I know the article is controversial and I don't think an edit request patroller who likely has no meta-knowledge of the article should be on the hook for the contents of the edit. would apply. Expecting patrollers to know all the discussions on the lead of an incredibly contentious article is unrealistic. The talk page watchers were still able to respond back to the edit request, and it appears there was no consensus for inclusion. Here's one I closed today, and added the mention that it would be a contentious change. ScottishFinnishRadish (talk) 15:22, 25 January 2022 (UTC)
Wow, this is actually tangential to something that came up a while back, I think at this very article. If an article is currently being actively edited and has hundreds of watchers, should patrollers even be patrolling that talk page? SFR, you answered that edit request ten minutes after it was made. There are nearly 300 watchers, over 50 of whom visited recent edits. Why not let someone who is familiar with the page respond to that request? Pinging EEng, with whom I discussed this at least a year ago. valereee (talk) 15:28, 25 January 2022 (UTC)
Would there have been a different outcome? Did my closing prevent any of the 300 talk page watchers from responding, or implementing the edit on their own? It didn't prevent them from discussing it, and establishing there was no consensus. It was poorly written, per Cullen328, If I am correct, then I oppose this proposed change, since that three word phrase "his dying words" already appears in the lead section. Once is OK but twice comes off as hackneyed and clichéd.
If a patroller reads an edit request, and believes that it's not an improvement, is that enough to close as "establish consensus?" Additionally, the template instructions explicitly state to close edit requests when there is discussion on-going, or the request is waiting on editor input. ScottishFinnishRadish (talk) 15:36, 25 January 2022 (UTC)
I've been completing COI edit requests on-and-off for about a year. I think the theory when edit request was created was that an editor would make a request, then other editors would discuss the edit request like an RFC. In reality, there's over 150 requests in the queue, some from almost a year ago, so now one editor is determining if the request is implemented. I don't think editors should decline any edit request as "get consensus first" because most edit requests are not going to generate discussion. Instead, editors evaluating requests should decide if they want to add it themselves or if they want to reject it for not fulfilling Wiki-policy and guidelines. If a request is closed with "get consensus first", then the closure should be reverted and another editor can evaluate the request. Z1720 (talk) 15:20, 25 January 2022 (UTC)
For the semi and extended queues, the older ones likely need some specialized knowledge to verify, or a fair amount of research to verify. Talk:Rus' people#editsemiprotected and [Talk:Bioidentical hormone replacement therapy#editsemiprotected] are good examples of aging ones. Every week or two I try to go through all of the aging ones that will take some time, and do the research necessary to close them. Or, if they deal with a rewrite or prose change, I'll often close them as consensus needed at that time, because after a week, if no one has made the edit then there is an implicit consensus against the change. ScottishFinnishRadish (talk) 15:42, 25 January 2022 (UTC)
Well, we can't really know, because if someone gets to an edit and sees it's been handled by an experienced editor, how closely do they even check the requested edit? In this case it took a bit of reading and comparing, because the editor had included too much of the content. I skipped reading it myself when I first saw it. It wasn't until just now that I bothered to actually read and respond. ETA: Not sure I agree that after a week there's an implicit consensus against, but if that's settled policy, why not wait a week to respond to the ER? valereee (talk) 16:20, 25 January 2022 (UTC)
The one week thing is not settled consensus, it's just generally how I handle it. There's actually not much "settled consensus" as far as handling edit requests. I operate off the assumption that the templates used for closes, and the wording of the edit request templates themselves, enjoy consensus.
SFR, just to be clear, I am not intending a criticism of your work. I'm questioning our standard operating procedure on this. valereee (talk) 16:24, 25 January 2022 (UTC)
No criticism taken. I think that expanding the templates used for responses could go a long way to help. If the George Floyd request had been closed as The subject of this article is controversial and content may be in dispute. As such this edit request will require consensus before being made. with a yellow icon, instead of red, I don't think we'd even be having this conversation. ScottishFinnishRadish (talk) 16:37, 25 January 2022 (UTC)
@Z1720: - think this varies by queue, the process for COI may need to vary from the FPROT queue (I don't work COI queue - but am all over FPROT queue). — xaosfluxTalk16:32, 25 January 2022 (UTC)
I agree with this general concern but don't have any immediate thoughts on how to fix it. But I support doing something KevinL (aka L235·t·c) 16:43, 25 January 2022 (UTC)
I think an expanded amount of templated responses would be the easiest to address some of the concerns. I'd like to know how often there are closes that anyone objects to, as well. I'd hate to see us come up with wait times and such around edit requests for what amounts to less than 5% of closures. ScottishFinnishRadish (talk) 16:51, 25 January 2022 (UTC)
The change I'd like to see in the Edit Request process is to stop "declining" edit requests that need more discussion and start "rescheduling" them. A desire for an empty queue can result in rejecting viable edit requests. Perhaps whatever code puts AFD pages into the correct date category after 7 days' wait could be adapted to this purpose. WhatamIdoing (talk) 23:44, 25 January 2022 (UTC)
As it stands, the edit request template instructs editors to close the request while waiting for editor input. From the last discussion I took part in dealing with edit requests there seemed to be a reasonable consensus that edit requests are specifically for edits that are ready to be made, rather than for discussion. Regular talk page discussion doesn't need an edit request template.
I do not think that's sufficient. We need to actively ask people not to rush to answer edit requests at pages they're unfamiliar with. There is no reason any edit request needs to be answered in five minutes by someone who is not familiar with that page. After a week, sure. But it's actually unhelpful for people not familiar with a page that has 500 watchers, 300 of whom have visited recent edits, to answer edit requests at that page with a canned edit request. valereee (talk) 21:03, 3 February 2022 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Should we prevent new/unregistered users from editing featured article and featured lists? Because I see in the last month, many featured articles were vandalised by newcomers and IPs. Vitaium (talk) 23:54, 3 February 2022 (UTC)
Oppose vandalism is usually swiftly reverted on such articles, as they tend to have a high number of pagewatchers, and if if not, WP:RC has really good vandalism filters now, so they're much more detectable. This is a non-issue. Curbon7 (talk) 02:07, 4 February 2022 (UTC)
Oppose: Wikipedia prides itself on being editable by anyone. How would it look if our most important and highest quality articles didn't even stick to the core of Wikipedia? bop34 • talk • contribs03:23, 4 February 2022 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Articles for improvement would be given the semi-active tag if it wasn't a vital WikiProject, why isn't it shown on the main page or somewhere else that will give it higher traffic. I only heard about it after 5 months of being on wikipedia. Why not link it on the main page or on Help:Introduction to Wikipedia? This would allow for more vital articles to have more edits and finally put this damn thing about how we ignore vital articles to rest. Lallint⟫⟫⟫Talk23:45, 2 February 2022 (UTC)
Good idea. An argument against it might be the front page is not for highlighting problems with Wikipedia, or to pull readers into helping. But why not? The front page might be used as a recruitment tool to encourage fence sitters to become editing heroes. Granted such articles will need to be watched since new users will do strange things, but the project could have editors willing to adopt articles, like lifeguards. -- GreenC00:39, 3 February 2022 (UTC)
Some of these are just ridiculous, like look at this:
The 2nd, 4th and last one especially, I'm surprised Genus isn't already a GA or FA. These are incredibly important to daily life and yet they are complete crap. Lallint⟫⟫⟫Talk01:24, 3 February 2022 (UTC)
Sure it was, 8 years ago. Can't we try again? It doesn't even have to be the main page, why not Wikipedia:Cleanup, or Wikipedia:To-do list? Why do you always shoot me down whenever I say something? Lallint⟫⟫⟫Talk17:09, 3 February 2022 (UTC)
Wikipedia is not a Gerontocracy, so the amount of time I've been editing is irrelevant. And it's not the case that [I] always shoot [you] down whenever [you] say something, instead that you keep doing things that come to my attention. Nor am I really shooting you down here, as my comment was purely factual and did not imply anything about my position on this proposal. * Pppery *it has begun...17:29, 3 February 2022 (UTC)
You know, Lallint, proposing a change to the Main Page and immediately personalizing the dispute with the first person to disagree is a pretty generous interpretation of what Rosguill intended by Block converted to partial block to allow for participation in RfD. Or, maybe it isn't. I wouldn't want to speak for them. But either way you should not be editing disruptively while still actively blocked for disruptive editing. -- Tamzin[cetacean needed] (she/they)17:33, 3 February 2022 (UTC)
I don't think years editing matters to much. I do agree that it was 8 years ago and things can change in 8 years, so it would be logical to at least try again (possibly do something a bit different). It appears it failed 8 years ago because the articles just weren't being edited. From what I"m reading it's because there wasn't anything encouraging the articles to be edited. Maybe awarding barnstars to users who help improve the articles would help (similar to the back log editing drives done by some WikiProjects)? The editing drives some WikiProjects do seem to be successful so maybe we could try and figure out what makes them successful and implement that into this. ― Blaze WolfTalkBlaze Wolf#654517:39, 3 February 2022 (UTC)
Also, the reason some people always seem to reply when you say something might just be coincidence, and also possibly the fact that you're currently partially blocked and are wanting to make sure you aren't doing anything to violate your block. ― Blaze WolfTalkBlaze Wolf#654517:40, 3 February 2022 (UTC)
Don't mean to support people who agree with me and not support people who don't like some freedom of speech advocating little b-boy, but this guy logics. Lallint⟫⟫⟫Talk17:43, 3 February 2022 (UTC)
I agree with 420 Blaze Wolf above, perhaps we could use a positive reward system for doing good on one of those pages instead of rollbacking every edit they made after they accidentally made a typo then indefinitely banning them and accusing everyone with more than 2 letters similar to their name as a sockpuppet Lallint⟫⟫⟫Talk17:53, 3 February 2022 (UTC)
now that I think about somebody's probably actively refreshing this thread with a bag of popcorn waiting for something to happen again Lallint⟫⟫⟫Talk17:55, 3 February 2022 (UTC)
Well, barnstars appear to be rewards for the editing drives some WikiProjects do and those appear to be successful. ― Blaze WolfTalkBlaze Wolf#654518:19, 3 February 2022 (UTC)
That would be a barnstar we could give users. I see your point in giving new users a reason to edit. It's kinda hard to give new users a reason to edit because, well, they're new users. And as I"m thinking about this a bit more, if it were on the main page it might just attract vandals to those articles instead of new users wanting to improve them. Maybe it could be integrated into the new user homepage? I'm trying to think of some reward that would appeal to new users. ― Blaze WolfTalkBlaze Wolf#654518:35, 3 February 2022 (UTC)
I think in order to come up with a reward for new users, we would have to figure out what appeals to constructive new users the most and causes them to stay. Obviously we can't just make it "If you help edit these pages you won't get blocked!" because if it's a vandal then they will get blocked and that will be shown to be a false statement. ― Blaze WolfTalkBlaze Wolf#654518:39, 3 February 2022 (UTC)
Whenever someone makes a mistake (such as a typo) I am usually just able to revert with the edit summary of it being in good faith and with an explanation as to why I reverted (and we definitely don't accuse everyone with more than 2 letters similar to their name as a sock, or at least, we don't block them, one of my friends here on Wikipedia had an SPI made against them because someone managed to get a character that looked exactly like a letter in the english alphabet and replaced that letter with the character, making it look like it was the same username). Barnstars are a good idea, although a human should give them out because if it were a bot, then it would probably function like this: Bot sees user has made an edit to article on list, bot awards user barnstar. The bot can't check to see if the edit is constructive or not (or at least, not reliably. we could use something similar to ClueBot NG, however there are false negatives and awarding a user for bad behavior isn't all that constructive) so if a human were to award the barnstars it could be a good system. ― Blaze WolfTalkBlaze Wolf#654517:59, 3 February 2022 (UTC)
When I first read this idea, my initial reaction was that I rather liked it. However, I can see the following problem. Wikipedia: Main Page is probably one of the most viewed pages in the encyclopaedia (indeed, if you just Google "Wikipedia", you will instantly be taken to the Main Page) and if the first thing that one reads on the Main Page is that there are articles needing improvement, it may put readers off the Wikipedia project. I guess that what I am saying is that there could be problems of putting "Articles for improvement" on a page with too much traffic. That said, tonight I looked at the category called "Articles needing improvement from the Bioguide" and had a look at two articles in this category - that on James Budd and that on Henry P. Haun. It was not clear from these articles in themselves that they needed improvement, that was just mentioned on their talk pages. I agree that we should place notices that articles need improvement in more prominent positions, so how about having a tag at the top of the article saying it needs improvement, just below its title? The article on James Budd is headed by a tag saying that its lead may not summarize its key points adequately. If it were also heading by a tag saying that it needs improvement, that may make more Wikipedians aware of how it needs attention.
The main page has an "Other areas of Wikipedia" section with links to editor-facing areas such as the Teahouse. That might be a good place to link to a list of articles for improvement. Certes (talk) 23:43, 4 February 2022 (UTC)
Frequency of Changes to Wikipedia Articles
I would like to suggest a metric for science and math articles on how likely a page is to change.
Many fields in mathematics such as number theory and geometry are not likely to change over time even as the content and presentation and clarity and layout of the article is improved.
For example, ellipses will mostly be the same geometrically and so some parts of the article will be less likely to change.
I think its good that articles on developing events include disclaimers on the current status of the article but think it would be helpful to include an opposite notice that for example Maxwell's Equations is invariant.
ScientistBuilder (talk) 02:23, 5 February 2022 (UTC)
This is interesting, but the way I understand it, you seem to mean that the source information upon which an article is based is not likely to change, not the article itself. I don't know if such a metric is entirely pertinent or relevant to Wikipedia. Current events have very fluid verifiability characteristics, and the warning is relevant. If such a metric is applicable and desirable it should apply to the article as a whole. If applied to parts of articles would probably be too cumbersome for editors and confusing for readers. And first, is it so? Something like "A's equation" obviously is set for posterity, and there is no need to proclaim the fact. One may add to it, but then it is no longer A's equation, it is "B's enhancement of A's equation". However the viability/applicability of any equation may change. Perhaps after the next hypothesis and its related experimentation. 65.88.88.71 (talk) 16:20, 5 February 2022 (UTC)
Wikipedia is a work in progress and most articles on number theory and geometry are incomplete, contain errors or misleading implications, are suboptimally comprehensible to laypeople, and could be re-organised or give a different balance of subtopic coverage to more properly represent the research area. A page is likely to change if an editor becomes interested in it, and unlikely to change if editors are not. There are trends that can create interest: for instance, news coverage, sudden social media interest or a major update to the topic. However, other trends are less predictable: if I bring 15 Black Mirror episodes to good article status then it becomes a lot more likely that the others will soon follow suit, but if I create a few Rick and Morty episode articles then I might stop with five still missing. I can think of one particular mathematician whose retirement from Wikipedia would dramatically decrease the likelihood of upcoming improvements to any particular mathematics article. — Bilorv (talk) 00:08, 6 February 2022 (UTC)
When I use Wikipedia to learn math and science topics I would like to know which subjects will be less likely to change in 10 years. For example, I want to work through all the articles on electromagnetism and am interested in which articles are not culture specific and more broadly applicable. ScientistBuilder (talk) 02:12, 8 February 2022 (UTC)
That seems like something that would be hard to determine. I don't think anyone here on Wikipedia can see into the future and know what topics aren't going to change for a while. ― Blaze WolfTalkBlaze Wolf#654520:53, 8 February 2022 (UTC)
Administrator note If removed, please clean up Wikipedia:Main_Page/styles.css as well. — xaosflux Talk 17:01, 26 October 2021 (UTC)
01:54, 27 October 2021 (UTC)
You are invited to join the discussion at Wikipedia:Village pump (technical) § System for handling possibly plural infobox parameters. {{u|Sdkb}} talk 22:30, 21 December 2021 (UTC)
Fundraising. The Wikimedia Foundation does not track the identity of IP addresses, so it doesn't know your age, income level or whether you donated in the past.
KevinL (aka L235 · t · c) 16:43, 25 January 2022 (UTC)
