I have an idea to (propose to) include a dedicated box on the Main Page for The Signpost similar to that Today's Featured List/Picture etc. I'm thinking it should displayed on the Main Page for 3/5 days after each issue is published; Any thoughts/suggestions regarding it would be appreciated..! Vestrian24Bio 12:24, 18 January 2026 (UTC)[reply]

The Signpost may be too inside baseball for such general-reader exposure. Randy Kryn (talk) 12:54, 18 January 2026 (UTC)[reply]

I agree with Randy. The Signpost is also facing a bit of heat right now regarding a "Special report" published by them where the author used an LLM "to help write and copyedit" the piece. I started a talk page discussion about this (Wikipedia talk:Wikipedia Signpost#LLM and the Signpost) to get some clarification. Some1 (talk) 13:13, 18 January 2026 (UTC)[reply]

Just for clarification's sake (for everyone else if not yours), that article was republished from Meta probably because it was previously already a major topic of discussion on Wikimedia-l and elsewhere. I haven't seen evidence that the Signpost knew AI was involved in writing/copyediting it, probably because that was buried on the Meta talk page, and they added a disclaimer to the article when they learned. That "bit of heat" is at best a flickering candle; give them a break. Ed ^{[talk] [OMT]} 15:57, 21 January 2026 (UTC)[reply]

I didn't select it, but I'm the one who did the final copyedit on it, albeit with a lot of what I did reverted (it happens). It was kind of late on in publication, and I thought it was incredibly dense, about twice or three times longer than it needed to be, and hard to follow, but I was under the impression this was brought over from one of the WMF publications, so reluctantly passed.

I could probably edit it into a more coherent document of half its size. But it wouldn't be the author's words at that point, and I'd be co-author of a paper I didn't believe in the argument of. But if we're only publishing articles that don't challenge readers, what are we doing as a newspaper? Sometimes, you just throw it out there, don't under any circumstances state that it's an official view of the Signpost, and let the debate go where it may.

That said, if I had known it was AI slop, I'd have suggested spiking it immediately. Adam Cuerden ^(talk)_{Has about 8.8% of all FPs.} 03:31, 22 January 2026 (UTC)[reply]

If you're unable to even see it's made with AI, then it's probably not AI "slop". The word has lost all meaning already and now just serves to signify overt AI aversion without ability for any nuance. I don't know if it was good that it has been featured mainly because it has some flaws like at least one misleading and possibly inaccurate data which I had asked about before signpost publication with basically no response. A reason to include it nevertheless is that has been read by very many and had substantial impact and got a lot of feedback by the community on its talk page – it could be reasonable to feature it for that reason alone but with proper warning notes at the top. People may be interested to read about essays have had major internal impact/audience. Prototyperspective (talk) 12:59, 22 January 2026 (UTC)[reply]

As I said, I personally found it barely readable and overly dense without ever saying much, while being technically gramatical. I didn't suspect it was AI because I didn't think there was any possibility someone would publish AI in what I thought was an official WMF publication. Once it came out it was AI, my first reaction was "Oh, that explains it", replacing my previous judgement of "corporate writing".

Humans and AI are both capable of writing in that rather awful corporate style. Humans and AI can write overblown claims of disaster. Humans and AI can get me to give up and say "this was already published, I'm just going to copyedit the opening and let the WMF have their place in this issue; it's not my job to speak for them."

Just because humans can also write corporate slop doesn't make it less slop. Adam Cuerden ^(talk)_{Has about 8.8% of all FPs.} 14:12, 22 January 2026 (UTC)[reply]

Thanks for explaining. I misread your comment thinking you were basically just referring to excessive length and maybe some grammatical issues here and there. Prototyperspective (talk) 14:24, 22 January 2026 (UTC)[reply]

Absolutely not while the Signpost is running chatbot output - David Gerard (talk) 14:17, 18 January 2026 (UTC)[reply]

I think if we had some more staff, this could be nice, but as it stands stuff is broken pretty often (e.g. some image gets deleted or some template breaks and then it's just cooked for a while until I can fix it). Currently, I am employed at a job that does not give me a lot of free time, so I cannot spend as much time as I think would be required to make it be consistently Main Page material (e.g. every article of every issue). jp×g🗯️ 14:18, 18 January 2026 (UTC)[reply]

Honestly, even when I do have enough time, the task of technical maintenance for the Signpost is so abjectly unpleasant that I would prefer to minimize my responsibilities as much as possible. For example, routine maintenance of templates and redirects will often be subjected to weeks-long bureaucratic review processes. A redirect that hasn't been wikilinked to anywhere since 2007 might be useful, according to somebody, so it needs to go through RfD and can't be CSDed and has to clog up the PrefixIndex until the RfD is processed; a template to black out text for crossword answers has the same name as a template that people got mad about in 2008, so even if it is hard-coded to be incapable of ever doing the thing that people got mad about the different template doing, it will be nominated for deletion, with a TfD notice breaking all the crosswords until it's resolved, et cetera. An image that we used in an article to discuss a hoax that was found and deleted gets nominated for deletion on Commons... for being a hoax. Somebody thinks an article from last year should have been titled something different, so they just edit the page to have a different title, which breaks a bunch of stuff in Module:Signpost. Oh, now some WMF guy slopped the copy in his essay that he submitted, so that's an ethical issue or something, because maybe the LLM was incorrect about what his own opinions were. Now some famous blogger is going to come call me a dipshit on the Village Pump over it. The whole tag system is busted because it was maintained entirely by force of Chris Troutman tagging the articles by hand every issue, and then he decided to go on some crazy tirade and get himself indeffed, so now the tag lists and the article series templates don't really work right, and even if we started tagging them again somebody still has to go through and add all of the articles from the last couple years. The archive pages and the main page still use totally different templates for some reason even though they basically do the same thing. There are about eight bajillion CSS classes that haven't been migrated into the master stylesheet, and also a bunch of them are just inline from random articles. Nobody knows what all the layout templates are or what they do. Also the commons delinker bot just fucks up old articles basically every day, and then you can't even go through to try to make a list of redlinked images to...

You get the point. jp×g🗯️ 14:35, 18 January 2026 (UTC)[reply]

Thank you for your service, @JPxG. You've made it so that the average reader doesn't realize any of this, which is most likely a double-edged sword. :) JuxtaposedJacob (talk) | :) | he/him | 17:58, 18 January 2026 (UTC)[reply]

No. It's internal and much of what's written would be incomprehensible to people outside the project. Also, there are serious unresolved issues regarding the use of LLMs in Signpost articles. It's antithetical to Wikipedia's mission to put LLM content in front of humans. Mackensen (talk) 16:49, 18 January 2026 (UTC)[reply]

Ignoring the current "scandal" about LLM use, this is not going to happen, because the Signpost is internal and of next to no interest to the reader. Cremastra (talk · contribs) 18:29, 18 January 2026 (UTC)[reply]

This is also hardly the first “scandal” to hit the publication; they’re a recurring feature and a leading cause of turnover in the editors contributing to the Signpost’s publication. It also generally fails to contact editors for comment when it covers topics they’re involved with, which is a failure to follow basic journalistic practices. This latest issue also included reporting on the Baltic birthplaces story that I believe seriously misrepresented the events in question; I haven’t made a big deal about it because the Signpost getting it wrong currently doesn’t really matter, any productive discussion towards resolving the actual underlying dispute will not come from such a complaint, and I don’t expect the Signpost to meet professional journalistic standards. If this were something we were advertising to all readers, however, I would have objected to its publication directly. TLDR, the signpost isn’t ready for prime time (even though I do think it’s worthwhile as an internal newsletter), and unless there’s a huge shift in the amount of editor effort and interest going into preparing its issues, it isn’t going to be ready in the foreseeable future. _signed, Rosguill ^talk 16:35, 21 January 2026 (UTC)[reply]

"It's antithetical to Wikipedia's mission to put LLM content in front of humans." No it's not Czarking0 (talk) 20:11, 10 February 2026 (UTC)[reply]

Feel free to elaborate. Cremastra (talk · contribs) 20:51, 10 February 2026 (UTC)[reply]

Strong oppose. The Signpost is a mixture of original reporting with opinion articles. It is not held to the same sourcing standards as mainspace articles. Putting it on the main page with our mainspace content will lead to confusion. Apocheir (talk) 19:47, 18 January 2026 (UTC)[reply]

The Signpost is a big part of why I signed up for Wikipedia in the first place! Having some more visible insight into the community would not be a bad idea per se, although putting The Signpost on the Main Page might be a bit much. And there is a bit of heat right now regarding the LLM generated article, too. MEN KISSING (she/they) T - C - Email me! 22:39, 18 January 2026 (UTC)[reply]

Support. The main page is boring and not engaging. There is only a very small chance the user is interested in what happens to be interested in the one daily featured article; the DIYs are mostly meaningless mundane trivia; featured pictures are nothing of importance to society and not really educational but just aesthetically pleasing which is a type of photos people see tons of online already; on this day is an arbitrary selection of events that happen to have occurred on the same day; the In the news tile is imo the only interesting changing content but gets just very rarely. Adding the signpost there would make it things more interesting.

Additionally, people would develop more interest and excitement about Wikipedia and become more interested in becoming a contributor themselves or a more active contributor if they've already signed up if they read the internal news there.

and of next to no interest to the reader. not true imo. Wikipedia news are or can be of interest to the Wikipedia reader. Wikipedia readers also read news about Wikipedia in external sources, there's no reason why they wouldn't be interested in some internal news as well. Additionally, a fraction of Wikipedia readers are contributors. An option would be to only display it for users who are logged in but it would I think probably be best to include at least some visible link to the latest issue also for logged-out users. Prototyperspective (talk) 18:02, 19 January 2026 (UTC)[reply]

The problem is many readers will expect a "Wikipedia newsletter" to be some kind of official newsletter about interesting facts and upcoming changes, not an internal newsletter about the latest WMF scandals. Cremastra (talk · contribs) 18:25, 19 January 2026 (UTC)[reply]

This doesn't sound like a good idea, far to much of signpost is opinion posting to give it any hint of official backing. -- LCU ActivelyDisinterested «@» °∆t° 19:29, 20 January 2026 (UTC)[reply]

I don't know why putting sth about the Signpost on the Main page would be interpreted by readers for it to have "official backing" but one could also clarify that it's nothing official at the top of the Signpost or at the top of whatever page is linked to. Prototyperspective (talk) 20:50, 20 January 2026 (UTC)[reply]

I'd rather it's opinions weren't on the main page at all, it's already pushed via notifications on the watchlist any interested editors can find it there. Even if labelled as unofficial it's presence on the main page would suggest it's articles have community support. -- LCU ActivelyDisinterested «@» °∆t° 21:32, 20 January 2026 (UTC)[reply]

No. The Signpost is mostly an internal project newsletter that thinks of itself as, and tries to be, a tabloid newspaper doing it's best to amplify minor scandals and division. The main page is focused on showcasing the best parts of the encyclopaedia to the readership, and The Signpost is neither part of the encyclopaedia nor our best work in project space. We do want to encourage readers to become editors, but not all readers - we want those who want to and can contribute collaboratively and collegiately. The Signpost will drive away many of those folk while attracting more of those looking for drama - the exact opposite of what the project needs. Thryduulf (talk) 16:06, 21 January 2026 (UTC)[reply]

What a silly pile of big ghastly allegations with no evidence whatsoever. jp×g🗯️ 20:59, 7 February 2026 (UTC)[reply]

Signpost is by wikipedians for wikipedians. It is of little interest to the general public Dronebogus (talk) 00:43, 31 January 2026 (UTC)[reply]

The Main page is read by a lot of Wikipedians. An idea would be to only show some tile / brief info with link about it for registered logged in users. The general public does read about Wikipedia from time to time as well and there's a bigger chance for that if they're browsing the WP Main page exploring around. Prototyperspective (talk) 19:45, 31 January 2026 (UTC)[reply]

I Support what has already been suggested here, a link in Template:Other areas of Wikipedia replacing the link to the obsolete portal space. Template:Other areas of Wikipedia/sandbox Guilherme Burn (talk) 22:02, 29 January 2026 (UTC)[reply]

I oppose that suggestion for two reasons, firstly all the reasons I oppose putting the signpost on the front page, secondly portals are not obsolete. Thryduulf (talk) 23:34, 29 January 2026 (UTC)[reply]

Can we reframe this? I urge contributors to remember the point of the idea lab is to be a brainstorming location. As noted at the top "Stalwart "Oppose" and "Support" comments generally have no place here." That is often challenging, because in many cases and this is a good example, it's easy to find reasons for outright rejection. However part of the point of brainstorming is to ask whether there is anything of value that could be reframed into something more acceptable. For example, MEN KISSING (talk · contribs) said "The Signpost is a big part of why I signed up for Wikipedia in the first place!". A potential reframe could be: Original: " put the signpost on the main page so it gets more exposure, " Reframe " the goal is more exposure; are there ways to accomplish this?" I'll also note the concern about the recent LLM issue, which arguably doesn't just make inclusion on the front page problematic, it might make more exposure in general problematic, but I would reframe that to say the LLM issue suggests "not now" rather than "absolutely not" S Philbrick(Talk) 21:43, 5 February 2026 (UTC)[reply]

To follow up on my own comment, I have no recollection of when I first encountered the signpost, but I'm guessing it was quite some time after my first edit. I would not want to see a link to the signpost included in welcome templates, as it is inside baseball, and that's too early, but what if we had a bot that monitored new accounts and when they reach some metric — time-based three months six months etc. or edit count based 1000 5000 whatever makes sense — the bot sends out a one time posted the talk page letting them know about the existence of the signpost. S Philbrick(Talk) 21:50, 5 February 2026 (UTC)[reply]

If we're doing something like that it should be based on project-space contributions, as almost nothing about the Signpost is relevant to editors who exclusively work on content. Those who spend any significant amount of time in the project space (for reasons other than their behaviour being discussed at noticeboards) are likely to have learned about it before we tell them anyway.

Also, "more exposure" isn't a useful goal in and of itself - What benefits to the project as a whole (i.e. not just The Signpost) would increased exposure bring? Is increased exposure to The Signpost the best way to achieve those benefits? If it were a wholesome "here's the best of Wikipedia this week, here are some projects you might be interested in, here's a look at a technical feature you know might know about" then the benefits would be obvious, but I'm not sure what benefits come from promoting a wannbe tabloid scandal rag? Thryduulf (talk) 00:35, 6 February 2026 (UTC)[reply]

I am curious what specific coverage you're noting here as "wannbe tabloid scandal rag" material, or if you are generally opposed to any coverage of internal discussions. jp×g🗯️ 20:48, 7 February 2026 (UTC)[reply]

Here's an example: Wikipedia:Wikipedia Signpost/2019-06-30/Special report. Some1 (talk) 22:42, 7 February 2026 (UTC)[reply]

That is from nearly 7 years ago. MEN KISSING (she/they) T - C - Email me! 23:16, 7 February 2026 (UTC)[reply]

Like for example, what if an article on a fiction book or series could be commented on by people who feel like the article is missing something? Any thoughts if this is unreasonable? — Preceding unsigned comment added by ~2026-57372-0 (talk) 21:14, 27 January 2026 (UTC)[reply]

All articles have a talk page. Phil Bridger (talk) 21:26, 27 January 2026 (UTC)[reply]

This is what a talk page is for. EatingCarBatteries _{(contribs | talk)} 00:46, 28 January 2026 (UTC)[reply]

Entertaining this idea a bit, it could be nice to make a place that served as a forum for some topics, as talk pages are NOT a forum. Honestly makes it hard to collaborate when you can't shoot the shit with other editors. There are some unofficial places for Wikipedia in general, like Discord or Reddit, but "You will never find a more wretched hive of scum and villainy." GeogSage ^{(⚔Chat?⚔)} 02:13, 28 January 2026 (UTC)[reply]

I do get it, but the #1 issue with "forum pages" is moderation. There won't be WMF content moderators, it'll be Wikipedians. It's just gonna spiral into being a Facebook comment section. I think if a feature like this were to be implemented, it would have to be turned on for uncontroversial pages.

Here are some examples of pages that shouldn't be allowed to have these pages:

• BLPs and recent deaths
• Anything subject to WP:ARBCOM measures, broadly construed
• Anything relating to race, ethnicity, sexual orientation, disability, etc.
• Top-level country pages (i.e. USA, Pakistan, D.R. Congo) and their relations
• etc.

Also, it violates neutrality. By allowing anyone to talk about the topic of the article and shove their own (often bad) opinions on the subject, Wikipedia will shift away from being a neutral encyclopedia.

TLDR: It might be cool, but it's not worth the effort for a volunteer community to set up and moderate for civility. even trillion dollar companies struggle doing it. EatingCarBatteries _{(contribs | talk)} 02:31, 28 January 2026 (UTC)[reply]

yeah, comment sections are at odds with our purpose as an encyclopedia User:Bluethricecreamman (Talk·Contribs) 02:35, 28 January 2026 (UTC)[reply]

Wikinews has a separate comments section. It does not attract many comments, but Wikinews gets many, many fewer readers. WhatamIdoing (talk) 02:59, 28 January 2026 (UTC)[reply]

Maybe the relevant Wikiprojects could host a metaphorical "water cooler" if appropriate. That said, with a few exceptions, I find the participation in Wikiprojects a bit disappointing. There isn't much collaboration, and when new people stop by to find people they are often met with silence. GeogSage ^{(⚔Chat?⚔)} 03:43, 28 January 2026 (UTC)[reply]

Wikiproject talk pages are often used to discuss broader topics within the remit of the project, but even there I think such discussions need to be about improving the encyclopedia. As others have mentioned, there are plenty of other venues on the web for general discussions about topics. As for your last complaint, while many projects have low participation, others still have useful discussions. I participate at Wikipedia talk:WikiProject Indigenous peoples of North America, Wikipedia talk:WikiProject Archaeology, and Wikipedia talk:WikiProject Tree of Life, and am aware of other active projects. Donald Albury 14:16, 28 January 2026 (UTC)[reply]

I know there are exceptions, but a lot of them feel pretty dead. Wikipedia:WikiProject Geography and Wikipedia:WikiProject Maps are the two I'm most familiar with, and unfortunately they have been fairly dead. I've tried to find collaborators on articles there, and yet to really get anyone to help. I've seen a lot of other topic specific projects like this. GeogSage ^{(⚔Chat?⚔)} 17:05, 28 January 2026 (UTC)[reply]

Wikipedia is not social media, and for good reason. ChompyTheGogoat (talk) 11:26, 8 February 2026 (UTC)[reply]

Article talkpages can be used to suggest improvements to a WP-article. If it's not about that, places like Reddit are available. Gråbergs Gråa Sång (talk) 07:50, 28 January 2026 (UTC)[reply]

controversial pages Misterpotatoman (talk) 19:54, 2 February 2026 (UTC)[reply]

This has been tried – see Wikipedia:Article Feedback Tool. It was not successful. Andrew🐉(talk) 21:04, 12 February 2026 (UTC)[reply]

Do we have rules or policies for editors who systematically do the same thing repetitively? Like changing which/that or killed/murder or any number of examples. Like splitting/merging paragraphs. They are some of the most irritating editors. Some are banned and they never go away turning into decades-long zombie LTA cases. They start out in good faith, become true believers, irritate the hell of everyone, get banned, and keep coming back with socks and IPs. There should be some kind of rule that can quickly stop it. Call it WP:REPETITIVE, a noticeboard where the community can discuss cases brought there. This often comes up at ANI, but usually not until they have already caused a lot of disruption. Repetitive editing is neary the same as bots, which have strong regulations. Human editors doing the same have no checks, except ANI which is inconsistent and difficult. -- GreenC 04:20, 28 January 2026 (UTC)[reply]

Are you talking about stuff like that one issue with the mass changing of BLP's places of birth from "Estonia" to "Estonian SSR, Soviet Union"

I mean, those kind of editors are textbook WP:DISRUPTIVE editors. I think exact scenario might specifically warrant a section in here.

Disruptive editing is a pattern of editing that disrupts progress toward improving an article or building the encyclopedia. This may extend over a long time on many articles.

Depending on the case, it could fall under WP:TENDENTIOUS (essay of WP:DISRUPTIVE)

Tendentious editing is a pattern of editing that is partisan, biased, skewed, and does not maintain an editorially neutral point of view. It may also involve repeated attempts to insert or delete content in the face of the objections of several other editors, or behavior that tends to frustrate proper editorial processes and discussions. This is more than just an isolated edit or comment that was badly thought out.

EatingCarBatteries _{(contribs | talk)} 05:07, 28 January 2026 (UTC)[reply]

Some of these might fall under WP:MEATBOT and require permission in advance. However, some of these are helpful edits, even if you don't like seeing the change happen. For example, people who change which to that for restrictive clauses in American English articles are doing a good thing and should be encouraged. Small improvements are still improvements. WhatamIdoing (talk) 20:36, 2 February 2026 (UTC)[reply]

As WAID points out, it really depends. Edits that change a dash to the correct type may not have much value individually, but they are unambiguously beneficial. Other corrections of common spelling and grammatical errors are in the same boat.

What you are probably thinking of is serial violators of WP:STYLEVAR. That is mildly disruptive, and the mild part is why there often is need for a noticeboard discussion before action is taken, especially if some of the other maintenance they do is good. Sometimes the socking is obvious, but when it isn't then yes things can be a bit tedious. Sometimes it may not even matter which sockmaster it is specifically for clearly NOTHERE cases though I have joked that we could all do nothing and let the various ENVAR sockmasters edit-war with each other while achieving the same end result.

Then there are the serial edits that while sometimes, or even often, beneficial, are when applied indiscriminately a mix of both good and bad. This is even trickier to deal with, especially if the user responsible has good social connections, because people will defend the good as being worth the bad this was for example one among many overlapping issues at play in the recent capitalization arbcase. Persistence does typically still result in sanctions but it is going to take a while to get there because the person responsible is clearly intending to help.

Is lowering the threshold for sanctions a good idea? It is of course easy to pick examples and say that a recurrence of the WP:WILDFLOWER pattern was visible a mile away, but hindsight is easier than foresight and many misguided newcomers do reform with time and gentle direction.

Even if some easy to adjudicate new standard finds consensus, a new noticeboard is unlikely to be a good idea; need high enough frequency of incidents that cannot be handled through less intensive methods and a critical mass of page watchers for viability.

With sysops an ARC or perhaps nowadays RECALL is probably going to be needed for someone who digs in their heels, and a prior discussion on AN or ANI is practically mandatory before that can go forward.

There are probably some possibilities here but the specifics need to be very carefully thought out. ~2025-41540-19 (talk) 16:24, 12 February 2026 (UTC)[reply]

I'm not sure what you mean. Is writing articles on the same topic over a long period of time and not doing anything else repetitive? Is fixing linter errors and not doing anything else repetitive? Do you have an example of such user? sapphaline (talk) 16:28, 12 February 2026 (UTC)[reply]

almost all the pages on my watchlist, i dont actually add to because i want to watch them, but because i want a easy way to access them and remember them, so i propose favorites, specifically for pages you want to remember, plus, a average user of wikipedia probably only uses it for checking pages, they may have a particular or multiple pages they need to a easy way to access, for example, a person might need to write something on topic like color theory, they could add it to their favorites and not their watchlist as they have no plans to edit it Misterpotatoman (talk) 19:41, 2 February 2026 (UTC)[reply]

Fortunately, the WMF’s developers are actually working on adding such a feature (though personally I don’t like that they’ve opted to move the watchlist icon into the Tools menu to do so).  novov talk edits 20:02, 2 February 2026 (UTC)[reply]

I do have to wonder why they're reinventing bookmarks. Anomie⚔ 00:21, 3 February 2026 (UTC)[reply]

The new mw:Help:Watchlist labels feature might be of interest to you. It enables separating pages within the watchlist, so that you can keep everything listed but hide some in the feed (essentially implementing the long desired "multiple watchlists"). HTH. Quiddity (talk) 19:29, 6 February 2026 (UTC)[reply]

The new Watchlist labels feature Quiddity linked is great for that but even better could be bookmarks – see here and m:Community Wishlist/W102. To address Anomie's implicit question, browser bookmarks can't be readily accessed from other devices, aren't specific to only Wikipedia articles, can't be used to get recommended articles, can't be shared in bundles, can't be accessed from within the Wikipedia app, etc. One further idea would be enabling notes for bookmarked articles. I'm also using the Watchlist feature like you describe Misterpotatoman. Prototyperspective (talk) 15:47, 12 February 2026 (UTC)[reply]

I note "can't be readily accessed from other devices" may not be true, several major browsers have cloud sync these days. "Aren't specific to only Wikipedia articles" seems like an advantage to browser bookmarks rather than a disadvantage. "Can't be shared in bundles" seems similarly dependent on the browser; in Firefox I can copy a folder and paste it into other apps. "Can't be accessed from within the Wikipedia app" seem valid, but on the other hand one might question the point of apps reinventing a browser in general. Anomie⚔ 23:43, 12 February 2026 (UTC)[reply]

Well good note because it wasn't clear but that functionality implies you want to sync all your tabs and I certainly don't want to send all my tabs to some cloud in the US but may entrust WMF with my Wikipedia bookmarks privacy. It may be a disadvantage to you but to me it's an advantage and even required to be usable. Maybe this also needs some using the WP app to see the benefit but it's also that this only would make sense to me on desktop but not on mobile where I just occasionally read things for fun & discovery/curiosity – it would be similar to somehow combining 3 books you're reading with your grocery list and printed pages of a code issue tracker for example, one would like to have these texts separately. At some times one is reading, at other times one is doing other things and some people like to keep this separate. Nobody needs to use the app anyway. With sharing I meant sharing it with other people but I don't know if that's already possible in the app. It's not reinventing a browser in general. And some things require use before recognizing how it's useful. I hope more features get added to the app over time that give it more and more advantages over the mobile Web version (better and login-nonrequiring dark mode is one) such as the Nearby Places map. Prototyperspective (talk) 01:19, 13 February 2026 (UTC)[reply]

by what i mean is a separate part of wikipedia that is purely for sharing interesting facts like average probability of a certain leaf, there is no widespread interesting fact sharing platform to my knowledge besides quora posts bug this would be more things you know, whole quora is more lessons you learn from what i've read and quite alot of people would like to fill that feeling, the best place for this would be to do is specific tumblr communities and those are more about fiction to my knowledge, this would be more about real life topics, it would feel out something akin to watching those interesting videos on relatively random topics, it would be separated into many sections, the main thing against this idea is that "why would this encyclopedia have unsourced content?" and to that i say because i think a majority of wikipedias users would also like this feature because they probably know alot of things they would like to share, the actual reason this shouldn't get added is because it would probably be better as separate wiki project, very different from anything to do with wikipedia and basically any other wide stream wikiproject. Misterpotatoman (talk) 09:20, 3 February 2026 (UTC)[reply]

There are plenty of sites that do what you want. Why do you feel that it's appropriate for an encyclopedia to have blogs? Phil Bridger (talk) 09:27, 3 February 2026 (UTC)[reply]

@Misterpotatoman can you clarify your idea a bit further. I think having a shared blogs (what editors are working on now) as part of a project could be interesting and build community, especially if we could somehow grab project members edit summaries to do with articles that are part of the project Not certain about on article as we try and avoid diverting people, but diverting high conflict editors from protected pages could be good.. (With fun, I find wiki meetups and pages to do with Wikipedia on FB and Reddit and mastadon helped.) — Preceding unsigned comment added by Wakelamp (talk • contribs) 10:51, 3 February 2026 (UTC)[reply]

i think there could be something be blogs purely for sharing interesting things and facts, like those interesting youtube videos but text, it would be separated into alot of topics, as far as i know theres no widespread interesting fact sharing platform anywhere and i good chunk of people want to share interesting facts, Misterpotatoman (talk) 05:54, 5 February 2026 (UTC)[reply]

• The Wikimedia Foundation actually made their own pseudo-social-media-type platform. Basically nobody knows it exists, and basically nobody uses it. So I'm not sure I would expect Wikimedia projects to ever be very good at making something where established alternatives already exist. GMG^talk 14:21, 3 February 2026 (UTC)[reply]

  And also meta:Capacity Exchange. Children Will Listen (🐄 talk, 🫘 contribs) 14:31, 3 February 2026 (UTC)[reply]

  And also Diff and the Wikimedia Blog. Andrew🐉(talk) 17:49, 3 February 2026 (UTC)[reply]

Why would an encyclopedia want to associate itself with something that would have no sourcing or quality standards? Why would a person reading an encyclopedia want to read your unsourced gibberish? --User:Khajidha (talk) (contributions) 15:55, 4 February 2026 (UTC)[reply]

"unsourced gibberish" - this is Ideas - blasting people you don't agree with is unhelpful ~``Wakelamp (talk) d[@-@]b

People posting random stuff that they think they know, without anything to back it up beyond "trust me, bro" is far more unhelpful. --User:Khajidha (talk) (contributions) 13:15, 9 February 2026 (UTC)[reply]

well, i guess we could also implement a safeguard which doesn't allow you to publish until there are a specified number of citations per para/heading (to prevent loopholes). the rest of it has to be handled by the editor publishing the blog.

in any case, calling it "unsourced gibberish" is really just overextending. why can't you call it "uncited"? that would be far more acceptable/ woaharang (talk) 14:44, 19 February 2026 (UTC)[reply]

• That’s the problem… I have a feeling that any such project (hosting unsourced content) would quickly devolve into little more than “everyone blasting people they don’t agree with”. Blueboar (talk) 01:07, 6 February 2026 (UTC)[reply]

  Wikipedia already has that – the Village Pump pages, for example. If you look at Top 1000 edited pages in last 30 days, you see that there's lots of activity on non-article pages. Andrew🐉(talk) 08:09, 6 February 2026 (UTC)[reply]

• Bad idea, in my view. Jusdafax (talk) 08:26, 6 February 2026 (UTC)[reply]

Wikipedia's default warning system (for example, with Twinkle) to problematic editors is an escalating set of five stages. Basically: note, caution, warning, final warning, and then a report for potential blocking. Recent changes reviewers may decide to skip levels, issue single warnings, etc, but the default is five. I feel that's a ridiculously lax standard. Because the harshest sanction we can enforce is to not allow editing, we reserve it for only the most persistent vandals and problematic editors. The problem with that mindset is that the threat of being blocked from editing is not actually a deterrent at all - because what does the bored kid who wants to add "eats poop" to an article care about eventually being unable to continue doing that? I'd like us to default to a three-tier system: caution, warning, block, with a low threshold for reducing that to immediate blocks. For TA's, a 24 or 31 hour block for a few clearly non-constructive edits (or a single egregious edit, such as to BLP articles) should be no big deal and handed out generously. Curious to see what others' thoughts are, especially fellow recent-change patrollers. Matt Deres (talk) 20:38, 3 February 2026 (UTC)[reply]

In my view, the reason there are four warnings by default is to encourage assuming good faith. You don't have to issue all four warnings before reporting someone to AIV if the vandalism is particularly egregious. That's what {{uw-v4im}} is for.

Also, this concerns warning templates, so you can probably ask for more input at WikiProject User warnings. SuperPianoMan9167 (talk) 21:07, 3 February 2026 (UTC)[reply]

Sometimes, when I've given a {{uw-attempt1}} template to warn a user for triggering edit filters, the editor I just warned gets immediately blocked, probably because of the edit filter auto-reporting that DatBot does. SuperPianoMan9167 (talk) 21:13, 3 February 2026 (UTC)[reply]

You may not have to issue all four warnings, but it's also not uncommon to see responses at AIV that the editor has "not been sufficiently warned". That's why I want to address the expectation. And I also want to be clear that I'm not talking about editors that are genuinely struggling with WP's way of doing things. Fuck up a template or a table or something? Well, we've all been there, right? But edits like this and this and this and this and this (those are all items I cleaned up just yesterday) are not editors that are struggling. They know what they're doing and know that they're doing wrong. You don't have to assume anything. Matt Deres (talk) 14:29, 4 February 2026 (UTC)[reply]

Five is not the default, but often the maximum. But you are right about the most severe sanction we can impose being the extremely trivial one of not allowing editing of one web site. I've lost count of the number of times that I've pointed out that we can't deprive anyone of their liberty for a minute or fine anyone a cent/penny. Despite the fact that I dont care about being blocked (or maybe because of it) I never actually have been. A bit sad, really. Phil Bridger (talk) 22:02, 3 February 2026 (UTC)[reply]

• I don't see how taking these tools away from recent changes patrollers would be useful. When an administrator at AIV says a user was insufficiently warned it's not because the administrator is blindly counting the number of warnings. They're taking the user's behavior into account. It's very, very, very common to see users blocked at AIV based on far fewer (or sometimes zero) warnings. The bot removes blocked users from AIV quickly, so most of these are invisible unless you're looking at the page history. Similarly, recent changes patrollers are not blindly applying warning levels. We take the user's behavior into account, and regularly skip levels, start on a higher level, or report at a lower level, based on what's appropriate. A maximum of two warnings prior to a block is unnecessarily aggressive. Recent changes patrollers are competent enough to report users to AIV after an appropriate number of warnings (whatever that number may be), and administrators are competent enough to act solely based on a user's behavior (and not whether they've received exactly 4 warnings). There's no problem here to be solved. --tony 15:03, 4 February 2026 (UTC)[reply]

  +1 Took the words right out of my mouth, absolutely agree with everything here. – LuniZunie_(talk) 12:01, 6 February 2026 (UTC)[reply]

• I'm not sure what problem we'd be trying to solve by discouraging or preventing editors from issuing good faith notices that are at least as informational as they are actual warning. For instance, most new editors have no idea that WP:FILMPLOT exists, and as such there's Template:uw-plotsum1, and for repeat offenders, Template:uw-plotsum2. Are we going to say that editors are no longer allowed to issue that notice, which doesn't just tell an editor that they violated plot summary guidelines, but also provides some explanation and links to other relevant guidelines? DonIago (talk) 18:22, 4 February 2026 (UTC)[reply]

  Nobody is suggesting that we block people for adding too much verbiage to a film plot. Why bring that up at all? I'm talking about deliberately nonconstructive edits: deliberate factual errors, libel, vandalism, etc. Matt Deres (talk) 14:33, 5 February 2026 (UTC)[reply]

  Repeatedly violating WP:FILMPLOT is disruptive editing, so it is germane to the conversation. DonIago (talk) 21:00, 5 February 2026 (UTC)[reply]

  Not really. If you give someone four templated warnings for overly detailed film plots then report them to AIV, I'm not going to block them, and I wouldn't if the warning sequence was changed. HJ Mitchell | Penny for your thoughts? 21:04, 5 February 2026 (UTC)[reply]

  It's encouraging to me to have an admin acknowledge that they wouldn't block an editor who was repeatedly violating a guideline and presumably refusing to communicate about it. DonIago (talk) 21:26, 5 February 2026 (UTC)[reply]

  As a general rule, I only block from AIV if it's bad faith. For anything else, it needs to go to a venue where they have a chance to defend themselves. I might make an exception if they're really persistent and you've explained in plain English and without templates what the problem is. But templating someone for adding their favourite plot point to a film article is biting the newcomer, which is more harmful than the edit itself. HJ Mitchell | Penny for your thoughts? 21:32, 5 February 2026 (UTC)[reply]

  My apologies, it seems, unlike my usual pattern, I didn't read your prior message literally enough. I wouldn't take someone to AIV for plot summary issues because that's not vandalism. If it was on the same article repeatedly that would likely be a 3RN problem, and if it was multiple articles it would be ANI most likely. DonIago (talk) 21:39, 5 February 2026 (UTC)[reply]

  There's a warning template for basically every kind of disruptive editing, including MOS violations. I imagine {{uw-mos4}} doesn't get used very often. SuperPianoMan9167 (talk) 21:03, 5 February 2026 (UTC)[reply]

• Oppose Left unchecked, punishment generally drifts towards being more severe over time. People get accustom to a punishment, and think that someone deserves worse, implements such new punishment, and then the cycle begins again until it becomes so cruel and ridiculous reform becomes necessary. Organizations left to their own devices will grow their bureaucracy, policy, and rules until it becomes so unwieldy it crumbles, but in the mean time people are forced to follow those rules or face increasingly harsh punishment. I would like us to move away from total "block" being the default, we are to quick to resort to exile. Other sanctions that are less severe, with time limits, should be developed and implemented.

GeogSage ^{(⚔Chat?⚔)} 00:14, 5 February 2026 (UTC)[reply]

If you think temporarily disallowing someone from editing a webpage in bad faith is in any way on some slippery slope to cruelty, I can only suggest you touch grass. Not getting to add "Did you know my ess has many many nooks and cranny" to an article is not a punishment at all and blocking that person has had zero negative repercussions for anyone. Matt Deres (talk) 14:46, 5 February 2026 (UTC)[reply]

• I've long thought (as one of the most active admins at AIV) that we give too many chances, especially for spammers (who are not bored kids and really should be blocked on sight). It's worth having the flexibility that the current warnings offer, but there's absolutely no need to go through all four in order. I'll happily block after level 3, or if you skip from 1 to 4; feel free to start at 3 and report on the next edit if there's no way it's good faith (like most of Matt's examples). But for borderline cases, it's nice to have level 1 for "that might have been a mistake" or "I'm not sure what you're trying to do". Level 2 is more "maybe you don't know it but what you're doing is disruptive", and level 3 is "no seriously, you need to knock it off now". I'd happily get rid of level 4, which is essentially level 3 but more so. HJ Mitchell | Penny for your thoughts? 19:06, 5 February 2026 (UTC)[reply]

  The question is, why do people habitually give out all four warnings for obviously bad-faith edits? Do they image it's policy? Or are they just on autopilot, and following the Twinkle/Huggle defaults? Suffusion of Yellow (talk) 20:21, 5 February 2026 (UTC)[reply]

  I think Huggle and similar are programmed to just escalate until they get through all four. There's basically no human intervention other than pressing the "vandalism" button. I think Twinkle will suggest a warning level but the user can override it with an extra click or two. A lot of inexperienced users feel they have to go through all four warnings before they can report; I thought that when I was new. HJ Mitchell | Penny for your thoughts? 20:34, 5 February 2026 (UTC)[reply]

  Does the number indicate A) the level of severity of the combined edits, or B) the amount of times someone did something naughty.

  If its A, and I think it is and should be, we don't communicate that clearly. Polygnotus (talk) 21:03, 5 February 2026 (UTC)[reply]

  Definitely A. At least that's the way it should be and I suspect the way it was always intended to be. HJ Mitchell | Penny for your thoughts? 21:07, 5 February 2026 (UTC)[reply]

  @WhatamIdoing What do you think? Polygnotus (talk) 21:19, 5 February 2026 (UTC)[reply]

  That's certainly how it's defined at WP:UWLEVELS. DonIago (talk) 21:21, 5 February 2026 (UTC)[reply]

  The first question is, do people habitually give out all four warnings for obviously bad-faith edits? Certainly some people do, especially if they are doing simple Wikipedia:Recent changes patrol work, but others probably don't.

  With counter-vandalism tools, escalating levels are automatic. You don't see the vandal/spammer/whatever's talk page, so you don't know if there were prior problems. In that sense, it's definitely (B) in practice, even if it "should" be (A).

  One difficulty with decreasing the levels is that notifications aren't always seen or read immediately. Consider this sequence:

  • Van Vandal vandalizes article A.
  • Van Vandal opens article B to vandalize it.
  • Dave Defender sees the vandalism to article A, reverts it and leaves a warning.
  • Van Vandal posts the vandalism to article B.
  • It's only now – with two articles vandalized – that Val Vandal has any chance of seeing Dave's warning. But someone may well see the vandalism in article B, and notice that the warning's timestamp precedes the timestamp for the article B edit, and be angry that Van Vandal was vandalizing after (and in spite of) being "previously" warned.

  And that's assuming that all warnings are correctly delivered. Sometimes a warning for "vandalism" is actually someone correctly removing poorly sourced or erroneous information. WhatamIdoing (talk) 21:58, 5 February 2026 (UTC)[reply]

  @WhatamIdoing See WP:VPT#Stats on vandalism template usage for a quick first exploration (more research required). Polygnotus (talk) 22:11, 5 February 2026 (UTC)[reply]

  With counter-vandalism tools, escalating levels are automatic. You don't see the vandal/spammer/whatever's talk page, so you don't know if there were prior problems. Only with some countervandalism tools. One thing I like about Twinkle is that when you revert an edit with it, it redirects you to their user talk page (so you can see previously issued warnings). Granted, doing this on mobile is tedious, as I have to repeatedly close the auto-opened edit window to access the warning templates from the TwinkleMobile menu, but I do get to see if there have been any prior issues with the editor. SuperPianoMan9167 (talk) 22:12, 5 February 2026 (UTC)[reply]

  Offering a choice instead of simply incrementing may be a good feature request. Polygnotus (talk) 22:14, 5 February 2026 (UTC)[reply]

  Already implemented in Twinkle: I can choose "auto-select warning level" or a specific level. SuperPianoMan9167 (talk) 22:16, 5 February 2026 (UTC)[reply]

  Programmes like Huggle just show the user a diff and they select one of several options. If they select vandalism, the programme reverts the edit and drops the next warning in the sequence without any human involvement. The human could be two or three diffs further on by the time the programme has left the warning. HJ Mitchell | Penny for your thoughts? 22:18, 5 February 2026 (UTC)[reply]

  I'll note that (at least some) counter-vandalism tools are continuously evolving; WP:WikiShield, a "descendant" of WP:Huggle, does have a setting to allow the user to choose the warning level or have it selected automatically. I haven’t used Huggle or WP:AntiVandal recently and can't remember if they have similar settings. ClaudineChionh (she/her · talk · email · global) 03:38, 6 February 2026 (UTC)[reply]

  Yeah this is the exact reason I have the settings. I sometimes find myself skipping straight to level 2 or level 3, as it all depends on the context of the edit.

  AV has the same, but I don't think HG does. – LuniZunie_(talk) 12:04, 6 February 2026 (UTC)[reply]

  Notified: Wikipedia talk:WikiShield, Wikipedia talk:AntiVandal and Wikipedia talk:Huggle/Feedback. ClaudineChionh (she/her · talk · email · global) 03:47, 6 February 2026 (UTC)[reply]

  Interceptor is another that allows users to see prior warnings. I oppose the changes proposed because having 4 warnings can be helpful, especially when an edit looks like vandalism but was actually good faith. As an aside, yesterday I dealt with a vandal on Wikiversity, who made 19 edits before being blocked, all vandalism, and they included adding "I am a vandal" in Ukrainian. They were blocked for 5 days, and after they trolled their talk page so much that their talk page was deleted, they had TPA revoked and their block extended to 2 weeks. I'm not sure if there's a lesson to be learned ("someone will always AGF more than you"?), or if I just wanted to rant. Anyway, I support assuming good faith and oppose unnecessary blocks for vandals who might well just stop anyway. lp0 on fire () 11:29, 6 February 2026 (UTC)[reply]

There is also some degree of minimizing sysop workload. Many vandals get bored quickly so will stop on their own after a few edits. A higher threshold limits reporting to cases that most likely need a block. And of course, gross-vandalism, obvious socks, LTAs, etc. can be reported with no warning at all. ~2025-41540-19 (talk) 04:53, 12 February 2026 (UTC)[reply]

I generally ignore levels of warnings, and go directly to an appropriate one (currently I use Twinkle), regardless of what has gone before with a particular case. Admins who have dealt with vandalising users after my warnings have never made any comment on this behaviour, and I've been doing it for years. Hand wringing on this issue seems a little pointless as a vandal is a vandal. I've got here from ClaudineChionh's notification notified above. - Walter not in the Epstein files Ego 16:44, 16 February 2026 (UTC)[reply]

Same. If someone's engaging in unambiguous vandalism or throwing personal attacks around, I see no reason to give them the 'good faith' notifications. They know what they're doing. DonIago (talk) 03:08, 17 February 2026 (UTC)[reply]

searching "{{" could show results for templates, so instead of "Template:Example" it could be "{{Example" or "{{Example}}" which would redirect to "Template:Example", "[[" could maybe also have the same effect with files, so "[[example"/"[[example]]" redirects to "File:example" Misterpotatoman (talk) 06:29, 5 February 2026 (UTC)[reply]

@Misterpotatoman My User:Ahecht/Scripts/TemplateSearch script does exactly that, at least with templates. You can do your file example by adding my script to your Special:MyPage/common.js and then adding the following line before it: var SearchRegexes = {"^\\\[\\\[":"File:", "\\\]\\\]$":""} --Ahecht (TALK
PAGE) 17:58, 5 February 2026 (UTC)[reply]

Holy cow, I love this. Thank you. EatingCarBatteries _{(contribs | talk)} 07:13, 10 February 2026 (UTC)[reply]

On Commons, one can already search categories like so: cat:search terms. The same would be useful here and one could add a shortcut for templates too like t:search terms as well as a note about this so that users can learn about such handy search shortcuts. Prototyperspective (talk) 15:40, 12 February 2026 (UTC)[reply]

TM: is already a shortcut for templates :) 📎 JackFromWisconsin (talk | contribs) 16:55, 12 February 2026 (UTC)[reply]

Since the latest policy proposal on using LLMs is unlikely to pass, I thought that maybe a different approach could work. Most of these proposals suffer from the enforcement problem: that it's extremely difficult to definitively determine whether any given text was LLM-generated (see this report by WikiEdu for the discussion on what works and what doesn't). The community would not want to sanction editors based on uncertain evidence.

Alternative proposal: address the harms directly! Rather than trying to detect LLM use itself, what if we focused enforcement on the specific problems that LLM-generated content causes? Consider the major issues with LLMs

• Citation accuracy: LLMs are often unreliable at faithfully representing sources. We could impose stricter sanctions and strengthen enforcement of WP:V, especially for editors who repeatedly add claims that don't match their citations.
• Volume and review capacity: LLMs enable editors to add large amounts of content slop quickly, overwhelming our ability to review it adequately. We could implement rate-limiting measures, perhaps restrictions on the number or scope of edits that editors can make within a given timeframe, with newer editors subject to stricter limits.

These measures target the harm to encyclopedia quality directly. They can work alongside (and serve as an enforcement mechanism of) a more general ban if we end up adopting it. They can also work on their own if we don't adopt a general ban on LLM content.

What other specific harms from LLM use can you think of? Any side effects such measures might have? Alaexis_¿question? 11:28, 5 February 2026 (UTC)[reply]

Putting aside the way the above is written, the enforcement problem applies to a lot of our policies, we are reactive because of the open nature of the project. There isn't really an enforcement gap in terms of stricter sanctions for Citation accuracy, people get blocked a lot. The gap there is in detection in the first place, which we don't have the manpower to do. As for rate limiting, not sure how that would work. Even WP:MASSCREATE requires manual oversight, and creation is easier to track technically than edits in general. CMD (talk) 11:36, 5 February 2026 (UTC)[reply]

There isn't really an enforcement gap in terms of stricter sanctions for Citation accuracy, people get blocked a lot I didn't know this is the case. What is generally considered a block-worthy behaviour? But in any case detecting inaccurate citations is a much simpler task than detecting LLM-generated content.

As to the rate limiting, it's a problem that a lot of other organisations have solved in various contexts. Before discussing technical details let's first establish whether it's a good idea in principle. Alaexis_¿question? 12:36, 5 February 2026 (UTC)[reply]

Disruptive editing in the article space often results in blocks, I don't think most admins have a strict checklist. I don't think it is easier to detect inaccurate citations in any case, llm use can be blatant, whereas checking citations almost always requires investigative work. As for rate limiting, there isn't going to be support for a generic number of edits or amount of content filter because they mask a huge range of variation. If you are proposing something more specific, there'll need to be at least broad technical details. CMD (talk) 13:44, 5 February 2026 (UTC)[reply]

I see your point. Let's see what others say. Perhaps our existing processes already do a good job of preventing this kind of mass editing. Alaexis_¿question? 14:42, 5 February 2026 (UTC)[reply]

detecting inaccurate citations is a much simpler task than detecting LLM-generated content. Actually the opposite, overwhelmingly so. A great deal of LLM-generated content is pretty obvious linguistically. But verifying the citations and source-to-text integrity can take hours or even days depending on length of the article and availability of sources. (This is the same conclusion WikiEdu came to recently - verifying AI content takes longer than just researching/writing from scratch.) Gnomingstuff (talk) 15:55, 5 February 2026 (UTC)[reply]

The wikiedu report I linked mentions false positives and clearly the no tool would give you full certainty.

"A great deal of LLM-generated content is pretty obvious linguistically" is *maybe* true if the person creating it makes zero effort to hide it. Alaexis_¿question? 16:02, 5 February 2026 (UTC)[reply]

Obvious AI content is obvious, but not all AI content is obvious. It is also the case that some content that is, to some reviewers, obviously AI is not in fact AI. The rates of detection reported in studies vary greatly with 75-99% detection of AI content as AI, and 2-50% for false positives (human-written content detected as AI). I can't immediately find it, but @WhatamIdoing has previously cited a study that found the humans who are most reliable at detecting whether something is or is not AI are those who themselves make significant use of AI tools (which describes few of the Wikipedians who are most vocal about AI use). Thryduulf (talk) 17:21, 5 February 2026 (UTC)[reply]

It's linked in Wikipedia:Signs of AI writing#Caveats. WhatamIdoing (talk) 18:34, 5 February 2026 (UTC)[reply]

I would guess the people who work heavily on AI cleanup are probably much more knowledgeable about AI, at this point, than the control group in that study.

A lot of what we get as AI content is either completely unreviewed, or reviewed little enough that if they made an effort to hide it, they didn't do a very good job, because the biggest tells of AI use are not necessarily intuitive or obvious to laypeople. (Which is the case with most large language model-related tells. These are quirks of vector math, they're not going to fit a palatable spiritual narrative.) Gnomingstuff (talk) 21:56, 5 February 2026 (UTC)[reply]

If we end up getting Pangram (which doesn't have an article btw?) through the WMF, then this proposal may be moot for now Kowal2701 (talk) 17:30, 6 February 2026 (UTC)[reply]

Not sure it meets WP:NCORP currently but I wrote a draft Gnomingstuff (talk) 21:21, 6 February 2026 (UTC)[reply]

Why? It still works probabilistically and has false positives. How comfortable would you be with imposing sanctions based on a black box that told you that a given edit is LLM-generated with the probability of 83%? Alaexis_¿question? 23:05, 6 February 2026 (UTC)[reply]

Depends on context. If it's an editor who's been warned and shown no sign of changing, pretty comfortable. Would obv use ordinary analysis as well. But Pangram has false positives less than 1% of the time Kowal2701 (talk) 00:03, 7 February 2026 (UTC)[reply]

@Kowal2701, I saw this number in the draft that you've created but to be honest I doubt it. I tested it and reached 100% fully human written with a simple prompt and 3 minor copyediting tweaks in a passage of ~100 words. I don't want to describe it here per WP:BEANS but if you're interested I can share it privately. Alaexis_¿question? 12:16, 7 February 2026 (UTC)[reply]

<1% is for false positives, I'm sure it's much higher for false negatives. Whatever troubles we're having, education systems have it much worse, I'm amazed LLMs were released with no considerations for that, like making all output identifiable. Btw it was Gnomingstuff who created the draft Kowal2701 (talk) 12:27, 7 February 2026 (UTC)[reply]

Sorry @Gnomingstuff! Btw I think that the draft can be promoted to the mainspace.

The paper says that Commercial detectors outperform open-source, with Pangram achieving near-zero FNR and FPR rates that remain robust across models, threshold rules, ultra-short passages, "stubs" (≤ 50 words) and 'humanizer' tools. Note that it hasn't been published in a peer-reviewed journal. I'll go out on a limb and say that I don't believe these numbers. To check false positives I'd need more Pangram credits, that would be an interesting exercise. Alaexis_¿question? 19:58, 7 February 2026 (UTC)[reply]

Yeah one of the reasons it's in sandbox is because the efficacy section is scant and mainstream media coverage is just not really there at the moment Gnomingstuff (talk) 04:24, 8 February 2026 (UTC)[reply]

So, adding a lot of content to Wikipedia is harmful and should be stopped. Duly noted. Cambalachero (talk) 14:00, 5 February 2026 (UTC)[reply]

This is not at all what I said. As an example, a user with an LLM can create 1000 articles in one day overwhelming the capacity to review them and do even basic notability checks. The rate limit should be set high enough not to affect human contributors. Alaexis_¿question? 14:21, 5 February 2026 (UTC)[reply]

Adding a lot of unvetted AI slop to Wikipedia is harmful and should be stopped, yes. XtraJovial (talk • contribs) 21:38, 6 February 2026 (UTC)[reply]

Adding a lot of poor-quality content to Wikipedia is harmful and should be stopped, whether that content is human-generated, AI-generated or a mix.

Adding a lot of high-quality content to Wikipedia is beneficial and should be encouraged, whether that content is human-generated, AI-generated or a mix.

What matters is the quality of the output, not the tool. Thryduulf (talk) 21:53, 6 February 2026 (UTC)[reply]

• The flaw with using LLMs is one that many editors fall into even when NOT using LLMs: not doing proper research before you write.

A proper article is source based… the writer first reads LOTS of sources and then summarizes what they say (and then cites the best of those sources to provide verification for that summary).

A poor article is text based… the writer first decides what he wants the text to be, and then finds (and cites) a source to verify it. That is the wrong/backwards approach.

That said… You CAN use LLMs for research… to locate potential sources… but you need to actually read those sources in order to see if they fall in line with what other sources say. You can not properly summarize the sources based only on an LLM. You need to read lots of other sources as well. Blueboar (talk) 14:49, 5 February 2026 (UTC)[reply]

• Just make WP:LLMDISCLOSE a guideline, as I've been saying for over a year now. Experienced editors should be able to understand that presenting text or ideas that originated in an LLM as their own words goes against WP:PLAGIARISM and/or WP:FREECOPY and/or WP:NOSHARE. Those guidelines apply in both article and talk space. New editors who are non-transparent about their LLM use get blocked all the time. Some of those people were headed for blocks anyway, but some of the blocks could possibly have been averted by a clearer explanation of community expectations for transparency about the provenance of text. We can litigate the pros and cons of various AI use cases, but there's literally no constructive reason to be non-transparent about the source of the content you insert here and most of the LLM-related problems we face will go away if people start following WP:LLMDISCLOSE. -- LWG ^{talk (VOPOV)} 17:33, 5 February 2026 (UTC)[reply]

  The people who would do the most harm using LLMs would be least likely to disclose their LLM usage. If they add unreviewed LLM slop it means they don't know or don't care about our basic policies. Why would they obey LLMDISCLOSE? Alaexis_¿question? 22:08, 5 February 2026 (UTC)[reply]

  Not all LLM users are bad faith. -- LWG ^{talk (VOPOV)} 06:34, 6 February 2026 (UTC)[reply]

  I think most LLM-use is done in good faith, most just aren't aware of on-wiki guidance or the problems w LLM-use Kowal2701 (talk) 17:33, 6 February 2026 (UTC)[reply]

  It's a combination of people using LLMs in good faith and people editing in bad faith (mostly spammers) who use LLMs because that's how you spam nowadays. Gnomingstuff (talk) 20:38, 6 February 2026 (UTC)[reply]

  That's a great point. So we have two personas

  Alice: a well-intentioned user who wants to contribute to Wikipedia and is not aware of our policies and of the issues with LLMs. For these users, a well-placed warning is all we need to prevent them from copy-pasting LLM output. The warning can be added based on existing policies such as WP:V.

  Bob can be a troll, a paid editor or a true believer with an axe to grind. They can use LLMs to generate a higher volume of edits and make the violations harder to detect.

  I regularly talk to new users and I can confidently say that both types exist. The measures I proposed were mostly to deal with the second type of editors. It's possible that the existing mechanisms already handle them just fine but I'm not sure they do, considering that they require manual admin/editor work. Alaexis_¿question? 22:59, 6 February 2026 (UTC)[reply]

  While this is true, it's the same principle we use for WP:COIs and especially WP:PAID - it means that we can block the worst abusers on sight as soon as we determine they're using LLMs. In both cases I'd prefer a total ban, but a declaration requirement backed by instablocks for knowing violations (maybe one warning for people who might not realize) will at least let us remove many of the worst abusers as soon as we recognize that they're using LLMs. If you flip it around, the fact that the worst abusers wouldn't obey LLMDISCLOSE is the entire point - we're always going to have to catch them, sure, but LLMDISCLOSE means we can block them instantly once we catch them, with no further debate or discussion needed beyond maybe one second chance for people who go "oops I'm sorry, I didn't know" and follow the guideline going forwards. --Aquillion (talk) 15:25, 14 February 2026 (UTC)[reply]

  The lead paragraph of WP:LLMDISCLOSE, verbatim, should definitely be a guideline if not a policy. Honestly, I think it should be in the Terms of Use. Arguing that we shouldn't require users to do something because bad-faith users won't do it is like saying we should ditch verifiability because vandals don't care. lp0 on fire () 11:48, 6 February 2026 (UTC)[reply]

  The huge difference is that a source can be checked by anyone who has access to it (for many sources - literally by anyone with the internet connection).

  To steelman your argument, it's more like the disclosure of COI and paid editing. Here we also don't have the ability to check whether an editor is paid for his edits. I don't know if this disclosure policy can be considered successful. Alaexis_¿question? 12:00, 6 February 2026 (UTC)[reply]

  That's fair. I nonetheless see no reason for a good-faith editor to hide their LLM use. lp0 on fire () 12:19, 6 February 2026 (UTC)[reply]

  But would you argue we should repeal WP:PAID just because we can't catch everyone? That would be absurd. Having it is still extremely valuable, since it's what lets us instantly block the worst paid editors when we catch them. LLMDISCLOSE would work the same way - it's not a magic cure-all, but it would be a huge improvement over having nothing. --Aquillion (talk) 15:28, 14 February 2026 (UTC)[reply]

  Let's say I ask ChatGPT a question, and it gives me a piece of text as an answer. Can someone else find that specific piece of text in the internet on his own? And if the answer is no, can we say (from the point of view of copyright law) that the text was "published", and not merely privately shared? Cambalachero (talk) 14:43, 6 February 2026 (UTC)[reply]

  WP:PLAGIARISM doesn't care if the text you falsely present as your own was privately shared or published. If you didn't write it youself, you cannot insert it into Wikipedia unless you disclose the source and provide proper attribution. -- LWG ^{talk (VOPOV)} 15:47, 6 February 2026 (UTC)[reply]

  I do not agree. The combo of both a lack of author and a lack of publication (understanding both terms in the copyright sense) means that there is no plagiarism even if the text is copypasted elsewhere. And note that Wikipedia:Plagiarism does not say anything about this specific scenario. Cambalachero (talk) 16:12, 6 February 2026 (UTC)[reply]

  Respectfully, this is why I am urging the community to adopt WP:LLMDISCLOSE as a guideline, to make it clear to people like you that the lack of copyright on LLM text does not make it acceptable to claim it as your own, just as it is unacceptable to claim other forms of public domain or mechanistically generated text as your own. -- LWG ^{talk (VOPOV)} 16:18, 6 February 2026 (UTC)[reply]

  In other words, you can't justify your proposal if it is challenged by someone with actual arguments instead of mere acronyms, so you want a "guideline" to shut the door to any discussion and have things be your way... not by force of reason, but by reason of force. Cambalachero (talk) 16:36, 6 February 2026 (UTC)[reply]

  Not at all, my argument is simple: per the terms of use of Wikipedia, any editor who inserts text here is representing that they own the copyright on that material and are releasing it under a Wikipedia-compatible license. The only exceptions are limited quotes, which must be clearly marked and attributed, and public domain content, which must be clearly marked and attributed. LLM text is not copyrightable, as you have argued above, so it cannot be released under a Wiki-compatible license, so it must be clearly marked and attributed as one of the exceptions if it is inserted at all. That's not acronym bludgeoning, and I don't think it's difficult to understand. You are allowed to disagree with me: I'm not the king of Wikipedia, and this proposal (which I oppose) isn't about LLMDISCLOSE anyway. -- LWG ^{talk (VOPOV)} 16:50, 6 February 2026 (UTC)[reply]

  It isn't? Oh, you must have confused me with that "Just make WP:LLMDISCLOSE a guideline, as I've been saying for over a year now" bolded text that I replied earlier. Cambalachero (talk) 16:56, 6 February 2026 (UTC)[reply]

  @LWG, please see https://creativecommons.org/2023/08/18/understanding-cc-licenses-and-generative-ai/ under "CC Licenses and outputs of generative AI", especially the line that says If you create works using generative AI, you can still apply CC licenses to the work you create with the use of those tools. Creative Commons "encourages" (but does not and cannot require) people to label generative AI output as CC-0. This is for the convenience of re-users, not because of some fundamental incompatibility with the license. After all, a typo fix or a one-word reply is not copyrightable either, and Wikipedia editors have been "licensing" such uncopyrightable edits for 25 years now.

  We could set a higher standard, as we do for (e.g.,) WP:NFCC. However, we should not say that there are licensing or legal problems with posting uncopyrightable content on wiki. WhatamIdoing (talk) 19:43, 6 February 2026 (UTC)[reply]

  Thanks for the link. What I see on that page: The CC license you choose will apply to the creative work that you contribute to the final product, even if the portion produced by the generative AI system itself may be uncopyrightable. So I'm not sure I have the same understanding as you do there. The copyright status of LLM output is above my paygrade, but if it's public domain, as has been argued by others, I don't see how it doesn't fall under the same requirements as other public domain content. -- LWG ^{talk (VOPOV)} 20:31, 6 February 2026 (UTC)[reply]

  Copying a string of text from an LLM is no more plagiarism than copying a random string of numbers from a random number generator Czarking0 (talk) 20:15, 10 February 2026 (UTC)[reply]

• Could we get a very simple brightline rule of "editors may not use LLMs for paid editing"? This includes the edits themselves, the disclosures, and addressing concerns about the edits on talk pages. Hopefully that's a simple, brightline, "don't speed with a body in the trunk" type rule. Tazerdadog (talk) 22:15, 5 February 2026 (UTC)[reply]

  Um, have you seen the various uproars at Wikipedia:Administrators' noticeboard § OKA: problematic paid translation and lead rewrites via LLMs across thousands of articles.? I fear a simple brightline is unachievable where LLMs are concerned. ClaudineChionh (she/her · talk · email · global) 11:55, 6 February 2026 (UTC)[reply]

  I think that is a very good example of why such a bright-line rule is desirable. The imbalance of time between a paid editor using an LLM and volunteers reviewing manually is untenable. Tazerdadog (talk) 00:58, 7 February 2026 (UTC)[reply]

  To quote from there

• Looks like some kind of rate limiting would've helped. Alaexis_¿question? 12:19, 7 February 2026 (UTC)[reply]

  Maybe we can encourage them to go work on Crockipedia instead? ← Metallurgist (talk) 19:19, 10 February 2026 (UTC)[reply]

you probably had that moment where you've been in a few conversation and now suddenly can't find your actual edits easily, your edits would be separated into 2 main types, being edits (edits to articles normal people read) and posts (talk page and forum edits, like the one here now for editors to talk), this would make navigating edits easier, there could also be a option to make it like how it is now in preferences Misterpotatoman (talk) 19:33, 5 February 2026 (UTC)[reply]

This actually already exists!

On your contributions page, open the "Search for contributions" drop-down menu. There is another drop-down menu labeled "Namespace". This allows you to filter your edits by namespace.

Choose the one labeled "(Article)" to see mainspace edits (edits to articles), choose "Talk" for article talk page edits, and choose "Wikipedia" for edits to projectspace, which includes discussion pages like this one. SuperPianoMan9167 (talk) 20:32, 5 February 2026 (UTC)[reply]

i know, I just want them to be separated by default so i don't have to separate them myself, id find it quite hard to miss the giant button that says "Search for contributions" Misterpotatoman (talk) 22:36, 5 February 2026 (UTC)[reply]

I'd support splitting them for the same reason, the same way pings are split out from general notifications. It would simplify things. ChompyTheGogoat (talk) 11:31, 8 February 2026 (UTC)[reply]

I for one would support having the A user with N edits. Account created on DATE text on the Contributions page print the user's mainspace edit count, rather than their total edit count. If nothing else it would sidestep a reoccurring source of confusion at WP:PERM when editors see that they need 500 edits, check their contributions and see N>500, then get berated by a bot because actually their mainspace count is too low. _signed, Rosguill ^talk 22:59, 5 February 2026 (UTC)[reply]

just because the talk space edits don't contribute to edits till 500 edits doesn't mean they should be discounted, having them listed separately would still mitigate the confusion generated from talk space edits Misterpotatoman (talk) 23:14, 5 February 2026 (UTC)[reply]

Independent of changing edit count displays, if this is a source of regular confusion, are there parts of our instructions that should be changed to specify "mainspace edits"? CMD (talk) 04:02, 6 February 2026 (UTC)[reply]

I almost wish there wasnt an edit counter, or it was more buried. There is some issue with gaming the numbers to reach high edit counts, but that also crosses over with prolific editors who actually are doing good things, not just trying to reach a high edit count. For me, quality over quantity, altho I have done minor edits in larger quantity, but its not a regular thing. ← Metallurgist (talk) 19:23, 10 February 2026 (UTC)[reply]

This seems like something that would have been discussed in the past, but I haven't seen any discussions so here goes...

Quick caveat: I'm just recently getting back into Wikipedia editing, so there's a good chance I'm not up to date on how some of this stuff works - so take the below with a grain of salt.

Many (most?) categories on Wikipedia (and likely on other sites like Commons) look to me like they could be automatically generated by querying WikiData.

For example, take https://en.wikipedia.org/wiki/Category:Albums. This category could be easily represented with a WikiData query - "Give me all Wikipedia pages that correspond to 'instance of' 'album'".

For another example, take https://en.wikipedia.org/wiki/Category:Against_Me!_songs. Corresponding WikiData query: "Give me all Wikipedia pages that correspond to 'instance of'='album', where 'performer'='Against Me!'"

Another non-music example: https://en.wikipedia.org/wiki/Category:People. Corresponding query: "Give me all Wikipedia pages that correspond to 'instance of'='person'".

Over the long-term, I think it would be way more scalable and maintainable to generate Category lists automatically using WikiData, rather than requiring editors to manually keep these up to date.

Benefits:

• Saves time for editors with adding categories. As long as pages are tagged with the relevant properties in WikiData, editors don't need to go into the "Category" section and select appropriate Categories for pages.
• Categories should become vastly more accurate/comprehensive over time. As far as I understand, accuracy of Categories currently depends on editors putting manpower into manual categorization. Instead if we can rely on our data and generate the Categories based on the data, the Categories should start to maintain themselves.
• Nudges editors in a more productive direction.
• ---- Current state (to my knowledge): If a page is missing from a Wikipedia category, the editor is encouraged to manually add the page to that category on Wikipedia, on a specific language Wikipedia.
• ---- If automatic categories are implemented: Editors are encouraged to fix the underlying metadata in WikiData - which provides more flexibility/value overall.

• This should make it easier for different languages to benefit from WikiData/categories. Rather than each wiki maintaining its own set of Categories, if the data is all centralized in WikiData and Categories are automatically generated, then every language wiki could benefit from the same Categories I'd think.

Another option:

Another possibility would be allowing let users to associate a WikiData query with a manually-created Category. Then, let the user click "run query" to get back a list of pages from the query. This would let the user compare the manually-curated pages in the Category to the query-generated Category pages.

Another option:

Create an alternative type of Category (maybe call it "auto-generated Categories" or similar) to fulfill this need, rather than messing with/impacting the existing Category system. And allow users to look at Categories and Auto-generated Categories side-by-side. This could be a beta feature for awhile, invisible by default until the bugs are worked out. Ancient9983 (talk) 10:42, 9 February 2026 (UTC)[reply]

I like this idea, and suggest that it not really be "automatic categories", but more like "automatic suggestions". It might be more valuable to Commons. WhatamIdoing (talk) 23:31, 10 February 2026 (UTC)[reply]

Hello, this is exactly the subject of Wikidata discussion: How can Wikidata be useful IRL if it has less data than Wikipedia? and in some way also m:Contradictions within Wikimedia projects. I'm intending to create a page on Wikidata about this topic which aggregates all the info about this subject.

A problem there is that other than what you may expect, Wikipedia usually has more structured data in categories than Wikidata. This is because there's only few users only running few and usually very limited bulk data imports and because data in Wikipedia is not systematically imported to Wikidata. A tool to do so is the HarvestTemplates tool which can get data from temples into Wikidata but it has issues and nobody is developing it further and is only about templates anyway.

For the other direction of Wikidata->Wikipedia, a tool to do this is petscan & list-building tool & listeria (forgot which of these is best suited) as described in this video. However, it requires quite some time, manual reruns to update things, and most importantly doesn't scale and is limited to highly-motivated highly-active technicallyskilled users. On Commons, automatic addition based on Wikidata is done via the Wikidata infobox template. However, it only adds a small subset of categories which have been requested individually on the talk page which has lots of requested in need for volunteer developers to help out with. For example, I requested the addition of automatic categories for software categories for the data on which programming language it was written in and things like that which were recently added. And I requested the birth year and death year categories to be added by the template which are currently added by contributors manually (0 replies so far). Note that this only works for categories that have a Wikidata item and were linked to it.

Over the long-term, I think it would be way more scalable and maintainable to generate Category lists automatically using WikiData, rather than requiring editors to manually keep these up to date. What it needs imo are ways to keep both in sync. That will also surface contradictions and thereby enable seeing & fixing flaws (see link above). Categories are created by Wikipedians. Categories part of a series (such as a category for every year) could also be created automatically (e.g. the one for 2026). Also note that a surprisingly large fraction of Wikidata items, including many linked to popular broad articles that are well categorized, do not have their key or any instance of and/or subclass of properties set and not very rarely are the ones set false.

then every language wiki could benefit from the same Categories I'd think. Please see Wish375: A tool to copy Wikipedia categories to another language Wikipedia. Note that it's not useful but problematic if you create finely subcateegorizing categories when the respective Wikipedia doesn't have so many articles to make that useful. A wikipedia with articles on just 3 books published in a year may not want to subcategorize them by genre for example.

allowing let users to associate a WikiData query with a manually-created Category That would be great and I meant to propose sth related to this regarding incomplete Commons categories.

Create an alternative type of Category (maybe call it "auto-generated Categories" Maybe the wish 375 could be extended with this idea. I don't think English Wikipedia in specific would have a lot of reasonable/useful auto-generated categories that aren't yet categories so I don't think this would be useful here. Prototyperspective (talk) 15:04, 12 February 2026 (UTC)[reply]

I agree about not over-categorizing subjects. First, it's not practical to drill down through a dozen cats to find a nearly empty category like "Category:British detective books published in 1952" at the end. Very small wikis might benefit from not having too many categories beyond the very basic list in mw:ORES/Articletopic.

Second, people might actually prefer a Wikipedia:Category intersection approach (how most modern websites work, e.g., if you go to a real estate website and filter for houses of a particular size and price), and putting detailed individual cats on the page. In that case, you want Category:British publications, Category:Detective books, and Category:1952, and the rest can be sorted out from there. WhatamIdoing (talk) 01:26, 14 February 2026 (UTC)[reply]

The second point is an interesting subject where there's quite some potential for improvements/developments I think. Here one can theoretically already use the deepcategory search operator which is far too unknown, underused and not integrated anyhow (eg into the search page). Problems with it are:

• It fails or only shows results up to a certain limit for large categories like deepcategory:Science (where one would have to use petscan or similar) but it actually works for deepcategory:1952 which also is a quite large cat with 41,566 articles. Also worth noting is that still many articles miss key categories (or have only too broad categories instead of being in the category about exactly the article's topic).
• Often, there are some miscategorizations. A tool to see why an article is somewhere underneath a category would help improving or fixing the categorizations and I requested such here (voting open) albeit focused on use for Commons. But even if such a tool is built and it's widely used by people to improve categorization, there probably are still quite many flaws (it always depends on the category). The miscategorizations often limit the usefulness or accuracy of the cat intersection/filter.
• Relevant categories are difficult to know or find and not eg suggested on the category page to create dynamic filtering. Currently people would have to know about the deepcat search operator and then manually type what intersection they have in mind into the search bar.

Prototyperspective (talk) 14:31, 14 February 2026 (UTC)[reply]

Unfortunately one problem I see here is how bad the current user interface is for Wikidata. Realistically unless it was completely overhauled to be more user friendly I personally would not want to have to edit Wikidata just to update something on Wikipedia. -- LCU ActivelyDisinterested «@» °∆t° 18:06, 13 February 2026 (UTC)[reply]

Other than the missing button to add a statement at the same place at the top (phab:T142082), which issue(s) do you see with it? The input fields already have autocomplete and also show the possible/expected properties to enter first (or only). One problem maybe is navigating to instances that are subclasses or things like that – do you mean such navigational things? If any of what the user suggested was implemented I'd imagine sth to add things to a dynamic category could be shown directly on the category page on Wikipedia without having to go to Wikidata.

In any case, it seems more reasonable to let changes to Wikidata trickle down into Wikipedia(s) and changes here to trickle up to Wikidata. @Ancient9983 I suggest to sometimes create sparql queries for the things you have in mind like "Give me all Wikipedia pages that correspond to 'instance of' 'album'" with that you'll often see if you compare it to the Wikipedia category that oftentimes Wikipedia is more complete (even when Wikidata has some items that are missed in Wikipedia). You can somewhat easily create such queries with this. This should make it easier for different languages to benefit from WikiData/categories. Rather than each wiki maintaining its own set of Categories If the Wikipedias' changes via categories and infoboxes are synced to Wikidata then the same thing is achieved without substituting categories. The categories retrieved from Wikidata could also be 'WD suggested categories' that are only added as normal categories when users here review them by going through the backlog. Prototyperspective (talk) 18:42, 13 February 2026 (UTC)[reply]

I mean that the whole interface needs to be chucked out and redone, and that noone should have to edit Wikidata to edit Wikipedia. It's a shame that the bridge to backflush data from Wikipedia to Wikidata hasn't been created, as it would solve this issue. No amount of tinkering with the current Wikidata interface will solve the problem. -- LCU ActivelyDisinterested «@» °∆t° 20:31, 13 February 2026 (UTC)[reply]

I have to agree with ActivelyDisinterested on this. When I look at a Wikidata page, I find it completely incomprehensible to me. It might as well be in ancient Sumerian. If I wanted to edit it, I would not even know where to begin. I don’t even understand how it is structured.

So… I tend to be wary of any attempt to integrate the two projects. And I strongly oppose any proposal that suggests that we would have to go to a Wikidata page to make a change appear on a WP page. Less adamant going the other way… but still wary. Blueboar (talk) 02:10, 14 February 2026 (UTC)[reply]

Well I have to say such criticism isn't as is quite constructive. It's unclear. But if you can explain it more clearly maybe some things could be improved there. It's very unlikely the whole interface will be fully overhauled to sth entirely different. I always found it quite self-explanatory and don't know what you don't understand about it. It's as simple as this:

There are 'items' which can have Wikipedia article links. Other than such links they're composed of Property:Value statements. For example, Instance of: Building. It's as simple as that. To make it complete and you don't really need to know this early, there are also Qualifiers for Values. One example for that is Language: English (for example if the Value is a website URL). If you want to edit you need to as said click the "add a statement" button on an item or if you want to create a new item in the left main menu panel select "Create a new Item". I don't think arguments the UI is that incomprehensible hold water in the face of this simplicity. People say the same about Wikipedia; well you got to actually go ahead and use it and try – then the things you need to know will quickly become simple. Nevertheless, I don't support requiring users to go to Wikidata anyway. Prototyperspective (talk) 12:08, 14 February 2026 (UTC)[reply]

Hello. [I have not seen much of the inner workings of Wikipedia previously, so please excuse me if my letter format, including the compliments preceding my idea, is thought of as superfluous.]

Thank you all for all of your efforts collectively for 25 years.

It's apparent that you've made several advancements in the past couple of years regarding your site's appearance, specifically in the ability to manage content organization.

I have a suggestion just regarding the overall visual, and it should be fairly simple, because of the CSS layer of website code. It might take even a single change effecting all of your pages.

Wikipedia has always conveyed with its bare appearance that it was set up in someone's spare time, even though the content elements have become very sophisticated.

But given that you're touting your 25 years, and drawing attention to your extensive processes and the many people involved, a slightly fancier presentation appears long overdue.

Please make the background of your pages a faint beige. It adds a touch of class and generally makes text easier to read, given that it provides a tiny bit less contrast, as black on white glows fairly quickly. Color #FFFEF5 is an example.

With the various options that you've been adding, including the dark option (which takes contrast to its own level), maybe you'll feel it best to make this an option.

Thanks for your time and consideration. ~2026-90420-1 (talk) 04:31, 10 February 2026 (UTC)[reply]

Making it an option doesn't seem too bad to me, however I wonder what others think about this. Cdr. Erwin Smith (talk) 07:00, 10 February 2026 (UTC)[reply]

Personally, I've never quite understood why people want everything to be grey-on-grey rather than adjusting the brightness of their display if things are too bright for them. Anomie⚔ 12:47, 10 February 2026 (UTC)[reply]

Just to keep thoughts on the actual suggestion, it's all of the existing colors on beige, not grey on grey. And darkening your display lessens all of the colors, so it actually makes things more grey on grey.

Also, this isn't about every other website or every other application, most of which don't have this problem. This is about Wikipedia. So, it's inappropriate to adjust your display for just Wikipedia windows.

And this isn't a random suggestion; it's an actual step that has improved readability in various presentations. A hint of beige just makes everything less harsh and helps people to keep reading, which is the intent. ~2026-90420-1 (talk) 15:48, 10 February 2026 (UTC)[reply]

If we want to make it an option, we should probably take this to Meta-Wiki or MediaWiki wiki so that it would be on all Wikimedia projects. ✨ΩmegaMantis✨^(he/him) ❦blather | ☞spy on me 21:00, 10 February 2026 (UTC)[reply]

m:Community Wishlist/Wishes is the place to go. Ponor (talk) 19:14, 11 February 2026 (UTC)[reply]

Old people here remember the times when #ffffec was the background color for non-mainspace pages. sapphaline (talk) 16:10, 10 February 2026 (UTC)[reply]

I'd prefer a #FFF8E7 myself to gain street cred with the astronomy nerds. :) ✨ΩmegaMantis✨^(he/him) ❦blather | ☞spy on me 21:11, 10 February 2026 (UTC) [reply]

The Wikipedia app (at least on iOS) has a sepia tone option. It could be smart to add it to the web version. ✨ΩmegaMantis✨^(he/him) ❦blather | ☞spy on me 20:55, 10 February 2026 (UTC)[reply]

One idea I have toyed with in the past is going the other way, applying a very light tint for non article pages - a pale green for draft pages, a pale red for old revisions, or something like that. Enough to make it visible at a glance that a reader is not looking at an actual live article. Never got around to mocking up some CSS for testing it, though. Andrew Gray (talk) 21:02, 10 February 2026 (UTC)[reply]

That would be quite useful, though I could see people getting annoyed about it. Interestingly, when I use the Wikipedia app, I have mode set to sepia tone, but since pages in the Wikipedia namespaces and some other namespaces aren't exactly supported as in app mode and just open a mobile version, the background turns white and so I get a version of what you are describing, in reverse. ✨ΩmegaMantis✨^(he/him) ❦blather | ☞spy on me 21:07, 10 February 2026 (UTC)[reply]

@Andrew Gray I could have sworn that back in 2006 or 2007, non-mainspace pages had a light blue or green background. ~ ONUnicorn^{(Talk|Contribs)}problem solving 21:30, 10 February 2026 (UTC)[reply]

@ONUnicorn ...you know, it wouldn't surprise me if I have been working off a hazy memory of that! It doesn't seem to be the case for any of the main ones listed at Wikipedia:Skin (I tested them all on WP, WPT, and mainspace) but possibly it was there for a period and off again. Andrew Gray (talk) 23:25, 10 February 2026 (UTC)[reply]

Monobook still does. Anomie⚔ 00:15, 11 February 2026 (UTC)[reply]

"Chick", "Standard", "Nostalgia" and "Simple" used to change the color for non-mainspace pages to #ffffec by default until their deprecation in 2013; Cologne Blue still does this, also by default (for example). Monobook doesn't do this by default, it's an old on-wiki customization. sapphaline (talk) 10:32, 11 February 2026 (UTC)[reply]

Wikipedia has always conveyed with its bare appearance that it was set up in someone's spare time. Nothing wrong with that. Phil Bridger (talk) 23:27, 10 February 2026 (UTC)[reply]

Thank you very much for showing all of the colors that have been mentioned. And it's interesting to see that the text color isn't quite black. Regarding the exact shade of beige, it should just be kept in mind that the color as an entire background seems darker than a box sample, and I think that subtlety might be most effective for extended reading. --- Also, to help get this implemented, for the most common situation, is it best to keep it as simple as possible? The other ideas that are building on the idea to just change the standard background appear to be helpful for more-specific situations, so they might be best as separate options. --- For the vast majority of the situations, the other ideas might be overwhelming to users. This includes that users might not understand why they're seeing differing backgrounds. For that purpose, it actually might be most helpful to have a clearly worded (and distinctly colored?) banner at the top of the content for unusual types of content. ~2026-90420-1 (talk) 14:48, 11 February 2026 (UTC)[reply]

So people can see the colors being mentioned:

•   #FFFFFF (actual white)
•   #FFFEF5
•   #FFFFEC
•   #FFF8E7
•   #F8FCFF (MonoBook)
•   #202122 (normal text on wiki)
•   #000000 (actual black)

WhatamIdoing (talk) 23:46, 10 February 2026 (UTC)[reply]

I appear to have replied to the wrong message, above. It might be helpful for this message board to have a horizontal separator line after each non-indented (top-level?) message. In any case, I've pasted my message here: --- Thank you very much for showing all of the colors that have been mentioned. And it's interesting to see that the text color isn't quite black. Regarding the exact shade of beige, it should just be kept in mind that the color as an entire background seems darker than a box sample, and I think that subtlety might be most effective for extended reading. --- Also, to help get this implemented, for the most common situation, is it best to keep it as simple as possible? The other ideas that are building on the idea to just change the standard background appear to be helpful for more-specific situations, so they might be best as separate options. --- For the vast majority of the situations, the other ideas might be overwhelming to users. This includes that users might not understand why they're seeing differing backgrounds. For that purpose, it actually might be most helpful to have a clearly worded (and distinctly colored?) banner at the top of the content for unusual types of content. ~2026-90420-1 (talk) 14:53, 11 February 2026 (UTC)[reply]

Iff this was to be implemented, it should definitely be an opt-in setting just like the Dark mode.

Bikeshedding on the precise background colour, it would make sense to use the same as the Sepia theme in the Wikipedia apps: currently #F8F1E3  . the wub "?!" 17:54, 11 February 2026 (UTC)[reply]

Thanks for the exact Sepia shade sample as well. Does everyone like the slightly darker Sepia or a slightly lighter beige? What shade seems to make the text easiest to read? --- And hey, let's talk about the birds of Europe! ~2026-90420-1 (talk) 20:53, 11 February 2026 (UTC)[reply]

  is too subtle, it would make almost no difference at all.

  looks better than the former, but a bit too dark.

  is a lighter version of the former, and looks ideal to me. But hey, it's just me. Cdr. Erwin Smith (talk) 08:25, 12 February 2026 (UTC)[reply]

Okay, I'm sorry about this. I originally copied the wrong color code. I've actually been looking at EEEDDC in another window the whole time. Its tint is more brownish than the Sepia, which is a little bit peachy. And it actually seems close to the third color in the above message. (For anyone who doesn't have access to web code, the color code can be put in Word's Page Color > More Colors > RGB option to see it at scale.) ~2026-90420-1 (talk) 12:43, 12 February 2026 (UTC)[reply]

That's all right.

Since we have had a good discussion, I would now recommend you to open an RfC on the Proposals Tab.

Be sure to add all 4 of the colour options, 3 here and 1 here, for a comprehensive debate. Cdr. Erwin Smith (talk) 07:10, 14 February 2026 (UTC)[reply]

This is really interesting - I had been looking at these on my desktop and thinking, huh, they're all the same blank white, is it a really imperceptible shade? But on the phone they're all very distinct. I wonder what configuration weirdness I have going on here. Andrew Gray (talk) 21:13, 11 February 2026 (UTC)[reply]

Multiple reasons. First of all.. by default a lot of LCDs for home computing are calibrated to emit WAY too much light and are also not adaptive to your surrounding light situation. It can pay off to spend some time to actually calibrate your screen (like it tells you to in the setup manual that no one ever reads). Mobile phones and often TVs as well are adaptive and will change their light intensity on the fly. This makes sense because they have to deal with a lot of changes during the day due to changing light conditions. In a work environment, you often want a more consistent color profile, instead of something that changes all the time.

Secondly: LED vs LCD. Expensive TVs and phones often have LED screens. LCD screens have to illuminate the entire back of the screen with light, even in the black areas. Combined with oversaturation of light LCDs will be more effected by not well calibrated screens.

Thirdly: Desktop and laptop screens are often pretty bad. Mobile phones are, due to their size (easier manufacturing) and the competitiveness in the market often higher quality, with shorter lifetime cycles. While in the laptop and desktop market the screen is an expensive part that can easily be saved on by manufacturers, with most consumers not really realizing what they are missing in return.

For instance, my home Desktop screen is a 600+ euro 27" LCD (when I bought it 6 years ago), which will show these color differences. But my (newer) workplace 27" LCD is a much cheaper LCD and unless I do a lot of calibration on it, is often not able to show the difference between these colors.

If you wonder why all designers use MacBooks... this is part of the reason. MacBooks by default, tend to come with better screens than most other consumer computers. If you order online and know nothing about screens, with Apple you sorta know what you are getting, whereas with most other brands it will be a complete toss up.

This is also why I always tell everyone over 40 to buy a better monitor, because using a better screen will literally change your life when your eyes start getting worse. —TheDJ (talk • contribs) 14:44, 12 February 2026 (UTC)[reply]

@TheDJ Thanks - I think this will be this evening's rabbit hole to go down! I am indeed over 40, and I strongly suspect this monitor is at least old enough to be thinking about its exams... Andrew Gray (talk) 18:45, 12 February 2026 (UTC)[reply]

For the record, I support such customization for logged-out users, and honestly Vector-2022 maintainers should provide an option for them to set any background and on-text color they want. sapphaline (talk) 10:38, 11 February 2026 (UTC)[reply]

@Sapphaline Such customization is of course possible with CSS variables. There are some 50+ of them that you can override and mess with if you want. This is precisely how dark mode works for instance. Just install an extension that modifies them, or use the browsers local styles, something like Greasemonkey etc. People can do whatever they want by following a few YouTube tutorials. However compiling and maintaining multiple of such sets of 50+ variables is a pretty expensive operation and its is very easy to introduce problems with accessibility etc. That's why it is left up to users to do this if they want to. —TheDJ (talk • contribs) 14:52, 12 February 2026 (UTC)[reply]

Please do no such god damned thing. The clean white background is far classier. --User:Khajidha (talk) (contributions) 22:38, 18 February 2026 (UTC)[reply]

It'll be an option : ) Cdr. Erwin Smith (talk) 05:50, 19 February 2026 (UTC)[reply]

Since autoblockiing bots can unintentionally block WMFLabs or cause other collateral damage, I think we should have a bot that automatically disables autoblock for users with the bot flag. Toast1454_TC 13:10, 10 February 2026 (UTC)[reply]

This is the best I can do with information gleaned from block logs on some bots. Toast1454_TC 13:11, 10 February 2026 (UTC)[reply]

Has there ever been a discussion on making all BLPs ECR? This has always been an issue on Wikipedia with IPs (now TAs) and new users making drive by BLP edits that can be promotional or defamatory. Making them all ECR would probably help with that by ensuring editors are here for constructive purposes, and in the longrun help with reducing VRT workload responding to issues. Thoughts on this? Is it silly? Does it make sense? ← Metallurgist (talk) 19:29, 10 February 2026 (UTC)[reply]

I think it would be easier to convince the community to attempt a WP:SEMI, but I'm not sure that even that would work. The fact is that while some unregistered and brand-new accounts cause problems, many more are actually helpful. Half of our current admins and other long-time experienced editors began editing as IPs, and cutting off that entry point might mean cutting off the next generation of editors, which we need. WhatamIdoing (talk) 23:50, 10 February 2026 (UTC)[reply]

Category:Living people has 1,139,680 articles with the category. Which means about 1/7th of all articles are BLPs. If there needs to be a mass protection of BLPs, pending changes would be the best option, but that would cause an absolutely huge backlog at Special:PendingChanges. 45dogs (they/them) (talk page) (contributions) 03:46, 12 February 2026 (UTC)[reply]

The majority of edits from new and casual editors are updates, expansions, and minor tweaks though admittedly sourcing quality is quite-variable. Defamation is usually reverted promptly, and historically the worst cases of negative content lingering were the result of registered users who had solid bureaucratic acuity and built up social capital they were unafraid to spend.

Even with the vast majority being unprotected updates are typically quite sporadic and many pages are written and never edited beyond basic maintenance; protection will worsen that issue. ~2025-41540-19 (talk) 04:41, 12 February 2026 (UTC)[reply]

I wouldn't support any new wide-ranging restrictions, in principle, until it can at least be demonstrated they wouldn't upset the somewhat stable equilibrium of Wikipedia's active editor pool. Dege31 (talk) 04:51, 12 February 2026 (UTC)[reply]

I fully support your suggestion. Convincing people to implement it is of course another issue. Yesterday, all my dreams... (talk) 12:15, 14 February 2026 (UTC)[reply]

Given the stance of Wikipedia on the matter of copyright, it is not possible for Wikipedia itself to host and manage a publicly viewable archive of webpages being cited. The situation with archive.today should be a wake-up call to better plan out how to deal with this matter. However, Wikipedia can develop, or at least endorse, a decentralized/distributed alternative archive: where the editors can use the developed software to store the DOM tree and/or screenshot of the webpage on IPFS or equivalent content-addressed cache, where we can use cryptographic hash to verify the authenticity of the cited material. This should also reduce dependence on Internet Archive moving forwards. Some volunteers can use copyright-havens (an allusion to tax-havens) to host a gateway to this decentralized archive, avoiding DMCA takedowns and such, in the manner of Sci-Hub, Libgen etc. (It is also of interest how the courts will decide on scraping of the internet to obtain training data for LLMs.)

What are the current state of the art in this direction? What do we need to do if we choose to go in this direction? What are some other viable directions to consider in this regard?

Smlckz (talk) 11:38, 12 February 2026 (UTC)[reply]

"What are some other viable directions to consider in this regard?" - I think SingleFile is worth having a look at. sapphaline (talk) 12:12, 12 February 2026 (UTC)[reply]

Sounds like a fun research project for someone who has the time for that. Would definitely encourage whoever wants to work on that. —TheDJ (talk • contribs) 14:54, 12 February 2026 (UTC)[reply]

I don't love the idea of Wikipedians setting up a massive copyright infringement site. Archive websites like .today are based in countries with lackluster copyright laws and use a variety of illegal methods for capturing copyrighted content. IA can get away with it since they're a non-profit which responds to takedown requests and respect the wishes of sites blocking it. The whole point of the Wikimedia movement is sharing free content, not coming up with ways to get around copyright law.

I'm not opposed to someone making a site like this, I don't really care. I just don't the idea of us developing or "endorsing" a project like this. IsCat (talk) 15:29, 12 February 2026 (UTC)[reply]

There's nothing wrong with copyright infringement as long as it's not hosted on WMF's servers. sapphaline (talk) 16:26, 12 February 2026 (UTC)[reply]

I mean, copyright infringement is illegal. I don't think it's smart to just ignore that.

Apart from that, WP:COPYVIOEL prohibits the addition of links that are knowingly in violation of copyright. To quote that page: If there is reason to believe that a website has a copy of a work in violation of its copyright, do not link to it. Linking to a page that illegally distributes someone else's work casts a bad light on Wikipedia and its editors. It's difficult to argue that the proposal here wouldn't fall under that. IA is acceptable because we can assume fair use, the same isn't true for this proposal (or even .today). IsCat (talk) 16:31, 12 February 2026 (UTC)[reply]

"copyright infringement is illegal" - "illegal" doesn't mean "unethical" or even "wrong". "IA is acceptable because we can assume fair use" - we can't. sapphaline (talk) 16:35, 12 February 2026 (UTC)[reply]

I never said copyright infringement is unethical. We live in a world full of laws and we have to follow them. IA themselves says that web archiving, at least the way they do it, is "broadly considered" to be fair use, see here. I don't think that's been challenged in court directly as IA has done takedowns and allows sites to exclude themselves. Perhaps we should keep it that way. IsCat (talk) 16:46, 12 February 2026 (UTC)[reply]

We live in a world full of laws and we have to follow them. If LLM scraper bots can get away with taking copyrighted materials as training data, using it for commercial purposes, does it make us a fool of ourselves for still following the law? By your own take, the use of .today links amount to violation. For not being sued for contributory copyright infringement by linking to .today links for so long, did we assume fair use in the manner of Internet Archive does? How do we then balance verifiability of cited matrials and still following law by not linking to archival sites? Smlckz (talk) 17:16, 12 February 2026 (UTC)[reply]

does it make us a fool of ourselves for still following the law? I don't think "someone else broke the law" is a good reason to break the law yourself. There are ongoing lawsuits relating to the copyright status of LLMs, and I'm sure we will have more clarity in that field soon.[1]

By your own take, the use of .today links amount to violation. Maybe. By my understanding, .today processes takedowns of singular archives but not entire sites. They do, however, run ads on mobile. I'm not a copyright expert and I don't want to be seen as making a determination, but .today is at the very least in a gray area. You could say the same about IA, but their willingness to exclude sites and not intentionally get around paywalls, as well as being a non-profit, makes their argument of fair use much stronger.

I'm not here to be super strict on copyright and demand that we stop using archival sites, I just do not believe it is wise to make the project dependent on shady, gray area tools like .today. Web archivers are necessary for producing the encyclopedia, so we can't drop all of them. Sticking with the ones with the strongest copyright policy is our best bet. IsCat (talk) 17:31, 12 February 2026 (UTC)[reply]

Virtually everything on the wayback machine is a copyright violation and it meets none of the American requirements for fair use. Doing partial takedowns if anything makes their case worse because they are aware the rest is infringment but keeping the rest of fheir collection. Just because they obey takedown requests does not make it not infringement, it just means they may not face as severe legal repercussions. PARAKANYAA (talk) 18:28, 12 February 2026 (UTC)[reply]

I mean, yeah. There is a good argument that IA is copyright infringement. They don't legally have an obligation to patrol their site for copyright infringement, only to respond to it if they receive a takedown notice. This was a key issue in Viacom v. YouTube, where YouTube was found to not liable for violations of Viacom's copyright as they responded to takedown requests and was thus protected as a service provider under the DMCA. This doesn't meant they weren't hosting content that infringed copyright (they were), it was just that they weren't liable. IA is in a similar situation, they may be violating copyright but they respond to takedowns and there isn't any caselaw over the fair use status of web archiving. Thus, they can operate under the assumption that they are not violating copyright, even if they are. IsCat (talk) 18:38, 12 February 2026 (UTC)[reply]

Sure, IA will probably not crumble into dust tomorrow. But neither will .today. The issue people are raising is that the material we are linking to is a copyright violation. There's plenty of caselaw over both library archiving and internet copyright that makes this situation not ambiguous. Whether IA will be fine is irrelevant. PARAKANYAA (talk) 18:43, 12 February 2026 (UTC)[reply]

Yeah, I didn't raise copyright in my !vote on the .today RFC for this reason. My main concern here is making a potentially Wikipedia-affiliated archival platform that is not responsive to DMCA requests, which is what this thread is proposing. That site would be liable for copyright infringement under the DMCA, and the proposed solution is trying to make it impossible to enforce the law against the site. It's a bad idea all around. If someone out there wants to make that site and potentially assume liability for copyright infringement, they can do that. It would be a violation of COPYVIOEL to link to it on WP either way. IsCat (talk) 18:53, 12 February 2026 (UTC)[reply]

Well the WMF can't make it but linking it wouldn't be any worse than linking IA. Whether is a copyright violation is unaffected by the DMCA takedown, that is just the enforcement mechanism. PARAKANYAA (talk) 19:32, 12 February 2026 (UTC)[reply]

IA can operate under the assumption that web archiving is fair use because there isn't caselaw that clarifies either way. We can assume the same. IA responds to DMCA takedowns and is thus protected by section 512. The archival site herein proposed would not respond to DMCA takedowns and would not be protected by section 512. Linking Google Books is entirely different than linking Anna's Archive for much the same reason. IsCat (talk) 19:36, 12 February 2026 (UTC)[reply]

That they comply with DMCA takedowns shows awareness that the content on their site is copyrighted and not fair use. So, we can assume that it is copyrighted by the same. Again, whether someone is protected by section 512 is entirely about punishment or not punishment, it is not about whether the materials at issue are fair use. PARAKANYAA (talk) 19:41, 12 February 2026 (UTC)[reply]

They can accept DMCA takedowns while not admitting liability or that they host other infringing content. Section 512 does protect from certain liability, including from lawsuits. This limits the options of rightsholders and more or less forces them to use the takedown system. This has kept web archiving out of courts and has caused the lack of caselaw in the area. Without caselaw, IA can assume that they aren't violating any laws. IsCat (talk) 19:48, 12 February 2026 (UTC)[reply]

Yes, their liability is not the issue here. Whether they are liable or not is unrelated to whether the content itself is fair use/an infringement of the copyright holder's rights. And again: does this not go for any web archive, including the hypothetical one you take issue to? PARAKANYAA (talk) 21:05, 12 February 2026 (UTC)[reply]

I don't think you are understanding the point I'm trying to make. Liability matters a whole lot in lawsuits. The purpose of a suit is ostensibly to determine if an entity is liable or not for something. If IA is not liable for infringement, they will likely not get sued. If nobody is getting sued, there is no caselaw. If there is no caselaw, it's a gray area. IA claims fair use. Unless and until a court of law (or Congress) acts to determine if web archiving is fair use or not, they can continue to assume its legality. The presence of infringing content is entirely besides the point because we are assuming fair use.

As for the proposed archival service, they would be liable under section 512 as soon as they fail to comply with a takedown request. A defining feature of the proposal is hosting in foreign jurisdictions where copyright law cannot be enforced. IA and this proposal cannot be further apart in terms of liability. IsCat (talk) 22:00, 12 February 2026 (UTC)[reply]

That they comply with DMCA takedowns shows awareness that the content on their site is copyrighted and not fair use.

No, it shows awareness that some content on their site may be copyrighted, just like any site that allows user contributions. Legally that's a huge difference. It doesn't matter whether it's 99% copyrighted, or 99% original with only a single copyrighted item, as long as they do respond to takedowns. That's the legal obligation and the reason they aren't liable, the same way Facebook isn't liable for user content as long as they respond similarly. ChompyTheGogoat (talk) 12:57, 14 February 2026 (UTC)[reply]

From what I can understand from the discussion here, IA honoring DMCA takedown requests shields them from liability of copyright infringements. So is the case with IPFS gateways. Then, can we link to pages archived on IPFS without problems, right? While the IPFS gateways honor the request, the content might still exist in the network, so those with need can still use the content ID to find it anyway.. Those with vested interest in maintaining an archive of internet can continue to pin the content in copyright-havens. Can this situation be any better? Smlckz (talk) 02:42, 13 February 2026 (UTC)[reply]

I mean, true. Plagiarism is wrong, which is why I use websites like Anna's Archive when tracking copyright violations on Wikipedia, which are (a) usually plagariasm (b) pose a licensing issue, since our content should be in our own words and CC-BY, not copyrighted text. Cremastra (talk · contribs) 00:30, 13 February 2026 (UTC)[reply]

Internet Archive is still copyright infringement no matter how much they get away with it. PARAKANYAA (talk) 18:22, 12 February 2026 (UTC)[reply]

I'm not disputing this, for the record. IsCat (talk) 18:28, 12 February 2026 (UTC)[reply]

You did say we can assume fair use, which I do not think is true. PARAKANYAA (talk) 18:31, 12 February 2026 (UTC)[reply]

You are also a well known copyright maximalist, to be blunt, who puts almost all power with rights holders. This is a strain of thought you can find, particularly in Europe. But courts in America tend to be less severe and more generous with public benefit. -- GreenC 19:16, 12 February 2026 (UTC)[reply]

I do not like copyright. I am, if anything, a copyright abolitionist. But that I want it to be a different way doesn't mean it is. PARAKANYAA (talk) 19:43, 12 February 2026 (UTC)[reply]

Copyright abolishment is an extremist position outside the mainstream. If that is your basis you might (consciously or not) try to pit copyright law against itself playing into the divisions to stoke and inflame. But please don't use Wikipedia for that end it is disruptive. -- GreenC 20:02, 12 February 2026 (UTC)[reply]

I am in favor of presenting reality as it is. PARAKANYAA (talk) 21:02, 12 February 2026 (UTC)[reply]

I don't think there is any need for endorsement by Wikipedia, just the need for some team to set such up. on IPFS or equivalent content-addressed cache sounds like a great idea. Anna's Archive already has links to IPFS-stored content, maybe some IPFS discussion place would be a good place to propose this. One could include in the proposal the idea for the archival site to archive all external links found/crawled on Wikipedia (that aren't yet archived in the Internet Archive and ideally these as well). Prototyperspective (talk) 15:52, 12 February 2026 (UTC)[reply]

One such place is [2] another [3] and maybe also [4]. I would not continue the discussion about legality or ethicality above (or the assumptions underlying the various claims for and against such) as there is no need for Wikimedia officially starting or backing this. Also forgot to mention that archive today is not just used for standard Web archiving but also for making paywalled content accessible. If you would like to debate this subject or to see more data & claims relating to it, see the structured argument map Do paywalls around academic publications slow scientific progress?. Prototyperspective (talk) 17:35, 12 February 2026 (UTC)[reply]

I asked in the IPFS Matrix channel, where they pointed me to [5], where reading through the documentation of [6] I found that it has "experimental support" for IPFS: [7]

I also found this project (which began a decade ago!): [8]..

Well.. it seems some solutions are already there, but are really obscured. Smlckz (talk) 04:41, 17 February 2026 (UTC)[reply]

Thanks for doing that – interesting. However, those aren't yet full solutions – rather potential components of potential solutions. A full solution would for example archive all external links used anywhere in Wikipedia using IPFS and then make these available using some website as well as regularly scan for new links. I think IPFS would probably be the best technology to use here but maybe there's some similar alternatives like ZeroNet(?) I wonder whether one could make a wish in the m:Community Wishlist for some tool that fetches all external links used in Wikipedia maybe from the dumps so that these can be all archived with a tool like the one(s) you linked which also would probably need to developed further for this to work and then be implemented in the project to archive all the links (except video media embedded in them) and make it possible for users to access them and store them decentralized. Prototyperspective (talk) 19:07, 17 February 2026 (UTC)[reply]

• Who says web archiving is a copyright violation? That's not totally true. It misunderstands how copyright works on the Internet. It also misunderstands library law and service provider law, which is not the same law as you and I operate under. There are specific statues in the law that allows for web archiving, when done a certain way, by certain parties. I have yet to see a single person on Enwiki who can explain why archive providers have operated for 30+ years and are not immediately shut for copyright violation. I understand why, but most people can not explain it. -- GreenC 17:42, 12 February 2026 (UTC)[reply]

  I'm not aware of any federal statutes that specifically allow for web archiving, could you cite what you're referring to?

  Your comment intrigued me so I found a law review article from Prof. Paul D. Callister, a professor of copyright and library law at the University of Missouri-Kansas City. You can read it here. In it, he claims that copyright law is fundamentally dissonant with archival practices. He notes that in a review of caselaw, he was unable to find any case were "preservation" were found to be transformative or fair use. He criticizes the claim that IA is somehow free from copyright infringement just because they've been around for so long, and he also notes that he was able to find any litigation against IA over web archiving. He argues that this is likely due to IA's strong takedown procedures instead of the law protecting IA. He concludes that it would be beneficial if web archiving was made to be fair use under law, but without a court deciding on the issue or Congress acting, web archiving will continue to be at the very least a gray area.

  If you could point me to differing viewpoints or caselaw/statutes that contradict this, that would be great. IsCat (talk) 18:12, 12 February 2026 (UTC)[reply]

  Also: I have yet to see a single person on Enwiki who can explain why archive providers have operated for 30+ years and are not immediately shut for copyright violation. I understand why, but most people can not explain it. Archival sites are understood to be service providers under section 512 of 17 U.S.C. and are thus not liable for monetary damages in a copyright lawsuit unless they fail to remove the content upon a takedown notice. This removes the incentive to file and has generally prevented courts from ruling on if web archiving is fair use or not. This allows IA to operate under the assumption of fair use, even if it does not actually exist under law. IsCat (talk) 18:24, 12 February 2026 (UTC)[reply]

  @IsCat I think you have a typo there: "he also notes that he was able to find any litigation against IA over web archiving". You probably mean "unable to find"... David10244 (talk) 06:12, 17 February 2026 (UTC)[reply]

  See, for example:[9] "The general problem for libraries, under the code section, is that they are only allowed to make archival copies of what they actually have in their collections.Footnote164 Neither Harvard’s law library nor registrant libraries are likely to own the Web materials that users contribute to the Perma.cc archive (although it is possible). Also problematic is several of § 108’s provisions require that the “copy … becomes the property of the user… .”"

  "The article concludes that Perma.cc’s archival use is neither firmly grounded in existing fair use nor library exemptions; that Perma.cc, its “registrar” library and institutional affiliates, and its contributors (see ) have some (at least theoretical) exposure to risk; and that current copyright doctrines and law do not adequately address Web archival storage for scholarly purposes." PARAKANYAA (talk) 18:23, 12 February 2026 (UTC)[reply]

  Those are legal arguments, and there are also counter arguments. The fact is, there is no law that strictly allows or strictly disallows web archiving. Web archives currently operate under a number of statues including: Fair Use, Section 512 DMCA Safe Harbor, and Section 108. Courts look at loss of commercial potential, the nature of the organization (non-profit library), the nature of the users (Wikipedia researchers and educational purposes). Honoring take down requests for DMCA. Courts exist to protect rights holders and public benefit. We see it in every case: Google Books was permitted to do mass scanning; Hatchet Case which gave Internet Archive a bunch of wins with out of print books and limited previews. Courts will protect interests beyond the rights holders, they find a balance, and the outcomes are complex and detailed. You can't make broad sweeping statements or ridged pronouncements that web archiving is an outright copyright violation. Even when it goes to court, it never turns out so simple because public benefit weighs heavily in court decisions. -- GreenC 19:04, 12 February 2026 (UTC)[reply]

  None of the four fair use criteria in the United States apply. They are reproducing the whole work, replacing the exact commercial market for the work, typically of commercial works. Being a non-profit might be considered in the balance of these factors but when the rest of the criteria are like this it is not a get out of jail free card. Per section 108, libraries can only archive materials they have in their collections, which is not The Web. DMCA safe harbor means they are unlikely to face significant penalty, sure, but that doesn't mean what is there is not a copyright violation.

  Google Books had the books they were scanning in their collection and did not allow readers to read the books in their entirety (e.g. it did not replace the commercial work and used a limited portion, unlike web archiving). The IA lost the Hachette case at every step of the way, "public benefit" or not. PARAKANYAA (talk) 19:38, 12 February 2026 (UTC)[reply]

  Your are repeating the most negative articles and opinions. And no they didn't loose every step of the way, again, you take extreme simplified black and white positions. -- GreenC 19:48, 12 February 2026 (UTC)[reply]

  How are they not replacing the market of the work or reproducing the whole work? PARAKANYAA (talk) 21:02, 12 February 2026 (UTC)[reply]

  I'm not even remotely well versed in the fair use doctrine, but surely if the web page is no longer accessible, the rightsholder isn't monetising it, so it's not competing? (Which still doesn't excuse copying extant webpages, though I'm sure a lawyer would argue that accessing a page through the internet archive is significantly less convenient than just going to the original, so it's not a substitute.) JustARandomSquid (talk) 09:15, 13 February 2026 (UTC)[reply]

  What is the commercial value of something you are not charging for? Hawkeye7 (discuss) 21:35, 13 February 2026 (UTC)[reply]

  Ads, exposure, a following, a good lawyer will come up with whatever's necessary, I'm sure. JustARandomSquid (talk) 22:27, 13 February 2026 (UTC)[reply]

  A copyright owner isn't required to be earning revenue from every way possible in order to protect its rights to use an approach in future. Also there are other ways to provide access to content than via the web. And if a rights holder chose to provide free access to their content, that doesn't mean it has relinquished its rights to control how that access is provided. isaacl (talk) 06:15, 15 February 2026 (UTC)[reply]

  Exactly. "Free as in beer" is not nearly the level of freedom needed to make a publicly accessible archive, and orphan works still enjoy full protection even though they are ridiculously problematic for potential researchers. DMacks (talk) 06:39, 15 February 2026 (UTC)[reply]

  Well, no, but it makes the respect for commercial opportunities part of the fair use argument much stronger. JustARandomSquid (talk) 07:34, 15 February 2026 (UTC)[reply]

  I disagree. For example, just because a book is out of print, or not being offered in an e-book format, doesn't mean it's fair use for someone else to create an e-book version. isaacl (talk) 09:26, 15 February 2026 (UTC)[reply]

  @GreenC "Hatchet case" --> "Hachette case"? Hachette is a book publisher. David10244 (talk) 06:14, 17 February 2026 (UTC)[reply]

  See Hachette v. Internet Archive. WhatamIdoing (talk) 20:08, 18 February 2026 (UTC)[reply]

I think a restricted Wikimedia archiving solution for webpages, accessible only to Wikipedians/Wikimedians - similar to the Wikipedia Library - would be a good idea. It would be harder for the general public to check a web reference archived in this way, of course, but I think it would be a good compromise between copyright concerns and verifiability needs. This also given that the long-term sustainability of at least one of the two large archive services we currently rely upon seems very questionable - even if we should decide to retain archive.today/archive.is links, I'm pretty sure they will be a giant heap of dead links not too far in the future anyway. And the Internet Archive, though unquestionably more reputable as a nonprofit enterprise that truly wants to achieve something good for the internet, is under heavy pressure too, technically, politically (given the current political climate in the USA), and copyright-wise. Gestumblindi (talk) 09:36, 13 February 2026 (UTC)[reply]

Yes, restricted access would be helpful evidence that the archive does not have a detrimental effect on the market for the content in question. There are other potential compromises, such as archiving textual content only (since that's probably what we want to cite), which would further distance the archive from any suggestion of intent to infringe. Barnards.tar.gz (talk) 13:22, 13 February 2026 (UTC)[reply]

It's a bad idea for WP:V. Making it so the only way to verify what Wikipedia is saying is to be an active Wikipedia editor harms our readers. TWL is acceptable because all the resources it has are available through others means, including other libraries. IsCat (talk) 16:07, 13 February 2026 (UTC)[reply]

Well, imagine archive.today and the Internet Archive going offline, which is absolutely possible. Then, an archive restricted to Wikipedia editors would still be better than nothing, if copyright issues are otherwise preventing it? That's what I would call a compromise. Maybe access could be made somewhat easier than for the Wikipedia Library, and maybe some way for external users to have access on request could be implemented. Gestumblindi (talk) 19:52, 13 February 2026 (UTC)[reply]

I have a somewhat wackier suggestion: an archive accessible to the public, but new pages can only be archived by autoconfirmed users, like Perma.cc.

The reason I'd want to do this is because a "web archive" can imply multiple use cases. A lot of people use archive.is to hop paywalls, which is obviously a copyright violation of the kind that can incur risk for Wikimedia. If we limit the number of users who can archive pages, we thereby limit bandwidth usage, copyright risk, and scope creep. Furthermore, an archive produced in this way seems to me to have a stronger claim to be a DMCA Safe Harbor than one which resembles a paywall-hopper in function.

If we take measures to limit the scope, perhaps we could open this to the public without incurring as serious a risk. NotBartEhrman (talk) 00:00, 14 February 2026 (UTC)[reply]

It would probably create a headache for us if Wikipedia becomes known as a provider of a paywall bypassing tool ("just make 10 junk edits to get access!"). Also, I think archiving sites that successfully bypass paywalls are using dark magic that a reputable site would struggle to replicate. Barnards.tar.gz (talk) 13:35, 14 February 2026 (UTC)[reply]

Bypassing paywalls should never be the goal anyway. The purpose of web archiving is not to access material for free that is still perfectly accessible online, though requiring payment (a printed book is also a legitimate source, and books aren't free as well, still you might be able to get them on loan through a library - just as some online content through the Wikipedia Library), but to save material to keep it accessible when it's otherwise offline and not available through any other means. So, a hypothetical Wikimedia archiving service would, IMHO, best be set up in a way that you can preemptively save web pages that are used as references, but the archived copy is made accessible only if the original source goes offline, and probably with some further restrictions (only for Wikipedia editors or something like that). Gestumblindi (talk) 14:11, 14 February 2026 (UTC)[reply]

Jinx! ChompyTheGogoat (talk) 14:24, 14 February 2026 (UTC)[reply]

This is more or less the kind of "dark archive" that I have been thinking about. Every page used in a citation would get automatically saved, and the saved copy goes into a lockbox that can only be opened if the original source is offline and the reader has WPL access. Stepwise Continuous Dysfunction (talk) 02:55, 15 February 2026 (UTC)[reply]

I think archiving sites that successfully bypass paywalls are using dark magic Well, you can consider the design/development process behind youtube-dl, Invidious and alternative web front-ends.. Few are like Wikipedia to provide good public APIs, most are pretty hostile to the development and continued operation of alternative front-ends, devolving into a cat-and-mouse game.

For websites, apart from paywalls, there's also the hurdle of captchas, or more recently Anubis and so on, that have been deployed to protect the sites from recent waves of DDoS from LLM scrapers: If web crawlers used to have some sense of propriety back in the days, when crawlers actually followed instructions of robots.txt and set apprpriate user-agent string, it appears to be quite lacking in these days of LLM scrapers: with residential botnets and user agents of mildly older browsers being common occurrence. Even if a FOSS solution is developed that can overcome the restrictions of websites, and then gets used by these LLM crawlers, it'll be a rather disgraceful situation, not considering that mitigations that will also be developed accordingly, leading to a protracted stand-off. A non-FOSS solution will create a dependance and might lead to a situation like that of .today. Smlckz (talk) 18:11, 14 February 2026 (UTC)[reply]

I'd take it one step further: the complete archive only accessible to users with special permissions, whose responsibility is to set individual page archives to public access if and when the original becomes unavailable - similar to how the deadlink status works now, but with additional protections on the archive to prevent abuse. Deadlink flags by other editors would add it to the approved editor log for confirmation. IANAL but I believe that would be along similar lines to current Commons policy on non-free images, which are only allowed if no suitable free alternative is available - the archived version would only be publicly accessible if the original copyrighted source is not. I don't think it matters quite as much who triggers the archival process (anyone can on IA) if it can't be viewed unless those conditions are met. The archiving could even be done by bots crawling wiki citations to ensure they're backed up.

I also agree that limiting the archives to text would help strengthen the fair use argument. If and when media qualifies for archiving is a discussion that should probably take place on Commons, amongst people more familiar with those policies, but afaik most media is not used as sources to substantiate claims, right - if it proves a claim we'd look for a text source explaining that? ChompyTheGogoat (talk) 14:23, 14 February 2026 (UTC)[reply]

As a Commons admin, I just have to point out that there is no "current Commons policy on non-free images, which are only allowed if no suitable free alternative is available"; Commons doesn't allow any non-free images, I think you're mixing this up with English-language Wikipedia's policy for non-free images locally hosted as "fair use". Gestumblindi (talk) 15:26, 14 February 2026 (UTC)[reply]

Quite possibly! Still new here - I thought I'd seen links to Commons in discussions on the subject, but I might be misrerembering.

m ChompyTheGogoat (talk) 15:30, 14 February 2026 (UTC)[reply]

(The point still stands however.) ChompyTheGogoat (talk) 15:31, 14 February 2026 (UTC)[reply]

Yes, a reasonable point otherwise, I agree. Gestumblindi (talk) 15:44, 14 February 2026 (UTC)[reply]

You're probably remembering the local Wikipedia:Non-free content criteria. WhatamIdoing (talk) 03:21, 17 February 2026 (UTC)[reply]

To assist with verification and finding suitable archival snapshots of webpages, it may be a good idea to make it a requirement to provide a valid |date= or |accessdate= parameter whenever a |url= parameter is used by a citation template. What I'm suggesting is that a warning message be displayed like when citing without a |title= parameter. Ideally, only one of them would have to be present to remove the warning, since it's often preferable for verification to have |date= but many websites don't provide one; |accessdate= provides a fallback when the reference is undated. If doing it that way would be difficult to code we could instead leave |date= as optional and make only |accessdate= a requirement, though this would increase the backlog we would have to deal with, so I'd rather avoid it. If implemented as accepting either |date= or |accessdate=, the wording of the warning should make it clear that |date= is not an alias or abbreviation for |accessdate= so newer editors are not confused. The warning should probably only be visible to editors, not readers.

If the presence of a date in some form were required with a URL, it would be a starting point for searching through snapshots of a webpage; just start with the snapshot with the nearest date. At present it's never a requirement, even for {{cite web}} where there's no alternative to using |url=. It might also be helpful for bots, since a bot could then not only check if a snapshot merely exists on an archival site but also check which snapshot is likely to be the most helpful, based on the archival date.

I first suggested this at Wikipedia:Requests for comment/Archive.is RFC 5 in the context of migrating archive links away from Archive.today; finding suitable snapshots elsewhere would be more straightforward if URLs were always paired with dates. Regardless of whether a consensus to deprecate/replace Archive.today links emerges, requiring dates with URLs would help with link rot in general.

If implemented, it would have to be done by an editor who has both technical knowledge and relevant permissions, as it would require modifying protected templates and possibly Module:Cite and/or related modules. It would also require making an appropriate tracking category, so editors could monitor and begin dealing with the new backlog of citations that should have dates but don't.

(I'm posting it here as I'm unsure if it's sufficiently "concrete" for "Proposals". If it is, please let me know so I can move this over there.) – Scyrme (talk) 23:03, 15 February 2026 (UTC)[reply]

For one thing, some URLs are courtesy listings when the citation is to a book, journal, or other printed matter. The cited material is not going to be lost if the URL stops working, and the date for the citation has nothing to do with when the URL link went up. Donald Albury 00:08, 16 February 2026 (UTC)[reply]

Providing a date for offline materials even when it isn't the same as the date it was published online is also helpful, so I don't see why this would be a problem. To be clear, I'm not suggesting that |date= always pertain to the URL. Part of the point of using the existing date parameter is so that references to works which have offline editions are excluded from the check even if a courtesy URL is provided. Link rot is less of a concern where print publications exist, so finding suitable snapshots isn't a priority and no warning/notice is needed.

However, if it would cause unforeseen problems to add this requirement to all citations, then how about at least requiring a date for {{cite web}}? The point of that template is to reference online-only resources, so there should be no issue with "date" differing from the date of publication online. Doing it this way would be better than nothing, but it would leave out any references that use other templates, eg. {{cite news}}, which are often also used for online-only material.

Another approach might be to create a new parameter, eg. |onlinedate=, to distinguish when "date" differs from the date of publication online, but the disadvantage of this is it would not exclude things that already have "date" or "accessdate", so the would inflate the backlog of citations with URLs to add dates to. If it's important to distinguish |date= and |onlinedate= for references which have both printed and online editions, we could add that new parameter as an additional way to remove the warning, so references which already have a date in some form are still excluded but editors can make the distinction when adding new references or updating undated references. – Scyrme (talk) 00:48, 16 February 2026 (UTC)[reply]

A lot of auto-filled citations for newspapers use {{cite web}}. WhatamIdoing (talk) 03:23, 17 February 2026 (UTC)[reply]

Might be possible to add a Help:CS1 errors about this, but as Donald Albury notes it would have to be refined enough to exclude citations where we don't require access-dates. CMD (talk) 03:31, 16 February 2026 (UTC)[reply]

I don't think this is needed because it's quite possible to find out when a URL was added to an article using a tool like WikiBlame. I'm pretty sure InternetArchiveBot uses a similar procedure to automatically add access dates and figure out which archive link to use. Also I've had situations where the access date is irrelevant because I've first accessed the link in archived form, long after it was taken off the live Internet; examples are references 2 and 16 at the Caitlin Hulcup article (permalink); I found those references because the Australian Web Archive is keyword-searchable. On re-reading, I've realised that those references have dates though. This reference, which I used dozens of times, is a concrete example of an undated reference, but I added a nominal access date in those cases. This sort of thing can also happen with the Wayback Machine if someone uses an old version of a website to find information. An example where I did this without either a date or access-date parameter because both were irrelevant is reference 4 at Corrina Hewat (permalink). Graham87 (talk) 04:08, 16 February 2026 (UTC)[reply]

@Graham87: I didn't know there were automated ways to add access dates. I'm glad they exist. However, these methods seem like they require some technical knowledge to use (and also knowing they even exist to begin with). I think most editors would find it much more straightforward to just click a live link, see if it verifies the text, see if it has a date, and add today's date (the date they checked) if it doesn't.

There are many articles that have issues that a bot could definitely fix, but, as is often the case with human editors, no bot has gotten around to it yet. If someone is editing an article anyway, why not alert them to an issue which is generally easy to fix?

If you have situation where the original webpage is undated, it dies, and you find it on an archive and reference it after the fact, a solution to that might be to also include |archivedate= in the check. Since the point of providing a date is help with finding an archive that works, if an archive is already provided the check can be skipped. – Scyrme (talk) 04:40, 16 February 2026 (UTC)[reply]

I know InternetArchiveBot has done at least a couple of run-throughs of the entire encyclopedia and I believe (but could be wrong about this) that it aims to check every page eventually. I think it's also through that bot that every time a new link is added to Wikipedia, an automated attempt is made to archive it on the Wayback Machine. Having said that, outside of the edge cases listed above, I usually only encounter URL's without dates/access dates when they're bare URLs. I'm going to provide a pointer to this discussion at Help talk:Citation Style 1, where changes like this are normally discussed. Graham87 (talk) 05:18, 16 February 2026 (UTC)[reply]

I'm not aware of links automatically being archived when added to Wikipedia. Is that for all URLs or only ones in references? If it's the latter, that would leave out bare URLs or manually written references which wouldn't necessarily get picked up automatically after an editor converts them to use a template. If there's some system that checks if an editor has added a URL, would it notice if an editor finds an old URL that was already in the article and puts it inside a template?

Regardless, as noted in the RFC regarding Archive.today, the Internet Archive isn't always successful at archiving pages so it would likely still be helpful to include a date that would assist in finding suitable snapshots through other archival services.

If dateless citations which use |url= are rare, managing the backlog shouldn't be difficult. At present, there's no way to check. (Or if there is a way, it's technical and most editors wouldn't know how to do it. I'm sure there's probably some external tool somewhere that could be queried to do this.)

Thank-you for providing the pointer. I wasn't sure where the best place for this would be, but I assumed it was here since it would affect so many articles, and I assumed the main talk pages would be mostly for maintenance. – Scyrme (talk) 06:08, 16 February 2026 (UTC)[reply]

It's all URLs in the main namespace. See Wikipedia:Link rot § Automatic archiving. Graham87 (talk) 11:07, 16 February 2026 (UTC)[reply]

Good to know. Though as it notes, "in practice not every link is getting saved". I don't think we can rely entirely on automation. – Scyrme (talk) 21:36, 16 February 2026 (UTC)[reply]

If it's not working with automated systems, then adding human error to the process is not likely to give us better results. WhatamIdoing (talk) 03:24, 17 February 2026 (UTC)[reply]

Guess anything a bot can't do perfectly isn't even worth attempting. Why allow human editors to do anything? Some of them will inevitably mess it up, so why bother? It's just more opportunity for human error.

I really doubt that's what you really think. There are obviously cases where manual editing is necessary. In cases where the the bots aren't successful, human intervention may overcome their limitations. In these cases, why not make the task simpler and less error prone by making relevant information more easily available? (In this case a date included in the template as a starting point for identifying the most suitable snapshot of a webpage.) – Scyrme (talk) 15:58, 20 February 2026 (UTC)[reply]

This would be something that's only useful for webpages that change overtime, for anything that's doesn't change this would be completely pointless. That goes beyond courtesy links to books, magazines, etc. There are many web links that will not change either, so this will only ever be useful for a subset of citations that are to webpages. Secondly there is no way to force editors to include an access date, all that can be done is create a tracking category and error message. If the large red error message that a refname is undefined goes regularly unnoticed (it's the most visible of such error messages), this will be doubly so. The tracking category will also start off with hundreds of thousands of entries.
Encourage editors to add a access date for transient webpage maybe, but it would be a bad idea to enforce this for everything with a url. -- LCU ActivelyDisinterested «@» °∆t° 12:54, 16 February 2026 (UTC)[reply]

All web links are liable to change eventually. Providing a date or accessdate where it's not strictly necessary doesn't do any harm. If even some editors notice and respond to the notice, which I know I would and I'm sure there are others who likewise fix citations when they find them, I don't see what the harm is. – Scyrme (talk) 21:25, 16 February 2026 (UTC)[reply]

Such a message could discourage people from supplying any citations at all. Far better a citation without a date than no citation. Phil Bridger (talk) 15:51, 16 February 2026 (UTC)[reply]

I don't see why it would discourage people from adding any citations. People aren't discouraged from adding citations by other notices/warning that citations emit. As ActivelyDisinterested notes, editors are more likely to just ignore a message they don't know how to fix than to remove a whole citation after adding it. Given how easy it would be to remove this notice, I can't imagine it deterring editors. – Scyrme (talk) 21:20, 16 February 2026 (UTC)[reply]

The longer and more complicated the task, the more likely people are to give up. WhatamIdoing (talk) 03:29, 17 February 2026 (UTC)[reply]

Finding a date for a dead link is a longer and more complicated process than providing one when adding a live link as a reference. In the latter case, an editor adding a URL could just provide today's date as the access date while they're adding it. It's quick and simple. It's probably an easier task than finding a URL to cite was in the first place. – Scyrme (talk) 03:36, 17 February 2026 (UTC)[reply]

I mean, you can always dig through the page history to find when they first added it. That's what I do sometimes. PARAKANYAA (talk) 00:50, 17 February 2026 (UTC)[reply]

That's true, but if editors were encouraged to add a date, there would be less need to dig through history (or use WikiBlame). It's usually better to reduce how often problems are made in the first place than to cleanup afterwards. – Scyrme (talk) 02:01, 17 February 2026 (UTC)[reply]

We don't even do that for people adding bare URLs. PARAKANYAA (talk) 05:17, 20 February 2026 (UTC)[reply]

A bare URL has no template which could be made to emit a warning. However, we do often manually add notices for bare URLs to encourage editors to fix them. ({{bare URL inline}}. {{bare URLs}}) We also provide tools to help with formatting references in both editors, to help editors avoid making the problem in the first place. The visual editor even has a tool that will automatically generate a properly formatted reference from a URL alone using Zotero (included a retrieval date), to make it as easy as it possibly could be to add a proper citation rather than just a bare URL. – Scyrme (talk) 15:50, 20 February 2026 (UTC)[reply]

a static efficient single-file HTML format

https://gwern.net/gwtar

https://news.ycombinator.com/item?id=47024506

Piñanana (talk) 03:26, 16 February 2026 (UTC)[reply]

What are you suggesting with this? – Scyrme (talk) 04:47, 16 February 2026 (UTC)[reply]

Worth considering for #Better solutions for archiving web pages above? Also, Gwern is a Wikipedian on top of everything else and may want to comment here. ClaudineChionh (she/her · talk · email · global) 23:38, 16 February 2026 (UTC)[reply]

i guess Gwern cleared it up, so this isn't going anywhere. Piñanana do you have anything to add now or is this officially closed? woaharang (talk) 17:17, 18 February 2026 (UTC)[reply]

I don't think Gwtar has much of a future for Wikipedia usage. Besides being literally less than a month old and a highly experimental/tech demo, it's aimed at a different niche: long-term ad hoc archives which get copied and passed around indefinitely by people who ideally would need know no more about a Gwtar than they do about a PDF.

Since MediaWiki is already so complex and a project like WP is centralized with full-time devs, it isn't a big deal to add some server-side software as a one off to support more straightforward archive formats, or to support full-blown WARCs etc.

I am also hopeful that we can get rid of Gwtar entirely and merge it upstream into SingleFile(Z). (seems to think that this would not be hard.) Much like InvertOrNot.com, this is a tool I could use for my writing, but I do not want to maintain or be responsible for once I've adequately documented what it should do. --Gwern (contribs) 00:20 17 February 2026 (GMT)

How about we use colours to make WP:RS sources stand out? Something in lines with this?^[1]

The pop-up link could be in green as well.^[1]

A different colour will also raise intrigue among new editors, and will ultimately lead up to a good chunk of them getting aware of the different categories of sources, especially reliable sources, in Wikipedia. Cdr. Erwin Smith (talk) 07:23, 18 February 2026 (UTC)[reply]

I do not support this idea. No source is reliable 100% of the time. We do not cite the New York Times for medical claims, for example. Sources may be generally reliable but editorial judgment is still required. Cullen328 (talk) 08:20, 18 February 2026 (UTC)[reply]

Editorial judgement will continue to be required, even if this proposal gets accepted.

The colour will simply differentiate RS from Non-RS sources, so that they stand out among the rest, if they're inserted based on editorial judgement. Cdr. Erwin Smith (talk) 09:34, 18 February 2026 (UTC)[reply]

It's often more complicated than just "reliable" or "unreliable". For example the Anti-Defamation League is listed at WP:RSPADL as being generally reliable for material outside the context of the Israel-Palestine conflict, partially reliable on the topic of antisemitism when Israel and Zionism are not concerned, and unreliable for the Israeli–Palestinian conflict. Any colour coding would this have to show it as red, yellow and green at the same time as the highlighter would be unaware of the context. Thryduulf (talk) 15:16, 18 February 2026 (UTC)[reply]

If the goal is to have a general color-coded list of reliable sources to make it easier for newer editors to identify them, we already sort of have that at Wikipedia:Reliable sources/Perennial sources. Note that this list is not reader-facing, and I agree with Cullen328 that it would not be desirable to make it reader-facing. The list merely attempts to describe past editorial decisions related to frequently used sources; it is not meant to prescribe how those sources should be used in every context. Mz7 (talk) 08:55, 18 February 2026 (UTC)[reply]

Note: when I first wrote the above comment [10], this section did not at the time include a link to WP:RSP in the section header. Mz7 (talk) 05:06, 20 February 2026 (UTC)[reply]

There are scripts etc. that do this based on various lists of sources, e.g. m:Cite Unseen and CiteHighlighter. Cheers, SunloungerFrog (talk) 09:28, 18 February 2026 (UTC)[reply]

If a source isn't reliable, why are you using it? All sources used within Wikipedia should be reliable, though no doubt some are more reliable than others. Colour coding for any reason is also a bad idea, with significant numbers of people being colourblind. Chuntuk (talk) 15:07, 18 February 2026 (UTC)[reply]

A generally unreliable source might be perfectly fine to cite for banal statements like "The sky is blue". Katzrockso (talk) 15:45, 18 February 2026 (UTC)[reply]

Do you even need to cite for banal statements like that? Citations are for proving things which have to be verified, not banal and everyday knowledge statements like your example. woaharang (talk) 17:22, 18 February 2026 (UTC)[reply]

Almost never. More relevantly though most generally unreliable sources are reliable for WP:ABOUTSELF matters. Some are also reliable for small niches, e.g. Blogger is marked as generally unreliable but hosts some blogs that are usable per WP:EXPERTSPS. Thryduulf (talk) 19:14, 18 February 2026 (UTC)[reply]

Do you even need to cite for banal statements like that? Generally not, but sometimes you do. mdm.bla 16:11, 20 February 2026 (UTC)[reply]

Honestly, I don't think it's a good idea. For example, a small number of editors may be colorblind. I know that most of us aren't, but it's important to respect disabled people. In any case, using WP:RS makes it kind of obvious what the category is.

Most editors ARE competent enough to know what citation goes where. This is basically spoonfeeding. woaharang (talk) 17:21, 18 February 2026 (UTC)[reply]

Aside from all of the valid issues already raised, I would not expect most readers to understand that ^[1] was intended to indicate that the citation to which it pointed was reliable. Rather, I would expect them to be confused by seeing different footnotes in different colours. Caeciliusinhorto-public (talk) 15:08, 20 February 2026 (UTC)[reply]

A discussion has been started about what help page on using AI on Wikipedia to draft first. See Wikipedia talk:Help Project#Planning help for AI workflows.    — The Transhumanist   13:35, 19 February 2026 (UTC)[reply]

I created Template:New archival link needed as a potential solution to highlight links to archive.today or other deprecated archival repositories. Following the archive.today RFC being closed in favor of deprecation and removal, I am wondering if it is possible to have a bot append this template to references linking to archive.today as part of the removal process. mdm.bla 03:21, 20 February 2026 (UTC)[reply]

As an example: Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.^{[1][new archival link needed]} mdm.bla 03:29, 20 February 2026 (UTC) mdm.bla 03:29, 20 February 2026 (UTC)[reply]

In a technical sense, a bot can to do this, and it should be fairly easy for one to do so. The harder part is establishing consensus that a bot should do it. The outcome of Wikipedia:Requests for comment/Archive.is RFC 5 helps, but doesn't specifically establish that a bot should go around adding this tag to half a million articles. Anomie⚔ 13:21, 20 February 2026 (UTC)[reply]

Thanks for the input, Anomie. Do you think this is an idea that is worth exploring further/could gain consensus? I assume that would be a discussion for VPR if/when my idea gets to that point. mdm.bla 16:24, 20 February 2026 (UTC)[reply]

I'm more interested in if the bot can go one step further - a bot to simply tag all the citations, or a bot that simply yeets all the citations are straightforward enough - can we technically build a bot that replaces the citation with the original link if it's live, or with archive.org if both have captures? Tazerdadog (talk) 21:35, 20 February 2026 (UTC)[reply]

If we're swapping captures the bot would need to verify that they're equivalent. I found one a while back where one had archived an error page and the other the actual content, even though they were very similar dates (a few days apart iirc). Thryduulf (talk) 21:44, 20 February 2026 (UTC)[reply]

Currently GreenC_bot's WP:WAYBACKMEDIC tasks are probably the closest actions to what you're looking for, but per Thryduulf the replacement process would have to be more involved in order to satisfy WP:V. InternetArchiveBot is also working on a similar task for dead links. Relatedly, GreenC_bot should probably be stopped from adding archive.today links (courtesy ping @GreenC). mdm.bla 21:55, 20 February 2026 (UTC)[reply]

When I do a search for a string using insource, it is *much* more likely to actually finish if I add a "normal" word to search for in the search. So if I do a search on (putting # around my searches in this text) # insource:/dia of Fraternities/i stevens #, it goes much faster than and is far more likely to finish than # insource:/dia of Fraternities/i # . The issue is that if the first search returns no records (say if I'd searched on # insource:/\<ref>[^\<]*dia of Fraternities/i stevens # ), it says "Showing results for sevens. No results found for insource:/\<ref>[^\<]*dia of Fraternities/i stevens." This assumes that the "problem" is there are no hits for stevens, not that the insource is limiting them. In the case where an insource: (or intitle: etc.) squeeze the results down to zero records, I propose that it show the results for the normal word actually in the search, in that case stevens rather than sevens. This is just an example, I've run into it doing other similar searches. I'm not sure this is ready for a proposal, or where this discussion should be done, but the help desk doesn't seem like the right place.Naraht (talk) 21:44, 20 February 2026 (UTC)[reply]