Wikipedia:Village pump (proposals)

 Policy Technical Proposals Idea lab WMF Miscellaneous 

The proposals section of the village pump is used to offer specific changes for discussion. Before submitting:

  • Check to see whether your proposal is already described at Perennial proposals. You may also wish to search the FAQ.
  • This page is for concrete, actionable proposals. Consider developing earlier-stage proposals at Village pump (idea lab).
  • This is a high-visibility page intended for proposals with significant impact. Proposals that affect only a single page or small group of pages should be held at a corresponding talk page. Please do not post large RFCs here, but please do post brief, neutral notifications of important proposals here.
  • Proposed policy changes belong at Village pump (policy).
  • Proposed WikiProjects or task forces may be submitted at Wikipedia:WikiProject Council/Proposals.
  • Proposed new articles belong at Wikipedia:Requested articles.
  • Discussions or proposals which warrant the attention or involvement of the Wikimedia Foundation can be held at Village pump (WMF).
  • Software changes which have consensus should be filed at Phabricator.

Discussions are automatically archived after remaining inactive for 7 days.

RfC: Name of the "Discussion" button

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

15 years ago the "Discussion" button was changed to "Talk", in an attempt to encourage participation from new editors. Since then no evidence has been presented in this discussion that this change achieved it's aims. Irrespective of that, there is consensus against changing this back to Discussion, based on a similar mentality. As this discussion may well resurface again in another 15 years of sooner, I'll do my best to summarise the arguments within, or at least those that appeared noteworthy.

The supporters cited consistency with other wikis, the "Talk" connotation regarding AI chatbots, as well as "Discussion" being more recognisable, intuitive, as well as the intended function of the page. The opposers highlighted that there is no evidence that this solves the suggested issues, such as misuse of talk pages and misunderstanding their purpose, and that it remains consistent with the Talk namespace. Further into linguistics, talk and discuss were described as synonyms, while the overview naming convention was also considered to be not broken. Naysayers criticised speculation regarding positive change, along with concerns over implying broader discussion than talking solely about the article. Also that Talk headers exist to clarify the purpose of the page.

As an alternative, over a dozen supporters and opposers (to changing to "Discussion") supported "Talk page", but this wasn't enough to sway the naysayers, otherwise known as the overall sentiment for consensus to not change the button name at present. At around 2:1 with arguments slightly more valid(*) than supporters (who failed to demonstrate evidence of the benefits of such a change), it's noteworthy from a closing perspective that a sizeable portion of both Yays and Nays supported an alternative here. This alternative may therefore benefit from further discussion, but bare in mind that the majority of opposers still did not support this alternative. (*)Naysayers failed to provide demonstrable evidence of why the current Talk button name is better, but the onus wasn't on them to do so for supporting the status quo, thus I considered the support arguments to be slightly weaker.

An interesting take towards the end of the discussion from InfiniteNexus was to Show "Discussion" for signed-out users and new accounts; show "Talk" for established accounts when signed in; retain "Talk" as the name of the namespace, but nobody appeared to take an interest in this alternative proposal, apart from myself. Also discussion on changing the namespace occurred, with lack of support generated. Finally quick plug for related RfC on adding talk headers to existing talk pages, for those unaware and also interested. (non-admin closure) CNCin solidarity (talk) 16:52, 23 October 2026 (UTC)


Fifteen years ago, we decided to change the label of the "Discussion" button to "Talk". Should we change it back to the default label? 16:03, 3 September 2026 (UTC)

Current label
Default label

Survey (button name)

Yes. And other language Wikis usually say discussion, eg Italian, French etc. Yesterday, all my dreams... (talk) 16:07, 3 September 2026 (UTC)
Yes (ETA: if "Discussion" does not pass, my second choice is now "Talk page". 23:48, 27 September 2026 (UTC)) because:
  • More and more of our readers are assuming that the "Talk!" button on our articles takes them to an AI chatbot.
  • As was explained below, users are mistaking it for text-to-speech. Most online news articles nowadays have a button that reads the article aloud for them.
  • Most people reading foreign Wikipedias probably have a decent grasp of the language, but enwiki is the largest and typically attracts more non-native speakers. "Talk!" is more recognizable than "discussion" and it's also an imperative verb.
  • "Talk" is the more opaque of the two terms for newcomers, which further helps to hide its intended function, which is to "discuss" how to improve the article itself, not to "talk" about the topic of the article. "Talk!" also has a broader meaning and can be used in context where "discussion" cannot.
FaviFake (talk) 20:56, 3 September 2026 (UTC)
I have already seen these reasons, no need to ping in an edit summary please. --ABx11 (she/they) 00:44, 4 September 2026 (UTC)
If it moves the needle even a teensy tiny bit, please god yes. I feel like I am the only person monitoring these, it is one of the few places on Wikipedia that actually DOES have a deadline (since you have to remove it before the archive bot gets it, otherwise you aren't allowed to clean it up anymore, joining the nearly 6,000 instances of enshrined untouchable vandalism), and I am so, so, so behind on it. Gnomingstuff (talk) 20:58, 3 September 2026 (UTC)
@Gnomingstuff: re: "you aren't allowed to clean it up anymore" - says who? Where and when was that decided, and was there broad participation? A rule that requires vandalism to be enshrined sounds like a really bad rule and one that should be reconsidered. HierophantOfOmens (talk) 07:12, 5 September 2026 (UTC)
Please do not ping me to a discussion I am obviously aware of given that I commented in it 5 minutes ago. If I want to look at a discussion, then I will do so on my own time. If I am not currently looking at a discussion, then I'm probably doing something else that I would prefer to not be interrupted during. In this case, it was doing the cleanup this whole thread is about, and now I am not doing it, all thanks to your ping.
The RfC was here. Gnomingstuff (talk) 07:15, 5 September 2026 (UTC)
I don't see how one interprets "There is no consensus one way or the other regarding editing talk page archives for any other reason, such as removing a nonsense post that was not reverted prior to archiving ... This close should not be construed as limiting removal of content from archives for other policy-based reasons, such as the legitimate use of oversight or revision deletion, nor should it be construed as affecting the reversion of vandalism to archives, which I don't believe was ever really in question here" (from the RfC close) as meaning "you aren't allowed to clean it up anymore", or that there is any such thing as "enshrined untouchable vandalism". Levivich (talk) 07:24, 5 September 2026 (UTC)
The RFC's closing statement begins: "There is consensus that talk page archives can be edited to remove material that breaches policy, such as copyvio, libel, and serious personal attacks..."
The first link in "the nearly 6,000 instances of enshrined untouchable vandalism" adds a racial slur to someone else's comment. That's obviously something that should be fixed (if it hasn't already been).
Mostly, when I see this kind of comment, though, I'm reminded of User:Betacommand, whom we tasked with tagging WP:NFCC violations. Then we left him to deal with the social fallout all on his own, and it turns out that having the technical skills to find and tag various files did not automatically give someone an endless supply of patience and kindness to people who felt entitled to ignore the legal policies, or at least to yell at someone before making a show of how they're grudgingly complying with these completely unnecessary, overly picky rules. It did not end well. I am concerned that we are doing the same thing to our AI defense folks. WhatamIdoing (talk) 20:35, 5 September 2026 (UTC)
You know, having learned to dabble (a tiny bit) in the site API... I bet you USD $1 that list of 6000 is bigger. — Very Polite Person (talk/contribs) 14:52, 5 September 2026 (UTC)
It absolutely is much bigger, I just have not been doing as much talk page cleanup because I only have so much time between that and AI cleanup. If you count stuff that I have found and fixed before archive bots strike then I suspect the number is in several tens of thousands. Gnomingstuff (talk) 17:47, 3 October 2026 (UTC)
Also support “Talk Page” as a next-best option
Because something has to be changed, and this discussion is like that Onion article “There Is a Huge and Intractable Problem with People Thinking ‘Talk’ Signals a Chatbot/Text to Speech” vs “No, There’s Not (There’s Just Not)” Gnomingstuff (talk) 17:45, 3 October 2026 (UTC)
If you believe that the opposition to "Discussion" is just No, There's Not (There's Just Not) then you either haven't read or haven't understood the opposing viewpoints. While there are some people who are disagreeing that the problem is a significant as proponents for change claim, the more substantive objection is best summed up as "Changing "Talk" to "Discussion" will not solve the chatbot problem, but it will cause other problems". Thryduulf (talk) 21:23, 3 October 2026 (UTC)
Yes to simply renaming the visual presentation of the clickable buttons from "Talk" to "Discussion". Very good idea. We have no justification, need or reason to be the weird outlier versus other wikis, and per other arguments here. — Very Polite Person (talk/contribs) 22:41, 3 September 2026 (UTC)
No per Maddy from Celeste and Very Polite Person below. Firstly there is no evidence that this will solve the problem it attempts to - everybody who thinks "talk" means "discuss this article with a chatbot" will think "discuss" means "discuss this article with a chatbot" so we gain nothing. Secondly the 2011 change was made for a good reason and that reason still exists, we will still refer to the page as a talk page and that will still confuse new editors who cannot find a button for a "talk" page, so we will lose significantly here - possibly even more than we were doing in 2011 as we are facing a bigger editor recruitment problem now than we were then. Thryduulf (talk) 22:50, 3 September 2026 (UTC)

No per ... Very Polite Person below.

I'm confused. Very Polite Person has always supported this proposal from the start, saying it's a very good idea. You're the first person to oppose. FaviFake (talk) 22:59, 3 September 2026 (UTC)
That's because I misattributed a comment, my opposition is per Anomie not VPP (my apologies to both). Thryduulf (talk) 23:05, 3 September 2026 (UTC)
How dare you, etc. All good. — Very Polite Person (talk/contribs) 00:16, 4 September 2026 (UTC)
  • No - Using a different word (“Discussion”) on the tab we click to reach the article’s TALK page makes no sense to me. I would expect to click on a tab reading “Talk” to reach the article’s TALK page. Blueboar (talk) 23:26, 3 September 2026 (UTC)
    Which, incidentally, would also be the button you'd expect to click in order to talk with other users (or with a chatbot) about the topic, or to have the article automatically read aloud to you... FaviFake (talk) 23:34, 3 September 2026 (UTC)
    Nah… to have the article read out loud I would expect a “Read out loud” button. Blueboar (talk) 18:12, 3 October 2026 (UTC)
    Sure, but if you had to choose between "Talk" and "Discussion", you would click "Talk", as in "Page, talk to me!".
    Anyway, would you support the alternative Talk page which has been proposed below? FaviFake (talk) 18:32, 3 October 2026 (UTC)
    I see them as the same, so… meh… I really don’t care. Blueboar (talk) 21:08, 3 October 2026 (UTC)
    If all the other equivalent encyclopedias apparently use their native tongue "Discuss", why wouldn't we want to be doing it how the others are? — Very Polite Person (talk/contribs) 00:18, 4 September 2026 (UTC)
  • Yes per Favi and Gnoming, "discussion" is much more intuitive, and we should be targeting readers' and newbies' experiences here. One of the faults of our decision-making process is that only experienced editors participate and prioritise their own experience. Kowal2701 (talk, contribs) 00:14, 4 September 2026 (UTC)
    The argument in favor of Talk, both in 2011 and now, is that "Talk" is more intuitive since it's the name of the namespace, and it's what everyone calls it, and that it would be better for readers and newbies to therefore have the button called "Talk." They're not prioritizing their own experience, they're targeting readers' and newbies' experiences.
    So does anyone on either side of this debate have any actual data to present, or are we just voting based on our own personal experience/opinion of what is less confusing for others? Levivich (talk) 01:54, 4 September 2026 (UTC)
    True, and it's the latter, no idea if there's a way to request data collection via survey (there should be) Kowal2701 (talk, contribs) 02:42, 4 September 2026 (UTC)
    Do the however many tens of thousands of prompt junk posts I have reverted count as data? The neverending deluge of stuff like this day after day after day, hundreds per week, thousands per month. Gnomingstuff (talk) 06:58, 5 September 2026 (UTC)
    No. I'm not talking about data that people misuse talk pages, anyone that's read some knows that. I'm talking about data about the button label. That edit wouldn't be prevented if the button was called "Discussion." A survey, as Kowal suggested above, and A/B testing, as CMD suggested in the discussion section below, could bring useful data, though. Levivich (talk) 07:12, 5 September 2026 (UTC)
  • (edit conflict) Weak no because while talk might suggest that the Talk page is for discussing the subject of articles, discussion isn't better in this regard. Of course, if the proposer has a better idea or wishes to clarify, I am open to changing this vote. --ABx11 (she/they) 00:17, 4 September 2026 (UTC) Hard no. The only reason that has been presented to me via a ping isn't sufficient as I had already seen these reasons. And after seeing the arguments against it presented elsewhere, I'm convinced that this might cause confusion, and frankly, I'm not even convinced that it even helps in this regard. --ABx11 (she/they) 21:22, 5 September 2026 (UTC)
  • No per Maddy from Celeste BilledMammal (talk) 00:19, 4 September 2026 (UTC)
  • No per Blueboar, Thryduulf, et al, and per the 2011 discussion that lead to the change to "Talk" in the first place. The conclusion drawn then remains very much valid. A tab leading to the Talk: namespace should be labeled "Talk".
Plus I think the idea that somehow "Talk" leads people to think it's a chatbot and "Discussion" will not is an unfounded conclusion. That really would need some sort of actual supporting evidence besides anecdotes, because I haven't seen any such activity. (I have seen many cases where none-too-bright people for some idea think it's a page for contacting the subject of the article, but that can be dismissed as clear lack of competency.)
Finally, what other language Wikipedias do is irrelevant. Each language Wikipedia is a separate entity. Yes, a lot of them use the cognate of "discussion" for that tab. But they also use that cognate for the namespace for their discussion pages. Which circles back to the whole reason the English Wikipedia tab is "Talk". It matches the namespace. To change the tab and not the namespace makes little sense. Either change both or change neither. Changing only one creates unnecessary confusion. oknazevad (talk) 00:41, 4 September 2026 (UTC)
Furthermore, Talk and Discuss are synonyms, so I'm not seeing the tangible benefit. --ABx11 (she/they) 00:44, 4 September 2026 (UTC)
  • No Way, way too many references to "the talk page" litter the database and help guides. This would make "the talk page" harder to find and I don't see the value. * Pppery * it has begun... 03:11, 4 September 2026 (UTC)
  • No Fiddling with labels won't help people who are unfamiliar with Wikipedia. Having a discussion button that leads to talk is confusing (absurd, actually). Discussion invites commentary even more than talk. Johnuniq (talk) 06:17, 4 September 2026 (UTC)
  • No (summoned by bot) Fiddling with labels won't help people who are unfamiliar with Wikipedia. Having a discussion button that leads to talk is confusing To the extent that there may be a problem (not sure of that), this isn't going to provide an answer IMO. All websites have their particularities and at least WP doesn't periodically reframe its appearance for trivial reasons. Pincrete (talk) 07:50, 4 September 2026 (UTC)
  • (summoned by bot) No per oknazevad and Pppery. As others have said, what other Wikipedias do is irrelevant, it would lead to more confusion from newbies, and it wouldn't decrease confusion with AI chatbots. Kovcszaln6 (talk) 10:19, 4 September 2026 (UTC)
  • Yes "Discussion" is a noun, while "talk" is a verb. Velocifyer (talk) 17:27, 4 September 2026 (UTC)
    From the Merriam Webster dictionary: "Talk: noun ... 4: a formal discussion, negotiation, or exchange of views —often plural" - Donald Albury 19:02, 4 September 2026 (UTC)
    They probably meant to say that "Talk!" can also be interpreted as a verb while "Discussion" can only be interpreted as a noun. FaviFake (talk) 19:40, 4 September 2026 (UTC)
  • No Perhaps a bit counterintuitively, contra some of what is said above, "discussion" would lead new people to think it's a place for discussing the article in general i.e. a forum. Jahaza (talk) 20:57, 4 September 2026 (UTC)
  • No I do not see a net positive from making the change. - Donald Albury 23:23, 4 September 2026 (UTC)
    I consider "Talk page" to also be acceptable. Donald Albury 18:55, 13 September 2026 (UTC)
  • Yes, as a small but hopefully meaningful step in the right direction. I would also be open to changing this for a month or so, and seeing if there was any meaningful difference. Axolitl (talk | contribs) 16:22, 5 September 2026 (UTC)
    I would also support Talk page. Axolitl (talk | contribs) 04:09, 13 September 2026 (UTC)
  • No per Thryduulf. —Kusma (talk) 20:49, 5 September 2026 (UTC)
  • No. Ain't broke, so don't "fix" it. Seraphimblade Talk to me 01:33, 8 September 2026 (UTC)
  • Talk page. (see ExtantRotations' comment below) I think this is unambiguous and less likely to be confused with LLM slop chatting. I doubt this option will reach consensus, but "yes" and "no" are both bad choices as they have too many drawbacks. --not-cheesewhisk3rs ≽^•⩊•^≼ ∫ (pester) 17:02, 8 September 2026 (UTC)
  • No to "Discussion", Yes to "Talk page" per ExtantRotations. --Ahecht (TALK
    PAGE
    )
    18:38, 8 September 2026 (UTC)
  • Sure we can always change back again. 15 years seems an appropriate time to try something new. —TheDJ (talk • contribs) 22:22, 8 September 2026 (UTC)
  • No. I don't mind causing confusion/alarm/despondency with a change if there's a clear benefit, but here I think it's just speculation to say that one of these words is better than the other. This would create a lot of fussing and complaining and I can't believe it would be worth it. Mike Christie (talk - contribs - library) 23:57, 8 September 2026 (UTC)
  • No. I think that the term Talk describes the intended purpose adequately. GrinningIodize (you just lost the game) (talk) 22:35, 9 September 2026 (UTC)
  • This is oddly specific, but I would permanently change the button to "Discussion" for only ChatGPT and the other articles on the AI chatbots. Why are people always Googling ChatGPT when they could use Google AI mode? For the other pages, lean yes as a trial. EDIT 02:41: Actually, yes, per FaviFake, and additionally because that's what Commons does as well. Also, I believe it should be made clear that only the button's name is changed, not the namespace. Hason-LEK-🇸🇬 ● 💬 ● 🧱 ● 🧪 02:38, 11 September 2026 (UTC)
    There are way more of these than one would think, I've been requesting semi-protection on the most common offenders but new ones keep popping up
    worst of the lot are the ones on deepfakes because the prompts are specifically people asking for revenge porn Gnomingstuff (talk) 21:09, 13 September 2026 (UTC)
    FYI I'm okay with "Talk page", I know the inconsistency between ENwiki and the other Wikimedia projects will still exist, but I'm willing to compromise. Hason-LEK-SIN ● 💬 ● 🧱 ● 🧪 01:51, 3 October 2026 (UTC)
  • Oppose change to "Discussion". As User:Johnuniq said, the word "discussion" invites even more commentary than "talk", and it'll make it sound for new users like the comments section from a journalism site. Concerns of "talk" implying a chatbot is IMHO weird, because... how? At most, a new user would reasonably mistake it for a recommendations comment thread or help desk. Plus, {{Talk header}} exists and that cancels out most of the concerns with new users not understanding the purpose of talk page. Too many things in the encyclopedia says "talk page" and making a mandate to change that would be time-consuming and we don't need to fix what is not broken. I would support change to "Talk page" as per User:not-cheesewhisk3rs. In solidarity, Brynn Who Likes Editing | talk w/ me! 07:58, 11 September 2026 (UTC)
    Concerns of "talk" implying a chatbot is IMHO weird, because... how?
    I don't know what to say here, if people who actually do talk page patrol are telling you that this is a thing, then it seems at least worth considering that they know what they are talking about
    see also the edit histories of basically any even tangentially AI-related page, many of which (e.g. Talk:Google Gemini) have banners added by people who could tell you that this is a thing Gnomingstuff (talk) 21:11, 13 September 2026 (UTC)
  • No The "Article" button takes the user to the page in articlespace. The "Talk" button takes the user to the page in talkspace. Giving more names to this space would likely just add to the confusion, and "Discussion" doesn't make the purpose much clearer either. Would likely support "Talk page" though. FlammablePizza (talk) 01:07, 13 September 2026 (UTC)
    Article and talk aren't the only namespaces though. On Wikipedia pages it says "Project page", in MediaWiki it says "Interface page", User says "User page" etc. Axolitl (talk | contribs) 04:08, 13 September 2026 (UTC)
    That being said, "Talk page" is a valid option. Axolitl (talk | contribs) 04:09, 13 September 2026 (UTC)
  • No to "Discussion", Yes to "Talk page". I'm with others here that changing it to 'Discussion' would be unnecessarily confusing re: the discrepancy between that term and the namespace, as well as with all the existing references to talk pages that are all over essays, help pages etc. Changing it to "Talk page" seems to elegantly solve all of the issues that people have with "Talk" without running into the problems with "Discussion". Athanelar (talk) 00:47, 14 September 2026 (UTC)
  • No with caveats as per Blueboar and the 2011 discussion, with my caveat being that we try and make sure all talk pages have the this is a talk page notice for new users. I don’t know if there’s a tool for speeding that process up, though I’m sure it’d be easy to implement in tools such as rater, though that is a separate discussion.Edlectro28 (talk) 15:42, 22 September 2026 (UTC)
    Unfortunately that's controversial and we would need a different RfC for that, but, luckily for you, I'm already working on it! Please feel free to comment at WT:RFC § Add the Talk header template to existing article talk pages before the RfC goes live. FaviFake (talk) 15:48, 22 September 2026 (UTC)
    I got carried away! Anyway, my no still stands, and that’s great timing and thanks for letting me know. I’ll be sure to say my piece over there. Edlectro28 (talk) 15:52, 22 September 2026 (UTC)
    Perfect! (To clarify, the actual RfC will happen on this page, that's just the workshop discussion.) FaviFake (talk) 16:06, 22 September 2026 (UTC)
    Thanks Edlectro28 (talk) 16:08, 22 September 2026 (UTC)
    Change to "Talk page" as this can solve the problems mentioned in this RFC and the one 15 years ago. Szxq (talk) 04:08, 23 September 2026 (UTC)
  • Oppose "Discussion" per the 2011 discussion; Support "Talk page". "Talk page" would match the style of tab name used on other Wikipedia interface instances, and would be even less likely to be confused for discussing with a chatbot than either "Discussion" or the status quo "Talk". Regards, User:TheDragonFire300. (Contact me | Contributions). 05:16, 25 September 2026 (UTC)
  • Change to "Talk page" – not a major change that disrupts the past 15 years of display, the namespace name, or the edit history and wiki culture; however, seems like a promising way to cut down on people thinking the talk page is a chatbot. Skarmory (talk • contribs) 23:41, 27 September 2026 (UTC)
  • No WP:BIKESHED. ~~ AirshipJungleman29 (talk) 10:47, 30 September 2026 (UTC)
  • Oppose "Discussion" as no one refers to it as such, it would still confuse newcomers; leaning to supporting a change to "Talk page" as that's commonly referred to as such and is quite a bit more clear than just "talk". AlphaBetaDeltaLambda(αβδλ)talk 22:24, 2 October 2026 (UTC)
  • Show "Discussion" for signed-out users and new accounts; show "Talk" for established accounts when signed in; retain "Talk" as the name of the namespace. The problem primarily stems from confusion from users unfamiliar with Wikipedia jargon, not experienced users. InfiniteNexus (talk) 19:49, 12 October 2026 (UTC)
  • No, I would expect a link going to the talk page to be labelled "talk". Would prefer "Talk page" over "Discussion", but would prefer the status quo most of all. Arnav Bhate (talk • contribs) 03:34, 22 October 2026 (UTC)

Discussion (button name)

Presumably, "Talk:Foo" would automatically be created (or maintained) as a redirect to a given "Discussion:Foo"? BD2412 T 16:53, 3 September 2026 (UTC)
No, only the label of the button would be changed, not the name of the page itself. The pagename of the talk pages have always started with "Talk:", even before we changed the button label to "Talk". FaviFake (talk) 17:01, 3 September 2026 (UTC)
Wait, so this proposal is JUST changing the visual presentation of the buttons on web and mobile versions of the page from "Talk" to "Discussion"...
...and that's it? If so can you make the RFC a teeny bit clearer that it's a MUCH smaller but impactful change, and as editors there is no actual impact? — Very Polite Person (talk/contribs) 22:40, 3 September 2026 (UTC)
Yes, exactly!
 Done, and i also added a side-by-side image comparison for clarity FaviFake (talk) 22:52, 3 September 2026 (UTC)
Why change just the label and not also the namespace? Levivich (talk) 23:07, 3 September 2026 (UTC)
The default namespace is fine. When editors open a talk page, they're almost always greeted by a {{talk page banner}} that immediately tells them in a bolded font that "This is the talk page for discussing improvements to the [Weather] article. This is not a forum for general discussion of the subject of the article." We couldn't ask for a better notice.
The button, on the other hand, is completely ambiguous: it just says "Talk!", which is website design means "talk with our chatbot!" or "chat with the community!". There's a reason "Discussion" has always been the default. Plus, changing the namespace would be a nightmare, while changing the label of a button literally takes 1 second. FaviFake (talk) 23:20, 3 September 2026 (UTC)
It probably isn’t just chatbots — it really started to accelerate in early 2022 (before ChatGPT and derivatives) and some comments show indicators that the users are mistaking it for text-to-speech, Siri, etc. No I don’t have any diffs handy but I have personally dealt with tens of thousands of these Gnomingstuff (talk) 23:38, 3 September 2026 (UTC)
I remember a phase from around then of IP users creating talk page sections containing a short phrase repeated in the heading and body (eg. this where a user posts to Talk:Plain with a heading Structural plain and a comment of structural plain). They read like someone trying to search for specific information or navigate to a different article, where they were re-entering the term a second time as a comment in order to make the "Add topic" submit button become clickable. I think some kind of filter was added to stop very short new-thread comments from being posted?
The bigger issue still seems to me to be the new thread talk box itself, with its deeply cryptic request that the user enter not a comment but a "Description". Belbury (talk) 17:28, 8 September 2026 (UTC)
If there's a filter, I don't know about it and it's not working very well. Here's an example from 2 hours ago. (The person they pinged has only ever made one edit, in 2021, to their userpage, so there's virtually no way this is a legitimate attempt to ping them.) I've tried to get a filter put into place, but no one ever did it.
The reason you see this stuff less often now is that I have been going through every single edit made to talk pages, every single day (except when I get behind), since 2025. Gnomingstuff (talk) 07:54, 19 September 2026 (UTC)
Oh, this is the talk page? I wanted the discussion page. I must have clicked the wrong thing. ~2026-47946-04 (talk) 07:21, 4 September 2026 (UTC)
Given that this plan is only to change the display text on the icon, why not change the text to Talk Page instead simply Talk? It removes the ambiguity of being an LLM and is still fewer characters than the current proposal. Plus it remains in line with the existing set up. ExtantRotations (talk) 16:40, 5 September 2026 (UTC)
I think one word, without "page", would be more friendly to newbies and readers. "Discussion" and "talk" are words used for discourse surrounding something, so its purpose as a button seems more obvious. If you were new and saw "talk page", I don't think it would be clear that it is for discussion of the article. Axolitl (talk | contribs) 17:36, 5 September 2026 (UTC)
You know what, I take back what I said. I would not be opposed to adding "page". Axolitl (talk | contribs) 20:37, 5 September 2026 (UTC)
Contra Axolitl, I think this is a very sensible suggestion with few downsides. "Talk page" is no more or less obviously for discussing an article than either "talk" or "discussion", it matches what we tell new editors to look for and the elision of "page" in casual discourse is hardly unintuitive. Thryduulf (talk) 17:39, 5 September 2026 (UTC)
This is a good idea, and will avoid rewritting years of documentation calling it the “talk page”. Velocifyer (talk) 19:15, 5 September 2026 (UTC)
With the exception of the first, the labels are supposed to be verbs. It's an article: talk about it, edit it, view its history, etc. WhatamIdoing (talk) 20:39, 5 September 2026 (UTC)
I would support Talk page as well. --Ahecht (TALK
PAGE
)
18:36, 8 September 2026 (UTC)
Re some of the comments above, is there any reason to think clueless people who think "talk" means talking to an AI chatbot wouldn't think the same for "discussion"? Anomie⚔ 22:09, 3 September 2026 (UTC)
Language barrier possibly, “talk” is a more recognizable word than “discussion” and it’s also an imperative verb
to be clear I don’t expect this to have an earth shattering effect but literally any tiny improvement would help Gnomingstuff (talk) 23:40, 3 September 2026 (UTC)
Would be curious though to hear whether other wikis have this problem to the same extent (proportionate to their size obviously) Gnomingstuff (talk) 23:41, 3 September 2026 (UTC)
I don't think other wikis would have this issue because the default is not "Talk" and, as Yesterday suggested above, most other wikis haven't changed the default. I'm an admin on a smaller wiki myself and we've never noticed editors coming to the talk page to have the article read aloud to them or chat with a bot. I'd guess this is partially due to the fact that we've always kept the default label.
But of course I'd love to know if this problem affects other larger wikis. FaviFake (talk) 23:51, 3 September 2026 (UTC)
Talk:Google sees this kind of disruption about once every few days. de:Diskussion:Google about every few months. Google gets 11 times as many pageviews as de:Google. So they're on the same order of magnitude, but maybe we get a bit more problems per pageview than them? There's so many possible confounding factors though that I wouldn't really put any weight on something like this. For one, most people reading dewiki probably have a decent grasp of German, whereas enwiki is typically a top search result for everyone, so it's to be expected that we get a lot more people who can't really understand what these things mean. ;; Maddy from Celeste (WAVEDASH) 00:14, 4 September 2026 (UTC)
We should remember that other language Wikis have distinct cultures. The French Wiki crowd often know each other surprisingly well, almost like the usual customers at a cafe in Paris. The Italian Wiki has far fewer vagabond editors and apart from hot topics like fascism is rather stable. The Spanish Wiki is somewhat similar. The German Wiki is highly controlled, more than one would expect and most users know the rules. But they all use discussion as the button text. Yesterday, all my dreams... (talk) 05:06, 4 September 2026 (UTC)
I would encourage people to go and have a look at that 2011 discussion. The consensus there was that having the link text differ from the namespace's name was confusing to newcomers, who were being told to go to the "talk page" but couldn't find a "talk" link. I don't see why this wouldn't still apply. ;; Maddy from Celeste (WAVEDASH) 22:43, 3 September 2026 (UTC)
  • This sounds like something that could genuinely, and without significant collateral, be A/B tested. CMD (talk) 03:04, 4 September 2026 (UTC)
    At the very least the placeholder text could be A/B tested (although it would be nice to get a heads up). The reason so much of this stuff has lines like "English", "History", "Social science"/"SST", "MAPEH" etc. is because people who want to cheat on their homework see "Subject" and assume it is a chatbot asking them what the school subject is. Gnomingstuff (talk) 07:02, 5 September 2026 (UTC)
  • A point I forgot to make is that this is a very frequent vector for posts requiring oversight. People will post their actual phone numbers, addresses, bank account numbers, you name it, because they think it's ChatGPT. So if we can discourage that even a little, it's a clear net positive. Gnomingstuff (talk) 06:59, 5 September 2026 (UTC)
    Speaking as an Oversighter, I see no evidence that prompts for Chat GPT are a common reason for posts being oversighted. I've looked at the most recent 20 suppressions on talk pages and only 1 of them seems likely to be an LLM prompt, people have been posting phone numbers, bank accounts, etc to Wikipedia since long before LLMs were a thing (subjectively I don't think it's increased significantly either). I also see no evidence that suggests changing the label of the page will reduce the incidence of people doing this. Thryduulf (talk) 10:57, 5 September 2026 (UTC)
  • Wait, who added this RfC? The signature appears malformed. Hason-LEK-🇸🇬 ● 💬 ● 🧱 ● 🧪 08:12, 5 September 2026 (UTC)
    It's normal to end the statement of the RfC question with just a timestamp, since it isn't supposed to express anyone's opinion. ;; Maddy from Celeste (WAVEDASH) 08:16, 5 September 2026 (UTC)
    I see. Hason-LEK-🇸🇬 ● 💬 ● 🧱 ● 🧪 08:21, 5 September 2026 (UTC)
    This is officially permitted. About 10% of RFCs use that style. A lot of editors never even notice. WhatamIdoing (talk) 20:44, 5 September 2026 (UTC)

Is there empirical evidence supporting either the contention that the current "Talk" label is confusing for some new editors or the contention that changing the label to "Discussion" would be confusing? I'm not comfortable making assumptions and this is something that is testable. ElKevbo (talk) 16:48, 7 September 2026 (UTC)

There wasn't any evidence when we first decided to change it and there still isn't any, afaik. FaviFake (talk) 17:02, 7 September 2026 (UTC)
"We never knew what we were doing before, why start now?" -- Wikipedia, in a nutshell. (Somehow, it actually works.) Levivich (talk) 17:57, 7 September 2026 (UTC)
There was plenty of anecdotal evidence from people who dealt with new editors, e.g. , , . The argument in favour of "discussion" doesn't have even that. Thryduulf (talk) 18:11, 7 September 2026 (UTC)
Should we ping participants whose most recent comment here was posted before "Talk page" was proposed as an alternative solution? FaviFake (talk) 15:51, 30 September 2026 (UTC)
Yes, to see whether there are issues with "Talk page" that have not yet been brought up, and how much support there is for it. --not-cheesewhisk3rs ≽^•⩊•^≼ ∫ (pester) 22:25, 2 October 2026 (UTC)
Courtesy pings: Yesterday, all my dreams..., HierophantOfOmens, Very Polite Person, Blueboar, Kowal2701, BilledMammal, oknazevad, Pppery, Johnuniq, Pincrete, Kovcszaln6, Jahaza, Anomie, Maddy from Celeste, ~2026-47946-04, BD2412, Chipmunkdavis
You are being pinged because you commented on this proposal before the suggestion to change the label from "Talk" to "Talk page" was made. You may wish to comment or amend your existing !vote to specify whether you prefer this alternative compared to the one proposed initially. FaviFake (talk) 22:32, 2 October 2026 (UTC)
I'm not convinced "talk page" will actually help but I have no substantive objection to it. * Pppery * it has begun... 22:34, 2 October 2026 (UTC)
I'm not sure that there is a problem, nor that this will help, but have no substantive objection. Most editors will barely notice the change I suspect. Pincrete (talk) 05:28, 3 October 2026 (UTC)
... That's because editors are not the people being confused by the label. FaviFake (talk) 09:47, 3 October 2026 (UTC)
Meh, I guess. I don't think adding "page" really clarifies anything for the confused; I think the whole thing is a bit WP:BIKESHED anyway. No change is needed at all. If a change is made though, this is better than reverting to "Discussion". oknazevad (talk) 15:16, 3 October 2026 (UTC)
The suggestion that adding "page" [doesn't clarify] anything for the confused keeps being brought up, so I'll revisit my original reasons in light of the new proposal:

More and more of our readers are assuming that the "Talk!" button on our articles takes them to an AI chatbot.
— User:FaviFake 20:56, 3 September 2026 (UTC)

If you compare "Talk!" to "Talk page!", it becomes obvious that the former is more misleading than the other on this front.

users are mistaking it for text-to-speech. Most online news articles nowadays have a button that reads the article aloud for them.
— User:FaviFake 20:56, 3 September 2026 (UTC)

Nobody would ever expect a button that says "Talk page" to read the page aloud for them. The same can't be said about "talk".

enwiki is the largest and typically attracts more non-native speakers. "Talk!" is more recognizable than "discussion" and it's also an imperative verb.
— User:FaviFake 20:56, 3 September 2026 (UTC)

Just like "discussion", "talk page" is not an imperative verb. "Talk", on the other hand, is.
The upsides are basically the same, if slightly less effective than "discussion". FaviFake (talk) 15:33, 3 October 2026 (UTC)
I would suggest that most of the people who are confused enough (in terms of language or technological proficiency) to go through the multiple steps of going to the talk page, clicking "Add topic", writing a post and submitting it, all while thinking they are talking to a chatbot or a text-to-speech system, probably would not be able to appreciate the nuance of us saying "talk page" instead of "talk". ;; Maddy from Celeste (WAVEDASH) 20:30, 3 October 2026 (UTC)
As you said, there are multiple steps of going to the talk page. I'm just trying to make the first and most important step less misleading. Not everyone who clicks "Talk" without knowing what it does ends up completing every step; they might just think "Huh, i must've clicked the wrong button", and go back to the article. We can help those people too. FaviFake (talk) 20:35, 3 October 2026 (UTC)
Give this user a "True..." Hason-LEK-SIN ● 💬 ● 🧱 ● 🧪 23:40, 3 October 2026 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Page mover–specific move protection

Should a new move protection level be created, which only allows page movers and administrators to move pages affected by it? 05:31, 29 September 2026 (UTC)

Survey (mover protection)

Currently there is no in-between between sysop and XC move protection, meaning that in the case of controversial topics (e.g. my earlier close of President Donald J. Trump International Airport) us page movers have to go through RM/TR, despite the fact that the right signifies that the community (presumably) trust us enough to enact these moves ourself. So my proposal is that a new move protection level, which allows only users with the extendedmove user right to move, be added, and add this user right to the sysop and extendedmover user groups. I can make the patch if there is consensus.

(Pinging @Skarmory, who proposed the idea on Discord.) msk 00:59, 25 September 2026 (UTC)

My personal most recent run with this was Talk:Economy of the Haudenosaunee#Requested move 11 July 2026. I see no convincing reason why this should've had to go through an admin.
A comparable user right and protection level would be template editor and template protection. Circumstances are a bit different, but there is precedent for user rights related to specific actions being able to edit past protection of those actions. Skarmory (talk • contribs) 03:03, 25 September 2026 (UTC)
This all seems very sensible to me. Thryduulf (talk) 08:20, 25 September 2026 (UTC)
I would support this. Most move-protected pages are from page-move vandalism or page move warring (source: just a guess), and I think by granting someone page mover the community trusts them not to perform page move vandalism. Axolitl (talk | contribs) 22:39, 25 September 2026 (UTC) edited 22:40, 25 September 2026 (UTC)
I also was discussing this on Discord too at a different time, though in an unrelated context. I would support this, especially since it means that admins would have a reliable middle ground to not need to default to full move protection when extended-confirmed protection is insufficient, except in the most extreme of cases. Any page mover who can't be trusted to, well, move pages responsibly and in accordance with policy, probably should not be a page mover. I think we should probably at least informally expect that admins do not use this new protection level for edit protection, only move protection, similarly to how template editor protection isn't (usually?) used on articles, since it's inconsistent with why the right was created. EggRoll97 (talk) 01:58, 26 September 2026 (UTC)
IIRC I can implement it to be an option for move-protect only. msk 02:06, 26 September 2026 (UTC)
Er, are you sure? The array in wgRestrictionLevels (which controls the protection options) is 'enwiki' => [ '', 'autoconfirmed', 'extendedconfirmed', 'templateeditor', 'sysop' ], so unless you have another location for more fine-grained tuning in mind, I don't think it can be technically restricted from being used as an edit protection level (nor do I think we really need to, I think we can just trust that admins wouldn't use it for something it's not designed for). EggRoll97 (talk) 05:40, 26 September 2026 (UTC)
Nope, you're right. Sorry about that. msk 14:13, 26 September 2026 (UTC)
Support. Page movers can be trusted to move the mine run of move-protected pages (in mainspace at least), so I'd be on board with downgrading a large number of protections if this is successful. Expectations like "don't use for edit protection" can be documented in a new section at Wikipedia:Protection policy. Extraordinary Writ (talk) 05:56, 26 September 2026 (UTC)
I accept that this proposal wouldn't save time on net, but I still think it's important just as a matter of principle to apply the least restrictive level of protection necessary and only take things away from non-admins as a last resort. That's probably an unorthodox position, though. Extraordinary Writ (talk) 01:44, 21 October 2026 (UTC)
@Extraordinary Writ: Adding a new protection level above extended confirmed is likely to make page moves more restricted for the broader community, not less. The typical long-term editor's most advanced group is extended confirmed. The better solution is to reduce the frequency of full move protection. Daniel Quinlan (talk) 01:59, 21 October 2026 (UTC)
Adding a new protection level above extended confirmed is likely to make page moves more restricted for the broader community, not less.
So your argument is that, if we add mover-protection, admins applying move protection would disregard our policies and use mover-protection even where, at most, only ECP move protection would be allowed? FaviFake (talk) 15:55, 21 October 2026 (UTC)
ECP move protection is non-standard; see Wugapodes' comment. msk 16:27, 21 October 2026 (UTC)
Then IAR applies. If an article can't remain confirmed-move-protected but doesn't need to be admin protected, use ECP. For example, the current TWAFI has been EC-move-protected for a week due to the relatively minor potential for disruption. FaviFake (talk) 18:21, 21 October 2026 (UTC)
No, I just think it's inevitable. How it happens will likely be reflected in policies and guidelines. Daniel Quinlan (talk) 16:56, 21 October 2026 (UTC)
If I understand correctly, the argument is something like this: Right now there is only ECP and the far more drastic admin-only move protection. There is some number of pages where maybe ECP isn't quite doing the trick but the currently available next level feels too extreme. Some, many, perhaps the vast majority of these remain at ECP. If we introduce this intermediate protection level, it will be more palatable to increase the protection on more and more pages without having to go all the way to admin-only move protection. Over time, the total number of pages that have a move protection level higher than EC will be potentially much greater than it is today. A downstream effect will be that requests to increase or decrease between the different levels will increase. —Myceteae🍄‍🟫 (talk) 18:21, 21 October 2026 (UTC)
Why would it be more palatable to increase the protection on more and more pages? To whom would it be more palatable? If a non-admin thinks ECP is not enough, they'll go to RfPP regardless of whether there is another available intermediary protection type.
If an admin lands on an article and they think ECP is not enough, they'll simply apply mover-protection and move on. I don't see the issue here. FaviFake (talk) 18:25, 21 October 2026 (UTC)
I'm not making this argument but my understanding is that admins sometimes encounter pages where ECP might be too loose but admin-only might be too restrictive. Some portion of these, perhaps the majority, remain at ECP. If they had another intermediate option available, they would use it. I'm not an admin and rarely have requested or participated in discussions about page protection. I don't have any sense of what the potential impact would be. —Myceteae🍄‍🟫 (talk) 18:52, 21 October 2026 (UTC)
I think it was said elsewhere in this discussion that ECP is not applied for moving without it being applied for the whole article, even though it can technically be done, because there's no guidance as to when it would be allowed. –Maltazarian ᚾparleyinvestigateᛅ 18:56, 21 October 2026 (UTC)
Ah, maybe that was more the issue. —Myceteae🍄‍🟫 (talk) 19:00, 21 October 2026 (UTC)
At the very minimum, at least one of ECP or page mover should be a valid move protection level. Skarmory (talk • contribs) 19:05, 21 October 2026 (UTC)
Note: Wikipedia talk:Page mover has been notified of this discussion. Axolitl (talk | contribs) 05:20, 27 September 2026 (UTC)
Support I think this could provide a good middle ground allowing for a smoother process. For pages where just EXCON is barely not enough to protect them from bad moves there's not really a reason to directly limit it to sysop and if a page mover abuses their rights to move such a page, imo they should and would loose their right immediately... squawk7700 (talk) 10:05, 27 September 2026 (UTC)
Oppose Looking back through Wikipedia:Requested moves/Technical requests#Administrator needed during 2026, I see only 49 requests. Some of these wouldn't be helped by this new protection level, for example this one that needed an admin to delete a conflicting redirect. This doesn't seem like it's enough of a problem to require a whole new protection level. Anomie⚔ 13:08, 27 September 2026 (UTC)
I would expect if this would implement we would be somewhat more free with protecting things at this level, so the current rate of requests is a lower bound but the upper bound is much higher. My personal opinion is that we should generally be much more free with move protections on potentially contentious or high-visibility topics, since unlike edits those should very rarely be done without consensus anyway. Rusalkii (talk) 23:54, 27 September 2026 (UTC)
I'm not sure that more protection would really happen, or that if it did that it would be a good thing. Meanwhile, that "lower bound" is very low. Anomie⚔ 00:48, 28 September 2026 (UTC)
Why not? We have an absurd number of bureaucrats, even though they mostly do nothing with those powers. Cheers, In solidarityUser:Wikipedian12512(alt) (Talking is fine | contribs) 14:57, 28 September 2026 (UTC)
It clutters the configuration and the protection interface. The comparison with the number 'crats is not a good one, since more or fewer people in that list doesn't affect anything else. Anomie⚔ 23:11, 28 September 2026 (UTC)
Support, per my comment above. I participated in at least one of the discord discussions on this topic, but I saw this RfC through CENT and expect I would have ended up here regardless. — Preceding unsigned comment added by Rusalkii (talk • contribs) 16:57, 27 September 2026 (UTC)
Just a note that this isn't an RfC, although one may come in the future. Axolitl (talk | contribs) 03:29, 28 September 2026 (UTC)
Support – Page movers are usually trusted. This is the same as fully protecting templates before the template-protection level was created (just at a smaller but still significant scale). FaviFake (talk) 00:03, 28 September 2026 (UTC)
Support have thought similar before, especially with how long such TRs can sit unattended to, ie 24-48 hours unnecessarily. Sometimes it feels like RM closes are undergoing an admin review rather than the move request itself (or that's how it's felt personally), so the additional delays aren't appreciated from a closing perspective either, especially when it only needs brief oversight from another page mover. Per above if page movers can't be trusted to move pages that are extendedmove protected then they should have rights revoked. CNCin solidarity (talk) 06:10, 28 September 2026 (UTC)
Support – Page movers should be able to move pages. Being trusted to do so responsibly is the whole point of the user right.
I have on multiple occasions expressed my frustration both on- and off-wiki (although not actually in the discussion that led to this RfC, which I was pleasantly surprised to see in WP:CENTRAL) about being a page mover yet being unable to move pages. It is a regular source of additional work and annoyance (especially for more complicated closes) for page movers closing RMs and the admins who have to stand-in to carry out the moves. On multiple occasions I've had to spend time explaining to editors asking me why the pages haven't been moved that yes, the closing template has a field that explicitly states that a non-admin page mover performed the close, but no, that page mover cannot move the page. Yes, it is relatively rare, but the additional work adds up and there is no good reason for it to be happening at all.
We are trusted with the ability to override the title blacklist, create and edit page edit notices and redlink almost anything by moving without leaving a redirect (and some other stuff), but somehow not trusted to do normal moves for pages that some other editors have been improperly moving. If someone cannot be trusted to deal with the ability to move pages that are move protected they should not be trusted to do any of these other things. –Maltazarian ᚾparleyinvestigateᛅ 16:33, 28 September 2026 (UTC)
Just going to note that many (but not all) of the arguments along the lines of there being no need do not really argue why it would be a negative, and that the concerns about it being too much work are ignoring that msk offered to do it (and for the record, they are more than capable of doing so) which makes it a very low cost for the community-at-large (unless we want to insist msk would otherwise be obligated to spend that time working elsewhere on the wiki). –Maltazarian ᚾparleyinvestigateᛅ 08:50, 23 October 2026 (UTC)
Personally, I'm seeing the opposite: a lot of the support votes focus on "page movers can be trusted to move pages" without considering whether there's enough of a need to balance the increases in complexity in interfaces and processes that result from adding another protection level. Anomie⚔ 11:54, 23 October 2026 (UTC)
There isn't much to say about that. If we want pages to be protected more precisely, then we need to add a new level, which should be used and requested if needed. The benefits of adding one more option in the drop-down are greater than leaving pages with an undue move-protection level. FaviFake (talk) 11:59, 23 October 2026 (UTC)
Most of the discussion here doesn't seem to be about protecting pages "more precisely" in the first place. It's about page movers being unable to handle the RM in the relatively rare cases where a fully-move-protected page needs moving, but without evidence this is leading to any sort of a backlog or unreasonable delay. Anomie⚔ 12:06, 23 October 2026 (UTC)
That's just a direct consequence of the fact that admins are currently forced to use full move protection in cases where ECP is not sufficient. FaviFake (talk) 12:11, 23 October 2026 (UTC)
What is? That most of the discussion isn't about what you claim, or that there's no backlog? Either way, I don't see how it supports your point. Anomie⚔ 22:49, 23 October 2026 (UTC)
Not sure if I've said this elsewhere in the discussion, but I do definitely think there are benefits to having this level around; I would think it would be a better level to use for cases of page move vandalism or move warring than full move protection when ECP isn't sufficient. Skarmory (talk • contribs) 13:50, 23 October 2026 (UTC)
I think that is actually a principled stance to have though. We strive to be an encyclopedia that anybody can edit, and we only put limits on that when it would be infeasible/unreasonable to not do so, not just for the sake of convenience, and we try our best to limit it only to the extent required to prevent disruption. Being supportive of a proposal to let editors one views as trusted to make certain edits be able to make those edits is in line with that. –Maltazarian ᚾparleyinvestigateᛅ 13:20, 25 October 2026 (UTC)
Comment how frequently do pages get fully move-protected because XC move-protection isn't sufficient, where the reason isn't a move war (for which full protection should continue to be used should this protection level be created) and why? Snowmanonahoe (talk · contribs · typos) 18:41, 28 September 2026 (UTC)
I had a similar question. I'm a fairly new page mover and I've actually not encountered this barrier yet although I am aware of the issue. My understanding is that the practical effect of this change would be primrarily to allow page movers to carry out RM closures for pages that fall under the first two bullets at WP:MOVEP (pages prone to vandalism and frequent page-move disputes). The purpose of page protection in these cases is to force a formal RM discussion, and page movers are entrusted to close and carry out complex and contentions RMs. I would think that the third MOVEP bullet (high visibility pages like WP:AN and Today's featured article) could maintain a higher, admin-only protection level. The discussion above highlights another category, templates and other complex pages where moving may break other parts of the site (although it's not clear if the templates discussed above were move-protected at the time or if the protection level was sufficient). —Myceteae🍄‍🟫 (talk) 18:53, 28 September 2026 (UTC)
Just to provide some context, the current list of fully-move-protected pages is at , and while I don't have a hard number for you, there is page after page of this. Anything from arbitration enforcement, to vandalism, to sockpuppetry, you name it for the reasons. As for where the reason isn't a move war, I would actually say page-mover-protection should be the default for move wars if created, as the main idea of the page mover group is that it is experienced and trusted users who regularly move pages and demonstrate familiarity with Wikipedia's policies and guidelines regarding page moving and naming, which is a quote directly from the page mover policy. EggRoll97 (talk) 04:35, 29 September 2026 (UTC)
Weak oppose I like the idea, but I'm convinced by Anomie and BilledMammal that the demand isn't really there. Especially if it does in fact require a patch to MediaWiki core, which we seem to be unclear on(...?)
This RfC looks like it's going to pass, so one thing I will say is that this action should be treated with a certain gravitas like we do with redirect suppression and template editor. The protection policy should say that a page mover should in most circumstances only move a move-protected page when implementing their close of an RM. Snowmanonahoe (talk · contribs · typos) 05:47, 29 September 2026 (UTC)
Agreed that moving through move protection should not be done lightly and should mostly be used for implementing results of consensus discussions. Skarmory (talk • contribs) 02:07, 30 September 2026 (UTC)
I mean yeah, I fully expect of all page movers to understand that move protection is generally a very clear indicator that a move will be controversial and thus require an RM. –Maltazarian ᚾparleyinvestigateᛅ 02:49, 30 September 2026 (UTC)
Support convinced by Extraordinary Writ's second comment above. Snowmanonahoe (talk · contribs · typos) 01:50, 21 October 2026 (UTC)
Hey @Sohom Datta, is there a reason you made this an RfC? AFAIK, the template shouldn't be added retroactively. It makes the old !votes a bit more confusing in context. Axolitl (talk | contribs) 00:52, 29 September 2026 (UTC)
It was on WP:CENT, and we were already !voting in the RFC style, so I assumed this was intended to be a RFC and the RFC tag just hadn't been applied. (No concerns from my end if there is consensus to not make this a RFC) Sohom (talk) 03:31, 29 September 2026 (UTC)
That's fine, though should we rephrase the opening statement, so it stays neutral? Axolitl (talk | contribs) 04:07, 29 September 2026 (UTC)
Pinging @MSK for their thoughts on this, as they were the one who started this discussion. - BlueEleephant (talk · contribs) 02:02, 30 September 2026 (UTC)
I did rephrase it as Should a new move protection level be created, which only allows page movers and administrators to move it? I tried to keep the intent of the original, while maintaining neutrality. Axolitl (talk | contribs) 02:11, 30 September 2026 (UTC)
Note that the "it" should have probably been "the page", but it's kind of too late now. Axolitl (talk | contribs) 02:11, 30 September 2026 (UTC)
I think the intended meaning is clear in this discussion. —Myceteae🍄‍🟫 (talk) 16:16, 30 September 2026 (UTC)
@Daniel Quinlan and Wugapodes: You both hit the nail on the head. Re-reading your comments above made me realize something—this proposal would really just result in a quasi-unbundling of the sysop toolset. However, the framing avoids the traditional ire drawn from true technical unbundling proposals! Convolution should always be avoided; if page movers are so trusted in actuality, then they should be granted the ability to move fully-protected pages. It certainly should not be done in this manner which suffers from all the cruxes which you both so aptly point out. — Godsy (TALKCONT) 04:01, 25 October 2026 (UTC)
Very good point. While I still support the proposal in absence of an alternative, a better direction would be similar to the intended purpose of NPR and PMR. In the same vein that NPR was "unbundled" from the admin tool set, and we now have more non-admin reviewers than admins with full permissions to review pages, PMR should realistically also include permissions for move-protected pages, based on the assessed trust of those who have page mover permissions. In response to Wugapodes however, Page movers who can be trusted with sysop-protected pages should apply for the existing sysop permission [...], I strongly disagree. Most page movers appear to have no interest or demonstrated need for sysop permissions, because their focus is on moving pages, not everything else that comes with the mop and bucket. On this note I'd prefer to see further unbundling of sysop toolkit, such as WP:Page deleter, WP:Page protector, etc, for those who prefer to stick to particular areas of the 'pedia. Moreover, the benefits of further unbundling would be worth the time and effort, like it has been for NPR and PMR already, while I can see the drawbacks of a new protection level. Overall for every permission granted, it can translate to dozens if not thousands of admin-like actions that otherwise wouldn't have occurred. I can't imagine where the project would be without NPR/PMR to be honest, especially given how backlogged NPP usually is on a good month. Also if editors want more admins then the best strategy for that is to create more stepping stones in order to reduce the hurdle of RFA/AELECT. Whereas recommending page movers apply for sysop rights, simply in order to move protected pages, is well intended but thoroughly unrealistic. CNCin solidarity (talk) 09:44, 25 October 2026 (UTC)
I would also like to note that move protection is hardly being applied to mainspace pages because only sysops can be trusted to move them, it's done because there is no other alternative. –Maltazarian ᚾparleyinvestigateᛅ 13:10, 25 October 2026 (UTC)
Moving full protected pages is a demonstrated need, and page movers are great admin candidates. Page movers have been trusted with limited delete permissions since 2021. They also show demonstrated experience in reviewing contentious discussions for consensus and can follow admin-level policy documents well. If a page mover only uses the tools to move pages we're better for it, and if they use the rest of the kit to improve the encyclopedia, even better. The tools are a way to serve your corner of the encyclopedia, not leave it.
That said, I don't think generally unbundling the core block-protect-delete tools is a good idea either. Dealing with disruption requires all three in your toolbox. For example, socks should usually be range blocked as a first resort rather than have the page protected and revision deletion can be important for cleaning up afterward. If we give some people block and some people protect and some people delete, then at best we will still need to wait for someone with the proper tools and at worst we will use the wrong tool for the job. Personally, I think one of our biggest AntiPatterns is that we spend hundreds of person-hours debating new permissions, coding new permissions, writing policies for permissions, processing requests for permissions, and monitoring use of permissions so that our most responsible editors can build an inferior toolkit request by request. At a certain point we need to kindly but firmly say, if someone wants to serve the community with further tools they need to stop making work for others and just get the whole toolbox. — Wug·a·po·des 02:39, 26 October 2026 (UTC)
@Wugapodes: I agree. Just want to clarify that while I think granting page movers the ability to move fully-protected pages is a better idea than what is being proposed here, it still is not something I would support. — Godsy (TALKCONT) 02:54, 26 October 2026 (UTC)
Do you think someone would pass RFA or AELECT if the only reason they are running is to supplement their ability to move pages? I suspect at best, it would be a very hard sell. Skarmory (talk • contribs) 02:56, 26 October 2026 (UTC)
Probably not, but most extended movers work in multiple areas, and the most trusted ones would benefit from the additional permissions that are entrusted to sysops. Daniel Quinlan (talk) 03:04, 26 October 2026 (UTC)
"I want to move pages and I might help with other stuff" was my answer to Q1 and it worked fine. — Wug·a·po·des 03:26, 26 October 2026 (UTC)

Discussion (mover protection)

Name

(Starting a separate section for this.) If this was implemented, what would it be called? Would it be called "move protection", and the sysop protection called something like "full move protection"? Or would it possibly be a level-2/level-2 thing? Input would be appreciated, especially if this became an RfC or something. Axolitl (talk | contribs) 22:20, 26 September 2026 (UTC)

Since page mover is already called extendedmover it would go that this would be called extendedmove technically; we can rename sysop move protection to you your suggestion, or just deprecate standalone "sysop move protection" as a concept entirely (we don't call fully protected pages "move protected") msk 22:28, 26 September 2026 (UTC)
"Mover-protected"? "Page mover–protected"? "Intermediate move protection"? FaviFake (talk) 00:05, 28 September 2026 (UTC)
I would probably name the sysop level full move protection and let this one be move protection. Skarmory (talk • contribs) 23:29, 28 September 2026 (UTC)
Surely "Move protection" and "Full move protection" are the simplest options here. –Maltazarian ᚾparleyinvestigateᛅ 05:12, 29 September 2026 (UTC)
@Maltazarian Skarmory "Move protection" usually refers to pages that can only be moved by extended-confirmed users. See {{Protection table}}. FaviFake (talk) 07:24, 29 September 2026 (UTC)
I feel like common usage is already for "move protection" to refer to the green lock. Like, sure, technically an ECP page is move protected at an ECP level, but I can't recall hearing anybody talk about it that way.
I'd suggest "extended move protection" as msk did, but then we're causing confusion due to EC not having anything to do with it.
Idk this part isn't all that important to me anyway. –Maltazarian ᚾparleyinvestigateᛅ 08:24, 29 September 2026 (UTC)
Yeah it's tricky. For now my preference is for "mover protection"; pages will be "mover-protected" FaviFake (talk) 08:28, 29 September 2026 (UTC)

Impact

Looking at the past month of requests at WP:RMTR, I see just seven:

  1. Template:Abbr to Template:Abbreviation
  2. Lion-man to Lion-man of Hohlenstein-Stadel
  3. Pakistani missile research and development program to Pakistani missile research and development programme
  4. MV Höegh Osaka to Höegh Osaka
  5. Template:RFPP to Template:Requests for page protection
  6. Palm Beach International Airport to President Donald J. Trump International Airport

The seventh I cant list. Overall, maybe there will be one hundred moves per year that will be done by page movers instead of admins; I'm not convinced that this labor saving is worth the cost in development time. (I'll add support for RMTR into Move+ some time, which should reduce the labor cost further - I'll also in the nearer future change RM to say whether it is listing a move in the admin section or the standard section, to make it easier to review this in the future) BilledMammal (talk) 03:52, 29 September 2026 (UTC)

I wonder how many times per month template-protected pages are edited by template editors, as a point of comparison. Snowmanonahoe (talk · contribs · typos) 05:14, 29 September 2026 (UTC)
Moves of move protected pages, and edits of template edit protected pages, by month for the past three years:
MonthMovesEdits
September 2026242781
August 2026403540
July 2026313685
June 2026303260
May 2026212950
April 2026323315
March 2026713205
February 2026482748
January 2026473288
December 2025873197
November 2025313285
October 2025134094
September 2025373439
August 2025303975
July 2025543057
June 2025382867
May 2025413453
April 2025282575
March 2025323125
February 2025413108
January 2025773865
December 2024233051
November 2024402873
October 2024223430
September 2024453065
August 20241013112
July 2024653105
June 2024262834
May 2024612946
April 2024352860
March 2024433442
February 2024133257
January 2024293304
December 2023303196
November 2023162707
October 2023363149
BilledMammal (talk) 05:32, 29 September 2026 (UTC)
Updated the table. The earlier one was moves of all move-protected pages, included extended-move protected. This one is still a bit of an estimate, as it assumes that if a page is protected now it was protected when the move occurred, so it can miss some moves where protected lapsed or was removed, and counts moves of pages later protected. For example, six moves from March are of Epstein files, none of which was done while the page was protected. BilledMammal (talk) 05:56, 29 September 2026 (UTC)
How hard to we really expect it to be to implement? Anyone got an idea? Also Move+ already has RM/TR capabilities last I checked. Did the recent update get rid of them? –Maltazarian ᚾparleyinvestigateᛅ 05:15, 29 September 2026 (UTC)
Move+ lists moves at RMTR, it's never supported (outside of a prototype I wrote two years ago) implementing the moves at RMTR. BilledMammal (talk) 05:19, 29 September 2026 (UTC)
Ah, I see. My misunderstanding. –Maltazarian ᚾparleyinvestigateᛅ 05:20, 29 September 2026 (UTC)
50 to 100 moves per year adds up over time, and this project is already over 25 years old. Meanwhile, we have someone volunteering to make the patch, who also happens to be the person who started this discussion, so that cuts down on the needed development time. This doesn't even account for other possibilities for how the protection level could be used; notably, I agree with EggRoll97 above that this would make sense as the standard for protection in case of move wars. Skarmory (talk • contribs) 05:16, 29 September 2026 (UTC)

Sourcing tools preceding / following AfD nominations

Hi everyone. We're all aware that one of the key issues driving nominations at AfD is a lack of proper sourcing on proposed articles. People aren't wrong that it's unlikely many of these pages will be worked on for a long while, which may lead to some resentment of Keep voters willing to salvage an article on notability grounds, but not to help improve the article thereafter.

With that in mind, I'm curious if we might benefit from something akin to the editing interface Refideas notice, at least for some time after an AfD nomination on sourcing grounds, to indicate to editors that come across the page that there are in fact sources available that were raised in the discussion to support what is otherwise unclear notability. Obviously this could be done just as well using Refideas, but doing so is functionally more difficult and not always possible given template restrictions. I'm curious what others have to say. CSGinger14 (talk) 21:53, 14 October 2026 (UTC)

People aren't wrong that it's unlikely many of these pages will be worked on for a long while, which may lead to some resentment of Keep voters willing to salvage an article on notability grounds, but not to help improve the article thereafter.
I would say any such resentment or... really anything would be invalid and silly. AFD is notability gauntlet broadly when deleting is up as a question. If WP:GNG is proven, or one of the sideways Notability gauntlets that are black and white objective ("You pass GNG if you have earned X, Y or Z"), then any Admin honestly doing anything but Keep is being wrong or acting on emotion versus policy.
The best long term solution would be to something that imports all the URLs/sources at least to the talk page in a non-archive bot eligible section up top. Articles can be stubs. Stubs are fine. Something could trivially pass WP:GNG and be a stub for 20 years. That's fine too.
Look at Amrom Harry Katz and how I found it here at this version: https://en.wikipedia.org/w/index.php?title=Amrom_Harry_Katz&oldid=1240112565
If that was sent to AFD back a year or three ago, it's very possible it dies as an article and I do not find it. It took me substantial effort to dig out and find a lot of that sourcing. Our biggest AFD cultural fuck up is simply not having something trawl AfDs for sources that are not mentioned on the page, on prior versions, on talk/talk archives, on AfD and so on.
Honestly, this could be something for a bot. Have it simply API call up every revision ever of an article at AfD or on demand. It scours all the versions of the page and talk, talk archives and AFDs. Any URLs or anything that's obviously a source (if no URL) is scooped up and put somewhere in a list like Article name/sources or something that's linked off talk. Every time it is reran, the sources list can grow. We'd have a permanent record of every reference ever put forth for a given article? The best thing is then each source could over time as needed develop on such a page it's own Perennial Sources-like history of review over time. Perfect space to permanent record quibble over sources, and then if 10 years someone new says "What about X source?" and we can simply say, "Read this section first". — VPP (t/c) 22:12, 14 October 2026 (UTC)
Having worked in politics, I can assure you that regardless of whether they are invalid and silly, sentiments remain, and play a fundamental role in shaping the community dynamic; it's clear in such cases that it's necessary to find middle grounds that preserve existing policy norms while nonetheless addressing the concerns raised by those angry with the way in which the system currently operates, on either side.
What this is meant to say is that we have a community here that necessarily exists within it's context. Denying that obscures the fundamental problem that we need to address, that there are serious conflicting opinions impacting relations between users, because there don't seem to be proper mechanisms to elevate and address the concerns of both parties in tandem with one another. That's what Consensus/3O/DRR are intended to address, but all of them seem to end up being a zero-sum game in some way or another, which only fuels further resentment on the losing side. I think there's a lot more that needs to be done on this front to reconcile that fact, but I suspect this might be a good, simple place to start.
CSGinger14 (talk) 23:07, 14 October 2026 (UTC)
That is a lot of information.
I was just tossing out an idea I had been noodling with in my head a bit, for a semi-automated way to warehouse all sources for a given article, so no one has to waste time redoing others work. Kind of related to this. But simply, a bot-like tool that will read out all relevant history of a given article and it's talk, and extract every https URL that ever was saved to article or talk (as a starting function). Then the user can dump it as a list on talk, or something like that template idea I'd had. — VPP (t/c) 23:49, 14 October 2026 (UTC)
An list is a good idea. It would need to be easily annotatable, both with objective and subjective comments (e.g. marking dead, doesn't verify anything, paywalled, in-depth, etc) and have an explicit note that not every source needs to be relevant to notability (e.g. a source verifying a subject's birthdate is important but irrelevant to notability). Thryduulf (talk) 10:08, 15 October 2026 (UTC)
Well, I wasn't thinking any of those should or would be scripted. Way more lo-fi; a set tool that you give it an article name. It then proceeds to trawl EVERY revision (in a smart way, deduplicate, limit API costs, etc.) to make a list of every URL ever that showed up in a page edit or talk edit or in redirects to it, related AFDs, etc. Dedupe that, sort A-z off https://whatever and then the tool writes that to your user space, like User:Very Polite Person/url-dumps/The Page You Checked_all_URLs. You get some metrics like when it was pulled, then just literally a link of the sorted URLs, and the diff/edit where (best effort) it was first introduced in the context of The Page You Checked. Then the editor has to do the remedial work or simply move page to The Page You Checked/The Page You Checked_all_URLs and make it a team effort. Each article gets it's own little Perennial Sources.
How to update around iterative cycles/runs, I hadn't thought of. Notes on each source should probably go on talk, so it's easy to update the list over time without worrying about overwriting comments or customization. Like if either the User or Article version exists, check there first. You only need to check diffs/edits AFTER where you last checked (gets faster over time) to find new stuff.
Anyway, something like that as an idea. Some 20 year old article... go to tools server, like how Citation Bot works. Toss in the article, some time later you get a nice sub page catalog of URLs and talk page note saying it's ready. — VPP (t/c) 18:03, 15 October 2026 (UTC)
I think a bot which extracted as many URLs from the article, its talk page, their histories and any corresponding AfDs, de-duping them and formatting them as either a plain bulleted list or something that could be cut'n'pasted into {{Refideas}} - would be very useful for future editors looking to improve or expand the article. It would be a good minimum viable product for something with more bells and whistles (iterative runs, offline sources, corresponding articles on other wikis, richer formats e.g. populated CS1/CS2 templates etc.). Cheers, SunloungerFrog (talk) 09:56, 21 October 2026 (UTC)
I started messing with it on the side already and seems to work ok. — VPP (t/c) 15:33, 21 October 2026 (UTC)
When all the PHP-patching shenanigans are done and PetScan is back up, for some live targets you could look at petscan:39840057, which is all unreferenced articles that survived AfDs. Cheers, SunloungerFrog (talk) 15:42, 21 October 2026 (UTC)
The resentment is real and goes both ways. I've personally seen both of these results:
  • The nom is mad because the AFD participant didn't put the sources in the article ("If you wanted to keep this article, why are you making WP:NOEFFORT to improve it?").
  • The AFD participant is mad because the nom didn't put the sources in the article ("I just handed you multiple sources on a silver platter. Anyone who isn't a deletionist troll would have copy/pasted them in the article themselves instead of moaning about how nobody else did it for you").
WhatamIdoing (talk) 22:09, 16 October 2026 (UTC)
@WhatamIdoing You’re quite right, which leaves me curious as to whether it might be better to create an outlet (of the sort that I described in my last edit (name change)) to which nominators concerned principally with improving sourcing can turn without having to start a cage match in order to do it.
Half the time these discussions seem to devolve into violent battles over policy interpretations, when the nom just wants to see some fundamental improvements to the reliability of referencing on the page. It seems as though half of those where the sourcing can be found just end up being a waste of everybody’s time (and end in keep regardless), which undermines efforts to bring much needed attention to the other half, where it’s far more necessary for those policy interpretations to be considered.
Always glad to see your name pop up in discussion,
Best,
CSGinger14 (talk) 06:15, 17 October 2026 (UTC)
I'm not hopeful. The problem is fundamentally that "I" want things to be a certain way, but "I" don't want to (or don't have the skills to) do it myself. So "my" options are:
  • I can add a maintenance tag, such as {{More citations needed}}. The median article has been in Category:Articles needing additional references for over five years. Category:Articles with unsourced statements has a four-year median. Of course, many tags get added and addressed right away, especially in high-traffic articles, but the tag may languish there for years. Also – and I think this is important in terms of speaking to the motivation of the editor – unless you are watching every edit to the article, or unless someone actually reverts your tag, you probably won't notice if the problem gets addressed. So this feels a bit like screaming into the void.
  • I can blank individual bits of uncited content. Problem: It can be difficult to do that without making the article worse. Problem: People will sometimes yell at you. Problem: If you do a lot of this, people will hate you. Problem: If you don't know all the little unwritten rules, and you don't have any social capital, you'll get blocked. After all, we flag section blanking so we can revert vandals, and not so we can thank editors for removing encyclopedic content that needs a citation added. And none of these actually solve my (perceived) problem, which is the absence of a little blue clicky number at GA- or FA-level of density. (I just had a prolific AFD nom tell me today that "all content requires citations".)
  • I can send the article to AFD. Problem: People will sometimes yell at you. But you get BIG rewards, and relatively immediate ones, too: People will often drop their current (and possibly more important) activities to give you lots and lots of attention right now, and some part of that attention will frequently be fixing up the article, so you have done a doubleplus good thing by finding a sneaky way to manipulate other WP:VOLUNTEERS into doing something that you couldn't or wouldn't do yourself, and you can see it happening on a predictable schedule. Of course, there are limits, but it usually doesn't reach that point, and it's usually a WP:TBAN rather than a block, and as long as you've only got a couple of noms active at any point in time, it's usually after years of getting what you want.
The rewards for misusing the AFD system. Until it stops being rewarding, the AFD system will keep getting misused. WhatamIdoing (talk) 06:51, 18 October 2026 (UTC)
Then I think that's the fundamental question we need to answer, either:
  1. How do we stop misuse of the AFD system from being rewarding; or
  2. How do we create an expectation that the objective purposes for which AfD is misused should/must be raised elsewhere in advance of a nomination?
The second question I consider to be more easily answered. I've been cooking something up but I'd want to know that it wouldn't just die here after a week before I considered putting real flesh on it.
Best,
CSGinger14 (talk) 07:47, 18 October 2026 (UTC)
If a source comes up that is really good but is not used on the article, consider adding it directly to an article as WP:Further reading or as an WP:EL. There, an entry indicates to editors and readers that more sources are available. (WP:EL does say "If the website or page to which you want to link includes information that is not yet a part of the article, consider using it as a source for the article, and citing it", but this discussion is presuming that we are stuck in the state before that. Call being stuck in that state one of the "other reasons".) CMD (talk) 02:52, 16 October 2026 (UTC)
@Chipmunkdavis Though I agree with you that it's a preferable option (particularly in advance of AfD), I don't think that instruction extends far beyond the bounds of this conversation, unless we sought to proselytize. Even still, uninvolved editors may simply ignore them, EL in particular, given that such sections are often devoted to platforms relevant to the given subject, but not qualifiable as a source in and of themselves. Part of why I felt that it would be beneficial to have a notice for these references similar to how Refideas is implemented was because it would highlight sourcing for which a consensus has necessarily been reached to indicate that they're reliable secondary coverage, which might help to guide newer editors unfamiliar with site expectations, and in turn lessen the chance that they have their first edit(s) erased as a custom/rule.
The proposal operates under the assumption that editors involved in AfD discussions will broadly not engage with the improvement of nominated articles upon their rescue. Perhaps that's misconstrued, but though it obviously doesn't account for all cases, the vast majority of those occur when someone from the ARS (or someone who shares its ideals) tidies up the article amid the fray, rather than sticking around to perform grunt work thereafter.
Though I'll admit that this is aimed at promoting inclusion, how I hope to do so is by reducing the extent to which editors feel that AfD needs to be used as an instrument for cleanup. Perhaps it would do the exact opposite (i.e encouraging editors to nominate more pages indiscriminately in the hopes of getting a few sources attached after the fact), but that's precisely what I'd hoped we could come to some understanding about through this discussion. Maybe some fusion of the point raised by VPP, in tandem with a shifted expectation that a challenge to the article's notability should first be raised at its talk, prior to / rather than immediately bringing it to AfD (talk discussions wherein/whereafter a system similar to the one I described above could also be implemented).
Best, and thanks for your engagement,
CSGinger14 (talk) 06:22, 16 October 2026 (UTC)
We already have a problem with editors sending articles to AFD in the hope of forcing everyone else to drop their current projects, some of which is significantly more important than whether Chris Celebrity gets fixed up during the next week. WhatamIdoing (talk) 22:21, 16 October 2026 (UTC)
Yes, there are a few editors who openly admit they use AfD to "enforce" the WP:V policy. Katzrockso (talk) 01:16, 18 October 2026 (UTC)
That is so weird. What does that look like? Just to be nasty and strong arm people into editing? — VPP (t/c) 02:43, 18 October 2026 (UTC)
"Nice little article you've got there. Shame if anything'd happen to it..." WhatamIdoing (talk) 06:53, 18 October 2026 (UTC)
That deplorable 'custom' I'm familiar with. — VPP (t/c) 07:29, 18 October 2026 (UTC)
We had a similar problem with portals in 2019. After a proposal to remove the namespace was rejected, a now-banned editor nominated them for MfD at rates of up to 100 per week and succeeded in getting most portals deleted. Certes (talk) 21:17, 19 October 2026 (UTC)
I tried to click that blue text and wondered why my cursor didn't become a hand. 海盐沙冰 / aka irisChronomia / Talk / Uploads 06:38, 22 October 2026 (UTC)
@CSGinger14 I think you're being generous. I find a lot of nominators don't do due diligence searches. Even where they do, it's often limited. And when two sig cov sources are found, some nominators (and previous delete voters) won't withdraw their objections. The problem with PROD is it relies on someone objecting. If the creator is no longer an active editor, the page has less chance of uplift/survival. The issue with AfD is that, instead of the closer/AfC reviewer determining if the article now means notability requirements, it's essentially a vote (even if we say it isn't). So a page can be subjectively deleted or saved. I'm happy to support your proposal but I don't think it goes far enough. I think we need one of two AfD circuit breakers:
  • if you AfD an article, the discussion doesn't not start immediately, the article is templated for 7 days. You are obliged to reconsider your nomination if two sig cov IRS sources exist/are added in that time or it can be 3O'd if rescuer thinks the nominator is being unreasonable.
  • if two sig cov IRS sources are added during the discussion, the previous delete votes get less weight or are thrown out
But honestly, I'd like to see an investigations process for bulk nominators where there is suspected bias/abuse. Mme Maigret (talk) 00:22, 27 October 2026 (UTC)

Edit summary reminder on by default?

New users often get reverted because they don't explain what they are doing. Often vandalism, but at times they have a good reason to remove text. The problem is they don't tell us. Should we ask the WMF to turn the "remind me when I forget an edit summary" on by default for new editors? Or at least test it? In solidarity, —Femke (talk) 🐦 19:42, 18 October 2026 (UTC)

I think that would be a good thing to trial. The only potential downside I can see is more misleading or irrelevant edit summaries, in good or bad faith, as not everyone understands what an edit summary is for (e.g. I've seen at least two in the past few days where people left their email address in the edit summary), and that might be harder to detect than an empty summary (I don't know), but overall my gut feeling is that it would be a net positive. Thryduulf (talk) 19:47, 18 October 2026 (UTC)
That sounds like a good idea, I've encountered it in other wmf wikis. The error message should only ask for a brief summary, to avoid burdening new users. FaviFake (talk) 12:58, 19 October 2026 (UTC)
Only time will tell how that will turn out. But, the idea is interesting in that a clever bot could add "obvious" edit summaries and ask for user confirmation. An obvious example would be typo corrections. I would like that for my own edits, given that I don't like to do obvious edit summaries. Another example is reference addition or cn tag addition etc. This does not have to be real time and will involve no LLMS. This would be more useful than reverse-genius projects like abstract Wiki, etc. Yesterday, all my dreams... (talk) 14:59, 19 October 2026 (UTC)
You can enable it for yourself right now by going to Special:Preferences#mw-prefsection-gadgets and selecting the corresponding option. FaviFake (talk) 15:02, 19 October 2026 (UTC)
Sorry, that is the last thing I would want to turn on. If it automatically suggests "reference added" as the summary and I just click ok, I would like that. Yesterday, all my dreams... (talk) 15:07, 19 October 2026 (UTC)
It doesn't, but there are other scripts at WP:USL that allow you to save pre-set edit summaries. I prefer to use a text expander app like aText. For example, I could set it up so that when I type "zref", it immediately turns into "reference added". I have hundreds of these, ranging from small templates to entire paragraphs. FaviFake (talk) 15:11, 19 October 2026 (UTC)
The fact that you have to tell me about it means that over 90% of users do not know about these. My suggestion was to have it for everyone. Anyway, I have said all I needed on this, and will leave it in the hands of you guys. Have a good day. Yesterday, all my dreams... (talk) 15:27, 19 October 2026 (UTC)
I would support this. I also think it would help new users pause and think a little bit before publishing an edit. qcne (talk) 15:32, 19 October 2026 (UTC)
Agreed. I run across many users with edit counts in the hundreds (and sometimes even thousands) who rarely if ever use edit summaries. A not insignificant number of them are problematic for one reason or another, and it makes it much harder to track what they've been doing. For good faith newbies it can help us intervene and correct them sooner so they don't continue making the same mistakes. ChompyTheGogoat [ Bleat | Munched ] 18:04, 19 October 2026 (UTC)
What do people think if the option is only to turn it on or off. That is: also for experienced users? I'd love to know more about what is behind edits of more experienced editors too. In solidarity, —Femke (talk) 🐦 18:08, 19 October 2026 (UTC)
I have zero issues with this being a universal "On". qcne (talk) 18:11, 19 October 2026 (UTC)
I can't think a good reason not to turn it on for everybody. There are occasionally times when there should be no edit summary (because something automated will add one) but it's no hardship to say that you actually do want to make an edit without a summary. Thryduulf (talk) 18:23, 19 October 2026 (UTC)
I always try to add one even when it's not really necessary - even just a single word - pro forma. If someone is skimming my contributions I don't want them to have to stop and check individual edits just to see whether there's a problem. My sandbox history is full of increasingly irrate summaries when I'm trying to work out tedious code issues XD ChompyTheGogoat [ Bleat | Munched ] 18:56, 19 October 2026 (UTC)
See also: "label" "label" "tag" "label". Just because. ChompyTheGogoat [ Bleat | Munched ] 19:00, 19 October 2026 (UTC)
I've opened a phab: phab:T441726. My preference is to test this first, as it introduces more friction which can backfire. But if there is no capacity to test, I would prefer this is enabled. In solidarity, —Femke (talk) 🐦 20:37, 19 October 2026 (UTC)
Yes, there is no "good" reason. But there is a real reason: laziness. If it is viewed as nagware, it will put some people off. An experiment is well warranted. Yesterday, all my dreams... (talk) 14:42, 20 October 2026 (UTC)
Please consider this edit. Why doesn't the system automatically add a summary for it? It would take a simple, simple bot to do it, and not even in real time. Let us start there, before introducing nagware, please. Yesterday, all my dreams... (talk) 15:14, 20 October 2026 (UTC)
I'm sure there are additional situations where an automated summary would be possible, but there are far more where it's not, and countless edits (including large scale changes) with no descriptors. ChompyTheGogoat [ Bleat | Munched ] 15:36, 20 October 2026 (UTC)
So we could prompt for large scale changes but not simple cases such as above. Yesterday, all my dreams... (talk) 16:01, 20 October 2026 (UTC)
Smaller changes can still have major impacts. The size of an edit isn't necessarily indicative of its significance. Besides, where would you draw the line? Any cutoff would be arbitrary. ChompyTheGogoat [ Bleat | Munched ] 16:05, 20 October 2026 (UTC)
I would start with link additions then see what happens. The two of us can discuss this for ever and a day. Let us wait for other comments. Thanks. Yesterday, all my dreams... (talk) 16:19, 20 October 2026 (UTC)
Most of the edits I see that are purely link additions are through the newcomer tasks, so those are already tagged as such. Edits without summaries are most often newbies manually adding or removing information. ChompyTheGogoat [ Bleat | Munched ] 16:26, 20 October 2026 (UTC)
Support. Summaries are optional and many good edits are made without them, but it's a good habit to encourage. Certes (talk) 20:48, 19 October 2026 (UTC)
I would love to have a trial with actual statistics, and then make a decision based on those statistics. Best, HouseBlaster (talk • edits • he/they) 02:48, 20 October 2026 (UTC)
Let us not just love to, but insist on. Let us release no cure (did someone say Viox?) without a Clinical trial, please. Yesterday, all my dreams... (talk) 14:47, 20 October 2026 (UTC)
Support as a trial, but we should also turn "Add two new dropdown boxes below the edit summary box with some useful default summaries" on by default if we do so. Hason-LEK-SIN ● 💬 ● 🧱 ● 🧪 00:37, 22 October 2026 (UTC)
Another idea I had, is a marathon A/B test with a bunch of existing settings tested. This intervention would possibly lead to more false edit summaries, meaning it can backfire too? In solidarity, —Femke (talk) 🐦 07:19, 22 October 2026 (UTC)
I do seem to recall that mobile (maybe one of the apps) had a dropdown at one point, and it was misused to the point that patrollers found it to be a signal for edits that needed extra attention. Anomie⚔ 11:47, 22 October 2026 (UTC)
Wikipedia:Canned edit summaries, still around in some form as Special:AbuseFilter/633. One of our best anti-vandalism tools. CMD (talk) 11:53, 22 October 2026 (UTC)
Interesting. I have the gadget enabled, although I pretty much only use it for either spelling/grammar or formatting corrections. Anything more extensive I type out manually. I guess the users who'd abuse such a feature don't know or care enough to bother enabling it. I'm mildly surprised that they'd outweigh good faith new users who'd prefer that option though. ChompyTheGogoat [ Bleat | Munched ] 19:49, 22 October 2026 (UTC)
I would also support a trial. What were you thinking, first 50 or 100 edits? First X mainspace edits? Relatedly, it would be good if someone could put together a quick and basic info page about what the warning looks like, perhaps something that Special:Preferences#mw-prefsection-gadgets could link to. That would also be a useful page to note any test results and track changes in defaults. CMD (talk) 07:25, 22 October 2026 (UTC)
I would say the group I expect the biggest difference for are newbies. So an A/B test among TAs and nonconfirmed editors would make most sense. To reduce confusion, I image their settings won't get changed once they reach a certain edit count. In solidarity, —Femke (talk) 🐦 16:55, 22 October 2026 (UTC)
Support: For newbies, more so than experienced editors. But happy to support for both Mme Maigret (talk) 09:30, 27 October 2026 (UTC)
Support changing the default in a trial, but Oppose any change that would prevent disabling the setting. Daniel Quinlan (talk) 17:35, 27 October 2026 (UTC)
Support adding it as default for a trial, collecting data for groups across editing levels. As far as I know, gadgets can always be disabled if needed. Chaotic Enby (in solidarity · talk · contribs) 18:05, 27 October 2026 (UTC)

RFC - Indian cinema CTOP

Should South Asian cinema, broadly construed, be placed under general sanctions as a subtopic of the South Asia contentious topic in the same way as caste and Indian military history?

Specifically, "South Asian cinema, broadly construed" should be understood to include at a minimum films as well as all associated cast and crew (actors, directors, musical directors, etc.) including but not limited to India, Pakistan, Sri Lanka and Bangladesh.

A. Status quo: South Asian cinema remains under the broader WP:CT/SA but is not subject to specific subtopic restrictions
B. South Asian cinema, broadly construed, is noted as a subtopic of CT/SA and placed under the extended-confirmed restriction.
C. Article creation in the topic area is restricted to editors with extended-confirmed permissions. Other editing within the topic is placed under autoconfirmed restriction.
D. The whole topic is placed under autoconfirmed restriction only.

Worth noting that the proposals for autoconfirmed restriction are without precedent as far as I'm aware.

Answers which were already given during the RFCBEFORE discussion (included below under 'Discussion') have been transcluded into the 'Survey' subsection. Courtesy pings for those editors in case they want to modify their responses at all: IrisChronomia, Gurkubondinn, Jéské Couriano, CoffeeCrumbs, CNMall41, ABx11

Athanelar (talk) 10:57, 23 October 2026 (UTC)

Survey (Indian cinema CTOP)

"Anchor" comment placed at the top for the purpose of giving editors something to hit "Reply" on.–Maltazarian ᚾparleyinvestigateᛅ 14:28, 26 October 2026 (UTC)

Disclaimer: I am here to canvass as a friend of Chompy. 海盐沙冰 / aka irisChronomia / Talk / Uploads 03:12, 20 October 2026 (UTC)
My original proposal is C, but after considering how many users game their edit count, I guess I'm going to support Option B. 海盐沙冰 / aka irisChronomia / Talk / Uploads 07:49, 20 October 2026 (UTC)
Option B. Autoconfirmed restriction is pointless. —Jéské Couriano v^_^v Thriller Night! 07:36, 20 October 2026 (UTC)
For the benefit of the closer interpreting these multi-choice options, while I like C a tiny bit more than B, ultimately, my preference is for whatever helps create a working consensus for C or B. CoffeeCrumbs (talk) 04:09, 24 October 2026 (UTC)
I also support D if there's a consensus. At this moment, doing anything is, in my eyes, better than A, which is nothing more than sitting back and waiting until the garbage is so high that there's no volunteer army large enough to empty the landfill. CoffeeCrumbs (talk) 01:56, 26 October 2026 (UTC)
In terms of South Asian Cinema, pages that are related to castes should already be covered by CT/CASTE It's not that simple, and this is why it's hard for people not in the know to understand how deep the problems run here.
In Telugu cinema (Tollywood) for example, a lot of the major actors are either of the Kapu caste (Chiranjeevi, Ram Charan, Pawan Kalyan) or of the Kamma caste (Nagarjuna, Mahesh Babu, N.T. Rama Rao). Not only that, but there are major film dynasties too; the three people I mentioned from the Kapu caste are not just related by caste, but also familially, and their family has major control over the whole production environment in Tollywood. There's an incredible amount of intersectionality and identity politics here which goes way beyond anything in Hollywood, and a lot of unseen factors that can influence disruptive editing (e.g., if I'm a person of a caste which is related to the Kapus, then I might have an identitarian interest in downplaying the success of films whose major actors are Kamma, or conversely in lavishing praise on people and projects related to the Kapus). I'm not as knowledgeable about Tamil films or Malayali films, but I have no doubt the same things exist there. Then there's also a whole separate dimension of Hindu vs Muslim politics in movies like Dhurandar and Ustaad Bhagat Singh.
The reason why ECR is appropriate here is because otherwise antivandal editors in this topic area need a veritable degree on regional history and sociopolitics to understand half of the shit causing the disruption. Athanelar (talk) 16:32, 23 October 2026 (UTC)
That explains why I keep getting accused of supporting some other person I've never heard of when I block inappropriate additions. Wait til they hear I'm a white girl who's never left the states. ChompyTheGogoat [ Bleat | Munched ] 21:15, 23 October 2026 (UTC)
Thanks, that was really informative to me. ‑‑gurkubondinn 22:09, 23 October 2026 (UTC)
This is a big reason as to why I don't agree with the two-tiered approach. I knew caste was a significant factor here, but I wasn't aware of just how much of one it was. —Jéské Couriano v^_^v Thriller Night! 16:47, 24 October 2026 (UTC)
Did not know that. Given that, this should probably be extended confirmed so I'm changing my vote to a mixture of Option D and Option C, with ECR for cinema and ACR for CT/SA in general. ғѳmɑɭʱɑυե (Any pronouns)ᵀᵃˡᵏ 22:04, 25 October 2026 (UTC)
G5 says no substantial edits by others not subject to a block, ban, or sanction. Based on that I believe the criterion would only be nullified if there are substantial edits by someone who is EC. Or are you saying that because the subsequent edits aren't article creations themselves, they could be construed as overriding the inappropriate creation? I can see how that might get messy based on interpretation. My original suggestion had included allowing non-EC users to submit drafts through AfC and only prohibiting direct creations in mainspace, but I think that would just increase the workload for reviewers even more, and full ECR is a cleaner approach. ChompyTheGogoat [ Bleat | Munched ] 04:23, 24 October 2026 (UTC)
I hesitate to go for ECR without having tried something less hefty first. As it means only a tiny handful of readers can edit an article, it should only be used in cases where it is unfeasible to allow articles to go without it. This does appear to be true for certain kinds of Indian cinema articles, but to place the whole of Indian cinema under ECR should require that the whole of Indian cinema needs to be under ECR. I do not think that's been established here. ECR can be applied to those kinds of Indian cinema articles where it seems necessary as part of the WP:STANDARDSET, but for Indian cinema as a whole we should try to go with a lesser restriction first. If that doesn't work we can revisit the matter. –Maltazarian ᚾparleyinvestigateᛅ 14:14, 26 October 2026 (UTC)
As such I don't see why South Asian cinema should be specifically singled out for ECR or an autoconfirmed restriction since the arguments used above to justify such a restriction would apply equally well to any other CT/SA subtopic. I wouldn't necessarily be opposed to a blanket autoconfirmed editing restriction on all of CT/SA (though in my experience from RCP this restriction feels a little too severe), but this is not what the RfC is about. ECR wouldn't deal with the UPE problems since most of the organised paid editing syndicates operate accounts with XC anyways, and the non-XC paid editors generally produce blatant spam that can be dealt with without needing anything from the CTOP toolkit. The other disruption for the most part can be dealt with using tools already available under the standard sysop and CTOP toolkits.
I think that a blanket autoconfirmed restriction on South Asian cinema would have more benefits than drawbacks, but it comes off as too broad in scope to me since most of the disruption (as I see it from my experience in RCP and NPP) seems to focus on new or "hot" films (and their crew); famous or controversial films, personalities, etc.; and topics already clearly under the caste and milhist ECRs. Most (>80% I guess) pages in the area get very few edits and don't need protection. A narrower scope for option D which applies only to (for instance) films released in the last 365 days and their crew would be fine with me. JavaHurricane 17:02, 26 October 2026 (UTC)
I support an ECR article creation restriction, but oppose any general restriction on editing. South Asian films are a hugely popular area for casual editors and are some of our most viewed articles. A general autoconfirmed restriction would lock out huge numbers of casual editors, while doing little to prevent the determined abuse and sockpuppetry these proposals are aimed at. OTOH, an ECR restriction on new article creation may have an impact on the widespread promotional/UPE sockpuppetry focused on boosting non-notable actors, films, and other topics in this area, while having minimal impact on casual editors interested in what they're seeing in the cinema or in the news. Toadspike [Talk] 01:45, 28 October 2026 (UTC)
I would somewhat oppose full ECR restrictions ; I believe that should be reserved for the most controversial topics when truly necessary. While South Asian cinema definitely has ties to the restricted topic; I doubt that it belongs at the same severity. So I would support C or D. There are a few autoconfirmed users who cause trouble, so I can understand the B position; but I'm not sure if it's enough to warrant it. Dawn Lim (talk) 11:38, 28 October 2026 (UTC)

Discussion (Indian cinema CTOP)

Pre-RfC discussion

I previously raised this at Wikipedia:Village_pump_(proposals)/Archive_228#Indian_cinema_CCTOP? but it came up again at WP:ANI#Jailer 2 and given the lack of traction in the first discussion I thought I'd raise it again.

As I said in the first discussion, and as @ChompyTheGogoat has now summarised; no one else seems to care that [Indian cinema] is rife with UPE and unsourced content, We have a whole corner of Wikipedia that's chock full of WP:PROMO.

Non-Indians have a tendency to underestimate the social role which cinema plays in India, and the degree to which nationalism, casteism, regional pride etc intersect with cinema. One needs only look at the mass reception to releases like Dhurandhar: The Revenge and the political discussion surrounding them to see that. I would go as far as to say that cinema can be just as controversial to an Indian audience as caste topics are (and they're often linked!) so it's no wonder that we see so much tendentious editing in this topic area.

I still insist that it would be sensible to place some degree of restriction on the Indian cinema topic area to maintain article quality, minimise disruption, and reduce the effort required for cleanup (although the extent to which anyone is trying to clean it up right now, I have no idea.)

Just to throw another example which came to mind, I remember the effort I had to go to in order to clean up Udit Narayan, an article about a playback singer which looked like this before I edited it in December. In January a sockpuppet again edited it back into a promotiomal mess. This was reverted and has since been stable, but it goes to show how a seemingly innocuous article can turn into a complete mess just becausr of the subject's relation to Indian cinema. Athanelar (talk) 10:48, 19 October 2026 (UTC)

Thanks for opening this. I stumbled into the subject mostly by accident and I've been doing what I can, but I'm only one person, and I've mostly been focusing on reverting and protecting - I'm not the right person to attempt to clean up the existing issues in articles. There is a existing task force, but from what I've seen most of the people involved appear to be fans or people who otherwise have a vested interest but also uphold WP principles and do their best to follow protocols with their editing. Unfortunately many of them aren't very experienced, especially with editing in any other areas. What we really need are more experienced editors who have no personal interest in the subject (like me) and can maintain NPOV. I've discussed it with others and was waiting on @IrisChronomia to write up a proposal, as they're more experienced, but I'm sure they have other priorities. The main idea we came up with was to require AfC for all new articles on the subject by editors who aren't EC (or autopatrolled, if there are any who aren't also EC). Anything else can be automatically draftified without attempting to determine notability, sourcing, or whether the creator is a UPE sock.
That only covers part of the issue, however - there's also a huge amount of problematic editing on existing articles. Personally I'd love to see semi protection applied by default, but I know that's a tall order. I'm open to other suggestions that would have a similar effect on minimizing disruptive editing by all the low edit count TAs/SPAs/UPEs/likely socks. Semi protection has solved most of the problems on most of the articles where I've requested it - only one had to be taken up to ECP. Most of them won't bother edit gaming and only reach autoconfirmed via edits to their target articles (if at all).
In terms of the overall project it would really help to have a few unbiased volunteers with experienced working AV. Even if they're like me and don't want to spend too much time trying to fix existing issues it would make a big difference if we could crack down on all the problematic editors so things don't continue to snowball - then we could chip away at improving existing content. Maybe someone could build a tracker for the project so that people can easily flag for COI, LLM, unsourced, etc. and editors who are involved can work their way through the list.
One other specific problem that's taken up an inordinate amount of my time (and is the most common reason for protection) is box office figures. This is (apparently) a very hot button issue that has a lot of bearing on how successful a film is considered, and there have been scandals involving gaming of reports. I know it's been discussed on wiki before (maybe someone else can find the links), and as far as I can recall the overall consensus was that it's relatively trivial to anyone not involved with the topic - and certainly doesn't need to be updated every five minutes! - but given how obsessed people are it's easier for us to allow them to be posted from reliable sources and focus on inappropriate insertions rather than trying to shut it down entirely. The issue is defining reliability. There are no official reporting sources in India, and BO trackers don't disclose their proprietary protocols, so we can only take their word on accuracy, and there can be a significant discrepancy. Current consensus within the project is to follow WP:ICTFSOURCES. Unfortunately, one of the most prominent sources - Sacnilk - was determined to be unreliable, and many otherwise reliable media sources quote their figures and must therefore be excluded as WP:FRUIT. I dug into things further and found that the actual discussions (such as they are) leading to reliability determinations for the handful of sources with independent internal tracking (including Sacnilk) were mostly based on vibes, not any particular proof that the figures or methodology are accurate. We've attempted to initiate re-evaluations at Wikipedia talk:WikiProject Film/Indian cinema task force#Reassessment of Sacnilk.com, Wikipedia:Reliable sources/Noticeboard/Archive 525#Reliability of Indian cinema box-office trackers, and Wikipedia talk:WikiProject Film#Reliability of Indian cinema box-office trackers, with no success. I don't personally care one way or another but I'd like to see standards applied consistently.
We aren't going to be able to make any progress on this unless editors are willing to step up and at the very least participate in discussions so we can establish said standards for others to enforce. People have to care, or it's only going to get worse. AI has made it far too easy for anyone to churn out a PROMO article in five minutes and get paid. ChompyTheGogoat [ Bleat | Munched ] 18:49, 19 October 2026 (UTC)
I'll also submit that if no one cares enough to argue against it, a few of us involved with AV/SPI can constitute a consensus to implement CTOP requirements. ChompyTheGogoat [ Bleat | Munched ] 19:04, 19 October 2026 (UTC)
Thanks for chiming in. I fully agree with the restrictions you've proposed, including both the AfC requirement as well as semiprotection. Athanelar (talk) 19:45, 19 October 2026 (UTC)
My suggestion of semi-protection across the board may turn out to be inadequate - I've just submitted two more for ECP. Not all articles are subject to the same level of disruption though, and I think we could at least trial it with semi and a low bar for ECP upgrades at WP:RPP. Maybe the disruptive editors will start to get the hint. Hey, a girl can dream, right? ChompyTheGogoat [ Bleat | Munched ] 03:22, 20 October 2026 (UTC)
@gurkubondinn since you asked to be notified. ChompyTheGogoat [ Bleat | Munched ] 19:43, 19 October 2026 (UTC)
Oop, I meant to tag him, thanks for that! Athanelar (talk) 19:45, 19 October 2026 (UTC)
Support the use of ECR for Indian cinema, presumably this would be through a WP:GS designation by the community. I wasn't aware of the social role that Indian cinema has until I started seeing the disruption (and LLM junk) here on enwiki, and I have not really watched any Indian movies to any real extent (saw one or two years ago but I can't remember which movies right now). I have no stake in this other than as an enwiki editor. ‑‑gurkubondinn 07:13, 20 October 2026 (UTC)
I would absolutely be in favor of an additional restriction on South Asian cinema. It's an absurdly deep source of UPE, sourcing issues, junk AFCs clogging things up. The Indian cinema task force has done a really good job at WP:ICTFSOURCES, but simply put, the people that want to write articles and force in content about every third-tier actor who appeared in a fourth-tier movie, and everybody who worked on or was even tangentially related don't follow that guidance. It's a real timesink on the community and noticeboards and LLMs have made this area even worse. CoffeeCrumbs (talk) 22:04, 19 October 2026 (UTC)
Strong support for ECR (creation of articles) and confirmed (any edit at all).
Disclaimer: I am here to canvass as a friend of Chompy. 海盐沙冰 / aka irisChronomia / Talk / Uploads 03:12, 20 October 2026 (UTC)
Is there anything else I'm forgetting from our previous discussions? I'm slightly afraid to attempt to dig back through all the threads. ChompyTheGogoat [ Bleat | Munched ] 03:16, 20 October 2026 (UTC)
Indian cinema already falls under WP:CT/SA. One of the existing example sub-CT topic bans is "Indian entertainment, generally or in a specific language", and another is "Indian political, ethnic, religious, and caste topics", which as mentioned films can tie heavily into. Given this, for those with deep experience in the topic, what existing potential remedies (WP:STANDARDSET) are not being used that would be helpful? Are existing potential actions being rejected, and if so, for what reasons? From reading above, it sounds like the issue may be a lack of people and understanding ("it would really help to have a few unbiased volunteers with experienced working AV"), in which case it would perhaps be a good idea to create some sort of information page at WP:ICTF that editors (including admins) can look at to get acquainted with the topic's challenges. CMD (talk) 04:21, 20 October 2026 (UTC)
I think we would need explicit consensus that current ECRs apply to cinema, as opposed to the subjective "tie into" - or designate it an additional subtopic per resolution 6b. By my reading military and castes are the only subtopics currently subject to said restrictions; anything more general is only covered by the default CTOP protocols. I would be more than happy with an admin action extending ECR. That would mean any article within the subject area should receive automatic ECP approval, correct? ChompyTheGogoat [ Bleat | Munched ] 04:35, 20 October 2026 (UTC)
The specific proposal here is to make sure ECR or similar applies. The standard set isn't really helpful if the number of people doing cleanup is slim to none compared to the people making the mess. It's an impractical amount of workload for the people doing the cleanup to individually report editors and articles for standard arbitration remedies. SA cinema needs to be under preemptive restrictions to reduce the quantity of bad edits coming in. Athanelar (talk) 05:16, 20 October 2026 (UTC)
And when I first realized the scope of the issue I did review the above arb case, and my interpretation was that the restrictions as currently worded don't apply in this area. I'm happy to be corrected in that regard. It's not the first time I've seen someone imply that ECR applies to a wider subgroup, but I think that may have something to do with the various amendments over time. If we implement ECP across the board I expect the disruption would drop to virtually nothing, and while there would be significantly less overall editing we could do more cleanup of the existing problems and less policing of new ones. SPAs often wouldn't even break autoconfirmed without being able to edit film articles, let alone EC. ChompyTheGogoat [ Bleat | Munched ] 05:23, 20 October 2026 (UTC)
Or when a large part of the people making the mess are using LLMs to make the mess, the asymmetry of effort becomes enormous. ‑‑gurkubondinn 07:42, 20 October 2026 (UTC)
Remember, the scope of WP:CT/SA was changed earlier this year to make the ECR restriction limited to South Asian castes and Indian military history (broadly construed). I don't think this is a case where additional documentation would be helpful; it's nearly impossible to get these participants to acknowledge sourcing in these areas, and it nearly inevitably ends up with blocks or restrictions at ANI. The problem isn't that there aren't enough knowledgeable editors in this area, but that there already a lot of knowledgeable editors in this area, pushing back at a tsunami. CoffeeCrumbs (talk) 09:52, 20 October 2026 (UTC)
Support 500/30 rule for Indian cinema topic area - What do Indian cinema and Indian military history have in common? Both are intrinsically linked to caste, which has been THE primary motivator of problems with regards to the India topic area. The standard set is irrelevant as Indian cinema already falls under WP:CT/SA and thus it can be assumed discretionary sanctions are already on the table. The problem is more dealing with blatant mercenary editors and the caste/nationalist warriors that come out of the woodwork in defence of a film that supports their caste or weltanschauung. —Jéské Couriano v^_^v Thriller Night! 06:22, 20 October 2026 (UTC)
This is such a great argument. Thank you. 海盐沙冰 / aka irisChronomia / Talk / Uploads 07:48, 20 October 2026 (UTC)
Both are intrinsically linked to caste, Huh? That's entirely false. I'm fairly certain that the scores of WP:UPE editors in the Indian cinema topic area are not motivated purely by nationalistic or caste-specific sentiment. You do get the odd film that flares nationalistic rhetoric (for example Dhurandhar: The Revenge) but tbh that is not significant enough to require a special carveout, SASG and IMH are good enough for those. The problem that it looks like we are trying to solve is UPE Sohom (talk) 08:55, 26 October 2026 (UTC)
@Sohom Datta read this. ғѳmɑɭʱɑυե (Any pronouns)ᵀᵃˡᵏ 21:57, 26 October 2026 (UTC)
@F0malhaut42 and @Athanelar There might be underlying caste lines in the Telegu industry but those are not the ones that have seen the most problems onwiki. For what it's worth, the WP:UPE disruption is not confined to just the Telegu film industry. UPE disruption exists in the Tamil industry, Telegu industry, the Bengali film industry, the Hindi one and potentially even the Punjabi one. The constant and primary disruption factor onwiki is WP:UPE, not motivated editing (which would require significantly different considerations) denoted by the fact that that most of the reports related to disruption show up on WP:SPI and not WP:AE and are typically less about POV-pushing of specific caste-associated sets of movies (obviously we ignore the SASG specific ones like Dhurandar that are already covered by ECR) Sohom (talk) 00:53, 27 October 2026 (UTC)
It's both. There are tons of disruptive editors who can't be taken to SPI because a bunch of unsourced insertions with no edit summaries or attempts to communicate leave no proof either way. I've been accused of bias numerous times for blocking such changes. There's nothing to take to AE because the current restrictions are too vague to apply to this problem. If they did we wouldn't need to implement additional ones. ChompyTheGogoat [ Bleat | Munched ] 23:35, 27 October 2026 (UTC)
FYI for those participating in the discussion: I think the best way to go about this is that after a couple more days of discussion, if there is consensus (and there does seem to be) to designate a CTOP here and impose ECR on that topic, then I'll open a subsection here for an RfC on that question so that more people can be notified and we can get a robust consensus. If anyone disagrees with that approach, please do say so.
Based on what's been said so far, these are my proposed RfC prompts;
A. Status quo: South Asian cinema remains under the broader WP:CT/SA but is not subject to specific subtopic restrictions
B. South Asian cinema, broadly construed, is noted as a subtopic of CT/SA and placed under the extended-confirmed restriction.
C. South Asian cinema, broadly construed, is noted as a subtopic of CT/SA. Article creation is restricted to editors with extended-confirmed permissions. The topic area as a whole is placed under autoconfirmed restriction. (not sure if autoconfirmed restriction has precedent?)
Please give feedback/workshop these however you think necessary.
N.B., "South Asian cinema, broadly construed" includes films as well as all associated cast and crew including musical directors, musicians and playback singers primarily working in film, and is specifically inclusive of India, Pakistan, Bangladesh and Sri Lanka. Athanelar (talk) 06:46, 20 October 2026 (UTC)
Option B. Autoconfirmed restriction is pointless. —Jéské Couriano v^_^v Thriller Night! 07:36, 20 October 2026 (UTC)
Please note the above is not supposed to be the survey itself, just workshopping the questions. I'll transclude this response when I do open the RfC if you want, though. Athanelar (talk) 07:39, 20 October 2026 (UTC)
My original proposal is C, but after considering how many users game their edit count, I guess I'm going to support Option B. 海盐沙冰 / aka irisChronomia / Talk / Uploads 07:49, 20 October 2026 (UTC)
Option C as first choice, Option B, as second choice. I don't think autoconfirmed is pointless here. While registered editors can certainly game autoconfirmed, TAs are a sizable chunk of the problem, and they can't be autoconfirmed at all. It's not uncommon to have to tangle with a TA editor on a slop article four or five times in a day as they rapidly jump TAs and IP ranges. CoffeeCrumbs (talk) 09:56, 20 October 2026 (UTC)
Not pointless, but possibly insufficient. I suggested an autoconfirmed restriction initially both to be conservative and because I expected ECR would get tossed out as WP:SNOW. Just since that earlier comment multiple articles have been subject to ongoing disruption by a gaggle of editors barely over the confirmed line. There are some low count editors who make valid improvements, but I'm not sure the scale of their contributions is enough to offset the scale of disruption. My suggestion to one good faith editor who was stopped by ECP was to work on other subject areas and reach EC if they're that interested in continuing to contribute to film articles, which seems perfectly reasonably for any others in the same boat. More experience will help them do better work. (They were only inserting box office figures from accepted sources anyway, and getting increasingly frustrated by the limitations, so...) ChompyTheGogoat [ Bleat | Munched ] 14:51, 20 October 2026 (UTC)
I'd concur with this view leaning towards option C, noting that we can always revisit this if it turns out that this just turns the TA disruption into autoconfirmed account disruption. In my experience it's much easier to weed out and halt autoconfirmed accounts than it is to address IP-hopping TAs, so I think it's worth giving it a shot. signed, Rosguill talk 14:59, 20 October 2026 (UTC)
You might want to check my latest RPPs. We'd have to go around dropping an awful lot of blocks. ChompyTheGogoat [ Bleat | Munched ] 15:04, 20 October 2026 (UTC)
I would add on to Rosguill's reply that one also has to consider achieving consensus. My feel for the community -- which may of course be wrong -- would be that going too far, too fast, here would undermine consensus building, even if that ends up what we have to eventually do. LLMs are a much larger problem than cinema of South Asia, but I don't think we'd have as quick success getting the policies closer to where they needed to be without the incremental steps first taken.
If autoconfirmed turns out to not be sufficient to manage this situation -- and I think this is one of the probable outcomes -- with there already being a restriction established and in place, it's not as much of a leap to go to ECR. I think as a principle, you want to try community solutions first; I believe that ethically, we have a responsibility to try to solve these issues as a community ourselves and only escalate it when we have to. That may make resolutions slower, and a bit messier, but I tend to think that the community can be too quick to make things admin/ArbCom headaches when they should be our headaches initially. This is one of the reasons I'm so active at explaining blocks to admins; admins have a toolset to do specific things, it shouldn't necessarily be their responsibility to have to also go into a billion dreary discussions explaining why sources are need or why legal threats are bad and why you can't just start a new account when you're blocked. I don't mean any of this as a dig at you, just explaining why I feel this way. CoffeeCrumbs (talk) 17:35, 20 October 2026 (UTC)
I think having admins designate it under the 6b resolution would be more expedient than running it through RfC, given that there is obviously long term extensive disruption. On the off chance they fail to reach consensus we could fall back on community designation.
And thank you again for initiating this! My mental health appreciates it. ChompyTheGogoat [ Bleat | Munched ] 14:29, 20 October 2026 (UTC)
The 6b provision says Such extensions must be of a limited duration, not to exceed one year. There's no reason to believe this will get any better in one year, so we'd be better off doing it indefinitely by community consensus. Athanelar (talk) 15:41, 20 October 2026 (UTC)
Oops, I missed that part. I think I'd still like to see that enacted for now - I can easily foresee hordes of canvassed SPAs flocking to an RfC and dragging things out for god knows how long. If admins shut down their editing in the area to allow us to start to get a handle on things maybe they'll give up and find better hobbies, so we can tie up the community side to make it permanent. ChompyTheGogoat [ Bleat | Munched ] 15:59, 20 October 2026 (UTC)
RfCs aren't headcounts, they're debates. It doesn't matter how many SPAs participate if their arguments are spurious, the side that wins is supposed to be the side with the better policy-reasoned argument. Athanelar (talk) 16:08, 20 October 2026 (UTC)
I realize that, but they could still drag things out indefinitely. We've seen socking on AfDs in the subject area that can get out of hand. ChompyTheGogoat [ Bleat | Munched ] 16:12, 20 October 2026 (UTC)
I would suggest a fourth option be added here, that being Option C but applied to CT/SA as a whole and not just the topic of Indian cinema. ғѳmɑɭʱɑυե (Any pronouns)ᵀᵃˡᵏ 06:29, 22 October 2026 (UTC)
For the record, I would support this option. ғѳmɑɭʱɑυե (Any pronouns)ᵀᵃˡᵏ 06:30, 22 October 2026 (UTC)
FYI - I posted a note at WT:WikiProject Film/Indian cinema task force about this proposal. S0091 (talk) 20:19, 20 October 2026 (UTC)
Support Option C then Option B - Option C would restrict many of the SPI throwaway accounts who operate heavily in that space. However, it would could be a nightmare to enforce and cause more issues than we alrady have. Option B would be my second choice. --CNMall41 (talk) 20:44, 20 October 2026 (UTC)
What part would be hard to enforce? We can slap protection on most articles instead of needing to wait for disruption first and chasing dozens of editors to noticeboards. ChompyTheGogoat [ Bleat | Munched ] 21:11, 20 October 2026 (UTC)
This definitely needs an RFC. The lack of experienced South Asian editors commenting here is a concern as are the derogatory comments about the ICTF from a ten month editor. There should be no rushing into action before a properly run RFC in my view Atlantic306 (talk) 23:27, 20 October 2026 (UTC)
Nobody is rushing into anything. I fully intend to hold an RfC on this once it's had a day or two more for any points of discussion to be raised, for any feedback to be given about the proposed RfC questions and so on. Athanelar (talk) 03:28, 21 October 2026 (UTC)
@Athanelar I am assuming this meant is to include actors, directors, etc. I suggest changing the wording to "The topic of South Asian cinema...." which aligns with the wording for Indian military history. I also suggest an option for AC restriction for the topic area, which would include new articles (like B but for AC). With that option, effectively TAs would not be able to submit drafts and as others have noted, a lot of the disruption is by TAs. Even if it is unlikely to pass, I think it is better to have the option on the table.. S0091 (talk) 15:09, 21 October 2026 (UTC)
It is, yes; N.B., "South Asian cinema, broadly construed" includes films as well as all associated cast and crew including musical directors, musicians and playback singers primarily working in film, and is specifically inclusive of India, Pakistan, Bangladesh and Sri Lanka. I've only specifically named musical staff because they play a much larger role in the culture surrounding Indian cinema than equivalent people do in Western cinema (name a famous movie musical director in the west except Hans Zimmer) and I want to make sure it's explicitly clear that this topic area categorises those people too.
I suggest changing the wording to "The topic of South Asian cinema...." which aligns with the wording for Indian military history. That's what the final wording on the CT page itself would be, but I can make that clearer in the RfC. I'll add an AC option too just to cover bases. Athanelar (talk) 16:21, 21 October 2026 (UTC)
"We can slap protection on most articles instead of needing to wait for disruption first", I like the idea, but "we" cannot. Protection needs applied by an admin and I am unsure how many would be willing to add to the already overwhelming workload. The disruptors will create disambiguations to avoid protection as well which adds to even more SPI work. --CNMall41 (talk) 15:55, 21 October 2026 (UTC)
Another thing to note is UPE socks game WP:AFC/Redirects, usually as a TA, where they request a redirect, an editor approves/creates it, then the socks turn it into an article, sometimes one with an account. That has significantly subsided as editors caught on to what they were doing but if restrictions pass, I expect it will become a problem again. The tricky part is because the redirect is created by an editor in good standing, some admins will not delete them (i.e. G5 which also applies to pages created in violation of restrictions). S0091 (talk) 16:22, 21 October 2026 (UTC)
Well, the regular AfC blocks editors from submitting drafts in an ECR CTOP when they're not EC, so surely AFC/R also rejects redirect requests relating to an ECR CTOP if the requesting editor isn't EC? If not, surely they should? Athanelar (talk) 16:26, 21 October 2026 (UTC)
Not all reviewers will know or they forget. That happens with drafts as as well. I was not aware of AfC had the ability to block an editor from creating/submitting a draft that violates ECR. When was that was implemented? S0091 (talk) 16:40, 21 October 2026 (UTC)
One of the "deny" reasons is because the editor is trying to submit a draft in an ECR CTOP they don't have permission for. If they again try to resubmit it will be rejected for tendentious resubmission. That's the "blockage" I mean. Poor word choice, I suppose, I didn't mean to imply WP:BLOCK. Athanelar (talk) 18:58, 21 October 2026 (UTC)
Thanks Athanelar. I thought that might be what you meant but also thought had AfC developed the ability to prevent editors from violating ECR, that would be something to perhaps leverage. :) Speaking from my own experience as an AfC reviewer, a topic being ECR is not my top thought when reviewing and I am aware of ECR topics. Things will slip by on occasion. S0091 (talk) 19:32, 21 October 2026 (UTC)
Sure, we can't be 100%. That said, if AFC/R is suddenly inundated by a lot of bad requests because of these new restrictions, it'll probably become easier to detect because reviewers will be on the lookout for it. And, after all, if even 1/10 slip through the cracks and result in an article being created, that's still better than the status quo which is anybody with an autoconfirmed account publishing straight to mainspace and everybody else packing the AfC queue full. A bonus to these restrictions I hadn't considered before is we'll probably be able to quick-deny a whole lot of SA cinema articles at AfC, too. Athanelar (talk) 19:42, 21 October 2026 (UTC)
It happens, but many reviewers focus on specific subject areas, so those most likely to review Indian cinema drafts would hopefully be more aware than others, just like they're more aware of active LTAs on the subject. ChompyTheGogoat [ Bleat | Munched ] 19:33, 21 October 2026 (UTC)
And sometimes LLM or sock target pages get through too, then we delete them and politely remind the reviewer to keep an eye out for them. Mistakes happen. That's not a reason to avoid applying preventative restrictions.
Having a good faith editor being the creator of record on request of a sock sounds like a technicality. The situation should just be noted in the G5 so the reviewing admin understands. ChompyTheGogoat [ Bleat | Munched ] 19:22, 21 October 2026 (UTC)
Sometimes? I think both of us can attribute our experience at SPI that "sometimes" actually means "bludgeoning a page to death including creation multiple drafts and pages under disambiguation titles like playing hide the coconut as experienced editors move back to draft and wasting countless hours of enjoyment editing and instead spent it playing whack a mole at SPI and AfD discussions." I get your contention, but "difficult to enforce" is still my contention. It will be difficult to enforce. --CNMall41 (talk) 23:38, 21 October 2026 (UTC)
No harder than it is without CTOP restrictions. If we apply this we can immediately draftify anything that does get through from non-EC accounts without stopping to worry about whether they're socks, and if they try to move it back they can be blocked as an enforcement action without waiting on CU. The area needs more patrolling regardless, but I'm not able to wrap my head around the idea that more protections and easier blocks will somehow make things worse than they are now. I'm very confused by it.
FWIW "sometimes" was specifically referring to AfC reviewers accidentally letting them pass when the socks try to run things through there. I'm not really sure what's up with the recent pattern of trying that first before a unilateral mainspace creation - maybe they think it's less likely to get deleted? Who knows; I don't understand a lot of what they do. ChompyTheGogoat [ Bleat | Munched ] 01:39, 22 October 2026 (UTC)
I not suggesting at all this a reason to not apply restrictions. I am simply noting situations I have encountered so others are aware. G5, at least with Twinkle, does have a way to add an explanation, outside of a sock master or applicable restriction.. If it were a redirect I created via AFC/R, I have done both G5 and G7 to cover both but if another editor created it, G7 is not applicable and those are the ones that might be declined by an admin. This is not something I think it a major issue but something to be aware of. S0091 (talk) 19:51, 21 October 2026 (UTC)
Then shouldn't the reviewers be informed? Katzrockso (talk) 06:59, 22 October 2026 (UTC)
I really wish they'd add a way to include an explanation for all CSDs. I frequently have to submit it as custom so I can explain the situation. ChompyTheGogoat [ Bleat | Munched ] 20:27, 21 October 2026 (UTC)
Well, it's the same as any CTOP. Admins don't need to go through and apply protection to every single cinema article, but they'd be able to way faster and easier if the topic is under ECR/ACR (since at the first sign of trouble on any relevant article an admin can slap the protection on and call it a day) Athanelar (talk) 16:23, 21 October 2026 (UTC)
Sure, they already do that for salted titles, but I'm taking about existing articles that pass notability. It shouldn't be an issue to batch nominate - admins would only need to spend approximately two seconds verifying the articles fall within the subject area. For new pages that pass AfC the request can be applied at move to mainspace. This would be far less work overall than chasing down all the bad edits that will continue to be made against the restriction and having to keep justifying that the disruption is in fact disruptive. The whole proposal would basically amount to nothing because we'd still be applying the same remedies for the same problems. Most of these editors don't care about our rules and will just keep on as long as they're capable of editing the articles. And a lot of them don't leave enough of a trail to track at SPI either. ChompyTheGogoat [ Bleat | Munched ] 19:18, 21 October 2026 (UTC)
Support having an RFC I think any sort of restriction here would be a welcome change. QuicoleJR (talk|edits) 19:22, 21 October 2026 (UTC)
Support having an RFC long overdue given the disruption we have experienced and appreciate Athanelar for starting the discussion. S0091 (talk) 20:17, 21 October 2026 (UTC)
Support RfC Better to have this formalised. —Jéské Couriano v^_^v Thriller Night! 20:22, 21 October 2026 (UTC)
Agree with others that there should be a formal RfC on this topic. mdm.bla 00:19, 22 October 2026 (UTC)
Could we add to the RfC a specific protocol for handling box office updates? The pushers are getting increasingly desperate on talk pages of articles I've had protected despite our big red notice that no one ever reads. It's unfortunate that the most popular sources are currently not accepted as reliable, which is why I supported the as-yet unsuccessful attempts to re-evaluate all of them without bias. Regardless, to the rest of the world updating the income every five minutes is not high priority. I'd suggest something along the lines of "box office requests must be submitted through a proper edit request with a supporting citation from an acceptable source at WP:ICTFSOURCES or they will be summarily deleted". I guess that might just be seen as updated phrasing of the current notice, and I don't know how we can force anyone to read it. Maybe I'm being too lenient with continuing to try to explain sourcing requirements to people who don't care. ChompyTheGogoat [ Bleat | Munched ] 04:33, 22 October 2026 (UTC)
I would not combine an RfC question about administrative procedures with an RfC question about content. For content questions, I would suggest adding something at WP:ICTFMOS (not the best shortcut as current advice goes beyond MOS) first. If needed, that provides text an RfC can affirm rather than starting from scratch. CMD (talk) 04:56, 22 October 2026 (UTC)
Aside from the sourcing issue (which I'm not sure what else we can do about, if no one has any input) my concern is mostly about how to handle enforcement, because when they can't push their preferred changes the talk pages immediately get bogged down with requests and subsequent arguments. I guess maybe just revisiting it at the task force would be the best first step. ChompyTheGogoat [ Bleat | Munched ] 05:11, 22 October 2026 (UTC)
Note that big red boxes at the top of the page are likely to be absent on mobile browsers. It's why I've put FAQs in the talk page proper for several India related topics (most notably Sushant Singh Rajput and Shivaji). —Jéské Couriano v^_^v Thriller Night! 15:51, 22 October 2026 (UTC)
I'm not convinced they'd slow down to read those either. Most of them bulldoze past all the other open threads with the same requests. ChompyTheGogoat [ Bleat | Munched ] 17:33, 22 October 2026 (UTC)
Enough would. The goal is more to mitigate, not eliminate. —Jéské Couriano v^_^v Thriller Night! 17:35, 22 October 2026 (UTC)
I'll try it on a current target page and see if it makes any difference.ChompyTheGogoat [ Bleat | Munched ] 17:43, 22 October 2026 (UTC)
The template does display on mobile for me as long as it's below a section header. Minerva just doesn't like anything above the table of contents. We can certainly make that standard practice if it has any effect. ChompyTheGogoat [ Bleat | Munched ] 17:59, 22 October 2026 (UTC)
Question on the technical side - we can't protect pages that don't exist yet, but could we utilize a maintenance category that would flag page creations by non-EC editors that are placed in relevant categories? Maybe even a bot that could automatically draftify and drop a corresponding ECR notice. Considering the scale of things I think the more we can automate and reduce the workload on enforcers (especially admins), the better. Minimizing new disruption will also leave good faith editors with more time to work on cleaning up existing content. ChompyTheGogoat [ Bleat | Munched ] 07:39, 22 October 2026 (UTC)
Nonexistent pages can absolutely be protected, and routinely are; see WP:SALT. We try to avoid it, though, because editors will often just create the page anyway with a slightly different title. Omphalographer (talk) 20:19, 22 October 2026 (UTC)
I mean ones we aren't aware of yet - brand new creations (as well as title gamed versions). This could potentially flag any creation within the relevant categories, under any title. ChompyTheGogoat [ Bleat | Munched ] 20:23, 22 October 2026 (UTC)
It seems technically possible, assuming WikiProject tags or categories are added to the article a bot could track. I'm not aware of a precedent however. CMD (talk) 22:26, 22 October 2026 (UTC)
I'd be happy to help work out the details with someone more savvy once the RfC clears. We're definitely going to need a structured approach to try to get a handle on things. ChompyTheGogoat [ Bleat | Munched ] 00:43, 23 October 2026 (UTC)
Support 500/30 requirement with Option B per Jéské Couriano. --ABx11 (she/they) 00:35, 23 October 2026 (UTC)

Post RfC start discussion

What kind of enforcement actions are available and aren't working? Indian cinema rarely escalates to the arbitration enforcement noticeboard; is this a lack of capacity (awareness of CTOPs, energy to do so, confidence to do so), range hopping TAs, mostly handled by non-CTOP admin actions, etc? Is this mostly getting reported to SPI, ANEW, and RfPP? Is this appearing at AN/ANI, and if so, what are those threads like?

Looking at a few recent protections from the protection log; Dalit Film and Cultural Festival under CT/CASTE, Fighter (2024 film) under IMH, Jailer 2 (1 year ECP, no subtopic), Achhut Kannya (no subtopic). Most people are getting blocked/topic banned for subpar conduct in CASTE or IMH or modern politics (check WP:AELOG for yourself to be sure, but I've read or participated in almost all cases in the last year and definitely in CT/SA). It's hard picking out the cinema related ones from the protection log alone, but it's not as frequent as other CT/SA protection clusters. The main clusters I am aware of are modern politics and political parties, castes, and military history. As for why I'm asking, characterizing how disruption is currently being handled helps a lot in understanding what we are struggling with. I don't go out of AE and AN very often, my main area is copyright after all, and I would imagine that this will also draw people that are unfamiliar with the scope of enforcement entirely. Sennecaster (Chat) 17:37, 27 October 2026 (UTC)

In my anecdotal experience we've had a lot of film-adjacent articles come through AfC in some form or another with UPEs, socks, etc. One which springs to mind is Mission C2000 which was tendentiously created and recreated under lots of different titles by Alakmarsaify socks. Admittedly I've never dived much into cleaning up the topic area myself because what I have seen of it at AfC has really kept me at bay. @ChompyTheGogoat is probably in a better position to call up some specific examples since they were recently doing cleanup. Athanelar (talk) 22:59, 27 October 2026 (UTC)
There's not enough enforcement period. Most of it goes through SPI or ANI when someone (usually me) actually bothers. The current CT/SA restrictions don't apply to this subject area, and most editors just drop whatever insertion they feel like with little to no sourcing and no communication, primarily from TAs or low count named SPAs.
Anyone who thinks we shouldn't need additional restrictions should spend some time actually working cleanup in this subject area to see just how extensive the problem is and why current remedies aren't sufficient. I just ran an editor to ANI with 2500 edits over multiple years, compromised almost entirely of unsourced or poorly source additions to this subject area. They had 18 warnings (and an additional dozen miscellaneous TP messages) that they ignored. All of those other editors were content to drop drive-by templates and move on without actually addressing the problem - and it's far from the only case. Even under ECR we'd have to work through grandfathered editors like this, but "difficult to enforce" is not a viable excuse for not implementing restrictions - otherwise why have restrictions at all? At least this would give enforcement some teeth. Widespread ECP and a low bar for blocks would have a huge impact. The problem has been allowed to build up for years and it will not be handled without additional restrictions. Milder sanctions might have been sufficient if it had been addressed sooner, but that ship has sailed.
Whatever is decided, you can deal with it without me. Or don't. Keep letting it fester. I'm washing my hands of it regardless. I'm done being the only person who cares. ChompyTheGogoat [ Bleat | Munched ] 23:46, 27 October 2026 (UTC)
ChompyTheGogoat, you sound dangerously close to total burnout. Maybe you're already there. Someone else will pick up that cleanup work later. Anecdotally, I've been doing copyright nonstop for 3 1/2 year straight, and then have done arbitration enforcement for 2 years straight. I am burnt out. I don't have capacity to report or handle everything even in copyright. That's okay though. I completely understand your frustrated, I have had extremely similar moments, but I am not here to be your "enemy" or to say that there's no need for action here. I'm trying to figure out what specifically needs to be targeted, whether or not any proposal here gains consensus or not. Okay, we need to get the AFC people more involved in identifying socking/UPE and escalating. That is doable. Okay, maybe we need to get RCPers using more semi-auto tools that make reporting a lot easier. EditCheck should hopefully be helping, but if it's not we need to know and the people that do this are not omnipresent and not high in number. There's a lot of people here that are interested in stopping disruption and frequently work arb enforcement, so you're speaking to people that do not have experience in this specific topic. I don't do AFC. I don't do SPI, and a lot of my wiki-friends are SPI but only think of it from the UPE and socking perspective. None of us are saying that there isn't an issue. The people that are familiar here are administratively conflicted out in a lot of ways, or don't want to open themselves up to the very real risk of harassment. We are asking in good faith because we want to know what we can do in the meantime. We're aware of the issues now, we can do something about it.
WP:CT/SA covers all of South Asia, broadly construed. It covers Indian cinema. What you're experiencing is the very real reality in that CTOP enforcement is incredibly stretched thin and simply do not patrol that topic enough. I don't appreciate All of those other editors were content to drop drive-by templates and move on without actually addressing the problem - and it's far from the only case.'s lack of good faith, so I really do ask that you step back before you say anything you regret. I get the burnout. I really do. I have spent a lot of time arguing with people that they can't add copyright violations back. But it doesn't give you the right to take that frustration out on others, and not on people that aren't familiar with the issue because that isn't their expertise or interest. It's the reality of wiki work that we have different things, and that we get burnt out and frustrated, but we have to emphasize and understand each other despite that. Sennecaster (Chat) 03:57, 28 October 2026 (UTC)
Horse, barn door. I tried giving myself a break by working on another topic area that I'm passionate about and got accused of LLM use after spending hours hand writing an entire article, so when I say I'm done, I'm done. It really doesn't matter what other editors think of me at this point.
Someone else will pick up that cleanup work later. If that was true we wouldn't be in this situation in the first place. Editors have spent years ignoring the problem, as Jeske said below. And when I said All of those other editors were content to drop drive-by templates and move on without actually addressing the problem that is literally what happened. Eighteen editors dropped templates and ran, without looking at the pile that had already gone unanswered or bothering to file at any noticeboards. For years. That is a fact, not hyperbole. It is not the only such case that I've filed. So yeah, when the people who have no experience in this subject area still think they're qualified to drop a !vote claiming we don't need to make any substantial changes, I take issue with it (and yes, some are saying that). They're free to abstain if they don't have the relevant experience to give an informed opinion. I also have no prior experience or interest in the topic. I stumbled across it and saw a problem that no one else was stepping up to deal with, so I did. Or at least tried. And it's no wonder no one wants to do it. It's incredibly thankless work - it's one thing getting harassed by the POV pushers that are causing the problem, and quite another when other experienced editors patrolling noticeboards are more worried about the formatting of my reports than the actual problem I'm reporting. You want to know why people are hesitant to report? That's why. Too much infighting and pedantry; not enough concern for the actual damage being done to the project. I'm highly disappointed in this community overall, and with AI hoards at the walls - now including fully autonomous agents - I don't think you'll be able to hold out for long while competent editors are being chased off. Even veteran editors of 20+ years are giving up in frustration, and I can understand why. Guess I waited too long to sign up. ChompyTheGogoat [ Bleat | Munched ] 05:04, 28 October 2026 (UTC)
I understand you're frustrated, but it's very likely that some of those 18 editors have their own overwhelming backlogs of work. Like with me for example, I almost definitely have flagged some Indian cinema articles for AI (if there is AI) instead of dropping everything to go fix it, because I am currently about 200 tabs deep in other unfinished AI cleanup and I do not have the time. There are a finite amount of hours in the day.
And if you mean userpage warnings, what more exactly are people supposed to do? Stand outside their window with a boombox? You can't force someone to change their behavior. Gnomingstuff (talk) 02:58, 29 October 2026 (UTC)
I think the point Chompy's making is that that's exactly why we need restrictions in this topic area. People obviously don't have the time or interest to dedicate to cleaning up this topic area, reporting editors and pages for arbitration remedies, etc. It's not that any of those 18 editors should've dropped what they were doing and solved the problem themselves, it's just that if we don't have the interested and able editor-power to do it, then we need another solution. Athanelar (talk) 03:10, 29 October 2026 (UTC)
Yes, the warnings. That's why we have noticeboards. Sanctions are a thing. Most of the ones I've taken the time to report do get blocked, and there would be much less disruption if others had bothered to do so sooner. The time it takes to file said reports is far less than the cleanup that's now needed for all those thousands of edits. I refuse to believe that all 18 editors (and all of the others who dropped additional messages there, or other warnings on other editors) were so very busy in that exact moment that they couldn't possibly take the time to compile a few diffs. Other types of disruption in other subject areas get addressed far more quickly.
So, if people aren't willing to address the huge number of problematic editors on a case by case basis, we instead need sweeping restrictions that will stop the vast majority of them, even if a few good faith also get caught up in the net. Page protections are one of the best tools we have for preventing ongoing distribution with minimal effort, and the sooner they can be applied in subject areas that are rife with these issues the less needs to be fixed. ChompyTheGogoat [ Bleat | Munched ] 03:37, 29 October 2026 (UTC)
From what I recall off the top of my head, cinema-related articles only show up at AE if they implicate Indian politics, caste, or history (as those are the ones that tend to draw the fiercest nationalistic responses). Otherwise, it's closer to what Chompy says - nobody gives a rat's ass about that specific topic area other than the mercenary editors and the naive newcomers, and I suspect part of the problem is that outside of India few have much interest in Indian cinema and those that do don't want to deal with the unusually-insistent mercenaries and true-fan types that populate the topic area. —Jéské Couriano v^_^v Thriller Night! 02:12, 28 October 2026 (UTC)
Yep - even with ECR it'll take some dedicated editors with no vested interest who are willing to roll up their sleeves for the overall integrity of the project to really get a handle on things. I think once the current swarms who feel like they have free rein to insert whatever they feel like realize that won't fly anymore things will simmer down and be easier to maintain - but that works needs to happen first or it will just continue to snowball. Good luck. ChompyTheGogoat [ Bleat | Munched ] 05:09, 28 October 2026 (UTC)
Hence my linking catch-22 above. I think it's safe to say the issues are threefold:
  1. Nobody with experience is familiar enough with Indian culture and how it interacts with cinema, especially where caste is involved. This makes them incompetent, through barely any fault of their own, to actually edit in and administer the topic area. Those who are knowledgeable about the subject matter are vastly outnumbered and overwhelmed.
  2. Few/none of the new users entering the area are willing or able to treat Wikipedia as anything more than an extension of Indian media, and almost all of them either have a conflict of interest or are true believers.
  3. The topic area is in an intractible ethnopolitical hellhole CTOP and tends to be connected to two potent third rails in that hellhole (caste and politics). This makes experienced users even more reluctant to touch the topic area and sets up new users for failure (CTs are the worst places to learn to edit; the intractible ethnopolitical hellholes especially so).
The ways to fix this would require, at a minimum, ECR in the immediate term. This is a very similar blend to the situation that caused WP:ARBPIA3 to happen. Once that is set up, and the firehose of edits to the area is slowed to a more manageable amount, there needs to be a community-wide effort to assess the articles for neutrality and COI concerns, with anything failing the test being sent to AfD if they cannot be improved. Anyone trying to disrupt this with nationalist, LLM, or COI bullshit needs to be at minimum topic-banned from the cinema topic area. Anyone evading these bans needs to be indef'd and restricted to one account, if that is possible as a discretionary sanction. (For anyone thinking about what precedent I'm looking at, SCI and MM are moreso what I'm looking at than any of the 17 PIA cases.) If this disruption continues despite everything, haul the mess to ArbCom, with an eye primarily towards amending CT/SA to make ECR de jure in the topic area indefinitely. —Jéské Couriano v^_^v Thriller Night! 06:52, 28 October 2026 (UTC)
@Jéské Couriano; I appreciate the clarification. Unfortunately, my experience over at CCI tells me that community cleanup efforts are vastly outpaced by the pace of crap added or the size of things to review without serious political and social capital. Doug Coldwell's whole pile of crap GAs isn't even fully cleaned up yet. A lot of what you're saying about CT restrictions, but we have a critical lack of capacity that is making everything worse. Treating admins poorly will not help the issue (I'm not accusing anyone, but it is a fear expressed to me). I just don't know what we can do that doesn't amount to "bully administrators into doing things they actively resent doing", since we have always been hesitant to elect admins focused heavily in "experienced user conduct" (a phrase from my own RFA).
As for cleanup: Chunking down Indian cinema to specific subtopics (ie. telugu films, marathi TV) with aggressive presumptive removals would lead to less reviewer/community burnout. It could also be turned into an editathon or drive. This level that's being described means that something much more drastic than a methodical combing and AFD can resolve without exhausting significant portions of the community. Despite my criticisms and counter-suggestions, there's a lot of good ideas here, and I think I know some things that I can angle people with more capacity than myself to get started on regardless of the outcome here. I myself am not experienced enough with background conflicts to admin fully in CT/SA, like you've described. I can handle blatant POV pushing and caste warring, but I've had to call in help from multiple sources both wiki editors and not to even begin on trickier reports. It's an issue and the more that you know here, the more you're likely to end up WP:INVOLVED. Sennecaster (Chat) 22:55, 28 October 2026 (UTC)
I would imagine the scope of the issue would more or less mandate that the subtopic be further broken up into further subtopics in order to actually deal with it. "Indian cinema" is the sort of overly-large topic area that ArbCom themselves comments about at WP:ARBIMH#Breadth of topic bans, and experiences with one subset of it don't necessarily translate well to other subsets (h/t Athanelar). The editathon/drive idea would certainly help as well (to get out in front of "how about AFI?", that to me seems more of a mixed bag, but it'd be worth a try for some of the lesser-known articles in the area that haven't drawn mercs or zealots), but this would fall into the same issue of anyone not "read in" being driven off by mercenaries and "true fans". Hence I think there would need to be an ECR in order for us to even entertain any such cleanup. The other alternative is going scorched-earth on users in the topic area to get rid of the UPEs, and that's counter-productive and would be a waste of admin time even if it weren't. —Jéské Couriano v^_^v Thriller Night! 00:39, 29 October 2026 (UTC)
I was thinking that setting up a tracker within the task force page could be helpful with cleanup - after restrictions are in place, because people will absolutely get driven off if they attempt it now (hi). Having a system to mark what's been reviewed, tagged, nominated for deletion, etc would help give a visual representation of progress and motivate people because they could see that even small contributions can move the needle. Maybe a bot could move pages through in batches to address the backlog in a format that feels manageable. ChompyTheGogoat [ Bleat | Munched ] 01:02, 29 October 2026 (UTC)
That would help, but the overall scope is the bugbear here. Going through it one subtopic at a time is still going to be the best way to handle this. This is an issue that has been festering for years; a quick fix at this point is unrealistic. —Jéské Couriano v^_^v Thriller Night! 01:44, 29 October 2026 (UTC)
Oh, I know. That's just one idea that could potentially help with working through content. Restrictions and above all willing editors are necessary if any progress is going to be made at all. ChompyTheGogoat [ Bleat | Munched ] 02:59, 29 October 2026 (UTC)

Template rejection for AI-generated unblock req

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.


As title. We should create a template e.g., {{unblock-ai}} and {{ubai}} to host a standardized, ice cold rejection text where
admins may use at their discretion had they decided an unblock request is not worth their time. 海盐沙冰 / aka irisChronomia / Talk / Uploads 07:28, 20 October 2026 (UTC)

Intended as a solution to SPAs and UPEs that makes no effort to contribute to the Wikipedia in any way. Since they're lazy, I don't see why we should cushion them with a human-written denial message. 海盐沙冰 / aka irisChronomia / Talk / Uploads 07:30, 20 October 2026 (UTC)
I often wonder if using a LLM to write an unblock appeal should an instant removal of TPA on rejection. FMecha (to talk|to see log) 13:10, 21 October 2026 (UTC)
For a second offence, possibly, and certainly not if they've never been informed of our LLM-related policies. Thryduulf (talk) 13:20, 21 October 2026 (UTC)
We actually have one: {{Decline-ai}}, which produces:

This unblock request appears to have been written by a chatbot using a large language model. The purpose of unblock requests is to determine whether you, the human operating this account, understand why you were blocked – not to test a chatbot's ability to tell us what we want to hear. A message written or rewritten by a chatbot can also cause you to sound like you're making empty promises. It is better to write the unblock request yourself. Please read through the guide to appealing blocks for more help.

OutsideNormality (talk) 19:44, 20 October 2026 (UTC)
Green tickY I see! I've seen that response quite often and didn't realize it was a template. Let's close this thread, then. 海盐沙冰 / aka irisChronomia / Talk / Uploads 06:41, 22 October 2026 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

RFC for Dog

I started an RFC at Talk:Dog#RFC on lead image. Please join in the discussion. Wolverine X-eye (talk) 10:30, 24 October 2026 (UTC)

Add Wikipedia:sandbox (WP:TEST) to Main Page, Main menu, or Page Tools

The sandbox is so hidden and useful to me when I was a newcomer for learning how to use Wikipedia. I think Wikipedia can create at least a link or a button for sandbox at an obvious spot or at least somewhere. ~2026-56952-03 (talk) 11:05, 24 October 2026 (UTC)

Looking at the main page in Vector2022 (the default skin) I agree there is no clear link to any sandbox, registered editors do see a link to their personal sandbox but it's in a dropdown menu behind a non-intuitive icon (in my preferred monobook skin there is a prominent link to your personal sandbox at the top of the page), and in the sidebar a semi-prominent "Learn to edit" link to Help:Introduction, but again no link to a sandbox. Now I'm aware of this, it does seem like an omission. Thryduulf (talk) 20:04, 24 October 2026 (UTC)
English Wikipedia HomePage 2001-02-19
the missing sandbox was a thing tho, rip ~2026-56947-61 (talk) 22:33, 24 October 2026 (UTC)
I like the idea of making the sandbox highly visible to readers, probably on the main page. Let them play with the editor in a safe environment. Though I wonder how it would handle a significant increase in traffic and edits. Thebiguglyalien (talk) 02:13, 26 October 2026 (UTC)
This is a good idea. Maybe the Sandbox could be linked inside of {{Article for improvement}} like this:

You can be bold and start editing the article. Have questions or suggestions? Visit the article's talk page, or post at the Teahouse for general discussion, or practice editing in the Sandbox.

mdm.bla 17:52, 26 October 2026 (UTC)
Notified: Wikipedia talk:Articles for improvement. mdm.bla 17:59, 26 October 2026 (UTC)
If there is agreement on giving greater prominence to a sandbox, I think the user's sandbox would be better. It would avoid conflicts with other editors, not get reset periodically, and perhaps (with a bit more guidance) help new users learn about user subpages. isaacl (talk) 19:12, 26 October 2026 (UTC)
Agreed, though beware that Special:MyPage/Sandbox redirects logged-out users to the login page rather than a usable sandbox. Certes (talk) 19:35, 26 October 2026 (UTC)
this would be a good idea, but it wouldn't work for users without an account. temporary accounts work, but you need to edit a page first to make one - perhaps we could switch the link for users with an account? Rexo (talk | contributions) 19:53, 26 October 2026 (UTC)
This could be solved by linking to the sandbox using the following text: {{If IP|1=[[Wikipedia:Sandbox|Sandbox]]|2=[[Special:MyPage/sandbox|Sandbox]]}}. This template renders as SandboxSandbox and links to your sandbox if logged in, and the global sandbox if logged out/TA. mdm.bla 20:17, 26 October 2026 (UTC)
So as to not confuse people, I think it should say "your personal sandbox" for logged in users. ScienceD90 (she/her) (talk) 02:33, 27 October 2026 (UTC)
That sounds like the best way to link it! Not as sure about tying it to TWAFI (which also restricts it to just the Main Page, which some users might not visit, instead of a more accessible sidebar), but that still makes sense. Chaotic Enby (in solidarity · talk · contribs) 18:02, 27 October 2026 (UTC)
This seems like the most logical place for a link to the sandbox. – The Grid (talk) 19:26, 26 October 2026 (UTC)

On a DYK article's Talk page, remove the Do not modify this page notice from the Talk page's DYK Nomination section

note: to see an example of the current state of what causes the problem

  1. Go to the Wikipedia Main Page.
  2. Select any of the articles in today's DYK list.
  3. Look at that article's own Talk page.

This numbered sequence of successive events illustrates how the problem happens:

  1. An article is nominated to be included on the Wikipedia Main Page article list Did You Know...?
  2. The article has a Talk page (Talk_A).
  3. In a different place, there is a DYK Nomination discussion of the article.
  4. The DYK Nomination discussion (Talk_N) ends.
  5. Talk_N receives a header that says Do not modify this page (intended to prevent the modification of Talk_N).
  6. Talk_N is reproduced as a section on Talk_A.
  7. Now, Talk_A has a section that says Do not modify this page (intended to prevent the modification of Talk_N).
  8. Eventually, Talk_A needs to be modified.
  9. A user (User_A) who needs to modify Talk_A sees a section of Talk_A (described in 6. above) that says Do not modify this page (intended to prevent the modification of Talk_N).
  10. User_A understands this prohibition (against the modification of Talk_N) to mean that modification of Talk_A is forbidden.
  11. User_A leaves Talk_A unmodified for the sake of obeying the directive that had forbidden modification of Talk_N.
  12. A confusing message has prevented User_A from accomplishing Wikipedia's mission; this is a serious problem.

Let's fix this problem! —catsmoke talk 05:18, 27 October 2026 (UTC)

@Catsmoke I made this edit to {{DYK top}} so that on talk pages it will say "Do not modify this section" instead of "this page". That won't fix existing pages, but it should fix it for ones created in the future. A bot task would be needed to fix existing ones by running through the 78,000 subpages at Special:PrefixIndex/Template:Did_you_know_nominations/ and replacing page with {{talk other|section|page}} -- you can request one at WP:BOTREQ. --Ahecht (TALK
PAGE
)
17:16, 27 October 2026 (UTC)
I feel kind of weary transcluding {{talk other}} so many times. Couldn't this be achieved with <noinclude> tags? Axolitl (talk | contribs) 23:43, 27 October 2026 (UTC)
Or alternatively, something like "Please don't modify the nomination"? Axolitl (talk | contribs) 23:45, 27 October 2026 (UTC)

Apple

I belive that searching up "Apple" should take you do a disambiguation page, showing both Apple Inc. and Apple, as in the fruit. Both are very common topics, and I belive neither should have a primary position.


Yes, Apple has trillions of dollars. But, the fruit is often more common in daily conversation. ThejimsterF (talk) 08:59, 27 October 2026 (UTC)

ThejimsterF Nothing wrong with coming here, but this is probably best discussed at Talk:Apple. I'd suggest that you review the several prior discussions on this very topic(linked to at the top of the talk page) before proceeding with such a discussion. 331dot (talk) 09:09, 27 October 2026 (UTC)
Per the Q&A on the Apple talk page, "In at least 6 move discussions (see the list below) on this page, Wikipedia editors have determined that the fruit is the primary topic, so disambiguation is not required.". So it seems like this has been discussed and settled. I'm not sure how long it's been though, or if circumstances have changed. I can do stuff! (talk) 21:16, 28 October 2026 (UTC)

I propose temporarily changing the Wikipedia logo for the 25th anniversary to be the one shown above. As you can see on this page, it is an unofficial logo for the 25th anniversary.

The actual website has a different logo, which only has the wordmark and a puzzle piece with "25" written above it.

The reason is that the logo is very iconic and should be kept. It symbolizes what the standard globe already symbolizes (the diversity and evolution of Wikipedia), but it also acknowledges the 25 years of Wikipedia's existence.

Some language versions like the German Wikipedia use a similar logo.

This is temporary (until January 15th, 2027), only affects the English Wikipedia, and would replace the current wordmark logo. Koubaki (talk) 14:57, 27 October 2026 (UTC)

We've already changed it to wikipedia-wordmark-en-25.svg in the vector2022 (desktop default) and minerva (mobile default) skins and the exact logo you posted in the vector2010 (desktop default prior to 2022) skin. This is consistent with vector2022 and minerva using the wordmark in place of the globe logo. --Ahecht (TALK
PAGE
)
16:41, 27 October 2026 (UTC)
As you can see here on Vector 2022 before the 25th anniversary there was a globe. Koubaki (talk) 19:21, 27 October 2026 (UTC)
I believe we went with the horizontal wordmark as it was one of the default options created by the WMF. It allows the tagline to stretch along the entire image. de.wiki gets lucky because its tagline doesn't need "of the". CMD (talk) 22:42, 27 October 2026 (UTC)
That's probably why the logo I'm proposing uses "Celebrating 25 years" as its tagline. Koubaki (talk) 10:13, 28 October 2026 (UTC)