Wikipedia:Village pump (proposals)

 Policy Technical Proposals Idea lab WMF Miscellaneous 

• Table of contents
• First discussion
• Jump to bottom
• New topic
• All village pumps

"WP:PROPOSE" redirects here. For proposing article deletion, see Wikipedia:Proposed deletion and Wikipedia:Deletion process.

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.
• 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 belong at Village pump (WMF).
• Software changes which have consensus should be filed at Phabricator.

Discussions are automatically archived after remaining inactive for 7 days.

« Archives, 213, 214, 215, 216, 217, 218, 219, 220, 221, 222, 223, 224, 225, 226, 227, 228, 229, 230, 231, 232, 233

RfC: Name of the "Discussion" button

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)

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)

Enabling iFrame graphics from Our World in Data on English Wikipedia

Moved from Wikipedia:Village pump (technical) § Enabling iFrame graphics from Our World in Data on English Wikipedia

 – per talk there

Hi all I’m posting this on behalf of Booksmurf, Doc_James and myself.  We would like to try and get a consensus on whether to enable iframes from Our World in Data, specifically allowing MDWiki:WikiProjectMed:OWID_popup to be run on English Wikipedia. showing a static image from Commons which becomes an interactive graph once clicked on and a reader agrees to the consent pop up. Below we have put together a summary of the background information but in short the system has passed a security review from the WMF and is currently being used on Basque and Spanish Wikipedia. Just to make clear, this isn’t a discussion on using iFrames from any source, only from Our World in Data.

Context

About Our World in Data

Our World in Data is a project run by the UK charity Global Change Data Lab, which is attached to the Oxford Martin Programme on Global Development at the University of Oxford, They produce over 2,000 interactive charts and data tools on a very wide range of topics under CC BY-SA licenses. They collate data from the UN, governments, and other reliable sources. Several people within the community, affiliates and WMF, have connections with the OWID team. In addition the Head of Engineering at Our World in Data took part in the last discussion about this topic (links below).

Development history

1. The OWID gadget was created by Wiki Projtec Med.
2. There was a pilot rollout on Basque and Spanish Wikipedia in April 2024, which the WMF paused shortly after to address concerns raised at the time.
3. An interim process was created to show images from OWID on Wikipedia, which relies on thousands of files on Commons and many kinds of images are not possible to visualise on Wikipedia using this method.
4. There was a security review where WMF security assessed the risk as low.
5. A Memorandum of Understanding (MOU) was put in place between WMF and Our World in Data in July 2025 covering how projects may incorporate this visualization method.
6. Implementation on Wikipedia
   1. The OWID iframe has been enabled on Spanish and Basque Wikipedia under the July 2025 MOU.
   2. The method includes a one-time consent prompt: the iframe content is not loaded until a reader actively interacts with the gadget (e.g. presses "play").

Example graphics

Below we provide examples of the kinds of graphics OWID produces. These graphics were created using the current, more difficult process, which can only visualise some kinds of graphic OWID produces. The iframes however allow using many types of interactive content that the all Commons approach does not support. there are two options for what to display:

1. Current: A current version of the graphic that will remain synced with the latest version on the OWID website
2. Snapshot: Allows users to choose a specific versions of the graph from a specific time period

Literacy rates

Annual co2 emissions per country

Asthma prevalence

Some examples of the kinds of graphics that currently can’t be shown using the older method but could be shown using this proposed method are shown here on the Wikiproject Med Wiki.

Summary of discussion

Previous discussions

There have been three previous discussions on the English Village Pump, none of which reached consensus but a lot of technical issues were discussed and resolved.

1. August 2025 (concerns raised)
2. November 2025 (no engagement)
3. April 2026 (overall support)

Impact (enabling iFrame graphics from Our World in Data)

There was consensus that the tool would be very useful for showing visualisations of data. Editors and affiliates who work with external data-holding organisations (UN agencies, governments, NGOs) noted that the existing options for getting institutional data onto Wikipedia ( manually uploading static images to Commons, or attempting to route data through Wikidata) do not scale and are error-prone.

There was consensus that the tool would be very useful for showing visualisations of data — and the case for it is stronger than a simple feature request. A few things make this approach powerful rather than just convenient:

• It fills a longstanding gap. Editors have wanted interactive data visualisations for years, but MediaWiki has no native way to render them — Wikipedia has always been limited to static images (SVGs, PNGs). This is a persistent capability gap, not a new ask. Using static images from Commons means that there is significant and often undone work to keep the graphics up to date on Wikipedia when new versions are released. The OWID graphics using the Commons approach do not fill this gap because they an only render a limited number of OWID graphics
• The content is built and maintained by a partner who already specialises in data visualisation. OWID already produces and maintains 2,000+ interactive charts as its core mission, with dedicated engineering resources behind them. Wikipedia doesn't need to build or maintain any visualisation tooling itself — it only needs to display what OWID already keeps current. That's a fundamentally different cost structure from the Commons or Wikidata routes, where volunteers have to do the ongoing maintenance work by hand (see John's reply below for a detailed account of why those routes don't scale).
• The usual iFrame risk profile doesn't map cleanly onto this case. The standard objection to embedding iframes is that you're pulling in content from an unvetted, potentially unreliable third party with no accountability. That's not the situation here: this isn't a general allowance for arbitrary third-party iframes, it's a single, named non-profit partner, vetted through a WMF security review, and governed by a signed MOU that constrains what they can do with any data collected through the embed. The generic risks of "working with iframes" — foreign control of content, uncertain data handling, no recourse if something goes wrong — are mitigated specifically because there is a formal governance relationship in place, not because iframes are inherently safe.

Put together: this is a capability the community has wanted, it comes at very low build/maintenance cost to Wikipedia, and the usual reason to be cautious about embedding someone else's content doesn't really apply here, because OWID isn't "a third party" in the open-ended sense — it's a defined, agreed-upon partner.

Security discussion

WMF security assessed the overall security risk as low.

Summary of concerns

The main concerns raised in the August 2025 discussion centred on two related issues:

• Loss of local control: an iframe embeds content that Wikipedia projects cannot version, vet, or revert the way they can wikitext or hosted media, since it is served live from an external domain (OWID) rather than from WMF infrastructure.
• Reader privacy / IP exposure: loading the embedded graph causes the reader's browser to contact OWID's servers directly, exposing their IP address to a third party.

Summary of mitigations

The mitigations put in place, and discussed by the community, include:

• A Memorandum of Understanding (MOU) between the WMF and Our World in Data, agreed in July 2025, governing how OWID may (or may not) use data collected through the embed. The exact terms of the MOU have not been made public to editors.
• A consent pop-up shown the first time a reader triggers the gadget on a page — nothing loads from OWID until the reader explicitly agrees.
• Browser storage partitioning (e.g. in Chrome), which limits OWID's ability to correlate a given visitor's iframe activity with their activity elsewhere on the web — noted as a partial mitigation rather than a complete guarantee, since it depends on the reader's browser.
• Version control: OWID has built the ability for us to link to a specific archived version of the content rather than the most recent live version. Therefore we have some version control.

Thanks for your time

John Cummings (talk) 16:04, 16 September 2026 (UTC)

Discussion (enabling iFrame graphics from Our World in Data)

Support/Oppose (enabling iFrame graphics from Our World in Data)

• Support: Personally I think having this would be extremely valuable, I work in the UN system, helping different agencies share their knowledge and content on Wikipedia. I think my experience is fairly representative of other people I know working with other large institutions. A lot of UN and other Intergovernmental Organization data is shared on Our World in Data.

Before this opportunity there were three options for sharing data visualisations and none worked very well at all and basically weren’t scalable:

1. Sharing graphics on Commons: I do this for a lot of my work and its extremely time consuming to agree licenses, someone has to update the graphics on Commons and exchange them on all versions of Wikipedia, its a huge amount of work and isn’t scalable.
2. Visualise using data from Wikidata: as far as I know no UN agency is willing to share under CC0 and is very unlikely to change this policy. Visualising from Wikidata onto Wikipedia is very complicated and is also risky for the organisation since on Wikipedia it can say the data is coming from an organisation but then anyone can change a value on Wikidata and this isn’t true any more. Also extremely time consuming to keep updated.
3. Use the old OWID in data approach: This approach has over 1.7 million+ svg files, its extremely complicated and fiddly, I’ve read the instructions several times and cannot make it work. I do not think its a realistic option for a long term widely adopted approach.

If this is approved I would like to spend time on improving the documentation and encouraging UN agencies to make sure their data is up to date in OWID

Thanks again

John Cummings (talk) 16:07, 16 September 2026 (UTC)

• Support: This will allow us to use more complicated interactive graphs that are not supported via the current all Commons approach. The current methods also do not support at all or support well, the larger interactive graphs pertaining to COVID. Just to many SVGs I think. Doc James (talk · contribs · email) 17:20, 16 September 2026 (UTC)
• Support: This is a great idea! Interactivity makes this vastly more useful than a static image. Wikipedia really needs things like this to keep people visiting articles instead of just reading summaries. I really hope it gets approved! NavinoEvans (talk) — Preceding undated comment added 11:53, 17 September 2026 (UTC)

Yearly healthcare expenditure per person (total public and private). See file page.

• Support: Go to Commons:Help:Interactive data graphics by Our World in Data for info on what exists now, the OWID slider. The iFrame version that is proposed is much better, provides much more info, and is much easier to maintain. Go to any OWID interactive graphic at the source, and compare it to the current OWID slider to see what I mean. For example, OWID source versus the OWID slider to the right. --Timeshifter (talk) 12:54, 17 September 2026 (UTC)
• Support: As per above. Battleofalma (talk) 09:19, 18 September 2026 (UTC)
• Support: The functionality described above has multiple practical uses that would benefit open knowledge sharing. EriedgenArc (talk) 08:34, 19 September 2026 (UTC)
• Support Looks reasonable and beneficial. -- GreenC 16:15, 19 September 2026 (UTC)
• Support: The more ways ze can visualise data the better! Octavosaurus (talk)
• support - we know our readers want more readily accessible graphics, especially since sharing knowledge becomes more image focussed due to social media, so I see lots of readership benefits Lajmmoore (talk) 16:00, 22 September 2026 (UTC)

• Oppose. Have to say this every time this up: I am not interested in giving up our presentational autonomy to OWID. The information we share must be something we can change locally (or within our sphere of influence). OWID is not.

  And again, please ensure this kind of request is advertised at a place where people don't just care about bugs and misbehaviors. It is exceedingly obnoxious that it keeps coming up at VPT, which is a place for technical problems, and not at WP:VPR. Izno (talk) 16:10, 22 September 2026 (UTC)

• Support as an interim solution: Ideally, the data would be in a .json file on Commons and these map/timeline visualisations would be an option in the Chart extension, giving us automatically-generated interactive images that are redistributable. Then again, we know that the relevant software development on MediaWiki can take years and still be unreliable. The ideal shouldn't be the enemy of the good. If we can have multi-dimensional visualisations relating to health, development, and economics, that are easier to take in than lots of images, and if the right protections are in place for user data, then we should. MartinPoulter (talk) 09:34, 23 September 2026 (UTC)
• Oppose per Izno. VPT is not the correct venue for this, and it being brought up here unstead of the correct venue should invalidate the proposal. - The Bushranger _{One ping only} 22:08, 23 September 2026 (UTC)

  The Bushranger, the proposal has now been moved to the Village pump {proposals) space. Thanks to Timeshifter for moving it. To the best of my knowledge there is no policy to 'invalidate' a proposal if it is initially proposed in a different place. John Cummings (talk) 19:16, 24 September 2026 (UTC)

  You are correct!​ FaviFake (talk) 23:57, 27 September 2026 (UTC)

• Support. This is a step in the right direction. Alaexis_¿question? 13:26, 24 September 2026 (UTC)
• Support I support either and both pulling data directly from OWID or copying/migrating their datasets to the Wikimedia ecosystem and generating this content from here. I get the concern and opposition that this is the first time we are pulling in non-Wikimedia data to serve to readers in Wikimedia platforms. However, I trust OWID as a mission-aligned project to Wikimedia, and also I think that it is critical now that we develop our infrastructure for processing datasets. A major part of the pressure on us is that we lack the infrastructure to host the datasets in the Wikimedia platform; or at least, our data visualization infrastructure is inaccessible and not being used. We need to quickly gain capacity to serve interactive data visualizations. We should accelerate this process, and go beyond OWID to bring in open government datasets into the wiki ecosystem. Now is not the time to make all editorial decisions about what data we want and what data we do not, but as for OWID datasets, yes, we want all of these. Bluerasberry (talk) 18:34, 24 September 2026 (UTC)
• Support - After balancing the benefit to readers (informative, quality data) vs the drawbacks (lack of control of underlying data), this seems like a good idea, because the maps are exceedingly useful. The primary concern seems to be lack of data control (or ability to specify a particular historical version). But WP already permits external data to be linked directly from WP articles, e.g. with template {{External media}}. It is not a black-and-white choice, a balancing is required. Noleander (talk) 12:25, 25 September 2026 (UTC)

  OWID has provided us the ability to link to specific historical versions if we wish. Or the ability to link to the most recent version. Doc James (talk · contribs · email) 14:29, 25 September 2026 (UTC)

  Just to make clear for Noleander, when we say 'the most recent version', this is a live version from the OWID website that is automatically updated when OWID collects new data from the data provider. John Cummings (talk) 21:33, 25 September 2026 (UTC)

• Oppose The community has regularly, and correctly, in my opinion, opposed efforts to make more widespread use of Wikidata because of the complications and confusion that causes for editors and because of the differing standards and practices that exist between the two projects. The exact same arguments and issues apply here. Further, I am flabbergasted that we spent so much time and effort to ensure that the IP addresses of unregistered editors are no longer visible to most editors and we're not suggesting that a third party be given access to the IP addresses of countless editors. Finally, the current implementation has significant UI issues e.g., clicking the "play" button suddenly and unexpectedly makes the video much larger instead of just playing the video/animation as expected. ElKevbo (talk) 13:25, 26 September 2026 (UTC)
• Support i am convinced of what Bluerasberry is proposing. Hence per Bluerasberry i support too. Accesscrawl (talk) 17:38, 26 September 2026 (UTC)
• Support should be allowed on a case by case basis, doesn't have the same vandalism issues as Wikidata. (t · c) buIdhe 17:46, 27 September 2026 (UTC)

  Thanks Buidhe, this is something I should have brought up in my support. If we say to the agencies which produce the data we can share it on Wikidata but anyone can change it at any time, so they need to monitor it, this isn't a very interesting proposition for them. John Cummings (talk) 09:40, 28 September 2026 (UTC)

• Support – This is a good idea! Wikipedia has way too many static images when interactive elements are much better. We're WP:NOTPAPER, after all. FaviFake (talk) 23:58, 27 September 2026 (UTC)
• Support - we are not obligated to use these images, and as long as we can freeze the data to a particular time if we want to and OWID isn't radically changing their UI constantly, editors retain control of the presentation in just the same way as we would using freely-licensed images created by someone else. Wikipedia (for understandable reasons) does very poorly with giving readers images and other visualizations; this would help at least within its area of concern. Rusalkii (talk) 00:02, 28 September 2026 (UTC)
• Support Interactive graphics will better serve readers; it's reasonable to want full control over how data is displayed, but the utility of OWID graphics would significantly improve articles. 🏰 Richard Nevell (talk) 21:39, 30 September 2026 (UTC)

Discussion and questions (enabling iFrame graphics from Our World in Data)

• "link to a specific archived version": if you do that, you are right back to the volunteers-have-to-update-manually problem that you seemed to be trying to solve. You can link straight to the OWID, and always get the latest version, no manual updating; or you can go for versioning, in which case the approach isn't solving the problem. You surely can't do both. Best would be to extract the version ID from the (current) OWID ... if it's there: if not, persuade them to provide it ... and not try to do manual version updates. Chiswick Chap (talk) 17:54, 16 September 2026 (UTC)

  Editors can choose which version they want. I would generally go with the most recent version, agree. But even if one goes with an archived version, it is just the one instance that needs updating, not the 100s or 1000s of underlying files. Doc James (talk · contribs · email) 18:08, 16 September 2026 (UTC)

  Hi Chiswick Chap, I'm sorry for the misunderstanding, I've put a few lines in the summary above to explain that there are two options, one to have a live version of the graphic that stays synced to OWID and one to have a specific snapshot of the graphic. John Cummings (talk) 08:51, 17 September 2026 (UTC)

  Oh good. Thanks for explaining. Chiswick Chap (talk) 12:19, 17 September 2026 (UTC)

  No problem Chiswick Chap, let us know if you have any other questions and please consider supporting the request :) John Cummings (talk) 22:07, 17 September 2026 (UTC)

• In addition to the "return to article" button at the bottom, I would like to see an X in the upper right corner to close the pop-up window. The bottom button wasn't very obvious to me, since it filling the entire width of the page has a bit of a dark pattern effect since it looks like a footer and not a button. Having an ✕ or Ⓧ in the upper right has become the standard for pop-ups, pop-ins, and modal dialogues across the web such as cookie notices, privacy policies, "special offers", newsletter signups, and even our own MediaViewer. --Ahecht (TALK
  PAGE) 18:48, 17 September 2026 (UTC)

  Sure, we can definitely add that to both methods. Doc James (talk · contribs · email) 22:02, 17 September 2026 (UTC)

• Comment: Shouldn't this discussion be held on VPP? VPT is usually limited to technical issues, questions, and answers, and does not usually hold RFCs or proposals. – Jonesey95 (talk) 20:21, 16 September 2026 (UTC)
  • Thanks Jonesey95, I wasn't sure where to put it, its a technical request so I guessed the best place was here. Do you know where any rules for this are? Also do you know if there is a process to move a conversation or is it just a case of copy and pasting the whole thing? John Cummings (talk) 21:57, 16 September 2026 (UTC)
    • Yeah, we should probably have a line at the top of this page that says something about RFCs and proposals generally belonging at VPP. – Jonesey95 (talk) 00:00, 17 September 2026 (UTC)
• Are these meant to work well on mobile? The CO2 one basically crashes the browser page, I'm guessing bots data set is to large for my phone to handle. It's fine if it doesn't work, but it should fail more gracefully. -- LCU ActivelyDisinterested «@» °∆t° 00:38, 26 September 2026 (UTC)

  Works for me… but the new approach should work better on mobile Doc James (talk · contribs · email) 05:17, 26 September 2026 (UTC)

• @John Cummings, I'd recommend viewing this in night mode, where the text is incredibly hard to read. Any ideas for how to address this accessibility issue? Axolitl (talk | contribs) 01:35, 26 September 2026 (UTC)

  The iframe should address this Doc James (talk · contribs · email) 05:21, 26 September 2026 (UTC)

  This actually only affects Minerva dark mode AFAICT, not Vector. Axolitl (talk | contribs) 05:29, 26 September 2026 (UTC)

• I have made a request for this discussion to be looked at by an admin for resolution. John Cummings (talk) 11:21, 8 October 2026 (UTC)

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)

Tracked in Phabricator
Task T439172

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)

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 solidarity}User: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. CNC^{in 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 ^{ᚾparley$\lor$investigateᛅ} 16:33, 28 September 2026 (UTC)

• Oppose. Just let page movers move all pages. If they can't be trusted with such power, they shouldn't have it. Jessintime (talk) 16:35, 28 September 2026 (UTC)

  This is a different proposal than the once considered here. If, hypothetically, your suggestion couldn't be implemented and you were left with only two choices, would you prefer to keep the status quo or create a new protection level?​ FaviFake (talk) 16:40, 28 September 2026 (UTC)

  Taken literally that is an incredibly bad idea. Letting page movers move any page would give them the ability to "edit" (replace the contents) of any page, including interface pages, the local global js/css files, etc, pages that even regular administrators can't edit. If a page mover were then to be compromised they could then engage in significantly more disruption. msk 17:27, 28 September 2026 (UTC)

  Yeah pages that have higher-level protections should require corresponding permissions to move. Some widely-used templates also break if you move them due to accompanying css modules. We recently had an incident where an RM led to some list templates were moved, such as Template:Hlist to Template:Horizontal list, and that caused a large part of the wiki to break, including the main page, although it was fortunately swiftly fixed. That move also queued so much work for the backend jobrunners that it put enough of a strain on the backend for a WMF employee to take notice and ask that further moves be held off to let the queue be cleared.

  Knowledge of this is not something page movers are expected to have, and the potential for disruption is on the level of "you can break the website doing this". Brings to mind that video of a chimpanzee being handed an AK-47. –Maltazarian ^{ᚾparley$\lor$investigateᛅ} 18:02, 28 September 2026 (UTC)

  MSK (Monkey Shooting a Kalashnikova) msk 18:04, 28 September 2026 (UTC)

  To be honest, that should be a separate proposal. (Not to mention that allowing PMVs blanket access to the move tool might not be a good idea for the reasons mentioned by other users above.) Accessedgrant (Epicgenius mobile alt) (talk) 16:42, 6 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 ^{ᚾparley$\lor$investigateᛅ} 02:49, 30 September 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)

• Support the idea, but this could end up blocked on the technical side. I think it will require a patch to MediaWiki core, and I am not sure this idea is wiki-agnostic enough to justify adding complexity to MediaWiki core. I've made a phab comment at phab:T439172#12372365. –Novem Linguae (talk) 02:45, 29 September 2026 (UTC)

  I've rephrased the issue because of that; this will be enwiki specific. msk 02:47, 29 September 2026 (UTC)

  The technical obstacles are not as severe as I thought. It looks like this can be done in config files, without making changes to MediaWiki core, except for some translation messages to be added to mw:Extension:WikimediaMessages. –Novem Linguae (talk) 21:30, 29 September 2026 (UTC)

  Thinking about this more, could we perhaps just encourage making most move protection extendedconfirmed rather than sysop? Or is there some evidence that there are lots of cases where extendedconfirmed folks are not trustworthy enough but page movers are? –Novem Linguae (talk) 05:38, 30 September 2026 (UTC)

  Good questions. It's also been suggested here that (page mover) move protection might be applied more often if this proposal goes through. —Myceteae‍🍄‍🟫 (talk) 15:11, 30 September 2026 (UTC)

• Support. This is good idea. It would allow admins more freedom to move-protect pages and let trusted pagemovers handle more controversial moves. Protection limited to people experienced with pagemoves is fairly similar to template protection for people experienced with templates, which I think is widely recognized as a useful tool. On procedure, I don't see how the presence or absence of an RfC tag has any impact on the validity of the consensus produced here, whatever that may turn out to be. The main point of the tag is to attract people watching the RfC categories to prevent local consensus issues, but VPPROP and CENT are sufficiently high profile to do the same. Toadspike [Talk] 11:11, 29 September 2026 (UTC)
• Support. Page movers are generally not stupid, and similar to when we established template editors, only the highest of the high-risk needs to be kept behind the sysop gate. Please ignore my brazen conflict of interest here, and perhaps consider me an exception to the first clause of my previous sentence. With love from Maryland, charlotte ^👸♥ 09:06, 1 October 2026 (UTC)
• Oppose. An additional move protection level will almost certainly lead to more protection requests and actions to adjust protection levels, and these requests will outnumber the move requests this would potentially avoid (which is only when a page happens to be at this level and a page mover happens to handle the request). I believe the real issue is that extended confirmed is a poor proxy for trust when it comes to page moves. We should address that issue instead. I also agree with Anomie that this would clutter the configuration and protection interface, and as someone who has handled many page protections, I believe adding another level would make each protection decision more complex and slower. Daniel Quinlan (talk) 20:11, 1 October 2026 (UTC)

  extended confirmed is a poor proxy for trust when it comes to page moves. We should address that issue instead.
  This is an attempt to solve this exact issue. How do you think the 30/500 protection could be limited to more users? I don't understand; if we make extended-move-protected pages require, say, 1000 edits instead of 500, that's no longer "extended-move-protection". FaviFake (talk) 20:14, 1 October 2026 (UTC)

  I didn't propose specific changes to extended confirmed, but I'm ready to join a discussion about other approaches at WP:VPI. I oppose this proposal because it likely adds more work than it saves. An acceptable approach would reduce reliance on sysops for page moves without adding more sysop workload than it saves. Daniel Quinlan (talk) 20:47, 1 October 2026 (UTC)

  Sure, I was just confused about how it could be possible to address this issue by modifying the 30/500 move protection in a way that wouldn't completely change the protection level itself. FaviFake (talk) 20:52, 1 October 2026 (UTC)

  OT/FYI: there have been discussions at WP:PP regarding a new protection level, something between ECP and Full stil get's my support. The fact there is nothing between a busy one month editor and admin protection is baffling, aside from imposing PBAN/TBAN/CBAN. Personally I prefer the high bar like 5K/6M or 10K/1Y as "Advanced protection", then just yank privileges when needed, something we never do for experienced editors as 500/30 as is only a month break by comparison, so bans become necessary. A 6M/1Y defacto ban from editing pages with advanced protection makes a lot more sense overall, if that is the issue with certain users. In absence of that, I support this idea. CNC^{in solidarity} (talk) 09:27, 3 October 2026 (UTC)

  I don't really see why it needs to lead to more frequent requests for move protection, other than perhaps as a result of admins being more willing to use it, and discussions about changing the move protection level would be exceedingly rare – the only situation where you would realistically use full move protection would be on highly-visible templates.

  For article space, I expect things to function pretty much just like they do now but with page movers able to move pages, and potentially with admins being more willing to use move protection on pages (which I don't see as workload as much as more tools to work with). –Maltazarian ^{ᚾparley$\lor$investigateᛅ} 22:04, 1 October 2026 (UTC)

  An increase in protection levels is not just "more tools" and it's definitely not a free lunch. Every new protection level creates two new boundaries, and we regularly field requests to increase or lower protections (both on RFPP and on sysop talk pages), and many of those are rejected due to insufficient disruption or excessive risk. Adding a new protection level because a small number of requests take a day or two to resolve is using an expensive sledgehammer to swat a fly. Daniel Quinlan (talk) 23:49, 1 October 2026 (UTC)

  I know you field plenty of protection requests for the different kinds of protection we currently have in place, but that doesn't mean that this one will be the same, and there is good reason to believe that it would not be for the reasons I already mentioned. The way I see it the current move protection can be split in half with a pretty clear boundary between the two levels. The only editors that would even be affected by a change between full move protection and the lesser move protection is page movers, and I cannot imagine that page movers are going to be consistently requesting changes to the protection level of high-visibility template pages. –Maltazarian ^{ᚾparley$\lor$investigateᛅ} 01:29, 2 October 2026 (UTC)

• Support This seems like a good idea. Page Movers are on some level going to be inherently more trustworthy than extended confirmed users in these situations because they have more to lose if they abuse it. --Ahecht (TALK
  PAGE) 17:20, 9 October 2026 (UTC)
• Support as there are less page movers (467) than admins (808) and that PMs can be trusted not to move protected articles unless absolutely necessary (usually after an RM). I have the PM right also JuniperChill (talk) 11:55, 10 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 ^{ᚾparley$\lor$investigateᛅ} 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 ^{ᚾparley$\lor$investigateᛅ} 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:

Month	Moves	Edits
September 2026	24	2781
August 2026	40	3540
July 2026	31	3685
June 2026	30	3260
May 2026	21	2950
April 2026	32	3315
March 2026	71	3205
February 2026	48	2748
January 2026	47	3288
December 2025	87	3197
November 2025	31	3285
October 2025	13	4094
September 2025	37	3439
August 2025	30	3975
July 2025	54	3057
June 2025	38	2867
May 2025	41	3453
April 2025	28	2575
March 2025	32	3125
February 2025	41	3108
January 2025	77	3865
December 2024	23	3051
November 2024	40	2873
October 2024	22	3430
September 2024	45	3065
August 2024	101	3112
July 2024	65	3105
June 2024	26	2834
May 2024	61	2946
April 2024	35	2860
March 2024	43	3442
February 2024	13	3257
January 2024	29	3304
December 2023	30	3196
November 2023	16	2707
October 2023	36	3149

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 ^{ᚾparley$\lor$investigateᛅ} 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 ^{ᚾparley$\lor$investigateᛅ} 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)

New section of AIV for TPA and email revoke

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

---

The following proposal was originally made by IrisChronomia here.

Recently, WP:LTA/SB1 has taken the tactic of sending mass pings after being blocked. However, it currently takes a while to stop them, because we have to manually alert the blocking admin or go to ANI to get TPA revoked, which leaves enough time for >20 pings to come out. AIV would be ideal, but if the user being reported is blocked, the bot auto-reverts. Therefore, I would like to propose creating a new section of AIV for requesting revocation of TPA and email, where the bots don't auto remove after some time. (Perhaps a new heading below User-reported would work.) 7amiþ reform · solidarity · 💬 · 📊 23:09, 25 September 2026 (UTC)

Support, see my response on the original ANI thread. Beta Beta Beta - talk 00:44, 26 September 2026 (UTC)

Support, ditto re:ANI thread. LizardJr8 (talk) 01:32, 26 September 2026 (UTC)

Support, especially as someone sometimes affected by "Porya azizi delete". Axolitl (talk | contribs) 02:28, 26 September 2026 (UTC)

Support - Surprised this hasn't been done yet. Would be very useful for cases like this. Jdcomix (talk) 03:29, 26 September 2026 (UTC)

Support as someone who has made several requests at ANI in the past. Lavalizard101 (talk) WP:SOLIDARITY 10:33, 26 September 2026 (UTC)

Support - Quite reasonable, especially if it's clear leaving those avenues open isn't going to be productive. —Jéské Couriano v^_^v ^{Look out it's Jimothy!} 15:26, 26 September 2026 (UTC)

Support. ANI should stay open for more important matters than TPA and Email revocations. —Leaf.Sheap ⇖ /.°°.\ ⇗ (They•Them) 18:50, 26 September 2026 (UTC)

Support. Good idea. Or create a separate WP page for requesting such tasks - whichever approach is easier to implement. ←Baseball Bugs ^{What's up, Doc?} carrots→ 18:59, 26 September 2026 (UTC)

I would prefer it was on WP:AIV, as having it on a different page would give it less visibility. Axolitl (talk | contribs) 22:14, 26 September 2026 (UTC)

As long as it's not too difficult to implement. Maybe Writ's idea below would be the easiest way. ←Baseball Bugs ^{What's up, Doc?} carrots→ 01:08, 27 September 2026 (UTC)

Support ~ ONUnicorn^{(Talk|Contribs)}problem solving 22:17, 26 September 2026 (UTC)

Support - makes it way more straightforward for the counter-vandalism “crew” (I’ve personally run into this) and helps keep ANI tidy. Netstars22 (talk to me!) 18:19, 27 September 2026 (UTC)

• Support, and make it a transcluded subpage of AIV (like we do now for the bot reports) so that it can be watchlisted separately. Extraordinary Writ (talk) 22:47, 26 September 2026 (UTC)

  +1 —Leaf.Sheap ⇖ /.°°.\ ⇗ (They•Them) 00:15, 27 September 2026 (UTC)

  +1 7amiþ = reform(solidarity).__init__(t, c) 00:31, 27 September 2026 (UTC)

  Good idea. Best of both worlds. Axolitl (talk | contribs) 00:31, 27 September 2026 (UTC)

Support, this sounds horrifying Gnomingstuff (talk) 23:10, 26 September 2026 (UTC)

Note: Wikipedia talk:Administrator intervention against vandalism has been notified of this discussion. Axolitl (talk | contribs) 00:53, 27 September 2026 (UTC)

Support per above commenters. Would make things a bit easier for us admins too, as there wpuld be a centralized place to handle these. Accessedgrant (Epicgenius mobile alt) (talk) 03:51, 27 September 2026 (UTC)

Support /usr/bin/owuh $ (💬 | she/they) 04:38, 27 September 2026 (UTC)

• Question – would improving the bot be a better way forward? I agree that there is a problem which needs solving, but I wonder if the bot should simply not remove requests for TPA or email revocation. Best, HouseBlaster (talk • he/they) 17:57, 27 September 2026 (UTC)

  I suppose the issue is just that the bot is unable to tell if a request is for TPA or email revocation. Its why the bot doesn't remove partially blocked users, and I would guess it would be a similar issue for TPA or email. 45dogs (they/them) (talk page) (contributions) 17:01, 28 September 2026 (UTC)

• Question: If implemented, would doing a TPA revoke request require an existing indef block to be in place OR could/would it be set up where one can request an indef w/ TPA revoked right away? Netstars22 (talk to me!) 18:29, 27 September 2026 (UTC)

  I would think that unless its a specific LTA TPA revocation should be a last resort, but I would also say there shouldn't be a specific rule against it. —Leaf.Sheap ⇖ /.°°.\ ⇗ (They•Them) 19:29, 27 September 2026 (UTC)

  Yeah, my thought is that for LTAs specifically it makes sense to issue an indef with TPA revoked immediately, so as to save folks time and limit the damage. Netstars22 (talk to me!) 02:35, 28 September 2026 (UTC)

  Perhaps TPA revocation should become the norm for socks of the small number of LTAs who habitually abuse their talk pages. Certes (talk) 21:17, 28 September 2026 (UTC)

Strong Support. I've seen many instances where this would have been very useful. FlammablePizza (talk / contrib) 17:19, 28 September 2026 (UTC)

Support No brainer; these requests are very uncontroversial (which is the whole point of AIV—uncontroversial requests) and don't need to be cluttering up ANI. As for the implementation, we could either create a new section, or update the {{Vandal}} template to include a parameter that indicates it's a TPA request, so the bot won't remove it until the user's TPA is revoked. Twinkle and other tools could then be updated to support whichever implementation we choose to go with. —⁠k6ka 🍁 (Talk · Contributions) 17:28, 28 September 2026 (UTC)

Support. This is irritating a lot of people, as well as creating publicity that should be denied. Something should be done, and this is undeniably something. Certes (talk) 18:15, 28 September 2026 (UTC)

On reflection, support doing something, but systematic TPA revocation for certain LTAs might be a better solution. Certes (talk) 21:23, 28 September 2026 (UTC)

Those who know will usually do that. It's those who don't know to do that that's the issue, and there's not much you can do about that. It's probably not sensible to default to revoking TPA of every vandal that someone says is an LTA (and even then not every LTA TPA needs to be revoked). Making an explicit request in the AIV report would probably be a useful interim measure. -- zzuuzz ^(talk) 21:33, 28 September 2026 (UTC)

• A new section does not sound like the best possible solution to this problem. FaviFake (talk) 19:19, 28 September 2026 (UTC)
• My preference would be for the vandal template to include a TPA parameter, and for the removal-bot to respect that. Yet another admin page doesn't seem too appealing. I just want to mention that the bot operator should probably be advised of any new sections or subpages, as the bots will need to parse one or both pages. Pinging @Mdann52: to the discussion. -- zzuuzz ^(talk) 21:33, 28 September 2026 (UTC)

  would also want to inform devs of all the tools to allow them to implement requesting via the new parameter /usr/bin/owuh $ (💬 | she/they) 21:40, 28 September 2026 (UTC)

   Done. Huggle, Twinkle, and Ultraviolet alerted on talk page. Also pinging TonySt (Interceptor), Awesome Aasim (rcpatrol), Ingenuity (AntiVandal), and LuniZunie (WikiShield). Snowmanonahoe (talk · contribs · typos) 03:08, 29 September 2026 (UTC)

  It seems UV is not being actively maintained at the moment, and Twinkle has been slow to catch up (we still don't have LLMPROD handling, for example). I support this. TPA/Email revocation in my limited experience has mostly been prompted from talk messages, which I'm happy to respond to, but in the event I'm unavailable, we have to wait, which is not ideal. ASUKITE 03:42, 29 September 2026 (UTC)

  Thanks for the ping. Integrating it into the existing AIV workflow makes sense, whether that's using a new argument for {{vandal}} or a new template altogether. Interceptor would be an early adopter of whatever solution we arrive at. TonySt  04:32, 29 September 2026 (UTC)

  I personally would much prefer a new argument, meakes it a lot easier to update and it allows for more variations in what you are requesting. – LuniZunie_(talk) 21:13, 30 September 2026 (UTC)

  Agreed. A new section sounds more complicated. the bots should recognise the new |tpa= parameter and avoid insta-archiving the request. FaviFake (talk) 21:21, 30 September 2026 (UTC)

  In my eyes, a new section should be completely off the table. It just would not be used a lot and would be a pain. – LuniZunie_(talk) 21:22, 30 September 2026 (UTC)

• Comment: I see blizzard-like conditions, but due to the recent notifications of tool maintainers I'm holding off on closing until they've had a chance to weigh in. Toadspike [Talk] 06:39, 29 September 2026 (UTC)

  Why would you want to close this? Why not keep it open indefinitely? As you said, the consensus is obvious. FaviFake (talk) 07:22, 29 September 2026 (UTC)

  I've seen this AIV phenomenon complained about for years, and no one has ever suggested it's an ideal situation. But the devil is in the detail of the implementation, and that's where further discussion would be most useful. -- zzuuzz ^(talk) 10:39, 29 September 2026 (UTC)

  Do you think it's worth treating this discussion as a WP:RFCBEFORE and starting an RFC on the implementation? I see at least three opinions on ways we could do this. —Leaf.Sheap ⇖ /.°°.\ ⇗ (They•Them) 17:05, 29 September 2026 (UTC)

  I'd be okay with that, but I'm a teense worried about WP:NOTBUR; we don't want more vandalism to happen simply because we were working out the nitty gritty. 7amiþ = reform(solidarity).__init__(t, c) 17:40, 29 September 2026 (UTC)

  Yeah. and we also don't want to work out the nitty gritty more than is necessary. FaviFake (talk) 20:05, 29 September 2026 (UTC)

  Not much is going to happen without someone writing and implementing the bot code. Well that's not entirely true - we could create a new page which might get automatically removed from AIV if anyone tries to transclude it, and which no one will automatically clear, and few admins will independently watch. Or we could create a new section which will either be automatically removed or just ignored by the bot. Or we could add a template parameter which will likewise be ignored. We need some buy-in from the (volunteer) bot operator, but it may help if we can decide what we'd prefer. RFC or discuss here, I don't really see any difference. -- zzuuzz ^(talk) 21:37, 29 September 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.

• I've opened the implementation discussion.
   Courtesy link: WT:AIV § Implementation. FaviFake (talk) 21:48, 6 October 2026 (UTC)

Wiki Loves Peace 2026

Hello everyone,

I am requesting community feedback regarding a CentralNotice banner for Wiki Loves Peace 2026, an international photography campaign supported by the United Nations Office for Disarmament Affairs (UNODA) aimed to document peace-related heritage, memorials, museums, monuments, public art, and other sites connected to peace and reconciliation around the world.

As guided by DerHexer on the Meta-Wiki CentralNotice request page, I am seeking community consensus on allowing the banner to run on the English Wikipedia as well. The banner period would be the first week of October and the last week of October 2026, for a total of 14 days.

Peace-related heritage is located in every region of the world, and the English Wikipedia has a global audience. Allowing the banner to run on the English Wikipedia would help inform contributors worldwide about the campaign and encourage participation in documenting places that embodies the pursuit of peace.

P.S. The campaign has also been featured by the Wikimedia Foundation on all its social media channels: Instagram, Linkedin, Facebook, YouTube, Bluesky, Threads.

Comments, questions, concerns, or support are all welcome.

Thank you for your time. ❯❯❯ Raydann^(Talk) 08:45, 30 September 2026 (UTC)

• Support: as proposer

❯❯❯ Raydann^(Talk) 08:59, 30 September 2026 (UTC)

Comment: As stated on the CN request page, “I have added a limit of 25 % maximum reach (with 5 displays per week)” in order to reduce banner blindness for this new campaign. If you have further questions or wishes for adjustments, I will try to follow the conversation here and on the request page. Best, —DerHexer (Talk) 10:05, 30 September 2026 (UTC)

I oppose running these banners for anonymous users; banners are not free. I support an impression diet of at most two per week (for a total of four banners over the campaign period). Best, HouseBlaster (talk • edits • he/they) 17:57, 30 September 2026 (UTC)

I support this, with any ordinary reasonable limits (e.g., as already set by DerHexer). WhatamIdoing (talk) 18:23, 30 September 2026 (UTC)

• Oppose. I do not think the number of en-wiki readers or editors who would be interested in "[t]ak[ing] photographs of subjects relevant to the theme of peace" and uploading them to Commons is high enough to justify something as burdensome as a CentralNotice. Advertising the campaign on Commons (the affected project), social media, mailing lists, etc. seems like a more proportionate approach. Extraordinary Writ (talk) 05:00, 1 October 2026 (UTC)

  Any registered editor who finds that ignoring or clicking away a banner five times a week is "burdensome" can go to Special:Preferences#mw-prefsection-centralnotice-banners and turn them off. WhatamIdoing (talk) 02:54, 2 October 2026 (UTC)

  I think the percentage of users who are aware of that is extremely small. Maybe I'd feel differently if CentralNotices had opt-out instructions. Extraordinary Writ (talk) 22:12, 2 October 2026 (UTC)

  I suppose we could run a local site banner or a watchlist notice to tell people about it. Or maybe you'd like to write something for The Signpost about it? (I could imagine a whole series on various prefs settings. For example, did you know that changing your language to en-gb usually has the effect of shortening a lot of software messages?) WhatamIdoing (talk) 22:22, 2 October 2026 (UTC)

• Provisional support, but what specifically are the metrics (eg number of times it runs) and how do they work? I can't seem to find the details and while I am willing to support projects related to peace, I do want to have the "spam" concerns sorted out before I "lock in" my !vote. Hason-LEK-SIN ● 💬 ● 🧱 ● 🧪 08:34, 1 October 2026 (UTC)

@Hason-LEK-SIN, with the current configurations (25% traffic limit and 5 displays), the banner will be shown to 25% of eligible users. For example, if 100 people are eligible to view the banner, it will not be shown to all of them, but only to a quarter of those users. Furthermore, the banner will be shown to an individual user at most 5 times per week, so if a user has seen the banner 5 times, they won't be shown the banner again until the limit resets the next week.
For this specific campaign, the banner will only run for 2 weeks: the first week of October, which is currently passing by (meaning that the total time duration for the banner is shrinking), and the last week of October, from the 23rd to the end of the campaign on 30 October. Therefore, a person can see the banner at most 5 times this week, and at most 5 times during the last week of October. ❯❯❯ Raydann^(Talk) 23:32, 1 October 2026 (UTC)

For ENwiki, that seems sufficient, while for Commons, the Wiki loves Peace campaign is already advertised on the home page, so there may be no need for the banner. Given all those limits to prevent spam, I wholly support. Hason-LEK-SIN ● 💬 ● 🧱 ● 🧪 00:37, 2 October 2026 (UTC)

I support HouseBlaster's proposition, 2 per week, I think it makes sense for enwiki as one of the most prominent wikis to promote it's sister project's initiatives, but seeing one every weekday on a related project feels overkill. Sohom (talk) 15:51, 2 October 2026 (UTC)

I don't think it works that way. I think it's 5 times in ~20 page views, and the nothing else for the rest of the week. WhatamIdoing (talk) 20:24, 2 October 2026 (UTC)

• Is peace neutral? I could see this drawing complaints from both the "this is criticism of [insert current war]" and the "no justice no peace" POVs. _signed, Rosguill ^talk 16:13, 2 October 2026 (UTC)

  Perpetual proposal to change Wiki Loves to Wiki-would-generally-very-much-like-to-have-better-coverage-of CMD (talk) 03:28, 4 October 2026 (UTC)

• Oppose As Clausewitz put it, war is the continuation of politics by other means. So is peace. It is inherently non-neutral.--Wehwalt (talk) 16:20, 2 October 2026 (UTC)

Comment: Traditional outreach channels are already being actively used (mailing lists, community groups, social media, and direct outreach to affiliates and local communities), @Sohom can perhaps attest to that.

Regarding banner fatigue, I am willing to compromise on a limit of 25% max reach and 2 impressions per week (4 total across the campaign period) for both logged-in and anonymous users.

My reasoning is that English Wikipedia reaches a global audience. Peace related heritage sites exist in every region of the world, and uploading a photograph is a relatively easy first contribution than editing Wikipedia articles. Several of the strongest submissions received so far have come from people who stated that they had never previously contributed to Wikimedia projects.

Regarding the neutrality discussion, debating differing interpretations of peace is unlikely to be productive. This nuance was discussed extensively during the development of the campaign with UN staff. At face value, the project is a photography and documentation campaign, similar in nature to Wiki Loves Monuments, with the additional criterion that the subject be connected to peace, remembrance, reconciliation, disarmament, or peacebuilding.

Questions about the wider concept of peace are understandable, but the campaign itself is a photography campaign. I would prefer to keep this discussion focused on the proposed banner and its configuration. ❯❯❯ Raydann^(Talk) 18:11, 2 October 2026 (UTC)

• Support - I almost opposed because this just doesn't seem very enwiki-related, but 25% of users for less than two weeks, max 2-5 impressions/week? Meh, why not promote a peace initiative on a sister project, it seems pretty low key and maybe we'll get some good photos to use in enwiki articles out of it. Levivich (talk) 22:03, 2 October 2026 (UTC)
• Given that more than 40% of the first week has already passed, I would like to request revised banner dates on enwiki to allow a fair full week of visibility. Possible alternate: 7-14 October, while keeping 23-30 October unchanged. ❯❯❯ Raydann^(Talk) 21:50, 3 October 2026 (UTC)

  Sure. Hason-LEK-SIN ● 💬 ● 🧱 ● 🧪 23:36, 3 October 2026 (UTC)

  Sure Sohom (talk) 03:06, 4 October 2026 (UTC)

  I continue to strongly oppose displaying any banners for anonymous users. I'm fine with the suggested dates. Best, HouseBlaster (talk • edits • he/they) 20:47, 4 October 2026 (UTC)

• I'd oppose running banners on this. Photo contests like WLM and WLE have clearly defined parameters. The concept of "peace" is quite a bit looser. Secondarily, although I believe that this would be impartial, I empathize with the concerns around appearing impartial and do think that possibility should tip an otherwise balanced scale. Ed ^{[talk] [OMT]} 16:01, 8 October 2026 (UTC)

Proposal: Enable support for self-closing tags in syntax highlighting

The gadget mw:User:Remember the dot/Syntax highlighter, out of the box, does not recognize valid self-closing tags such as <br> which is the preferred and correct version in HTML without troublesome user config. In fact, the talk page has six threads of people wondering why it is not supported. I am proposing to set up a site-wide default so they are parsed correctly. Northern Moonlight 04:36, 3 October 2026 (UTC)

Courtesy pinging @Pppery and @Jonesey95 who discussed this on the talk page. Northern Moonlight 04:36, 3 October 2026 (UTC)

That would be fine with me. It should cut down on the completely unnecessary changing of <br> to <br /> and vice versa. The site-wide configuration should look something like: syntaxHighlighterConfig = {voidTags: ["br", "Br", "BR", "hr", "HR", "wbr", "WBR"] } – Jonesey95 (talk) 15:36, 4 October 2026 (UTC)

@Northern Moonlight Why are you using a 3rd-party syntax highlighter gadget when CodeMirror is installed by default and has none of these issues? --Ahecht (TALK
PAGE) 20:51, 8 October 2026 (UTC)

I don’t use it. This is for those who still use it for some reason. Northern Moonlight 21:02, 8 October 2026 (UTC)

Maybe it's time to deprecate that gadget then. --Ahecht (TALK
PAGE) 17:19, 9 October 2026 (UTC)

Read status in talk pages, noticeboards etc.

The read status could be easy to make and implement using Java script. I want it to be 2 features where you can never see them, or when you post a message, others can't see your read status. If accepted, this would be ready to be implemented unless sysadmins have to get involved. Fence127 (talk) 07:32, 3 October 2026 (UTC)

What exactly do you mean by "read status"? Are you referring to the little receipts on things like iMessage which says "Read 12:34"? Axolitl (talk | contribs) 21:18, 3 October 2026 (UTC)

@Fence127 Am I right that you are referring to read receipts but for Wikipedia notifications? Hason-LEK-SIN ● 💬 ● 🧱 ● 🧪 22:47, 4 October 2026 (UTC)

You don't need permission to create Wikipedia:User scripts for yourself. If it can be done in Javascript and won't hurt anyone else, then go for it. If you don't know how to do it yourself, then you could ask for help at Wikipedia:User scripts/Requests and hope that someone else will WP:VOLUNTEER to create it. WhatamIdoing (talk) 07:10, 10 October 2026 (UTC)

Skydance Motion Picture Group as a standalone article

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

---

Should Skydance Motion Picture Group, the film division of Skydance Corporation overseeing Paramount Pictures, Warner Bros. Pictures and the company's wider film portfolio, have a standalone article, or should coverage of the Motion Picture Group remain within the article on its parent company?

A proposed standalone article is available at Skydance Motion Picture Group. The draft was submitted through Articles for Creation, where the reviewer (declined the proposal) & another editor (@S0091 & @Redrose64) recommended seeking community consensus regarding whether the Motion Picture Group as a separately named division warrants standalone coverage, particularly given its references across numerous film-related articles.

Comments and opinions are welcome.

Thank You & Regards,
❖ ⚜ 𝕽𝖎𝖈𝖍𝖆𝖗𝖉 𝖁𝖊𝖊𝖗𝖆 𝕽𝖔𝖞 𝕯𝖊𝖛𝖔𝖓 ⚜ ❖ ​Talk 05:48, 8 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.

Text on "article not found" page

Hello folks, the "article not found" page (for example Footopia) displays the following text:

"Wikipedia does not have an article with this exact name. Please search for Footopia in Wikipedia to check for alternative titles or spellings.

• Start the Footopia article, using the Article Wizard if you wish, or add a request for it.
• Search for "Footopia" in existing articles.
• Look for pages within Wikipedia that link to this title."

There's two "search for Footopia" links, which is ridiculous. In fact they are different, as the first one searches on multiple namespaces (including Wikipedia which it shouldn't), but the second one only searches for articles. Also, it looks horrible to have the bold text and the first suggestion in the first line.

In my opinion it should be like this:

"Wikipedia does not have an article with this exact title.

• Search for "Footopia" in existing pages.
• Look for pages that link to "Footopia"."
• Start the "Footopia" article. You may use the Article Wizard or add a request for it.

Thoughts? -- NaBUru38 (talk) 22:37, 8 October 2026 (UTC)

The first link does not search in all namespaces? It searches the one that the red link is in. Axolitl (talk | contribs) 23:38, 9 October 2026 (UTC)

Bot proposal: automatic addition of infobox for company articles

There are about 12k articles tagged by WikiProject Companies that have no infobox. I'd like a bot (User:OKA bot, which is already active on Commons and Wikidata) to add {{Infobox company}} to them. The infobox would only contain what each article already says: no additional information, no new sources, no potentially controversial edits.

Safeguards:

• Companies only. This is a fairly uncontroversial type of edits, as ~95% of company articles already have one, and there is only one type of template (unlike people, which have a variety of infoboxes, and where there had been in the past some disputes)
• No new information. Focused on formatting of existing info only
• No overwrites. Only add when there isn't already an infobox.
• High confidence only. An LLM (Claude Opus 5.5 with high effort setting) is asked to flag any change that has a risk of being incorrect (e.g., if not 100% sure it's a company) for human review, or would skip it.
• Checking validity of parameters. Before saving, the bot would preview to ensure that the infobox doesn't introduce any error.
• No revert. If at any point the bot's changes are reverted, the batch stops for a human to review. An infobox that is removed is never added back by the bot without explicit human intervention
• Progressive increase, with test runs. The bot would first proceed with a couple of articles for the community to review, before doing larger and larger batches, so that any issues can be detected

If this looks acceptable, I'll file a WP:BRFA and can start with a small dry run on Swiss companies.

The goal of this is also to get some data on whether such bots could be used at larger scale for other types of infobox maintenance tasks 7804j (talk) 09:09, 10 October 2026 (UTC)

Is the list of 12k tagged articles available? How about a couple of examples showing an article where a sample infobox has been added? Johnuniq (talk) 09:44, 10 October 2026 (UTC)

Good idea! I've done a trial run here. I can add more if helpful.

I've also done an initial run through the list to find which ones are likely candidates, removing some obvious ones like lists, and got down to about 9k (full list). The number will likely change a bit in the final run, as the bot eliminates false positives (e.g., checking against wikidata, reading the actual content) and maybe finds a few more along the way. 7804j (talk) 11:48, 10 October 2026 (UTC)

Throwing an LLM into a CTOP seems a bad idea. CMD (talk) 11:20, 10 October 2026 (UTC)

The unasked questions here are: why do these articles not have an info box? And, Do they need one? I have a few thoughts…

First, not all articles need one. The information is easily found by reading the text. Second, in a few cases an article shouldn’t have one (for subject specific reasons).

So… I don’t think a bot is the right approach here. I understand that we are talking about a lot of articles, but an article-by-article review seems more appropriate. Blueboar (talk) 11:50, 10 October 2026 (UTC)

Do you have some examples of company articles that shouldn't have an infobox? I can see why some might argue that the article is also fine without one, but so far I haven't seen anyone argue specifically against including infoboxes for companies. I personally find them useful both because of the consistency they bring to the information and because by default they autopopulate some wikidata info like the logo, but also they make the articles visually more appealing in my opinion. The fact that 95% of company articles already have one also suggest that they have become the de facto norm in that topic. I believe the main reason why most don't have an infobox is simply the original author didn't think to add it/didn't know/was lazy. 7804j (talk) 12:01, 10 October 2026 (UTC)

(even if we were to find a couple of rare cases where the infobox is not desirable, I think it may be better to then revert these, than to have no bot at all, as doing it manually is extremely time-consuming and a pretty menial task. And once I have a few examples of cases where no infobox is better, I can instruct the bot to find other similar ones and skip them/revert them) 7804j (talk) 12:15, 10 October 2026 (UTC)

Meh… “Time consuming and menial” is a good thing… it means we thought about what we were doing and did it right. Blueboar (talk) 12:55, 10 October 2026 (UTC)

"Time consuming and menial" is a good thing if we had unlimited number of volunteers. But we don't, so I think their limited bandwidth and motivation is better spent on writing articles, improving them, etc. than on adding manually infoboxes 7804j (talk) 14:21, 10 October 2026 (UTC)

Unfortunately, infoboxes are a controversial topic and despite companies not having been an area of dispute with them (afaik) it's still not a good idea to add them by bot. Thryduulf (talk) 13:00, 10 October 2026 (UTC)

If I understand correctly you are saying the issue is not necessarily about the bots but mostly about whether we want to have these infoboxes or not in the first place, due to previous controversies.

Perhaps we could then have a separate discussion to get feedback from the community on this: getting a sense of who is still opposed to the idea of having infoboxes, specifically for companies and possibly for other categories other than people.

It was indeed controversial several years ago in the context of people and some other themes; also Wikipedia has changed a lot since then.

What do you think? 7804j (talk) 14:20, 10 October 2026 (UTC)

It was very controversial, the extent there were three arbcom cases explicitly about them: Wikipedia:Arbitration/Requests/Case/Infoboxes (2013), Wikipedia:Arbitration/Requests/Case/Infoboxes/Review (2015), Wikipedia:Arbitration/Requests/Case/Civility in infobox discussions (2018). Wikipedia:Arbitration/Requests/Case/SchroCat (2026) also contained a significant amount of evidence related to infoboxes (and I think there was at least one other between 2018 and 2026 where that was the case too but I can't remember which it was). There is still a restriction somewhere I believe that discussions about adding or removing an infobox must be about matters related to the specific article not infoboxes in general. I am very pro-infoboxes and believe that most articles about concrete subjects would benefit from one, but mass-adding infoboxes by bot is just not something that is going to go well and not something I can support. Thryduulf (talk) 14:57, 10 October 2026 (UTC)

Reading the arbitration cases, my impression is that this wasn't so much about the infoboxes, but more about the way they were added, the lack of communications, incivilities, etc. and none of these arbitration cases related to companies. 7804j (talk) 16:19, 10 October 2026 (UTC)

I won't bother saying I'm amazed infoboxes are controversial because apparently everything here is to someone.

But I'll ask perhaps the more decorum free and important question: do their numbers/head count matter to be relevant or are we talking about a numerically irrelevant number of editors? — VPP (t/c) 14:24, 10 October 2026 (UTC)

• I like the idea. Your sample looks good. But as with any piece of software, it needs to go through a serious test phase. I suggest at least 100 test cases before release. Yesterday, all my dreams... (talk) 13:09, 10 October 2026 (UTC)

  Let me get a batch of 100 random articles through the bot. I agree it will be more representative 7804j (talk) 14:21, 10 October 2026 (UTC)

  Generated the 100 articles simulation here. 7804j (talk) 17:20, 10 October 2026 (UTC)

• And how exactly is the infobox generated? All you seem to have said is "Focused on formatting of existing info only". Okay, but how? –Deacon Vorbis (carbon • videos) 15:03, 10 October 2026 (UTC)

  By an LLM (Claude Opus 5.5; Max effort) 7804j (talk) 15:17, 10 October 2026 (UTC)

  Yeahhhh, I appreciate your candor, but in the immortal words of Lana Kane, noooooooooooooooope. Given current attitudes and policy on LLM use, no way. –Deacon Vorbis (carbon • videos) 15:18, 10 October 2026 (UTC)

  I like the idea, but can you explain why this isn't a violation of the WP:LLM policy? Seems like it it a bot task that requires context, and involves having a LLM generate text unsupervised... FlammablePizza (talk / contrib) 15:19, 10 October 2026 (UTC)

  A number of years ago we would regularly have bots/bot-like accounts taking external database entries on sports people and making thousands of articles based purely on the text pulled from those databases. Taking the text of an existing Wikipedia page and extracting out information to put into an infobox seems largely like the same thing, just with a more complex input text requiring more complex tool use. I have no opinions on whether a bot to do this task should exist, but its methods seem fairly acceptable. (please ping on reply) Primefac (talk) 15:25, 10 October 2026 (UTC)

  That's a sharp difference. Subtle one.

  Old style you mention, end of the day, would have boiled down to this work flow:

  1. Some piece of written fixed code reads some fixed data
  2. That written fixed code transforms that fixed data into a new format
  3. That new formatted fixed data is then entered into wikipedia

  If LLM comes into play:

  1. Some piece of written fixed code

     None of our business it's genesis, be it a human hand pecking each character or using LLM to build it or whatever else inbetween.

  2. That written fixed code

     Still the same at this point.

  3. transforms that fixed data into a new format

     WP:NOLLM only becomes a discussion point here.

  Mechanically, this is the reality (broadly). — VPP (t/c) 15:47, 10 October 2026 (UTC)

  In my opinion this is an ambiguous area as this discussion shows. I see it as a case of LLM used for creating/formatting wikitext, to which there is currently no clear consensus and with several editors expressing the view that the ambiguity is intentional, precisely to allow cases where the use of an LLM would be otherwise unnoticed if not mentioned. We could also see where that other discussion lands. 7804j (talk) 16:06, 10 October 2026 (UTC)

  I'm reasonably sure the present in-flux consensus is:

  • Stuff that is plain text in the raw editing box at the end of day generated by LLM: no
  • Back-end code that does stuff/supports wikipedia doesn't go into the plain text data entry: beyond the authority of en.wiki

  So if there AI/LLM derived code that ran a "bot" or wrote the underlying deterministic code that's not governable... but the bot cannot just be a passthrough for the LLM generated text? No "laundering".

  • Operations/backend/development/upkeep/integration/test: do whatever you want. None of our business and abstracted beyond our ability to control anyway, full stop. Anyone saying otherwise may claim moral standing but that's effectively it.
  • Outputs into Wikipedia: no LLM.

  That's basically it. — VPP (t/c) 15:41, 10 October 2026 (UTC)

One of the reasons infoboxes are a contentious topic is that summarizing any complicated or contentious matter into a couple words is inherently a subjective task. For instance, the classic infobox fight was over a person's nationality. The article can say "so and so was born in X, lived in what is now Y but was then Z, published in language W. Their parents were from A and of B descent.". This requires human judgement, and in fact fairly complicated human judgement, to decide what if anything to put in the infobox. Company infoboxes are probably less likely to have that sort of explosive content, but while I am reasonably confident that Opus 5.5 can handle with a very high degree of accuracy extracting simple cases, I am less confident in its ability to consistently identify cases where it should refuse and leave it to human judgement if the information is theoretically in the text, just complicated for, well, complicated reasons. Do you have example(s) of running this bot on something complicated like that? If you can't find examples in your company list I'd take a couple dry run/no edit examples on articles that already have infoboxes as long as the infobox was fully hidden from the model's input and we were confident it was not fetching the live page.

While we're at it, if you do end up getting consensus for this bot I strongly recommend having an agent verifier approach, in which the second agent does not have the first's context and is instructed to reject the change if it fails a list of safeguards, ideally with a different family of model than the first agent (for instance, whatever today's frontier GPT is + Opus 5.5). This prevents confirmation bias and the models have different strengths and tend to be more critical of output that doesn't have hallmarks of their own work. Rusalkii (talk) 16:08, 10 October 2026 (UTC)

I agree that in your example, the nationality parameter would be a subjective case, which is why I explicitly put it out of scope. In your example, the bot would only indication birth place, etc. which are facts already present in the article and not inferred, thus not requiring human judgement (or if they do, the bot would flag it to a human).

> Do you have example(s) of running this bot on something complicated like that?

Yes there are a few examples from the 5 articles sample already, which I'm working on extending with more examples. 7804j (talk) 16:22, 10 October 2026 (UTC)

My point is not "do you think this is out of scope", it's "will the bot consistently identify it as out of scope", which I doubt. Rusalkii (talk) 16:31, 10 October 2026 (UTC)

Here's the results of the 100 articles sample. What I see is there are indeed a lot of cases where the article's scope is not 100% well defined (e.g., same article referring to both a brand and a company, or to the group and the underlying company), which the LLM identified fairly well. So to the model's credit, it seems to be detecting these well, but on the other hand this is also an indication that the task has a higher degree of ambiguity than I originally expected in terms of identifying the primary "subject" of the infobox. However, I am also of the opinion that a "mistake" in that area has almost no negative consequence (e.g., if an infobox company was to be added to an article that covers both the brand and the company, worst case scenario someone would just remove it, and the bot wouldn't add it back). 7804j (talk) 17:19, 10 October 2026 (UTC)

• Why are we even entertaining this? This should be 100% DOA. An LLM-bot is NOT going to do mass edits to articles. –Deacon Vorbis (carbon • videos) 16:18, 10 October 2026 (UTC)
• Agreeing with Deacon Vorbis, absolutely not. Nope. ‑‑gurkubondinn 16:22, 10 October 2026 (UTC)