Wikipedia:Village pump (idea lab)

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]

I think we should keep it because there are situations where a new editor (who doesn't know or fully understand the rules) and/or an editor with good/misguided intentions should be shown leniency; only a persistently problematic and/or knowingly malicious user deserves harsh and/or immediate sanctions. QuisEstJoe (talk) 20:51, 27 February 2026 (UTC)[reply]

I'm a new editor on here, so I may not have as much skin in the game as all the other editors here.

That being said, I think it's better to assume good faith and stick to the 5 strike system, because from what I understand, there's 4 tiers of warning before a report, and then one special tier for particularly egregious cases that may warrant more immediate action, which seems like a good solution. Speaking as a newbie editor: I'd (personally, at least) appreciate a little leniency and decency from the more experienced editors, like whenever I'm editing something and they catch something I did wrong, they can point to a policy I've neglected or violated; learning and reading all the policies is at times quite daunting and a little overwhelming, to be completely honest here. Ediot (talk) 03:16, 2 March 2026 (UTC)[reply]

Wikipedia is not a bureaucracy and Our social policies are not a suicide pact. The problem of biting newcomers will not be solved by requiring adherence to the five strike system. How much leniency we should show to editors who have made problem edits is conditional on how damaging such edits are to the encyclopedia and what evidence is available as to the intentions of the editor. Some edits are very obviously intended to harm the encyclopedia or attack other users, and the assumption of good faith can be very short-lived. We have to trust the judgement of our fellow Wikipedians in dealing with problem edits and allow leeway in imposition of warnings and, for administrators, blocks, unless and until an editor or admin demonstrates that their judgment on warnings and blocks is out of step with the community. Donald Albury 13:47, 2 March 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]

  Yes, LLM output (according to what others say) at least usually does fall under "the same requirements as other public domain content".

  But: In terms of the CC license itself (NB: not including any additional rules that the English Wikipedia chooses to adopt – just the actual legally binding contract in which you "agree to irrevocably release your text under the CC BY-SA 4.0 License"), there are no requirements for public domain content.

  For example, you can "license" a typo correction, like you did in this edit, even though that is a non-copyrightable public domain edit. The typo correction doesn't become copyrighted or further restricted by the license, but you're not violating the license by posting something that is not eligible for copyright.

  The same logic applies (as far as anyone can tell, at least under US law at the moment) to LLM output. It's not eligible for copyright protection, but posting it on wiki doesn't violate the Creative Commons license.

  Posting some kinds of LLM output (e.g., a couple of sentences of new content) without disclosure would AIUI fall afoul of our local rules against Wikipedia:Plagiarism, but it isn't a copyright or license problem. WhatamIdoing (talk) 07:17, 22 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]

  Claiming that you wrote something when you definitely didn't write it is plagiarism. (Call it "lying about who wrote this" if that's easier to understand.) WhatamIdoing (talk) 07:19, 22 February 2026 (UTC)[reply]

  Whem you say "plagiarism", are we talking about actual copyright law, or just using buzzwords to mean that you don't like it? Cambalachero (talk) 15:42, 22 February 2026 (UTC)[reply]

  @Cambalachero: neither; WAID is talking about plagiarism, which, as that page will tell you, is not the same thing as copyright infringement. lp0 on fire () 15:47, 22 February 2026 (UTC)[reply]

  WhatamIdoing was pretty clear to me. XtraJovial (talk • contribs) 15:52, 22 February 2026 (UTC)[reply]

  I don't think it's black and white. If I consult a dictionary to find the right word I don't need to credit it. With the LLMs the question is how much human review and/or changes are needed for me to be considered the author. Alaexis_¿question? 15:57, 22 February 2026 (UTC)[reply]

  If you post something to Wikipedia, unless it is clearly marked as a quote, then you are representing it as your work. If you are copying the content from somewhere without attribution, that is plagiarism. And the argument about words you have looked up in a dictionary is a straw man. Donald Albury 18:16, 22 February 2026 (UTC)[reply]

  Copyright is a legal thing. Plagiarism is a moral thing. It is possible to violate the legal thing without violating the moral thing, and vice versa. WhatamIdoing (talk) 19:30, 22 February 2026 (UTC)[reply]

  If morality prevents you from improving or maintaining Wikipedia, ignore it. Cambalachero (talk) 18:13, 24 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]

The rate limiting measures could possibly end up creating a Streisand effect to editors who were not planning to use an LLM to generate wiki content. ~2026-11404-95 (talk) 16:47, 24 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]

I know that MediaWiki uses SQL, so maybe we could query (with my very limited knowledge of SQL) SELECT * FROM data WHERE instanceof = 'album'. SeaDragon1 (talk, contributions) 16:24, 23 February 2026 (UTC)[reply]

This would be queried using SPARQL and as said WD has some items with that instanceof set that Wikipedia does not have and Wikipedia has some (sometimes many) that Wikidata does not have. Moreover, things are categorized sometimes differently on WP than what's possible on Wikidata (more so when considering not only whether it's technically possible but also whether it's actually set). Lastly, the SQL or SPARQL for querying isn't among the main subjects here.

Another non-music example: https://en.wikipedia.org/wiki/Category:People. Corresponding query: "Give me all Wikipedia pages that correspond to 'instance of'='person'". Wikipedia has them subcategorized; Wikidata, with the slow-loading tens of thousands of people items, hasn't. Prototyperspective (talk) 17:05, 23 February 2026 (UTC)[reply]

Well, if you want to fetch it from Wikipedia (either from the actual content of Category:People or via an API), go ahead. Just make sure you know about CORS. SeaDragon1 (talk, contributions) 17:22, 23 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]

That is not what you are arguing. You were arguing for it to be required when you include it. First we would have to get consensus for access dates being mandatory. Also, citoid does not work with many websites, including the New York Times. PARAKANYAA (talk) 23:03, 20 February 2026 (UTC)[reply]

I am and have always been arguing for a warning or notice to be displayed in preview when editing when a citation template which uses |url= does not include any kind of date parameter (not just |accessdate=). That is what I meant by making it required. If you thought otherwise, then perhaps I've not been clear enough; perhaps I should have said "encourage", not "require", but regardless I have not changed what I've been suggesting or arguing for. I am aware that consensus would be required; that's why I started a discussion.

I don't see the relevance of citoid not being perfect. Feels like you're moving the goalposts. I said it's usually better to reduce how often problems are made in the first place, you said we don't even do that for people adding bare URLs, and I have just shown that in fact we do, both by visibly marking it as a problem when it happens, albeit manually, which discourages some editors who see the notices from doing it in the future because they're made aware it's a problem, and by providing tools that help editors avoid creating the problem, by automatically formatting references for them, so it's easier for editors to do it correctly.

Now you're saying citoid doesn't always work. So what? How is that relevant to it's usually better to reduce how often problems are made in the first place? Even if it does it imperfectly, the rationale is still to assist editors so fewer of them create problems in the first place. If your argument is that it actually creates more problems than it prevents, then I could see the relevance, but, 1. I doubt it, and 2. that would be a case for removing the tool not an argument against encouraging or helping editors in not making (in this case, very easily avoidable) problems. – Scyrme (talk) 00:25, 21 February 2026 (UTC)[reply]

I am saying it is ridiculous for a warning to pop up over date when we don't even do it for bare urls. We don't need templates to emit warnings the strings can be detected. Neither are mandatory so we shouldn't treat them like they are. PARAKANYAA (talk) 02:47, 21 February 2026 (UTC)[reply]

Why is it "ridiculous"? I have described the practical benefits of including dates and how a notice would encourage editors to include them. You have neither refuted these benefits nor raised any problems which may outweigh the benefits. That a notice for some other problem doesn't already exist doesn't mean one should never be added for either problem.

The argument resembles WP:OTHERSTUFFEXISTS, though in this case you're arguing other stuff does not exist. I also still don't see much difference in principal between manually added notices and automated notices, so bare URLs don't seem like they're a particularly good example for other stuff not existing. – Scyrme (talk) 16:12, 21 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]

There is no way to do this that can tell if the captures are equivalent, many supposed captures are actually nonfunctional, 404s, or of the wrong content. It will have to all be checked manually. PARAKANYAA (talk) 23:04, 20 February 2026 (UTC)[reply]

Manually is ... not going to happen. The biggest manual cleanup I am aware of us completing was 70,000 redirects under CSD X1. I was one of the people who put the most hours into that cleanup. Most of those redirects were decided with single digit seconds of volunteer time. It took two and a half years to finish. This is an order of magnitude more references, and each reference likely takes longer to manually fix than a Neelix redirect took to process. We need at least some automation help here. We can accept a fair amount of errors as better than the alternative, and I'm definitely going to put in some hours personally to get through this. However, there mathematically must be a bot somewhere, even if all it can do is rescue the live links. Maybe a AWB plugin that asks if these are the same website? If we can't get any automation, then we have to mass delete these and eat the hit on verifiability. Tazerdadog (talk) 23:32, 20 February 2026 (UTC)[reply]

There is quite simply no automated way to replace the links with other archives and have any reliable rate of accuracy because the other archiving services work completely differently and there is no way for the bot to tell if the content is the same, or even if it exists and is not a 404.

A fair amount of errors for new content introduced is not acceptable. The most automated way that is possible is simply ripping out all of the archive.today links and marking them as dead. Infinitely preferable to linking things that are very likely to not contain the content at all; additionally in many cases the link cannot exist because the other archiving service does not capture the website at all. The archiving bot already only used archive.today as a source of last resort where other archives failed.

Its main use cases are 1) paywall jumping (which we shouldn't have even been linking them for in the first place) 2) javascript heavy or obscure websites that the Internet Archive cannot capture due to technical or request reasons (e.g. there are some fairly major Canadian websites that block the Internet Archive entirely). With 1 we can just remove the archive and deal with the paywall (which is what I have always done, I don't know why everyone is so determined to jump paywalls) but 2 is unfixable. Per WP:LINKROT we are not actually supposed to remove material cited to dead links, though. With news sources we could just remove the link to the original entirely if it is dead, to address that issue. PARAKANYAA (talk) 23:58, 20 February 2026 (UTC)[reply]

Yes, WP:VPR would be appropriate if it gets to that point. Anomie⚔ 23:42, 20 February 2026 (UTC)[reply]

If the link is alive still, a bot can simply remove the archive. If it is not, then you... cannot just make a new archive capture. So just remove it and tag it as a permadead link. I oppose the usage of the template as it doesn't actually solve any of this. PARAKANYAA (talk) 23:05, 20 February 2026 (UTC)[reply]

Having a bot go through and remove all of the instances of archive.today leaving the base link feels like the logical next step then. Tazerdadog (talk) 01:02, 21 February 2026 (UTC)[reply]

Well, we should add the dead link tag in the cases where the link is no longer live, but yes. PARAKANYAA (talk) 01:04, 21 February 2026 (UTC)[reply]

• In defense of just adding this or a similar tag (+ category) , it gives page watchers and readers, especially those not in the know, an alert to let them know that there's an issue with the source, and that they can help by changing it. How edits that will prompt is unknown to me - however, something I have also thought of is that this is a lot of manual effort, but it's not overly difficult, for probably the vast majority of archive.today uses - if the link is live, remove the archive.today link. If it's not, check archive.org, and replace if possible. If not, then move on to the next citation & circle back later to do the difficult one. Given that, it might be interesting to experiment using that task as one of the newbie onboarding tasks? It's certainly no more difficult than expanding an article section, finding citations for unsourced material, or copyediting -- probably far easier for some newbies, actually. (Just saying, I'm a wee bit shit at copyediting and typo hunting, which is what all of your newbie onboarding pages said to try when I first started) Can't promise it'll be a perfect solution, but it's something relatively easy, yet tedious, and hard to mess up that badly. GreenLipstickLesbian💌🧸 03:53, 21 February 2026 (UTC)[reply]

  Instead of having a bot add a tag so we can maybe solve the problem in 12 years, why would we not have a bot just remove all the links and immediately solve the problem? PARAKANYAA (talk) 04:36, 21 February 2026 (UTC)[reply]

  @PARAKANYAA Because there's two problems here, both of which are being talked about as though they're the same, but which are distinct:

  a)large amounts of links to website we now know to be an unreliable mirror / website running illicit code.

  b)large amount of material which we can only seemingly verify to an unreliable mirror that we know can, and will, tamper with archived webpages.

  Bot removing links only solves problem A. Having the bot break/hide/render unclicklable all links would also only solve problem A. That would be useful. Bot (your solution) can't solve problem B. Bot solution "remove all links" would rather only mask problem B/move it to the 12+ year backlog. Only humans can solve problem B. Also, only humans can figure out how large problem B is. B will possibly take 12+ years to solve, but, well, that's where we're at. No matter what we call it, the backlog created by problem B exists, and will exist for the foreseeable future. I'm trying to think of ways to solve problem B; like you said, solving problem A is trivial. GreenLipstickLesbian💌🧸 04:55, 21 February 2026 (UTC)[reply]

  No matter what we do there are going to be large swathes of material, especially pre-2013, that do not exist on any other archiving service. There is nothing we can do about that, and there is no way for it to be solved. Therefore it is not a consideration. Removing the links will solve "Problem A" and and it will not hinder finding sources for the ones that are still findable. It wouldn't mask it any more than tagging it like this would. PARAKANYAA (talk) 04:58, 21 February 2026 (UTC)[reply]

  @PARAKANYAA Tagging it identifies the issue, which is the first step to solve it. Making it appear as though the material is supported by an active, working citation does hide the issue because people see a footnote and go "oh, yes, well, this must be true and verified!" A footnote with a whacking great "better source needed" or "fails verification" alerts people to the fact that no, not everything is okay. And then they can fix it.

  And, yes, material cited only to a website only on archive is is an issue. The citation will be to be replaced or, if you truely can't find that material supported by any other source or sources, online or off, then the material will need to go (the same way you might remove material cited to Fandom a random SNS post) because a)we can't trust it atp and b)the material is likely undue. Not guaranteed, but likely. That is how we solve this problem, though I'm most certainly not operating under the delusion that it will be a quick and easy solve. Now, if you'll excuse me, I'm going to go put on a podcast and fix a few dozen archive today links. GreenLipstickLesbian💌🧸 05:39, 21 February 2026 (UTC)[reply]

  That is why I said add the dead link template when you remove it by bot!

  Fixing it manually is a complete non starter. Also, no, per WP:KDL you are not supposed to remove material even if only cited to a dead link: "Do not delete a citation just because it has been tagged with dead link for a long time". You can just remove the archive and tag the dead link, or remove the link entirely and keep the citation. For news outlets especially you should never delete the citation because that is going to exist in an archive somewhere in the world even if not online. PARAKANYAA (talk) 05:52, 21 February 2026 (UTC)[reply]

  Great, I'm glad we're still on the same page that a tag of some form is needed; I'm still looking for a solution that will actually migrate these links over to new archives or live, published, citations, however. A bot tagging everything as permanently dead will not do that, though, like I maintained in my first post, it could be useful at solving the other problem. Which is what my post was targeted at?

  And, Parakanyaa, everything will have to be fixed manually, one way or another. I know you think the amount of work makes this impractical; if we're getting that nihilistic, though, ultimately, we will die, our servers will go dark, the sun will consume the rock on which we reside and entropy will take all. For now, though, let's try and brainstorm ways to fix a bunch of dead citations with the least impact possible?

  ... and, um, yes ,the existence of other archives is why I specifically said "online or off", and said only if you truly couldn't find the material supported in other sources, and can't track down a copy of the original source through contacting the original publisher or author, and you've made a reasonably exhaustive search through other potential sources, including primary sources. Ultimately, however, if I scour the entire planet looking for a source to back up the statement "X railroad opened on October 16, 2019", and I can't find one, not even a record tucked away in the office of the government which commissioned said railroad, then I'm challenging either that material's authenticity or dueness. So, as per my last message, not technically "just because it has been tagged with a dead link for a long time", there's a few extra steps. If it's something like a fact about a living person, then those extra steps suddenly start including BLP privacy-related PAGs as well. GreenLipstickLesbian💌🧸 06:42, 21 February 2026 (UTC)[reply]

  Also, @PARAKANYAA, per WP:DEADREF (our actual content guideline on the matter, not the how to guide),

  Do not delete a citation merely because the URL is not working. Dead links should be repaired or replaced if possible. If you encounter a dead URL being used as a reliable source to support article content, follow these steps prior to deleting it:

  where step 7 is:

  Remove hopelessly-lost web-only sources

  So. Yep. GreenLipstickLesbian💌🧸 06:46, 21 February 2026 (UTC)[reply]

  Well, if we do what you are suggesting, there isn't much brainstorming to do, is there? We pick at this manually for the next decade. Sure. I still do not think the tag is helpful even from that perspective. We cannot make a "new archive link" of a source that is dead; it hides the more dire fact that, as you describe, we are going through the dead reference process and are treating it like a dead reference.

  TIL on that last one. PARAKANYAA (talk) 07:02, 21 February 2026 (UTC)[reply]

  Yeah, it's grunt work. Hence brainstorming "is this gruntwork enthusiastic newbies could do, especially given that there's such a high portion of sources still available on the web & an abnormally high amount of source metadata documented here and on archive.is when compared to the deadref category as a whole?"

  I'm not completely sold on the tag's being exactly worded as "new archive link needed" or whatever it is. The problem with having a bot apply the dead reference tag, as you pointed out, the bot can't (or, can't practically and reliably) tell if a an alternative archive was already created for the website, whether on archive.org or elsewhere. I think having a bot tag all articles, then having humans either fix the citation or manually remove the tag and replace it with a "dead link" tag once they confirm that an archive doesn't appear to exist, and only then funnel it through the dead references process, might be more efficient and less disruptive to mainspace content. Or it might not - unfortunately, this is the point where my thought experiment needs more data. GreenLipstickLesbian💌🧸 07:16, 21 February 2026 (UTC)[reply]

  Anecdotally -- and I hope this doesn't completely put everybody off the idea -- I got into serious Wikipedia editing with CCI, aka hunting down dead links, unreliable mirrors, and replacing those links and sources on older, untouched, articles. If my newbie homepage had a task like this, I'd have leaped at it, instead of just ignoring it. But I'm not quite narcissistic enough to map that experience onto others! GreenLipstickLesbian💌🧸 07:21, 21 February 2026 (UTC)[reply]

  @GreenLipstickLesbian: The tag name is open to wordsmithing, maybe something like [deprecated archive]? mdm.bla 20:32, 21 February 2026 (UTC)[reply]

  I'd like that. But, also, please bear in mind that not only am I awful at copyediting, I'm awful at figuring out concise ways to convey a nuanced information in a way that make sense to anybody whose name is not GreenLipstickLesbian! GreenLipstickLesbian💌🧸 20:35, 21 February 2026 (UTC)[reply]

  That looks fine to me and seems clear enough as to what the issue is. --Super Goku V (talk) 01:08, 22 February 2026 (UTC)[reply]

  Took me a bit, but here is an example: M. P. Castle. As you can see from the last edit before today, one of the sources needed to be fixed by InternetArchiveBot to use an archive.today link last year. If we remove all archive.today links automatically, then this link would be a dead one as http://www.abps.org.uk/Home/Who_Was_Who/index.xalter#C now takes readers to a page that says "The page you are looking for may have been moved or removed." It would leave parts of the article sourced with a dead link and drop this article down to two active sources, both of which are not good for biographies. --Super Goku V (talk) 05:41, 21 February 2026 (UTC)[reply]

  Yes, this is going to leave a lot of dead links, regardless of whether manually or done by bot. PARAKANYAA (talk) 05:50, 21 February 2026 (UTC)[reply]

  My concern is that automatically going in and removing the links increases the likelihood that articles will have content removed because the link is dead without being checked for a replacement or even lead to articles being deleted. Maybe I shouldn't be concerned this way, but currently I am. --Super Goku V (talk) 05:58, 21 February 2026 (UTC)[reply]

  I don't see what difference it would make here if it was done by the bot or a human. PARAKANYAA (talk) 06:04, 21 February 2026 (UTC)[reply]

  Scale. It's one thing to fix incorrect content removal when they're following a human and another entirely when they're following a bot. Thryduulf (talk) 01:20, 23 February 2026 (UTC)[reply]

I think we can go one step further than this. At the very least, we could remove archive.today links from templates which have |url-status=live. There has been talk of even using the Internet Archive API to automate beyond that; I don't have enough knowledge on the subject to know how feasible that is, but I think removing WP:EARLYARCHIVEs would be a good step. I spent a decent amount of time yesterday removing archival links for live URLs, which could have been saved by such a bot. {{GearsDatapack|talk|contribs}} 00:16, 26 February 2026 (UTC)[reply]

I've been reading through the discussion, and I think there's enough here to start putting together a more concrete proposal. My first pass is below:

RFC: Automating the deprecation of archive.today

Please answer each of the following questions:

1. Should a new cleanup tag, [deprecated archive], be placed by a bot on references linking to archive.today?
2. Should links to archive.today be removed en masse by a bot?
3. Should a bot attempt to replace links to archive.today to either a non-blacklisted archive or the original site?

I believe this summarizes the above into three actionable questions. Any feedback would be greatly appreciated. mdm.bla 16:06, 22 February 2026 (UTC)[reply]

@Mdm.Bla, I don't think this is the right approach, because most of these links are inside the Wikipedia:Citation templates, and work is already underway to handle them via the template code. In other words: we can have the maintenance category and the other benefits of tagging, with no need to flood everybody's watchlists with half a million bot edits.

The discussion is at Help talk:Citation Style 1#archive.today deprecation. I've suggested that the message not be made visible for a little while (so we can hopefully get the easy/bulk parts of the cleanup done before people start complaining about the error message). WhatamIdoing (talk) 05:53, 23 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]

Phab: might be the right place. See mw:How to report a bug. Just tell them that you're having a problem with searches timing out (they know this is a problem) and that when it's a problem, you'd like to get ____ instead of nothing. WhatamIdoing (talk) 06:04, 23 February 2026 (UTC)[reply]

WhatamIdoing. Timing out isn't really the issue. I've written some fairly complex insource regexes (The fact that look-ahead/look-behind aren't allowed isn't that surprising) It's the how do we get from stevens to sevens. (In a similar situation it suggests fraternitys (yes, an improper plural) for a complex insource plus fraternity. And I'm not honestly sure it would count as a *bug*, but more of a discussion, which is why jumping to Phab doesn't seem right.Naraht (talk) 13:27, 23 February 2026 (UTC)[reply]

Phab takes feature requests, too. Anything that needs a code change is going to require a Phab ticket eventually. WhatamIdoing (talk) 19:36, 23 February 2026 (UTC)[reply]

Naraht, if I understand what you are saying, this is nothing new and is already described at mw:Help:CirrusSearch#Using the index first to filter results. You could try asking at mw:Help talk:CirrusSearch. Or, try a Phab enhancement request, but I'm not sure how far that would get as Cirrus is built on mw:Elasticsearch and what you are asking for isn't fixable by MediaWiki, I don't believe. Just follow the recommendations for responsible regex requests (which it seems you are already doing, and discovered by yourself) and you should be fine. Mathglot (talk) 03:08, 24 February 2026 (UTC)[reply]

I've been a huge fan of checking in on the featured article and especially the featured picture on the main page each day. I remember reading something about certain audio files being promoted on the main page as part of a Today's Featured Audio section, or something like that. Did this ever happen? And if so, could it be brought back? There is such a great variety of audio on the site, such as historical speeches, animal calls/sounds, and recordings of instruments and compositions. These audio tracks bring so much colour and depth to articles, and I think having a section on the main page for them is more than warranted. RedRampageRuckusRaider (talk) 04:29, 22 February 2026 (UTC)[reply]

We used to have Wikipedia:Featured sound candidates. Per this search, they've only appeared on the Main Page once for Wikipedia's tenth anniversary. Graham87 (talk) 05:30, 22 February 2026 (UTC)[reply]

I really like this idea! Amercer1 (talk) 02:34, 23 February 2026 (UTC)[reply]

What does exist is the 'Media of the Day' tile on the Commons frontpage. See audio files previously featured there here. Prototyperspective (talk) 17:08, 23 February 2026 (UTC)[reply]

Hi! I saw in Village Pump (proposals) that User:SunDawn said Today's Google Doodle is about Winter Olympics, a Google logo but the Os are replaced with a puck and a hockey stick, a funny thing. It still appears as that when I searched about "holocaust" and about "Putin invasion". Both are very serious issue and Google is not changing their look for such matter. and I wondered... could we add a mechanic where on a genocide-heavy page, the baby globe would appear, but then be scared away by the topic? Thanks!

P.S. If this is the wrong place to discuss this, please tell me. SeaDragon1 (talk, contributions) 14:29, 24 February 2026 (UTC)[reply]

This seems yet more frivolous than the example that SunDawn was complaining about, and thus yet more offensive. Add to that that it would require a fair amount of effort to implement and this idea seems fundamentally unworkable. _signed, Rosguill ^talk 14:33, 24 February 2026 (UTC)[reply]

Oh, okay. Just thought it would be kind of cool. SeaDragon1 (talk, contributions) 14:36, 24 February 2026 (UTC)[reply]

This implies that the baby globe manages to keep absolute perfect composure at genocide, war crimes, dictatorships, and other horrors of man. I wouldn't want to have to face him in a match of poker. ~2026-11404-95 (talk) 15:04, 24 February 2026 (UTC)[reply]

What I meant was:

The Baby Globe (if it appeared on ALL pages) would be scared by the title and flee off to... wherever.

Or cry. That works too. SeaDragon1 (talk, contributions) 16:17, 24 February 2026 (UTC)[reply]

The VPP discussion got long and difficult to navigate, but don't worry, baby globe will be OK. The baby globe will only appear on a pre-determined set of articles, not every article. (The exact list of articles can be found on Meta-Wiki if you know where to look, but I haven't been sharing this list so as not to spoil the surprise.) ClaudineChionh (she/her · talk · email · global) 22:29, 24 February 2026 (UTC)[reply]

I think your idea is kind and foundamentally right in theory but i see this as hard to implement in practice Madotea (talk) 16:56, 1 March 2026 (UTC)[reply]

I am in agreement with @Madotea for this, implementing this feature would take a lot of unnecessary templates and code complexity, and would almost guarantee that every single page relating to any form of atrocity would end up with a Wikipedia:TURQUOISELOCK. ~2026-11404-95 (talk) 14:01, 4 March 2026 (UTC)[reply]

Also, the "Baby Globe Fear" module would be a big pain to fix, not only because of how complex it would be, but because of the fact that it would get a Wikipedia:PINKLOCK before you can say damn you Red Baron! ~2026-11404-95 (talk) 14:04, 4 March 2026 (UTC)[reply]

I meant like how the baby globe appears on pages, right? Well, maybe if the globe appears on a... let's call them no-no pages for now. Anyways, if the globe appears on a no-no page, then it plays a video (which is literally just what the baby globe is) of it getting scared and running away, then delete the <video> element.

Pseudocode:

if (fearPages.includes(pageName))
{
    let video = document.createElement("video");
    video.setAttribute("loop", "");
    video.setAttribute("src", `/w/extensions/WP25EasterEggs/resources/media/video/scared-${mode}.webm`);
    video.setAttribute("style", "width: 100%;height: 100%;object-fit: contain;");
    easterEggContainer.appendChild(video);
}

SeaDragon1 (talk, contributions) 22:21, 4 March 2026 (UTC)[reply]

Robert Carradine is a well-known actor whose death is attracting a lot of attention currently. I first noticed this at In the News where the nomination is already mired in the usual nitpicking – I raised an objection myself. Then, this morning, I see that his article was the top read yesterday with over a million views, along with many other members of the Carradine family. This pattern is fairly typical and Eric Dane got similar attention when he died recently.

As our ITN is not handling this expeditiously, I looked at how it was playing on other projects. Starting with other European languages that I can understand, I found that Carradine had already been posted on the main page of the Wikipedias for French, German and Spanish, along with his picture (right). I've noticed before that they usually get such deaths posted without delay but I'm not sure what their process is and the language barrier makes it difficult to find out. We have pages that likewise get this done quickly such as Portal:Current events and Deaths in 2026 which have already posted the death too. So our ITN is quite an outlier.

Looking further, I checked out Wikidata and found that its main page has a similar section called Related to current events and that this currently lists both Eric Dane and Robert Carradine. I'm more familiar with the internals of that project and so looked at how this was done. It turned out that there's a bot which populates that section of their main page automatically: MsynBot 11. This was created by MisterSynergy and the code is on Github. I'm not sure exactly what its logic is but it seems to work well enough – well done!

We could use something similar here to automatically list such trending topics on the main page. We already have the WP:TOP25 but that requires manual effort, runs on a weekly cycle rather than daily and isn't surfaced on the main page. So, the idea to discuss is that we might borrow this concept and tech to set up something similar here.

Andrew🐉(talk) 11:30, 25 February 2026 (UTC)[reply]

Automatically listing popular articles seems like it would quickly run into conflict with a fundamental principle of all of the current main page sections that articles must meet a certain quality standard (in the case of ITN, WP:ITNQUALITY). A bot could automatically avoid articles with major cleanup tags, but ITNQUALITY also advises Articles should be a minimally comprehensive overview of the subject, not omitting any major items. Stub articles are never appropriate for the main page. Articles should be well written with clear prose. Articles which consist solely or mostly of lists and tables, with little narrative prose, are usually not acceptable for the main page, and prose should be in narrative style, not proseline-type writing. – most if not all of these restrictions would be difficult or impossible to automatically enforce. Caeciliusinhorto-public (talk) 17:02, 25 February 2026 (UTC)[reply]

There's no such fundamental principle. Many articles linked on the main page have issues and this is especially common in some sections such as the Featured Picture. That's why WP:ERRORS exists. And why the main page has the usual disclaimers. The fact that Wikipedia makes no guarantee of validity is its actual fundamental principle.

Of course, some quality filters might be used by the bot logic, as suggested, and this is commonly done in such displays to exclude spurious articles which seem to be artifacts such as .xxx. For example, see the equivalent Top Read card in the app.

Andrew🐉(talk) 17:14, 25 February 2026 (UTC)[reply]

Editors like to have control over what readers see. Periodically someone points out that trending articles are shown in the Wikipedia app. This usually freaks someone out, but it also gives you an answer: If you want that, use the app. WhatamIdoing (talk) 19:32, 26 February 2026 (UTC)[reply]

But editors don't control what readers see. Such popular and trending articles are, by definition, the ones which are already being most read. Most readers choose articles themselves using search engines and editors have limited control over those. So, for example, Robert Carradine was the most read article on the English Wikipedia yesterday, even though it has yet to appear on the main page, being still hung up at ITN. It got about ten times the views of the featured article which was a worthy but rather dull topic.

So, the main page listings are mainly for the benefit of the Wikipedia community as they are more likely to read them than the general public. By highlighting what's getting the most traffic, the community is alerted to what's hot and can check that it has not got serious problems such as vandalism. If you're not tracking this then you're working in the dark.

Andrew🐉(talk) 20:57, 26 February 2026 (UTC)[reply]

If editors want to see what is currently getting the most traffic, there are backrooms ways to do that already – Topviews, the weekly Top 25 report, weekly most edited article report. The mainpage currently averages about seven million views per day; it's disingenuous to suggest that it's mainly read by members of the Wikipedia community rather than the general public. If you want better ways of tracking spikes in readership, then propose that; that's not what the main page is for. Caeciliusinhorto (talk) 19:57, 1 March 2026 (UTC)[reply]

I know the very existence of temporary accounts is controversial, but let’s assume that allowing people to edit the encyclopedia while logged out or without a permanent account at all serves some useful purpose, such as minimizing barriers to people who can contribute meaningfully. I get all that, but I question whether that extends to user talk pages or other “back of the house” discussions.

So the idea is this: if you don’t want to edit with a permanent account for whatever reason—-great. But your contributions are limited to articles and article talk pages, where there is almost no reason to know what your contribution history is. Let your contributions stand on their own merits. But in other contexts, such as administrative discussions, where the user’s involvement in discussions may be relevant, or on user talk pages, where the user with a permanent account is left wondering whether they’ve ever interacted with this user before, you need a permanent account. Those discussions can seem (or get) pretty personal, and the cloak of complete anonymity lowers the quality of discussions when one user can see an editor’s entire contribution history, and the other’s rolls over every so often.

Thoughts? Dustinscottc (talk) 23:26, 25 February 2026 (UTC)[reply]

At absolute minimum temporary accounts need to be able to edit their own user talk pages, and to contribute to project-space discussions about their edits/behaviour. Thryduulf (talk) 00:42, 26 February 2026 (UTC)[reply]

In addition, having access to draft space and other user's talk pages is probably a very good idea. This lets them create articles and ask a question to another person. File namespace is probably also a good idea. Tazerdadog (talk) 00:49, 26 February 2026 (UTC)[reply]

I could possibly get on board with draft space, but not about other users’ talk pages. I think editors who get more involved with long-term discussions — especially discussions that are inherently targeted at other users — need to be transparent about the kinds of conversations they have had in the past. If you want to be a part of community discussions, I think it’s reasonable to be required to adopt a consistent identity as part of the community. Dustinscottc (talk) 15:51, 26 February 2026 (UTC)[reply]

I agree with that, which makes me wonder whether it would be too difficult from a technical perspective. Dustinscottc (talk) 15:47, 26 February 2026 (UTC)[reply]

No, it'd be easy: you'd give them access to the Wikipedia: and Wikipedia_talk: namespaces, plus User_talk: because someone could be talking about them in any of those spaces.

So now the list is Main, Talk:, User:, User_talk:, Wikipedia:, Wikipedia_talk:, Draft:, Draft_talk:, and that's probably 99% of edits, so why bother adding restrictions?

Maybe instead of proposing a solution (e.g., restricting edits to certain namespaces), you could tell us what problem you'd like to solve. For example, I see that a TA suggested that you be more civil on an article's talk page – probably referring to this comment aimed at a long-time admin – so now you don't want TAs to be able to leave notes on your talk page. And I'd have to ask: So, do you instead want them to address your behavior in the middle of the article's talk page, where everyone in that discussion will see it? Or at ANI? Or do you just not want anyone to tell you that you were not showing an optimal amount of civility, so you can be shocked when enforcement actions appear? Or maybe you just want someone with a registered account to say it, because it's more impressive if you hear this from someone who spent 15 seconds registering an account than from someone who didn't (or doesn't happen to be logged into their account from the computer they're using)? WhatamIdoing (talk) 19:49, 26 February 2026 (UTC)[reply]

No, I’d like to be able to identify disruptive editors. There was no civility problem. Meritless notices are disruptive. When a user is registered, it’s easier to tamp down the disruption by keeping the user accountable for past and future disruptive behavior. When it’s a TA, there’s no good way to identify

The incident that prompted this is not a big deal, but it’s easy to see how it could become a big deal. Minor concerns about single comments can and should be addressed in the discussion where they occur. If users of TAs become interested in policing discussions and trying to enforce Wikipedia norms, then they should sign in. Clearly, there is some value to being able to see a user’s past contributions. After all, you just did it.

And no, my revised thinking is not all the pages you listed. It’s Main, Talk, and their own User talk space. TAs should not even have access to their own page other than their talk space because it’s all temporary anyway. Dustinscottc (talk) 20:26, 26 February 2026 (UTC)[reply]

It sounds to me like you agree that if someone posts a thoughtful comment in a discussion, and some guy on the internet who disagreed with that POV responded by saying "Well, I think this comment illustrates that we’re past the serious debate portion of this RM", then this would not exactly make the poster feel like their participation was welcomed and valued by this person. Therefore, maybe there actually was a civility problem.

I agree with you that your comment wasn't a big deal relative to community practices, but there is widespread disagreement about whether minor problems should be addressed in the discussion where they occur. Some people feel like a note on your User_talk: is more private, or that side discussions about behavior shouldn't be placed in main discussions, where they could distract from the discussion or be seen as a way of discrediting your POV. Others are horrified that their less-than-perfect behavior is being highlighted to the people who watch their talk pages, whose respect they want to keep.

Everything's temporary. The median number of days for an active registered editor is 1. The median number of edits made (among those who make any edits at all, which is already a minority) is 2. That's not much opportunity for seeing a user's past contributions. WhatamIdoing (talk) 21:00, 26 February 2026 (UTC)[reply]

So first of all, the civility complaint was not about that comment, which I also don’t think violates the civility standards. It certainly is no more uncivil than your list of rhetorical questions above. The comment I was responding to was, intentionally or not, not a serious comment, and was in fact illustrative of the kinds of unhelpful comments that were little more than commentaries about what people think of Elon Musk’s acquisition of Twitter or how X is currently operated. Pointed comments do not present a civility problem. All of which is off-topic. If you want to discuss further, come on down to my talk page.

More to the point here, user talk pages are inherently personal. Access to them is not necessary to allow unregistered users to contribute meaningfully to the encyclopedia, and any benefit is outweighed by the risk of anonymous harassment. Dustinscottc (talk) 21:15, 26 February 2026 (UTC)[reply]

On your talk page, you claimed that you didn't know which comment the person was complaining about. But now you do? Which one do you now think they were complaining about?

That TA made 19 edits over the space of four days. Compare that against the Registered editors by edit count: If they'd registered an account for those edits, they'd be in the top 5% of Wikipedia editors of all time by edit count. And I'd bet that they'd still be telling you that they didn't appreciate your comments. (NB that I'm neither agreeing nor disagreeing with them about that; I'm just saying that registration doesn't magically change people's POV on what's polite.) WhatamIdoing (talk) 21:49, 26 February 2026 (UTC)[reply]

Editor that made Dustinscottc make this section here. I will do the right thing here owning up to an honest mistake and fully apologise for and admit the fact that that was not their error, it was mine because I accidentally linked the Twitter RM when the WP:NPA was actually on their user page. I explained everything here.

Your other points still stand though. ~2026-12020-63 (talk) 22:31, 26 February 2026 (UTC)[reply]

User who added the warning box here. There was a civility problem, please stop lying: [1] [2]. ~2026-12020-63 (talk) 22:19, 26 February 2026 (UTC)[reply]

No. SuperPianoMan9167 (talk) 00:59, 26 February 2026 (UTC)[reply]

I don’t think anyone believes that granting access to some tools and not others makes unregistered users not human. Unregistered users can’t do some things already. The idea I’m floating would not inhibit the vast majority of useful contributions that unregistered users make, which is to directly contribute to articles. Dustinscottc (talk) 15:55, 26 February 2026 (UTC)[reply]

Under your revised proposal, TAs would no longer be able to report vandalism, request page protection, discuss changes to policy, participate in Village Pump discussions, participate in XfD discussions, comment on noticeboards, update file descriptions, create drafts, fix template documentation, revert vandalism to a category page, discuss changes to a help page, etc.

This would absolutely inhibit useful unregistered contributions. SuperPianoMan9167 (talk) 20:32, 26 February 2026 (UTC)[reply]

The vast majority of TA edits are to articles and talk pages. What is so unreasonable about asking for a modicum of accountability for the rest? Dustinscottc (talk) 20:35, 26 February 2026 (UTC)[reply]

The vast majority of registered accounts have only made edits to articles and talk pages. WhatamIdoing (talk) 21:01, 26 February 2026 (UTC)[reply]

I’m not sure I follow your point. I’m not suggesting that registered users should be obligated to do anything other than the same things that TAs could do. Dustinscottc (talk) 21:18, 26 February 2026 (UTC)[reply]

The vast majority of TA edits are to articles and talk pages is your excuse for restricting them to those namespaces.

Well, I'm telling you that The vast majority of edits by registered accounts, especially newly registered accounts, are also to articles and talk pages. What's sauce for the goose is sauce for the gander.

More to the point, "accountability" isn't what you get with a free registered account. In fact, with a TA, senior editors can find their IP address, which sometimes means the actual human can be tracked down. That's why subpoenas ask for IP addresses instead of usernames. WhatamIdoing (talk) 21:53, 26 February 2026 (UTC)[reply]

No. The reason for restricting them to those spaces is that the risk of disruptive behavior due to a lack of accountability outweighs the potential benefit except in the spaces I’ve mentioned. Senior editors can track down IP information for registered users, so there is no advantage to a TA. Dustinscottc (talk) 23:21, 26 February 2026 (UTC)[reply]

IP information for temporary accounts is available to all administrators and to those with the Temporary account IP viewer right accounts (currently 822 and 377 accounts respectively, so nearly 1200 editors and there are also about 276 editors with the global temporary account IP viewer right, although some of them will be included in the first figures).

IP information for registered accounts is available only to checkusers (currently 49 editors) and only in accordance with very strict rules. Thryduulf (talk) 23:39, 26 February 2026 (UTC)[reply]

What "lack of accountability"? The TA showed up here and gave an account of what happened and how. That's literally accountability. WhatamIdoing (talk) 23:41, 26 February 2026 (UTC)[reply]

But when has the user of the TA done similar things in the past? Does this user have a history of posting frivolous warnings on users’ talk pages? Is there context from prior conversations that indicates the user has some kind of grudge? This is relevant information that is obscured by the use of a TA. And if you don’t think that information is relevant, why did you avail yourself of it with respect to my previous conversations? Dustinscottc (talk) 23:51, 26 February 2026 (UTC)[reply]

Being able to check someone's contributions to find out if they're just as "bad" as you isn't accountability. That's "two wrongs make a right" illogic.

If you register a Wikipedia:Clean start, then how would we know if you have done similar things in the past? For all we know, you could have an undisclosed prior account. How would we know if you have a history of posting frivolous (you mean mistaken, right?) warnings on users' talk pages? What's the context from the prior conversations that indicate that you might have a grudge that can only be detected if someone knows your (hypothetical, AFAIK) prior account name? WhatamIdoing (talk) 23:57, 26 February 2026 (UTC)[reply]

I’m not suggesting that the value is from making comparisons. It seems like you are injecting a lot of facts regarding a specific incident, which I’m not interested in discussing here. You’re welcome to post in my talk page if you want to talk about that. But speaking globally, yes, registered users may, on occasion, start over. But they do not do so automatically every 90 days or when they use a different device. For a user with hundreds of edits over several years, you can identify patterns and understand their intent by that wider context. While it could sometimes be true with registered users, it is always true with TAs. Dustinscottc (talk) 00:09, 27 February 2026 (UTC)[reply]

Sure, for the less than 1% of editors who have hundreds of edits over several years, you can sometimes identify patterns and use that information to guess what's going on.

But for the 99% who don't – a group that included you just a few months ago, BTW – you can't. And that's a lot of editors. For example, you suggest that we need "hundreds of edits" to figure out what's going on with an editor, and before then, they shouldn't be allowed to leave a note at someone else's talk page. Your 75th edit ever was to leave a note on someone else's talk page, complaining about behavior that you felt rejected your participation. Ignoring a dozen edits from many years before, you had effectively been editing for five (5) days when you posted that note. Do you think that someone with five days' experience is justified in communicating directly with an editor? And if yes for you, then why not someone with up to 90 days' experience?

The next day, just a few edits later, you were editing Wikipedia:Administrators' noticeboard/3RRArchive490#User:Dustinscottc reported by User:Newimpartial (Result: Both users and an IP blocked from page for a week). Again, if you have been editing for just a few days and are still well short of the "hundreds of edits" you mention here, but you're justified in responding there (I certainly think you were), then why shouldn't everyone else be allowed to? WhatamIdoing (talk) 00:36, 27 February 2026 (UTC)[reply]

I did not say or suggest that one must have hundreds of edits (or any other number of edits) prior to posting on other user talk pages. I am suggesting that users should engage in these discussions in a way that can be viewed over time. The mention of “hundreds of edits” was illustrative, not prescriptive.

But even in your enthusiastic thrashing of the straw man you’ve constructed, I think you’re illustrating my point. For whatever reason, you’ve decided to take the time to dig through my contribution history, going back more than a year. Clearly, that has some value to you. Dustinscottc (talk) 00:47, 27 February 2026 (UTC)[reply]

Yes, it has some value. For example, when people say "Oh, IPs/TAs are bad because one did this", it's usually pretty easy to find an example of me doing that myself when I was new, or the complainer doing that when they were new. It's a way of getting some perspective.

Here, you are complaining that someone who edited as a TA for five days left a complaint on your talk page. But functionally speaking, when your registered account was five days into its "real" editing (I do not count you making a single-digit number edits every couple of years beforehand), you did exactly the same thing: you went to the User_talk: page for another editor and told them that you didn't like them calling you a Wikipedia:Single-purpose account just because almost the only thing you had edited was Talk:COVID-19 lab leak theory, where almost the only thing you had to say was that you objected to any connection being made between the idea that COVID-19 leaked from a Chinese lab and rising anti-Chinese sentiment in other countries.

Why is it okay for you complain directly to an editor on Day 5 as a registered account, but not okay for a TA that edits for five days to do the same thing? Sure, you have kept editing since then, so we can have this conversation a year later. But you also could have quit when you got blocked for edit warring (it's a common response), and the rules have to work with the information we have at hand on the day of the complaint, and not with the information we might have a year later. WhatamIdoing (talk) 02:58, 27 February 2026 (UTC)[reply]

The warning was not frivolous ~2026-12020-63 (talk) 08:58, 27 February 2026 (UTC)[reply]

This would prevent unregistered editors from listing anything on one of the WP:CP subpages or the talk page, which is problematic when we do occasionally get a listing from them. Tenshi! (Talk page) 20:13, 26 February 2026 (UTC)[reply]

Is there a way to follow an article's talk page only? Or is there a way to be notified of new activity on an article's talk page?

Following an article's talk page can keep one up to date with any new discussions or disputes without following the entire article which could lead to excessive notifications. IOHANNVSVERVS (talk) 23:50, 26 February 2026 (UTC)[reply]

@IOHANNVSVERVS, see mw:Help:DiscussionTools#Topic subscriptions. You may need to enable it in Special:Preferences#mw-prefsection-editing-discussion. Then go to Tools > Subscribe. WhatamIdoing (talk) 00:06, 27 February 2026 (UTC)[reply]

This is only for subscribing to already existing talk page entries/topics though, right? IOHANNVSVERVS (talk) 01:14, 27 February 2026 (UTC)[reply]

Slightly lower down on that page is mw:Help:DiscussionTools#Page subscriptions, which I believe is what WhatamIdoing is referring to. It says that you will only be notified about new discussion topics. 45dogs (they/them) (talk page) (contributions) 01:25, 27 February 2026 (UTC)[reply]

Oh, brilliant! Thank you, IOHANNVSVERVS (talk) 01:31, 27 February 2026 (UTC)[reply]

Yes, thank you. WhatamIdoing (talk) 02:45, 27 February 2026 (UTC)[reply]

what im suggesting is a mode where everything appears like your reading a book in a library, it firstly, citations and links flat out don't work, to check citations, you actually have to go to the cites page and links would be like being told to buy this other book, or you could make links and work but lets assume not, you would view articles in pages, swipe to go to a page on the left or right, the first page would be the cover, it show the title, (article name) author, (article creator), writers, (recent editors), publisher, (wikipedia) A [all categories of that article], (categories for that article) and more, i think long infoboxes should be their own page, you could also swipe down or press a button on top to close that book, then you could explore a library of books that are articles, i do think the library idea is unrealistic (?) so i think it is better to have a normal searchbar (?) Misterpotatoman (talk) 06:00, 27 February 2026 (UTC)[reply]

This feature would be extremely complex, and would almost instantly get a Wikipedia:PINKLOCK. Maybe it should be a feature just to turn off links? ~2026-11404-95 (talk) 15:14, 4 March 2026 (UTC)[reply]

There should be a way to search by category with a higher depth. e.g. incategory:"Cities in Australia" doesn't give any results, because it only has subcategories. There should be a way to search within all of these subcategories in e.g. Cities of Australia at once. ChaoticVermillion (converse, contribs) 03:14, 28 February 2026 (UTC)[reply]

If you replace incategory: with deepcategory:, that will search subcategories to a depth of five: see mw:Help:CirrusSearch#Deepcategory. Alternatively WP:PetScan allows you to specify an arbitrary depth. Cheers, SunloungerFrog (talk) 07:09, 28 February 2026 (UTC)[reply]

I had an idea for pages about languages to allow you to go to that language's main page on Wikipedia, it could appear above the article in both English and that language, it would be something like:

This is the English language article for {insert language here}. To browse Wikipedia in {this language}, click here.

Seo an t-artaigil Beurla airson {cuir a-steach cànan an seo}. Gus brobhsadh tro Wikipedia ann an {a’ chànan seo}, briog an seo. GlitchedCheeseSandwich (talk) 18:38, 28 February 2026 (UTC)[reply]

I like it, it's possible people search something like "german wikipedia" and arrive at German language Kowal2701 (talk, contribs) 18:59, 28 February 2026 (UTC)[reply]

Searching something like "german wikipedia" would actually send you to German Wikipedia, the English-language article about the German-language Wikipedia, not German language.

If something like this were implemented, I think it'd make much more sense to have it appear on articles like German Wikipedia, French Wikipedia, etc. than on articles for languages. Someone searching for a language probably just wants information about that language, not to browse Wikipedia in that language, whereas someone searching for another language version of Wikipedia might plausibly be looking to use that language's version of Wikipedia.

However, I'm fairly sure most (if not all) the articles about different language versions of Wikipedia already link to them in their infoboxes, so I'm not sure a notice like this would be needed on those articles. Arguably, having a bilingual notice could be helpful, but then again if a reader is on, say, the article German Wikipedia and wants to read it in German to help them find a link to the German-language Wikipedia they can just use the languages menu to go directly to the German-language Wikipedia, without having to look for a link to it in the English-language article. – Scyrme (talk) 19:14, 28 February 2026 (UTC)[reply]

I had a page that I decided to db-g7 and when it was deleted, I had an urge to thank them, but I don't see an easy way. Could something be added to enable thanks for things like page creation, page deletion, moves, protection addition or removal, etc. I'm expecting that would be technically complicated, but I thought I'd drop the idea here.Naraht (talk) 20:04, 3 March 2026 (UTC)[reply]

Deletions (including speedy deletions) are logged at Special:Log/delete, and you should be able to thank the deleter from there. mdm.bla 20:07, 3 March 2026 (UTC)[reply]

Or you could post your thanks about anything to the user talk page. It's not hard. Phil Bridger (talk) 20:15, 3 March 2026 (UTC)[reply]