Wikipedia:Village pump (proposals)

Moved to Wikipedia:Village pump (proposals)/This week's article for improvement

Chaotic Enby (in solidarity · talk · contribs) 11:33, 21 June 2026 (UTC)[reply]

Re-added section to main VPR and pinning it as it is still ongoing (ping and trout me if this isn’t allowed) Hason-LEK-SIN ● Let’s chat! ● My contribs 08:05, 1 July 2026 (UTC)[reply]

@Hason-LEK-SIN: People who care really should have watched that page, and probably have. We don't normally try to keep the "moved discussion" notice present indefinitely. But at least your attempt (three weeks; note the box slightly lied) was better than the 10 years someone else attempted before you. Since multiple people seem to insist on restoring this, one week seems more than sufficient. I'm going to remove the {{DNAU}} pinning; it'll re-archive 7 days after the latest comment here. Anomie⚔ 11:30, 1 July 2026 (UTC)[reply]

... would've been very easy to remove the pin when the RfC started and have it automatically archive Kowal2701 (talk, contribs) 14:59, 1 July 2026 (UTC)[reply]

Does including Public transit access in Infoboxes constitute a violation of WP:NOTGUIDEBOOK and/or WP:PROMO and thus warrant removal? --Zackmann (^{Talk to me}/_{What I been doing}) 21:29, 22 May 2026 (UTC)[reply]

Background

There are a large number of infoboxes that include information about how to best access the location via public transit and/or the nearest parking facility. These values would, to me, appear to be direct violation of the fact that Wikipedia is not a guidebook at best and at worst would seem to be promotional information which serves nothing but to promote the best way to reach a certain location.

I will also quote from MOS:INFOBOXPURPOSE that The purpose of an infobox is to summarize, but not supplant, the key facts that appear in an article. I question what encyclopedic value exists in listing what metro or bus stop is nearest to a certain building?

Examples

Some of the many templates I have found that have some form of |publictransit= and/or |parking= parameter include: {{Infobox building}}, {{Infobox museum}}, {{Infobox airport}}, {{Infobox venue}}, {{Infobox shopping mall}}, {{Infobox casino}}, {{Infobox library}}, {{Infobox park}}, {{Infobox UNESCO World Heritage Site}}, {{Infobox amusement park}} and {{Infobox zoo}}. There may be others that I have not listed here.

Much appreciated Thryduulf. I did post on the talk pages for the templates above. Zackmann (^{Talk to me}/_{What I been doing}) 22:34, 22 May 2026 (UTC)[reply]

• Comment my first thought is that for some articles, whether there is public transport and/or parking is a key aspect. Certainly whether a public airport has public transport access is a very important aspect of the topic. Thryduulf (talk) 22:35, 22 May 2026 (UTC)[reply]

  It is worth noting that of the over 13,500 uses of {{Infobox airport}}, under 60 of them use the |publictransit= parameter per the May 2026 param report. That alone doesn't mean we should nuke the parameter of course, but I do think it is worth noting that in this instance, the parameter is barely being used. Zackmann (^{Talk to me}/_{What I been doing}) 22:42, 22 May 2026 (UTC)[reply]

  An alternative reading of that stat is that the parameter is only being used where it is key information - exactly as it should be. Thryduulf (talk) 23:59, 22 May 2026 (UTC)[reply]

  Fair point!! Zackmann (^{Talk to me}/_{What I been doing}) 00:35, 23 May 2026 (UTC)[reply]

Comment I think it's just unnecessary in general since several buildings, tourist attractions, airports, restaurants, etc. have public transit access. Aspifi (talk) 22:59, 22 May 2026 (UTC)[reply]

• As transportation facilities, airports seem to be in a different class than the others listed here. Public transit and parking are connections at airports (just as they are for train stations), not merely access; we should keep them (and use the parameters much more widely). I'm neutral about the others. Pi.1415926535 (talk) 23:02, 22 May 2026 (UTC)[reply]

• Prefer to keep. I'm mostly on board with the other discussions, but there are cases where public access is indeed well reported and well noted, and in such cases, I think it should be kept. However, it should be used sparingly and only in non-controversial cases. I'm just not quite on board with blanket removing it. guninvalid (talk) 02:02, 23 May 2026 (UTC)[reply]
• Does the use in the infobox reflect regular use in the articles? CMD (talk) 03:13, 23 May 2026 (UTC)[reply]
• Questions I didn't really realize this was a thing until I made the article for Archives of the Impossible, and noticed it in the template. Aside from WP:NOT POV, what's the harm/downside of carrying information like this? Were there any major prior discussions about all of it? — Very Polite Person (talk/contribs) 04:07, 23 May 2026 (UTC)[reply]

  The downside is that its debated on whether including parking/public transit is considered promotional or not. Aspifi (talk) 04:09, 23 May 2026 (UTC)[reply]

  Well, this should be a solved problem already then perhaps?

  What other major templates carry details of public services beside this, which by being offered up to readers can be seen as promotional? — Very Polite Person (talk/contribs) 04:11, 23 May 2026 (UTC)[reply]

• Comment While I agree that using the param for nearby transit/parking would be inappropriate, if the transit/parking directly serves the location in question I would argue it would be appropriate. For example, the usage in Ottawa Macdonald–Cartier International Airport would be appropriate because the station was built to serve that location, and perhaps saying the rough number of parking spots may also be fine. There is also the option of being vague, for example saying a simple "Yes/No" for parking, or saying "Buses" for public transit. Jumpytoo Talk 04:10, 23 May 2026 (UTC)[reply]

  But again, Jumpytoo, what encyclopedic value is there to saying "yes/no" for the existence of parking for a particular building ({{Infobox building}}) or a shopping mall ({{Infobox shopping mall}})? Perhaps airports are a valid exception here. As Pi.1415926535 pointed out above, As transportation facilities, airports seem to be in a different class than the others listed here. So lets for a moment set aside {{Infobox airport}}, but what about the value for a museum? a zoo? a venue? Zackmann (^{Talk to me}/_{What I been doing}) 04:16, 23 May 2026 (UTC)[reply]

  It could be used to highlight an unusual aspect of the place in question, for example a mall having no (or very little) parking at all. And there would also be sources noting that aspect in such case, which would meet the WP:DUE. Jumpytoo Talk 04:38, 23 May 2026 (UTC)[reply]

• Comment WP:NOTTRAVELGUIDE, the relevant part of WP:NOTGUIDE, does not explicitly cite transportation links as part of its remit. I agree that an excessive discussion of transport routes would be a NOTGUIDE vio, but a simple one-off mention of the nearest transport links in the infobox does not seem to be against the 'letter of the law' here. Athanelar (talk) 04:27, 23 May 2026 (UTC)[reply]

  While it is not directly mentioned in NOTTRAVELGUIDE itself, I still think it's promotional. If someone from Florida wants to know if a tourist attraction in Arizona offers free parking, they are expected to check the place's website, not use an encyclopedia. Aspifi (talk) 02:16, 24 May 2026 (UTC)[reply]

  I agree, I think NOTGUIDE probably ought to mention it explicitly. Athanelar (talk) 05:38, 24 May 2026 (UTC)[reply]

• Comment I can't say I see how including public transit information, in and of itself, could be considered promotional information. There are ways that it could be written promotionally, but those can be handled accordingly. XtraJovial (talk • contribs) 17:21, 23 May 2026 (UTC)[reply]
• Comment I can't imagine this ever being due/non-guidebook information for the infobox. If there is something unique about the public transit for these subjects it'd probably need to be covered by prose regardless. Traumnovelle (talk) 20:43, 23 May 2026 (UTC)[reply]
• Keep – Many performance venues don't have on-site parking, so information about public transport access is crucial and encyclopedic. -- Michael Bednarek (talk) 00:56, 24 May 2026 (UTC)[reply]

  How is it encyclopaedic? If I am reading about a performance venue in another country the public transit access is the least of my interest. If someone is wanting to travel to one they should consult the website of the venue itself. Traumnovelle (talk) 01:41, 24 May 2026 (UTC)[reply]

  Oppose argument per Traumnovelle. It's not encyclopedic because it's not notable information. Someone living in Texas is not expecting an article about a mall in Maryland like Marley Station Mall to tell them that their parking options are free because the average shopper is not going to spend three hours driving into another state just to arrive at a destination. As an editor who has done work on several articles about shopping malls and entertainment venues in the U.S. and some in Canada, is not crucial at all for the average building, especially office buildings. Aspifi (talk) 02:00, 24 May 2026 (UTC)[reply]

  It is e.g. notable when opera/concert reviewers in The New York Times, who are not used to on-site parking, remark on their surprise of seeing Washington venues surrounded by parking lots. -- Michael Bednarek (talk) 03:16, 24 May 2026 (UTC)[reply]

  Yes but its better to include that info outside of the infobox. Aspifi (talk) 03:22, 24 May 2026 (UTC)[reply]

  That can be said, and it has, about any part of an infobox. WP:INFOBOXPURPOSE is remarkably non-committal. OTOH, when did WP:ALMANAC get deprecated? -- Michael Bednarek (talk) 07:07, 24 May 2026 (UTC)[reply]

• Keep Cannot see how this would improve the encyclopaedia. Often relevant, seldom promotional. No violation of WP:NOTGUIDEBOOK. Hawkeye7 (discuss) 01:50, 24 May 2026 (UTC)[reply]

  Disagree - The average reader does not need to know that a building has a specific number of parking lots, let alone if it's free or not. Compare it to amusement parks where you need tickets; several events need tickets. Aspifi (talk) 02:03, 24 May 2026 (UTC)[reply]

  What about how this article that I wrote has it? Archives of the Impossible - what's the harm here...? — Very Polite Person (talk/contribs) 02:14, 24 May 2026 (UTC)[reply]

  In the case of public transit access, would only include if it's a notable or adjacent part of the building as described. For example Fashion District Philadelphia is connected to Jefferson Station (SEPTA). Aspifi (talk) 02:19, 24 May 2026 (UTC)[reply]

  The harm is that it is unnecessary information for an Infobox per MOS:INFOBOXPURPOSE. This is an encyclopedia, not a travel guide. As Traumnovelle points out above, if someone is interested in how to get to the Archives of the Impossible, they should go to the Library's website. This is not encyclopedic information. Zackmann (^{Talk to me}/_{What I been doing}) 02:19, 24 May 2026 (UTC)[reply]

• WP:IAR !keep then, and never thought I'd ever IAR first time over something like this. I really like having these here now that I've actually noticed them. But you're right, 100%. I got no counter argument. I had genuinely no idea these are omnipresent on Wikipedia. The first team I thought of was the Padres just now, and sure enough on Petco Park, there it is. And I see it as being encyclopedia worthy because it's also really just a little bonus mission-specific ==See also== that gives you for that article as an example:

# San Diego Trolley

# 12th & Imperial Transit Center

# Blue Line (San Diego Trolley)

# Green Line (San Diego Trolley)

# Orange Line (San Diego Trolley)

# Gaslamp Quarter station

For the low cost of this real estate:

Public transit: 12th & Imperial
Gaslamp Quarter

I dunno. I still remember the entire bottom third of my childhood bedroom closet that was just paper encyclopedias with text so small my now-aged eyes shudder in terror thinking of. Hundreds of pounds of books read cover to cover. Some rather sketchy back to the 30s, 50s. But it's 2026 and soon 2036, and what ought to be gets updated too sometimes. Keep. (Sorry, I was on the fence prior.) — Very Polite Person (talk/contribs) 02:52, 24 May 2026 (UTC)[reply]

Subsuming parking access and/or public transit access under WP:PROMO seems to be casting a very wide net. One wonders if by such logic any kind of transportation or accessibility information would count. I think we need to define WP:PROMO narrower than that. And I generally think that WP:NOTTRAVELGUIDE requires a lot of detail (cherrypicking one cafe is WP:UNDUE another policy) not one or two mentions. Jo-Jo Eumerus (talk) 08:45, 24 May 2026 (UTC)[reply]

• Keep - It's a real stretch to consider transit info WP:PROMO. I think we can dismiss that concern outright. WP:NOTGUIDEBOOK is closer, but I don't think a straight reading of that really applies here either. The text of that guideline is concerned almost entirely with explaining that Wikipedia should not make recommendations to users. (For example, list a city's best restaurants.). That's a worthwhile guideline, but I don't think it applies. To anyone who lives in a city, specifying what transit line a thing is on is a practical way of specifying a location. We include GPS coordinates, but "on the green-line" is a more human way of conveying that same information. It's not instructions or suggestions to the reader, it's location information. ApLundell (talk) 21:39, 24 May 2026 (UTC)[reply]

  "It's location information" Why do you think someone out of state wants to know how to get to a tourist attraction in Florida using an encyclopedia? I am going to quote WP:NOTTRAVEL directly: "while Wikipedia has descriptions of people, places, and things, an article should not read like a "how-to" style owner's manual, cookbook, advice column (legal, medical or otherwise), or suggestion box. This includes tutorials, instruction manuals, game guides, and recipes. Describing to the reader how people or things use or do something is encyclopedic; instructing the reader in the imperative mood about how to use or do something is not." Aspifi (talk) 21:52, 24 May 2026 (UTC)[reply]

  What part of stating "this airport is served by the city's metro" or "this theatre has on-site parking" is instructing the reader in the imperative mood about how to use or do something? People who live outside the state of Florida but who might consider a trip there are not the only people reading encyclopaedia articles about things in Florida that could be tourist destinations. Thryduulf (talk) 22:26, 24 May 2026 (UTC)[reply]

  If you are confident in your position, you don't have to reply to every single person who disagrees with you. I believe there is also a policy about that.

  Anyway, my position is unchanged. I continue to disagree that mentioning a transit line is "how to" style content or any other form of recommendation to the reader. To me, that assertion seems obviously incorrect, for reasons I've already explained. ApLundell (talk) 23:23, 24 May 2026 (UTC)[reply]

  It isn't describing how to do things, though, it's neutrally giving them information on transit links, which are encyclopedic information.

  I just started writing an article on Denbigh, Ontario. Should I remove the names of highways it connects to because, god forbid, people could use that information to go there? Cremastra (talk · contribs) 16:34, 27 May 2026 (UTC)[reply]

  The nomination is specifically for infoboxes about buildings, not cities/suburbs Aspifi (talk) 01:16, 28 May 2026 (UTC)[reply]

• Keep per my comment above. Per Thryduulf and ApLundell, Mentioning public transit connections is not instructing readers how to do anything. It's just mentioning them. Editors have to go out of their way to convey such information in a manner that goes against WP:PROMO or WP:NOTGUIDE anyway, and we already have methods to handle that. XtraJovial (talk • contribs) 00:38, 25 May 2026 (UTC)[reply]
• Keep these, at least in most of the infoboxes, but especially for the airports. I think they will often not be appropriate to use, but the parameter should be there for the situations in which it is appropriate. Saying that the Louvre is almost on top of a subway stop is not giving tourists directions; it's telling readers what's underneath that big glass pyramid of a skylight. WhatamIdoing (talk) 04:48, 26 May 2026 (UTC)[reply]
• Comment, I am not sure of the value of a parameter for parking, but I can see how the public transport parameter could be useful. If the infobox for a London landmark has the nearest rail/underground station, I would probably be able to visualise whereabouts in the city it is quite easily without having to zoom in/out on the map. EdwardUK (talk) 18:42, 26 May 2026 (UTC)[reply]
• Keep. I don't agree that listing the existence of public transportation access is PROMO or NOTGUIDE. If consensus were to reach that it is, I would agree with Very Polite Person that we should WP:IAR. I could see the value of having all of these public transit connections in the template because here is really the only place on the web that all of this info could be centrally listed. That would be very helpful for someone who is trying to research that, for example. So I think it does have potential encyclopedic value, even if you're someone in Texas looking up a place in Arizona. Parking could theoretically be PROMO so I think that should be treated case by case, but this conversation is about public transportation and I don't consider parking to be in that category anyway. Edittttor (talk) 20:45, 26 May 2026 (UTC)[reply]
• Keep, partially per Edittttor and partially per VPP. Public transit connections are often useful for locating a place within a city. I know if you told me which transit lines connect to a place in the city I live in that would be much more useful for envisioning where it is than coordinates. However, also, I think this information is useful enough that I'd favor an IAR override of WP:NOTTRAVELGUIDE even if it was unambiguously covered. I don't think it is, though. Loki (talk) 21:51, 26 May 2026 (UTC)[reply]

  I now agree but I still think providing parking information is unnecessary. Aspifi (talk) 23:22, 26 May 2026 (UTC)[reply]

• Keep, with the caveats mentioned by guninvalid and Jumpytoo. I don't think PROMO is a significant risk here, but there is a risk that excessive or trivial parking/transit information could have WP:NOTGUIDE or WP:DUE issues. That said, it's easy enough to think of various situations where transit access information is pertinent or noteworthy, with the result that I don't think it'd be helpful to proactively warn against including it. ModernDayTrilobite (talk • contribs) 17:01, 28 May 2026 (UTC)[reply]
• Keep the public transport information for two reasons. The first is already expressed by XtraJovial regarding whether such information violates WP:NOT in the first place. The second is that I worry about the wider implications to the article text. Per MOS:INFOBOXPURPOSE, as mentioned in the opening statement, The purpose of an infobox is to summarize, but not supplant, the key facts that appear in an article. If the information is inappropriate for mentioning in the infobox as a simple listing for violating WP:NOT, by extension it would imply such information should not be mentioned in the article at all in an elaborated prose manner. And I cannot possibly support opening up an opportunity for a blanket removal such that Changi Airport does not mention Changi Airport MRT station at all, or that Trafford Centre does not include The Trafford Centre tram stop, per WP:COMMONSENSE if not for anything else. S5A-0043🚎^(Talk) 02:59, 29 May 2026 (UTC)[reply]
• Comment - While this info may be relevant and DUE to include in the article, the infobox is different. The infobox should be summarising key details, not trying to cram in the whole article. Detail like this can be included in the body of the article without having to be in the infobox. Of course - if it isn't in the article body (and appropriately referenced) then it shouldn't be in the infobox either).Nigel Ish (talk) 09:23, 29 May 2026 (UTC)[reply]

  This ignores that in some cases parking and/or public transport is a key detail. Thryduulf (talk) 09:41, 29 May 2026 (UTC)[reply]

• Remove in most cases. In some cases the transit access is noteworthy, such as an arena that has its own subway station directly below it, a college that has a train station named for it, an airport where its integration into the transit network is key to its purpose. But in most cases these infobox params are heavily overused, being used to just note the nearest transit access that might be blocks away. Helpful if you're trying to navigate to that location, but not encyclopedic. See for example Washington Monument, which links to a metro station hundreds of yards away, or The Cloisters, which links 2 subway stations that are half a mile away and 3 bus lines that happen to pass nearby. Toohool (talk) 16:12, 31 May 2026 (UTC)[reply]

  As a note to anyone else who misreads as I did "remove" is not being used here to mean "remove the parameter", rather "keep the parameter but remove most uses of it in articles". Thryduulf (talk) 16:36, 31 May 2026 (UTC)[reply]

• Keep This would not be a meaningful improvement and the existing infobox parameters are non-intrusive and would not violate WP:GUIDEBOOK.LivinAWestLife (talk) 10:15, 2 June 2026 (UTC)[reply]
• Suggestion. This is probably not notable as encyclopaedic content but it is useful to some readers. Wikimedia already has a place for this sort of travel information, Wikivoyage. How about we remove it from Wikipedia but routinely link Wikivoyage instead? That way we keep Wikipedia encyclopaedic while still making it easy for people who want that sort of useful information to find it. (BTW, I strongly disagree that listing public transport is in any way promotional. It's not like bigging up a specific taxi company or something.) --DanielRigal (talk) 10:32, 2 June 2026 (UTC)[reply]

  The point is that the information sometimes is encyclopaedic content. Thryduulf (talk) 10:52, 2 June 2026 (UTC)[reply]

• Keep as a small amount of information like this does not make the article a guidebook. We may even have whole articles about bus stops, and most train stations and airports. When there are topics not notable in themselves, but supported by stuiable sources, then it can be included. Mentioning a provider name is not promotion if the coverage is due. So for example if one bus company is mentioned, then perhaps all the others should be included. But for a parking lot, perhaps we don't need to mention that it is operated by Wilson Parking. Graeme Bartlett (talk) 11:55, 2 June 2026 (UTC)[reply]
• Remove, but only per MOS:INFOBOXPURPOSE. This is not summarising key information, it's just adding extra to an infobox. I'm okay with it being outside an infobox, but not inside. In solidarity, FantasticWikiUser_{(Ts and Cs)} 20:17, 7 June 2026 (UTC)[reply]

  this is not summarising key information except where it is. Thryduulf (talk) 20:37, 7 June 2026 (UTC)[reply]

• Keep both the transit and parking parameter (which perhaps would have benefited from a separate thread) per the arguments above — this is significant encyclopedic information that meets WP:LEADWEIGHT in some but not all circumstances, and it should be retained so it can be used in those circumstances. It does not inherently make Wikipedia promotional or a guidebook. I will note that the parking parameter, at least at {{Infobox building}}, is explicitly scoped to on-site parking, not nearby unaffiliated parking, and this ought to be the case anywhere the parking parameter is used. Sdkb ^talk 20:30, 14 June 2026 (UTC)[reply]
• Definite Keep per Sdkb, useful and not promotional. – SJ + 20:45, 16 June 2026 (UTC)[reply]
• Lean keep. As others have mentioned, stating the public transport access is not promotion, otherwise, every single mention of any company would already have been considered “promotion”.

While Wikipedia isn't a guide book, I believe just a quick mention of the connections, which is basically those few lines in the infoboxes, are fine. And some pages rely on these train stations to explain their location!

The problem I’m seeing is that such mentions are unencyclopedic, which could be easily resolved via a tone revision. Additionally, not all pages about a place have a Wikivoyage equivalent, so there wouldn’t be a place to mention such connections other than the page on Wikipedia.

And about the parking spots? (idk why some people are mentioning it even though this is only about public transit access) I’m neutral about it, fine to keep if there’s a source available. Hason-LEK-SIN ● Let’s chat! ● My contribs 10:36, 22 June 2026 (UTC)[reply]

• Lean keep. I can see the NOTGUIDE argument and can sorta see the PROMO concerns but that seems like a stretch. Detailed information on how to get to a location or about the cost of parking would be inappropriate but the straightforward infobox params seem potentially useful and otherwise harmless, and can reasonably be considered part of the basic information about a place. I don't see the benefit of removal nor any evidence of harm. —Myceteae‍🌈 (talk) 16:27, 22 June 2026 (UTC)[reply]
• Weak remove per nominator's rationale. FaviFake (talk) 19:45, 23 June 2026 (UTC)[reply]

Replaced the link to the Portals space with a link to the Wikiprojects in Main Page.

Since 2017, The portal space continually lose space on Wikipedia, motivated by low readership and poor maintenance, WP:PWP and Wikipedia:Arbitration/Requests/Case/Portals#Community_discussion_recommended were ignored by the community. Analyze this graph [1]. Portals have been losing views in the last years. There have been many discussions about this, but the fact is that, after years, the status quo of the portal space, a skeuomorphic version of 1990s websites, remains the same. It is unclear what the purpose of this tool and the attempts to improve the portals don't seem to be moving in a solid direction (transclusions, for example, have solved some problems and created others).

In contrast to this depreciated state, portals enjoy prominent positioning at the Main Page via the link to Wikipedia:Contents/Portals on {{Other areas of Wikipedia}}.

Wikipedia:Contents/Portals is itself a very outdated page in terms of layout and content when compared to the others linked in the same template. Its last edition was in 2022, while the others have had recent editions, and unlike the others it doesn't use any modern styling tools like .css.

Wikiprojects are also largely neglected, but on the other hand, they do not face the same existential crisis as the portals, with many users calling for their elimination. And they have never been given a prominent spot on the main page. Some users felt that linking to them on the main page might be a good idea and could help revitalize the space.

Per Wikipedia:Portal#Purposes of portals "Providing bridges between reading and editing, and between the encyclopedia proper and the Wikipedia community, via links to pages in project space...", Portals are failing miserably in their mission, so this proposal serves to disintermediate, directing readers from the main page directly to the Wikiprojects.

1. Replace Wikipedia:Contents/Portals on {{Other areas of Wikipedia}} per WikiProjects (directory) – groups of contributors who work together to focusing on a specific topic area.
2. Replace Wikipedia:Contents/Portals on {{Other areas of Wikipedia}} per WikiProjects – groups of contributors who work together to focusing on a specific topic area.
3. Replace Wikipedia:Contents/Portals on {{Other areas of Wikipedia}} per other link related to WikiProjects.

Guilherme Burn (talk) 18:38, 10 June 2026 (UTC)[reply]

Support either, with a preference for 1. WikiProjects can get editors engaged by helping them find a sense of community, and are generally much more active than portals. The directory would help prospective editors find relevant WikiProjects faster instead of having to go through the information page (more disintermediation). Chaotic Enby (in solidarity · talk · contribs) 18:43, 10 June 2026 (UTC)[reply]

• Lean oppose. I'll be honest, I find portal somewhat baffling and don't spend much time with them. That said, the pageviews statistics you shared shows that all of these continue to get >2,000 views/month, which is more than many articles. WikiProjects serve a strictly behind-the-scenes purpose. Some WikiProject pages provide something of an overview of their content area but most don't. I don't follow the logic that WikiProjects are a good replacement for Portals on the main page, but perhaps there are separate arguments to add the project links. Outlines strike me as a better replacement for Portals, though these have their problems and detractors, too, and I'm not necessarily suggesting this. —Myceteae‍🌈 (talk) 01:40, 11 June 2026 (UTC)[reply]

  Hiding our "behind-the-scenes" pages is exactly what worries me, as it creates an artificial wall between readers and editors. Why shouldn't readers get to know how the encyclopedia is made and how they can help too? Chaotic Enby (in solidarity · talk · contribs) 08:02, 11 June 2026 (UTC)[reply]

  I have some initial reservations about sending tons of new editors to WikiProjects but I'm open to the idea and broadly supportive of increasing participation. In one of the discussions that the OP linked (Wikipedia:Village pump (idea lab)/Archive 79#WikiProjects in Main Page) the handful of participants seemed more or less supportive of linking WikiProjects on Main but the conversation stalled in discussing issues that may or may not need to be addressed prior to publicizing the projects in this way. Editors there noted that WikiProjects (like Portals) have varying degrees of maintenance and activity and that there are two different directories (Wikipedia:WikiProject Council/Directory and Wikipedia:WikiProject Directory) which might be linked to. Both directories were felt to (possibly) be in need of cleanup and it was not clear which would be better to link to from Main. It was noted that publicizing WikiProjects on Main could be broadly aligned with the WikiProjects 2.0 objective Wikipedia-wide recommitment to WikiProjects. After leaving my initial response, I read WP:PWP and some of the other essays and discussions on the topic of Portals. I was largely responding to the framing—that WikiProjects are a substitute for Portals and that we should link to one or the other from Main. I would decouple the decisions and assess the merits of linking to project and Portals independently. For some editors, part of the assessment may be that WikiProjects and Portals accomplish similar goals and linking both is redundant if one does so better. But I see them as having quite different functions and purposes and don't think it should be one or the other. If Portals are such a mess, we shouldn't link to them regardless of whether there is a replacement. If the goal is to find a replacement then Wikipedia:Contents or Wikipedia:Contents/Outlines seem more similar in function and purpose. If editors want to promote WikiProjects in this way, we should move that discussion forward whether or not we continue to link Portals. —Myceteae‍🌈 (talk) 14:56, 11 June 2026 (UTC)[reply]

  One of the misconceptions, I think, is "anyone can get a job editing, they won't just deny that," which was my (and other's) belief before. _{In solidarity}Wikipedian12512 (Talking is fine | contribs) 12:00, 16 June 2026 (UTC)[reply]

• From the last big discussion about Wikipedia:Contents, the impression seems to be that the community does not know what to do with it as a whole. How do the pae views for portals compare with the Contents pages in general? Separately to portals, I'm hesitant to promote WikiProjects as many of those are dead too. CMD (talk) 02:34, 11 June 2026 (UTC)[reply]

  I don't care (either way) about the portals, but I oppose promoting WikiProjects this way, because so many of them are dead. WhatamIdoing (talk) 18:19, 11 June 2026 (UTC)[reply]

Support any, 1 is the best. First of all, some seem to have brought up other Wikipedia's, but we are our own project and really the information brought up is tangential. Secondly, portals are an absolute confusing mess (built on the WikiProject system which is already a bit messy and has been proposed major changes many times over the years) that aren't really helpful. I can find out about things similar to what I am reading, by, ya'know, clicking the blue links everywhere. Ilov3gam3z (talk) 11:55, 12 June 2026 (UTC)[reply]

Why not both? I don't think the best answer to "this system isn't working as intended" is necessarily "let's throw it out completely". While I admittedly haven't used portals much myself, I think conceptually they're a great idea, and we could lean into them as a gateway to the Wikipedia-diving "rabbit holes" that people love so much. We could then additionally integrate portals and relevant Wikiprojects: portals could have links to relevant Wikiprojects in their subject areas, and the relevant Wikiprojects could take up the maintenance of the portal. Portals could even act like a "homepage" for these Wikiprojects, helping to bridge the gap between readers and editors. Athanelar (talk) 05:55, 16 June 2026 (UTC)[reply]

One thing I have seen people say is that portals failed due to proliferation: 10 core portals can easily be maintained, but 500+ are doomed. I wonder if something like that happens with wikiprojects as well. Military history, film, medicine, video games, and maybe a dozen others all chug along, but most are barely existing. I suspect that folding all of the topic wikiprojects (not RX, GOCE, WiR, URA, etc.) and all of the topic portals into a small subset with reader-facing portals would strengthen both the wikiprojects and the portals, but I also don't think that plan would get consensus. Rjjⁱⁱⁱ (talk) 02:47, 17 June 2026 (UTC)[reply]

There are other key differences. Projects are intended to be self-directed and self-sustained, and not reader-facing. Inactive or minimally active WikiProjects are (mostly) harmless whereas poorly maintained Portals may contain outdated or frankly erroneous information. —Myceteae‍🌈 (talk) 15:53, 17 June 2026 (UTC)[reply]

• Oppose. It may be instructive to look at the main page of other wikipedias.
  • French has a link to Portails thématiques top and centre in the header (where English Wikipedia's portal links used to be)
  • German links to its eight top level portals such as Geographie, bold top and centre
  • Spanish has a main page box listing and linking to over 50 of its main portals
  • Italian has a link to Naviga tra i portali tematici top and centre
  • Dutch links its top ten portals in the header, with a bold link to their portal of the week
  • Portuguese links to the a list of portals and directly to its nine broadest portals

English already makes portals far harder to find than in other major wikipedias (hence the lower page views), and there's no reason to hide them further. Certes (talk) 17:35, 11 June 2026 (UTC)[reply]

• Portals are failing because we've made them useless cluttered messes and created them for every random topic. Plugging an example I put together last year of how a clean portal design would facilitate editing with a "get involved" panel: User:Thebiguglyalien/Portal sample. Thebiguglyalien (talk) 06:56, 12 June 2026 (UTC)[reply]
• Regarding "poor maintenance", I think part of the solution is streamlining and automating portal maintenance where possible. If you check out Portal:FOSS, it is using {{top7}} and {{portal content}} which draw styling from a Portal-specific style sheet. Another part of the solution is narrowing down the portals. I think a start to that (and I may try something to this effect when I have the time) is to create clear criteria for deleting/keeping portals. Rjjⁱⁱⁱ (talk) 02:53, 17 June 2026 (UTC)[reply]
• Support per nominator's rationale. FaviFake (talk) 19:46, 23 June 2026 (UTC)[reply]
• Lean oppose Seeing the discussion and the arguments from both sides, why not try promoting portals on the English Wikipedia instead of abandoning it? I think that portals are a massive boon to building the web. Besides, not all WikiProjects list out all the articles that they are involved with, and many articles involve multiple Wikiprojects. Doing so might obfuscate the scope of the WikiProjects involved and make it more difficult for users to find precisely what they're looking for. I think portals as they are function quite well and what we should be discussing is how to promote them. Atakes Ris (talk) 11:07, 25 June 2026 (UTC)[reply]

Like the title says. _{In solidarity} Wikipedian12512 (Talking is fine | contribs) 02:44, 19 June 2026 (UTC)[reply]

TAs are just as apt to revert vandalism. This would just hamstring us. —Jéské Couriano v^_^v ^{Object Class: Drygioni} 02:50, 19 June 2026 (UTC)[reply]

They still could, but it would just take a bit longer, while the revert ability could be used to edit war. _{In solidarity} Wikipedian12512 (Talking is fine | contribs) 02:53, 19 June 2026 (UTC)[reply]

Do you have any evidence that the majority of reverts by temporary accounts are incorrect? Thryduulf (talk) 03:21, 19 June 2026 (UTC)[reply]

That would be an interesting (if subjective) statistic to collect. I suspect many TA reverts are self-reverts (or reverts by parent when they see what their little darling has done). Any preventative measure would be easy to evade. Certes (talk) 08:48, 19 June 2026 (UTC)[reply]

Agreed. And even if I (subjectively) think that a particular revert was "wrong", that doesn't necessarily mean it was disruptive. Good-faith reverts by editors who don't have the full context are a dime a dozen. I also agree this would be easy to evade, especially by determined bad actors. A "revert" can be accomplished by simply deleting text. It would be strange to say that temp accounts can only add text and I'm not even sure that capability is possible. —Myceteae‍🌈 (talk) 03:51, 20 June 2026 (UTC)[reply]

Looking at recent changes, 197 of the most recent 500 edits by TAs with the Undo tag are also tagged as Reverted. Danski454 (talk) 00:38, 20 June 2026 (UTC)[reply]

A banned user is currently at large. Typically they edit as a TA, correctly get reverted, try again* and get reverted again. The starred edit is a TA undo (of the first revert) with the Reverted tag. Example target: James Wattana. Certes (talk) 13:14, 20 June 2026 (UTC)[reply]

Is this even possible to do? Sure, you could remove the undo button presumably fairly easily but that doesn't stop manual reverts. 45dogs (they/them) (talk page) (contributions) 08:58, 19 June 2026 (UTC)[reply]

Doesn't seem like a good idea to me. Most bad edits are not reverts. A revert just takes you back to an earlier version, usually a more stable one, one that's had more opportunities to be examined. --Trovatore (talk) 00:54, 20 June 2026 (UTC)[reply]

Agreed. Of course reverts can be problematic—any edit can be—but by definition they are just restoring something that was already there. —Myceteae‍🌈 (talk) 03:45, 20 June 2026 (UTC)[reply]

A very ill-thought-out proposal. Even experienced contributors self-revert for multiple legitimate reasons, and preventing TAs from doing the same is effectively ruling out self-correction. Or at least, it would be, if it wasn't so easily worked around. A bad fix for the wrong problem. AndyTheGrump (talk) 13:25, 20 June 2026 (UTC)[reply]

I've seen many TAs, or previously IPs, get rollbacked when what they've removed was a BLP violation or otherwise should have been removed. -- LCU ActivelyDisinterested «@» °∆t° 13:57, 23 June 2026 (UTC)[reply]

I believe the proposal is contrary to the purpose of Wikipedia as an open platform. In running an encyclopedia such as this, while devoted to it's mission, things that can't be adressed or are hard to adress arise. Anyone being able to edit unless special circumstances aply is a pillar of Wikipedia as per Wikipedia:5P4 "Wikipedia is free content that anyone can use, edit, and distribute". The issue of TA reverts as far as I see is nowhere near severe enough to further narrow the intrepretation of this pillar, because restrictions have been increasing all the time as it is. Finfixer (talk) 14:46, 23 June 2026 (UTC)[reply]

Strongest possible oppose - This locks TAs out of doing any meaningful counter-vandalism work. We do not need to decrease the number of people doing counter-vandalism work (and yes, they can sign up, but will they?) Gnomingstuff (talk) 18:54, 25 June 2026 (UTC)[reply]

Oppose per the comments above. Some temporary accounts I've seen have done very constructive anti-vandalism work around here, and they should not be restricted to a basic feature for simply being unregistered. Reminds me of the essay WP:HUMAN. I also found a similar proposal in the past that didn't go through: Wikipedia:Village pump (proposals)/Archive 183 § Preventing IP editors from creating article talk pages. Justjourney (talk | contribs) 18:50, 30 June 2026 (UTC)[reply]

Oppose Of all possible malign edits open to a TA, a revert it the soonest noticed — by the reverted author, who (unless they also are unregistered) gets notified of the revert, and has the strongest motive to get it right. Doug butler (talk) 21:52, 30 June 2026 (UTC)[reply]

Okay, this is a bit of radical idea even by my standards but hear me out. I think we should retire the name "Move" for renaming pages and call it "Rename" instead. Meaning on the sidebar of articles it should be changed to "Rename" (by changing MediaWiki:skin-action-move and all similar pages, including updating the documentation such as Wikipedia:Moving a page).

Why?

• It is quite confusing to newcomers and newbies. I do outreach and it's always confusing to them. I think it can make contributing more welcoming to new users and remove one small cognitive burden on them.
• Everywhere else on the internet it's called "rename". Even in wiki-world, for renaming users, it's called rename and not "moving users".
• It is hard to translate and causes confusion (phab:T294188#12035015 and phab:T429657#12036692) and in many languages such as Russian, it's already translated to "Rename" instead of "Move"
• It has contributed to people picking really unsuitable icons for this action (see phab:T294188). It's currently which doesn't make any sense to me.

There is no need to make technical changes (unless I'm missing something super obvious), nothing would break when we change the labels only and we have had the precedent of renaming thins before (image -> file, "save" button -> "publish" button). The ticket for it is phab:T429657. Ladsgroup^overleg 17:49, 20 June 2026 (UTC)[reply]

• Support as the proposer Ladsgroup^overleg 17:49, 20 June 2026 (UTC)[reply]
• Support, given the greater ambiguity of "move", which can also apply to merely moving content within an article, or to various other meanings of Move. BD2412 T 18:19, 20 June 2026 (UTC)[reply]
• Support per nomination. Aspifi Talk to me! 18:24, 20 June 2026 (UTC)[reply]
• Support per nom, although we have to keep into consideration that all of the move-related templates and processes (like Wikipedia:Requested moves) might have to be adapted for consistency, and also the tools relying on them such as Twinkle. A bit more ambitious that it appears on the surface, but definitely doable. Chaotic Enby (in solidarity · talk · contribs) 18:26, 20 June 2026 (UTC)[reply]

  @Chaotic Enby if someone is using gadgets or twinkle, they'll be able to handle multiple names. As the user rights group won’t be renamed anytime either. ~ In solidarity 🦝 Shushugah (talk) 22:16, 20 June 2026 (UTC)[reply]

• Comment Rename seems like a clearer name for moving within a namespace. What about other cases, e.g. Draft:Foo to article Foo in mainspace? Perhaps that really is a move rather than just a rename. As an analogy, some operating systems distinguish between renaming a file (change the filename only) and moving it to a different directory (folder) or device. Certes (talk) 18:44, 20 June 2026 (UTC)[reply]

  @Certes That is valid but I looked at the data and it seems it most moves are inside one namespace (74% of moves in English Wikipedia are inside one namespace see phab:T429657#12035947). I was thinking that it the special page and the help page could start with something like "Rename the page or move it between namespaces" but the label for it could be Rename as it's more newcomer friendly + it's the majority of cases. Ladsgroup^overleg 19:26, 20 June 2026 (UTC)[reply]

  that is all renaming still, with different implied permissions. Restrictions for renaming might be name collision, topic protected, salted, namespace restrictions etc and no name will capture all of the technical scoping there. New editors will continue to be confused by WP:IMAGE IMAGE And HELP:IMAGE among other namespaces. ~ In solidarity 🦝 Shushugah (talk) 22:20, 20 June 2026 (UTC)[reply]

• We don't have a "rename" for pages - this is literally a move, especially for cross name space moves. Moving between namespaces can be significant for multiple reasons - we shouldn't pretend it is something it is not. — xaosflux ^Talk 19:01, 20 June 2026 (UTC)[reply]
  • Quite frankly, actions that change the substantive title of a page should be considered separate from actions that change the namespace of a page. BD2412 T 19:18, 20 June 2026 (UTC)[reply]

    This makes some sense. Even if it's the same process from a technical standpoint, there is an operational difference between moving between namespaces and changing the title of an article (or any other page). "Renaming" Draft:Foo to Foo sorta minimizes what's being done. —Myceteae‍🌈 (talk) 19:44, 20 June 2026 (UTC)[reply]

  • On the technical level, even moves between namespaces is still just a rename. The page id stays the same and page_title (basically the label of the page) changes. One could argue if wikipedia were a book, that would mean we are moving an entry from page 123 to page 456 but WP:PAPER. On "we shouldn't pretend it is something it is not." We do that all the time for the sake of usability. For example, deletion of a page is not really deleting it. It's just hiding it. Ladsgroup^overleg 19:30, 20 June 2026 (UTC)[reply]

    Perhaps a move between namespaces is more like moving the hypothetical paper page into a different volume. Certes (talk) 19:52, 20 June 2026 (UTC)[reply]

    Or to the table of contents or an index or afterward or supplementary material or endnotes or forward… The namespace both defines and is defined by the type of content, its purpose and function. When we move something to a different namespace we are reclassifying it in a way that is meaningfully different than a mere name change. Whether or not it's useful of worthwhile to maintain a difference in the lingo, I'm not sure. —Myceteae‍🌈 (talk) 20:38, 20 June 2026 (UTC)[reply]

    Yes, I'd agree with all of that. Certes (talk) 20:46, 20 June 2026 (UTC)[reply]

  • ...when you say "this is literally a move," you don't mean that, right? I mean, it's quite literally not a move, because a page name is, literally, not a location, and when we change the name of a page we are not like, literally, moving bits and bytes from one place to another, we're just changing the letters. Renaming something is not the same thing as moving something, and a namespace is not actually a space. That's just the label we gave to a prefix. Levivich (talk) 14:11, 24 June 2026 (UTC)[reply]

    I like to think of it as follows: You have Page A, which can be found at en.wikipedia.org/wiki/Page_A. You retitle/move/rename it to Page B. The same page contents can now be found at en.wikipedia.org/wiki/Page_B, but you can still reach the page by going to en.wikipedia.org/wiki/Page_A, which will redirect you to en.wikipedia.org/wiki/Page_B. Therefore, the apparent virtual location of the page has changed. Even if all that really changes is a value in the database labeled "page title", to the end-user, it looks like the page has "moved", because it's now accessible from a new URL. SuperPianoMan9167 (talk) 19:36, 25 June 2026 (UTC)[reply]

    That may be how you think of it, but it's not how everyone else thinks of it. And as evidence for how everyone else thinks of it, I submit that on Windows, Mac, Google Drive, OneDrive, iCloud, WordPress, and just about every major software system in the world, when you change the name of a web page or other file, it's called "rename," not "move." AFAIK, among major software, only Unix and MediaWiki call changing the name of a file a "move." The vast majority of the world calls it a "rename." This fact really isn't debatable, and if we want more editors, we should use nomenclature that is familiar to them, even if you or I might think of it differently. Levivich (talk) 14:54, 26 June 2026 (UTC)[reply]

    As has been repeatedly explained though, the reason MediaWiki calls changing the name of a file "move" is because it moves it. Thryduulf (talk) 15:06, 26 June 2026 (UTC)[reply]

    As has been repeatedly explained though, no, the MediaWiki "move" function doesn't actually move anything. Nothing changes a location, not in the physical world, nor electronically on the hard disk, nor virtually in a conceptual file system, with the sole exception of changing namespaces. (I, once again for the umpteenth time in many years, beseech you to stop writing "as has been explained" in your comments, when you're referring to disputed arguments. It's pretentious.) Levivich (talk) 15:58, 26 June 2026 (UTC)[reply]

    I'm not talking about file systems. The page is moved from one title to a different title along with all it's edit history, leaving a redirect in its place (unless specifically suppressed). However others have actually explained what changes in the database, etc. you can disagree with those facts but that doesn't mean they are incorrect and doesn't mean that it has not been explained to you that you are incorrect. What mediawiki does is much more accurately described as moving than it is described as renaming, but even if that were not the case making a few small changes will not solve the problem you want to solve, making all the changes required to actually solve that issue will cause disruption that is orders of magnitude greater than that problem does and it will cause new problems that will cause their own disruption (e.g. more well-intentioned moves of pages that shouldn't be moved (to the selected title)) that will need to be cleaned up. Thryduulf (talk) 16:30, 26 June 2026 (UTC)[reply]

    When we change the page title from "Kiev" to "Kyiv," the page does not move. It does not change namespaces. It does not change location in the file system. It does not change location on the hard drive. It does not change location in the physical world. It does not move, in any sense of the word move. What MediaWiki actually does -- change a string of text in a database from "Kiev" to "Kyiv" -- is more accurately described as "renaming" than "moving." I and others have actually explained what changes in the database, etc. You can disagree with those facts but that doesn't mean they are incorrect and it doesn't mean that it has not been explained to you that you are incorrect.

    (See how easy it is, and how frustrating it is, to describe arguments as explanations, and to assert that someone who disagrees with you about a characterization is factually incorrect?) Changing the name we call it from "move" to "rename" involves nothing more than changing some text files on this website, it doesn't even require changing the code (although that is also easy to do, it's just a search-and-replace of text, from "move"/"moving" to "rename"/"renaming"). Levivich (talk) 17:07, 26 June 2026 (UTC)[reply]

    When we change the page title from "Kiev" to "Kyiv," the page does not move. except it does. It moves from https://en.wikipedia.org/wiki/Kiev to https://en.wikipedia.org/wiki/Kyiv with the former location now being a different page altogether (a redirect). When the namespace is changed as well it's even more clearly a move.

    Other people have repeatedly explained that it is not just a matter of changing a few labels, nor doing a find and replace. It has also been repeatedly explained how much disruption making those changes would cause, yet you continue not to acknowledge these things and keep insisting that changes would be trivial and cause no disruption. Thryduulf (talk) 18:35, 26 June 2026 (UTC)[reply]

    Thryduulf, I've now twice asked you, just in this conversation, not to condescend to me by saying "as has been repeatedly explained" and variations thereof, in addition to the many times I've made this request in our past interactions over several years. Why do you continue, in each and every reply, to say "as has been explained"? You know it bothers me, so why are you repeatedly doing it? Are you intentionally trying to upset me? Because I'm telling you in no uncertain terms: it upsets me. It's condescending. It's pretentious. Please don't do it. Even if you do it with others, even if you do it with me in the future, at the very least don't do it again in this discussion with me. Can you do that for me, as a colleague of yours?

    A change from https://en.wikipedia.org/wiki/Kiev to https://en.wikipedia.org/wiki/Kyiv is not "moving" the page. The page stays at the same location in the file system. That location is https://en.wikipedia.org/wiki/Kyiv. Specifically, it's the folder /wiki/Kyiv. That folder -- insofar as it is a virtual "location" -- does not change, when you change the name of the file from Kiev to Kyiv.

    Nobody has "explained," or even argued, that effectuating this change would require anything other than changing our text documentation to use the word "rename" instead of "move". That doesn't require changing the code. Even if we decided to also change the MediaWiki code, we're still just talking about changing the name of a function, from "move" to "rename." This is also just changing a text string. What is being proposed here is changing a label we use to describe something; nothing more. Levivich (talk) 19:02, 26 June 2026 (UTC)[reply]

    I apologise for offending you, that is not my intention, it's just that when I find myself repeating the same facts and explanations over and over again I have a tendency to say that that is what I am doing.

    The rest of your comment is moving into denying of reality so I'm going to disengage now as it's clear I'm not going to convince you that black is not white. Thryduulf (talk) 19:13, 26 June 2026 (UTC)[reply]

    Can you please refrain from using confrontational terms such as "denying of reality"? I don't agree with everything people are saying, but I appreciate there are different viewpoints on what conceptual model is best to use. I can disagree with others without saying they are denying reality. isaacl (talk) 22:06, 26 June 2026 (UTC)[reply]

    To avoid any confrontation or annoyance, I suggest that for Levivich & Thryduulf, you don't continue on this specific point without any new information because you'll keep repeating yourselves which is the reason for the irritation. You've both made your positions clear, so absent anything new, you might just have to agree that you disagree. My understanding of Thryduulf's point is that it's not a "rename" in that Kiev doesn't just turn to Kyiv in all the relevant places, but that the latter is created, & former's data is (stripped/moved) to the latter's position, & then the former is modified to be a redirect to the latter. I get that often what people care about when they "move" is just they can work with a new name (the renaming aspect), but perhaps it's good for them to understand what goes on (that it's actually a new thing being created and not just 1 thing being renamed). It'd also make them understanding cross-namespace moves easy too so they don't get confused by how that uses the same process Theo wiki user (talk) 09:10, 27 June 2026 (UTC)[reply]

    @Isaacl @Theo wiki user I've expressed that I wish to disengage. Please do not ping me (or expect a response if you mention me) with respect to, at least, Levivich's contributions to this discussion. Thryduulf (talk) 09:19, 27 June 2026 (UTC)[reply]

    Though I appreciate why changing the labels referring to a page can be considered conceptually a move, personally I don't agree that preserving the edit history fits into this viewpoint. To me, renaming a page implies that it remains the same object that it always was, just with different labels attached, and so the edit history should be preserved. isaacl (talk) 17:16, 26 June 2026 (UTC)[reply]

• Comment: There is a lot I like about and agree with in this proposal. I've gotten quite used to our jargon but even I occasionally find it awkward. I sometimes find utility in conceptualizing it as a move, for example when multiple subpages will be impacted or, as another editor has raised, when switching from one namespace to another. Of course there are other ways to convey this, and just calling it a move actually doesn't really do this, and none this applies to article title changes, which are probably most relevant to most editors. —Myceteae‍🌈 (talk) 19:48, 20 June 2026 (UTC)[reply]
• Oppose This would just cause unnecessary chaos and churn. The term "move" is fine as is. * Pppery * _{(alt) in solidarity} 21:10, 20 June 2026 (UTC)[reply]
• support way more accessible to the general population. Should have been done 20 years ago. May suggest also taking some inspiration from Commons, which turns the link onto a request for renaming form for those without the permissions. —TheDJ (talk • contribs) 21:50, 20 June 2026 (UTC)[reply]
• Strong support we should use accessible and non-jargon language where possible. ~ In solidarity 🦝 Shushugah (talk) 22:26, 20 June 2026 (UTC)[reply]
• Comment: "Rename" could overlap with the term "rename the user", which might still cause potential confusion. Are there any considerations for using alternative terms, such as "relocate" or "retitle" other than the term "rename"? Hakimi97 (talk) 00:01, 21 June 2026 (UTC)[reply]

  Well, they are both connected as they are similar processes, like @Ladsgroup pointed out. If anything, we can also see this from the consistency angle. Chaotic Enby (in solidarity · talk · contribs) 00:10, 21 June 2026 (UTC)[reply]

• Comment: Should this be posted at T:CENT, considering this proposal regards a very visible part of the interface? I was thinking of listing this there myself, but I feel like it is best to play it safe. - BlueEleephant (talk · contribs) 00:22, 21 June 2026 (UTC)[reply]

  Fully agree with CENTing it, although I'm on the more open side regarding listings there so don't take my opinion as anything definitive. Chaotic Enby (in solidarity · talk · contribs) 00:58, 21 June 2026 (UTC)[reply]

  If changing most (if not all) instances of move in the software really is as ambitious as you said in your first comment in this thread, then chances are, this would be a big enough chance to warrant listing on T:CENT. Although, the move feature is very visible like I said above, so I think I have changed my mind, and will go list it at T:CENT per WP:BOLD. - BlueEleephant (talk · contribs) 01:06, 21 June 2026 (UTC)[reply]

   Done. - BlueEleephant (talk · contribs) 01:14, 21 June 2026 (UTC)[reply]

• Cautiously supportive. Not sure if any other issues will arise, but the namespace issue does not bring me to oppose. For the purposes of most users, the namespace is indicated through the name. Neither word seems intrinsically more technically correct. CMD (talk) 00:46, 21 June 2026 (UTC)[reply]
• Oppose. Don't fix what isn't broken. I sincerely doubt that this is seriously confusing to new editors or that a common word in the English language can be construed as jargon. There should be a consistency in naming page moves that are within the same namespace and those that are between different namespaces - and "rename" does not meaningfully apply to those between namespaces.Katzrockso (talk) 01:16, 21 June 2026 (UTC)[reply]

  @Katzrockso, do you do any mentoring or Teahouse monitoring? It frequently confuses newcomers. In solidarity, asilvering (talk) 03:38, 21 June 2026 (UTC)[reply]

• Eh. I think that "move" represents the idea of page names being "locations", which is how the software works. A title is a fixed location that a page is "moved" to. Changing to "rename" might solve some confusion, but it's only temporary confusion – any editor wanting to rename a page should understand the process and ramifications first, and that includes the verbiage, to a lesser extent. This is a well-intentioned proposal, but it will create a lot of work: requested moves becomes "requested renames", for example. Rename review (RRV?🚐) Page mover would need to be "Page renamer". If we went full-steam on this, it would result in confusion when looking at past discussions using different shortcuts and jargon. If we opt for a half-measure, it will cause immediate confusion, which is counterproductive. ASUKITE 01:27, 21 June 2026 (UTC)[reply]
• Oppose Moving can be far more complex than just renaming. On the other hand, renaming is technically a move so it would be better to call it that. Masem (t) 01:36, 21 June 2026 (UTC)[reply]
• Support clearer for newcomers, consistent with virtually everything else within a computer system (we don’t move Word Documents, we rename them, as an example), and in the extremely rare cases where renaming a page is complex, it’s really only long-standing power users who are doing it, so it’s not like this will confuse them. TonyBallioni (talk) 02:48, 21 June 2026 (UTC)[reply]

  If you're on a unix-like system, you move files; you don't rename them, so that's really not always true. –Deacon Vorbis (carbon • videos) 19:17, 22 June 2026 (UTC)[reply]

  Yeah but what's Unix's market share? 95% of users (windows and mac) "rename" files. And there's a reason: calling it "rename" makes sense when you change the title of a file. "Move" is when you change the location of a file in the file system (but not the file's title). Levivich (talk) 14:16, 24 June 2026 (UTC)[reply]

  On a side note, Mac users have been Unix users for a long time now. On less of a side note: both on Unix and Windows, moving a file on the same hard drive volume doesn't actually move the file's physical location. The choice of "mv/move" as the shell command on Unix/Windows is a semantic one, and covers both moving files across hard drive volumes and within a volume. The abstraction placed on top of this by your file manager (Windows Explorer/MacOS Finder/your favourite Unix file manager) can make a different semantic choice. isaacl (talk) 17:19, 24 June 2026 (UTC)[reply]

  Mac users are not Unix users. MacOS is based on Unix, it is not the same thing as Unix. Almost nobody uses shell commands, terminal commands, or command line at all -- 95% are using graphical OSes like Windows and MacOS. Levivich (talk) 14:50, 26 June 2026 (UTC)[reply]

  More precisely, it is a Unix branded system based on NeXTSTEP and BSD.-- Shmuel (Seymour J.) Metz Username:Chatul (talk) 15:54, 26 June 2026 (UTC)[reply]

  Like I said, this is a side note, because regardless of what happens under the hood, we can choose whatever conceptual model we want that best serves users. I only brought it up to clarify that under the hood, the underlying OS APIs are Unix-based. isaacl (talk) 16:55, 26 June 2026 (UTC)[reply]

• Support the "move" to "rename". GoodDay (talk) 03:08, 21 June 2026 (UTC)[reply]
• Support per TonyBallioni. The work involved to implement this is a one-off task which is very well worth doing given the significant conceptual improvement that it provides to newcomers. MichaelMaggs (talk) 03:53, 21 June 2026 (UTC)[reply]
• Weak oppose (was convinced by Godsy). When I first learned of moving I was also confused why it wasn't called renaming, as (it seemed) it was just changing the title. As I learned more I reconceptualized it as moving the page and its history to a new URL, which is why a copy-paste move is not equivalent. Like Asukite I find that more accurate to the way moving works, and don't think the transition cost is worth it anyway. Sophocrat (talk) (from an alternative account) 04:11, 21 June 2026 (UTC)[reply]
• Comment: if this passes, there should be a full list of pages, categories, templates, and tools that need to be updated so we won't end up with inconsistent terms. Gonnym (talk) 04:24, 21 June 2026 (UTC)[reply]
• Strong oppose - This would require a vast amount of change to the infrastructure surrounding page moves, which should not be understated. Many templates, categories, policy, guidelines, essays, and even a user right. Depending on the implementation, it might even affect userscripts and modules. Anyone wishing to go beyond a surface level understanding of a page 'rename' would have to understand the move concept to read any discussion about the topic that has taken place in the last 25 years. It also minimizes the concept of redirection; what is left behind during a move is extremely important. It will likely collide in spots with user renaming infrastructure. The benefit is purely semantical (and neither way of saying it is obscure or wrong); the burden on the community to implement this is extremely high. If one cannot come to an understanding regarding what is a page move, then they probably should not be moving a page anyhow. — Godsy ^(TALK_CONT) 04:49, 21 June 2026 (UTC)[reply]

  It's just effort though. Compared to how much time people spent being confused, it probably pales to that. By this metric, almost anything that we want to change will become an unsurmountable mountain. Are we really letting a bit of effort block us from achieving relatively 'simple' changes ? That seems pretty defeatist to me. —TheDJ (talk • contribs) 14:48, 22 June 2026 (UTC)[reply]

  Maltazarian expands on the matter well below. This is not 'a bit of effort' but rather a grand undertaking. That aside, how much 'confusion' move terminology may or may not cause is largely anecdotal (at least what has been presented so far). The squeaky wheel gets the grease anyhow; e.g. those who are new and understand the move system without issue are unlikely to show up at the teahouse and praise our process (and they could very well be in the vast majority). Who is to say this will actually move levels of confusion in any particular direction? Any change is 'just effort'; what needs to be determined is whether the effort is worth it. The bar for that has no where near been met in this case. I had a well-simmered retort to your defeatist accusation, but I am going to refrain as it would be unproductive. — Godsy ^(TALK_CONT) 01:24, 23 June 2026 (UTC)[reply]

  I don't think it's a grand undertaking. Also, we don't have to let the perfect be the enemy of the good; we could move/rename a couple of pages, and people would figure it out. There's no reason why Wikipedia:Moving a page has to be at that title and can't be at a title like Wikipedia:Changing the name of an article instead. WhatamIdoing (talk) 01:28, 24 June 2026 (UTC)[reply]

  We could move/rename a couple of pages, and people would figure it out. Yeah.... I mean, why not? New editors who make it to the technical guidance pages and read things besides the title (something I did very often as a newbie) can be completely and utterly confused when they cannot find the 'move' function described there. I, for one, love a big broiling mess to cleanup in our backrooms across guidance pages, essays, redirects, templates, and venues, just to name a few, without a plan. People (supposedly) struggle with a concept with well-worn wayfinders; let's flood it all to make sure to keep the stuggle-boat afloat! Putting a pin in that, the sparsest thing in this proposal discussion is anyone actually providing evidence that the proposed change is indeed good! — Godsy ^(TALK_CONT) 04:43, 24 June 2026 (UTC)[reply]

  Or just call it WP:Moving (renaming) a page. JoelleJay (talk) 20:12, 28 June 2026 (UTC)[reply]

  We renamed "sysop" to "administrator" years ago. We don't need to change that infrastructure so fast. In solidarity, Aaron Liu (talk) 15:50, 22 June 2026 (UTC)[reply]

• Oppose. As others have noted, this is not just a matter of adjusting some guidelines, but would require an actual code rewrite of the Wikimedia software itself, because the tools and user rights use "move", not "rename", all to fix something which is not actually broken. And from my point of view, nothing is wrong with the "move" idiom. It isn't just changing the title of the page, it is moving the location of the page to a new URL. Sławomir Biały (talk) 08:17, 21 June 2026 (UTC)[reply]

  I'm not sure I understand this. What software exactly needs rewriting? As people pointed out, Mediawiki internally still calls admins sysop and as someone who knows Mediawiki well, I say that we can do this without a single line of code change in Mediawiki. Of course, we can do clean ups later but they are nice-to-haves and not really required (as sysop vs admin). Even then, there is no need to rewrite anything. For example, MovePage class would need renaming but we (devs) rename classes all the time. Ladsgroup^overleg 15:11, 21 June 2026 (UTC)[reply]

• Oppose - while I understand the issues with newcomers (it certainly confused me early on), I frankly view it as an "if it ain't broke, don't fix it" situation. Firstly, on a technical basis, its more accurate, per above. Secondly, it would require an enormous amount of technical modifications that simply aren't worth it for what seems to be something that can be explained in under 30 seconds. A comment I would like to make however is that as a Wiki-archaeologist, I know that the term "syop" was used in Wikimedia software way back in the day, before eventually being moved to administrator. Did this require a massive technical change, or was it just softcoded in (i.e, were/are the terms syop and administrator harcoded or does Wikimedia code still uses "syop", but have the word administrator softcoded on top)? — Knightoftheswords 10:49, 21 June 2026 (UTC)[reply]

  i think but not 100% sure that the code technically still uses syop but it was changed on the user facing side to be administrator not sure how much technical changes were done to change the user facing name Isla🏳️‍⚧ 12:07, 21 June 2026 (UTC)[reply]

  Internally the group is still "sysop", for example it's Special:ListUsers/sysop rather than something like Special:ListUsers/administrators. Anomie⚔ 12:34, 21 June 2026 (UTC)[reply]

  I think they've always been called administrators colloquially. See the page Wiki Administrators on the Nostalgia Wikipedia, but that pre-dates MediaWiki. This edit from March 2002 is the first use of the word "sysop" on the Wikipedia administrators page, back when Wikipedia used Phase II software. Graham87 (talk) 05:05, 22 June 2026 (UTC)[reply]

  Changing the name of roles in MediaWiki is simple in the scheme of things. – The Grid (talk) 12:51, 24 June 2026 (UTC)[reply]

  Would it convince you if I take responsibility for doing the work? let's say it's a lot of work both on-wiki and software, just drop it on me and I do it. If I miss anything, ping me or talk page message and I get to it.

  It shouldn't matter that it'd be a lot of work if someone else is doing it 😅 Ladsgroup^overleg 15:14, 21 June 2026 (UTC)[reply]

• Oppose at least for now. The suggested benefits do not seem to outweigh the amount of work that would be required, and the scope of that work isn't even entirely clear. I'm particularly not convinced by phab:T294188 as a "benefit"; if the people making UIs don't understand things well enough to choose a good icon, I think renaming the things is just hiding the real problem. Anomie⚔ 12:41, 21 June 2026 (UTC)[reply]

  FWIW I originally suggested it on phab:T294188 as something that should be done because it is a frequent issue for translating from English to other languages (‘move’ isn’t a common word for the sense of renaming a page to a new location everywhere), so I don’t think it relates just to whether the icon for it is good or not. There are more benefits than that, so it’s not about ‘hiding’ that problem. stjn 17:40, 22 June 2026 (UTC)[reply]

  The title of phab:T294188 is literally The icon for "Move" is far from intuitive. It was brought up in the proposal here specifically in relation to the icon. Whatever other concerns you have with translations (and IMO those could probably be better solved by explaining in the qqq message than by hoping that one single word is always clearer than another one), it's not really on topic for that task. Anomie⚔ 23:26, 22 June 2026 (UTC)[reply]

  Requiring every message related to moves to mention in its documentation that moves actually mean renames but enWP community is too anal about changing it because of hysterical raisins is a solution, but probably not the solution. Hopefully what we’ll end up on eventually is that enWP continues to call it moves (as it seems this is the emerging opinion) while the overall MediaWiki localisation switches to renames. Because at the end of the day the word rename is just objectively clearer than the word move because it has no semantic ambiguity, even if some languages might prefer to continue to translate its meaning as ‘move’ instead. stjn 23:37, 22 June 2026 (UTC)[reply]

  I suppose someone could be that petty. 🙄 Or we could use a much more useful qqq message. Personally, I hope what we end up with is dropping this suggestion based on a handful of people's assertions, rather than wasting a ton of time changing the name for what seems to be very hypothetical benefit. No matter how often you assert that "rename" is "objectively clearer" despite many others here finding it inaccurate for many types of moves. Anomie⚔ 23:45, 22 June 2026 (UTC)[reply]

  It is objectively clearer for the purposes of localisation, which is what I was referring to. Your personal grudge against Amir (which on the substance I somewhat agree with, for the record, having called the thumbnail size diktat ‘the most destructive interface change in a long time’) doesn’t change the fact that having less semantic ambiguity is better for interface translation, and adding a template about it in every move-related message (it’s not like it’s just one of them, it’s probably at least a hundred) is a much more messy (and unfortunately forgettable) solution. Talk about being petty :-) stjn 23:54, 22 June 2026 (UTC)[reply]

  Between "supposed semantic ambiguity, that could be clarified with a little work" and "seen as actually wrong in some cases", I'd still go with the one that's not wrong.

  P.S. I find 94 messages in languages/i18n/en.json that contain the word "move", "moved", "moves", or "moving" in the value, case insensitive. Most but not all refer to page moves, e.g. MediaWiki:mergehistory-fail-toobig or MediaWiki:diff-paragraph-moved-tonew, and some wouldn't necessarily make sense to change from "move" to "rename", e.g. MediaWiki:log-action-filter-protect-move_prot or the first instance in MediaWiki:movepagetext. Anomie⚔ 00:26, 23 June 2026 (UTC)[reply]

  I suppose MediaWiki:Movepagetext actually needs to be rewritten to never use the word ‘rename’ there given what some people here seem to suggest in regards to cross-namespace renaming :-) stjn 01:38, 23 June 2026 (UTC)[reply]

• Oppose Title (Name) is under WP:TITLE, move is under WP:MOVE, they are subtly different inquiries: to paraphrase, one is, is this the best title (name) for this subject, the other is, should this subject be anywhere else but here. Or 'name' is substance, move is process.-- Alanscottwalker (talk) 12:59, 21 June 2026 (UTC)[reply]
• Comment. Information on page names is under WP:PNAME. To summarize what one can read over there, a page name is often the same as the page's main title, but the page title is, well, a title. A page name is also often part of the URL, and encoding seems to make the distinction matter. To make matters worse, we have concepts of namespace, pagename, and fullpagename. Not sure I'd go so far as to say none of this is broken. We should try to accommodate feedback from our outreach team, and focus on documentation first. In my experience, users who need help find the "move" menu option might also need help was it renamed "rename".Selbstporträt (talk) 15:57, 21 June 2026 (UTC)[reply]

  Addendum. WP:RENAME refers to changing user names. Can't have good things. Selbstporträt (talk) 21:21, 21 June 2026 (UTC)[reply]

• Oppose. As a frequent commenter at the Teahouse, it is true that this can be confusing for newcomers but this isn't just a simple matter of renaming this process. Some things are actually page moves(from one namespace to another) and not a rename, and this would create confusion on the other side. 331dot (talk) 15:42, 21 June 2026 (UTC)[reply]
• Oppose Its not really a rename, although renaming the article that is part of the process. Per above, there is a movement process as its physical move within the db, so it wouldn't be accurate to rename it. A lot of these process name are well thought out back in the day and shouldn't be messed with. scope_creep^Talk 16:42, 21 June 2026 (UTC)[reply]
  • There's no physical move within the database; it's just a change of title. See mw:Manual:Page moving. But a redirect is generally left behind, which isn't the case in regular file renames on a computer. Graham87 (talk) 05:05, 22 June 2026 (UTC)[reply]

    Moving a page is not like renaming a file on a computer, primarily because it leaves a redirect behind, which is another reason to keep using the term "move". For example, when you physically move to a new home, you usually can get your mail forwarded to your new address, much like how the old title redirects to the new title. SuperPianoMan9167 (talk) 14:17, 22 June 2026 (UTC)[reply]

    Unless you as a renamer decide not to leave a redirect, or unless the content model disallows redirects (CSS, and sanitised CSS pages). This feels more like some pseudo-intellectualisation of what is actually happening. stjn 17:42, 22 June 2026 (UTC)[reply]

• Oppose, while I like the Idea and have to admit that the terminology confused me when I started as well - it would just plainly in my opinion be false. According to my understanding, what happens on a technical level is much closer to a move than a rename, even if the result is basically that. In agreement with WP:SPADE I think it makes more sense to call the feature what it actually is, if it were just a rename, e.g. logs would not be affected, therefore I think even for newbies it would be better to call it move than to explain why the "rename" is more than just that, as a matter of fact I think it would be harder to understand some things such as automatic redirect creation and round-robin moves. Best, Squawk7700 (talk) 20:43, 21 June 2026 (UTC)[reply]
• Oppose: Whilst I can sympathise that the term can be confusing for new editors, it is representative of the entire process, not just the aspect of renaming the article or page. The edit history is also moved in the case of drafts being moved into mainspace, with the same being true of the talk page and talk page history. It is a "move" in its entirety, not just a mechanism for renaming a page. 11WB (talk) 20:50, 21 June 2026 (UTC)[reply]
• Conditional support if this happens the word 'move' should still be applied somewhere for cross-namespace changes. For example, Where currently on the move page you have (namespace) (name), you could separate these into two lines where the namespace is branded as "move to other namespace". This would also be a convenient place to add a warning that cross-namespace moves are even more drastic. If this is not possible for technical reasons or not supported then I oppose. JacobTheRox^{(talk | contributions)} 21:43, 21 June 2026 (UTC)[reply]

  Since they're currently in the same mediawiki menu, if I understand it correctly would require a fundamental recode of the actual software + since this discussion can only create local consensus it would require the old menu to be preserved as well as an option for all the other wikis. In my opinion I would like to see that developer time rather spend on things that improve the editing experience in a more effective way. Best, Squawk7700 (talk) 21:54, 21 June 2026 (UTC)[reply]

• Oppose per several comments above; e.g. 331dot puts it well. Mike Christie (talk - contribs - library) 22:01, 21 June 2026 (UTC)[reply]
• Oppose per 331dot basically. It's interesting to note the choice made by other wikis: es.wiki and de.wiki basically use "Move/Transfer" but fr.wiki uses "Rename". Pichpich (talk) 23:36, 21 June 2026 (UTC)[reply]
• Oppose per 331dot. Would support conditional "move" and "rename", or "Move/rename" though. --ABx11 (she/they | formerly TheAuroraBorealis | In solidarity) 02:14, 22 June 2026 (UTC)[reply]
• Oppose Renaming is for users, and changes the username. Moving is for pages, and can change the namespace, the title, or both, in an effort to relocate the page to another location. I'm not really concerned by the amount of work here, so much as: what is the need here? The Phabricator discussion linked has some discussion about logos. Why do we need logos? Does Special:MovePage not sufficiently explain the action of moving a page? EggRoll97 ^(talk) 04:34, 22 June 2026 (UTC)[reply]

  Like 331, I'm not convinced that there's a need. There's a chance it might be changed if the string was truly better, but based on the high number of "oppose" !votes I don't think there's gonna be a change anytime soon. --ABx11 (she/they | formerly TheAuroraBorealis | In solidarity) 04:52, 22 June 2026 (UTC)[reply]

• Oppose – would cause too much upheaval for not enough benefit. Having said that, the original help page for page moving, Wikipedia:How to rename (move) a pageWikipedia:How to rename (move) a page, was originally at the title Wikipedia:How to rename a page. Graham87 (talk) 05:05, 22 June 2026 (UTC)[reply]
  • Also the access key, alt+M, wouldn't make as much sense ... but it'd probably be the best one we'd have. Graham87 (talk) 05:15, 22 June 2026 (UTC)[reply]
• Strong support for moves within a single namespace. These are obviously renames in practice, and inertia is not a good reason to keep a name that's plainly bad. Neutral for moves between namespaces, as those actually are "moving" from one namespace to another. Loki (talk) 05:06, 22 June 2026 (UTC)[reply]
• Comment: TIL! Is there scope for renaming it within the UI even if under-the-hood it's still a "move"? Todepond (talk) 10:44, 22 June 2026 (UTC)[reply]
• Support The UI should be clear for new users. In most other languages I'm aware of, this is already called rename ('hernoemen' in Dutch Wikipedia for instance). Changing the interface term is quite easy, and updating the help pages shouldn't be too much work. People working with new editors frequently have to explain how to rename articles and that's an unnecessary burden. Power users might disproportionaly have a bit of a tech background, but most new users do not and will be confused by this word. In solidarity, —Femke (talk) 🐦 10:58, 22 June 2026 (UTC)[reply]
• Oppose for a few reasons.
  • The current level of confusion is that new editors have to say "ah, renaming is done by moving a page". I'm a relatively new editor and this is one of the least confusing parts of wikijargon. If we make this change we cause confusion due to old edit summaries and discussions using the term "Move" and the fact some moves are more than just renames, and if you say we should separate "Rename" and "Move" I certainly don't see how that would make new editors less confused.
  • We are not considering the other side of the translation coin. I feel it's likely that doing this will cause new translation issues.
  • You can change the bad icon without changing this.
  • Workload. How much? Unclear. There is no plan available here. Part of the workload will figuring out what the rest of the workload is. It is not just changing labels. We have to update (including a lot of moving, or renaming I suppose) templates, other pages, bots, scripts and do it in a smooth way to not screw up the workflow of WP:RM. Template:Old moves is a fun one. It's used on 35,000+ talk pages to show what a closer put down as the outcome of an RM discussion. Change the template, then the outcome parameter of the template doesn't make sense anymore, and if you change that then the stated outcome in the template doesn't match the stated outcome in the close, and if you change that you'd be changing another editor's signed talk page post, and you wouldn't be able to say "it's okay we're only changing the bolded outcomes" as those are usually written alongside closing rationales that often mention moving in some way.
  • It sounds less cool to say I'm a page renamer than to say I'm a page mover. Unserious objection, obviously.
• ⹃Maltazarian ^{ᚾparley${\displaystyle \lor }$investigateᛅ} 11:25, 22 June 2026 (UTC)[reply]

  Something I forgot to mention: editors used to the idea of a page being "moved" and titles actually being "locations" (which is actually a really good way of thinking about it) have to do a bunch of relearning. As someone who does a lot of page moving it's not going to fun to deal with the muscle memory and how natural it has become for me to refer to it as moves.

  Also, it's perhaps worth considering that if an editor is so new that they don't know what moving a page means they likely should not be moving pages. Is it really a problem if a new editor with the idea to move a page has to ask how it works? Instead of potentially seeing "Rename", hitting it and boldly going forth without having read any guidance, they ask for help, get directed to read WP:MOVE, which has a part about whether or not it's okay to move a page placed before instructions on how to move a page. ⹃Maltazarian ^{ᚾparley${\displaystyle \lor }$investigateᛅ} 14:30, 22 June 2026 (UTC)[reply]

• RENAME within the same WP:namespace, and MOVE from one namespace to another. It is confusing. The shortcut WP:RENAME is a problem with this proposal. SmokeyJoe (talk) 13:21, 22 June 2026 (UTC)[reply]
• Oppose because it's less technically accurate ("moving" is a better abstraction because changing a page title moves the page contents to another URL, leaving behind a redirect at the old title by default), will require a lot of work for very little benefit (every instance of, e.g. requested moves must be changed to something like "requested renaming"), and it introduces new potential for confusion with username changes. SuperPianoMan9167 (talk) 14:11, 22 June 2026 (UTC)[reply]

  Also, things like Special:Log/move are apparently hardcoded into MediaWiki and cannot be changed without updating the codebase. SuperPianoMan9167 (talk) 14:13, 22 June 2026 (UTC)[reply]

  This is what I mean when I say that we would be creating a workload to figure out how much of a workload we are creating. It is very unclear just how much we need to do and I don't like blindly supporting an idea without knowing what it actually entails. ⹃Maltazarian ^{ᚾparley${\displaystyle \lor }$investigateᛅ} 14:32, 22 June 2026 (UTC)[reply]

  @Ladsgroup Is a mediawiki dev with a long history of contributing to the project, so I'm fairly sure he is aware of this and would be willing to help ease this through on the software side. Sohom (talk) 15:50, 22 June 2026 (UTC)[reply]

  Kind of missing the forest for the trees here. The point is that there are all kinds of things that can cause issues and we don't know about them, let alone have plans to deal with them, yet we are going headfirst into this. ⹃Maltazarian ^{ᚾparley${\displaystyle \lor }$investigateᛅ} 16:59, 22 June 2026 (UTC)[reply]

  To tell the truth, given his record lately with other changes and ignoring or disregarding feedback, that makes me more wary of this proposed change rather than less. Anomie⚔ 23:32, 22 June 2026 (UTC)[reply]

• oppose. I find the conceptual metaphor behind "moving" pages useful, even if technically under the hood "renaming" may be more precise. For example, the whole idea that when you "move" a page you then have a "redirect" from the old title to the new one – calling that a redirect (a thing that "directs" you to a different "place") is consistent with the metaphor that different titles are different "locations"; the old page still exists but it is no longer at the one "place" but at another – hence it has been "moved". That has always felt quite natural to me. (Of course I also agree with the argument of too much work for too little clearly defined gain). Fut.Perf. ☼ 14:49, 22 June 2026 (UTC)[reply]
• Oppose for two reasons. 1. Sometimes a "move" actually moves a page two a new part of Wikipedia, like moving something out of the draft space. 2. wkt:if it ain't broke, don't fix it Leaf.Sheap (talk) 15:24, 22 June 2026 (UTC)[reply]
• Oppose for two reasons. The first is a general "If it ain't broke, don't touch it." I have seen no indication that this is particularly confusing to people, at least not for long. However, the second reason is that touching it will break it, or at least make it less accurate. Renaming is one possible reason to use the move tool, but not the only one. If you move something from draft to mainspace (or vice versa), to userspace, etc., you are not just renaming it, you are moving it from one namespace to another, and that is a frequent use of the move tool as well. Calling it "rename" would obfuscate that use of it and not even accurately describe its function. Seraphimblade ^{Talk to me} 15:37, 22 June 2026 (UTC)[reply]
• Support: I don't get the software argument. In the software, page titles aren't just pregenerated locations you can just fill in either. That implies a degree of specific object-oriented stuff that is simply not there. The article is not a property of some title object, the title is a field property of the article. Simple as that.
  For "moving" out of namespaces, I don't see an issue with making it clear that the move is technically just a rename. Just like how we call administrators "sysops", we can still refer to renaming with the "moving" metaphor in discussions. In solidarity, Aaron Liu (talk) 15:52, 22 June 2026 (UTC)[reply]

  Just like how we call administrators "sysops", we can still refer to renaming with the "moving" metaphor in discussions. Then why not just refer to moving as renaming in discussions as is? SuperPianoMan9167 (talk) 15:56, 22 June 2026 (UTC)[reply]

• Oppose. The term "move" is more transparent about what's taking place at a software level. Concepts like WP:ROUNDROBIN moves, the persistence of redirects after (most) moves, etc., make intuitive sense in a framework where pages are moved from one location to another, and much less sense in a framework where static pages are simply renamed. "Renaming" can be a useful shorthand for introducing the concept to users who are unfamiliar with the RM space and are looking to have simple moves pushed through, but making it the primary title for the process loses clarity in a way that I think will hurt as much as it helps. ModernDayTrilobite (talk • contribs) 19:06, 22 June 2026 (UTC)[reply]
• Oppose. I see a lot of potential hassle for something of very dubious benefit. Could it have been named "rename" from the outset? Sure, and it would have been perfectly fine to do so, but it was named "move" instead, and I can't imagine anyone is really going to be that confused by it. –Deacon Vorbis (carbon • videos) 19:20, 22 June 2026 (UTC)[reply]
• Oppose lots of moving/adjusting for no concrete benefit. Yes, some things on Wikipedia are not named completely intuitively, or delineated completely appropriately, or whatever. But has any newcomer editor really thought "I can't stand that they call this function moving!" and left the project? ~~ AirshipJungleman29 (talk) 19:59, 22 June 2026 (UTC)[reply]

  Me, initially. The first time I wanted to edit Wikipedia I wanted to rename a page, spent an hour trying to figure out why I couldn’t edit the page title and “rename page on Wikipedia” wasn’t giving any hits, and eventually I got so fed up with the interface that I just gave up on editing for several years, since it seemed way too complicated. – Closed Limelike Curves (talk) 20:17, 22 June 2026 (UTC)[reply]

  I'm very surprised "rename page on Wikipedia" gave no results, Wikipedia:Renaming pages has existed since 2006, and Wikipedia:How to rename a page since 2002 (it was moved to Wikipedia:How to rename (move) a page in 2003). Help:Renaming a page was created in 2021 and Help:Rename has had a prominent link to moving since creation in 2011. Thryduulf (talk) 22:15, 22 June 2026 (UTC)[reply]

  Just checked and WP:Moving a page shows up today, but under that name (with no mention of "renaming" whatsoever). I'm not sure if this is a change in Google's search algorithm or (more likely) some variant of confirmation bias/functional fixedness on my part. If you're used to a functionality being called "rename" everywhere else, it's very easy to skip right past the link labeled "moving a page" without stopping to realize "wait, that's logically equivalent to what I want to do".

  I'm guessing this problem also leads to a lot of cut-and-paste moves from people who don't realize you can move a page. – Closed Limelike Curves (talk) 23:20, 22 June 2026 (UTC)[reply]

• Let's compromise. Instead of renaming "move" to "rename" we could move "move" to "rename". Phil Bridger (talk) 21:59, 22 June 2026 (UTC)[reply]
• Oppose: per 331dot and others – PharyngealImplosive7 (talk) 22:19, 22 June 2026 (UTC)[reply]
• Oppose per 331dot. I understand nom's argument, and while I agree with it, simply renaming the tool to rename doesn't make sense in the case of, say, draftification. You move a page throughout namespaces, not rename it.
  The confusion problem does exist though. Perhaps there could be a more simple tool for beginners? Some kind of wrapper of Special:Move. EatingCarBatteries _{(contribs | talk)} 22:43, 22 June 2026 (UTC)[reply]

  I question how wise it is to strive towards making it easier for new editors to move pages without having to first consult other editors. ⹃Maltazarian ^{ᚾparley${\displaystyle \lor }$investigateᛅ} 15:13, 23 June 2026 (UTC)[reply]

  Indeed, there should be barriers to actually carrying out a move. Making the policies and procedures easier to understand is another matter. —Myceteae‍🌈 (talk) 15:36, 23 June 2026 (UTC)[reply]

  I don't think it's that hard to understand that moving a page means renaming it, once you're actually learning about it. ⹃Maltazarian ^{ᚾparley${\displaystyle \lor }$investigateᛅ} 16:43, 23 June 2026 (UTC)[reply]

  That's more or less my view but I am giving some weight to editors here who say they spend a lot of time at Teahouse or mentoring newbies, and that the terminology is a frequent source of confusion. It is surely true, in isolation, that learning what move means is not difficult, though this does not mean there is no benefit to simplifying our terminology. Taking a broader view, the totality of jargon and wiki-speak is a barrier even to editors with some experience under their belts, and any simplification may be beneficial. All that said, I'm not at full support, but I'm not sure I have a good reason for it. —Myceteae‍🌈 (talk) 17:07, 23 June 2026 (UTC)[reply]

  I agree that the totality of wikijargon is a barrier, but, as I said in my main reply, as someone who has relatively recently had to learn wikijargon I feel this was one of the least confusing parts, and one that arguably makes a lot of sense being called what it is. I think focus should instead be directed at cutting down on the wikijargon that that can't be said for, and primarily on aspects of it that act as barriers to activities that we would like new editors to easily and intuitively jump into without having to consult more experienced editors. ⹃Maltazarian ^{ᚾparley${\displaystyle \lor }$investigateᛅ} 17:33, 23 June 2026 (UTC)[reply]

• Oppose (conditional): Within same namespace, changing to "Rename" is OK. But don't change it if it can't be done while keeping "Move" for across namespaces (which I guess is mostly just for drafts -> main; P.S. - I'm interested if anyone knows other use cases for cross namespace moves). This must be how Ken Thompson and Dennis Ritchie felt about introducing mv to Unix. cases. Good points made by I agree with JacobTheRox^{(talk | contributions)}, Loki (talk), & Maltazarian ^{ᚾparley\/investigateᛅ}.
  Theo wiki user (talk) 01:00, 23 June 2026 (UTC)[reply]

  Common cross-namsepace moves include: User → most others (userspace drafts of article content, templates, project pages, etc), Main → user/draft (draftification) and Wikipedia → Main (fixing a common mistake when attempting to publish a draft is to move it to the Wikipedia namespace instead, although this is less common now than it used to be). Wikipedia ↔ Help (reorganisation, etc) is less common but isn't too infrequent, obviously mistaken moves to and creations in can apply to almost any pair of namespaces; before draftspace existed drafts were written in the Wikipedia talk: namespace and then moved to main when expected. Obviously in all cases talk pages get moved to the corresponding talk namespace alongside the content pages. Thryduulf (talk) 01:19, 23 June 2026 (UTC)[reply]

• Strongly support renaming intra-namespace moves to renames since it is the more appropriate term. weakly support namespace to namespace moves, if it is not technically possible to distinguish these moves to intra-namespace renames.FoxOutOfRange 07:15, 23 June 2026 (UTC)[reply]

  Also, I do not think the fact that it isn't broken does not mean that we shouldn't improve on things. If that was the argument for all possible improvements to the wiki then we would not get anything done except reacting to issues, and being reactive rather than proactive is a bad thing... FoxOutOfRange 07:20, 23 June 2026 (UTC)[reply]

• Support, changing it would make it more intuitive and demystify the editor experience for new editors. Overall it would streamline things and help reduce the pressure that too much jargon could create. Atakes Ris (talk) 10:01, 23 June 2026 (UTC)[reply]
• Comment. The current name is technically more correct but it is true that it confuses some people. I see that we have tried to ensure that people mistakenly looking at the wrong guides (e.g. WP:RENAME) are pointed towards the correct ones (e.g. WP:MOVE) but I wonder if there is more we can do to avoid confusion e.g. having a template for a little banner that explains the terminology in one or two simple sentences and links to the correct guide. That said, I also wonder whether inexperienced editors should be encouraged to do their own moves anyway. It's quite easy to do it wrong and make a mess. It is something I occaisionally see people asking for help with because they either did it wrong, and aren't sure how to fix it without making it worse, or they are just not sure whether they did it right. --DanielRigal (talk) 10:39, 23 June 2026 (UTC)[reply]
• (edit conflict) Oppose. Having read all of the above, I'm convinced that this will cause a very significant amount of disruption for only a very small benefit at most (and is actually more likely to be overall neutral). Insead, improving the documentation, inclduing making it clear that renaming is carried out by moving, will unquestionably achieve the desired goals without causing any disruption and will almost certainly bring additional benefits too. Changes to documentation (in some cases greater changes) would be needed if we carried out this proposal anyway, so the effort to do this is required either way. Finally, moving or renaming pages is inherently disruptive in almost all cases, when done properly this disruption is vastly outweighed by the benefits of the move but when done incorrectly it's a net negative. For this reason we want there to be a small barrier to moving/renaming so that new editors acting in good faith but unaware of policies, guidlines and conventions don't unintentionally cause disruption by unnecessarily and/or incorrectly renaming a page. There being no prominent "rename" button but requiring people to search for how to achieve it provides this small barrier and gives us a chance to educate them before they accidentally cause disruption - assuming they can find the documentation, which will be an issue whatever it's called (and where improving it comes in). An editor causing disruption, regardless of their intent, is far more likely to be driven away from the project as a consequence than editors who can't figure out how to rename a page, can't find our documentation and choose not to ask. Thryduulf (talk) 10:48, 23 June 2026 (UTC)[reply]
• Support. There is, as far as I can think of, any reason to not use self-explanatory terminology where possibe. Article moving is often, but not always, renaming. I believe the actions other than renaming should continue under "move", but the tools use for renaming and the associated rules for such use should be called "renaming". Finfixer (talk) 14:49, 23 June 2026 (UTC)[reply]
• Comment: I've added a notice about this discussion to Wikipedia talk:Moving a page and Wikipedia talk:Requested moves. Graham87 (talk) 15:03, 23 June 2026 (UTC)[reply]
• neutral To me the two terms are synonyms, i don't think it really matters. I find all but the first bullet point of the why section uncompelling. Move is common computer terminology for this operation (e.g. Unix mv command). Arguably move does have connotations of a file system metaphor, which isn't really the metaphor we use on wiki. I don't think how other languages translate the term should have any bearing on what the english translation is. Translation is never a 1:1 mapping. And last of all, people choosing a bad icon has nothing to do with what the action is literally called. Icon choice should follow semantic meaning. If someone choses an icon based on looking up the word in the dictionary and then choosing the wrong sense of the word, that is on them. Bawolff (talk) 15:09, 23 June 2026 (UTC)[reply]
• Oppose While there's nothing wrong with the idea of using "rename" to refer to this process, I don't see "move" as wrong either. It's likely that making this change would create more confusion, not less. 162 etc. (talk) 15:17, 23 June 2026 (UTC)[reply]
• Oppose. "Rename" is, in my estimation, inaccurate; even within a namespace, we really are moving the pages to a new location, not simply renaming them. This is illustrated in the manual histmerge process; if we delete a page at one title and then move/rename another title on top of it, the previous page's edit history is still there, and if that's all undeleted, then the edit history of the previous page will be mixed into the edit history of the new page. To me, the analogy of the new title being a "place" where we are moving an edit history is much clearer; if it were "renaming", my intuition would be that the edit histories would stay separate, that the pages are still separate, and simply now have the same name. Writ Keeper ⚇♔ 15:14, 23 June 2026 (UTC)[reply]
• Strong support – As an ex-newbie myself, calling what we do "moving" a page is ridiculous. We literally just rename it. It is so simple and not even that inaccurate. You can say a page was renamed to a new title, and the page history of the old title is now the history of the new title. Ridiculous. FaviFake (talk) 19:44, 23 June 2026 (UTC)[reply]
• We should paint the bike shed green. Phil Bridger (talk) 20:06, 23 June 2026 (UTC)[reply]

  😭 —Myceteae‍🌈 (talk) 20:13, 23 June 2026 (UTC)[reply]

  I see no bike sheds here. FaviFake (talk) 20:14, 23 June 2026 (UTC)[reply]

  Maybe. More importantly, though, what kind of coffee should we provide for the person painting the shed? — Godsy ^(TALK_CONT) 20:58, 23 June 2026 (UTC)[reply]

  Cappuccino pls! FaviFake (talk) 21:35, 23 June 2026 (UTC)[reply]

• Support and a cold, wet {{minnow}} to all the people who are wringing their hands over the technical aspect. Changing the contents of MediaWiki:Skin-action-move from 'Move' to 'Rename' would take about 15 seconds. It also doesn't require any dev time, and the reason that the devs created pages like MediaWiki:Skin-action-move is precisely so that we-the-community can change them whenever we want to. I bet that we could change the title of WP:MOVE in significantly less than a minute, too. (This reminds me of when we renamed the Wikipedia:Naming conventions policy years ago – so much fearfulness about how much work it would be to change the name of the page and how terribly confusing it would be. Reality proved otherwise, and I think that will be the case here, too.) WhatamIdoing (talk) 01:38, 24 June 2026 (UTC)[reply]

  The problem is that a lot more things beside MediaWiki:Skin-action-move (like Wikipedia:Requested moves) need to be changed to accommodate the renaming. SuperPianoMan9167 (talk) 01:44, 24 June 2026 (UTC)[reply]

  Plus it's not clear just how far people might decide to take this. I see suggestions about renaming classes in the code too, for example. Anomie⚔ 13:07, 24 June 2026 (UTC)[reply]

  The decision to make changes on the code doesn't belong here. It's internals of mw so it should be decided on phabricator. Not here. Ladsgroup^overleg 14:14, 24 June 2026 (UTC)[reply]

  I don't think we have to make all possible changes at the same time. It's enough to change the main newbie-facing label, or perhaps a couple of them. WhatamIdoing (talk) 19:42, 27 June 2026 (UTC)[reply]

  I strongly disagree with that. Making the terminology inconsistent would be the worst option for both new and experienced editors. Thryduulf (talk) 09:49, 28 June 2026 (UTC)[reply]

  Really? People seem to manage just fine with "A truck (North American and Australian English) or lorry (British English) is a motor vehicle designed to transport freight, carry specialized payloads, or perform other utilitarian work", but you think they'd be seriously confused by "A page can usually be renamed if the existing title is incorrect or needs to be changed; this is done by moving a page" – which, by the way, is already the first sentence at WP:MOVE? WhatamIdoing (talk) 03:20, 1 July 2026 (UTC)[reply]

• Oppose, oversimplification of what is actually being done is a net negative. If it's not immediately obvious what "move" means I'm not sure what to tell you. PARAKANYAA (talk) 04:03, 24 June 2026 (UTC)[reply]

  The point that newcomers who don't understand "move" don't belong here misses the point. The point is to reduce how overwhelming being a new editor can be. I don't know if you had the experience of jumping to a new job and everything being different. Being a new editor is like that. We take a lot for granted and many are simple but they add up. The cognitive load of "move" referring to a rename is not much but it contributes to whole experience of editing being intimidating and the more we can reduce the cognitive burden, the more welcoming and faster for people to pick up our policies and guidelines (and less people giving up) Ladsgroup^overleg 14:22, 24 June 2026 (UTC)[reply]

  Us making the name of a basic function incorrect will not change that at all. PARAKANYAA (talk) 15:13, 24 June 2026 (UTC)[reply]

• Oppose. The confusion to new users should be minimal, as 95% of registered editors have made fewer than 10 edits and thus have not reached autoconfirmed status where they would even have the right to move pages, so they never see the "move" tab. --Metropolitan90 (talk) 06:35, 24 June 2026 (UTC)[reply]
• Strong support, per Ladsgroup and Closed Limelike Curves. I think much of the "if it ain't broke, don't fix it" arguments are... silly, at best. It clearly is broken; people are confused by it. Even if the process is ""technically"" a move rather than a rename (which, per Ladsgroup, I think is dubious) I don't see how that's a strong enough motivator to retain such an unintuitive label for something so simple. Maybe we should replace the 'edit' button with a 'wiki markup' one, or rename talk pages to 'intra-project discussion namespace' articles. The cross-namespace argument doesn't convince me either; why is it less confusing to explain that "'renaming' a page can also move it across namespaces" over "'moving' a page just means renaming it"? Ultimately, 'rename' is simply a much more intuitive label. Loytra^✨ 08:43, 24 June 2026 (UTC)[reply]

  I think much of the "if it ain't broke, don't fix it" arguments are... silly, at best.
  Absolutely. You can't possibly argue a newbie will understand how to rename a page better if we give the process a technical name. One way we avoid WP:BITING the newcomers is by not using jargon when possible. FaviFake (talk) 09:59, 24 June 2026 (UTC)[reply]

  Except moving a page isn't unnecessary jargon, it's the literal description of what we do to rename a page. The best way to avoid BITING newcomers in this instance is to improve the documentation so that they learn what the necessary jargon means. Thryduulf (talk) 10:32, 24 June 2026 (UTC)[reply]

  Not really. Very strictly speaking. On page table, the canonical row describing a page has primary key of page ID which is a number and doesn't change with rename and as such it doesn't move on the binary tree holding the data. But if we are speaking, conceptually you can argue either way IMHO Ladsgroup^overleg 14:12, 24 June 2026 (UTC)[reply]

  And even if we accept it strictly a "move" not rename, that is not the reason to pick a more intuitive but less accurate name. Deletion (specially revision deletion) is not a deletion at all. It's "hiding" or "archiving" Ladsgroup^overleg 14:32, 24 June 2026 (UTC)[reply]

• Oppose, the long history of 'Requested moves' exists and nobody has claimed it is really broken. To change it to an unfamiliar term at this point just for the sake of, well, I don't know, seems like a make-work project rather than a useful idea. Randy Kryn (talk) 14:23, 24 June 2026 (UTC)[reply]
• Strong support and it's so sad to see so many editors opposed to this, especially on obviously-incorrect grounds such as that it's "literally" or "physically" a "move." It's obviously not! Changing the title of something does not move that thing. When you change a page's title, it doesn't move the page from one place to another. It's not like the bytes are moving to a different hard drive! (Did you know that files aren't even stored in one location on a hard drive? If you didn't, it's called file fragmentation.) So calling it a "move" is not accurate. When we change the title of an article, we're changing a parameter (the "title" or "name" parameter) in a database. Nothing is moved, certainly not physically, but not electronically, either.
  Because it's inaccurate, it's also confusing. Wikipedia has this lifelong problem of reinventing the wheel, of naming things using different names for those things than everyone else uses, and I think it's inherent in being built by amateurs who just don't know (or haven't thought about) what everyone else calls it. Thats why we call them "namespaces" instead of "categories" or "folders" or "types." That's why we call them "categories" instead of "labels" or "tags." That's why it's "neutrality" instead of "following the mainstream view" or "accuracy." That's why it's "notability" instead of "inclusion criteria," and we call "copyright" what everyone else calls "plagiarism".
  We say we want more editors but we make it extremely complicated and confusing to become an editor, and even when this is pointed out to us and clearly demonstrated by years of new editors' complaints, we're still loathe to change, even on a website that changes 3 times every second. If we want more editors, we need to stop asking new editors to learn new inventive names for everything.
  I yearn for Wikipedia to fix these original sins and start calling things by the names everyone else calls them. Changing a title? That's a "rename" not a "move." (And I totally don't agree that making this change would be some massive undertaking. It's a find-and-replace job to change a text string, or rename -- ha! -- from "move" to "rename.") Levivich (talk) 14:36, 24 June 2026 (UTC)[reply]

  Obviously 'move' doesn't mean a physical move, I think internet users are aware that moving a page doesn't mean we pick it up with a forklift and move it to a new location. 'Move' has an obvious meaning, a word that shouldn't confuse new editors and, if it does, they will quickly realize what it means (to move a page). Randy Kryn (talk) 14:57, 24 June 2026 (UTC)[reply]

  Move does not have to mean physical location? You are literally moving the page from one place to another.

  And copyright is not the same thing as plagiarism! At all! Not all plagiarism is a copyright violation. Plenty of non-plagiarism copyright issues exist. PARAKANYAA (talk) 15:15, 24 June 2026 (UTC)[reply]

  I don't understand how anyone can say "you are literally moving the page from one place to another," when we are very much not literally moving anything anywhere. The word "move" means "change location" and when we change page titles, we do not change their location (they remain in the hard drive, even at the same file table address). Pages don't even have a "location" to begin with: they're spread out at multiple places in a hard drive (they're "fragmented"). It's almost like we're speaking a different language. Because we are ... because wikispeak is not English, because Wikipedia redefines words, eg calling a rename a "move." (Btw I didn't say copyright was the same thing as plagiarism.) Levivich (talk) 15:35, 24 June 2026 (UTC)[reply]

  I think its silly to take it this literally, but if you do, a move operation is indeed moving nodes around in the b-tree index. However we shouldn't care what happens behind the scenes, what matters is what sort of UI metaphor we want to present to users. Bawolff (talk) 17:14, 24 June 2026 (UTC)[reply]

  You're still speaking in metaphors. When we rewrite the b-tree index, we're not actually moving a node from one location to another location--that's just a metaphorical construct-- what we're actually doing is changing a sequence of 1's and 0's to a different sequence of 1's and 0's in order to document a different relationship between various strings of 1's and 0's (nodes in the b-tree index). Nothing is moved. Nothing changes its physical location in the world, nor are we changing the location of bits on a hard drive.

  what matters is what sort of UI metaphor we want to present to users or whether we want to use a metaphor at all! "Rename" is not a metaphor, because it is, literally, what is happening. We are changing text (or, technically, binary sequences representing text) from one string to another. That is what "rename" means. That is not what "move" means. My whole point is that Wikipedia should not invent metaphors like "move" when we can just use regular plain old literal meaning, like "rename." It's simpler to not ask users to have to learn metaphors for common ideas. Levivich (talk) 17:45, 24 June 2026 (UTC)[reply]

  Why not just change MediaWiki:Skin-action-move to something like "Move (Rename)"? That way it introduces both terminologies at once. SuperPianoMan9167 (talk) 19:32, 24 June 2026 (UTC)[reply]

  I'd support that as an interim measure, but one reason why not to do it is because "move (rename)" is just a longer way of saying "rename." One reason to do it is that "move" confuses at least some people (new editors), while "rename" will confuse no one. Levivich (talk) 20:07, 24 June 2026 (UTC)[reply]

  Except that "rename" will confuse a bunch of editors who type in WP:RENAME and end up on a page talking about username changes instead of title changes. SuperPianoMan9167 (talk) 20:10, 24 June 2026 (UTC)[reply]

  That can be fixed with a disambiguation page. Levivich (talk) 20:31, 24 June 2026 (UTC)[reply]

• Oppose - on top of the other arguments, I think it's actually a useful shibboleth that can indicate someone's familiarity with the page move process and relevant guidelines. Of all the complicated parts of the page move process, its name is the least significant obstacle. _signed, Rosguill ^talk 15:10, 24 June 2026 (UTC)[reply]
• Comment. I feel like "move" is a standard idiom for people used to dealing with computer files. In Unix it's called mv even though all it actually does is give you a different key to look up the first inode. For Windows and Mac folks, they're used to dragging and dropping icons to different folders (though it's true they might use "rename" when it's in the same folder). So while it's true that you're not really "moving" anything, it's a tried-and-true metaphor that's been vetted for decades.
  That said, I can imagine a world where we use "rename" inside a namespace but "move" to go to a different one. That seems to make things more complicated rather than simpler. Is there a genuine problem that justifies the complexity? --Trovatore (talk) 19:54, 24 June 2026 (UTC)[reply]

  The confusion lies in that moving a file (from one folder to another) is not the same thing as renaming the file, on Windows or Mac, which is what 95% of people use.

  If "Kiev" becomes "Kyiv," we call that a "move." If "Draft:Kiev" becomes "Kiev," we also call that a "move." That's confusing.

  Technically, the same thing is happening: the "name" field is being changed. Conceptually, two very different things are happening: in one, we're changing the title, in the other, we're changing what we call the "namespace" (a virtual location), which is basically changing the type of page.

  When you change the title of an article from "Kiev" to "Kyiv," calling that a "move" makes no sense. Calling a discussion about what an article title should be a "requested move" also makes no sense. So I think it would reduce confusion if we called that a "rename," a "proposed rename," etc. Levivich (talk) 20:05, 24 June 2026 (UTC)[reply]

  Levivich I think at the very least you can see that this is not a Wikipedia innovation, as your "reinventing the wheel" comment might have been understood, but a longstanding idiom used in the wild.
  In any case I have not yet taken a position on the proposal as such; I'm just suggesting a point that people may find relevant. --Trovatore (talk) 03:03, 25 June 2026 (UTC)[reply]

  Granted, in this case it's not reinventing the wheel, it's using obscure tech jargon. Longstanding, yes, but not widespread. It's not "a standard idiom for people used to dealing with computer files". It's a unix command, not a windows/mac command, and so (based on market share) 95% of "people used to dealing with computer files" (windows/mac users) do not call a renaming a file a "move." Levivich (talk) 03:10, 25 June 2026 (UTC)[reply]

  I suspect that, while people might fill the blank in "Alice ____ the file from 'Untitled.jpg' to 'Christmas tree.jpg'" with "renamed" (although "moved" wouldn't be surprising either, IMO), most native speakers would not choose "renamed" for "Bob ____ the files from the 'Unsorted photos' folder to 'Christmas 2025'". This seems similar to the difference several others have raised above about within-namespace versus cross-namespace page moves.

  A difference to keep in mind is that graphical file managers generally have different ways to accomplish these two operations (editing the filename (not path) versus drag-and-drop between folders), while command lines have a single tool (e.g. mv or move). MediaWiki too has a single tool. Anomie⚔ 11:32, 25 June 2026 (UTC)[reply]

  I think whether or not command shells have one or two tools is a side note. To be accurate, though, in DOS the ren / rename command pre-dates move, and they both co-exist in DOS/the Windows command prompt. isaacl (talk) 17:13, 25 June 2026 (UTC)[reply]

  Yes, but I can also "rename" a file on my Mac without dragging and dropping or otherwise "moving" it to a different folder. And when most people move Final paper.pdf from their "Documents" folder to their "School" folder (or whatever) I don't think they conceptualize this as renaming. —Myceteae‍🌈 (talk) 21:47, 24 June 2026 (UTC)[reply]

  But when most people change Final paper.pdf to Final paper v2.pdf, they don't conceptualize that as moving. And I think most editors' mental model of a pagemove is closer to that. Their motivation is that they want the page to be called X rather than Y. Gnomingstuff (talk) 18:57, 25 June 2026 (UTC)[reply]

  I completely agree that most people conceptualize that as renaming and not moving. Even people who have some understanding that the file path location is changed by dint of the name change do not see it as having moved. And I agree that is most editors likely view most page moves that way, too. Speaking for myself, though I suspect I am not alone, I tend to think of page moves within the same namespace as name/title changes first and foremost, even though (I think) I have a fair grasp of the underlying process and can rationalize why we call it a move. —Myceteae‍🌈 (talk) 21:54, 25 June 2026 (UTC)[reply]

• Oppose As 331dot said, not all moves are simply renaming pages. Moving articles in/out of draftspace or userpages are also covered as well. EaglesFan37 (talk) 20:54, 24 June 2026 (UTC)[reply]
• Support I don't understand the software argument here. Editors are thinking of articles as articles, not as files or filepaths or anything like that, so "rename" is a useful abstraction for what they are doing. The implementation doesn't matter to them -- or even need to be changed at all! This is basic programming design. Gnomingstuff (talk) 18:47, 25 June 2026 (UTC)[reply]

  (I apologize for the length of this comment) There are situations where it is useful to think of a title as a location; for example, trying to move a page to a title with significant page history. On most filesystems, if you create or obtain two files with the exact same name, the software will prompt you to either overwrite the pre-existing file or keep it intact, in which case one of the files is forced to have a different name (usually by adding (1) or something similar). On Wikipedia, you can overwrite a redirect to move a page to a new title if and only if the redirect's history contains exactly one edit. Otherwise, the other page blocks the move and you have to get it deleted via G6. If moving were called renaming, editors might try to move a page to a title with significant history and expect the other page to be overwritten or forced out of the way, like on most filesystems, but that's not what actually happens.

  TL;DR "moving" makes more sense when trying to change to a title with nontrivial page history because the other page and its history has to be "moved out of the way". SuperPianoMan9167 (talk) 19:26, 25 June 2026 (UTC)[reply]

  I basically agree with your conclusion but not in detail with your reasoning. In Unix, when you move a file on top of another file, the other file is in fact deleted by default (not "overwritten", just unlinked — the content may be recoverable for a while but you can't count on it).
  I think the real issue with "rename" is that, if you just rename an article to a name already in use, you might expect there to be two articles with the same name. --Trovatore (talk) 22:41, 25 June 2026 (UTC)[reply]

  Gnomingstuff, I think the issue is that, in important ways, our articles are more like computer files than they are like articles in a magazine. In particular the name of an article isn't just something the user sees at that one article; it's an index to the article throughout the whole 'pedia. Users who don't understand that probably shouldn't be performing this operation anyway. --Trovatore (talk) 22:58, 25 June 2026 (UTC)[reply]

  I don't think most editors doing their day-to-day editing, especially on the writing/copyediting side, are thinking of the articles as files. I certainly don't. Gnomingstuff (talk) 13:32, 26 June 2026 (UTC)[reply]

  Speak for yourself. I've always thought of them that way, because, well, of course they are. (Well, they're actually text fields in a database at the end of the day, but those text fields are then used to generate an HTML file for display in a browser.) But...of course they're files, what else would they be? Seraphimblade ^{Talk to me} 13:38, 26 June 2026 (UTC)[reply]

  ...of course they're files, what else would they be? These days, the concept of documents being files in a filesystem is less universal than it used to be. Today's web users are very familiar with posting content to a site, which then wraps it with surrounding layout, builds indexes, provides history information, and so forth. They may be well likely to think of a Wikipedia article as a blob of content stored in a database. isaacl (talk) 17:28, 26 June 2026 (UTC)[reply]

  That is, if anything, a reason to use language that emphasizes the file-like nature. For better or for worse, I can (and probably do) have multiple documents called "Untitled Document" in my Google Drive, which despite the name acts in some ways more like a database than like a filesystem. If we call it "rename", users might be led to think that the same is possible with Wikipedia articles, but of course it isn't. --Trovatore (talk) 19:01, 26 June 2026 (UTC)[reply]

  I disagree that it's necessary for Wikipedia procedures to emphasize that Wikipedia pages are like files. We could choose to do so, but we could also choose to treat them as objects unto themselves, which are packaged by clients to display them in different ways, automatically sorted into category pages, indexed for searching, and generally incorporated into an ecosystem of information presentation provided by the MediaWiki software. Their titles can be changed (just as titles to posts and to "Untitled Document" documents can be changed), thus preserving all other properties and history for that object (it's the same object after all), and new objects can be created that point from the old title to the new title. isaacl (talk) 21:55, 26 June 2026 (UTC)[reply]

  The point is that an article title is not just a way for the user to know what the article is about. Just as importantly, it's a global index to the resource (metaphorically, a "location"). Ordinary users don't necessarily have to have internalized that, but anyone who is considering moving articles really should. The "move" terminology doesn't by itself guarantee that people will understand that but it's a step in the right direction, because it invites the question, what if I move something but there's something already there? --Trovatore (talk) 22:01, 26 June 2026 (UTC)[reply]

  Sure. Personally I don't view this aspect as being specific to files. I think giving unique labels to pieces of content has become pretty widespread across many conceptual models, in no small part thanks to the web. isaacl (talk) 22:14, 26 June 2026 (UTC)[reply]

  It may not be unique to files; that isn't really the point. The issue here is that if you "rename" a resource to a name that's already used, it's not obvious that anything special has to happen. Maybe you just have two resources with the same name. You might think it's not a good idea, but there's no clear reason to expect that the system is going to prevent it. On the other hand if we use language that suggests that names are locations, then you can leverage the user's intuition that you don't have two different things in the same "place". --Trovatore (talk) 22:29, 26 June 2026 (UTC)[reply]

  My initial response to you was specifically regarding the suggestion that my first comment was a reason to use language that emphasizes the file-like nature. Regarding the uniqueness of resource labels, personally I think that many people have become accustomed to the concept of unique resource labels, so that the inability to rename a resource to a label already in use is not surprising. In the context of Wikipedia, I don't think many people are surprised that a given page title reliably returns the same content. isaacl (talk) 23:47, 26 June 2026 (UTC)[reply]

  I conceded that this aspect may not be unique to "files" per se. Everything else I said is completely solid and I stand by it. The behavior is still file-like as opposed to database like so really there's not anything I want to retract. "Move" is better than "rename" because it makes it clear that there's an issue if you duplicate a name, even if it doesn't tell you how the issue would be resolved, and even if you might realize there's an issue using "rename", it's still the case that "move" makes the point more clearly and is therefore the better choice. --Trovatore (talk) 00:15, 27 June 2026 (UTC)[reply]

  This whole argument is missing my point. When the average person is writing or editing an article, they are thinking of it as an article. Their brain is in content mode, not in file-system mode. Gnomingstuff (talk) 03:44, 27 June 2026 (UTC)[reply]

  I'm not sure how they're mutually exclusive. If I'm writing code, I might be in C++ or Java or Python "mode", but I still know I'm writing a file. If I'm writing a document in Office or LaTeX, I'm in the "mode" to write that, but I'm still writing a file. If I save my game, I'm in "playing the game" mode, but I still know I'm writing the save to a file. Right now, I'm in "how do I get the outdent format to work properly and write a response once I figure that out" mode—but I'm still writing a change to a file. The fact that one is utilizing a file shouldn't generally be the primary thing one is focusing on, but the awareness of it is still there. Seraphimblade ^{Talk to me} 05:21, 27 June 2026 (UTC)[reply]

  
  Gnomingstuff, actually that kind of is my point. Thinking in "content mode" may be sufficient when you're changing content, but it is not sufficient when you're moving articles, because that is not simply a content change. So if you're only thinking in content mode, please don't move articles. --Trovatore (talk) 06:15, 27 June 2026 (UTC)[reply]

  Why not? Wikipedia:Article titles is a content policy. Editors should be thinking "in content mode" when they're changing an article title. WhatamIdoing (talk) 03:23, 1 July 2026 (UTC)[reply]

• Oppose I don't really see that, "rename" might sound a bit more obvious to a newcomer but we are talking about a term that's been around here forever, wikipedia has way bigger things that confuse new editors than the word "move" even if even if, still new editors are gonna have questions no matter what we call it, I don't think changing it to rename is some magic fix. just like your first day at a job and you want to do work for principal; there are levels and instructions. CONFUSED SPIRIT(Thilio).Talk 19:12, 25 June 2026 (UTC)[reply]
• Support (Conditionally), especially if changed to Retitle / Re-Title, which avoids confusion with renaming a username.

  The longstanding practice of calling retitles a Move is indeed ambiguous and confusing. Dance21c (talk) 19:20, 25 June 2026 (UTC)[reply]

• Oppose pages are moved, users are renamed. (And don't get me started on McDonald's calling out guest numbers instead of order numbers....) SarekOfVulcan (talk) 19:35, 25 June 2026 (UTC)[reply]
• Oppose. Took me a while to figure out how I really felt about this, but after reviewing (many of) the above comments, I think "move" enables better intuitions about what happens when the desired new title already exists. --Trovatore (talk) 21:05, 25 June 2026 (UTC)[reply]
• Oppose per 331dot and Thryduulf; this causes more trouble than it's worth, and "rename" technically doesn't apply when talking about cross-namespace moves. Electricmemory (talk) In solidarity 07:45, 26 June 2026 (UTC)[reply]
• Oppose as it is just not accurate. Renaming is one function of the move button, likely the most common, and this should be explained clearly in as many places as possible. Other functions include moving a page to a different namespace, history merging, and (though I would never do it this way) archiving a talk page. – filelakeshoe (t / c) 🐱 12:19, 26 June 2026 (UTC)[reply]

Comment I'd like to understand one aspect of the argument on some in support of the proposal rather than insist on my opinion: beyond the technical level on which one can discuss the accurateness of either term, move serves as an analogy for all the consequences of a rename/move, such as the creation of a redirect or the discoverability or not discoverability of some logs. This idea of files being in a location and moving from there to somewhere else is what actually allowed me to even understand the rather complex process when starting out. I too was first confused at least a bit when trying to "rename" an article, however once I've overcome that initial confusion it was much simpler to understand the rest of the process. In my mind it would be much more confusing to explain to a user: "you can rename the file here, but that will automatically create a redirect at the old title which you cannot prevent, but some users can, and sometimes you will not be able to find log entries for the page at the renamed title but the "new" redirect we created that previously did not exist at all. In contrast to the comparisons to user interfaces such as Windows/ macOS this is unique to our process, would the windows button really also be called rename if it would create a symlink you cannot remove at the old name? Wouldn't it be desirable to make the entire process as understandable as possible, even if that means to compromise on initial understanding?

My comment here is only intended for me to understand other arguments/ opinions better, I don't want to needlessly double down just for the sake of it.

Best, Squawk7700 (talk) 22:10, 26 June 2026 (UTC)[reply]

Oh and please ping on reply - I don't look through all the notifications of the tread - thanks! Squawk7700 (talk) 22:32, 26 June 2026 (UTC)[reply]

@Squawk7700: Here's how I would explain it, using the terms used by Windows and Mac: When you rename an article, a shortcut/alias (called a "redirect" on Wikipedia) from the old name to the new name is automatically created. Users with the suppressredirect user right are able to stop this from happening when they rename pages. As for the history and logs, I'd say When renaming a page, the page's history will continue to be available under the page's new name. The page's logs, however, will remain at the page's old name because MediaWiki developers hate us. I think that's clearer than a "move" metaphor. I think "move" makes sense when you talk about namespaces, e.g.: If you change the namespace prefix in a page name, it has the effect of 'moving' the page to the new namespace. For example, renaming a page from "User:Foo" to "Draft:Foo" 'moves' the page from the User namespace to the Draft namespace. This is the approach I think is best/easiest for new editors, because while you and I were confused at first and later caught on, others, I fear, are confused at first and then leave. Levivich (talk) 23:45, 26 June 2026 (UTC)[reply]

I would counter that people who are confused by this probably shouldn't be doing it. The operation has more serious consequences than you might expect from "rename". They can get unconfused later and then they can do it, but by then they'll probably have learned what we mean by "move". --Trovatore (talk) 00:18, 27 June 2026 (UTC)[reply]

Exactly. On Windows or Mac you can rename a file as many times as you want with no consequences. On Wikipedia, unless you're a page mover, every move leaves a redirect behind, which can quickly make a huge mess if a page is rapidly moved to a bunch of different titles. SuperPianoMan9167 (talk) 00:21, 27 June 2026 (UTC)[reply]

Walk me through that logic: if we call it "rename," people who would otherwise be confused by calling it "move" would change the title of pages, and that's a bad thing because...? Whereas, if we call it "move," then people who are confused by that would not change the title of pages, and that's a good thing because...? Levivich (talk) 03:59, 27 June 2026 (UTC)[reply]

Because they are not just changing the title of a page, in the sense of something a reader of that page sees. They are changing the global index to the page, and it has consequences beyond what you see on that page itself. Users who haven't internalized that fact probably shouldn't be doing that, because it has consequences they may not predict. --Trovatore (talk) 06:10, 27 June 2026 (UTC)[reply]

"Global index"? Do you mean Page ID? When you move a page, I do not think that changes the page's Page ID. Can you explain what you're talking about with "global index"? Levivich (talk) 15:58, 27 June 2026 (UTC)[reply]

Global index in the sense of the canonical key used to look up the resource from anywhere in Wikipedia. I assume under the hood there is some sort of unique identifier that can't be changed, and when you move a page what you are doing is changing a map somewhere from titles to these identifiers. But I don't know enough about the implementation of MediaWiki to be sure about that. The point is there is some sort of map somewhere for looking up the resource from the name, and when you move an article, you change that map, not just the name on the page. --Trovatore (talk) 18:30, 27 June 2026 (UTC)[reply]

Maybe if you don't know enough about the implementation of MediaWiki to be sure, then you shouldn't be building your argument on your guesses about how it might operate?

I assume that there is "some sort of map somewhere", but I don't see why "changing that map" necessarily involves moving anything. The individual revisions presumably stay in exactly the same blocks on the disks that they're already in.

I also don't see any reason why a non-technical end-user should have to be confronted with any low-level technical considerations. WhatamIdoing (talk) 03:28, 1 July 2026 (UTC)[reply]

@Levivich Thank you very much for your reply. I don't think we disagree on that it would still be possible to explain action after this proposal, it isn't absurd in nature. I'm more concerned that it would be much less intuitive. I'm worried that an apparently self explanatory feature (that rename usually is in like a file system) that this won't happen as much and we'd get more bad moves requiring PMR intervention. However I have to admit that that is just pure speculation and that I (and possibly everyone in this discussion) cannot really know whether worries such like mine would come true or if it would be a real improvement to the effort.

This discussion is probably too far along by now and I have no idea how large the technical effort would be (and there's the problem with all policies and essays) but I would find something like a month test period interesting where we could track wether the entire process lightens up a bit or we'd get more endlessly confused users or bad moves. Have a nice day, Squawk7700 (talk) 20:56, 27 June 2026 (UTC)[reply]

• Oppose the page isn't being renamed it's literally being moved from one location to the other, e.g. Horbob → Draft:Horbob. This proposal clarifies and simplifies nothing, and is less accurate as to what is actually going on and would cause more headaches than in solves. Headbomb {t · c · p · b} 03:27, 27 June 2026 (UTC)[reply]

  @Headbomb, is "moving" really how a change of namespace works? I understand that the revisions stay in the same place. It's not like the servers have different hard drives for "mainspace" and "draft space" revisions. WhatamIdoing (talk) 03:29, 1 July 2026 (UTC)[reply]

• Comment Much has been said about new users, and I just don't think there is any reason to believe that new users as a group really care (some certainly might). I say this as being a new user once, who did a cut and paste "move": I copied, deleted and dropped the text elsewhere, and I even "redirected" (because I had seen redirects). And I did not do that "move" because of what the process is called, and I certainly did not look for "rename". It was soon explained to me that it is a process called move and that what I did, did not bring the history along, my response was something like 'oh, ok.' (I was not shamed by whomever told me that and they, with grace, cleaned up my mess. Nor did I feel mortified, one wit.) -- Alanscottwalker (talk) 10:11, 27 June 2026 (UTC)[reply]
• Oppose - Move better describes what's actually happening. What we should do is fix things up so that new users more readily find WP:MOVE when they search the help system for rename and get them oriented to how title and namespace changes work in Wikipedia. ~Kvng (talk) 15:50, 27 June 2026 (UTC)[reply]

I converted Wikipedia:Rename from a redirect to a disambig. Helps a bit. I'd like WP:RENAME to have the same treatment, but WP:RENAME is protected. ~Kvng (talk) 21:16, 29 June 2026 (UTC)[reply]

You could nominate it at WP:RFD (I'd recommend that over boldly retargetting even if it weren't protected) but I'd suggest waiting for this discussion to conclude first. Just note in your nomination that the redirect is protected and an admin will add the tag for you. Thryduulf (talk) 22:05, 29 June 2026 (UTC)[reply]

I agree with Thryduulf. Take it to RFD, but wait until this concludes and to see if the conversion to a dab page sticks. These outcomes will be informative. —Myceteae‍🌈 (talk) 01:29, 30 June 2026 (UTC)[reply]

• Oppose as it makes little sense to say that a page will be renamed when accepting a draft. The creator would expect it to be renamed from Draft:A to B if the draft were to be accepted. Also, if a disambiguation tag were to be added, modified or removed (and the bit outside the brackets remains unchanged), then its a page move rather than a page rename to me. As a comparison, users who create drafts often use 'declined' and 'rejected' interchangeably. (the former means that a resubmission is still possible while the latter means that it isn't as the reviewer has determined that it would clearly be deleted if it were an article, at least at the current state, and its only possible to resubmit after discussion it with the reviewer). Changing these might make it easier for new users, but it may make it harder for experienced and established users to adapt to the new name. JuniperChill (talk) 18:13, 27 June 2026 (UTC)[reply]
• Oppose. As mentioned and argued by many others above, "renaming" is just a subset of moving, which also includes moving between namespaces (e.g. when publishing AfC drafts, draftifying during NPP, or userfying at AfD). It's also an inaccurate descriptor that implies an action done to a single page, while the status quo correctly describes the action of transferring one page to another title... or "moving" in layman's terms. Let's just call a spade a spade. UpTheOctave! • 8^va? 15:26, 29 June 2026 (UTC)[reply]
• Oppose - Move is the better description. Rename is just a special case of the move function in which the document is conceptually moved within the same namespace, and the movement is indeed just a change of name. But that is not all moves. One of the most common moves is a cross namespace move, especially moving a draft into mainspace. These are conceptual moves of the page because the page was in one namespace and is now in another. Calling that a rename is at least as bad as calling an in-namespace change a move. The more generic term is better, and that is why Unix systems have the mv command (namespaces being replaced, conceptually, by directories and filesystems).
  And I think the answers looking at what actually happens to the data are missing the point. Filesystem fragmentation is irrelevant, because a filesystem is organised to conceptually describe an arrangement of files for the user of the filesystem while keeping track of the filesystem blocks where the data is stored behind the scenes (and also while ensuring very large files can be accommodated, random access is supported, space is not wasted, and usually that small files are prioritised). Wikipedia pages are actually served from a database but also arranged to conceptually look like a filesystem (I argue that the web itself may be considered a massively distributed virtual filesystem). There are abstractions on abstractions, and what happens to individual disk blocks will never be the concern of people undertaking the page move. That pages do conceptually move is not a hard concept to grasp, and calling this a rename will not remove confusion, unless the function is separated out from cross namespace moves. We don't need to do any of that. Sirfurboy🏄 (talk) 15:58, 29 June 2026 (UTC)[reply]

• Support - The opposition here seems heavily focused on the technicality of what the software does. The problem is that it is nonetheless very confusing to newcomers, including myself when I was first starting out. Not only that, but that is what the feature is doing from a user perspective. Even when it is "moved" to another namespace, it still seems like a renaming is done to accomplish that. The best way to explain it to newcomers it just to tell them that titling an article with a certain prefix will put it in a certain namespace, and that renaming the article will automatically create a redirect from the old title. It's easy to understand for someone just starting out on Wikipedia. AaronNealLucas (talk) 02:22, 30 June 2026 (UTC)[reply]

  The point of my comment that you explicitly reply to is that the supporters were the ones heavily focused on the technicalities. As to your point, I think that denying a move from one namespace to another is a move will spread confusion as to what is meant by a namespace. A namespace is not just a trick of titling, it is a scope or naming domain. New editors need to understand that, so the move terminology is actually an aid to them. I understand editors have much to learn, but some lessons are very useful. Sirfurboy🏄 (talk) 07:30, 1 July 2026 (UTC)[reply]

@Sirfurboy, I agree with you that "answers looking at what actually happens to the data are missing the point" (also, I think they're mostly wrong), but I don't agree with you that changing the title is when a "document is conceptually moved within the same namespace". I think that when you change a title, the document is conceptually kept right where it is, and only the exterior label is changed. WhatamIdoing (talk) 03:32, 1 July 2026 (UTC)[reply]

Within a namespace, both are right. You are merely changing the title without taking it from one namespace to another (as you say), or the namespace consists, conceptually, of an extent in which all valid names may be located/mapped, and changing the name moves the location of the page within the extent. That model is contained in the term "namespace" as well as terms such as "mapping" used to describe a namespace. I get that not everyone thinks of it that way, but it is still a valid model of a namespace. Although reasonable people will disagree on that, and although you could even argue that "rename" is better if all moves are within namespace, it is where movement is from namespace to namespace that the term rename becomes actively confusing. Sirfurboy🏄 (talk) 07:22, 1 July 2026 (UTC)[reply]

• Oppose - Move is more descriptive of the process than rename. While usernames are used for identification, page titles are used emphatically as addresses. To "rename a page" is to change its address. As per Godsy, the action of moving invites the operator to consider the address left behind, and the other pages that might still target that address. Wikipedia is often thought of as a network of nodes and edges representing pages and links, and I find that "moving" is the more accurate than "renaming" in that common visualization. Wikipedia is admittedly complicated, but changing descriptive terms to more immediately intuitive ones just delays confusion, rather than abating it. Trevan Cooley (talk) 04:34, 30 June 2026 (UTC)[reply]
• Why not just relabel the "move" button in the "tools" sidebar to "move/rename article"? Or if we really want to hold hands add a second button called "rename article" that takes you to a dialog box where you can't change the namespace and there's a perma-selected (greyed out or invisible) "rename associated talk page" button. That way it would just be a UI thing without needing to change the backend anywhere. JoelleJay (talk) 10:44, 30 June 2026 (UTC)[reply]

  I like this suggestion. WhatamIdoing (talk) 03:33, 1 July 2026 (UTC)[reply]

• Support per BD2412: guidelines for moving content from article to article suffer because of this convention. And per Gnomingstuff: "rename" is more descriptive of what is usually happening, and it's not conceptually a move from the perspective of anyone who doesn't see the (deliberately very flat) directory topology. The fact that pseudonamespaces can exist means namespace notation isn't even a guarantee of a technical or topological difference. Alternatively, I support "move/rename" per JoelleJay. TheFeds 03:13, 1 July 2026 (UTC)[reply]

Copied from WP:VPT, as I am told this is not a technical question. I work with reference templates quite a lot, and in quick succession, and it is a minor but persistent annoyance to me that sometimes it is not easy to see exactly where a URL ends and the next parameter begins because there is no space before the next pipe. I think it would be trivially easy to have a rule that a URL in a template with parameters separated by pipes should have a space before the pipe, and have a bot go around and add those spaces. Another editor suggested there that it would be good to have a space before all pipes, which I would agree with as well. BD2412 T 21:47, 21 June 2026 (UTC)[reply]

• Support both space between url and pipe, and space before all pipes in these templates (reader, I am that other editor). I believe, as an editor who does a lot of fixing other people's citation errors, that these changes would tend both to make error detection easier, but also to make it harder to make the error in the first place. Both of these are highly desirable results. DuncanHill (talk) 21:52, 21 June 2026 (UTC)[reply]
• If an editor uses citer.toolforge.org, it includes spaces before the pipes. How do other cite formatting tools that people use behave? Schazjmd (talk) 23:27, 21 June 2026 (UTC)[reply]
  • @Schazjmd: I typically use ReFil, which does not put spaces around pipes, but probably could easily be made to do so. BD2412 T 01:28, 22 June 2026 (UTC)[reply]
• Support although I don't mind too much either way (I already format my references with a space before pipes but not after them). It doesn't seem particularly disruptive, so if it helps other editors with their editing I'm alright with it, and I'm fairly sure it would be relatively simple to have a bot go around fixing references to follow this format. Also, if we're going to require a space between the end of a URL and a pipe we should also be requiring it before all pipes as it would just make references look goofy to insist on doing it for just one parameter. ⹃Maltazarian ^{ᚾparley${\displaystyle \lor }$investigateᛅ} 12:23, 22 June 2026 (UTC)[reply]

  To be clear I would still support the proposal even if it only applies for the URL parameter for the same reasons as I would otherwise (other editors say it would help them edit so let's do it). ⹃Maltazarian ^{ᚾparley${\displaystyle \lor }$investigateᛅ} 15:15, 23 June 2026 (UTC)[reply]

• Agree with the rationale and support a general presumption that spaces before pipes are helpful to editors, and support including the addition of spaces as part of editing tool processes. (A bot running around fixing only this may run into WP:COSMETICBOT concerns, but rolling it into other tools should shift this over time.) CMD (talk) 12:40, 22 June 2026 (UTC)[reply]
• Support, this would be a nice visual demarcation between template parameter fields, and I can't conceive of any downside to it. Seraphimblade ^{Talk to me} 02:14, 23 June 2026 (UTC)[reply]
• Support This would make things so much easier. Even if it was only the suggested way, so as to respect WP:CITEVAR, and automated tools were updated. -- LCU ActivelyDisinterested «@» °∆t° 14:00, 23 June 2026 (UTC)[reply]
• Support This is an absolute minimum if you want the markup to be editor friendly. I find that white space makes editing easier. My preference is one parameter per line, aligned, but even adding one space is an improvement. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 14:26, 23 June 2026 (UTC)[reply]
• Oppose per WP:CITEVAR. If an editor prefers an article's citation templates to be formatted more tightly (for instance because it makes it easier to skip past citations when reading article source text) then we should respect that preference. Also because imposing extra formatting requirements on citations makes human editing much more difficult and imposes unnecessary bot churn and watchlist clutter, for something that is totally unnecessary. —David Eppstein (talk) 18:44, 23 June 2026 (UTC)[reply]
• Strong oppose to "spaces before all pipes". This would mean lots of linebreaks within the otherwise nice and uncluttered {{sfn}}'s. I can't see any advantage to enforcing this for templates used within the main text. —Kusma (talk) 18:48, 23 June 2026 (UTC)[reply]

  {{ill}} is another example where added whitespace would decrease readability instead of increasing it. Not all templates are the same. —Kusma (talk) 18:59, 23 June 2026 (UTC)[reply]

  As stated below, this wouldn't be applicable to templates that don't have URLs entered into their parameters. ⹃Maltazarian ^{ᚾparley${\displaystyle \lor }$investigateᛅ} 19:10, 23 June 2026 (UTC)[reply]

  I read several of the replies as applying this to all pipes in all templates. Anyway, I generally oppose us having guidelines for how to use whitespace in wikitext; while certainly my indentation style and date formatting choices are superior to those of other editors, the spirit of WP:ENGVAR and WP:CITEVAR seems much more helpful to editors to me than bot-enforced uniformity. If bots enforce a particular style, it should be my style. —Kusma (talk) 19:27, 23 June 2026 (UTC)[reply]

  Looking back at it I suppose I have to agree it is ambiguous. I certainly did not intend to suggest it must apply to all templates. I meant that if we apply it to the URL parameter of a template then we should also apply it to the rest of the parameters of that template.

  As for the spirit of ENGVAR and CITEVAR: I prefer having consistency over trying to adapt to each articles own little idiosyncrasies in situations where it is feasible to do so (uniform spelling is out of the picture, for example). ⹃Maltazarian ^{ᚾparley${\displaystyle \lor }$investigateᛅ} 20:12, 23 June 2026 (UTC)[reply]

• Support This is what I am currently doing when I manually create or edit full citations. And, @Kusma:, I interpret this as applying to full citations, not to sfns. Donald Albury 19:02, 23 June 2026 (UTC)[reply]

  "This is what I am currently doing" is not a good rationale for "everybody should be forced to do it the way I do it". —David Eppstein (talk) 01:57, 24 June 2026 (UTC)[reply]

• Oppose. We should not enforce personal preferences in policy. Very strongly oppose any bot making these changes per WP:COSMETICBOT. Thryduulf (talk) 19:32, 23 June 2026 (UTC)[reply]

  We should not enforce personal preferences in policy. Don't we have an entire namespace dedicated, with some exceptions, to doing just that? ⹃Maltazarian ^{ᚾparley${\displaystyle \lor }$investigateᛅ} 20:14, 23 June 2026 (UTC)[reply]

  The manual of style is not a personal preference, nor does it deal with the presentation of things that have exactly zero impact on the reader. Thryduulf (talk) 20:51, 23 June 2026 (UTC)[reply]

  I'm fairly sure the MOS does have some guidance saying that certain things should be done in a particular way in the markup even though multiple methods can be used achieve the same result (and be just as accessible). Parts of MOS:LIST come to mind. ⹃Maltazarian ^{ᚾparley${\displaystyle \lor }$investigateᛅ} 01:36, 24 June 2026 (UTC)[reply]

  The manual of style has guidance on lists that affects their appearance and rendering, including how screen readers read them. It doesn't provide guidance on wikitext syntax that doesn't affect how the lists are displayed. (On a side note, the manual of style isn't a namespace.) isaacl (talk) 02:09, 24 June 2026 (UTC)[reply]

  But its redirects are :) Extraordinary Writ (talk) 04:27, 27 June 2026 (UTC)[reply]

  Ahh, I'd either forgotten about that or missed any on-wiki discussion. Thanks for the clarification. isaacl (talk) 04:10, 1 July 2026 (UTC)[reply]

• Support – Nominator makes a good point, I myself hate having to identify where the next parameter begins. Of course, if this passes, I very strongly support this rule being enforced by a bot, otherwise it would just become a silly suggestion for the few editors who will know about it. Simple solution to a simple problem. FaviFake (talk) 19:52, 23 June 2026 (UTC)[reply]

  A bot editing six million Wikipedia articles to make changes that do not affect the HTML output is not a "simple solution" to the problem that the OP is sometimes confused while reading wikitext. —Kusma (talk) 20:02, 23 June 2026 (UTC)[reply]

  How else are you gonna enforce it then? Edit filter? FaviFake (talk) 20:05, 23 June 2026 (UTC)[reply]

  Why would it be enforced? We don't any other personal preferences. Thryduulf (talk) 20:07, 23 June 2026 (UTC)[reply]

  It's not a personal preference if there's consensus for it. FaviFake (talk) 20:14, 23 June 2026 (UTC)[reply]

  It's entirely a personal preference. Some people find spaces more readable, some people find compact code more readable, some people just don't care. Neither is more objective than the other. We don't enforce a consensus for single or double spaces after full stops because it is a personal preference that makes exactly zero difference to readers. Thryduulf (talk) 20:54, 23 June 2026 (UTC)[reply]

  (And yet I do still see the occasional editor removing double spaces after full stops, in the mistaken belief that it's a helpful edit.) WhatamIdoing (talk) 01:45, 24 June 2026 (UTC)[reply]

  No one actually finds compact code more readable when looking at URLs. BD2412 T 01:49, 24 June 2026 (UTC)[reply]

  False. It is definitely more readable if what you are trying to do is read past the reference to find the article text that it is the reference for. They are more compact (making skipping over them easier) and more visually distinctive (because of the lack of spaces). —David Eppstein (talk) 01:59, 24 June 2026 (UTC)[reply]

  If that's what you're looking for, why would you be looking at the Wikitext at all? BD2412 T 02:13, 24 June 2026 (UTC)[reply]

  To edit it? —David Eppstein (talk) 02:32, 24 June 2026 (UTC)[reply]

  Are you looking for referenced article text to appear after the reference, rather than before it? BD2412 T 02:37, 24 June 2026 (UTC)[reply]

  References appear in more places than just the ends of paragraphs. For example special:Random took me to Fish crow, which has multiple mid-paragraph references. Those are formatted with spaces, which means that at a glance it's not easy to tell what is prose and what is citation template when looking at the wikitext. Thryduulf (talk) 03:10, 24 June 2026 (UTC)[reply]

  Nope, I often do. Not always, but usually. Thryduulf (talk) 02:20, 24 June 2026 (UTC)[reply]

  (Replying to WhatamIdoing) Wait, what? Should I not be doing this? I know they aren't displayed, but is there a rule against this I should be aware of?? :0 JordyGrey _talk🧸 03:53, 25 June 2026 (UTC)[reply]

  You should not be doing this, because it's a cosmetic edit. It's acceptable (but still a pointless waste of time that makes diffs harder to read) if you make some other, non-cosmetic change in the same edit. WhatamIdoing (talk) 19:39, 27 June 2026 (UTC)[reply]

• Oppose. As someone who used to remove spaces in such situations, I really don't think it matters (hence why I stopped doing that). For what it's worth, the mobile editor, last I checked (on an Android phone) does line breaks after pipes. I'd go as far as to say that adding spaces (especially after every parameter) just makes it harder to tell when the cite template ends. That said, I'm not so sure I'm fond of inline citation templates that give each parameter its own line (list-defined references are OK). -Brainulator9 (TALK) 00:24, 24 June 2026 (UTC)[reply]
• @BD2412, can you give an example of what you're looking for, or which templates are the main offenders? For the main CS1 citation templates, we changed the Wikipedia:TemplateData to add spaces between paramenters a few years ago. Infoboxes use block formatting. I wouldn't necessarily expect to see spaces in a short template (e.g., we expect to see {{convert|1|in|cm}} instead of {{convert | 1 | in | cm}}). WhatamIdoing (talk) 01:44, 24 June 2026 (UTC)[reply]

  For example, the first citation in Money#Measure of value, with the template containing two URLs (the original and the archive version) appearing as <ref>{{cite web|date=2017-10-11|title=Functions of Money|url=https://www.boundless.com/business/textbooks/boundless-business-textbook/the-functions-of-money-and-banking-21/money-as-a-tool-123/functions-of-money-568-3194/|url-status=dead|archive-url=https://web.archive.org/web/20151018115939/https://www.boundless.com/business/textbooks/boundless-business-textbook/the-functions-of-money-and-banking-21/money-as-a-tool-123/functions-of-money-568-3194/|archive-date=October 18, 2015|website=[[Boundless (company)|boundless.com]]}}</ref>. Without any kind of space in the template, the first URL could be read as:

  https://www.boundless.com/business/textbooks/boundless-business-textbook/the-functions-of-money-and-banking-21/money-as-a-tool-123/functions-of-money-568-3194/%7Curl-status=dead%7Carchive-url=https://web.archive.org/web/20151018115939/https://www.boundless.com/business/textbooks/boundless-business-textbook/the-functions-of-money-and-banking-21/money-as-a-tool-123/functions-of-money-568-3194/%7Carchive-date=October

  That is, frankly, the only template configuration that I care about with respect to this issue. BD2412 T 01:59, 24 June 2026 (UTC)[reply]

  Why are you converting pipes to %7C encoding? Surely that would break the template? Thryduulf (talk) 02:20, 24 June 2026 (UTC)[reply]

  @Thryduulf: Oh, I didn't do that; your browser does that all by itself, because it's trying to be helpful. Go look at the wikitext. BD2412 T 02:28, 24 June 2026 (UTC)[reply]

  Specifically it's URL encoding. – The Grid (talk) 12:58, 24 June 2026 (UTC)[reply]

• Oppose per CITEVAR. Also, I don't think anyone voting support realizes just how annoying this would be for next to no benefit. PARAKANYAA (talk) 04:01, 24 June 2026 (UTC)[reply]
• Oppose - It is difficult enough to get citation templates to not throw back errors; oppose anything that alters them cosmetically by bot on the off-chance something might be affected. Also per David Eppstein. Reminds me of university paper formatting to the eye preferences of particular faculty members. — Godsy ^(TALK_CONT) 07:18, 24 June 2026 (UTC)[reply]

• Oppose this is not something that needs to be legislated by policy. There are several ways to have editor-friend wikitext. Compare

*{{cite book |last=Smith |first=John |year=2006 |title=Book of Things |url=https://example.com}}
*{{cite book
 |last=Smith |first=John
 |year=2006
 |title=Book of Things
 |url=https://example.com
}}
*{{cite book
 | last=Smith | first=John
 | year=2006
 | title=Book of Things
 | url=https://example.com
}}
*{{cite book
 |last = Smith |first = John
 |year = 2006
 |title = Book of Things
 |url = https://example.com
}}
*{{cite book
 |last  = Smith
 |first = John
 |year  = 2006
 |title = Book of Things
 |url   = https://example.com
}}

with

{{cite book|last=Smith|first=John|year=2006|title=Book of Things|url=https://example.com}}

The 'visual' problem doesn't concern the url parameter alone, but every parameter. By all means, improve the output of tools (e.g. Wikipedia talk:RefToolbar/Archive 2#Put spaces to the left of pipes). But requiring a certain solution for one parameter isn't the way. Headbomb {t · c · p · b} 13:13, 24 June 2026 (UTC)[reply]

• Support space after URL, space before pipes in all templates including sfn, and a bot to make the change site wide. In Headbomb's examples above, all of those formats are easily readable except the one that has no space before the pipe. Bots edit pages all day every day, I'm not worried about one more bot edit per article, well worth it to make those citation templates readable in wikisource. Levivich (talk) 04:06, 25 June 2026 (UTC)[reply]

Oppose per @Headbomb Dw31415 (talk) 15:36, 25 June 2026 (UTC)[reply]

• Support mandatory space after URLs, also support mandatory spaces before pipes in cite x reference templates like Template:Cite web. Oppose requiring this in general, which really does come closer to a personal preference, and compact forms for common templates like Template:Sfn or Template:Harvnb are fine. Why: For these reference templates, it's not a personal preference, it's a usability issue. When editing in source editor, refusal to use spaces results in weird line wraps that makes it harder to parse the template and its arguments. There's no benefit to spaceless form, and there is a real if minor usability harm. Check out a spaceless form of a cite web website with a long URL and a longer archive URL... it can get crazy. SnowFire (talk) 16:49, 26 June 2026 (UTC)[reply]
• Comment I already support it in my practice: " |" and "=", i.e. space before pipe, no space around equal signs. Using the old editor helps search and replace. For tables, that becomes problematic. So it's context-dependent.Selbstporträt (talk) 06:45, 27 June 2026 (UTC)[reply]
• Oppose, per Headbomb. I think it's good practice to do this, and would have no objection if various tools avoided producing template output with no spaces around the pipes, but we shouldn't legislate it, and per COSMETICBOT no bot should ever do this, unless writing a modified form of the template. Mike Christie (talk - contribs - library) 10:46, 27 June 2026 (UTC)[reply]

Should items in ITN Ongoing automatically roll off after 45 days? 03:25, 24 June 2026 (UTC)

Note: The RfC tag on this discussion has been removed twice, with the editors suggesting that this be treated as a WP:RFCBEFORE. For that reason I'll use this discussion to guide the opening of a new RfC, when discussion on this dies down. BilledMammal (talk) 01:30, 29 June 2026 (UTC)[reply]

• Support. We now have ten items in ITN ongoing. This is ridiculous, and a consequence of this has been that we now only have space for three items in ITN itself. It also has stopped being useful; a reader going to Russo-Ukrainian war (2022–present) will struggle to find recent news about the war, such as the attacks on Saint Petersburg and Moscow. If there are sufficiently notable events related to the conflict - such as the Kharkiv offensive, the sinking of the Moskva, or the fall of Pokrovosk - then we can create an ITN entry, and direct readers to the relevant article rather than one that takes a longer-term view.

This also won't cause ITN to be overloaded; even with only three articles listed the oldest is almost two weeks old, so having a few extra stories on topics currently covered under ITN ongoing won't be disruptive. In addition, the 45 day period will still allow us to include events like the Olympics and the World Cup for the full length of the event.

As a second choice abolish ITN Ongoing entirely, because something needs to be done. BilledMammal (talk) 03:25, 24 June 2026 (UTC) Edited per Natg 19 BilledMammal (talk) 04:58, 24 June 2026 (UTC)[reply]

• Support in general, or at least that a review at ITN should be held to make sure the item is still being updated properly with ongoing significant news coverage (and not just gnoming type edits). Eg: to me it makes no sense yet to remove the Ukraine/Russian conflict, that still dominates the news, but every 45 days, or maybe 60, it should be put for an ITN review. That might help identify that there's a new timeline page, or a better target, or something along those lines. But I think we also need a better way to judge an ongoing item, like the Sudanese civil war is getting nowhere close to the attention of other ongoings, and the timeline is not updated since the 10th, so this is a prime candidate to go (which I will nominate immediately after this). We don't keep something in ongoing just because the event in ther real world is ongoing, there has to be a good volume of sourcing to keep it there and the article has to show sufficient updates. Masem (t) 04:27, 24 June 2026 (UTC)[reply]
• Support in principle, as I agree that there are ongoing articles that are on ITN too long, so there should be some sort of review process. However, the conclusions being drawn are incorrect. ITN has always had between 3-5 items blurbed, and the length of the ongoing section is not a major factor for this. (Earlier today, there were 4 blurbs, and a few days ago there were 5 blurbs.) This is typically a concern for admins to maintain the balance of the main page (WP:ITNBALANCE), and admins will add or remove blurbs based on this. Strong oppose the option to remove ongoing altogether as that is not at all necessary. Natg 19 (talk) 04:49, 24 June 2026 (UTC)[reply]
• Oppose mandatory removal after X days. Remove articles that have been listed there on a case-by-case basis. —Kusma (talk) 04:59, 24 June 2026 (UTC)[reply]

• Support in general. We definitely need this limit for the ongoing section as it's very unreasonable to have more ongoing items than blurbs (at the moment of writing this comment, there are seven ongoing items and three blurbs). I understand that there are multiple ongoing conflicts and events of wider significance whose timeline articles receive regular updates, which doesn't fully abide by WP:ONGOING, but it doesn't mean that prolonged ongoing events should be kept for good. The concept of 'news' is to inform people about notable current events, and a time frame of 45 days is reasonably long enough so that most people learn about an event. Furthermore, as ongoing events extend well over time, people get used to them and their coverage becomes routine (see WP:ROUTINE and WP:RUNOFTHEMILL). As for the time limit, the longest event that we post to ongoing with known duration is the FIFA World Cup, which lasts 38 days in the current format, so 45 days sounds like a reasonable time. --Kiril Simeonovski (talk) 07:34, 24 June 2026 (UTC)[reply]
• Support – The way I see this: if no one has done a blurb proposal for a news story covered by an Ongoing item for 45 days, then that ongoing-feature is likely no longer serving the original purpose. In general I am in favor of shorter-term ongoings. We can't possibly be massively overhauling an article constantly for over a year, and the front-page should not be filled with static content. ~Maplestrip/Mable (chat) 08:04, 24 June 2026 (UTC)[reply]

  if no one has done a blurb proposal for a news story covered by an Ongoing item for 45 days, then that ongoing-feature is likely no longer serving the original purpose

  Blurb discussions are often shut down explicitly since items are in ongoing (see the blurb noms for the Iran war as an example). Most editors on ITN see ongoing (which is somewhat true, although like many thing there, this has been overdone) as a way to offput blurbs for items frequently in the news, so not having a blurb proposal is largely by design. — Knightoftheswords 00:53, 25 June 2026 (UTC)[reply]

• Oppose. I don't like the idea of automatic removal, there should be some involvement in deciding(we don't automatically remove ITN items). There's no need to formally require a review, as any editor is free to start a proposal to remove an item("the Ukraine war has been up too long, let's remove it.") Ongoing can and has posted a significant event from an Ongoing event when called for. ITN, due to its name, is often misunderstood as a source of news, when its intention is to highlight articles about the news. I've long advocated that it should be easier to post something to ITN to increase movement(and that more articles posted is a good thing, not a bad thing). Ongoing isn't meant to require a "massive overhaul" every day, simply timely and regular updates. 331dot (talk) 08:13, 24 June 2026 (UTC)[reply]
  • we don't automatically remove ITN items This is absolutely wrong. Blurbs roll off because the room of the ITN box is limited, and RDs roll off because the limit per WP:ITNRD is six recent deaths. In both cases, however, we automatically remove the oldest news and recent deaths. The only missing puzzle with no restriction on such removal is the ongoing section. An alternative to time limit is maximum number of ongoing items (in a similar way as we have for RDs). Otherwise, the section will continue to grow without control and occupy the largest part of the ITN box. --Kiril Simeonovski (talk) 08:54, 24 June 2026 (UTC)[reply]

    They don't roll off based on an arbitrary time period, they roll off as new ones arrive. Would be open to a limit on the number of listings for ongoing(since we also limit ITN). 331dot (talk) 08:56, 24 June 2026 (UTC)[reply]

    Exactly, and that's why we need a rule that old ongoing items should be removed as new ones arrive. One way is to set a time limit, the other way is to set a maximum number. --Kiril Simeonovski (talk) 09:00, 24 June 2026 (UTC)[reply]

    I'd rather see a limit on the number of items rather than a time period(which would suggest items would leave and not necessarily be replaced)

    Has this discussion been brought to the attention of ITN? 331dot (talk) 09:03, 24 June 2026 (UTC)[reply]

    No (see the procedural note in the 'Discussion' section below). --Kiril Simeonovski (talk) 09:06, 24 June 2026 (UTC)[reply]

• Oppose. The solution isn't removal after an arbitrary time not abolishment of ongoing as a whole, rather the solution is to impose a maximum number and/or to periodically have a automatic renewal discussion (with no prejudice to keeping an item in ongoing if it meets the usual requirements). Thryduulf (talk) 09:07, 24 June 2026 (UTC)[reply]
• Support. It's not really in the news if it's been there for 45+ days. FaviFake (talk) 09:17, 24 June 2026 (UTC)[reply]

  Then that's an argument that can be used in a discussion to remove the item; we don't need an arbitrary time limit to do that.(which, as I said, would mean things would be removed but not necessarily replaced, as with ITN proper.) 331dot (talk) 09:27, 24 June 2026 (UTC)[reply]

  That's not always true, for example the Russia-Ukraine war is still ongoing after more than 45 days. Thryduulf (talk) 09:32, 24 June 2026 (UTC)[reply]

  Yes, and in that case it's no longer relevant enough to still be included here. It could be replaced with an article about a ore recent event in the war, for example. FaviFake (talk) 09:55, 24 June 2026 (UTC)[reply]

  It is certainly relevant enough, if being "in the news" is the measure. On the other hand, if you have the feeling that it should be replaced with something more recent, probably others feel that, too. Maybe that feeling is based on a view that would argue for calling the module "Breaking News" instead, which would be more aligned to the way you view what should be covered there. On the other hand, if a war is going on (or more precisely, being covered daily) then I think I would be shocked *not* to find it there. To some extent, it comes down to a core question of what this module is really for. Mathglot (talk) 10:29, 24 June 2026 (UTC)[reply]

  Ongoing is motivated by the Olympic summaries that we had used to post long time before it existed, and the key moment that led to its introduction was when the concept was expanded to the Arab Spring protests in order to prevent the ITN section from overflooding with blurbs on seemingly related events. Hence, its original purpose was to prevent multiple blurbs documenting a single event from being posted at the same time, not to keep major ongoing events on the main page simply because they're ongoing, and that's why WP:ONGOING requires regular updates to the article. As time went by, however, we significantly departed from the original purpose and began repeatedly invoking WP:IAR by posting timeline articles in brackets to justify that an item should still be kept (note that WP:ONGOING nowhere mentions that updates to sub-articles are sufficient). So, the answer to your core question is that 'ongoing' isn't as descriptive as it sounds. --Kiril Simeonovski (talk) 11:46, 24 June 2026 (UTC)[reply]

• Oppose in current form. While ongoing section is getting longer, it is also a result of that there more high impact continuing events than before in the various parts of the world. Having an arbitrary cutoff does not reflect the ongoing nature of these events. Instead, we can focus on other aspects such as if the ongoing entry has timely updates, instead of editors getting prodded to update the item when the entry comes up for discussion because the lack of timely updates. What for have it on the main page if the readers are not being kept abreast with developments on a day to day basis? – robertsky (talk) 09:43, 24 June 2026 (UTC)[reply]
• Oppose automatic time. I think a main purpose of ongoing is to save space and time, without it, all (most) the blurbs would be about ongoing matters. But I would support limiting the number, which would require more finely detailed editorial judgement. Alanscottwalker (talk) 13:07, 24 June 2026 (UTC)[reply]
• Oppose , for example the Russia-Ukraine war still is ongoing and still has plenty of developments. That something is lasting for long is not a reason to exclude it from the ITN sections, especially since it's still newsworthy. Headbomb {t · c · p · b} 20:11, 24 June 2026 (UTC)[reply]
• Oppose per Robertsky. Just since they're are more noteworthy events happening at a time doesn't mean that we need to start automatically dropping stories. Besides, a few of those entries could prolly just be removed via independent noms. — Knightoftheswords 00:51, 25 June 2026 (UTC)[reply]
• Oppose per Robertsky's comment on there being "more high impact continuing events" and Headbomb's comment on newsworthiness. S5A-0043🚎^(Talk) 03:59, 25 June 2026 (UTC)[reply]
• Oppose per Headbomb. GenevieveDEon (talk) 10:11, 25 June 2026 (UTC)[reply]
• Support in general. I think a time limit on Ongoing is preferable to a limit on the number of items. If an ongoing story is still worthy of being kept on ITN, it can be approved for another 45 day period by discussion. --Metropolitan90 (talk) 13:45, 25 June 2026 (UTC)[reply]
• Support 45 days in most cases is ample, and requests for extensions can be considered case by case.--Wehwalt (talk) 15:03, 25 June 2026 (UTC)[reply]
• Oppose as arbitrary. Why 45 days? Ongoing events don't just stop being relevant after a certain period of time has passed. I get the bar for an Ongoing item leaves open the possibility of way too many items in Ongoing, but the solution should be raising the bar for inclusion, not early removal. If not, I think we should consider a maximum number of Ongoing items, wherein one is removed when we're adding a new Ongoing item at a certain point. For example, if we have a limit of five, adding a new item after five would bump one item out, say, the article with the lowest volume of substantial edits in the past week. But a blanket limit isn't productive to the purpose of the section, IMO. DarkSide830 (talk) 02:01, 26 June 2026 (UTC)[reply]
• Oppose. Is the current process for removing an item from Ongoing insufficient? Or is the complaint that !voters in these removal discussions are "wrong"? If you truly think that there are items that should be removed, propose their removal. If ITN !voters are "wrong", then propose stricter criteria for "Ongoing" and get it changed. I don't think a simple day limit is the way to make criteria stricter, though. (As a side comment, I only count 7 topics in Ongoing, not 10 - it's 10 links but 7 topics.) SnowFire (talk) 16:58, 26 June 2026 (UTC)[reply]
• Oppose per Headbomb and Robertsky. To a reader, it would not be clear why some items that are ongoing are not on the list; right now the dichotomy between the regular blurbs/ongoing/recent deaths is intuitive but the proposed delineation is very much not. If there are issues with specific articles staying on there then they can be dealt with individually. Mir Novov (contribs | talk) 11:53, 27 June 2026 (UTC)[reply]
• Oppose per Robertsky, more ongoing means more events going on. You can add a discussion on removal of events that is not anymore ongoing on ITN. Warm Regards, Miminity (Talk?) (me contribs) 12:00, 1 July 2026 (UTC)[reply]

• Procedural note: I don't see any evidence of WP:RFCBEFORE's

  you should try first to resolve your issues other ways. Try discussing the matter with any other parties on the related talk page. If you can reach a consensus or have your questions answered through discussion, then there is no need to start an RfC.

  For this situation, that would be an attempt to hold regular discussion on the matter at WT:ITN. To my knowledge, this has not occurred. Left guide (talk) 03:50, 24 June 2026 (UTC)[reply]
  • I've boldly removed the RfC tag. Formal RfCs represent an enormous investment of time from our community of volunteers, and to launch this without regard for RFCBEFORE/even trying to resolve concerns at the appropriate talk page is disrespectful of those people. I don't actually see any archived WT:ITN comments from BilledMammal in this calendar year, let alone comments on ITN's ongoing section, before today. Ed ^{[talk] [OMT]} 04:30, 24 June 2026 (UTC)[reply]
    • I've reverted, per my explanation below and the fact that WP:RFCBEFORE is a suggestion, not a requirement. BilledMammal (talk) 04:34, 24 June 2026 (UTC)[reply]

      Re-removed, essentially for the reasons Ed stated; this works fine as a proposal discussion. It's fine to advertise this in other projects and venues to get additional opinions if you like (have you?), and this discussion can be the one that fulfills the "before" requirement for a subsequent Rfc, but it doesn't fulfill it for itself. Then again, perhaps an Rfc won't be needed subsequently, unless this one becomes hopelessly deadlocked. Let's let the discussion continue, and see what we can learn about the situation and the issue in question. Mathglot (talk) 08:29, 24 June 2026 (UTC)[reply]

  Discussion at WT:ITN might allow us to reduce the current number of articles listed in ITN ongoing - although I think it is more likely to turn into a trainwreck - but it can't resolve the overall situation or prevent us from arriving here again. I think opening this RfC directly was the best option under the circumstances. BilledMammal (talk) 04:32, 24 June 2026 (UTC)[reply]

  Not following. Why would a discussion at WT:ITN that resulted in a consensus to permanently cap the number of ongoing entries not be able to "resolve the overall situation or prevent us from arriving here again"? After all, ongoing started with a proposal on WT:ITN.

  Also, I edit-conflicted when trying to add to my comment above that I do not have a concern with the topic of the RfC. I've certainly posted about concerns with ITN multiple times over the years! However, we have processes for a reason. I strongly object to you reverting my removal of the RfC tag, and would once again point out that you are parachuting into this situation and disrespecting the most important resource we have—editorial time. Shame, really. Ed ^{[talk] [OMT]} 04:43, 24 June 2026 (UTC)[reply]

  In my view, any discussion that resulted in a consensus to permanently cap the number of ongoing entries should be a formal discussion - we shouldn't be changing highly visible processes without broad visibility and input. BilledMammal (talk) 04:50, 24 June 2026 (UTC)[reply]

  Gotcha. That is an opinion, or really a question, that should have been asked as part of the RFCBEFORE that you decided to ignore. Plenty of changes happen on the main page "without broad visibility and input"; should Wikipedia talk:Did you know § Applying WP:EASTEREGG to hooks considered harmful happen on Talk:Main Page? Would you propose that all RfCs that aim to change the manual of style for all our articles be held here? Isn't the point of a RfC tag (as well as WP:CENT, etc.) to bring people into RfCs regardless of where they're happening? Etc. Ed ^{[talk] [OMT]} 05:17, 24 June 2026 (UTC)[reply]

• I !voted on the proposal, but I agree with others that this should've started at the ITN talk page. It was a shock to see this "complaint" opened without prior discussion at the ITN project, as in my opinion , this is more of an ITN internal matter. Natg 19 (talk) 05:02, 24 June 2026 (UTC)[reply]

  Processes with significant impact on the encyclopedia - and I include those controlling the main page in that - should in my view not be an internal matter, but a matter for the broader community. BilledMammal (talk) 05:07, 24 June 2026 (UTC)[reply]

  Then what's the point of WT:ITN? Might as well redirect it here if that premise is true. Left guide (talk) 05:11, 24 June 2026 (UTC)[reply]

  Then you are free to solicit input from the project more broadly- but ITN should at least be made aware of this discussion, if not it being held there. 331dot (talk) 09:14, 24 June 2026 (UTC)[reply]

To be fair, ITN was notified of this discussion - BilledMammal did the requisite notification template: Wikipedia talk:In the news#Wikipedia:Village pump (proposals) has an RfC. The main objection here is that this should have been discussed there first. Natg 19 (talk) 16:59, 24 June 2026 (UTC)[reply]

• Comment: the initial motivation or justification for the discussion appears to be the view that the presence of ten items in the ongoing list "is ridiculous". I am not a frequent consumer of ITN, but I don't understand why that is ridiculous. For example, on my device, the "From today's featured article" appears to the left of ITN and is longer than it by about two lines. By my reckoning, six additional items could be added to the ongoings, making the two modules about the same length, which would be easy on the eyes. Then again, I suppose it depends to an extent on the length of the FA excerpt. But I don't see a reason a priori why the ongoing list shouldn't have 16 (or 26) items. Is there some previous discussion about either the list length, or the comparative lengths of the FA and the ITN modules? Is there some attempt to keep them roughly the same vertical height on devices that support two columns, either formally, or by conventional practice? Or are they entirely independent, as far as length is concerned? Mathglot (talk) 10:10, 24 June 2026 (UTC)[reply]

  The goal is "balance", by which it is meant that the length of the TFA+DKY column should be approximately equal to the length of the ITN+On this day column. As I look at it now, the right (ITN+OTD) column is about two lines shorter than the left.

  Looking at the most recent 10 archived snapshots of the main page (i.e. 19 June to 23 June 2nd version): 19, 19b, 20, 20b, 21 and 21b were all balanced, in 22 and 22b the left column was about 2 lines longer and 23 and 23b the right column was about 2 lines longer. Thryduulf (talk) 10:42, 24 June 2026 (UTC)[reply]

  It's the idea of micromanaging such entries to "balance" the two-column view that is ridiculous. The majority of our readers use the mobile view which only has one column and so it's not an issue at all for them. And even the readers that use the desktop view won't care that much about a bit of white space. This also depends on other factors like the monitor size, viewing preferences, browser settings and so forth and so it's impossible to make it exquisite for everyone.

  My view is that Ongoing should be limited because of diminishing returns and less is more. There's always plenty ongoing in the world and we should focus on the items that are dominating the news, not trying to cover everything or promote particular protests.

  Andrew🐉(talk) 12:40, 24 June 2026 (UTC)[reply]

  @Mathglot: The most ridiculous thing (if any) is that we have only three blurbs documenting news stories in a section called 'In the news', and the reason for that is not their length, which sometimes happens to be, but the excessive room occupied by the ongoing and RD sections. Moreover, WP:ITNBLURB begins with Most In The News postings come in the form of blurbs., but the problem is that this is no longer the case. Therefore, either we change the ITN-related policies so that we no longer put weight on the blurbs or refrain from defending the content posted to ongoing because it's still significant. The room for ITN is limited, so it's a perfect trade-off between blurbs, ongoing items and RDs. --Kiril Simeonovski (talk) 12:58, 24 June 2026 (UTC)[reply]

  Only one of those blurbs is fresh news from this week; the other two are 10 days old and no longer in the news. Space for more blurbs is not needed until ITN figures out how to increase the rate at which it posts them. Andrew🐉(talk) 14:32, 24 June 2026 (UTC)[reply]

It only shows that we fail to serve ITN's purpose. --Kiril Simeonovski (talk) 17:41, 24 June 2026 (UTC)[reply]

• Pageviews By coincidence, 10 articles is the limit for the pageviews tool. To understand how these 10 topics are playing with our readership, please see their pageviews for this year. Only two of them have been getting the sort of massive views that indicate that there is a high level of general coverage and interest. They are 2026 Iran war and 2026 FIFA World Cup. These two routinely get daily pageviews of 100,000+ whereas all the rest rarely pass 10K. Those other topics don't stand out against the general background of ongoing issues which are often in the news such as climate change, artificial intelligence and other armed conflicts. Andrew🐉(talk) 11:38, 24 June 2026 (UTC)[reply]

  It should be noted that your view that pageviews are relevant to what ITN should and should not feature has been rejected on every single one of the many occasions you have brought it up. Thryduulf (talk) 12:52, 24 June 2026 (UTC)[reply]

  As GreatCaesarsGhost observed, everything is rejected at ITN. Andrew🐉(talk) 15:08, 24 June 2026 (UTC)[reply]

  You're free to use page views as your personal metric, as long as you understand you're largely wasting your effort. 331dot (talk) 19:27, 24 June 2026 (UTC)[reply]

  I didn't invent page views -- they have long been a standard, well-supported metric so DYK, for example, uses them to measure the effectiveness of its blurbs on the main page. The top read articles are headlined each day by the Wikipedia app which I browse every morning. They are given top billing and respect.

  But, for ITN, the app only shows new blurbs when they appear and all of ITN's repetitive clutter like Ongoing are ignored altogether. The app has been designed by WMF professionals to have a clean, fresh, engaging style. They reject ITN's hidebound format and so it's that which is wasted effort.

  Andrew🐉(talk) 06:53, 25 June 2026 (UTC)[reply]

• For some reason, ITN simply cannot police itself. We suffer from some kind of analysis paralysis where every proposed change, however simple or obvious, immediately devolves into 10 tangential debates and everyone forgets to weigh in on the actual matter. BilledMammal is correct to think a proposal as ITN will go nowhere because they always do. GreatCaesarsGhost 13:23, 24 June 2026 (UTC)[reply]
  • I don't disagree that ITN has enormous problems (to the point where I've mostly disengaged from it!). Despite that, we have processes to protect volunteer time from extended unnecessary RfC participation. It's one thing to move intractable discussions to a wider venue, and a very different thing to parachute into a previously undiscussed issue (AFAIK) to drag likely dozens of editors into RfC back-and-forths. Ed ^{[talk] [OMT]} 14:36, 24 June 2026 (UTC)[reply]

  Sounds like the remedy might be to shut it down. Katzrockso (talk) 21:17, 24 June 2026 (UTC)[reply]

  Agreed, it's so dysfunctional, needs to go back to drawing board Kowal2701 (talk, contribs) 16:30, 27 June 2026 (UTC)[reply]

  We had this discussion almost exactly a year ago: Wikipedia:Village pump (miscellaneous)/Archive 82#Follow up discussion on ITN, and before that: Wikipedia:Requests for comment/In the news criteria amendments. That's enough "RFCBEFORE" for an "abolishing"/shutting down ITN RFC, so you can start one if you'd like. Some1 (talk) 16:48, 27 June 2026 (UTC)[reply]

  Tbh I've got too much on my plate atm, idk whether anyone else fancies it? Kowal2701 (talk, contribs) 17:32, 27 June 2026 (UTC)[reply]

  If anyone does, User:Levivich/ITN has mockups of potential replacements (what the main page could look like without ITN) from that old RFC. Anyone should feel free to take those pages (literally, move them) if they're helpful. Levivich (talk) 17:42, 27 June 2026 (UTC)[reply]

• I want to imagine WP:ITN came from WikiNews back in the day. WikiNews was discontinued a few months ago. – The Grid (talk) 14:41, 24 June 2026 (UTC)[reply]
  • WP:ITN says "ITN originated in the aftermath of the September 11 attacks, when entries were created and put on the Main Page within minutes of the attacks." Ed ^{[talk] [OMT]} 15:06, 24 June 2026 (UTC)[reply]
    • And Wikinews itself did not start until 2004. --Metropolitan90 (talk) 13:45, 25 June 2026 (UTC)[reply]

I think we can all agree that Talk header is a good template. Clear, concise, simple, is an easy way to view old talk page archives and has a call to action for new editors + a list of basic editing/discussing on Wikipedia principles. This template is already used in over eight-hundred-thousand pages (around 1% of all Wikipedia pages) and most big, important articles generally have one of these in their talk page.

Most new editors (I have no source for this, but it just feels right) are probably going to either start editing without reading anything, check the talk page for additional information and context or click the blue "anyone can edit" link on the main page. If a new editor picks the second path, the very first thing they will see is the call to action "New to Wikipedia? Welcome! Learn to edit; get help." and some good principles for new Wikipedians to know, like AGF and avoiding personal attacks + being polite. It also has a link to dont bite for experienced editors as a reminder and a list of places to search out sources with, which can help pretty much everyone. Sure, this would take some effort, but I feel it would in the long run be a good change to Wikipedia.

(Also, side note, but this would help polish and standardize Wikipedia. I mainly came up with this idea because I find it silly that things like this are not standard on the site, despite the fact they have clear benefits and no clear drawbacks)

In this case, "why not?" is a much better argument then "why?".

• 1. Automatically add to the top of every newly created Wikipedia mainspace article talk page the {{Talk header}} template.
• 2. Have a temporary bot quickly go through every mainspace talk page and add the tag; if it is already there, skip.
• 3. Create some mechanism to automatically re-add the template upon it's removal from an affected talk page; most likely a bot. Exceptions will be handled on a case-by-case basis that would require some kind of admin approval, most likely finding consensus in a talk page discussion and then alerting a random admin for approval.

I have nothing else to write, this is the full proposal. Thank you for reading. Ilov3gam3z (talk) 19:46, 25 June 2026 (UTC)[reply]

Comment: Does this need to happen for every page? I can see its use for most pages, but I don't see the need for pages with less than 100 views in 60 days to be tagged with the template because the people that usually edit them are already experienced editors with an understanding of Wikipedia's best practices.

Aside from the above comment, I support this proposal. Walteronthehill (talk) 20:43, 25 June 2026 (UTC)[reply]

True, but I feel a good deal of new editors join this way: search for random niche topic, find problem with article and fix. This is how I started, at least. Also, this would require more complexity from a bot designing stand point. Ilov3gam3z (talk) 20:58, 25 June 2026 (UTC)[reply]

I'd oppose this in the strongest possible terms as it'd contribute to banner blindness; also, if this had to be implemented everywhere, it'd be much better done as a MediaWiki feature rather than an enforcement bot. See a similar discussion from 2012 that I started. Also, I'm about to add a pointer to this discussion to Template talk:Talk header, and have simplified the heading of this discussion for easier linking. Graham87 (talk) 06:16, 26 June 2026 (UTC)[reply]

I don't know much of the 'technical' side of Wikipedia, so if a MediaWiki feature would be better: I'm not opposed. On banner blindness, I would like to hear your opinion on only making this apply to articles that have had a talk page discussion at some point or an archive, I thought of this aswell but I did not include it into the proposal. Ilov3gam3z (talk) 11:29, 26 June 2026 (UTC)[reply]

That'd be highly unwieldy to implement, and plenty of talk page sections are created automatically (e.g. by the WikiEducation Dashboard, bot notices, etc.). Regarding making it automatic when an archive exists: I don't think that would really fit the bill either, because some users create archives for really small amounts of discussion (or just for bot notices). Graham87 (talk) 15:26, 26 June 2026 (UTC)[reply]

No !vote. Although I am actually a big fan of this template and have also contributed to it, I am nevertheless very aware that there are a great many editors who are not at all fans—just the opposite, in fact—and may be ready to run you out of town with pitchforks and torches. So, be ready... Mathglot (talk) 08:04, 26 June 2026 (UTC)[reply]

This is a proposal I considered including in my archiving reform plans. {{talk header}} handles displaying archive links as well and having it there already makes the process of setting up archiving one step shorter. It isn't a big deal but it's yet another argument for including this template on all mainspace talkpages. My main concern with this proposal is competing for attention with the start a new discussion text (included below) which appear on small talk pages. This text seems likely to br bettter at making proplr voice their concerns than the talk header template and if someone is only going to read one thing I think I prefer them reading that.

Trialpears (talk) 10:12, 26 June 2026 (UTC)[reply]

Another factor on the "only going to read one thing" angle is that we're getting more and more users assuming that the "Talk" button on a Wikipedia article is taking them to an AI chatbot. The "start a discussion" message seems like it would do a better job of catching those users. Belbury (talk) 10:43, 26 June 2026 (UTC)[reply]

I have wanted to suggest renaming the "Talk" namespace or at least button for a while now, for this very reason, but given the reaction to the Move => Rename proposal I don't expect that to go anywhere Gnomingstuff (talk) 13:27, 26 June 2026 (UTC)[reply]

The link was called "discussion" until 2012. Graham87 (talk) 15:26, 26 June 2026 (UTC)[reply]

The talk page comment box that pops up doesn't help either, bizarrely asking the user to enter a "Description" and giving them no other context for what's happening. I've tried to get that changed, but even with some support, WMF were cautious about an interface change that could have other impacts, and it didn't go anywhere. Belbury (talk) 10:54, 27 June 2026 (UTC)[reply]

Maybe the proposal could be modified so that this will only apply to talk pages already with an archive or a topic? I do realize in hindsight having two banners with slightly different messages fight against eachother for the user's attention isn't the best idea. Ilov3gam3z (talk) 11:31, 26 June 2026 (UTC)[reply]

I oppose this proposal. Generally, we need to take steps to decrease the amount of banner bloat on our talk pages, and this would be a massive step in the wrong direction. Best, HouseBlaster (talk • he/they) 21:04, 26 June 2026 (UTC)[reply]

Any registered editor who dislikes these templates as much as I do should see line 11 in User:WhatamIdoing/common.css, which makes them invisible. I can't remember which VPT hero wrote the line for me, but I've been very happy with the result. WhatamIdoing (talk) 03:39, 1 July 2026 (UTC)[reply]

This is covered in the documentation, reasonably enough at {{Talk header#Hiding the template}}. Your css version hides a portion of the template, not the whole thing. Your hero for partial hiding is Jacobolus, here. Mathglot (talk) 19:57, 1 July 2026 (UTC)[reply]

No, talk header is usually unnecessary. PARAKANYAA (talk) 01:49, 27 June 2026 (UTC)[reply]

• Support, no real reason not to and it makes counter-vandalism easier when you don't start with a blank page. Gnomingstuff (talk) 19:01, 28 June 2026 (UTC)[reply]

  How does that help? WhatamIdoing (talk) 03:38, 1 July 2026 (UTC)[reply]

About the proposed mechanism: That's the wrong way to go about it. MediaWiki:Talkpageheader exists for the purpose of automatically forcing the display of a message on each page. I think we shouldn't do this, but if we're going to do this, we should use the sensible, purpose-built method for doing this. WhatamIdoing (talk) 03:42, 1 July 2026 (UTC)[reply]

• Oppose. The {{talk header}} template is emblematic of a kind of inertia—for years, people have pushed at it in various directions (improve! delete! reformat!) without much success. It's rather flawed as a UI element, but also functional enough and complex enough that there isn't much traction to change it without breaking things and offending expectations. The present opportunity for someone to stake out a little corner of the talk namespace and try to do better is a small price to pay. We shouldn't always instiutionalize things in a way that locks them in—look at how Commons got swallowed by licence template chaos with UI internationalization layered on top, and lacks the critical mass to address the problem systemically. TheFeds 19:34, 1 July 2026 (UTC)[reply]

There are many long term editors, administrators who are not editing for long time. Yet there are some automated bots which post various news, articles to improve, wikiproject pages on their talk pages. And they also have a bot which archives those messages after few days.

I think those who are inactive completely for more than four years, such automated messages must be stopped (if possible the archive bots also)

Those who worked with them, their messages of appreciation, farewell type messages gets lost due to mass bot messages and archiving of those messages.

Some editors post retired template while some do not and they quit completely and never come back. So these bot messages they receive weekly or monthly is not required.

What is required is their friends saying "Thank you for your contribution to the project" which should not be archived by the talk page archive bot ~2026-37101-40 (talk) 08:23, 28 June 2026 (UTC)[reply]

What do you see as the benefit(s) of doing this? The cost of posting and storing those notices is quite small. With so many other things that affect the reader and editor experiences needing attention, why should editors and programmers spend time fixing this? Donald Albury 14:38, 28 June 2026 (UTC)[reply]

Not compulsory for every inactive editors as that would be impossible huge task, but it must be allowed for their friends to do this, if they want. It should exist as an option. ~2026-37290-36 (talk) 04:46, 29 June 2026 (UTC)[reply]

I am uncomfortable with the idea that any random editor would be able to unenroll another editor from a list service. Donald Albury 13:09, 29 June 2026 (UTC)[reply]

Agreed. If they are gone, they wont worry about their talk page being littered. User:Bluethricecreamman (Talk·Contribs) 14:08, 29 June 2026 (UTC)[reply]

I think that some subscription-type messages (e.g., Wikipedia:Wikipedia Signpost) should not deliver to inactive accounts.

However, other messages (e.g., notifications about deletions) should be delivered. I have one WP:VANISHED editor's user page on my watchlist just so I can catch inappropriate deletion attempts. WhatamIdoing (talk) 03:44, 1 July 2026 (UTC)[reply]

I propose adding CESAR person ID (P2340) (for actors/theatre professionals) and CESAR title ID (P13726) (for French plays) to the standard Authority Control templates/modules across Wikimedia projects. Integrating these properties directly into the ⁠Authority Control module eliminates the need for editors to manually add external links to the relevant Wikipedia articles. Relying on structured Wikidata properties within Authority Control guarantees stable, dynamically updated, and centrally managed links. This approach far outperforms manual curation, which is particularly critical following the database's recent extensive platform update. William C. Minor (talk) William C. Minor (talk) 20:37, 28 June 2026 (UTC)[reply]

Template talk:Authority control is probably the best place to request this. Additionally, if you have any conflict of interest with that project, you are invited to clarify it when making your request (feel free to ignore that last part if you're not connected to the project!) Chaotic Enby (in solidarity · talk · contribs) 21:00, 28 June 2026 (UTC)[reply]

This adorable mascot disappeared a couple of months back. I call for this removal to be reversed. I feel like the inclusion of the said mascot should be made permanent. I also request the reinstatement of the dark mode button in its former location. Pablothepenguin (talk) 17:54, 1 July 2026 (UTC)[reply]

He must come back. Walteronthehill (talk) 18:04, 1 July 2026 (UTC)[reply]

Baby Globe is genuinely the best mascot we've seen, and I would love to see it back! Chaotic Enby (in solidarity · talk · contribs) 18:58, 1 July 2026 (UTC)[reply]