Wikipedia:Village pump (all)

This is the Village pump (all) page which lists all topics for easy viewing. Go to the village pump to view a list of the Village Pump divisions, or click the edit link above the section you'd like to comment in. To view a list of all recent revisions to this page, click the history link above and follow the on-screen directions.

(to see recent changes on Village pump subpages)

Village pumps

Policy

• New topic
• Search

Discuss existing and proposed policies

Technical

• New topic
• Search

Discuss technical issues about Wikipedia

Proposals

• New topic
• Search

Discuss new proposals that are not policy-related

Idea lab

• New topic
• Search

Incubate new ideas before formally proposing them

WMF

• New topic
• Search

Discuss matters involving the Wikimedia Foundation

Miscellaneous

• New topic
• Search

Post messages that do not fit into any other category

Other help and discussion locations

I want...	Then go to...
...help using or editing Wikipedia	Teahouse (for newer users) or Help desk (for experienced users)
...to find my way around Wikipedia	Department directory
...specific facts (e.g. Who was the first pope?)	Reference desk
...constructive criticism from others for a specific article	Peer review
...help resolving a specific article edit dispute	Requests for comment
...to comment on a specific article	Article's talk page
...to view and discuss other Wikimedia projects	Wikimedia Meta-Wiki
...to learn about citing Wikipedia in a bibliography	Citing Wikipedia
...to report sites that copy Wikipedia content	Mirrors and forks
...to ask questions or make comments	Questions

Discussions older than 7 days (date of last made comment) are moved to a sub page of each section (called (section name)/Archive).

Policy

Upgrade MOS:ALBUM to an official guideline

I floated this at Village pump (proposals) here awhile back, and there was wide support for doing this (some editors said they felt it unofficially already was a guideline). But, it was noted that the essay, Wikipedia:WikiProject Albums/Album article style advice, needed some clean up and to be fleshed out in places. After multiple discussions, including some disputes and RfCs, I think the essay is finally in a place where there is an updated consensus and enough detail that it can be an official MOS style guideline. This is a formal presentation of the updated and discussed essay to see if there is support for making it formally part of Wikipedia's Manual of Style.--3family6 (Talk to me|See what I have done) 12:35, 26 January 2026 (UTC)

• I do support this. Camilasdandelions (✉️) 17:03, 26 January 2026 (UTC)
• Note the MOS:ALBUM shortcut has been nominated for deletion at Wikipedia:Redirects for discussion/Log/2026 January 21#MOS:ALBUM. I have linked this discussion there and suggested it should be procedurally closed pending the outcome of this discussion, but I don't know how that will be received (I'm not neutral with regards the redirect, but have no strong opinions regarding the essay/guideline). Thryduulf (talk) 17:18, 26 January 2026 (UTC)

  Link to RfD corrected. Thryduulf (talk) 21:53, 26 January 2026 (UTC)

  The WP:RFD discussion was procedurally closed pending the outcome of this RFC. —Myceteae‍🍄‍🟫 (talk) 21:39, 20 February 2026 (UTC)

• Oppose not really strong enough to carry the same weight as guidelines, and it lazily tries to give credits a free pass on being unsourced. SNUGGUMS (talk / edits) 17:58, 26 January 2026 (UTC)

  Where does it give a pass to credits being unsourced?--3family6 (Talk to me|See what I have done) 21:49, 26 January 2026 (UTC)

  Look under "Track listing", where someone added "This is generally assumed and does not need explicit citation in most cases". Even when albums are already released, we frankly shouldn't be so quick to presume that an unsourced track list lines up with actual credits. Adding liner notes or an iTunes/Amazon link would be better than nothing. You might be surprised how often others have dubiously tried to use the essay as an excuse to ignore the non-negotiable requirements of WP:Verifiability and WP:No original research. SNUGGUMS (talk / edits) 23:30, 26 January 2026 (UTC)

  WP:V doesn't require citations, and the essay reflects consensus. Are there cases of people inserting false information? I'm not opposed to modifying that text a bit, I just fail to see how it doesn't reflect consensus.--3family6 (Talk to me|See what I have done) 00:03, 27 January 2026 (UTC)

  On the contrary, WP:V opens its second paragraph with "Each fact or claim in an article must be verifiable." That doesn't give essays the right to make selective exceptions. I also haven't seen any consensus suggesting citations wouldn't be needed for facts. As for fabrications, I wouldn't be surprised if there have been, though cannot think of specific instances at the moment unless one counts vandalism. SNUGGUMS (talk / edits) 00:23, 27 January 2026 (UTC)

  The spirit of WP:V is that anybody should be able to check that the claimed facts are true. Picking up a record sleeve or CD inlay should be OK for that. That said, there are occasional discrepancies between the reality and what's actually written. Two examples: (i) Masque where the actual playing order matches a sticker on the sleeve but not the record labels; and (ii) Platinum, where the track "Sally", present on original copies, was replaced by "Into Wonderland" but without the sleeve being amended. --Redrose64 🌹 (talk) 14:07, 27 January 2026 (UTC)

  Even the most reliable of reliable sources only attains 99.973% reliability. Phil Bridger (talk) 14:32, 27 January 2026 (UTC)

  As long as articles make it clear that credit listings are taken from sleeves, inlays, or anything similar, I don't see an issue with using print sources for credits. If there are discrepancies, then it shouldn't be too difficult to find additional sources backing them up, perhaps even with some commenting on omissions. My qualm is enabling lazy-at-best mentalities of "just trust that I got these accurate" or "I don't need anything to back up my insertions of credits/personnel" when adding credits without any citation at all, even print ones. One or more refs (whether online or printed) helps show the listings aren't being pulled out of nowhere. SNUGGUMS (talk / edits) 17:46, 27 January 2026 (UTC)

  "Verifiable" is not the exact same thing as "has a citation". If something does seem questionable and is challenged, then it should have a citation. Regardless of what an essay or an MOS guideline says.--3family6 (Talk to me|See what I have done) 19:57, 27 January 2026 (UTC)

  "just trust that I got these accurate" or "I don't need anything to back up my insertions of credits/personnel" - is anyone doing this? Refusing to provide a source when asked?--3family6 (Talk to me|See what I have done) 19:59, 27 January 2026 (UTC)

  For a few samples showcasing the latter attitude by trying to use the essay as a cheap cop-out for not sourcing credits at all, have a look at these diffs. The choice to deliberately leave such sections with no sources is careless. SNUGGUMS (talk / edits) 23:03, 27 January 2026 (UTC)

  Thank you for those. Yes, those are WP:V violations and misusing the essay as well. I'm fine with changing the wording of the essay, if there's consensus for it.--3family6 (Talk to me|See what I have done) 13:38, 28 January 2026 (UTC)

  You're welcome, and for starters, I would recommend fully scrapping the sentence quoted above within the "Track listing" section even if this essay never becomes a guideline or a policy. We also shouldn't endorse any similar phrasing that people would attempt to use as an excuse for not implementing citations. It baffles me how anybody thought an essay could plausibly be used to overrule policies/guidelines. SNUGGUMS (talk / edits) 19:11, 28 January 2026 (UTC)

  As mentioned elsewhere, it is not overruling policy. Read WP:V. Content needs to be cited if the content is likely to be challenged, is BLP relevant or is a quotation. If there is consensus that primary sourcing (i.e. the album itself) is sufficient for verifying the track listings and that this is generally not likely to be challenged then no citations are required. This is the current consensus for plot summaries (which are sourced to the primary work and not cited because it's the subject of the article). You can make an argument that that citations should always be provided either because it's regularly wrong and therefore likely to be challenged but providing a citation isn't mandatory in all cases. Scribolt (talk) 10:26, 29 January 2026 (UTC)

  Personnell sections should have a citation if any of the people are living, then.--3family6 (Talk to me|See what I have done) 15:45, 29 January 2026 (UTC)

  That would be up for discussion, but wouldn't be a requirement imo. An article about an album isn't a BLP, and material about who did what during the production isn't necessarily contentious or controversial. There's certainly a higher possibility of getting the content wrong here compared to simply checking the track listing, so there might be added value in recommending in a guideline to make the extra effort and cite the content as a default, but if there isn't consensus to do this I wouldn't regard this it as being against any higher level policy. Scribolt (talk) 08:08, 2 February 2026 (UTC)

• Weak support I like the idea of this proposal and the page seems fleshed out enough to be a part of the MOS. 3family6, do you have a link to the discussion at VPR? TIA mdm.bla 23:01, 26 January 2026 (UTC)

  It actually was here at the policy page, I misremembered. That then was moved to WT:ALBUM. Here is the discussion. If you want me to link to the RfCs, I can do that.--3family6 (Talk to me|See what I have done) 23:59, 26 January 2026 (UTC)

  Thanks. The concerns brought up in that discussion seem to have been taken care of, and I don't share Snuggums' concerns w.r.t. WP:V issues. Increasing to a regular level of support. mdm.bla 04:52, 28 January 2026 (UTC)

• Support It may need further improvement, but making it formally a part of the MOS rather than a wikiproject sub-page will make that more rather less likely. Scribolt (talk) 14:33, 27 January 2026 (UTC)
• Support – I don't think its necessary to have to cite the release for information from the release, as anyone with access to the media can verify it themselves (à la MOS:PLOTSOURCE). That said, I wouldn't oppose making {{Cite AV media notes}} (or w/e source) a requirement for WP:PERSONNEL, as that's often not as easily as accessible with digital releases, but I would argue it's unnecessary for the track listings (as anyone with access to both the physical release and streaming services can easily verify for themselves). Nil🥝 04:18, 28 January 2026 (UTC)
• Comment – I'd like to hear more about the intended benefit of promoting WP:ALBUMSTYLE to a guideline. What problem would that solve? What isn't the page able to do as a WikiProject advice page that it could do as a guideline? If it were promoted to a guideline, where would it be moved to? Wikipedia:Manual of Style/Albums? There are already a few MOS subpages dealing with music, most of which, in my opinion, are better fits for explanatory essays or WikiProject advice pages. As a procedural note, there area few steps outlined at WP:PROPOSAL that should be followed for this discussion, including adding a formal RFC tag and posting a notice at Wikipedia talk:Manual of Style.--Trystan (talk) 13:50, 28 January 2026 (UTC)

  I've WP:BOLDly added an RFC tag and posted a message at WT:MOS. I would support the proposed page title that you've included, per the current shortcuts for the page MOS:ALBUM and MOS:ALBUMS. mdm.bla 16:31, 28 January 2026 (UTC)

  Thank you for that.--3family6 (Talk to me|See what I have done) 01:33, 29 January 2026 (UTC)

  isn't the page able to do as a WikiProject advice page that it could do as a guideline? In practice, I'm not sure, as it's de facto treated as an MOS already (for example, the short name link WP:MOS). This would formalize what is effectively the status quo. It would give more weight, though of course it's still a guideline to which IAR applies.--3family6 (Talk to me|See what I have done) 01:35, 29 January 2026 (UTC)

• Oppose per SNUGGUMS. Clearly the advice not to source credits doesn't fit with wider policies and guidelines. And more broadly, per WP:CREEP, having too many guidelines of this nature which are crafted by niche WikiProjects and may not be widely watched, is not beneficial. The overall MOS has almost all the guidance you need, and any further details should be worked out by consensus at individual articles, not by a wide-ranging set of arbitrary guidelines that aren't being widely vetted.  — Amakuru (talk) 14:58, 28 January 2026 (UTC)

  It seems that SNUGGUMS' understanding of policies and guidelines on this specific point is in the minority. As to WP:CREEP, that's fair, but should we then rescind/downgrade other MOS?--3family6 (Talk to me|See what I have done) 00:02, 4 February 2026 (UTC)

• Comment. Generally, the MOS applies to all topics. Are there any other examples of subject-specific guides within MOS, or would this be a scope expansion? pburka (talk) 16:54, 28 January 2026 (UTC)

  Template:Manual of Style lists a number of subject-specific MOS subpages by topic area; this page is especially comparable to MOS:TV and MOS:VG. mdm.bla 17:52, 28 January 2026 (UTC)

  Amakuru, see this--3family6 (Talk to me|See what I have done) 00:03, 4 February 2026 (UTC)

  My opinion would be that those things shouldn't be designated as guidelines either. Without assuming any bad faith - editors are of course writing down that they think is best practice - but these often reflect a WP:LOCALCONSENSUS, being usually formulated by small groups of editors rather than the community a a whole, and the things asked for may not be required by the wider MOS or necessarily appropriate for every article in the space. An example was a road article I wrote where I was told it couldn't become an FA due to not complying with MOS:RJL, something which is only really sensible for certain types of road. Having general guidance in essay form is fine, but it is much better for such questions to be handled by consensus and applying the sitewide MOS than by a one-size-fits-all guidelines written without a lot of the community being involved. Let's not make this situation worse by adding another one into the mix. Cheers  — Amakuru (talk) 11:19, 4 February 2026 (UTC)

  There's a reason I'm proposing this here, as opposed to just the Albums WikiProject, and it's advertised at the main MOS page. This shouldn't be simply local consensus. Regarding your example, I personally would've opened an RfC about that particular guideline.--3family6 (Talk to me|See what I have done) 13:49, 4 February 2026 (UTC)

• Support. This discussion has stagnated a little, but as a participant in the original RfD I am now inclined towards promoting this to the MOS having seen how valuable it is for its area of focus. — An anonymous username, not my real name 22:45, 11 February 2026 (UTC)
• Oppose. I appreciate the effort, and I weighed in a couple of times during previous discussions, but there are still too many issues for me to support. The project, unlike any other WP one, continues to fetishize primary source information, with editors often trying to reproduce every piece of album packaging credit, rather than worrying about what secondary sources have to say. The alternate track listings are still out of control, as are long personnel lists of non-notable musicians, producers, songwriters, etc. The vast majority of the project uses one track listing style, but a vocal (extremely tiny) minority of editors want to keep choices, which leads to needless edit warring. Genres are still an issue---if "hair metal" or "classic rock" showed up, despite being the subjects of thousands of reliable articles, books, and magazines, some editors may start having embolisms. Cheers. Caro7200 (talk) 12:20, 19 February 2026 (UTC)

Caro7200 I'm trying to understand your concern here. Is your concern that there isn't consensus on some issues because the ongoing disputes demonstrate it so?--3family6 (Talk to me|See what I have done) 10:30, 27 February 2026 (UTC)

Yeah, in part. One purpose of a formal standard is to avoid shifting so much to the "take it to the talk page" route. We should be more precise and clear with our language, rather than, for example, something like "Whether or not to include bonus tracks and alternative track listings should be evaluated on a case-by-case basis." I do agree with you that credits found on packaging don't require citations; a New York Times reporter isn't contacting Parkwood/Columbia to verify the information found on the copy of Cowboy Carter that they're holding in their hand. Additionally, we could use tougher language in regard to chronology and exact release dates, which continue to be hugely unsourced; this is too often wrongly regarded as a Wikipedia:You don't need to cite that the sky is blue thing. And our consistent enforcement is part of adopting a formal standard. Too many IP and "new" editors are switching out track listing styles to our most popular one, for example, with the reasoning that the others are "outdated". Caro7200 (talk) 15:26, 1 March 2026 (UTC)

Wouldn't these issues be all the more reason to have a more formal standard? The track listing issue finally reached a consensus, and the personnel issue I believe reached one last year. Genres have always been an issue, despite there being long-standing consensus, because some editors ignore consensus.--3family6 (Talk to me|See what I have done) 13:45, 27 February 2026 (UTC)

• Oppose, largely in agreement with Caro7200 and SNUGGUMS. I'm also sympathetic to Amakuru's WP:CREEP and related concerns. I'm on the fence as to whether we should have a dedicated albums MOS at all. At a minimum, the concerns regarding citations and genres need to be addressed. If the current wording reflects the consensus of the WikiProject then we're at an impasse, but from the discussion here it appears some editors are open to further rewording. It remains unclear what the benefit is of promoting this—What problem will this solve? What's not working now that would be improved? It sounds like some (many?) editors active in this space treat this as more or less a guideline currently. That there are ongoing disputes and edit wars indicates either a lack of consensus or a minority of editors ignoring consensus. —Myceteae‍🍄‍🟫 (talk) 22:14, 20 February 2026 (UTC)

  On the track listing issue, the RFC for that finally closed recently so there is actually a community consensus that can be pointed to.--3family6 (Talk to me|See what I have done) 10:34, 27 February 2026 (UTC)

  Generally, apart from some issues that have been hammered out over the past year, it's editors ignoring consensus.--3family6 (Talk to me|See what I have done) 13:43, 27 February 2026 (UTC)

• Support. Having read this discussion, I'm not of the opinion that having this as a formal guideline would be of benefit. Thryduulf (talk) 14:19, 27 February 2026 (UTC)

  @Thryduulf: Unless I'm reading this wrong (entirely possible), your reasoning seems to contradict your !vote. Did you intend to Oppose, or did you intend to say "I'm of the opinion"? DrOrinScrivello (talk) 14:49, 27 February 2026 (UTC)

  Thanks for the headsup, the "not" is erroneous (probably left over when I was going to word my comment differently). Thryduulf (talk) 18:34, 27 February 2026 (UTC)

• Oppose. Just caught wind of this after doing an album page edit and referring to guidelines which apparently no longer exist. I'm mostly with Caro7200 and Snuggums. IMHO there is still too much wiggle room in certain areas, particularly WP:ALTTRACKLISTING, which is now so vague that it is basically meaningless.—The Keymaster (talk) 12:25, 2 March 2026 (UTC)

Introduce maximum page size and mandatory archiving for pages intended for user communication (accessibility)

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

(non-admin closure) WP:BOLDly closing this RFC early per snowball clause

Polling is not a substitute for discussion, but examining the !votes is a good place to start divining consensus.Currently, there are 38 bullet points in the survey, of which 27 are !votes opposing any one of the seven proposals in this RFC. There are an additional 9 bullet points (some of which are unbulleted) in the proposal by Sapphaline, of which eight are in total opposition to either their proposal or the original proposal. Of the 11 remaining bullet points, two are discounted for not being !votes. The 9 remaining bullet points are in various levels of support for the original proposal, from supporting all of the points (2), to supporting them all except for one or two (3), or only supporting a couple (4).

Some opposes believe that there may be a discussion worth having on the topic of archiving talk pages, but many do not believe a one-sized fits all solution will work. On the other hand, supporters of the proposal have accessibility concerns about large talk pages. Editors on both sides believe that the structure of this RFC has prevented any productive outcome for this discussion. I would encourage continued discussion on this topic, as the accessibility concerns are a problem worth solving, but the issues will not be solved in this discussion. There is consensus against this proposal, but not against the existence of an underlying issue. Mdm.Bla (talk) 15:46, 3 February 2026 (UTC)

I have opened a discussion at Wikipedia:Village pump (idea lab)#Automated talk-page archiving, page splitting, and accessibility to continue talking about the accessibility issues of large talk pages. Please do not relitigate this RFC there. Mdm.Bla (talk) 17:06, 3 February 2026 (UTC)

---

The following RfC concerns a set of proposals be implemented for all pages intended for user communications (e.g. (X) talk: pages and noticeboards in the Wikipedia: namespace) A short summary of the complete set of changes:

1. Establish a minimum number of 10 threads on pages, except on user talk pages
2. Establish a maximum size of pages (about 200 KB) and page archives (about 150 KB).
3. Mandate some sort of automatic archiving mechanism for all pages, except for user talk pages; that archiving mechanism will by default do all the enforcement of the maximum size rules on non-user talk pages.
4. Require pages that will likely routinely fall afoul of the maximum size rule to introduce a short archiving interval
5. Limit discretion of users to manage their assigned talk page to comply with maximum size guidelines, but leave the choice of the preferred way to comply with the guideline to the users; no other part of user discretion is disturbed
6. Introduce an enforcement mechanism for users failing to abide by the accessibility guideline (max size)
7. Force changes to the codes of archive bots in such a way that any input value above the maximum permitted/below the minimum permitted thresholds will default to the threshold values.

Full changes, along with the reasoning, is presented in the collapsed table.

Do you support these changes as presented in the table below? If not, which specific parts of the changes do you not like?

A very similar set of ideas was previously discussed at the idea lab section of the Village Pump, where I got some encouraging feedback. Szmenderowiecki (talk · contribs) 14:29, 29 January 2026 (UTC)

Changes (talk pages)

Collapsed for clarity

Policy/guideline	Before	After	Reason
WP:TALKSIZE	Large talk pages are difficult to read and load slowly over slow connections. As a rule of thumb, archive closed discussions when a talk page has numerous resolved or stale discussions – see Help:Archiving a talk page.	All pages intended for communication between users have to be reasonably accessible. Their size must not substantially impact device/browser performance while reading or editing.	The whole premise of the RfC.
		All pages intended for communication between users must have some sort of automated archiving deployed. This concerns all (X) Talk: pages, and noticeboards in Wikipedia: namespaces. There are two possibilities: A user can deploy an archiving bot A bot can generate pages for a given period that are assembled in a log (see example here). Discussions are started directly on these subpages. This is the procedure used at various venues to discuss potential page deletion. The period should be adjusted so that each individual subpage is unlikely to break the archive size guideline. Generally meant only for extremely busy pages. Do not archive pages manually, unless this is necessary because bot errors somehow prevent the pages from being archived. User talk: pages are exempt. Single discussions split into their own pages due to size considerations are exempt from internal archiving but have to be searchable through archives of the page they were split from.	We have well-tested archiving tools/subpage creation tools that automate the process. This wording will eliminate bickering over archiving preferences, which is pretty lame and a waste of editor resources. Set up an archive once and forget about it. There are pages that remove discussions instead of deleting them, e.g. WP:ERRORS, which could benefit from the log-based scheme. Pages that remove discussions are already in violation of the rule that discussions should be archived, not blanked; this rule will make sure that the transition must take place.
		All pages intended for user communication should not exceed 1200 KB HTML weight. Archives of these pages should not exceed 900 KB HTML weight. Existing archives are grandfathered. This rule should not be interpreted as discouraging new or existing discussions in any way.	A recent RfC about talk page guidelines scrapped the 75 KB wikitext size limit on non-user talk pages as it had no consensus and practically was not followed anyway. I do not read the discussion as finding consensus against any sort of talk page size limit and the closer specifically encouraged a user talk-dedicated discussion. I don't see the functional difference between the two, that's why this proposal concerns all such pages. The point is to make sure that pages are responsive upon reading and editing. HTML size is not a perfect proxy for measuring this but much better than wikitext. Page weight matters a lot, so some value needs to be set. A median desktop page weighs about 800-900 KB HTML+CSS+JS these days. We can't measure the impact of JavaScript directly on the CPU/browser, but there are Inspect tools integrated in the (desktop) browser. For example, ANI (2062 KB HTML as I write) has an OK value for Largest Contentful Paint (1.86 s) and good Interaction to Next Paint time (40 ms), but not very good values for Cumulative Layout Shift (0.1 s). When I try to edit it in source, however, the latter two values grow to pretty horrible 1,256 ms and 1.02 s; typing text sends INP value - which is basically lag - to an asinine 4,432 ms (syntax highlight on; Chromium 143). The page visibly struggles. Larger talk pages may freeze or crash browsers, or make them effectively uneditable, which is an absolutely unacceptable outcome. The point is to make sure that the value is set reasonably high to allow wide discretion to manage talk pages but not too high to make compliant pages struggle on devices that are not top-shelf. Compliant pages should give users at most mild inconvenience in reading and editing, given any reasonable device and Internet configuration. Any threshold value is arbitrary but the value appears to be a good compromise. (second and later paragraphs based off performance and the page weight chapters of the HTTP Archive Almanac. See the performance page for good reference values of Inspect parameters I mentioned) Lazy loading and render engine improvements depend on WMF/MediaWiki. While their performance improvements are welcome, there is absolutely no guarantee that they will do it, and there is no deadline for them. This proposal is something we as users can do right now. Some users claimed that we should not do it because other websites become heavier over time, which they do, so the value will become obsolete as old hardware is inevitably replaced with better hardware. For one thing, if other websites create pages that consume tons of resources, they are free to do so, but it doesn't mean we should do the same or force people with devices that have poorer performance to make them suffer through loading. For another, consensus can change and we can edit the value later. Almost 1000 user talk pages exceed 400 KB wikitext weight. There are a couple of pretty bad talk pages, too. See also WP:CHOKING and Wikipedia:Vandalism#Illegitimate_page_lengthening. Articles have guidance on size.
		Footnote: As a rough estimate, 1 KB of wikitext weight (the one you see in the page history) is about 5-6 KB HTML weight (source: my observations using PROSESIZE on a couple dozen pages). The more templates, formatting, and user JavaScript and CSS there is on the page, the more HTML weight there will be per 1 KB wikitext weight. Archiving bots assume that 1 KB of wikitext is 6 KB of HTML for the purpose of this guideline. Although the limit is in HTML size, not wikitext, this ratio will allow most discussion pages to stay well within the maximum allowed value. HTML size does not account for the weight of loaded images. If the page is image-heavy, consider lowering the maximum page size limit. To measure HTML weight of a given page, you can use tools such as WP:PROSESIZE. On desktop, there is also an option to open "View page source" and copy-paste the code into a text counter to see the number of bytes.
	None	The archive interval value must balance the need to keep the talk page within a reasonable length with giving adequate notice to all potential participants to engage in the discussion. Only finished discussions may be archived; if possible, the only discussions that go to archive should be clearly stale (=1 year since last comment). If in doubt, apply a longer archive interval. In particular, pages with very high traffic are allowed to exceed the limit to some degree if necessary to give adequate notice to potentially interested users, or to show a recent discussion of large impact. If the page intended for user communication is likely to routinely exceed the maximum size limit, and if the log system is not used, the archiving interval (=time since the last comment in the thread) of an archiving bot must be set at at most 10 days. This, or lower, value, should be only set for high-traffic pages.	The first part is pretty self-explanatory. The second part is designed to a) force high-traffic pages to adopt relatively aggressive archiving schedule and b) effectively exempt them from the requirement that the page be smaller than 1200 KB HTML. The only consideration for high-traffic pages is whether it's more desirable to keep the page small and friendly to edit/read or to keep threads for slightly longer to encourage more discussion. Generally more discussion is more desirable, but on pages like ANI, where threads are often closed in a matter of hours, this may actually be not necessary.
	Apart from the exception described in WP:TALK#User talk pages, discussions should be archived, not blanked.	Discussions on all pages, except for user talk pages, should be archived, not blanked. Any user may choose to blank most messages on their own talk pages, but archiving is recommended instead. There are messages that the user must not remove. If a user removes a message from the talk page, whether by themselves or assisted by automation, this will mean that the user has read and is aware of its contents. Insisting on keeping the message that the user may delete against the user's wishes is not appropriate.	As mentioned above, pages like WP:ERRORS violate this guideline by not keeping any archives.
WP:BLANKING	Policy does not prohibit users, whether registered or unregistered, from removing comments from their own talk pages, although archiving is preferred. If a user removes material from their talk page, it is normally taken to mean that the user has read and is aware of its contents; this is true whether the removal was manual or automatic. There is no need to keep them on display, and usually users should not be forced to do so. It is often best to simply let the matter rest if the issues stop.		Basically a slightly refactored restatement of these two rules, with emphasis on user autonomy on user talk pages.
WP:TALKSIZE	If a thread has been archived prematurely, such as when it is still relevant to current work or was not concluded, unarchive it by copying it back to the talk page from the archive, and deleting it from the archive.	Add this before the red passage: Archive bots must not archive threads on pages intended for user communication if: there are 10 threads or fewer on the main talk page the last comment in a given thread is 10 days old or younger, unless the archiving interval was set at a lower value	This is to address user complaints in the linked Talk page guideline thread above, as confirmed on VPI, that empty pages discourage discussion. I agree. Hence the first requirement. The second requirement is to prevent (potentially) active discussions from being archived. As mentioned above, manual archiving of talk pages is discouraged. But on the off-chance that the thread still is relevant even if archived by bot, the instruction is kept.
WP:USERSUBPAGE	While you do not "own" them, by custom you may manage [user space pages] as you wish, so long as you do so reasonably and within these guidelines.	While you do not "own" pages in User: namespace, by custom you may manage these pages as you wish. Your requests not to edit your User: namespace will be honoured. However, your style of userspace management must be within reason and not lead to breaking these guidelines.	This is to separate User: from User talk: namespaces. Nothing changes in the User: namespace, and generally editors will still have free rein in their user namespace.
WP:USERTALKSTOP	If an editor asks you not to edit their user pages, such requests should, within reason, be respected. However, editors should not make such requests lightly, especially concerning their talk pages, as doing so can impede the ordinary communication which is important for the improvement and smooth running of the project.
WP:OWNTALK	The length of user talk pages, and the need for archiving, is left up to each editor's own discretion.	A user can generally manage their User talk: namespace pages as they see fit, so long as they keep the management within the talk and user page guidelines, including those on maximum size limits.	All discussion pages have to be reasonably accessible, both for reading and for editing, under all reasonable configurations allowed by MediaWiki software. There is no legitimate reason for distinguishing non- User talk: discussion pages from those in this namespace. Users will still be able to manage User talk: pages as they like, but they will have to clear clutter from time to time. It doesn't matter how they do it so long as they do it.
	None	Any user or bot may notify you about your excessive user talk page size that violates the guidelines, and ask you to fix this issue. If you: refuse agree to do it but fail to bring the talk page within compliance within 10 days have a history of notifications that shows that you are unable to maintain compliance with the maximum size long-term an administrator may unilaterally impose an archive bot using the loosest limits necessary to maintain the minimum user talk page accessibility criteria long-term, or correct values to more aggressive archiving if the archive bot was deployed but the size of the talk page is still too large. For people who use archiving by periods of time rather than numbers, a period can be chosen that is likely to stay within these limits, but no longer than 365 days. The archive bot must not be removed without agreement from the administrator who imposed it. The administrator must notify the user of the intervention. Non-administrators may request this intervention at the incidents section of administrative noticeboard. Such requests must be granted if any of the above points apply.	This is the mechanism to enforce size restrictions on user talk pages if the clutter is not cleared. The mechanism respects user's autonomy to decide how to manage their talk page but steps in if it is clear that the user can't or doesn't want to comply. If a user doesn't know how to set up an archive, they can always ask for help. Again, it doesn't matter how they choose to clean up the page to a minimum standard so long as they actually do the clean up. I'm not saying "make it super tidy" but more like "make it not look a total mess". If users feel particular attachment to the collections of their discussions that they ABSOLUTELY NEED on one page, they can create a subpage in the User: space for themselves and advertise it with big-ass fonts. They can also have discussions they are fond of on their talk page so long as they keep the overall size in check. The requirement for administrators to intervene is to make sure the heightened accountability standards apply, even if such intervention does not involve administrative tools. Note that having a big talk page is NOT in itself misconduct. No blocks, no warnings intended, unless there's some real shenanigans going on or the refusal is so stubborn it has a real impact on the community.
Archive tool parameters	Upper archive size limit: 512 KB (wikitext)	Upper page size limit: 200 KB (wikitext) Upper archive size limit: 150 KB (wikitext) Minimum thread count: 10 (outside user talk pages) Maximum archiving interval: 365 days (1 year), but not until the minimal thread count is exceeded.	If the parameter is unspecified, or if any value outside the permitted range is put in the parameters, the values will default to the threshold values.

Survey (talk pages)

• Yes to all as proposer. Szmenderowiecki (talk · contribs) 14:29, 29 January 2026 (UTC)
• Oppose all, mega oppose c, turbo oppose d and g, turbo mega oppose f. Automatic archiving of talk pages, astonishingly frequently, preserves any vandalism or disruptive edits of talk pages in the archives. We should not make it mandatory and we definitely should not mandate giving people even less time to check for vandalism until the bot strikes (that window is already as short as one or two days, in some cases). We absolutely should not make it the job of users to enforce accessibility considerations, that is the job of the actual paid frontend employees. Gnomingstuff (talk) 15:25, 29 January 2026 (UTC)

  also, I assume a) is meant to be "maximum number of 10 topics" because otherwise that makes most talk pages non-compliant. But I still oppose it either way, because setting a topic maximum codifies the loophole of spamming a talk page with many new topics to force the archive bot to trigger and disrupt the discussion. Gnomingstuff (talk) 15:28, 29 January 2026 (UTC)

  No, it's actually minimum. Most threads are not that long. If that the threads are so huge as to spill over the maximum limit, which doesn't happen that often (average >20 KB wikitext or even more), then this setting will be overridden.

  re: spamming a talk page with many new topics to force the archive bot to trigger and disrupt the discussion. -> impossible under this proposal, because archiving will be disallowed if the last comment in a given thread is 10 days old or younger, unless the archiving interval was set at a lower value. And that's a hard one. Szmenderowiecki (talk · contribs) 16:03, 29 January 2026 (UTC)

• Support all except point a - there should be flexibility on this point. 10 would be innappropriate for infrequently accessed talk pages, and 3 or 5 is perfectly adequate for encouraging discussion. Danners430 _{tweaks made} 15:29, 29 January 2026 (UTC)
• Skeptical of hard rules - If a page is at a hard maximum, and someone comes in with an important topic that needs to be discussed, is their edit disallowed? Do they have to fiddle with archiving something (perhaps even an active conversation) before they can tell everyone that Willy on Wheels is deleting the main page again?
  I'm fine with a smarter archive bot that can dynamically change how aggressively it runs based on page size. That seems worthwhile to me. Is forced archiving of user talk something that affects more than a few dozen editors? Is there a systemic problem here? However, if we happen to have 2 big, active important discussions on a noticeboard at the same time, I think accessibility is the sacrifice we make for keeping those discussions intact and in the expected place.
  It also might be worth exploring a finer grained structure for some noticeboards - Wikipedia:Administrator's Noticeboard/Quick Requests for things that don't need huge input is one wild guess I had that might work. Tazerdadog (talk) 15:38, 29 January 2026 (UTC)

  If a page is at a hard maximum, and someone comes in with an important topic that needs to be discussed, is their edit disallowed? -> ABSOLUTELY NOT. The question is why the page hits the ceiling. If the reason is that the page has very high traffic, but the bot is set at 10 days archiving interval or shorter, then deviations will be tolerated for the sake of keeping discussions, although huge discussions probably should be spun out in their own pages (see table). If the page hits the ceiling because the parameters are too loose and there's suddenly high traffic, they have to be set at 10 days. The page should not generally hit the ceiling despite low traffic, unless it's a userpage, where archiving will not be obligatory, in which case the enforcement kicks in. These archiving enforcement restrictions are absolutely not supposed to discourage or ban discussion.

  I don't think there are archive bots that dynamically adjust aggressiveness of archiving. This would be ideal but require a bit of coding I simply do not have the brain for, and I think this will actually be hard to code well, and will be likely too much effort for someone who is not paid for the coding. Szmenderowiecki (talk · contribs) 16:13, 29 January 2026 (UTC)

  This is probably worth exploring after this discussion is closed. At the grave risk of saying this about anything technical, it doesn't look like it'd be that hard to implement a minimum viable product of dynamic archiving. Tazerdadog (talk) 01:57, 30 January 2026 (UTC)

• Skeptical of hard rules I can understand the premise, but I am not convinced that we want a one-sized fits all solution. Fundamentally, I think there should be ways to "sticky" some threads on a talk page and there is a smarter way to search archives. --Enos733 (talk) 16:32, 29 January 2026 (UTC)

  • I believe Template:Do not archive until might do what you want to do already. Tazerdadog (talk) 02:00, 30 January 2026 (UTC)

• Oppose: I think this is too inflexible to allow for the deviations mentioned. This (except a maximum page size which should be a requirement unless all sections are ongoing and not close-able) should be a set of recommendations, not enforced rules. That would be very unWikipedia.
  Turbo mega oppose a: I don't really see the purpose of a requirement that so deviates from our current practice. This would be a lot of enforcement for little benefit. I would think just one is enough, and I unfortunately don't have time to figure out where the TPG talk page discussed this right now, so I'd appreciate if someone could point this out. Aaron Liu (talk) 16:35, 29 January 2026 (UTC)

  unfortunately don't have time to figure out where the TPG talk page discussed this right now, so I'd appreciate if someone could point this out. This was discussed at the linked idea lab thread of the Village Pump. I got some feedback that the number is too high, and on the other hand, a temp account suggested a maximum of 15 threads/30 for high-traffic areas. This is not the essential part of this RfC, so if the number is 3 or 5, so be it. I don't care that much so long as it's not 0. 1 is probably not good enough. Szmenderowiecki (talk · contribs) 16:42, 29 January 2026 (UTC)

  Could you elaborate on why 1 is not good enough? Aaron Liu (talk) 17:26, 29 January 2026 (UTC)

  As I was reviewing discussions, I found some users' concerns that empty pages discourage discussion. One may be pretty empty, particularly if the suggestion is not answered, as it is on most article talk pages. Szmenderowiecki (talk · contribs) 17:30, 29 January 2026 (UTC)

  I guess I just disagree that one discussion is pretty empty. Aaron Liu (talk) 17:34, 29 January 2026 (UTC)

• Oppose all - I'm not really convinced there's an issue here that requires fixing, especially "fixing" via enforcement. If a talk page for an article is too large, please feel free to add automatic archiving as you see fit. If a user's talk page is too large, consider opening a discussion with that user, even if their page loads kinda slow when you start that discussion. Per Gnomingstuff's earlier point, if there's actually widespread accessbility issues related to how pages are rendered and presented to users, that would be a UI problem to be fixed by development and not a content problem to be fixed by limiting content. --tony 16:46, 29 January 2026 (UTC)
• Oppose all also BADRFC which goes against the consensus. RfC statement is not neutral nor brief. Pinging large groups of people wastes valuable volunteer time. Polygnotus (talk) 16:50, 29 January 2026 (UTC)
• I don't think such restrictive requirements are a good idea, and definitely strongly oppose a. Editors should keep in mind that very large talk pages could be a barrier to communication. For article talk pages simply setup archiving if you come across one with size issues. When it comes to the talk page of that one particular editor active editors maybe there could be an annual AN discussion to encourage them to tidy up their talk page. There are many inactive editors without talking page archiving who receive endless automated messages, leading to a lot of bloat, but that's of very little impact (noone needs to communicate with them, and there is little limit on storing text). -- LCU ActivelyDisinterested «@» °∆t° 16:56, 29 January 2026 (UTC)
• I firmly support introducing an enforceable talk page size limit. Having a talk page that will load across all editor devices is important for accessibility, and as we have documented elsewhere we have talk pages that are unusable (so contra several colleagues above, there is a concrete problem, albeit one of limited scale). I don't want to get too far into the weeds with respect to specifying limits; a byte-size should be sufficient, because we do not want the enforcement to become a bureaucratic mess. I suspect this RfC has too many specifics to gain consensus, but in the interest of making a closer's life easier I will note I support b & e, oppose a and am largely agnostic as to the rest. Vanamonde93 (talk) 16:58, 29 January 2026 (UTC)
• Oppose almost all, the one possible support is b (maximum byte size for pages, a reasonable technical limitation) but that should probably be done in a separate RFC on just that topic, and be a "soft" maximum anyway. Everything else is a bad idea that creates layers of bureaucracy and bad feeling over nothing important. SnowFire (talk) 16:59, 29 January 2026 (UTC)
• Oppose all, including B because you can have a single discussion going over that limit. Just check ANI for easy samples. --SarekOfVulcan (talk) 17:04, 29 January 2026 (UTC)
• Oppose The OP claims that We have well-tested archiving tools/subpage creation tools that automate the process. This is not my experience. I've been editing Wikipedia for nigh on 20 years and I've not gotten on with any of the assorted archive tools which I've tried. And the archive pages for subprojects like ITN are among the worst offenders in my experience -- bloated and broken due to the template limit. What's needed is for the WMF to address the technical issues as that's their job. Wild development and draconian diktats are unlikely to be helpful. Andrew🐉(talk) 17:05, 29 January 2026 (UTC) (edit conflict)
• Oppose. This is a disproportionate response to the basic issue of Eeng's ludicrous talk page.—S Marshall T/C 17:07, 29 January 2026 (UTC)

  Also, snow closes exist.—S Marshall T/C 17:09, 29 January 2026 (UTC)

• This is not well-thought-out at all. It contradicts existing practice for the majority of cases, and some of the provisions (particularly a and b) are mutually exclusive. —Cryptic 17:15, 29 January 2026 (UTC)
• Essay Make an essay. Create the case there, supported by common sense, guideline and policy. Create a CAPLETTER link. Start linking it. If it catches on, within a couple years, you or someone else will promote it to guideline. This is the way to do it. These all-or-nothing hail mary proposals on VPP are lazy and usually don't work. You got to build something if you want to make change. -- GreenC 18:02, 29 January 2026 (UTC)
• Oppose oppose oppose.
  Oppose RfC structure. The letters a-g don't match the rows in the table. My head hurts, and since this should be headed for SNOW close I won't renumber. Capital letters below talk to the table, not the lower-case list.
  Oppose A. Not mandating archiving of user talk (i.e. just deleting old stuff is fine) is valuable and should be kept. Archiving parameters (including "no archiving") is a personal preference. While the justification of the RfC is making user talk accessible, the proposal fails to explain why such harsh measures must be taken.
  Oppose B. No need for a specified number. Just force EEng to archive, and you've solved all problems :)
  Oppose C. Different talk pages require different archiving intervals. Archiving every 10 days is insane for regular user talk pages.
  Oppose D. Start a new separate discussion (without the infected atmosphere of this one). Opposing mostly because bundling this together with everything else is really ill-advised.
  Oppose E. The suggestions makes it clear the proposer don't know how people use archiving bots. The only sane minimum number of threads to keep is 4. 10 is way too many.
  Oppose F. For the same reason as D - start a separate discussion.
  Oppose G. Just hell no.
  Oppose H. For the same reason as D - start a discussion separate from everything else.
  In closing, the proposer really needs to study how to create constructive RfCs because this ain't how you do it. CapnZapp (talk) 18:22, 29 January 2026 (UTC)
• Yes to all I believe this is sorely needed for accessibility reasons, though I'm sure it will be opposed by people as too restrictive. ᴢxᴄᴠʙɴᴍ (ᴛ) 19:38, 29 January 2026 (UTC)
• Oppose as written This goes too far and is too strict (and "a" is just a bad idea). I'd support stronger recommendations around archiving than we have now after Wikipedia talk:Talk page guidelines#RFC: Recommended maximum talk page size, but strict limits aren't going to work well and mandating bots archive every talk page would probably work even less well. Good luck figuring out what those recommendations should be though, since it seems the people who really care are mostly the ones who like having ridiculously huge user talk pages and they're happy to derail straightforward heuristics into demanding any rule be based on "page weight" and so on. Anomie⚔ 19:56, 29 January 2026 (UTC)
• Oppose all. This entire proposal is a complete waste of time. There's no reason whatsoever why we should enforce a hard limit on talk page sizes. This has to be one of the most poorly thought out RFCs I've ever seen, let alone participated in. Sugar Tax (talk) 20:11, 29 January 2026 (UTC)
• Strong oppose all - A is a terrible idea. That will add to clutter, not reduce it. It will make pages less accessible, not more. B is also a terrible idea. This has been explained many times: how long it takes for a page to load is not based on how many kB the page is in size. Because A and B are bad ideas, the rest of the proposals, which seek to enforce A and B, are also bad ideas. And really, the last thing this website needs is more r00lz. There are like a million f'ing rules on this website because it's 25 years of people being like, "I don't like this, let's make a rule to prevent it!" Look, you want to make every page on Wikipedia load reasonably quickly, there is one way, and really only one way, to go about it: you pick your website performance tool, and you say "must load within 5 seconds (or whatever amount of time) on any browser less than 10 years old (or whatever amount of time), as measured by X tool (or the average of multiple tools, take your pick)." You don't regulate the damn kB or the number of minimum threads if you want a page to load quickly, because that doesn't solve the problem. Levivich (talk) 20:31, 29 January 2026 (UTC)
• Oppose all and suggest WP:SNOW close:
  I have a fair amount of experience with limited hardware and ancient software. As I look around my lab I see that my CP/M machine (actual Z80 hardware, none of this emulation rubbish) from 1983 is still working fine and used daily for text editing and my daily driver is a ThinkPad T580 from 2018. The limits proposed in this RfC are far too small. Anyone who has trouble reading a page twice the size of these limits is already used to having trouble reading half of the web.
  I would be inclined to support a policy against exceeding the limits found in https://www.mediawiki.org/wiki/Manual:$wgMaxArticleSize and https://www.mediawiki.org/wiki/Manual:$wgAPIMaxResultSize --Guy Macon (talk) 20:47, 29 January 2026 (UTC)
• Oppose all. In particular:

  a) oppose minthreads=10. If you have sufficient experience with Talk pages you know that sometimes an individual thread can run long, including longer than 200kb on occasion, so this would contradict one of your other proposal terms.

  b) oppose max pagesize=200 and max archive=150. This has been very recently debated, and it is inadvisable to raise this again so soon, even if subsumed as part of a longer proposal.

  c) oppose mandated archiving: better clarify what you mean by mandated. We mandate very little at Wikipedia, other than WP:LIBEL, WP:COPYRIGHT, some trust & safety considerations, and a short list of other policies with legal implications.

  d) oppose required short archiving delay in some cases, per WP:CREEP and WP:BURO. You do not trust administrators at WP:ANI to know enough how to do the right thing? I can conceive of no case where having a rule about this will do anything other than provoke unnecessary strife.

  e) oppose limitation on user freedom to choose their own talk page size. Is this about EEng's talk page? If so, then it is none of your fucking business. Don't bring proposals to VPP aimed at particular users; solve it in discussion with them, or at WP:AN if you must. If not about their (or some individual's) talk page, then please ignore the previous statement with my apologies; in that case I oppose per WP:OWNTALK and WP:CREEP.

  f) oppose oppose oppose UTP max size enforcement. See e), and WP:OWNTALK, WP:CREEP, and WP:BURO. Personally, I would consider invoking WP:IAR to reverse enforcement at random other UTPs under this rule to see how strong the community support for this disastrous provision really was, assuming it were ever adopted, which I strongly doubt.

  g) oppose enforced bot maxsize validation. I see a lot of terms like mandate, enforcement, limit, require, comply, and force in your proposal. You see to be in battle dress here, getting ready for the mother of all archiving wars. Where are all the terms like generally, should, typically, suggested, consider, and other terms that are often used in Wikipedia policies and guidelines to indicate something less than a hanging offense? Your usage smacks of my way or the highway, and does not conform to general usage at Wikipedia, in my opinion.

• Thanks, Mathglot (talk) 21:06, 29 January 2026 (UTC)

In re "e)", if there's something about someone's User_talk: page that makes it difficult for other editors to communicate with them, then it is other editors' business. WhatamIdoing (talk) 22:07, 29 January 2026 (UTC)

Not necessarily. If you have trouble accessing a webpage, it's not necessarily the problem of the webmaster to fix it, it might just be that you're using obsolete technology. It's not tolerable or practical to expect us to have every single web page work great for every single user no matter how obsolete (or laden with plug-ins, scripts, etc.) their client is. We should require ourselves to meet industry-wide web standards, not the standards of every random person on the internet. Levivich (talk) 22:12, 29 January 2026 (UTC)

If you're required to post an ANI notice, and you can't because the editor has a million-byte-long User_talk: page, then we have a problem. "Hey, stop being a jerk and archive your talk page" is something we can do. "Dude, stop being poor and buy a new computer if you want to report someone to ANI" is not something we can do. WhatamIdoing (talk) 22:54, 29 January 2026 (UTC)

Not necessarily. If 1,000 people have no problem posting the ANI notice, but one person does have a problem because they have too many plug-ins or scripts installed, or they're simultaneously downloading many files, or they're just using a 30-year-old machine, then "we" do not have a problem, just that one person has a problem, and "fix or update your client" is something we can say. Again: we should comply with industry-wide web standards, not with the needs of every single person out there. Levivich (talk) 22:59, 29 January 2026 (UTC)

This is not the case I'm asking about. Nobody is saying that we accommodate Nokia 3310 users. Szmenderowiecki (talk · contribs) 23:04, 29 January 2026 (UTC)

Re: recommendations vs mandates, recommendations are basically unenforceable with enough determination from the user who does not want to follow recommendations. We already have a recommendation saying that Large talk pages are difficult to read and load slowly over slow connections and User talk pages must serve their primary purpose, which is to make communication and collaboration among editors easier. - Hint: make pages accessible enough to make collaboration easier. Does this recommendation work? No.
There is a reason government pages require basic accessibility support, with reference to WCAG guidelines. There is no reason we cannot require this on our side. Szmenderowiecki (talk · contribs) 23:10, 29 January 2026 (UTC)

And how exactly is this the job or responsibility of unpaid volunteers, as opposed to the engineers who are actually paid to make websites accessible and improve rendering time? Gnomingstuff (talk) 23:47, 29 January 2026 (UTC)

And how exactly is this the job or responsibility of unpaid volunteers, as opposed to the engineers who are actually paid to make websites accessible and improve rendering time? Why as opposed to? Por qué no los dos? Also, volunteers don't have to do anything at all, and yet they do.
Your attitude just kicks the can down the road. And I don't have to remind you that WMF has had quite a few fumbles about their coding. In this thread, just look at the 03:31, 30 January 2026 (UTC) comment. Szmenderowiecki (talk · contribs) 11:31, 30 January 2026 (UTC)

if you're proposing sanctions then it does make it compulsory, at least if one wants to participate Gnomingstuff (talk) 18:25, 30 January 2026 (UTC)

Does this recommendation work? Yes.

The subject of archiving comes up nowhere in the W3C acessibility guidelines.

You just gave the reason yourself why this Rfc was unnecessary and a gigantic waste of time; quote:

We already have a recommendation [about] [l]arge talk pages...

Details in the discussion below. Mathglot (talk) 02:58, 30 January 2026 (UTC)

Bad performance impacts accessibility and user experience. State of California, University of St Andrews. I thought this was obvious.
The long pages talk report would at most have a few entries above let's say, a cutoff of 250 KB. It not the case. So no, the recommendation doesn't work. Szmenderowiecki (talk · contribs) 11:19, 30 January 2026 (UTC)

I have never seen anyone get any actual negative action against them if they fail to post on a user's talk page for an ANI report. Many editors are eager (perhaps overly so) to notice omissions and correct them. To avoid this argument (and I think it's actually generally a good change) perhaps we should amend the ANI rules to say that if you cannot reasonably, for any reason, post on a user's talk page, mention that in your initial report (or immediate reply). Skynxnex (talk) 00:54, 30 January 2026 (UTC)

More generally, even when specific forms of communication are not required, we expect editors to be able to communicate with each other. That includes making it reasonably possible for newbies to be able to leave a message on any page that is used for discussion.

ANI itself frequently breaks that limit; a handful of editors' User_talk: pages do as well. For example, I remember when DGG's talk page regularly ran >800K long (example) and sometimes exceeded a million bytes. That revision took about 10 seconds just now to load on a modern computer with a decent internet connection and all scripts/gadgets disabled via mw:safemode. @Levivich mentions industry-wide standards, which I believe are that pages should generally load within three to four seconds (because that's when users start giving up). Now imagine that it's not loading on my MacBook, but on a smartphone. Good luck loading the page. Extra good luck being able to edit it, or even to scroll to the end.

You and I could think up half a dozen ways to cope with this, but a newcomer can't, and nobody should have to. WhatamIdoing (talk) 05:22, 30 January 2026 (UTC)

That old revision took about 8 seconds to load load on my modern phone over 5G. Most of the time was spent, I am pretty sure, by the server itself having to freshly fetch and render the page since it was probably uncashed for me. I think one circle I'm trying to square is that none of this should be be any editor's job. It shouldn't be a bot's job. There shouldn't be rules and potential punishments if you do it wrong. The MediaWiki itself should just allow editors to pick how many sections they see per talk page. Abd the rest are the archives. But of course the long history of talk pages just being a page makes that hard. But that sort of change is less disruptive than more rules. Skynxnex (talk) 05:40, 30 January 2026 (UTC)

What do you think the loading time would be if you were using a low-end phone (e.g., a JioPhone) on a pay-per-use data plan? I think it's safe to assume that the answer is "worse", and yours was already twice the industry standard. Did you try to scroll to the end of the page?

The problem with changing talk pages (remember Wikipedia:Flow?) is that the change would have hurt one group of people and benefited a different group of people. So naturally the first group complains that it's all harm and no benefit (to them), and the beneficiaries are already have difficulty with joining conversations, so they have much less ability to make their view heard. I don't think that reality will change this decade. We will probably have to wait until the small minority of editors who primarily use mobile devices become a more vocal part of the Wikimedia communities. In the meantime, what's happening is that mobile-heavy communities are finding off-wiki places for discussion and coordination (e.g., Whatsapp or Discord). WhatamIdoing (talk) 18:50, 31 January 2026 (UTC)

• I support a limit on the size of user talk pages, but not on noticeboards, which are generally archived automatically and have not proved an issue in the past. However, I also think the horrendous formatting of this RfC has killed any chance of us getting a productive outcome here. Proposing seven different changes at once, some of which put the cart waaay before the horse (enforcement mechanism for a guideline that has yet to exist??) was a bad idea. Toadspike [Talk] 21:34, 29 January 2026 (UTC)
• Oppose all - I am yet to be convinced that there is a real problem with talk pages - annoyances yes, problem no. Nor do I think that any of the proposals would be an appropriate way to deal with the annoyances. When there is an issue with a talk page, our current rules (and lack thereof) give us FLEXIBILITY to deal with them as we think best fits the specific situation. This all seems to CREAPY to me… boxing us in unnecessarily. Blueboar (talk) 21:46, 29 January 2026 (UTC)
• Oppose as misguided and repetitious. As I already said in December, If archiving a thread is controversial, it very likely should not happen. If it's not controversial, there's no reason to wait until the page reaches some arbitrary size. The fact I am quoting myself from another RFC on this same topic barely a month ago suggests this RFC is problematic. —Rutebega (talk) 23:00, 29 January 2026 (UTC)
• Oppose all, as strongly as possible. Good grief, not this nonsense again! The idea of making this kind of stuff enforceable is downright offensive. --Tryptofish (talk) 00:14, 30 January 2026 (UTC)
• support b, good compromise between a maximum size and accessibility. ltbdl (love) 00:49, 30 January 2026 (UTC)
• Oppose as written This is a bit too much to do in one RfC. Would suggest rescoping this RfC to be targeted to user talk pages only (I'd assume that's why you wanted to make this RfC right?). In addition, outside of the user talk space, if the talk page is too big, no one is going to complain if you archive some stale topics so no hard guideline is needed. Workshop something that's basically "you have a problem if the average user can't discuss conduct issues on your user talk page" and I think that would be sufficient. Jumpytoo Talk 01:54, 30 January 2026 (UTC)
• Support a maximum size, absolutely. I have a reasonably good computer, and it still takes an absurd amount of time for some user talk pages to load. This is a collaborative project, where accepting communications is necessary, and should not be hobbled by an inordinate pride in an absurd talk page size. BD2412 T 04:52, 30 January 2026 (UTC)
• Oppose all: WP:OWNTALK, "Oppose the creation of this unnecessary and complicated rule for a very uncommon situation that could just as easily be solved by editors using their best judgment..., and WP:BURO -- Otr500 (talk) 05:14, 30 January 2026 (UTC)
• Strong support some kind of stronger enforcement for accessibility, including a maximum size for user talk pages. I don't know why editors think the layout of their talk pages is so important that they can impede accessibility for others. Wikipedia is not a forum and talk pages exist so editors can communicate with each other, not so they can be fancily decorated or have years old discussions visible at first glance. There is a good reason we have a WP:SIZERULE for articles, and there is even less of a reason to not impose a strict limit on the size of user talk pages than for articles. While WP:CREEP can be a valid concern, it does not apply here, at least without meaningful justification as to why a user talk page might need to be that large.
  I don't have strong opinions on many of these particular proposals other than I generally echo the sentiment from others (particularly Toadspike) that this is far too specific/narrow a proposal to work. For the closer, you might interpret this as support b, e and f, oppose a and no opinion on the rest. Katzrockso (talk) 13:45, 30 January 2026 (UTC)
• No. With all due respect, this feels like a case of wasting the community's time to resolve a petty issue of minimal consequence. I struggle to believe that even goofy talk pages like User talk:EEng present a real accessibility problem. How frequently does someone need to contact those specific editors so urgently that they can't wait a few seconds for the page to load, or wait until they are on a more reasonable browsing setup? Some of the devices I use to browse the web are so ancient that they struggle to load most pages on the web, but I was still able to load User talk:EEng, scroll through the sections, and click edit on a section of my choice in about 30 seconds. -- LWG ^{talk (VOPOV)} 19:34, 30 January 2026 (UTC)
• Oppose - None of these seem worth doing. Too many edge cases, too much bureaucracy when it's only very rarely a problem. On-wiki page sizes are tricky measures to use, because the size of the wikitext is not the same as the size of a page in a browser, with all the images and templates and whatnot. And there are some talk pages that really do need to be longer than others. So this all seems like for circumstances when both of these are true: (a) multiple people have difficulty using a talk page and ask for something to be done about it (or tries to do something about it), and (b) someone ignores the complaints and/or reverses efforts to fix the issue. The latter is very rare, and only ever an issue in userspace, where we tend to frown on other users jumping in to archive. Really, I can only think of one case where both of the above have been true on a usertalk page. I do not know why that person digs their heels in, or why several people reliably show up to insist it's cool, but them's the breaks with norm-breaking and social capital on wikipedia (and, let's face it, most places). In other words, if anything it's a one-off for an administrators' noticeboard, no ta new policy; and I'd also recommend against that noticeboard trip as pointless. As I wrote below, a new entry in perennial proposals would be justified at this point. — Rhododendrites ^talk \\ 00:53, 1 February 2026 (UTC)
• UM WHAT? All pages with discussions limited to 10 topics? So how do you suggest Wikipedia:Administrators'_noticeboard/Incidents, Wikipedia:Village_pump_(technical), Wikipedia:In the news/Candidates, etc get handled @Szmenderowiecki:? — xaosflux ^Talk 00:58, 1 February 2026 (UTC)

  No, their proposal is to have all pages have a minimum of 10 topics. SuperPianoMan9167 (talk) 00:59, 1 February 2026 (UTC)

  @Xaosflux: You misread their proposal. They are proposing for all talk pages to have a minimum of ten topics at all times. (Which still doesn't make a whole lot of sense.) SuperPianoMan9167 (talk) 01:01, 1 February 2026 (UTC)

  I am flexible as to the minimum number, so long as it's not 0 Szmenderowiecki (talk · contribs) 01:11, 1 February 2026 (UTC)

  Why not zero? If all the discussions on my user talk page are a year old and refer to something long since resolved, who are you to tell me that I can't archive all of them? --Guy Macon (talk) 01:41, 1 February 2026 (UTC)

  Establish a minimum number of 10 threads on pages, except on user talk pages. So I think we are talking about article talkpages. But often article talkpages contain only stale stuff that has been dealt with years ago and is no longer relevant. Polygnotus (talk) 01:53, 1 February 2026 (UTC)

  I can see the value in the default being a non-zero value for article talk pages automatically archived by a bot, which cannot tell whether the stale stuff is still relevant. That also gives an approximate indication of how active the talk page is (if I ask a question there is it likely to be seen or should I hunt down a WikiProject?) but if editors at a particular talk page think a non-default value (including zero) is appropriate there then that should be allowed imo. Thryduulf (talk) 02:01, 1 February 2026 (UTC)

  OK thanks, I think this proposal is confusingly worded. Certainly we wouldn't require pages to have 10 discussions on them, it seem that that is supposed that 10 part is supposed to only be about a parameter for this mysterious archiving solution - and not actually a minimum number of topics required on a talk page (i.e. a talk page can't even be CREATED unless you start 10 or more discussions at once). — xaosflux ^Talk 01:32, 1 February 2026 (UTC)

  I think this is intended to relate to the number of threads left on a page by archiving bots. For example Wikipedia talk:WikiProject UK Railways archiving configuration has the parameter minthreadsleft = 5 so old threads (in this case defined as 30 days since the last activity) will not be archived if it would result in fewer than 5 threads being left on the page. I'm at a loss as to why this is something that needs to be a guideline, let alone anything stronger. Thryduulf (talk) 01:50, 1 February 2026 (UTC)

  Some people think a talk page with some discussions on it, even if they're really old, is more inviting for newbies. Possibly the proposer here is one of them. Or maybe the idea was just to avoid "unnecessary" archiving on very inactive pages since the proposal calls for automatic archiving of all talk pages. Anomie⚔ 02:01, 1 February 2026 (UTC)

  That's the impression I got from reading the TPG discussion, where two issues were raised: disputes over manual archiving and empty talk pages that may result out of that. It was a minor thread in the discussion, but the people who did address it were largely opposed to both. Hence the proposal. Szmenderowiecki (talk · contribs) 09:06, 1 February 2026 (UTC)

  Regarding 0 threads: there appear to be more than 1.9 million user talk pages with no discussions on them. No doubt many are inactive, but not all; what happens to them if this passes? Mathglot (talk) 06:44, 1 February 2026 (UTC)

  Nothing, because this proposal discourages manual interference with the archives unless it is due to bot error. Szmenderowiecki (talk · contribs) 09:04, 1 February 2026 (UTC)

• The easiest solution is an addition that anyone can archive any inactive threads on any talk page, and reverting these archivals is disruptive. sapphaline (talk) 10:10, 1 February 2026 (UTC)

  See "Proposal #2" section below. sapphaline (talk) 10:23, 1 February 2026 (UTC)

• Oppose absurd talk-page bureaucracy. —David Eppstein (talk) 18:34, 2 February 2026 (UTC)
• Strongly oppose preposterous proposal for draconian, misguided, additional rules. I'll admit it: you lost me at your very first point, Establish a minimum number of 10 threads on pages. You mean you demand that we add up to 9 (or even 10) threads to every talk page on enwiki? No, thanks. I went on, anyway, out of basic respect, but your suggestion that we let the bots from Minority Report crawl over every page and disrupt even appropriate and useful retention of discussion did not entice me. Your hidden table—kudos: you collapsed it!—was impossible for me to make any use of. I did see reasonably accessible but did not make it to the part where you defined "Reasonable". In summary, the specific parts of the proposed changes I do not like are a through g. Thanks for asking, but I can offer no support. — JohnFromPinckney (talk / edits) 23:04, 2 February 2026 (UTC)

Counterproposal

1. EEng is asked to archive his talk page.
2. If, within 7 days, EEng doesn't archive his talk page so it works like a normal talk page, then EEng is topic banned from editing any other page except his talk page. This sanction expires when EEng's talk page works like a normal talk page.

The end.—S Marshall T/C 20:36, 31 January 2026 (UTC)

Quick question: how does this help us achieve our goal of a world in which every single human being can freely share in the sum of all knowledge? Polygnotus (talk) 21:01, 31 January 2026 (UTC)

We generate an encyclopaedia collaboratively, and this facilitates collaboration by making sure users can talk to each other.—S Marshall T/C 21:03, 31 January 2026 (UTC)

I have asked Quiddity to find a WMFer who can dive into the technical stuff; that way we have a solution for all long pages once and for all. Polygnotus (talk) 21:09, 31 January 2026 (UTC)

I don't want trouble for anyone, man. I don't have a beef against EEng, but his page is a problem and he's not the only one with this problem. It would be unfair to EEng to punish him but not the others in Wikipedia:Database reports/Long pages/User talk (no subpages).
The whole point of my proposal was to avoid any banhammer deployment. Szmenderowiecki (talk · contribs) 21:03, 31 January 2026 (UTC)

Being unwilling to archive your talk page is a user-level problem and the solution is at user level.—S Marshall T/C 21:20, 31 January 2026 (UTC)

Counter-Counterproposal:

Common snipe ^[a]

1. S Marshall is asked to stay on topic, avoid personalizing discussions, and stick to general principles of Wikipedia.
2. If User:S Marshall continues to waste everybody's time by perverting this discussion and turning it into an attack on one editor (and in the wrong venue), then S Marshall shall be required to write one hundred times on a Village Pump subpage (which may be entitled, .../Blackboard, if desired) that "I shall stick to the point and avoid personalizing the issue and being a general dufus at Village Pump." (in cursive)

Corollary: Mathglot to be trouted for failing to take their own advice. Mathglot (talk) 21:14, 31 January 2026 (UTC)

Bargain-Countertenor Proposal: Everybody here should go and work on some content, and give this a rest. --Tryptofish (talk) 19:48, 1 February 2026 (UTC)

I think this talk section illustrates vividly how unhelpful the entire idea proposed at the top really is. And frankly, this section (not the whole discussion, just this section) should be closed and hatted as a personal attack. --Tryptofish (talk) 22:00, 31 January 2026 (UTC)

should have been hatted the moment someone brought donald trump into it, really

seriously guys (Polygnotus excepted for actually doing something productive), what the fuck Gnomingstuff (talk) 02:59, 1 February 2026 (UTC)

Let's agree that it should have been hatted, because it sure ain't making Wikipedia great again. --Tryptofish (talk) 19:31, 1 February 2026 (UTC)

But that snipe sure does have a big beautiful bill! --Tryptofish (talk) 19:45, 1 February 2026 (UTC)

• Has this been retained (not archived) for humor reasoning, a community consensus against one or more editors, or maybe the love of drama and large talk pages? Surely it is not because of a lack of archiving knowledge-- Otr500 (talk) 22:41, 31 January 2026 (UTC)
• Is it time to just add "force EEng to make his user talk page functional" to the list of perennial proposals? Or an extension of WP:UNBLOCKABLES called "WP:UNARCHIVABLES" or "WP:UNTALKABLES"? Raised by many people many times over many years, but just gets a bunch of "relax, it's no big deal" responses from third parties. After it crashed my browser a couple times some years ago, I'm certainly not going there (not that I've had a need to), and I light a candle for any newbie who tries to leave him a message on mobile. But yeah, I agree with the pile-on above that we're not going to institute hard rules for this. It's one of those fairly-low-stakes-in-the-grand-scheme-of-the-project norms that everybody just kind of does because we want this to be a place where collaboration is easy and we don't make life unnecessarily hard for each other, and which we're realistically only going to enforce if someone lacks social capital. Adding: EEng is not usually the person with the longest page -- we should enforce this evenly or not at all -- but EEng is certainly the page that comes up most frequently. — Rhododendrites ^talk \\ 23:12, 31 January 2026 (UTC)

  Hard cases make bad law. Polygnotus (talk) 23:37, 31 January 2026 (UTC)

• I tried to WP:BOLDLY hat this discussion, but of course I'm involved, and S Marshall reverted it. I still think this section is counterproductive. --Tryptofish (talk) 23:32, 31 January 2026 (UTC)
• It occurs to me that a counterproposal that involves the idea of sanctioning EEng is something that EEng ought to be notified of. (Oh, but his talk page was too long to notify him, I get it! rolls eyes) So I did it: [1]. --Tryptofish (talk) 23:39, 31 January 2026 (UTC)

  I've been trying to talk to you for about half an hour Tryptofish and got edit conflicted every single time so you get the short version.

  Your claim that this reduces to a personal attack on EEng is wildly mistaken. It's about EEng personally. It's about a problem with EEng's talk page behaviour. But it's not an attack to propose a solution.—S Marshall T/C 23:45, 31 January 2026 (UTC)

  And, the solution for EEng is not the solution for every editor in the long talk pages category. Some of those talk pages load easily. Some of the editors are indeffed and it's not realistic to expect them to fix it.—S Marshall T/C 23:47, 31 January 2026 (UTC)

  But, EEng is a user in good standing who's bright enough to see that his talk page is a problem. He's well aware that it needs to be fixed. We've established at the DRV that preceded this mess that other people don't get to archive EEng's talk page for him.—S Marshall T/C 23:49, 31 January 2026 (UTC)

  Therefore there's only one person who can fix the problem and it's EEng. He knows he needs to do it. He hasn't. So I suggest ways of making him.—S Marshall T/C 23:51, 31 January 2026 (UTC)

  In a collaborative project you must have a talk page people can work with. If people can't work with your talk page then you're being uncollaborative. It's the Wikipedia equivalent of antisocial behaviour.—S Marshall T/C 23:53, 31 January 2026 (UTC)

  There isn't only one way to look at this. There's several different ways. One way I like to see it, is that outside of article space, I don't care how long a user talk page is, but it presents technical problems that have yet to be solved. When I comment on a long talk page on my desktop and on my mobile (using desktop view), there is a bit of lag that makes using the reply function impossible. Using the edit section isn't as bad, and adding a new comment entirely tends to work. This shows that there is a problem with MediaWiki, not EEng. How about we fix that first? Viriditas (talk) 00:10, 1 February 2026 (UTC)

  In a perfect world, MediaWiki would be less ghastly. But we don't control that. We have to work with the software we have, not the software we want. So we need volunteers to have the behaviours that make the software work. EEng doesn't. It's got a lot in common with hoarding: begins with a disinclination to get rid of old rubbish, but over time it evolves into a situation where the neighbours are complaining about the smell and the postman can't force any more mail into the overstuffed letterbox.—S Marshall T/C 09:52, 1 February 2026 (UTC)

  @S Marshall I think you mean It's not about EEng personally. Polygnotus (talk) 00:11, 1 February 2026 (UTC)

  I did mean that my proposals are about EEng personally. I didn't misspeak in that respect.—S Marshall T/C 00:13, 1 February 2026 (UTC)

  Oh, then I misunderstood, sorry. Polygnotus (talk) 01:03, 1 February 2026 (UTC)

  S Marshall, you and I have both been around this project for a very long time. (Indeed, I remember the verifiability-not-truth debates of a bygone era.) You, like EEng, are a user in good standing who is bright enough to realize that this discussion you have started is only inflaming the issue, and not accomplishing anything productive. If you have accomplished anything at all, it's that you just might have caused more editors to come over to the opinion that is opposite to your own. --Tryptofish (talk) 19:31, 1 February 2026 (UTC)

Discussion (talk pages)

Pinging all participants of the deletion review that precipitated the discussion, the idea lab thread and the talk page guideline thread. I have reason to believe that these participants will be likely interested in this discussion. Pings: @Voorts, OwenX, GreenLipstickLesbian, SuperPianoMan9167, Katzrockso, Tryptofish, SmokeyJoe, Bradv, XtraJovial, Jumpytoo, EEng, SportingFlyer, ~2025-43151-08, Sugar Tax, Cryptic, Jclemens, S Marshall, Spartaz, LakesideMiners, Alalch E., Skynxnex, Schazjmd, WhatamIdoing, ActivelyDisinterested, Aaron Liu, Gnomingstuff, Anomie, ~2025-31733-18, Ritchie333, Mathglot, CapnZapp, Rolluik, Zxcvbnm, Locke Cole, Guy Macon, Vanamonde93, Cremastra, Rchard2scout, Polygnotus, JoJo Anthrax, Ltbdl, Odysseus1479, LaundryPizza03, Andrew Gray, GreenC, Levivich, SnowFire, FaviFake, Blueboar, and ~2025-35132-06: @JoJo Anthrax, Ltbdl, Odysseus1479, LaundryPizza03, Andrew Gray, GreenC, Levivich, SnowFire, FaviFake, Blueboar, ~2025-35132-06Swordman97, Rutebega, SunDawn, Stifle, Toadspike, Andrew Davidson, Alpha3031, Chipmunkdavis, Coining, Otr500, Andrybak, Andrew Gray, and Wbm1058: Szmenderowiecki (talk · contribs) 14:29, 29 January 2026 (UTC)

@Szmenderowiecki I didn't receive a ping from this that I can tell. I believe it is because you included more than 50 and possibly since the edit that had these had multiple sections (WP:MENTION). Skynxnex (talk) 16:06, 29 January 2026 (UTC)

Well then I don't know if it's the case that no one got the ping or it's just random users in the list didn't get it, or maybe those that were at the bottom of the alphabet? I knew that {{ping}} only fits 50 usernames but I didn't know that one comment couldn't have more than 50. Szmenderowiecki (talk · contribs) 16:17, 29 January 2026 (UTC)

They can contain more than one, but if they do, nobody will receive the ping. FaviFake (talk) 16:27, 29 January 2026 (UTC)

Please stop pinging large groups of people. Thanks. Polygnotus (talk) 16:29, 29 January 2026 (UTC)

Why? I appreaciated the ping FaviFake (talk) 16:32, 29 January 2026 (UTC)

@FaviFake Because pinging large amount of people to bad RfCs is a waste of valuable volunteer time. Polygnotus (talk) 16:34, 29 January 2026 (UTC)

I agree. However, that's not what Szmenderowiecki has done. This RfC looks fine. FaviFake (talk) 16:36, 29 January 2026 (UTC)

Resending first batch @Voorts, OwenX, GreenLipstickLesbian, SuperPianoMan9167, Katzrockso, Tryptofish, SmokeyJoe, Bradv, XtraJovial, Jumpytoo, EEng, SportingFlyer, ~2025-43151-08, Sugar Tax, Cryptic, Jclemens, S Marshall, Spartaz, LakesideMiners, Alalch E., Skynxnex, Schazjmd, WhatamIdoing, ActivelyDisinterested, Aaron Liu, Gnomingstuff, Anomie, ~2025-31733-18, Ritchie333, Mathglot, CapnZapp, Rolluik, Zxcvbnm, Locke Cole, Guy Macon, Vanamonde93, Cremastra, Rchard2scout, and Polygnotus: Szmenderowiecki (talk · contribs) 16:20, 29 January 2026 (UTC)

And second batch @JoJo Anthrax, Ltbdl, Odysseus1479, LaundryPizza03, Andrew Gray, GreenC, Levivich, SnowFire, FaviFake, Blueboar, ~2025-35132-06, Swordman97, Rutebega, SunDawn, Stifle, Toadspike, Andrew Davidson, Alpha3031, Chipmunkdavis, Coining, Otr500, Andrybak, Andrew Gray, and Wbm1058: Szmenderowiecki (talk · contribs) 16:20, 29 January 2026 (UTC)

@Szmenderowiecki This is just a bad RfC which is probably why people don't respond to it. And I don't really see the point. What are you hoping to achieve? We already had this discussion a short while ago. Polygnotus (talk) 16:25, 29 January 2026 (UTC)

This is just a bad RfC - in what way? I'm looking at WP:RFC and I don't see your point. You can disagree with the premise (which I guess you will based on your prior comments) but it doesn't make it a bad RfC.

We already had this discussion a short while ago. - addressed in the table.

which is probably why people don't respond to it - We are just two hours into the discussion, so how do you know?

What are you hoping to achieve? - minimum accessibility standards that will cause at most moderate performance issues for all users wanting to engage in Wikipedia discussions; also stopping quarrels about archiving preference. Szmenderowiecki (talk · contribs) 16:34, 29 January 2026 (UTC)

@Szmenderowiecki

This is just a bad RfC in what way? you don't have a clear understanding of the situation so any proposal you make is hindered by that.

We already had this discussion a short while ago addressed in the table. Maybe, but this is still a problem.

which is probably why people don't respond to it We are just two hours into the discussion You are, that is my point, but" we" as an alleged community are not "just two hours into the discussion"

minimum accessibility standards that will cause at most moderate performance issues that proves you don't understand the problem. Read what I wrote in that earlier discussion. Then think about it for a day or two. Then, if you have a good idea you can propose it. But starting an RfC and pinging a bunch of people when you haven't really understood the problem, the various factions in the debate and the upsides and downsides of the various options is unlikely to lead to a good result.

I don't think there are archive bots that dynamically adjust aggressiveness of archiving. This would be ideal but require a bit of coding I simply do not have the brain for, and I think this will actually be hard to code well, and will be likely too much effort for someone who is not paid for the coding. But you didn't ask anyone... You don't have to be a nerd to have a good idea, but when talking about (talk) page archiving it does help. Polygnotus (talk) 16:41, 29 January 2026 (UTC)

This might sound a bit too aggressive. Aaron Liu (talk) 17:32, 29 January 2026 (UTC)

I may or may not have resting bitch face in English. In 2003 Brooke Vibber wrote: There's no theoretical maximum, but our server only has 2 gigs of memory, so don't push it please. ;) In all seriousness though, I very strongly recommend against letting articles grow beyond 32 kilobytes.[2] Server. Singular.

We may need to write a userspace essay explaining how long this topic has been debated for and how complicated it is so that we can stop new users who aren't nerds wasting a bunch of everyone's time. Note also [3] and [4] and [5], this is not the first time. Polygnotus (talk) 19:55, 29 January 2026 (UTC)

Wow, I missed that before. This whole, huge, indigestible discussion no longer looks like a good-faith effort to improve editor collaboration by making talk pages more generally accessible (a totally defensible goal per se). It now looks to me more like a way to harass an editor in a fit of pique after previous attempts to directly interfere with their chosen archiving one-on-one were rejected and undone by admins, lightly concealed as a broad, improve-accessibility discussion. Only, this time, their fit of pique is not only harassing one user, it is wasting the time of many users. This is completely unacceptable. This isn't ANI, but by raising this discussion, Szmenderowiecki's behavior should be open to scrutiny as well. If there were a proposal on the table to ban Szmenderowiecki from starting a discussion on archiving or pagesize for eighteen months, I would vote to support. Mathglot (talk) 07:16, 1 February 2026 (UTC)

The first link is irrelevant to this discussion, the second link is the DRV, the third is literally a companion discussion to DRV. I am using all forums for their intended purpose.
Mathglot I started this discussion because it became apparent to me at DRV that there are no good procedures to enforce talk page accessibility, which I believe are needed. This is the only reason I was starting this discussion. I am amazed that some editors dismiss my concerns as fake.
I urge you to strike your accusation of me trying to harass editors. If you insist or want to go the route of banning discussion, go ahead, but that accusation, and that of any other editors suggesting I'm trolling or creating the concern out of thin air, will also be brought to light in appropriate forums if need be. Szmenderowiecki (talk · contribs) 08:57, 1 February 2026 (UTC)

I am sorry, but that is my honest impression, right or wrong. If I were in your shoes, I would comment anywhere but here, as it will only draw more attention to your actions. In my opinion, you are skating on thin ice, and the more attention paid to this, the more likely it is that it will cause trouble for you now, or at some later date. You are of course always welcome to raise accusations you view as inappropriate at the appropriate forum, which would be my Talk page, followed by WP:AN/I if you don't get satisfaction there. If you just want to vent, I invite you to my Talk page. I can be very conciliatory, and will listen to what you have to say. Maybe it will make you feel better. Good luck, Mathglot (talk) 09:40, 1 February 2026 (UTC)

I'm not going to be the one to escalate, so the ball is in your court. I don't think any disciplinary intervention is necessary for any party here, for now, at least if you strike that accusation. I'm not going to be the one who shouts WP:UNCIVIL at the slightest hint somebody makes a faux pas and the one who drags you to ANI. I've worked jobs where people assaulted me every once a while and where I learned a lot of very interesting things about who I am and where I need return to (as a naturalised immigrant). I managed to still maintain a poker face most of the time and grow somewhat immune to these attacks. Bickering strangers on the internet are several pay grades below that.
But I will mount a defence if necessary. Or remain silent where I believe it will be best for my case. Szmenderowiecki (talk · contribs) 09:53, 1 February 2026 (UTC)

I have no wish (nor time) to escalate, so we agree on one thing at least. Sorry to disappoint, but I will not strike, as it represents my honest opinion. I agree that remaining silent is best for your case. I should add that I did not realize you were an immigrant and I am very impressed (and envious) of your command of English, which to me, appears to be of native-speaker level. I wish my abilities in foreign languages were as good as yours. Kudos! Mathglot (talk) 10:38, 1 February 2026 (UTC)

Szmenderowiecki, Actually, I will strike under one condition: I strike my comment, and immediately following that, you withdraw and {{hat}} this proposal as "|status=withdrawn". That would be to the general benefit of everyone. Do you accept? Mathglot (talk) 10:50, 1 February 2026 (UTC)

If there is a viable alternative proposal, I will withdraw this one. I am in works of discussing another one proposed by Sapphaline. This is independent of my request to strike/remove.
PS. For the future, I have a thing to say: editors are always responsible for their edits. It's only your decision because you made the claim. I don't want it to be on you, and I'm not going to complain myself. But if you stand by your claim, I reserve the right to consider it if necessary for any appropriate defence against any allegations. This is because if you have that honest opinion which you stand by even upon request to retract, this should imply that you have good evidence to back it up, which will stand upon independent scrutiny and presentation of all exculpatory evidence. And I want that possibility to rebut any point of that potential complaint, hence the "reserve the right".
I still appreciate honesty, even if it occasionally breaks rules of what discussion should look like. Szmenderowiecki (talk · contribs) 14:02, 1 February 2026 (UTC)

also WP:RFC specifically states "neutral and brief", this is neither. Polygnotus (talk) 16:46, 29 January 2026 (UTC)

you don't have a clear understanding of the situation so any proposal you make is hindered by that - sorry?

that proves you don't understand the problem. Read what I wrote in that earlier discussion. Then think about it for a day or two. Then, if you have a good idea you can propose it. Read all these discussions, understood them well, and I disagree with your premise. You can disagree with mine. You can think of it as a terrible idea but it doesn't mean it becomes a bad RfC question.

But you didn't ask anyone... You don't have to be a nerd to have a good idea, but when talking about (talk) page archiving it does help. And no one came up with that idea at the idea lab, where you could have participated and told me this was a terrible idea and maybe we should do something else instead... That discussion was up for almost a month in a high-traffic forum. You could have proposed that idea yourself, the idea I didn't have before that comment. Why nobody thought of that before? Why do you blame me? For what?

neutral and brief - you just seem to be opposed to holding the RfC because you are satisfied with the status quo rather than having problems with neutrality and brevity. Because you don't say how it's not neutral. It's not the shortest statement but it's definitely not out of place for RfCs I witnessed in terms of size. Szmenderowiecki (talk · contribs) 16:54, 29 January 2026 (UTC)

@Szmenderowiecki you just seem to be opposed to holding the RfC because you are satisfied with the status quo To me it seems to be the other way around. It looks like you disagree with consensus formed in the recent preceding discussions (which is allowed of course) and then started an RfC that ignores the opinions expressed in them. Combine that with a very long and non-neutral RfC statement and you got a bad RfC. Polygnotus (talk) 17:02, 29 January 2026 (UTC)

I mention that the way I read that discussion was that the 75 KB wikitext limit was removed, and that's it. Nothing more, nothing less. The question was not specific enough to say if that means no limits or maybe some higher limit or something else. That was a bad RfC, because the result's interpretation is ambiguous. And you know it because you engaged in that discussion extensively. Szmenderowiecki (talk · contribs) 17:12, 29 January 2026 (UTC)

RfC asks for the question to be neutral and brief. This is easy to fix; we would move the neutral and brief "Do you support these changes as presented in the table below? If not, which specific parts of the changes do you not like?" to the top. From time to time, RfCs include background information. See for example Wikipedia talk:Please do not bite the newcomers#RfC: Rewriting specific sections. Aaron Liu (talk) 17:31, 29 January 2026 (UTC)

What the hell is this, your idea of a "big beautiful bill"? I presume I was pinged to here because of my close of this thread. It seems you've disregarded my advice to start separate RfCs for article-talk and user-talk. I do not care to spend hours getting up to speed on what you're asking for – your ping was an annoying distraction when I'm trying to stay focused on tasks in my to-do list which require focused concentration. Pick the one change that you most want to make, and which you believe has a strong chance of obtaining a consensus, and start with that, please. I'm not a member of a political party who will just vote up or down on your big bill, based on how my party leadership tells me to vote, without even bothering to read the details of the bill. – wbm1058 (talk) 17:14, 29 January 2026 (UTC)

What the hell is this, your idea of a "big beautiful bill"? Trump aside, the proposal was up for a month on a high-traffic page. Why didn't you engage? I gave a list of ideas and anyone could have said the thing you say now. But no, I have to be pummeled at the start of the RfC because people don't bother to look at the very place intended for workshopping proposals. Why workshop them at all then?

I presume I was pinged to here because of my close of this thread. - no, that's because you posted in the Discussion : Recommended maximum talk page size part.

It seems you've disregarded my advice to start separate RfCs for article-talk and user-talk. As I said, I see no functional difference between these two. I am free to disregard your advice if I believe it's bad advice.

your ping was an annoying distraction when I'm trying to stay focused on tasks in my to-do list which require focused concentration - Jesus Christ, I didn't know that pings can make people so cross. You don't have to engage with it, you can come to it later if your task list is what you need. There's no need to be so worked up. Szmenderowiecki (talk · contribs) 17:28, 29 January 2026 (UTC)

This proposal has not been up for a month, you just started it today, hours ago. I have no idea what proposal was up for a month on a high-traffic page, but it's not this proposal. – wbm1058 (talk) 17:43, 29 January 2026 (UTC)

I agree that one ping is a non-issue. But wbm and Polygno are right to recommend reducing the number of options/changes an RfC proposes (see also Wikipedia:Writing requests for comment#Best practices). You definitely can do that if you think it's best, but if so, you should expect the possibility that most of the parts would be met with chaos, confusion, messy discussion, and disgrunt, especially if you didn't hash them out first: Half of your proposals were not put forward at your Idea Lab thread, especially the change from recommendation to enforced rule. Aaron Liu (talk) 17:44, 29 January 2026 (UTC)

I have no idea what proposal was up for a month on a high-traffic page, but it's not this proposal. The idea lab thread? At almost 1,500 watchers, 9K pageviews per month, you bet it's a pretty high-traffic area. Or at least one that people supposedly watch.

Ad Aaron Liu: A recommendation is unenforceable. I meant it to be specifically a rule. If I wanted to make it a recommendation, I would have said so, but IMHO there's no point to discuss a recommendation if there's no enforcement of the recommendation.

Who cares if something is recommended if I disagree with the recommendation and there's nothing against disobeying the recommendation? Same for essays: who cares about essays if anyone can say "essay is not policy/guideline, so leave me alone"? Anyone's understanding of terms like "reasonable", "substantial", "large", "slow", if not backed by specific numbers, is different. What is "slow enough"? Is this "reasonable"? Is this inconvenience "substantial"?

Some people say "this is against current practice". OK. Just because it's current practice doesn't mean it's good practice. Substitute "current practice" with "industry standard", and you'll see what I mean.

Unfortunately, untangling a single piece of it is going to be very hard. Presumably, for the sake of simplifying discussion, it's going to be the size limit. So let's look at it:

- People are still gonna edit war over archiving and that's a concern, expressed incidentally at the TPG.

- I read opinions from certain users that manual archiving is busywork, and I agree. Also expressed incidentally at TPG.

- Doesn't address lack of archiving on pages like ERRORS.

- Enforcing anything on user talk pages without an impartial and specific mechanism is going to be hell.

- People are gonna ask: why only enforcement on user talk and not any talk? Well, that enforcement was supposed to be archive bots/logs (mostly) but you insist this be one proposal at a time, so I can't propose this. Unfortunately certain proposals only work in tandem.

- Empty talk pages are a concern for some users, and I agree with their concern - and it was discussed at the maximum talk page size discussion of all places, not minimum. So I felt it was necessary to address. I again get pummeled for that.

(Contrary to some suggestions, I don't mean this proposal as a snide against EEng. EEng's page was not the first time I had this problem, I just didn't speak up. This is a general applicability rule. Any talk page about 500 KB is absolutely terrible for my browser just reading it, pages of the size of ANI are terrible editing them). Szmenderowiecki (talk · contribs) 18:24, 29 January 2026 (UTC)

You'll notice there are very few guidelines as rigid as what you propose.

Ease of implementation is always something policywriters need to consider. Min threads and max archive size are going to be hard to implement.

It is great that you've identified and analyzed issues and are willing to put in the work or fix them. But often, if you put them forward in an RfC—the process for attracting as many participants as humanly possible—without consulting through non-RfC discussions, you are going to attract as many participants as humanly possible that have a lot of questions. Aaron Liu (talk) 22:32, 29 January 2026 (UTC)

This proposal does not say anything about min size. minthreadsleft or similar exist in both of the used bots. Max size is easily implementable by something like this: If pagesize exceeds, say, 200KB, archive the oldest discussions whose last comment was at least a year ago; if still exceeds, decrease by 30 days until you get within 200KB, but not below 10 days. Or something like that.
But often, if you put them forward in an RfC—the process for attracting as many participants as humanly possible—without consulting through non-RfC discussions the problem is that I have consulted my proposal. The gist was always there: mandatory automated archiving and limits on all pages intended for user communication. There may be an detail that I have not, but I consulted most of it. And people are shouting me down for this. Szmenderowiecki (talk · contribs) 23:00, 29 January 2026 (UTC)

Yes, I'm talking about min threads. You're not going to stop the extremely-popular manual archiving by just forcing changes to the most popular bots. It will also be hard to set up automatic archiving everywhere.

I'm sorry, but I did not see where you mentioned a, c, f/g, the change from "should" to "force", or the 50%/90% reduction in the page size limits. I did not see where you mentioned mandatory automated archiving at all. Aaron Liu (talk) 03:36, 30 January 2026 (UTC)

It will also be hard to set up automatic archiving everywhere. Nope, all it takes is a bot function that automatically introduces e.g. {{subst:setup auto archiving}}, when the first talk page thread is created. It is going to default to the loosest parameters, but you can change them manually later.
For existing pages, check for existing archive, if there is none but there are talk page threads, automatically deploy. I'm not a coder but pasting a text if a certain piece of text exists isn't a complicated piece of code we are speaking of.

I'm sorry, but I did not see where you mentioned a, c, f/g, the change from "should" to "force", or the 50%/90% reduction in the page size limits

• a was originally expressed as the minimum size limit (it was 500 KB HTML, but it could be 200 or 300 or even 100, so long as it's not 0. The pseudocode part at the bottom included the minkeepthreads parameter. I got feedback that the code was "too complicated", so I simplified it. I was never that part was a bad idea.
• c (mandated archiving) is literally the second bullet point in the VPI.
• f is the seventh bullet point
• g was discussed along the way.
• the change from "should" to "force" Equivalent in meaning for purposes of guiding user behaviour. If "should" had been supposed to be a non-binding recommendation, the discussion would have made no sense.
• the 50%/90% reduction in the page size limits. I don't know what you are talking about.

Szmenderowiecki (talk · contribs) 10:36, 30 January 2026 (UTC)

Szmenderowiecki, is it then your position that mandatory automated archiving would apply to all user talk pages, including those currently archived manually? As an example, my user talk page, now nineteen years old, is manually archived and always has been. If your proposal achieves consensus would I have to give up manual archiving and submit to obligatory bot archiving? What about users who manually archive by theme (or other algorithm of their choice) instead of last comment age? Oblige them to switch as well? Mathglot (talk) 03:49, 30 January 2026 (UTC)

Read the proposal carefully and you will get the answer. Short answer: no, do whatever you want so long as you keep within the size guidelines out of your own accord. If you refuse upon request, or you have trouble keeping the maximum size long-term, only then it becomes a yes.
Archiving by theme will not be possible because we don't have bots that guess the discussion's context and sort discussions into buckets according to what you are talking about. If an admin wants to manually sort their discussions, fine, but I don't expect admins to do that because they likely won't hve the time and their job is not to micromanage others' talk pages.
If you don't want this to happen, keep within your 1200 KB HTML and you'll be golden. I'm upfront that this is a restriction on user autonomy, but user autonomy, just like generally being allowed to edit, is not a right, it's a convention. If your user autonomy makes others suffer, you are abusing it. Szmenderowiecki (talk · contribs) 10:46, 30 January 2026 (UTC)

Any talk page about 500 KB is absolutely terrible for my browser just reading it @Szmenderowiecki: Three quick questions. What browser are you using, how much RAM do you have, and how fast is your download speed? This is because I think the problem here may be your device, whatever it may be.

This is not to say that people should intentionally keep talk pages large just for the fun of it; I'm just saying that there may be technical limitations on your end that are affecting your ability to read really large pages. I can still open EEng's 972k talk page in Safari on my iPhone 11 with 140 other tabs and 24 other apps open, probably because iOS is really good at memory management and frees up memory from inactive apps and Safari tabs. Trying to edit EEng's talk page, however, is a different matter... SuperPianoMan9167 (talk) 23:19, 29 January 2026 (UTC)

Sure: Chromium 143, 8 GB RAM, 25 Mbps download on WiFi. RAM is 100% not an issue because I have tons of spare RAM without forced cleaning, neither is download speed because the whole source code should be downloaded within at most a second, shorter than the rendering itself. Everything works pretty fine with these parameters on any web site until I get to gargantuan talk pages on Wikipedia. Or try to edit big talk pages.
It's not a "me" problem. Szmenderowiecki (talk · contribs) 23:31, 29 January 2026 (UTC)

Okay. I figured as much but I still wanted to ask.

I admit that I have sometimes experienced issues on very large pages; I've gotten the "This webpage was reloaded because a problem occurred" message (which is Safari's way of telling you that the page crashed because it ran out of memory) on large talk pages before. When I scroll down a very large page, it usually takes a couple of seconds for the page content to appear. And of course, the sheer size of these pages makes them difficult to navigate on mobile (Minerva skin helps to make this less tedious). SuperPianoMan9167 (talk) 23:41, 29 January 2026 (UTC)

Minerva skin looks shit on desktop, and besides readers are very likely not aware that they can change the skin using the "Mobile version" link, and quite a few may not be even aware of the possibility.. So long as we allow IP editing, any reader may become an editor with no warning. Any IP who wants to post on any noticeboard or talk page and the noticeboard is 500K+ is likely to abandon the effort due to the lags. This is unacceptable Szmenderowiecki (talk · contribs) 10:50, 30 January 2026 (UTC)

• My understanding is that there's no standard way of archiving pages and so there's a mish-mosh of bots and tools. I've evolved my own way of filing my talk page but it's too manual for my taste. Anyway, I have a question. What I'd really like is a simple method of moving a section from one page to another. This is the way that email and other documents are usually filed -- you move them to folders. Is there such a thing in Wikipedia? Andrew🐉(talk) 17:30, 29 January 2026 (UTC) (edit conflict)

  I believe the closest we have is one click archiver, but in theory it should be possible to develop something that can do a similar action but to a manually defined page. CMD (talk) 03:34, 30 January 2026 (UTC)

• BTW, every time I've tried to say something in this discussion, I've gotten an edit conflict. Wiki software is really poor at doing user communication when compared to just about everything else. Andrew🐉(talk) 17:34, 29 January 2026 (UTC)

  Try c:User:Jack who built the house/Convenient Discussions.
  Both moving topics and automatic retrying after edit conflict sure included. Aaron Liu (talk) 17:47, 29 January 2026 (UTC)

  I've heard of that tool before but it seems too complex for my needs and I gather that it is resource-hungry. Looking at its talk page, it seems that there's an incompatibility which is going to break it. I've seen many useful tools broken as a result of change and that's why I think all such infrastructure and interface should be managed centrally by the WMF. Andrew🐉(talk) 23:19, 29 January 2026 (UTC)

  I daily-drove the parser migration tool (which allows you to set your default parser to parsoid) in late 2024 and had no issues with CD (in fact, little issues at all other than the reduced server caching increasing page load times). I just checked again and everything works. @ChildrenWillListen probably had a configuration issue.

  There's been many calls for WMF to maintain promising infrastructure. WMF couldn't even install it. (slightly clickbait, but I couldn't figure out a better way to summarize this, sorry) Aaron Liu (talk) 03:31, 30 January 2026 (UTC)

  sounds like they should hire some engineers then, I hear there are a lot of people looking for work Gnomingstuff (talk) 20:04, 30 January 2026 (UTC)

  You mean the same engineers who built out the internet to give us a postliterate society where everyone is addicted to screens, where people no longer read books, where society is more susceptible to disinformation and propaganda, and who are solidly against the humanities and democratic values? Those guys? Viriditas (talk) 22:47, 31 January 2026 (UTC)

• Please keep in mind about mobile users, who because of such small screen size have to contend with extremely difficult scrolling of pages with long discussions or too many threads (especially as the font size for thread headings can be relatively large ~2026-63332-0 (talk) 17:54, 29 January 2026 (UTC)

  ~2026-63332-0 consider going to WP:VPI and proposing that the WikiMedia software automatically provide page nav links 'skip to top' and 'skip to bottom' for moibile users, when the page size or number of threads is greater than X (user preferences-configurable). Then, after you get some feedback and some kind of working consensus there on what might be useful and have some support, take it to the meta:Community Wishlist and register your wish. Mathglot (talk) 19:34, 29 January 2026 (UTC)

  Minerva skin already provides a "Latest comment" link at the very top of the page and in the header of each section, which is very helpful. In fact, it is so helpful that I sometimes find it easier to comment on talk pages on my phone than on my computer in Vector 2022.

  (Yes, I use Vector 2022. Experienced editors may now publicly shame me. I've been reading articles here for long enough to remember a time when it didn't exist yet. I also (gasp!) used VisualEditor when I started editing, but I eventually quit using it because I find that writing wikitext directly is much faster, especially on mobile where I don't have access to keyboard shortcuts.) SuperPianoMan9167 (talk) 23:52, 29 January 2026 (UTC)

  That's good to know; that means that the code to do this already exists, and porting it to other skins should not be that difficult. I would say in response to temp user 63332, that either in addition to, or instead of the Community Wishlist idea, you could file a Phabricator ticket requesting it as an enhancement. (I think you have to be registered, but make a request at WP:Help desk and I am sure someone could help you with that.) Mathglot (talk) 02:32, 30 January 2026 (UTC)

  There's no need for a Phab ticket. Go to Special:Preferences#mw-prefsection-betafeatures and turn on "DiscussionTools". Go to Special:Preferences#mw-prefsection-editing-discussion and make sure that "Show discussion activity" is enabled.

  If we want this enabled by default, then an RFC and a config change request would be enough. WhatamIdoing (talk) 20:02, 31 January 2026 (UTC)

• CapnZapp I'm confused about your order of opposes in justifications.
  • The A part refers to what, the introductory statement or the mandatory archiving? Mandatory archiving does not speak about user talk exemptions or even user talk at all in the justification. User talk is specifically exempted, end of story. What are you talking about?
  • The B part presumably refers to specific limits. I don't have a problem with EEng, I do have a problem with his talk page, as with hundreds of others I cannot easily read, interact with, let alone edit. Also, good luck.
  • C (max archive interval) misunderstands the proposal. The 10 day limit is only meant to cover high-traffic pages ("likely to routinely exceed the maximum size limit"), and that's additionally explicit in the last sentence.
  • D is not substantial to this discussion, I could have edited this myself.
  • E: Why 4 minimum threads specifically? I had opinions that 1 is the number. Some prefer 2. Some prefer 5. We can discuss it.
  • F: Impossible to discuss in separation of B because there are no maximum user talk page size regulations right now, so such change would be meaningless. I'm not sure what I'm poisoning by opening this discussion.
  • H: Possible to discuss at the archive bot pages, but will likely discourage people from using bots. So pretty much impossible to discuss without A because it's pointless. It is meant to be the automated enforcing mechanism. Szmenderowiecki (talk · contribs) 18:48, 29 January 2026 (UTC)

    I explained at the start. Basically, I went through the table, creating a point for each row. Only once I was done did I realize you failed to match your a-g to your table. CapnZapp (talk) 18:54, 29 January 2026 (UTC)

My comment before was that Endorse This is the single stupidest thing Iv ever seen be discussed on here. I'm legit laughing my tired ass off, and despite having zero memory of writing that(it was 3AM, and I was coughing up a storm). I still stand by it and it's even more funny that this was made seemingly solely because of EEng.

Has anyone ever considered that if we weren't such assholes about it, he might be willing to archive more often? Or ask him to add skip to top or bottom buttons like iv seen on a few other user talkpages?

We have had this discussion so many times, it always ends the same.

If the page starts crashing browsers, bring it up to him, otherwise, just wait the extra two seconds for it to load. And use the edit section function.

I'm against all the points. LakesideMiners^{Come Talk To Me!} 21:18, 29 January 2026 (UTC)

@Szmenderowiecki, what's your plan for handling individual discussions that exceed 200K? For example, Wikipedia:Requests for comment/Rollback of Vector 2022 is 910K. Wikipedia:Requests for comment/Merging merge discussions with AfD is a currently active RFC that is over 230K so far. WhatamIdoing (talk) 22:06, 29 January 2026 (UTC)

From the table: Single discussions split into their own pages due to size considerations are exempt from internal archiving but have to be searchable through archives of the page they were split from.

There might be creation of subpages due to size considerations, but I understand that there may be discussions with huge turnout wbhich cannot be split, or pages with several questions that are interconnected ando so would be inadvisable to split. So there's no dedicated solution for this problem. Accessibility is an issue due to poor performance, but any other solution would be worse. Szmenderowiecki (talk · contribs) 22:13, 29 January 2026 (UTC)

So firm rules, except for exceptions. WhatamIdoing (talk) 22:47, 29 January 2026 (UTC)

IMHO better than no rules at all. Making a carveout where necessary is a sacrifice I'm willing to make. Szmenderowiecki (talk · contribs) 22:49, 29 January 2026 (UTC)

I'm here because of the ping. I don't like anything about this proposal, but I do like the comparison made in this discussion to the so-called Big Beautiful Bill. --Tryptofish (talk) 00:17, 30 January 2026 (UTC)

You gave the reason yourself above (@23:10, 29 Jan) why this Rfc was unnecessary and a gigantic waste of time; quote:

We already have a recommendation [about] [l]arge talk pages...

Precisely. There are different levels of obligation and administrative enforcement depending on how serious a particular kind of violation is, which is why adding copyrighted material to a Wikipedia article or libeling someone is going to get you in hot water faster than conflict of interest violations, which in turn will get you in trouble faster than WP:Manual of style violations.

As you say, we already have a recommendation about this, but apparently, your opinion is that the existing recommendation doesn't have enough teeth in it on the enforcement side, hence all the draconian language trying to sharpen the teeth. But this violates the sense of proportion. There is a reason that libel and copyright get more attention and stricter enforcement. No doubt in the thicket of Wikipedia regulations, improvements can be made, but we do not want very large talk pages to have the kind of enforcement wording or response that libel does; it is way out of proportion to the seriousness of the violation (if it is even deemed a violation at all). Nothing in your Rfc proposal is an improvement over current guidelines imho, imperfect as they my be; rather, they would make page and archiving guidelines worse, and cause additional strife among editors, perhaps resulting in enforcement discussions against users with long talk pages. Is that really the hill you want to die on?Mathglot (talk) 02:58, 30 January 2026 (UTC)

Precisely. There are different levels of obligation and administrative enforcement depending on how serious a particular kind of violation is
You may disagree with me on this point, but overbearing talk pages that barely load and are all but impossible to edit are pretty much a serious violation on a website whose core tenet is enabling editing and good-faith discussion by anyone interested in the topic or in a contributor at any time. If the "anyone can edit" (=have technical tools to edit) part in "Wikipedia is a free online encyclopedia that anyone can edit" can be rendered effectively moot, then it should not advertise itself as such. If Wikipedia effectively forces users to switch from not-clearly-outdated devices to view/edit content, it is no longer anyone who can edit.

Also, the enforcement for libel and copyright violations is potential blocks as well. This rule is not meant to create another means to block someone because this can be resolved without blocking anyone. And I wrote just that in the reasons. So despite the seriousness of obstruction of talkspaces, it does not escalate to revocation of editing privileges. Szmenderowiecki (talk · contribs) 11:13, 30 January 2026 (UTC)

"Overbearing talk pages that barely load and are all but impossible to edit" would be a problem if they existed, but they don't. As another user said, "Some of the devices I use to browse the web are so ancient that they struggle to load most pages on the web, but I was still able to load User talk:EEng, scroll through the sections, and click edit on a section of my choice in about 30 seconds."

And even if they did exist, the rational approach would be to go to ANI, document the problem, see what happens when others try to replicate it on similar hardware, and if the problem is real deal with that one page. (If anyone does this, ping me. I have a number of ancient computers running ancient browsers available to me) --Guy Macon (talk) 03:16, 31 January 2026 (UTC)

Also, while it might be great if everyone could easily use any device to leave messages at all talk pages, forcing compliance with a uniformity rule would make Wikipedia a nastier place with the side effect of encouraging rule-pushers while discouraging a variety of editors. Johnuniq (talk) 03:50, 31 January 2026 (UTC)

Also, the difference is that libel can get you sued and long talk pages can't. Gnomingstuff (talk) 04:01, 31 January 2026 (UTC)

Guy Macon, is it that you insinuating that I am lying my ass off about the problems I have with loading the pages, do you pretend to know better than me how my device works, or are you saying "not a problem for me, so deal with it"? My device specs are public knowledge at this stage.
Some of the devices I use to browse the web are so ancient that they struggle to load most pages on the web, but I was still able to load User talk:EEng, scroll through the sections, and click edit on a section of my choice in about 30 seconds
A lot to unpack here:

• We don't know what the specs of that device that loaded the page for 30 seconds were, and what software they use.
• We don't know if that device is one of the "ancient" devices that the user uses for browsing the web (what is "ancient"?). What they said does not exclude the possibility that they tested it on an iPhone 16 Pro or some modern PC for $2000+.
• We don't know what the "other pages" are.
• 30 seconds to be able to interact with a page element is absolutely unacceptable performance. Anything over 4 s of basic rendering (LCP) and 500 ms of response between click and action (INP) is poor performance on Chromium-based browsers. That user may put up with it but there's a reason Google says it's poor performance. If I were a random user I would have never tried to interact with that page again. This is a problem.

the rational approach would be to go to ANI, document the problem, see what happens when others try to replicate it on similar hardware, and if the problem is real deal with that one page
Or maybe, just maybe, avoid all this dragging to ANI unless absolutely necessary and document a procedure that everybody knows, and everybody is aware what happens if it is not followed? And not bog down in discussion on whether your device sucks, on whether you should change your device, lifecycles, operating systems, differences in browsers, popular userscripts you choose to run and so on? I thankfully see, hear and read well, but there are folks who have to read Wikipedia with a page reader. Folks who need high contrast because they don't see that well. On Chrome, this is done via extensions. But these extensions will struggle even worse on huge pages. Which is a reason you don't do huge pages unless absolutely necessary.
(OK, you'll say, this concerns like 1% of readers/users, so whatever, suffer. Well, modern public transport has Braille and wheelchair ramps not because there are a lot of blind/physically disabled people but because they also deserve the service. It generally features low-floor vehicles not only for these people but for anyone - whether you are a normal passenger or you carry a big bag of groceries home or maybe a bicycle or a stroller. You could have the bare minimum of seats for the frail to cram as many people as possible within a given budget for new vehicles - after all, most people can stand up for 15 minutes just fine - but that doesn't normally happen because passenger comfort is also a valid consideration.) Same logic applies here.
forcing compliance with a uniformity rule would make Wikipedia a nastier place with the side effect of encouraging rule-pushers while discouraging a variety of editors.
One by one:

• nastier place: in which way?
• side effect of encouraging rule-pushers: where possible, make rules that are clear, unambiguous and tight so that they do not leave the possibility for wikilawyering. Simple as that.
• discouraging a variety of editors - well, the inaccessibility discourages me from engaging on Wikipedia because I have that info in the back of my head that I will not be able to edit certain pages without some non-standard hacks. And I'm pretty sure I'm not alone, but I'm also pretty sure not everyone would want to search for said hacks.
• Also, the difference is that libel can get you sued and long talk pages can't. POV pushing is a serious violation of Wikipedia's rules, but will not generally get you sued. Same for obstruction of discussion process. I don't see your point.

Szmenderowiecki (talk · contribs) 07:56, 31 January 2026 (UTC)

@Szmenderowiecki

Plain text rendering is extremely fast. Even large amounts of text render quickly. The bottleneck on Wikipedia is almost always JavaScript, especially scripts that process the entire page. So limiting the amount of plain text makes no sense.

Loading large external resources (images) can slow things down, but usually those get cached so they would only be slow once. So in your case the reason is JavaScript.

1. Find a page on which the problem is reproducible (ANI?)
2. Visit that page in an incognito (sic) window, without logging in. Does the problem still occur?
3. In a non-incognito window: disable your scripts and DiscussionTools in preferences, then try again. Does the problem still occur?
4. Enable your scripts and DiscussionTools again and capture a performance profile (not the HAR file) and post a link.

Polygnotus (talk) 11:41, 31 January 2026 (UTC)

I will tell you the results:
Point 2: Loading pages like EEng's make browser visibly struggle upon rendering even when logged out. Just slightly less time than in my JS configuration. Impossible to say if editing is impacted because my editing environment in source is the 2017 wikitext editor and it's a small box when logged out. Also, I do feel the need for syntax highlighting to better see the, you know, syntax. My eyes get lost in the sea of monotone black text.
Point 4: The files have like 50 MB each, so I'd need to make sure you will have to be able to download these. I tested this on just reading User talk:Tryptofish (870 KB wikitext at the moment). The summary results I got were these:

Painting 10,280 ms
Scripting 4,300 ms
Rendering 4,116 ms
System 2,050 ms
Loading 285 ms

with all scripts but Convenient Discussions enabled; and I have a separate batch for Convenient Discussions enabled - which did eat a lot of resources but is also clearly superior to current talk design IMHO. The browser could not load the right-click menu without significant delay while all of this was happening.
On Convenient Discussions disabled, LCP 2.56 s (needs improvement, <2.5 s for good), Cumulative Layout Shift (CLS) 0.91 (poor, <0.25 for needs improvement, <0.1 for good), Interaction to Next Paint (INP) 600 ms (poor, <500 ms for needs improvement, <200 ms for good)

But all of that is besides the point. An editor does not have to disable the JavaScript tools they feel they need for editing just to accommodate for excessively long talk pages. You have it backwards. If WMF says the software option is good enough for choosing directly in my preferences without any caveats, I trust that the software is ready to be used out of the box. That's the default expectation of any new user, and it's how it always should be. The JS may be buggy, but that's not the issue of buggy JS, at least not on my side, because I can replicate all the same issues while logged out. And even then users are not expected to be debuggers or know how a certain piece of code may impact performance. Maybe if you get the template editor or the interface administrator bit. But that's not for the vast majority of users.
I am used to the environment I edit in and it doesn't cause me much problems for 99.9% of my use cases. I don't have to change it because of the 0.1% of the times when I need, or hell, choose to land on long talk pages, that's ridiculous. Also, there's a brilliant public service announcement by the government of Wales on disability that illustrates my way of thinking - why don't you just raise the roof if you can? Or, in this case, why don't you make the pages uncluttered enough so that any user can answer? The roof job may be expensive but the uncluttering isn't asking for much. Szmenderowiecki (talk · contribs) 14:00, 31 January 2026 (UTC)

@Szmenderowiecki Interesting, thank you. I can download files up to ~20tb in size.

It looks to me that the problem is not the amount of plain text (as I predicted). The problem is the amount of Document Object Model elements.

Every piece of a webpage, each paragraph, link, button, image, or heading, is a DOM element.

The issue is that talk pages contain many DOM elements: signatures, timestamps, indents, etc.

So if you want to limit something it should be the amount of DOM elements on a page, not the amount of text.

And the situation wouldn't be so bad if DiscussionTools didn't add so many DOM elements per comment. Even when you aren't logged in.

Would you be willing to share some data with a WMF nerd? I may be able to find someone who can further diagnose this problem, and work towards a fix.

It won't be automated archiving of all pages, but maybe drastically reducing the amount of DOM elements added by DiscussionTools.

@Quiddity (WMF): probably knows who to ask. @Quiddity we need someone who can check why long usertalkpages render very slowly for Szmenderowiecki. It is probably/possibly DiscussionTools related. Do you know someone who can look at a performance profile and diagnose the problem? Thanks, Polygnotus (talk) 15:24, 31 January 2026 (UTC)

DOMs are in large part generated by text you and other editors type. Too much DOMs is usually a problem of the page and not the user who tries to load the page. If the page is user-generated, then it becomes the responsibility of the user(s) who contribute to that page, and to maintainers of the engine rendering that page, to make sure the amount of DOMs does not impact user experience.
The meaning of DOM is not also something we typically expect from a regular user to know about. They just expect the website to work.
DiscussionTools were disabled because I use Convenient Discussions, which is incompatible.
WMF can contact me directly for inquiries at any time. Szmenderowiecki (talk · contribs) 15:55, 31 January 2026 (UTC)

@Szmenderowiecki DOMs are in large part generated by text you and other editors type. DiscussionTools adds a whole bunch of DOM elements per comment. About ~8. If you want to we can make a test page that contains the same DOM elements but no text and you'll see it load slowly on your computer.

It is the responsibility of the WMF to deal with performance problems. Quiddity has over 2 decades experience on Wikipedia and started working at the WMF in 2013. They'll know who to ask.

DiscussionTools were disabled because I use Convenient Discussions, which is incompatible. Unfortunately DiscussionTools still adds those DOM elements to the page, even if you have it disabled and even if you are not logged in. Polygnotus (talk) 16:02, 31 January 2026 (UTC)

Irony above: "This page is too big. Excessive page size can cause accessibility problems for some editors. Please temporarily speed up the page archiving rate or split large discussions to separate subpages" ~2026-68406-1 (talk) 15:19, 31 January 2026 (UTC)

I have a 4Mhz (That's megahertz, not gigahertz) Z80 running CP/M and Fusix that communicates at 9600 baud. It can display and edit text-based discussions of any length on USENET or BBSs lightning fast -- no need to limit discussion size. If computers that are thousands of times faster than that are struggling, the obvious answer is to talk to the WMF and ask them to look at what they are adding to the text. --Guy Macon (talk) 17:38, 31 January 2026 (UTC)

I mean, any website would load well, whatever its volume, if it looked like The Motherfucking Website. It could probably run on a potato - but that's not really the point. In 2026 I'd expect at least this or this or this or this.
I'm not saying there isn't a room for code improvement (although I don't know if it's true) but if the suggestion is that I have to disable certain in-built features just to be able to view/edit large pages, that person also has it backwards. Szmenderowiecki (talk · contribs) 21:24, 31 January 2026 (UTC)

If you want a fun view into the alternatives, the debug page for EEng's talk -- which reformats it into a far more "modern" experience -- is worth viewing: https://en.wikipedia.org/wiki/Special:DiscussionToolsDebug/User_talk:EEng

I'm actually sort of curious whether you feel it performs better for you once you get to the point of actually scrolling around. Not really the initial load (it's not a useful comparison because it's less cached by the parser which slows it down, and it doesn't actually initialize DT reply widgets which speeds it up), but we were able to massively reformat the HTML used there in ways the talk pages community consultation didn't let us consider. DLynch (WMF) (talk) 15:37, 3 February 2026 (UTC)

Since talk page size and number of DOM elements is strongly correlated, then reducing talk page size would actually solve these problems. WhatamIdoing (talk) 20:11, 31 January 2026 (UTC)

I played around with document.querySelectorAll('*').length and that first assumption is incorrect. Reducing all talk pages to 10 bytes max does fix the problem so the second one is hard to disprove. Polygnotus (talk) 20:21, 31 January 2026 (UTC)

Polygnotus what's your plan if WMF says that everything is all right with the software or if they do not answer back your ping (presumably because they don't think that your suggestion of simplifying MediaWiki output is not worth the effort))? Szmenderowiecki (talk · contribs) 10:08, 1 February 2026 (UTC)

@Szmenderowiecki There are people who work at the WMF whose entire job it is to ensure that Wikipedia works properly on as many devices and in as many situations as possible. Quiddity works or has worked in the relevant team.

Help them help you, this is your best shot. There are people who have been tracking such stats for years and are interested in situations where the user experience is bad, so they know what to do and not do.

Quiddity is usually quite busy so we can leave a message on their talkpage in a week or so , if necessary. If you are polite and constructive they will help you. They may ask you some follow-up questions or do some tests so they can understand your experience better. Polygnotus (talk) 12:48, 1 February 2026 (UTC)

This doesn't really answer my question. Sorry if I'm not clear, so I'll rephrase it. While I disagree with their opinion, some users say that WMF alone is responsible for this, not users (my opinion is that it's a joint responsibility). Suppose that WMF/MediaWiki says any of the following:

• Our software works just fine, no bugs impacting performance detected, anything else?
• We fixed bugs that give a boost of 1.3% in loading time, but that's about all you will get.
• This is core functionality that we are not ready/willing to disable.
• We are introducing something new that will increase JS load, so no scaling back (given that webpages get more bulky over time and old devices, including, hopefully, mine as well someday, get changed - not a stupid thing to expect). We are not introducing any "lite" version of MediaWiki with just the bare minimum of DOM elements necessary for MediaWiki functioning and images linked instead of actually loaded. There will be no toggles.
• I agree with Szmenderowiecki that just because there's a technical limit to a page that our servers can handle doesn't mean that any individual page ought to push towards it because of UX issues. (They may even issue a recommendation in their user guides to the effect that a page is not supposed to be over X KB wikitext unless necessary)

In other words, suppose WMF/MediaWiki says it's actually not their problem, it's the problem of the community, because there's nothing/not much to fix on the software side (regardless of whether they tell the truth, because you are not going to get anything (more)). What happens next?

I will reiterate that if @Quiddity (WMF): or any other person who they believe will be competent to look into this issue wants to get feedback from me, they can ask all relevant questions and get relevant test results. Here, by email or otherwise. Szmenderowiecki (talk · contribs) 13:16, 1 February 2026 (UTC)

@Szmenderowiecki That is a very hypothetical hypothetical. They own the servers and they sign the contracts and they have the money.

So in theory they could decide to stop this whole Wikipedia thing and start a VIP dog walking business in Lithuania instead. There is nothing you or I could do to stop them.

Of course its a joint responsibility; I could easily install some Javascript shitcoin miner that will tank performance.

In reality at least some of the people who work at the WMF are nice, hardworking people who share our goal. That doesn't mean I agree with every decision ever. Quiddity was a Wikipedian for years before he started working at the WMF.

Since they share our goal they want Wikipedia to work well for everyone, on any device. That means they will at least try to investigate the situation.

Will you be happy/agree with the result of the investigation? Will there be a quick fix that solves the problem in a week? I do not know, but if we don't give them the information they need we can't complain about performance.

If they say "WONTFIX" then at least we know where we stand. I can look at your pc (if you let me), but not their servers. The WMF can see exactly what is happening on both ends if you let them. So they are in the position to fix this.

I am pretty certain they will at least look at the problem. I can't promise you'll be happy with what they do with that information because they don't work for me. They are independent beings with free will. And they are your best bet to fix this problem once and for all. Polygnotus (talk) 14:04, 1 February 2026 (UTC)

Listen, if MediaWiki suddenly runs 3x faster and the load time is no longer a nightmare, I think anyone will be ecstatic. I would still argue the switch is necessary on other grounds - for example, because large pages, even if they load OK, are hard to navigate. But at least the barrier to discussion will be not as severe.
So yeah, I wait for instructions from MediaWiki/WMF team. Szmenderowiecki (talk · contribs) 14:11, 1 February 2026 (UTC)

Just confirming that I have seen these pings and am passing along the request for technical investigation - [EDIT: Done at phab:T416247.] Quiddity (WMF) (talk) 20:04, 2 February 2026 (UTC)

(reply-to @07:56, 31 Jan) The performance report (parser profiling data linked at T416247) on loading the long user talk page you most complained about, shows a CPU time of 5.977 and real time of 6.714 seconds. This is only half again over the limit of 4 s you list as acceptable performance. If that is the actual load time for the worst Talk page at Wikipedia, then I'd say we were doing pretty darn well! I believe you wen you say that it is taking much longer than that for you to load the page on your hardware/software configuration, even if it takes much less time for others who have tried it on various setups, including ancient ones. Various conjectures have been raised about why that is, and the phab ticket will hopefully shed some light on that and lead to improvements for everyone. But making a proposal to limit Talk page size based on a misdiagnosis of a problem you are seeing and others do not, and then adding a draconian archiving proposal on top of it to be imposed on everyone based on the original misdiagnosis seems to be compounding error upon error, and not a valid proposal. I suggest we wait until we understand why you are getting the delay you are. And thanks for agreeing to provide input to the investigation tracked at the Phab ticket. Mathglot (talk) 03:55, 3 February 2026 (UTC)

There is irony and confusion. Why do we need more "rules"? Maybe this is putting the proverbial cart before the horse in some or most cases. Read #7- "Require pages that will likely routinely fall afoul of the maximum size rule to introduce a short archiving interval. Who has encountered pushback for achieving long talk pages? It seems any editor who finds a long discussion page (article talk) can archive older discussions.

At best, this is a terrible idea. At worst, it might be insane. It is too broad. Editors should not run out and buy a cart, then walk around looking for a horse. I would think suggestions or a number by consensus on page size limits would be found at Wikipedia talk: User pages. Help:Talk pages#Archiving states, On talk pages that generate significant amounts of discussion, old discussions are often archived to keep the size of the talk page at a manageable level. It states this can be done manually or with the help of a bot, but no suggested size. Although there is no link to the specific bot for "help", there is the "Main page: Help:Archiving a talk page". (TALKSIZE) gives some rationale, and Wikipedia:Talk page guidelines#User talk pages (maybe in the "Personal talk page cleanup" section) might be a good place to have some information on page size? It seems this may be important for new users or editors who would like some teeth and a place to point to. It is sort of a sad idea to attempt to teach someone to swim by just tossing them into the water. I think we should steer clear of user talk pages. -- Otr500 (talk) 01:10, 1 February 2026 (UTC)

A lot to unpack here: We don't know what the specs of that device that loaded the page for 30 seconds were, and what software they use. We don't know if that device is one of the "ancient" devices that the user uses for browsing the web (what is "ancient"?). What they said does not exclude the possibility that they tested it on an iPhone 16 Pro or some modern PC for $2000+. We don't know what the "other pages" are. I'm the user in question: that particular test was with an obsolete Android phone from circa 10 years ago. I tried it today with a 2015-model Raspberry PI 2 that I bought in 2016 for about $30 (now past end-of-life, has been sitting in a non-climate controlled junk drawer for years) and was also able to successfully load the page and open the editor (first load on that machine took about 10 minutes, but subsequent loads took ~30 seconds, indicating that the slow first load was due to media loading/caching, not byte size as targeted by this proposal). I don't claim to understand your computer setup better than you do, but I'm just saying that you seem to have far more powerful hardware than I do, on a better internet connection, yet you seem to be getting worse results. -- LWG ^{talk (VOPOV)} 02:22, 1 February 2026 (UTC)

OK, so that makes sense now. I mean, yes, obviously a Raspberry Pi will be less powerful than my computer. But contrary to what you say, my computer is not so bad as to be loading User talk:EEng for 10 minutes. It takes about 30-35 seconds on the first load (so no cache yet available) with browser freezing in the meantime or extreme difficulty to navigate any other part of the browser or the already rendered part of the page. With cache, this decreases to something like 15 seconds.
It still is unacceptable behaviour. Say what you will about Google but they know how to code shit and know about reasonable expectations of performance, and also know a bit about UX/UI as well. Szmenderowiecki (talk · contribs) 09:18, 1 February 2026 (UTC)

It still is unacceptable behaviour. Ok, so it sounds like your experience is pretty similar to what I get on my primary devices. It seems like the core point of contention here is: should Wikipedia users be obligated to maintain their talk pages to provide a Google-level industry standard UI/UX experience to all conceivable hardware/browser configurations? to which the answer of the community appears to be matching recent North American weather with a resounding no. -- LWG ^{talk (VOPOV)} 16:37, 1 February 2026 (UTC)

You are asking the question no one was actually asking.
The good/needs improvement/poor score is a score that any website can get and these score are relevant for any website. It is not guidance for Google-owned sites only, it is guidance for all web sites.
So no, Google-level UI/UX experience is something we probably should strive towards but this was NOT proposed as a requirement. Szmenderowiecki (talk · contribs) 16:48, 1 February 2026 (UTC)

Sorry for being unclear, by "Google-level" I didn't mean to imply only Google owned sites, just the best practices they advocate. Which is a fine question to ask, but the community seems to be comfortable with falling a few seconds short of that ideal. -- LWG ^{talk (VOPOV)} 18:57, 1 February 2026 (UTC)

LONG PAGES

At Wikipedia:Database reports/Long pages/User talk (no_subpages) I see a bunch of users who were indefed long ago and are obviously never coming back. Would anyone object if I or someone else set up archiving on those pages? --Guy Macon (talk) 02:17, 1 February 2026 (UTC)

Yup, because that is a database report, not a backlog. Anyway that stuff is always outdated; if you run Quarry 100159 you get fresh data. Polygnotus (talk) 02:21, 1 February 2026 (UTC)

Also the top 99 contains only 19 users that are active (defined as having edited in the past 12 months) and not blocked, 2 indeffed users and 78 users who have not edited in the past 12 months. There is no reason to edit the talkpages of inactive and indeffed users. Polygnotus (talk) 02:35, 1 February 2026 (UTC)

Continue, close, or what

This discussion was opened two days ago (14:29, 29 January) so why does it already feel like a month? The section sizes template (which I don't trust for word count) tallies the discussion at 129,627 bytes and 606 prose words. My text editor (which I do trust, but which counts hidden text and sigs as words) tallies it as 130,065 bytes and 21,662 words. There is a do-not-archive-until template at the top configured for 5 March. If the discussion keeps going at this rate until 5 March, it will be approximately 1.8 million bytes and over 300,000 words.^[b]

What shall we do?

A – request closure

B – let it run

C – something else (specify)

Your choice? Mathglot (talk) 03:49, 1 February 2026 (UTC)

• B. I don't see any reason to shut off discussion so soon, on what is clearly a very active discussion. Mathglot (talk) 03:49, 1 February 2026 (UTC)
• Mathglot just invented the meta-RfC! I choose option E. Something productive. Polygnotus (talk) 03:53, 1 February 2026 (UTC)
• C: Keep this discussion going until it reaches one million bytes of discussion. But in reality, B, as there is still legitimate discussion happening. SuperPianoMan9167 (talk) 03:54, 1 February 2026 (UTC)

  Perhaps a special price for whoever adds the millionth byte? Polygnotus (talk) 03:57, 1 February 2026 (UTC)

  That kinda reminds me of discussions like this one. Mathglot (talk) 07:56, 1 February 2026 (UTC)

• Looks like it's WP:SNOWing to me. The proposal seems too flawed to get much support, and the discussion seems to be mostly people sniping at each other or re-arguing whether slow old devices are actually slow and old rather than trying to work out something better. We can leave it a while longer if people want to see if it turns around, but I'd be surprised if it runs all the way until March. Anomie⚔ 03:59, 1 February 2026 (UTC)
• I really don't like closing down discussions after two days. I don't want to feel like I have to check Wikipedia every day just so I don't miss some discussion that gets opened and closed while I am spending a weekend away from my computer. --Guy Macon (talk) 05:07, 1 February 2026 (UTC)
• B per Mathglot. sapphaline (talk) 10:11, 1 February 2026 (UTC)
• Well, lemme see. I like the close-it-yesterday aspect of A, but I hardly see the point of requesting that someone waste their time divining a consensus. I think nothing good can come of B, and I find the claims that productive discussion is still happening downright ridiculous, although I enjoy the humor of SuperPianoMan's idea. Perhaps we should just leave it open forever. --Tryptofish (talk) 19:42, 1 February 2026 (UTC)
• I note that this discussion was quite properly closed by Polygnotus yesterday. Unfortunately, it was reverted by PackMecEng ([6]). That strikes me as bureaucracy for bureaucracy's sake, without any benefit to anyone. --Tryptofish (talk) 20:53, 2 February 2026 (UTC)

  I completely agree with this. Could the closing summary have been better? Yes. Did reverting the closure benefit the project in any way? No. Thryduulf (talk) 21:19, 2 February 2026 (UTC)

  Now 171,836 bytes (28,523 words), a 32% increase since 03:49, 1 Feb. Mathglot (talk) 21:35, 2 February 2026 (UTC)

  And no further insights to show for it, other than a growing consensus that this has been a waste of time. --Tryptofish (talk) 21:39, 2 February 2026 (UTC)

C Take it behind the barn, close it out right, this has been a drain. LakesideMiners^{Come Talk To Me!} 00:46, 3 February 2026 (UTC)

Proposal #2

I propose the following change to Wikipedia:Talk_page_guidelines#Archiving:

Current text

New text

Large talk pages are difficult to read and load slowly over slow connections. As a rule of thumb, archive closed discussions when a talk page has numerous resolved or stale discussions – see Help:Archiving a talk page. Apart from the exception described in § User talk pages, discussions should be archived, not blanked.

Large talk pages are difficult to read and load slowly over slow connections. As a rule of thumb, archive closed discussions when a talk page has numerous resolved or stale discussions – see Help:Archiving a talk page. Apart from the exception described in § User talk pages, discussions should be archived, not blanked. Any person can archive any inactive (2+ weeks without new messages) threads on any talk page; reverting these archivals is disruptive unless there's a valid reason to do so.

sapphaline (talk) 10:22, 1 February 2026 (UTC)

Interesting idea. Among concerns:

• 2 weeks may be a rather tight cutoff for a lot of folks here. I mean, I don't care if my page gets a drive-by archiving, and I'd be even grateful to some extent, but it seems that others will be pissed off big time. I think it's a month at a minimum, and probably preferably 3.
• does this concern user talk pages? If so:
  • what to do with users who insist that their talk page, or specific (list of) thread(s), are not be touched, even if such threads heavily tax your browser?
  • if the user has autoarchiving deployed, the archiving presumably must conform to the preferred choice of archiving by the user, correct? So numbered archives are continued, new monthly/yearly archives may be created, OK. What to do with theoretical topic-based archives?
  • what if the user says: I only want discussions to be blanked, I don't want no archive box or any fancy bots? Because after all the clause at Wikipedia:Talk page guidelines#Personal talk page cleanup that The length of user talk pages, and the need for archiving, is left up to each editor's own discretion. is unchanged by this proposal. They insist that they need no archiving and that any old thread be removed. But this proposal does not allow drive-by removal of threads from user talk pages, only archiving. Welcome to ANI I guess?
• how do you address some editors' complaints that empty talk pages are uninviting. It's not a hill I'm willing to die on, but I have a mild preference for non-empty pages if possible. And there are folks who seem to care about this a lot, at least if judged by the linked TPG discussion.

Szmenderowiecki (talk · contribs) 10:36, 1 February 2026 (UTC)

"does this concern user talk pages?" - "any talk page" = "any page intended for communication between editors" so yes. "what to do with users who insist that their talk page, or specific (list of) thread(s), are not be touched, even if such threads heavily tax your browser?" - such behavior is covered by "reverting these archivals is disruptive unless there's a valid reason to do so" and wp:own. "if the user has autoarchiving deployed, the archiving presumably must conform to the preferred choice of archiving by the user, correct?" - I think pages with auto-archiving can be excluded. "what if the user says: I only want discussions to be blanked, I don't want no archive box or any fancy bots?" - they should be blanked, then, not archived. "how do you address some editors' complaints that empty talk pages are uninviting" - can they explain why they are uninviting? sapphaline (talk) 10:45, 1 February 2026 (UTC)

So something like this:

Current text

New text

Large talk pages are difficult to read and load slowly over slow connections. As a rule of thumb, archive closed discussions when a talk page has numerous resolved or stale discussions – see Help:Archiving a talk page. Apart from the exception described in § User talk pages, discussions should be archived, not blanked.

Large talk pages are difficult to read and load slowly over slow connections. As a rule of thumb, archive closed discussions when a talk page has numerous resolved or stale discussions – see Help:Archiving a talk page. Apart from the exception described in § User talk pages, discussions should be archived, not blanked. Any person can archive or blank any inactive (3+ months without new messages) threads on any talk page, unless there's auto-archiving with a reasonable archiving period set up; reverting these archivals is disruptive unless there's a valid reason to do so.

sapphaline (talk) 10:54, 1 February 2026 (UTC)

This goes in a much better direction and makes sense. I applaud your effort.
The other two things that may be litigated are:

• what is a "reasonable" archiving period? "Reasonable" is a very vague word, and if we take real life, Americans with Disabilities Act lawsuits about "reasonable accommodations" is something of a cottage industry, judging by number of Supreme Court cases listed in the article. Because there are a couple of ways to define it:
  • "It keeps the page below a certain limit" (define the limit)
  • There is a maximum thread count so that users don't get lost in the ton of old threads nobody cares about (again, define the limit)
  • It keeps the page from substantially impacting user experience on their browser (on Chrome-based browsers, this could be the Inspect tool performance indicators). Judging by how the discussion is going, the next question is likely going to be "what device are you using? specs please", "what scripts you are running?" and the addition that "it works fine for me" or "it's not that big an inconvenience to complain about, I can load the page in X seconds".
  • some other criterion I can't think of right now?
• Any person can archive or blank conflicts with discussions should be archived, not blanked. I get the point. My proposal would be:
  Discussions should be archived, not blanked. Any person can archive any inactive (3+ months without new messages) threads on any talk page, unless there's auto-archiving with a reasonable (?) archiving period set up. On user talk pages, users may request that discussions be blanked instead of archiving - respect their wish. Reverting these actions is disruptive unless there's a valid reason to do so.

The reason I'm asking all these questions is to test the proposal against wikilawyering. Szmenderowiecki (talk · contribs) 11:27, 1 February 2026 (UTC)

• Oppose Editors should please mind their own business. Here's a fresh example. I get several regular newsletters posted to my talk page and I usually blank older ones so that only the latest appears. It would be better if the newsletters did this automatically but so it goes. Anyway, after recently clearing a batch of these, another editor restored them. An admin then turned up to revert their action because it appears that this user has a developing tendency to disrupt.
  The problem is that Wikipedia is the encyclopedia that anyone can edit and so our editors have a wide range of (in)competence. As they cannot be relied on to agree on such matters or have the necessary skills and understanding, they should not be encouraged to mess with other users' personal workspace. The Wikimedia software ought to have a foolproof interface maintained by its professional staff and, if there are technical problems with it, there ought to be a properly professional system for reporting and resolving them.
  Andrew🐉(talk) 13:50, 1 February 2026 (UTC)

  with other users' personal workspace
  The problem with arguments like these is that I don't think such thing exists on Wikipedia, at least if we consider WP:OWN (No one "owns" content (including articles or any page at Wikipedia and Wikipedia offers wide latitude to users to manage their user space as they see fit. Nevertheless, they are not personal homepages, and are not owned by the user. They are still part of Wikipedia and must serve its primary purposes; in particular, user talk pages make communication and collaboration among editors easier. These functions must not be hampered by ownership behavior.)
  A better descriptor would be "a communal workspace assigned to a user for issues relating to a user, with customarily large latitude at self-management" Szmenderowiecki (talk · contribs) 14:21, 1 February 2026 (UTC)

Oppose - There is no god-given right to talk to each and every other user on this website. Can't load their user talk page? Don't want to wait 30 seconds? Then don't talk to that user. Can't post an ANI notice on their page? Fine, then they don't get an ANI notice on their page. That's their problem. The notion of limiting all 250,000+ editors to some stupidly arbitrary and onerous rules, or letting busy-bodies mess with other people's talk pages, just because some editors don't want to wait for some talk pages to load, is ridiculous. Editors should not try to be so controlling of other editors. Levivich (talk) 14:28, 1 February 2026 (UTC)

"Can't load their user talk page? Don't want to wait 30 seconds? Then don't talk to that user" - Wikipedia isn't a social media website; you can't opt out of communication in a collaborative project. sapphaline (talk) 14:39, 1 February 2026 (UTC)

You don't need user talk pages to collaborate. We have article talk pages for collaboration. Levivich (talk) 14:41, 1 February 2026 (UTC)

Article talk pages are here solely for content dicussions. sapphaline (talk) 14:43, 1 February 2026 (UTC)

Yes. And template collaboration happens on template talk pages. And project wide collaboration happens on Wikipedia space talk pages. You don't need to talk to people on their user talk pages in order to collaborate with them. Levivich (talk) 14:46, 1 February 2026 (UTC)

"You don't need to talk to people on their user talk pages in order to collaborate with them" - yes, you need. Conduct issues exist. sapphaline (talk) 14:51, 1 February 2026 (UTC)

Yes conduct issues exist. You don't need user talk pages to resolve them. We have conduct noticeboards. If you didn't get a chance to discuss conduct issues with a user because their talk page was too long, that's too bad for them. It doesn't mean everybody else needs to follow new rules. Levivich (talk) 16:13, 1 February 2026 (UTC)

The conduct boards have a giant notice saying that you must leave a message on the person’s talk page and that a ping is not sufficient, so I don’t think that would be acceptable. ExtantRotations (talk) 23:35, 2 February 2026 (UTC)

From WP:USER: User pages are for communication and collaboration. ... However, pages in user space belong to the wider community. They are not a personal homepage, and do not belong to the user. They are part of Wikipedia, and exist to make collaboration among editors easier.
From WP:OWNTALK: User talk pages must serve their primary purpose, which is to make communication and collaboration among editors easier. Szmenderowiecki (talk · contribs) 14:45, 1 February 2026 (UTC)

1) you're bludgeoning. You've posted these quotes already in this discussion. 2) you're not making any point here with these quotes. Levivich (talk) 14:46, 1 February 2026 (UTC)

No, I'm rebutting a point which is obviously wrong according to current policy. Policy says this is the literal purpose of these pages. You may want to use pages not according to their intended purpose but that's your personal preference. I'm going to use these pages according to what they are for and which use policy explicitly endorses. And I should not be punished for asking that these pages be used for the purpose specifically outlined in the policy.
I also don't believe that any argument to the effect of "let's allow users to force discussions in non-obvious forums because they don't want to do the housekeeping in the places where such discussion is intended to take place" complies within the general intent of Wikipedia policies and guidelines to promote discussion. Szmenderowiecki (talk · contribs) 14:53, 1 February 2026 (UTC)

None of our policies and guidelines say Every user talk page must load within a time frame acceptable to User:Szmenderowiecki. I checked EEng's user talk page (the longest on the website) on pingdom and it said 11 seconds load time. If that's too slow for you, too bad. It doesn't mean we need to have everybody else in the website limit their page sizes. Levivich (talk) 16:11, 1 February 2026 (UTC)

Another problem with this proposal is that sometimes threads "2+ weeks without new messages" should still remain on a talk page. Sometimes returning old threads from the archives is exactly the right thing to do. To require those to be archived, or to prevent them from being un-archived, mass collaboration harder, not easier. Rarely have I seen "solution in search of a problem" as clear as this. Levivich (talk) 14:44, 1 February 2026 (UTC)

There is no god-given right for any editors to have their user talk page be organized or contain any content that they wish it does. User talk pages exist for a purpose - to facilitate communication. Katzrockso (talk) 20:00, 2 February 2026 (UTC)

Oppose all per most people above. There should be (and indeed are) already guidelines about talk page size, but they should remain no more than guidelines because there are far too many variables for a hard and fast one-size-fits-all rule to be useful, even if one were desirable (per most people above). If you need to post on someone's talk page to notify them about something then state that, with a ping, in whichever discussion you want to notify them about. Either they will respond to the ping or someone who can post on their talk page will leave a message on your behalf. Thryduulf (talk) 14:38, 1 February 2026 (UTC)

Oppose all, with no small amount of annoyance. Seriously, if someone comes to my talk page and wants to blank it, that's OK, but if I revert even part of that, I'm violating policy? Now, I'm quite tempted to blank this VPP discussion, and would love it if I were empowered to do whatever pops into my mind, with nobody allowed to object (woo-hoo, I wanna be an autocrat!), but no, just no. --Tryptofish (talk) 19:37, 1 February 2026 (UTC)

Oppose this and all future attempts to give random trolls power over what I can post on my talk pages:

(I have no problem with anyone bringing up any problems they have with my talk page at ANI and asking an admin to deal with them. That's why they get paid the big bucks.)^{[Citation Needed]}

If your 386SX running Internet Explorer on Windows 3.0 doesn't allow you to post a required ANI notice just say that in your ANI post -- someone will notify me.

Nobody forced you to read my talk page. Unless, of course, you are strapped to a chair with your eyelids taped open in front of a monitor with a Wikipedia feed and with The Wikipedia Song blasting in the background.

If you are strapped to a chair, etc., then let me address this message to your captors: First of all, keep up the good work. Secondly, please take away their keyboard. --Guy Macon (talk) 19:44, 1 February 2026 (UTC)

• Oppose giving carte blanche to meddlers to meddle in other peoples' talk pages. —David Eppstein (talk) 18:36, 2 February 2026 (UTC)
• Oppose all. Phil Bridger (talk) 21:24, 2 February 2026 (UTC)
• Oppose meddling in other users' Talk pages per WP:OWNTALK: "The length of user talk pages, and the need for archiving, is left up to each editor's own discretion." Mathglot (talk) 21:29, 2 February 2026 (UTC)

Reasons and ways to end RfCs

Per WP:RFC#Reasons and ways to end RfCs, there are five ways an Rfc may end. One way, is a consensus among participants to end it (#2 in the list). However, that requires discussion and time, and given the size of this discussion already and the number of participants, that may be a significant effort in itself. However, there is a much quicker and easier path. The originator may decide to withdraw the Rfc unilaterally (per #1) if the outcome seems clear early. Normally, this would be carried out by the OP removing the {{Rfc}} tag at the top, however, this Rfc has no such tag.

So that we don't become bogged down in bureaucracy, I think I can speak for most participants here that a clear statement from the OP, such as, "I withdraw this Rfc because reason" would be sufficient to meet the requirements of method #1. Szmenderowiecki, you are in a unique position to be able to end the Rfc now. Would you be willing to do so? You are, of course, under no obligation whatever, and you don't even need to respond to this if you don't wish to. Cheers, Mathglot (talk) 23:00, 2 February 2026 (UTC)

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

"Notability" really is a terrible name.

I've heard it discussed around a fair amount, and I'm sure it's one of those 'perennial proposals' that the veterans here are going to roll their eyes and say "ugh, somebody's bringing THIS up again," but I do think it bears saying. Notability is an awful descriptor for what we're actually looking for, which is presence in sources. That's 'notedness' if anything, not 'notability', and the inevitable result is that every time you tell someone you can't accept their autobiography/company's article/article about their favourite media thing because it's 'not notable,' they get their haunches up and go on a tirade about how many awards they/the thing have won and how many cool things they/the thing have done, etc. Pretty much every mention of something being notable or not notable has to be accompanied by a mandatory disclaimer of what notability means here and how it doesn't mean what they think it does. It's a thought particularly spurred on by my deletion nomination of the article Deaglán de Bréadún, which led the man himself to post a response essentially calling me a nasty person for daring to imply that him and his career aren't notable... which, of course, is not actually what we mean, despite literally saying the words "you aren't notable enough for a Wikipedia article"

So, the obvious question is; what would we call it instead? I've heard the term "Criteria for inclusion" mentioned, which I think would be a graceful solution, since you can explain that the criteria for inclusion is presence in sources etc without ever having to use the scary word 'notability.' Whatever alternative option is presented, I do think it is seriously high time that Wikipedia take the big step of retiring the term 'notability' Athanelar (talk) 00:39, 20 February 2026 (UTC)

I agree with you. Notability is a dumb name. However, there's never going to be a consensus to change it. voorts (talk/contributions) 00:55, 20 February 2026 (UTC)

And then, what would we call all the lists of "notable" people/residents/alumni/etc.? "People/residents/alumni/etc. who meet the criteria for inclusion"? Donald Albury 01:11, 20 February 2026 (UTC)

I think you could probably still keep those; the definition there would logically run in the opposite direction, they are notable because they meet the criteria for inclusion. It's not an ideal solution, but obviously cuts down on some of the logistical challenge. Athanelar (talk) 01:41, 20 February 2026 (UTC)

Renaming notability has been an WP:PEREN issue, repeated discussed without finding any term that has a benefit over "notability" that would not be disruptive (how many P&G depend on it) but would be more descriptive. And no, "presence in sources" is an indicator of notability, but not how notability is defined. Masem (t) 01:16, 20 February 2026 (UTC)

It is undoubtedly true that it would be a lot of work changing the nomenclature all over the project if we got rid of 'notability,' but I don't think "It'd be a lot of work" is a compelling counterargument. There would no doubt be a long transitional period where lingering remains of 'notability' were still all over the place; but that doesn't have to be an issue, it's not like the change has to happen overnight. We could just say "from today on, the term 'notability' is deprecated and we prefer this new term instead" and people can change mentions of it as and when they catch it. Just today I heard about the NSPORTS 2022 RfC where the definition of notability for athletes was radically changed; that too would've had far-reaching implications on the project, but that didn't stop people from doing it just because it was a lot of work ahead of them to clean up the now non-notable athlete articles everywhere. Athanelar (talk) 01:42, 20 February 2026 (UTC)

The NSPORT change did not radically change what notability was, just eliminated a very poor presumption of notability (playing one professional game) that had led to thousands of permastubs on athletes that was a constant problem at ANI.

We've been through what the downstream impacts of changing the term notability to something else as part of past discussions (because this being PEREN) and its not as simple "from now on it will be known as..." "notability" is embedded in WP culture and in coverage of how WP works, so it would be a massive shift, so any new terms must carry a lot of massive benefit to make it worth the effort to make the change. And dozens of suggestions have been made and failed to show this. Masem (t) 04:47, 20 February 2026 (UTC)

• My 9-year-old essay's time has finally come! WP:Noted not notable. (Note: It's a very, very short essay, admittedly.) EEng 01:58, 20 February 2026 (UTC)

  We could put this in big letters on the notability page and all the spin-off pages like WP:42. Thebiguglyalien (talk) 🛸 04:24, 20 February 2026 (UTC)

  This is also a fairly elegant solution, hut unfortunately relies on people actually clicking the link and then actually reading the words on their screen. The 'headline effect' is real when it comes to WP links. Athanelar (talk) 09:23, 20 February 2026 (UTC)

  Nice essay, EEng. I especially like how the "nutshell" explanation is nearly twice as long as the essay itself  ;) —Fortuna, imperatrix 19:24, 20 February 2026 (UTC)

  [7] EEng 20:16, 21 February 2026 (UTC)

• For reference, the last big discussion on this topic that I know of is Wikipedia talk:Notability/Archive 84 § RfC on change of name, from April 2025. isaacl (talk) 02:07, 20 February 2026 (UTC)

  Much appreciated. Starting to read through some of that, I think 'eligibility' is quite a strong contender. It's an easily-understood English word already, which perfectly encapsulates the concept being described, and also would actually allow us to broaden our definition in some useful ways (because eligibility is a catch-all term that could include not only the presence of positive indicators like strong sources, but also the absence of negative indicators like WP:NOT or criteria for speedy deletion.) A subject which is 'eligible' is one that is both suitable for inclusion and unsuitable for deletion, which 'notability' does not currently encapsulate. Athanelar (talk) 02:15, 20 February 2026 (UTC)

  No, eligibility is a terrible idea, because it implies a brightline yes/no answer. Notability is a greyscale, its why notability is based on presumptions and not a hardline test.

  The only real issue with notability is for editors encountering the term for the first time, and coming to learn that real-world definition of notability is not exactly the same as WP's definition of notability, but reading the P&G should quickly resolve that. Masem (t) 04:53, 20 February 2026 (UTC)

The only way to get the name changed? would be to propose only one alternative. GoodDay (talk) 02:10, 20 February 2026 (UTC)

I disagree, the bugbear for a lot of people seems to be whether we'll get consensus that changing the name is worth the effort. I think people first have to be disgruntled about the old name to be resolved to change it before we worry what the new name ought to be. Athanelar (talk) 02:11, 20 February 2026 (UTC)

Do you have a proposed name? GoodDay (talk) 14:37, 20 February 2026 (UTC)

No! God please no! This is a perennial issue based primarily on WP:IDONTLIKEIT. It’s too late and too entrenched to change and someone is just going to bitch about how dumb “eligibility” is down the line. A better proposal would be outright banning perennial proposals and requiring consensus to unban them before allowing them to be discussed again, since that would require more extraordinary reasoning than “I know this has been talked to death, but just me out, I swear”. Dronebogus (talk) 02:43, 20 February 2026 (UTC)

While I agree that changing it has a less-than-ideal cost-reward, this post (and the others before it) explain legitimate downsides to the current name besides preference. Also, a discussion to unban a perennial proposal would look almost identical to the proposal itself. Thebiguglyalien (talk) 🛸 04:28, 20 February 2026 (UTC)

A discussion to unban a perennial proposal would look almost identical to the proposal itself. Maybe so, but it would force proposers to go through the process twice, which would discourage most proposers from doing it at all and save everyone a lot of time. Additionally, it wouldn’t necessarily always result in the aforementioned situation— if a proposal was banned because it was a hot-button issue now, it might be uncontroversially removed from the list 10 years later after things cool off, without actually endorsing it. It would be sort of like the MediaWiki:Bad image list or a gold lock for proposals. Dronebogus (talk) 09:51, 20 February 2026 (UTC)

I totally agree with you and I was disappointed that there wasn't consensus to change the name in the aforementioned April 2025 RfC. But given the outcome of said RfC, I struggle to see the point of rehashing the discussion so soon as it's very unlikely that there will be a different outcome. Perhaps give it a year or two.  novov talk edits 05:24, 20 February 2026 (UTC)

• Coverage perhaps? Or renown? Or just noted ... I doubt it'll ever actually change though. EvergreenFir (talk) 05:42, 20 February 2026 (UTC)

  Coverage is a distinction without a difference. Renown is far more pretentious than notability. Noted is barely even a change and couldn’t be used rationally in a sentence. Dronebogus (talk) 09:53, 20 February 2026 (UTC)

• WP:Eligibility was recently suggested by Wikipedia expert Bill Beutler. SmokeyJoe (talk) 06:00, 20 February 2026 (UTC)

  Eligibility is the rename option that sucks the least, since it most accurately reflects what “notability” actually means. But “notability” still at least puts a vague idea in people’s heads (namely, is this thing/person significant in some way?) whereas “eligibility” could mean pretty much anything and could actually put a worse idea in people’s heads (namely, eligibility is whatever somebody says it is, or is some arcane ruleset known only to insiders that isn’t easily summarized). Dronebogus (talk) 09:59, 20 February 2026 (UTC)

  I still think "notedness" would be better than "eligibility", as "eligibility" seems like it should include non-WP:N things such as WP:NOT and WP:BLP. Anomie⚔ 13:50, 20 February 2026 (UTC)

  I don't see that as a negative. We are, ultimately, looking for a term that describes "eligible to be included on Wikipedia." In fact, some of the AfC decline notices literally use "your references do not demonstrate that this subject qualifies for a Wikipedia article" as a piped link to 'notability' anyway. If anything, having a more comprehensive term would be an advantage, since then you don't run into the tricky situations of 'well, we TECHNICALLY have enough information to presume this person is notable, but there's still not enough coverage to substantiate an article about them' amd so on.

  Eligibility includes what we now define as notability, but way more succinctly communicates the point of whether or not something should have an article. Athanelar (talk) 14:02, 20 February 2026 (UTC)

  Having an all-encompassing term actually referring to just one facet seems like it would make it harder to discuss that facet versus other facets. "Ok, that meets WP:ELIGIBILITY, but it's still not eligible because it doesn't meet WP:BLP1E." "Wat?" Anomie⚔ 00:01, 21 February 2026 (UTC)

  Exactly. Dronebogus (talk) 14:33, 21 February 2026 (UTC)

  “notability” still at least puts a vague idea in people’s heads: but I think that’s the problem with the term. People don’t realize they are encountering a jargon term and substitute their own meaning. I’d argue that “eligibility” is better because there’s more precedent that contextual criteria will define eligibility for a particular thing; it might cue people that they need Wikipedia-specific information. (I’d almost want to try a complete neologism that people would know they don’t know the meaning of, something like “wikifiability” or “AAOEW” (Article Allowed On En-Wiki) that they’d know they don’t know.) ~ le 🌸 valyn (talk) 07:35, 21 February 2026 (UTC)

  Anomie said it best with the “wiki-eligibility is not dictionary definition eligibility” example. Notability still hits the general vicinity of the right idea; eligibility doesn’t and has the potential to be more confusing. As for a neologism, I don’t support that either because (on top of being a solution in search of a problem like all these replacement suggestions) it just adds MORE incomprehensible jargon to Wikipedia— which is what this proposal is supposedly trying to cut back on. Dronebogus (talk) 14:39, 21 February 2026 (UTC)

  I feel like you might have misunderstood my argument. When it comes to the one-word name for this concept, I contend that "trying to cut back on" jargon is counterproductive; any one-word name for this mess of concepts is inherently jargon. Accordingly, I think there's no point trying to change to something "clearer", but it could possibly be helpful to change to something less "clear", because it could make the term into a "known unknown" instead of "something you know that isn't so". Personally, when I want to avoid jargon with newbies, I write out a whole explanatory phrase instead (eg "our criteria for a book to have an article"); I think that's the only approach that can actually effectively cut down on jargon. ~ le 🌸 valyn (talk) 02:42, 23 February 2026 (UTC)

• Notability was never a good choice of name, but we've stuck with it because of the cost of changing; it's a QWERTY vs DVORAK problem. Personally I'd quite like to call it "Citability".—S Marshall T/C 09:45, 20 February 2026 (UTC)

  I think the 'cost of changing' would quickly be outweighed if you tallied up the editor-hours required and compared it to the editor-hours that have been spent and will continue to be spent in perpetuity explaining to disgruntled would-be article creators why appearing on a list of the Top 100 Best Things doesn't confer notability. Athanelar (talk) 13:11, 20 February 2026 (UTC)

  Don't misunderstand: I personally would support most reasonable alternative names because "notability" is still (after all these years) a misleading, dramagenic, and generally awful choice of words. But there's a non-zero cost of changing and a lot of neophobia to overcome here.—S Marshall T/C 14:40, 20 February 2026 (UTC)

  Is “dramagenic” a word? Dronebogus (talk) 14:40, 21 February 2026 (UTC)

  As I discussed last April, personally I encourage everyone to focus on providing more complete explanations on the standards for having an article rather than just linking to a jargon term. The key obstacle is that the community has to want to reduce its use of jargon. isaacl (talk) 16:51, 20 February 2026 (UTC)

• It is highly unlikely that the community is going to rename "Notability", this being as noted a perennial proposal that gets enmeshed in the long and complicated history and complicated current understanding of the concept of 'notability' on en.wiki. However, a creative smaller change probably worth exploring might be to create an alternative name for WP:GNG that somehow does not include the "N". GNG is the aspect of notability that best describes "presence in sources", it is the least likely aspect of notability to get enmeshed in notability politics. I don't have a perfect suggestion offhand, but creating an alternative name for GNG is a smaller task then renaming all of notability, and would capture much of the practical benefit of a full notability rename even if that full rename never happens. CMD (talk) 14:11, 20 February 2026 (UTC)
• The community's inertia is such that a proposal to change this isn't a good use of my time or anyone else's. But I agree, and if I had my way I would want the policy not to be a near-synonym of "significant". The practical consequence I see most often is the eliding of "should we as an ambitious global encyclopedia cover this in principle" and "can we as an encyclopedia that cares about verifiability write an article about this in practice". I could go on at length, but a more prosaic name may help us a good bit, perhaps something as plain as "standard for inclusion". Vanamonde93 (talk) 17:47, 20 February 2026 (UTC)

  “Standard(s) for inclusion” is by FAR the best proposed option so far; but there are multiple “standards for inclusion” beyond notability. Dronebogus (talk) 14:46, 21 February 2026 (UTC)

  @Dronebogus: This is precisely the distinction that I want to make. To my mind there's not multiple standards for inclusion, because in our most overarching policy language, "notability" is used as a synonym for standards of inclusion. We do have multiple was of showing notability beyond GNG/SIGCOV. And the frequent use of "notable" to mean "has SIGCOV" therefore causes considerable confusion as well. Vanamonde93 (talk) 20:18, 21 February 2026 (UTC)

  "Notability" is one commonly discussed standard, but there are others such as WP:NOT and WP:BLP. Anomie⚔ 20:52, 21 February 2026 (UTC)

  @Anomie: I see those as standards for exclusion, which may require the removal of notable topics, but will never compel the inclusion of non-notable topics. Vanamonde93 (talk) 01:49, 22 February 2026 (UTC)

  Two sides of the same coin. You could just as well say that WP:N will never compel the inclusion of topics that go against WP:BLP, and so on. It all goes together to determine what's included, i.e. multiple criteria. Anomie⚔ 03:20, 22 February 2026 (UTC)

• Wikipedia jargon. We use a word with a meaning that differs from its normal English meaning. Any other word would therefore have the same issue unless we created an entirely new word like "cituated". My personal favourite is "living persons", which includes dead persons. Hawkeye7 (discuss) 18:42, 20 February 2026 (UTC)

  I don't think that this is necessarily true; "eligibility" "suitability" and "criteria for inclusion" which have all been mentioned all transparently mean what we would want them to mean; the bar a subject has to pass to get an article. This isn't an unsolvable dilemma, it's just hard work. Athanelar (talk) 19:33, 20 February 2026 (UTC)

  "Criteria for inclusion" leads us straight to one of the most common points of confusion: inclusion of an article in the encyclopaedia versus inclusion of details within an article. The criteria applied to the creation or retention of an article are not the same as those applied to the content inside it. Hawkeye7 (discuss) 20:36, 20 February 2026 (UTC)

• "Notability" really is a terrible name. Yes, you are correct. Toadspike [Talk] 18:49, 20 February 2026 (UTC)
• Yes, it is really a terrible name. The fixation that it needs to be one word is also bizarre. Neutral Point of View is not one word, Original Research is not one word, Biography of Living Persons is not one word, Article Title is not one word, etc.: so, Article Criteria, or some such. 'On Wikipedia, Article Criteria is a test . . .'; It meets the AC; it does not meet WP:AC; and done. Alanscottwalker (talk) 01:44, 21 February 2026 (UTC)

• Comment: Unpopular opinion I guess but I like the word "notability," especially when paired with "Wikipedia:Verifiability." Notability gives a lot of wiggle room but suggests there is some minimum for inclusion, and we can adjust what that is.

GeogSage ^{(⚔Chat?⚔)} 02:23, 21 February 2026 (UTC)

It’s not an unpopular opinion. I’m pretty sure the silent majority either likes it or has no strong opinion on it. Otherwise we would have changed it by now. Dronebogus (talk) 14:50, 21 February 2026 (UTC)

• I think some people are confusing the aim and the criteria. We really do want to write articles on topics that are notable according to its everyday meaning (that's the aim), but to achieve that in practice we have to make guidelines for notability that editors are able to follow and agree with each other about (that's the criteria). So my opinion is that "notability" is actually the best of the options mentioned so far in this discussion. "Eligibility" is way too vague (neither an aim nor a criterion) and "citeability" is just wrong (that would refer to sources, not topics). The word that has annoyed me the most, for the past 20+ years, is "verifiability", which in wikispeak means something entirely different from its meaning in plain English. In plain English, something is verifiable if its truth can be confirmed, which is why the ancient slogan "verifiability, not truth" is my nomination for the worst own-goal in Wikipedia history. Zero^talk 10:35, 21 February 2026 (UTC)

  In defense of verifiability, it's purely a question of which frame of reference you're using. Sure, in everyday speech it usually means verifiable [against objective truth] but it's not a stretch or corruption of the meaning that on Wikipedia it means verifiable [against a source text]. The whole point of 'verifiability, not truth' is to clarify that the thing we're verifying against is not objective truth, merely source->text integrity. Athanelar (talk) 10:48, 21 February 2026 (UTC)

  No, that was not where "verifiability, not truth" came from (I was here when it was adopted). The "not truth" part refers to "no original research". The idea is that we use what reliable sources say is true and not what we personally believe is true. It isn't a reference to objective truth. The problem with the slogan is that it was commonly taken to mean that Wikipedia doesn't care about getting the facts right, and this misunderstanding got "out there" to our detriment. And we threw it at newcomers before they had a chance to grasp that "verifiability" didn't mean what they thought it meant. Zero^talk 11:40, 21 February 2026 (UTC)

  When it comes to "verifiability" I view it as "is the notability verifiable." Something can be true, but not notable. There is a lot of stuff about me floating on the internet, my existence is verifiable, however none of it meets the criteria for notability, my notability is not verifiable. GeogSage ^{(⚔Chat?⚔)} 20:01, 23 February 2026 (UTC)

I would probably call it "sourceability" which is somewhat more accurate. However, as said before it's one of these entrenched terms that are hard to change. Jo-Jo Eumerus (talk) 14:25, 21 February 2026 (UTC)

What name is being proposed, to change "Notability"? GoodDay (talk) 14:37, 21 February 2026 (UTC)

Nothing currently; I'm not trying to make a proposal, just to discuss the topic. There's no point in proposing a candidate if nobody thinks it should be changed to begin with. Athanelar (talk) 14:42, 21 February 2026 (UTC)

No-one can decide. And most likely no decision will be made. This is such an obvious waste of time I don’t really know why I, or any of the many high-profile editors here, dignifying it with a response beyond “WP:PERENNIAL” Dronebogus (talk) 14:43, 21 February 2026 (UTC)

I note WP:PERENNIAL doesn't actually have this topic listed (yet). Anomie⚔ 20:57, 21 February 2026 (UTC)

"Notability" is fine. It means what subject can be noted on Wikipedia. I don't see a glaring problem with it. Joe vom Titan (talk) 14:46, 21 February 2026 (UTC)

The glaring problem is that that's an extremely unintuitive and niche use of that word, which usually means "important" or "significant" Athanelar (talk) 16:34, 21 February 2026 (UTC)

That's what "notable" means, while "notability" reflects how much someone is likely to be notable, which matches the intent of what WP's notability does. Masem (t) 16:47, 21 February 2026 (UTC)

But "importance" is subjective (my wife is important to me, the road I take to work is important to me, the band my friend started when he was 15 is important to him; none of them are notable in the Wikipedia sense). "Notability" (or at least the GNG) aims to be an objective standard that is either met or not and has little to do with what most people think of as "importance". HJ Mitchell | Penny for your thoughts? 20:49, 21 February 2026 (UTC)

Also worth adding that we do "note" unnotable things on Wikipedia, just within articles rather than as standalone topics. CMD (talk) 04:18, 22 February 2026 (UTC)

Its far from an objective standard, which is why notability is a rebuttable presumption. Show that the topic is given in-depth coverage from at least a few independent, reliable sources (generally being secondary sources), and we'll presume that the topic can merit a full article. But there's so much variability in what qualifies as in-depth coverage, how many and what kind of sources, etc. that its far to call the test solely objective. Otherwise, we'd not have any problem at AFD with deletion.

But we do associate being notable as if the topic was important enough to independent authors to cover in-depth, that is, is the topic demonstrated the quality of being notable based on sourcing. Masem (t) 04:29, 22 February 2026 (UTC)

When you read that notability is necessary for inclusion on Wikipedia how is it not glaringly obvious that it is Wikipedia that sets the standards for what is notable?--User:Khajidha (talk) (contributions) 18:09, 22 February 2026 (UTC)

While we’re here, why don’t we look at all the other less-than-ideal names used for rules on Wikipedia? WP:NPOV (which isn’t neutral) WP:IAR (don’t actually do this) WP:DELETION (pages aren’t deleted). I could probably find lots of examples. Wikipedia is just like any hobbyist subculture in that it has a lot of weird jargon that doesn’t necessarily mean what the dictionary and common sense say it means. “Fixing” that will just create more problems as now both newbies AND veteran editors are confused by the weird new terminology. On top of that Newbies still won’t understand what it’s meant to convey, veterans will just keep using the same terminology they always used, and eventually it will just get reverted back with the same unnecessary cost as changing it. Dronebogus (talk) 15:00, 21 February 2026 (UTC)

• Notability is a terrible name because it's easily conflated with "importance", which is subjective—everything is important to someone. I've previously advocated for "criteria for inclusion". HJ Mitchell | Penny for your thoughts? 15:20, 21 February 2026 (UTC)

  One word synonym could just be "Includable." GeogSage ^{(⚔Chat?⚔)} 20:03, 23 February 2026 (UTC)

  It looks like we have a nice set of redirects in the Wikipedia:Criteria for inclusion line. I think that's a good thing. People can use whichever they like. WhatamIdoing (talk) 23:04, 28 February 2026 (UTC)

• I prefer "Notability". While "criteria for inclusion" would convey the idea, it would be awkward to use regularly. None of the other suggestions above work for me. - Donald Albury 19:04, 21 February 2026 (UTC)

  My POV hasn't changed since the discussion last year, specifically that we should eventually change this, and that the way to go about it is to pick some other word or phrase and use both, e.g., "On Wikipedia, notability, or eligibility, is a test used by editors..." or "On Wikipedia, notability is the article creation criteria that editors use..." Then editors have a choice, and if they choose to say "It's Wikipedia:Notable" or if they choose to say "It meets the Wikipedia:Article creation criteria" or if they choose to say "I think this meets our Wikipedia:Eligibility standards", then that's fine (though it'd be preferable if the guideline suggested a single alternate name). WhatamIdoing (talk) 23:02, 28 February 2026 (UTC)

Hey @Athanelar, I'm the person who started the last massive discussion. Good luck. The main message I came out of it with is there will be many more opposing people in actual RfCs rather than discussions; I started an RfC thinking I would have significantly more support than I did based on my experience discussing it at the idea lab. I think the only way to make this work is to make a smaller change first -- maybe some sort of movement among AfD contributors to use eligibility (linking to notability) would work to get it off the ground, but I have no idea how that would be organized. Maybe a WikiProject? Mrfoogles (talk) 20:59, 27 February 2026 (UTC)

• Can we at least footnote the WP:N lead sentence with an explanation along the lines of:

  (1) Wikipedia notability is largely independent of real-world notability, (2) while this is confusing, we continue to use the word because multiple discussions have failed to find a better one, and (3) alternative names (that have been considered, but not adopted) include notedness, criteria for inclusion, eligibility, suitability, admissibility, and wikinotability.

  New editors start out assuming that Wikipedia notability is at least somewhat related to real-world notability, which isn't helped by WP:N statements like Determining notability does not necessarily depend on things such as fame, importance, or popularity. While new editors don't start by reading all the PAGs, WP:N and WP:GNG are quoted so often they'll likely see them first, making it even more important these pages clarify common misconceptions. An overview of previous discussions will also be of value to more experienced editors. Preimage (talk) 06:41, 1 March 2026 (UTC)

  Alternatively, we could remove the term altogether (in effect, making WP:N a self-referential acronym): "On Wikipedia, WP:N is a test used by editors..." Preimage (talk) 07:08, 1 March 2026 (UTC)

  Please note that the existence of the term "Notability" is essential to a joke on the signpost. I think it was in the comix section of the last January edition. ~2026-11404-95 (talk) 19:51, 3 March 2026 (UTC)

• I dunno why people have complained how terrible "notability" is other than... probably it's unfair to those who may not be "notable" but might deserve an article perhaps. This is more akin to (failed?) efforts to repeal and (failed) constitutional challenges to the Affordable Care Act, both perhaps time- and money-wasting. Right? Frankly, "notability" has been fine as-is, despite hostile backlash and all, and something that consensus should practice often. Too bad certain others here wanna change it. BTW, have standards of "notability" been that low or that high? George Ho (talk) 19:55, 4 March 2026 (UTC)
• I like Preimage's solution of referring to Notability as a native concept abstracted from outside usage, but I like better the idea of changing the word notability. I've created WP:WOTABILITY to try to best differentiate outside notability with WP's notability. If anyone has any better idea than my sort of clunky one please share - I suspect this may be a big problem in editor retention, to have such an onerous stumbling block placed so early in editor lifetime. Embyarby (talk) 04:02, 5 March 2026 (UTC)

AI SEO

In WP:WikiProject AI Cleanup/Noticeboard#Chat hack there was a suggestion for some guideline or policy warning. Suggestion will be appreciated. Thanks Yesterday, all my dreams... (talk) 09:11, 21 February 2026 (UTC)

good luck trying to get anything done, the only policy people seem to want anymore is a policy allowing things Gnomingstuff (talk) 16:30, 21 February 2026 (UTC)

Well, we can always say C'est la vie. Yesterday, all my dreams... (talk) 17:57, 21 February 2026 (UTC)

I'd support a policy that says that all commercial AI products are immoral technology, but I can only see that proposal going over like a lead balloon. On a much more modest level, we could add a bullet point to the LLM warning, observing that LLM output can include deliberate misinformation. Stepwise Continuous Dysfunction (talk) 21:22, 21 February 2026 (UTC)

Please, Just Do It... Now. Yesterday, all my dreams... (talk) 21:36, 21 February 2026 (UTC)

I’d support a flat ban on AI, outside of examples on AI-related pages. Wikipedia should have zero tolerance for LLM text, AI-generated images, or any other kind of AI slop that people dump into articles (or anywhere else). Hosting AI images on Commons is kind of a necessary evil to discuss this technology and its “applications” (for lack of a better word) informatively, but I can see no other reason for Wikimedia to engage with or promote AI. It belongs in the Web 3.0 box of shame with crypto, which was rightfully banned as a donation method years ago. Dronebogus (talk) 09:07, 22 February 2026 (UTC)

Community Consensus is to allow LLM generated output with tight restrictions and warnings. I believe that this is a quality compromise between Anti-AI and Pro-AI viewpoints. ~2026-11404-95 (talk) 14:23, 24 February 2026 (UTC)

I think a total ban on all AI use on Wikipedia is an awful idea; not everything involving AI is automatically bad, and we should treat each use of AI in a nuanced, case-by-case method rather than just mindlessly assuming "AI bad." QuisEstJoe (talk) 17:48, 1 March 2026 (UTC)

Yeah I think a disclaimer and/or tight regulations are a lot more fair than just automatically assuming "AI bad" without thinking about whether or not the AI said anything bad. We can't let Wikipedia be tainted with the black-and-white "AI slop" mindset already rampant on the internet. QuisEstJoe (talk) 17:51, 1 March 2026 (UTC)

Editors are responsible for everything they add to the encyclopedia. So as long as any AI output is checked / corrected and all it's sources are verified before posting I don't see it as a problem. -- LCU ActivelyDisinterested «@» °∆t° 19:07, 1 March 2026 (UTC)

As an example: Talk:Zamia oligodonta. I didn't ask for in-line citations, so it took me a while to find which source a particular piece of content came from. The big time saver was the list of sources, which it would otherwise have taken me some time to dig out. The sources panned out, and while a few items tended towards more synthesis than I was comfortable with, I don't think any of it was wrong, just hard to literally verify from the cited sources. Donald Albury 20:07, 1 March 2026 (UTC)

Adding pre-debut members of music group

There are 2 pages that in conflict: TLC and NSYNC. Both have pre-debut members who never released any song as the group member. The problem is, some Wikipedia editors list them as past members. In this case, Blackpink's page should also include Miyeon, BTS with Supreme Boi, Big Bang with Jang Hyunseung, SNSD with Soyeon, and Innosense with Britney Spears.

Now, what is the consensus? ~2026-41110-5 (talk) 14:18, 23 February 2026 (UTC)

I don't see the problem. As long as the group has maintained the same name, then those pre-fame members are still former members of the group. There should definitely be a clear delineation of when a person was a member of the group in the prose and there may be special organization or footnotes in lists or tables, but they still need to be in there. --User:Khajidha (talk) (contributions) 17:28, 23 February 2026 (UTC)

Reading the further responses, I see some possible distinctions to draw. A group of musicians may come together and practice. At some point, they try out for bookings and print materials to advertise themselves. Eventually, they begin booking shows. They finally receive a recording contract and release their debut album. People may come and go at any point in this sequence. My position is that anyone who is presented to the public (either in marketing materials or actual performances) should be counted as a member. Where in this sequence do the people you mentioned fall? --User:Khajidha (talk) (contributions) 13:35, 25 February 2026 (UTC)

I don't know exactly why the pages for TLC and NSYNC have the very early members listed, but in the case of the K-pop groups listed; just absolutely no. You'd need to add over half a dozen "members" just for SNSD alone, because leading up to their debut, their management was swapping potential members in and out at seemingly a moments notice. There were at least four different line-ups prior to debut, with as many as twelve members in them. And that's just the ones we know of, I'm sure there were plenty more, are we gonna add every SME trainee from that period as a potential past member? Which brings me to a further point: good luck finding reliable sources any of this, because every thing I could find in my research for this reply was terrible fansites, or "sources" known to be unreliable. Pre-debut trainees are just that: trainees. They are not official members.DragonFury (talk) 22:28, 23 February 2026 (UTC)

I mean, the actual final plan of SNSD was 10-member group before Soyeon left voluntarily.

But yes, pre-debut members should not be included since it's not official. I also don't know why they including pre-debut members on NSYNC and TLC. ~2026-41110-5 (talk) 22:34, 23 February 2026 (UTC)

And to add another point; Twice was formed from the TV program Sixteen, so do we add the seven people not selected in the program as past members? Because if so, I'd like to see someone make the same argument for Kep1er and the NINETY contestants from Girls Planet 999 who weren't selected for the group. DragonFury (talk) 22:38, 23 February 2026 (UTC)

It should be whatever is reflected in reliable sources. If reliable sources describe those people as actual, bonafide former members of the band then sure.

For most of the examples you listed, however, this wouldn't be the case... they were just trainees in the same company along with the people who eventually became the final lineup. Agencies add and remove people from lineups all the time before they actually release any music. It doesn't mean they're a member of the band. RachelTensions (talk) 01:41, 24 February 2026 (UTC)

so you agree that we should not include pre-debut members? ~2026-41110-5 (talk) 19:44, 24 February 2026 (UTC)

I'm going to quickly reject "never released any songs as a member" as the dividing line, because bands can have a healthy life as a performing group before they become a recording group. There were no The Beatles songs released with Stu Sutcliffe on them until he was dead over thirty years (if I recall correctly), but he was a key player in their pre-record-contract days. -- Nat Gertler (talk) 02:16, 24 February 2026 (UTC)

The Beatles does not include Sutcliffe, Pete Best, etc in the infobox -- instead they add a link to the former members section, so that would be a solution for this kind of issue. ^~Hydronium^~Hydroxide^~(Talk)~ 04:18, 24 February 2026 (UTC)

Based on your contribution, this discussion seems to originate from a content dispute involving a temporary account that has since been blocked. As such, it is unclear why the argument is being revisited here rather than being handled on the relevant article's talk page, or whether it is intended to validate that blocked account's viewpoint. Regardless, there is general mutual understanding among most editors that only individuals who officially debuted and/or released work with the act are listed as members. Those involved solely during pre-debut stages, such as auditions or trainings, are typically excluded and do not carry long-term encyclopedic significance in relation to the act. Such information, if sourced reliably, may instead be included in the individual's biographies instead, should they have an article here. This standard has been applied consistently across comparable articles, with limited exceptions that are likely the result of per-article consensus. — 🧧🍊 Paper9oll 🍊🧧 (🔔 • 📝) 03:16, 24 February 2026 (UTC)

So the consensus is only official debuted members are listed, right? ~2026-41110-5 (talk) 07:33, 24 February 2026 (UTC)

For clarity, when I refer to "general mutual understanding", I'm specifically referring to South Korean musical acts only. That wording is intentional and is applied in conjunction with WP:VERIFY. As for anything else, refer to the last sentence in my earlier reply above instead. Additionally, it appears you are conflating two different categories of group formation. Certain Western acts where membership may be tied to founding history, name origin, or early lineup evolution are being treated as directly comparable to K-pop acts, where membership is defined through a formalized debut system and post-debut activity. Applying the same framework to both assumes a one-size-fits-all standard, which does not reflect how these industries function. Because of that conflation, comparisons such as invoking NSYNC to justify listing pre-debut trainees in K-pop groups are not particularly meaningful. For cases outside the K-pop context, exceptions and differing treatments may and or could already be accounted for on a per-article basis, or may not be, as noted previously. — 🧧🍊 Paper9oll 🍊🧧 (🔔 • 📝) 08:25, 24 February 2026 (UTC)

I mean, “pre-debut” means before debut, right?

Before debut = unofficial. Does it mean the same everywhere, or does each country have its own definition of “pre-”? Doesn't matter. It’s still unofficial.

I feel like Wikipedia is turning into a Wiki Fandom now. Why are we including unofficial members / non-final members in the same list as the official members? Where’s the standard? What makes Wikipedia different from Wiki Fandom? It's unofficial, like how I explain it better to you all. It's unofficial. ~2026-41110-5 (talk) 11:07, 24 February 2026 (UTC)

Alright let's summon User:Binksternet who putting Jason Galasso as former member of NSYNC. In his defense, Jason's name was part of the NSYNC name (which is already changed to Lansen). ~2026-41110-5 (talk) 07:47, 24 February 2026 (UTC)

• Why are we having this content dispute on VPP?—S Marshall T/C 10:23, 24 February 2026 (UTC)

  Because it's still about guideline. We are literally talking about an undisclosed guideline for hundred pages related to musical groups. ~2026-41110-5 (talk) 11:27, 24 February 2026 (UTC)

  No we aren't. This decision is fact-sensitive and needs to be made on a case by case basis. It depends on the person's contribution -- did they help write a key song, did they affect the band's development or sound, were they just a hired gun for a few shows? What do the sources say about them? There's no guideline to write. It's a simple matter of editorial judgement. If there's dispute then they don't go in the infobox (WP:ONUS).—S Marshall T/C 12:28, 24 February 2026 (UTC)

  Exactly that's why we are here. You think we are here for planning slumber party? No, we are here for discussion. And there is a big disagreement about whether people should include pre-debut members or not. Did those pre-debut members help the group? Put them on the History section, not the main infobox. That's the function of History section, to tell the story behind the group's creation. Infobox is only for the official information. ~2026-41110-5 (talk) 19:42, 24 February 2026 (UTC)

  Official in whose eyes? Is there an office somewhere where a team of people decide who is official or not? Without answering that queston it's no good bolding "it's unofficial". There are so many differences between times, places, genres and individual bands that it's pointless trying to create a general rule that will apply to everyone. And it seems that by pre-debut you mean before the recording debut. Many notable bands don't make recordings until a few years into their careers. Phil Bridger (talk) 19:42, 25 February 2026 (UTC)

The sources talking about the formation of NSYNC all agree that the name of the band came at a time when bass singer Jason Galasso was in the group. Galasso was warmly received when he joined, with other group members telling him his voice was what they were finally looking for. It was this formation that was deemed ready for a record label deal. Timberlake's mother Lynn remarked that, with Galasso on bass, the group now sounded very much "in sync". They noticed that the final letter of each group member's name could be assembled to form the name NSYNC, with Jason supplying one of the letters. That means Galasso was a foundational member of the group. Supporting sources include a Timberlake bio book and a People magazine piece on Galasso, calling him the "original fifth member of NSYNC".

I don't think there is any basis for artificially drawing a line for the purpose of rejecting Galasso. We should not be determining band membership on our own by saying "pre-debut" or whatever. That would be a violation of WP:No original research. The reliable sources should be telling us who are the group members. Binksternet (talk) 20:40, 2 March 2026 (UTC)

Inclusion criteria for those listed in the Epstein Files and updates to BLP policy

I’d like to invite broader community input on a potential addition to BLP policy. A recurring question has been how, and when, it’s appropriate to tag individuals named in the Epstein files, while avoiding a rush to judgment, guilt-by-association, or the appearance of a witch-hunt dynamic.

Clear inclusion criteria:

1. Only after at least 60 days have passed from the time the subject’s name appears in the released files.
2. The individual is formally under criminal investigation and/or has had criminal charges filed against them.

It seems fairly straightforward, aligns with BLP policy, and should be easy to put into practice. Input welcome. Coffeeurbanite (talk) 19:28, 25 February 2026 (UTC)

This would seem to rule out cases of mentioning other forms of high profile responses to the naming of individuals in the files, such as public protests to remove names from honorary buildings, etc., which seems a bit too broad to do WP:DUE justice. I'm not convinced we need any WP:RULECREEP here other than diligent observance of BLP and DUE. _signed, Rosguill ^talk 19:32, 25 February 2026 (UTC)

@Rosguill: I’m generally in agreement with you in principle. The concern, however, is the lack of consistent diligence in how this is being handled, which risks sliding into guilt-by-association tagging. As I’ve mentioned elsewhere in the project, we’re still in the middle of the immediate fallout. Many responses, whether high-profile or not, are understandably reactionary at this stage. Allowing some time to pass will give us a clearer sense of what is truly warranted and help ensure we’re acting thoughtfully rather than in step with the news cycle. Coffeeurbanite (talk) 19:38, 25 February 2026 (UTC)

And frankly, it may be worth considering a temporary pause as a community, a kind of fail-safe, so we can ensure we’re proceeding carefully and consistently rather than reacting in the moment. Coffeeurbanite (talk) 19:40, 25 February 2026 (UTC)

I'm not sure what you mean by "guilt-by-association tagging". _signed, Rosguill ^talk 20:10, 25 February 2026 (UTC)

The "Epstein Files" are not a secondary source, so, according to policy and guidelines we should not be creating articles about people just because they're mentioned there, or even mentioning them in other articles. The whole of at least the western world seems to have gone into some kind of collective madness over them, as if crucifying everyone who was in touch with one dead sleazebag will fix the problems of misogyny and pedophilia. Yes, they are important, but not so important that we should be changing the policy of an encyclopedia over them. Phil Bridger (talk) 20:35, 25 February 2026 (UTC)

@Phil Bridger: Is content being added to articles based on editors perusing the files themselves, rather than such content being reported in a source? I would agree with a prohibition against additions on that basis. BD2412 T 20:49, 25 February 2026 (UTC)

I can't point you to any existing article, but it looks as if that's what the OP is proposing. Phil Bridger (talk) 21:27, 25 February 2026 (UTC)

Then it's already moot, contentious material can't be added to BLP based on primary documents like the Epstein Files under existing policy. There is no need for additional policy. Katzrockso (talk) 21:40, 25 February 2026 (UTC)

But the OP is proposing to change existing policy about living people to allow that. Phil Bridger (talk) 21:55, 25 February 2026 (UTC)

Yes content is being added based on the primary source. It has started to calm down now, but as they were being released it was happening continuously. That issue is somewhat separate from the issue of inclusion when reported in other sources, but the details are little more than 'guilt by association'. -- LCU ActivelyDisinterested «@» °∆t° 12:30, 26 February 2026 (UTC)

We should mention it when its mentioned in reliable sources. For example, the NY Times is reporting today on Richard Axel's resignation from a Columbia University institute.[8] There's no reason it should be limited to people who are under criminal investigation. Jahaza (talk) 20:44, 25 February 2026 (UTC)

I second this. We report what reliable sources report, and those who dislike the fact that sources are reporting such things can take that up with those sources. BD2412 T 20:47, 25 February 2026 (UTC)

No, 'We report what reliable sources report' has never been Wikipedia policy. We exercise editorial discretion on what we report, depending on what sourcing is available, and on what policies and guidelines advise and/or proscribe (e.g. NPOV, and WP:BLP etc). Wikipedia is not an aggregator of 'everything on the internet' and has never aspired to be. Those who dislike long-standing Wikipedia policy and practice are obliged to conform to it until such time that they can successfully get it changed. AndyTheGrump (talk) 21:11, 25 February 2026 (UTC)

@AndyTheGrump, WP:AGF is also a policy to which we are obliged to conform. Don't assume that others are advocating violating Wikipedia policy.

The context here is a request to make a new time-based rule beyond the rules we currently have. As our content guidelines do say, "Wikipedia articles should be based on reliable, published sources, making sure that all majority and significant minority views that have appeared in those sources are covered" (my emphasis, and parenthetical removed). This doesn't mean ignoring other policies and content guidelines, but it aptly describes when we should add new information to an article all other things held equal. Jahaza (talk) 21:38, 25 February 2026 (UTC)

I'm not assuming anything. I'm stating as a fact that it isn't Wikipedia policy or practice to include everything published in reliable sources, and that including content on that basis alone can sometimes be a clear contravention of WP:BLP policy. As for time-based rules on when something can be included, I'd suggest that we should be exercising editorial discretion based around existing policy, not pulling arbitrary time limits from nowhere. AndyTheGrump (talk) 21:48, 25 February 2026 (UTC)

Being verifiable to a reliable source is something that all included content must have, but by itself it's not an inclusion criteria (WP:VNOT). Inclusion depends on context. One I reverted out was an individual who had reports stating he was called a 'good friend' in the Epstein files, but the context was that they had no contact with Epstein. They were considered a good friend by someone who emailed Epstein. That a friend emailed Epstein was obviously not due for inclusion, whether it was reported on or not. -- LCU ActivelyDisinterested «@» °∆t° 12:38, 26 February 2026 (UTC)

We clearly should wait until either their inclusion has lead to some type of charging or arrest, or has directly impacted that person (eg all the resignations that have happened). BLP reigns here as well as NOTNEWS, it is far better for us to wait to see if being named actually has impact. E are not a newspaper and this is a clear situation we shouldn't be regurgitating what the news puts out just because the name appears. Masem (t) 20:50, 25 February 2026 (UTC)

• My first instinct is to only include when something stems from the subject's listing in the files, such as a resignation or arrest, or if there are more reliable sourced information about the relationship (beyond a mere listing). Also, being mentioned in the files should not mean that a stand-alone page is created. --Enos733 (talk) 21:15, 25 February 2026 (UTC)

On the general question of whether the subject's name appearing in the files could be sufficient grounds on its own, even if discussed in secondary sources, to justify inclusion in articles, lists etc, I'd have to suggest that we'd need in-depth discussion in several sources at minimum. What we must not do, which apparently has been going on at List of people named in the Epstein files is attempt to include individuals on the basis that e.g. 'they were sent an invitation by Epstein', without evidence of even having responded. Even if sourced, this on its own is nothing but guilt by association, and remains so, regardless of sourcing: a gross violation of WP:BLP policy. Possibly 'resignation or arrest' might be stretching things a little to far in the opposite direction, for clearly-notable individuals where there has been extensive discussion in multiple top-quality sources, but in such situations, the primary-source file(s) concerned will only be a minor part of the coverage anyway if they are being reported on. Credible sources aren't going to be built around 'Epstein files' alone, and they will be assessing the content in the broader context of events they relate to. The 'files' themselves - a mishmash of material from the credible to random junk sent by nobody in particular - aren't 'a source' they are an accumulation of primary-source material kept together fundamentally for no greater reason than having the name 'Epstein' in them. We shouldn't be trying to assess them collectively at all. AndyTheGrump (talk) 21:32, 25 February 2026 (UTC)

I'd almost go one step further and posit that List of people named in the Epstein files is borderline violating WP:NOT regardless of what level of "in-depth discussion" merits inclusion in that article. The disclaimer in the lead section of that page does little to dispel the guilt by association here. mdm.bla 04:12, 26 February 2026 (UTC)

That list absolutely needs to go. It only would make sense after all investigations and legal actions are complete with the files, which may be years down the road. Masem (t) 12:35, 26 February 2026 (UTC)

Like I said on the talk page there, the whole concept is a nightmare combination of WP:INDISCRIMINATE and WP:BLPCRIME. The list should be deleted, there are other Epstein pages. Gnomingstuff (talk) 15:47, 26 February 2026 (UTC)

@Masem and Gnomingstuff: There is an ongoing deletion discussion with respect to the list at Wikipedia:Articles for deletion/List of people named in the Epstein files. BD2412 T 18:14, 27 February 2026 (UTC)

I have commented for deletion there. Masem (t) 19:15, 27 February 2026 (UTC)

My first reaction is "why are we limiting it to people in the files?"; if people are facing consequences because of their links to Epstein, that should be enough to be on whatever sort of useful list we want to make. I don't see the point in having a list of the Venn diagram between people suffering for their association and people on the list.

My second thought is that, as phrased (but presumably not as intended), this does not limit it to folks suffering from their relationship to Epstein; if someone's names appears in the files and they get charged with tax avoision, that would seem to qualify.

My third thought is that in the form stated, it does not limit itself to notable people, which brings up WP:BLPCRIME concerns regarding non-notable people charged.

My fourth thought has to do with a scheme to convince Flavor Flav that I am a member of the women's hockey team, and is thus not relevant to this discussion. -- Nat Gertler (talk) 21:36, 25 February 2026 (UTC)

It is entirely possible to be 'in the files' (or rather, in a file in the accumulation of primary-sourced material of mixed credibility known collectively as 'the Epstein files') without having interacted with Epstein at all. For example Janis Joplin and Elvis Presley are both mentioned in 'Epstein files'... AndyTheGrump (talk) 21:42, 25 February 2026 (UTC)

Hey folks. As a possible point of interest, there are now at least three separate discussions on this topic:

• This section
• Wikipedia:Biographies of living persons/Noticeboard#We need a clear policy about being in the Epstein Files
• Talk:List of people named in the Epstein files#Inclusion criteria - second draft

— Mudwater ^(Talk) 12:53, 26 February 2026 (UTC)

I resemble these remarks. Walter not in the Epstein files Ego 15:58, 26 February 2026 (UTC)

• To clarify, I was thinking about this in terms of whether the subject is either identified directly in the list itself (as a primary source) or mentioned in reliable secondary sources as appearing on the list. My concern is that there is a wave of resignations or removals that are occurring regardless of whether any criminal conduct occurred. If subjects are notable, those resignations or removals are likely to be covered in secondary sources, but that still reflects reactionary fallout rather than confirmed wrongdoing. So my question still stands, can we build in some sort of temporary pause? Coffeeurbanite (talk) 16:32, 27 February 2026 (UTC)

Users without extended permissions should be allowed on talk pages of extended-protected articles

I fully agree that newer users should not be allowed to edit extended-protected articles due to the risk of vandalism and heavily-biased editing, but what's the harm that could be done if normal users are allowed to simply talk about potential edits? The worst that could happen is that the talk page section gets a little bit toxic (and that's assuming that the admins aren't able to stop that with warnings/sanctions), and all that it does is that it prevents newer users with potentially good ideas from contributing. (And yes, there is the edit request wizard, but that does not allow for the same freedom or ease of discussion as participating in a talk page does.)

So yeah, only long-time editors should be allowed to edit extended-protected articles, but I don't get why that has to apply to talk pages of those articles as well. QuisEstJoe (talk) 21:27, 1 March 2026 (UTC)

@QuisEstJoe: Non-EC editors used to be permitted to make constructive comments on talk pages subject to ECR, but that clause was struck in favor of only permitting edit requests [...] provided they are not disruptive following a filing at ARCA and an 8-0 decision in favor of removing the constructive comments clause by the Arbitration Committee. Tl;dr, the previous language was problematic as non-EC editors were still prohibited from participating in RfCs, AfDs, etc. I'll especially encourage you to read the statement by ScottishFinnishRadish for the problems with allowing non-EC editors to participate beyond making edit requests. mdm.bla 21:55, 1 March 2026 (UTC)

Non-EC users are allowed to post on the talk pages of EC-protected articles (see the talk page of Donald Trump, for example). I'm assuming you mean articles under WP:ARBECR. Some1 (talk) 22:25, 1 March 2026 (UTC)

@QuisEstJoe: With the exceptions of the Arab-Israeli conflict, the Nagorno-Karabakh conflict, Kurds, the Russo-Ukrainian war, South Asian castes/tribes and Indian military history, any user can and should be able to edit the talk page of an article under extended-confirmed protection. The extended-confirmed restriction, as Mdm.bla says, was stiffened because the people who were causing problems on articles under 500/30 restrictions simply shifted their attention (and thus aggression, inability to shut up, and unwillingness to change the subject) to the talk pages instead of finding somewhere that isn't a powderkeg looking for a lit fuze. —Jéské Couriano v^_^v ^{threads critiques} 20:07, 2 March 2026 (UTC)

Abuse of Wikipedia by AI

It seems a third of the sources used to train AI is material from Wikipedia. Shouldn't something be done about that? We all are doing this for free to inform people, not to support billionaires AI investments who can push out the people of their daily jobs. I've been working on several Wiki's in different languages, and I have the feeling my work is stolen by big companies. — Preceding unsigned comment added by ~2026-13646-72 (talk) 19:49, 2 March 2026 (UTC)

1. Do you have sources to prove that "a third of the sources used to train AI is material from Wikipedia)?
2. Who cares if we're "supporting" billionaires? Not only is that a major oversimplification of the AI debate (more people use and are affected by AI than just the billionaires), but you also support billionaires through the brands you use in your day-to-day life (such as the device that you use to edit Wikipedia on, which was made by a company run by a billionaire), so the billionaire point doesn't hold much weight.
3. Where is the evidence that AI hasn't created more jobs than have lost, and what about the people whose jobs have been improved by AI (such as programmers, engineers, or medical researchers)? Besides, ending jobs doesn't make something automatically wholly evil; the internet has put a lot of jobs at stake (online shopping, for example, has put many brick-and-mortar stores on the line), yet that does not mean we should just forget about the benefits of the internet. The same thing can be said about AI.
4. How is AI analyzing information to train its ability to make something completely different "stealing?" Besides, your work on Wikipedia isn't wholly "your" work; not only have many other editors contributed to the articles that you have wrote on, but you and other editors have gotten "your" info from other sources, so it's not like AI is "stealing" your personal, wholly-original creation. Besides, Wikipedia is not meant to be anyone's source and its use is not meant to be restricted; it's meant to be a free-to-use platform for anyone to gain information. Why does that stop with AI analyzing that information? Furthermore, why doesn't it stop with others using Wikipedia as a source to get information for their own projects? I don't think you would get mad at someone on YouTube "stealing" from Wikipedia articles to get the info they need for their video essay.

QuisEstJoe (talk) 21:53, 2 March 2026 (UTC)

When you edit Wikipedia, you are agreeing to allow your work to be used by anyone in any way, basically. We don't have a way of excluding big companies (and indeed, some huge ones like Google use it in very obvious ways), and it would not serve the stated goals of the project if we did start excluding. -- Nat Gertler (talk) 22:00, 2 March 2026 (UTC)

I am not a fan of AI, but one of the pillars of Wikipedia is that all editors freely license their work to the public, and no editor owns an article – any contributions can and may be mercilessly edited and redistributed.

Whatever wikis you're working on probably have AI cleanup efforts you may be interested in. Gnomingstuff (talk) 02:47, 3 March 2026 (UTC)

I am not agreeing to allow my work to be used by anyone in any way. Wikipedia:Reusing Wikipedia content: Wikipedia's text content ... can be used under the terms of the Creative Commons Attribution Share-Alike license (CC BY-SA)... To re-distribute a text page in any form, provide credit to the authors... If you make modifications or additions to the page you re-use, you must license them under the Creative Commons Attribution-Share-Alike License 4.0 or later. Outside of that, the copyright reverts back to me. Hawkeye7 (discuss) 03:22, 3 March 2026 (UTC)

I desire to see a source for your claim. Also, you agree by using Wikipedia that "agree to irrevocably release your text under the CC BY-SA License and GFDL." And "You agree that a hyperlink or URL is sufficient attribution under the Creative Commons license." This means that an AI agent providing a link to the Wikipedia page is enough to disqualify you from saying your work was stolen. You did agree to allow your work to be used. ~2026-11404-95 (talk) 19:48, 3 March 2026 (UTC)

This is what it means to license your work under a copyleft licence: you can't restrict who reuses your work if they meet the terms of the licence. And something is being done, by Wikimedia Enterprise getting Big Tech to pay for high-volume access without taking down the servers. See the various news reports following their announcement on our 25th birthday, such as this one in Ars Technica. ClaudineChionh (she/her · talk · email · global) 21:45, 3 March 2026 (UTC)

Hi ~2026-13646-72

The "one third" number needs a source, but yes, AI companies scrape Wikipedia for training data, this is a known fact. They are allowed to, under the CC BY-SA license, but other editors have identified that there is still the issue of attribution. As I understand it (I am not a lawyer), the considerations for licensed works used for training data is a legal grey area. And I agree, it does suck, because I agree that the AI industry sucks.

There's two senses in which you could say Wikipedia could "do something" about this. You either mean the Wikipedia community (the volunteer editors who edit Wikipedia), or the Wikimedia Foundation (the non-profit that hosts the website itself). I don't have much to say for what the Wikimedia Foundation could do.

For what the community could do, Wikipedia isn't really here to right great wrongs; we don't organize protests or anything, we're just here to build an encyclopedia, and we certainly shouldn't artificially inject anti-AI bias into the encyclopedia. You can, however, help chip in over at the AI cleanup efforts! We do (on the whole) consider using LLMs to contribute to Wikipedia to be abusive, but many folks try it anyways, and it takes no small amount of volunteer effort to deal with that abuse. You could always become an editor and assist over at WP:AINB. MEN KISSING (she/they) T - C - Email me! 20:10, 4 March 2026 (UTC)

I honestly don't even think that it sucks that much because Wikipedia is supposed to be a free-to-use encyclopedia for everyone to use, and suddenly closing that off to AI training itself because it's using "stolen" data is both unfair and nonsensical. If you come to Wikipedia to create "your own" article for yourself (which, just to be clear, I'm not saying that you in particular are), you're kind of missing the point of Wikipedia. Besides, it'd be one thing if this was an art-sharing or fiction-writing forum where we publish artistic expression, but saying to someone training AI that they can't use an article of real-world facts because "that's MY article of facts that I have the right to" is simply selfish. QuisEstJoe (talk) 20:40, 4 March 2026 (UTC)

Well, the sentiment against AI scraping of Wikipedia is not only based on the idea of content ownership being violated. It's a complicated issue with a lot more moving parts than that.

This more gets into the wider politics surrounding AI, and I'm sure that can be quite polarizing, so I'm not too eager to dig into it. But perhaps that wider conversation is one we should have, because some of the involved politics is quite relevant to the Wikipedia project. MEN KISSING (she/they) T - C - Email me! 22:32, 4 March 2026 (UTC)

As others have explained above, whether you're fond of LLMs or not, it would be antithetical to the purpose of Wikipedia for us to impose restrictions on who can use its content, and for what purpose. That is the entire point of calling Wikipedia the "free encyclopedia"—not only in the sense that anyone can edit it, but also in the sense that anyone can use it, reuse it, reproduce it, redistribute it, etc. Kurtis ^(talk) 14:48, 5 March 2026 (UTC)

Alternate potential usage of LLMs in editing Wikipedia—what is permissible, and what is not?

Say, for example, you have an editor who's written an article about XYZ. It is well-written, well-sourced, comprehensive, and it's about an actual person who actually lived. They get it to GA-status, and eventually, to FA-status. But later on, they admit that they used ChatGPT in helping them to create that article. They explained the process that they used in doing so:

• First, they found a bunch of reliable third-party sources about the subject in question.
• They use the following prompt to get ChatGPT to generate text: "Create a comprehensive overview of XYZ using the copy-pasted text provided below the horizontal line. Format this overview in the style of a Wikipedia article."
• They double-space, add three underscores (the "horizontal line"), and then copy large chunks of text from the various sources they've assembled, sectioning them according to the source from which they were excerpted.
• ChatGPT generates the text of a Wikipedia article; the user copies and pastes it into Google Docs.
• They then begin using their sandbox and the preview button to prune, paraphrase, copyedit, fact-check, expand, and further "Wikify" what ChatGPT generated.

By the time they're through with their work on the article and are ready to submit it, it can no longer be readily identified as AI-generated—it is almost entirely in their own words, using sources that they compiled. They checked it for factual accuracy, and they made sure that everything flowed together smoothly.

In your view, is this still a problematic use of generative AI for the purpose of editing Wikipedia? If so, why do you consider it problematic? And if an editor confessed to doing something like this, do you feel they should face sanctions for having done so? Kurtis ^(talk) 15:23, 5 March 2026 (UTC)

• Your example isn't realistic. If a person is going to rewrite an LLM-generated article so that every word in it is their own, then what's the purpose of LLM generation in the first place? ~2026-14165-49 (talk) 17:08, 5 March 2026 (UTC)

  Exactly. See my post below. EEng 17:16, 5 March 2026 (UTC)

  They would use it as a springboard to actually building a proper article, and to make the whole task feel significantly less daunting. Kurtis ^(talk) 17:17, 5 March 2026 (UTC)

  It can only "feel significantly less daunting" if they skip all the hard parts of writing an article i.e. gathering and internalizing the sources, selecting the facts for presentation, deciding on article organization, and so on. Your "springboard" is, in fact, a nice way of saying, "A way of letting people who aren't able to usefully contribute, feel like they're usefully contributing". Things like you're proposing will be the death of Wikipedia. EEng 17:32, 5 March 2026 (UTC)

• It's problematic because it's fiction. The fact-checking part would never happen, because by the time you prune, paraphrase, copyedit, fact-check, expand, and further "Wikify" what ChatGPT generated you could have just written the article from scratch with less effort (not to mention less chance of AI excrement slipping through). Anyone with sufficient competency to do what you describe would know this, and so would know better than to actually do it; therefore those who claim they're doing it actually aren't competent to do so (even if they fool themselves into thinking they are, in fact, doing so -- Dunning-Kruger). That's why there's no use case for AI-generated content, and why those who use AI to generate either article content or talk-page posts are, ipso facto, incompetent and should be blocked on sight. EEng 17:16, 5 March 2026 (UTC)

The reason I would think of for someone doing this, even if it ultimately expends the same amount of effort as simply writing the article from scratch (if not more), is because it might make the act of actually writing an article soup-to-nuts feel less daunting. Logically, anyone would surmise that they're just doing content creation in a roundabout way, but the sight of a "completed" article with flaws might give them more of an impetus to develop and build upon what was generated. It could create the illusion of editing rather than building an article from the ground up. Kurtis ^(talk) 17:27, 5 March 2026 (UTC)

"Illusion of editing"? You want us to foster an "illusion of editing"??? EEng 17:33, 5 March 2026 (UTC)

Was it not clear what I was attempting to convey? By "illusion of editing", I meant that it would feel more like editing an article as opposed to writing an article from scratch, even if that is functionally what it is. Kurtis ^(talk) 17:41, 5 March 2026 (UTC)

No, it was not clear. In general, most "editing" (in the sense you're using the word) involves improving presentation, copyediting, maybe pruning out UNDUE cruft, by making incremental changes to an article which is assumed, by default, to be verifiable, free of copyvios, and otherwise in conformance with key policies. What you're proposing is that we allow an inexperienced user be presented with a ton of material which without question is studded with hidden crap, and expect that user to find and remove all that hidden crap. EEng 23:06, 5 March 2026 (UTC)

Say, for example,

Nope, start over and try again. Which specific Featured Article are you vaguely alluding to in this hypothetical?

Anyway, your thought experiment here has a lot of problems:

• WP:LLMDISCLOSE strongly recommends that people disclose AI use from the get-go, in all associated edit summaries. This is not an outrageous, time-consuming thing to do. Here's an example of someone doing it usefully in good faith.
• Your sense of how the average AI Featured Article comes about is unrealistic. Based on the cases I've seen, the more common scenario is that AI is used to find the sources (potentially introducing non-reliable sources/WP:UNDUE emphasis/bias), to summarize those sources (likely introducing source-to-text integrity issues), and copyediting/rewriting existing text (potentially introducing tone issues, and distortion of meaning).
• There's no way to prove the negative here, but many articles that people think "can no longer be readily identified as AI-generated" can be identified as AI-generated in about 15 seconds if you know what you're looking for. I've flagged several GAs and FAs as AI-generated (and was right), and there are several more GAs and FAs that I'm pretty sure contain AI text but haven't bothered to flag because I don't really feel like getting into even more arguments than I already do. (Panic Room, it's your time to shine!)
• There's no way to prove how much fact-checking people do, but in my experience, when I spot-check sentences and claims that obviously came out of an LLM, the citations do not often verify the text, and sometimes they don't even come close. WikiEdu found last year that of the AI-generated articles they flagged, nearly every cited sentence failed verification. Similarly, a lot of AI text has a sheen of promotional tone that, for whatever reason, just doesn't register on some people's radar no matter how obvious.

Gnomingstuff (talk) 18:10, 5 March 2026 (UTC)

@Gnomingstuff: Which specific Featured Article are you vaguely alluding to in this hypothetical?—It really is just a hypothetical, but in the interests of disclosure, it's an idea that I'd been mulling over in recent times. Over the past few years, my executive dysfunction due to ADHD-PI has worsened (I suspect due to Long COVID-related brain fog), and so I have difficulty motivating myself to write much of anything. I've played with the idea of using ChatGPT to create a sort of "skeleton" for an article, or for generating something that I could use as inspiration. I want to be very clear: if I add something to Wikipedia, you can rest assured that it will have been thoroughly fact-checked and well-sourced, and each claim that has a reference attached to it is directly and explicitly verified by that reference. However, I was unsure of how the community would respond if I were to write an article, and then disclose that I had used ChatGPT to lay down a "blueprint" of sorts. I genuinely think that for a lot of editors, this would be seen as a serious breach of trust, even if what I submit is qualitatively different from what ChatGPT spat out; it effectively circumvents much of the article-writing process. I'm not sure if an editor who did this would be blocked for doing so, but I do think it would cast their integrity and their critical thinking skills into doubt, and it might trigger a review of whatever content they'd submitted using this approach.

Your linking of LLMDISCLOSE demonstrates that current community practice is more nuanced than I would have expected. Disclosure of using an LLM strikes me as the ethical thing to do, but it's fraught with risk. A lot of editors who attempt something like what I've described would probably opt against doing so, as it would undermine trust in them if they openly acknowledge using such a tool. Kurtis ^(talk) 03:30, 6 March 2026 (UTC)

A lot of editors who attempt something like what I've described would probably opt against doing so, as it would undermine trust in them if they openly acknowledge using such a tool.

I mean, it also undermines trust to learn about something the community strongly recommends doing (I realize LLMDISCLOSE is not really publicized that well) and decide "no, I'm not going to do that." It usually undermines it more -- generally if people are sanctioned for using AI it's because they are evasive about it, meanwhile there are a couple of people who are open about their process with AI who are not. Gnomingstuff (talk) 14:34, 6 March 2026 (UTC)

WP:LLMDISCLOSE is an essay. Nobody has to follow it, it's optional. Cambalachero (talk) 16:05, 6 March 2026 (UTC)

Correct that no one has to follow it, but undisclosed LLM use will undermine trust with many people in the community, which is what the essay WP:LLMDISCLOSE is trying to help editors understand. On the other hand, disclosure is a good way to WP:DGF: Conversely, clumsily using an LLM in a transparent manner, promptly receiving relevant feedback, and responding reasonably to that feedback, would generally mean that the user is able to receive the message, following which they are just expected to improve their editing, motivated by what is in Wikipedia's best interest. -- LWG ^{talk (VOPOV)} 16:34, 6 March 2026 (UTC)

I have tried this before on a couple of articles and it turned out to be more work than just writing from scratch. So I would find it problematic for an editor to do this regularly because once you have built the writing muscle, that is so much easier than using the chatbot. 📎 JackFromWisconsin (talk | contribs) 19:09, 5 March 2026 (UTC)

I should probably clarify that the above hypothetical was devised for demonstrative purposes. The fundamental question is: if someone admits to using generative AI for any facet of content creation, but doesn't specifically use it to actually generate content, is that still something that we should explicitly refuse to tolerate? Kurtis ^(talk) 18:07, 5 March 2026 (UTC)

Opinions vary on that point, but as EEng said, the non-hypothetical reality is that few to no examples of LLM use like you describe have been seen in the wild so far, while the LLM text we are actually seeing overwhelmingly fails verification. -- LWG ^{talk (VOPOV)} 19:38, 5 March 2026 (UTC)

There was an RfC about this topic only a few months ago. Gnomingstuff (talk) 19:40, 5 March 2026 (UTC)

Should something like the hypothetical scenario described ever actually come up… we can always look into it and decide on a case by case basis.

My one thought is that the editor in question made their job much harder by using the LLM… by simply summarizing the source material in their own words (from the get go) they could have saved themself a lot of extra steps (extra time and effort). Blueboar (talk) 20:37, 5 March 2026 (UTC)

• This reads like ragebait. Why would adding fact-checked, human-written material be problematic? (But the bait has inevitably been taken).Wh1pla5h99 (talk) 00:38, 6 March 2026 (UTC)

  To be clear, please: what reads as ragebait? EEng 02:37, 6 March 2026 (UTC)

  The whole post has the whiff of "let me act as if I need help tying my shoelaces". Wh1pla5h99 (talk) 02:45, 6 March 2026 (UTC)

  If an LLM is involved in any part of the process, it could cast the integrity of the editor into doubt in the eyes of many, even if they did their due diligence in ensuring that what they add is quality content. Kurtis ^(talk) 03:33, 6 March 2026 (UTC)

  I don't know why you would be worried about that. Wh1pla5h99 (talk) 04:45, 6 March 2026 (UTC)

  If an LLM is involved in any part of the process, it could cast the integrity of the editor into doubt in the eyes of many

  That's something they need to own, then. Gnomingstuff (talk) 14:29, 6 March 2026 (UTC)

• For things that involve actual writing, genAI's a net negative and I agree with EEng's scorched earth philosophy. But I think it's worth pointing out that a tool linked on WP:ATODAY was created using Claude AI, and having used that tool personally, it's pretty good. This is obviously not what you mean by genAI editing, but it uses genAI and it's for editing Wikipedia. It's worth stating the obvious that a tool like this can also be created without the assistance of AI, and I wouldn't be surprised if it would've been easier to do so. Tessaract2^Hi! 02:29, 6 March 2026 (UTC)
• I am curious. Two editors cite the high proportion of LLM generated text that "fails verification", and one example cites the WikiEdu process where we encourage newbie students to edit Wikipedia. What proportion of non-LLM-generated text on Wikipedia also "fails verification" (putting, presumably, our "I'm going to be strict" hat on). And what proportion of newbie student edits either fail verification or could be described as "hallucinated" or "clearly doesn't have the first clue" or "wouldn't make that mistake if they were an experienced editors like we all are".

To pick an article I hoped wouldn't be AI generated, I chose the User:Gnomingstuff's Agnes Grozier Herbertson. The first fact "(c. 1875 – 1958)" I'm going to guess appears somewhere in the 462 pages of the "The Oxford Companion to Edwardian Fiction". The citation lacks a page number. The second fact "a Norwegian writer and poet" I can characterise as "fails verification". A source cites Norway as her place of birth, but having Scottish parents, growing up in Scotland and later living in Oxford and Cornwall, and writing English-language works, I'm pretty sure there are no serious reliable sources describing her as "a Norwegian writer and poet". Our WP:MOSBIO says not to describe someone's nationality by their place of birth.

If I ask CoPilot "is Agnes Grozier Herbertson a Norwegian writer and poet" it replies: "Yes — Agnes Grozier Herbertson was a Norwegian writer and poet. According to multiple reliable sources, she was born in Oslo (then Christiania) and is consistently described as a Norwegian writer and poet, even though she later lived in the United Kingdom." The so-called "multiple reliable sources" include the Wikipedia article and another that appears to have lifted some text from the Wikipedia article. This makes me reasonably sure that falsehoods that fail verification predate the AI plague on Wikipedia, and that our fallible human editors are themselves the source of a great deal of AI's incorrectness. -- Colin°^Talk 14:36, 6 March 2026 (UTC)

Please don't ping me for discussions I am already aware of. The article isn't AI-generated, thanks for pointing out the style and sourcing discrepancies.

That being said, "fails verification" in the context of AI generally means that AI attaches a source to text when the source does not back up that text, and sometimes may not say anything even remotely like it. Generally this suggests that whoever added it didn't even bother reading the source (considering that many such issues can be found in 5-10 minutes' worth of spot checking). It doesn't generally mean unsourced content. Gnomingstuff (talk) 15:17, 6 March 2026 (UTC)

EDIT CONFLICT - basically what the unpingable user above said: There is no source attached to the claim of Norwegian nationality there, so this is not a source-text-integrity issue. No one is claiming that humans are infallible, what we are claiming is that AI routinely places in-line citations on text that those citations do not verify, and that a human who read and comprehended the source would be unlikely to think they did verify. -- LWG ^{talk (VOPOV)} 15:29, 6 March 2026 (UTC)

For comparison, here are articles generated from those sources using Grok and using ChatGPT, so you can compare and see how the source use and style issues differ. -- LWG ^{talk (VOPOV)} 15:50, 6 March 2026 (UTC)

Maybe I'm misunderstanding, but I'm seeking two pages listing prompts you used but not the results that you got from them. -- Nat Gertler (talk) 17:52, 6 March 2026 (UTC)

Technical

Un-hidable(?) new UI decoration taking up lots of screenspace

"synthesizer-idle-light.webp" is randomly appearing in a new right-hand pane of some pages, knocking about 20% off the window width available for content. It's where one of the UI menus had been until I hid it a long time ago. There were many discussions, resulting in consensus that we should allow articles to fill the full screen-width by collapsing or hiding various panes and the TOC. This thing has no close button or explanation what it is, and clicking on it also does nothing useful except change it to a slightly different image. Please make it go away (or a simple "[x hide]" button on it). DMacks (talk) 03:04, 24 February 2026 (UTC)

Does it always appear on the same random pages? Or does it randomly appear and disappear even on the same page/article? – Scyrme (talk) 03:12, 24 February 2026 (UTC)

DMacks, please link to example pages. Take a screen shot if you can. Let us know what browser, skin, and view (mobile or desktop) you are using. Does it happen when you are logged out? Does it happen in a different browser? – Jonesey95 (talk) 03:18, 24 February 2026 (UTC)

if I am not mistaken, the initial idea was to have the globe appear really at random, but it apparently was a performance issue so it is now limited to just 2,500 articles at the most. The WMF team has narrowed down to a predefined list of 2,100+ articles leaving 300+ slots for local projects to determine which other articles to put up. Of course, we can also override the predefined list in whole or in part and curate the full 2,500 articles to show. – robertsky (talk) 16:13, 24 February 2026 (UTC)

@DMacks: If it's always appearing on the same pages, it may be related to "birthday mode". Does it still appear after toggling birthday mode off in your preferences? Or did you already do that? – Scyrme (talk) 03:18, 24 February 2026 (UTC)

I'm fairly certain it's just birthday mode now. I was confused because you quoted .webp (static image) instead of .webm (animation). You can toggle it off in the "Appearance" tab of your user preferences. – Scyrme (talk) 03:30, 24 February 2026 (UTC)

It seems consistently on Ney but consistently not on other pages I've visited lately. Desktop-mode on a desktop computer running firefox, vector 2022 skin. Does not appear when I'm in private-browsing non-logged-in mode. Looks like it is indeed birthday mode, and the pref toggle turns it off. Given that clicking on it does nothing useful, the only way I could even see what to call the image was by browser right-clicking "open image in new tab" and copying the filename. So now I merely emphasize that it's a problem there's no way to know what it means (why doesn't it link somewhere?) or where to turn it off (contrary to closure statement at Wikipedia:Village pump (proposals)#requests for comment on enabling the 25th anniversary birthday mode). DMacks (talk) 03:35, 24 February 2026 (UTC)

There's also a toggle to enable/disable it on Wikipedia's welcoming portal. It would probably be a good idea if the mascot animations linked somewhere, like the link I posted earlier as that page explains why it's there and how to toggle it off if you'd rather not have it. Doing it that way would likely be easier to implement than adding a toggle switch to every page it appears. – Scyrme (talk) 03:47, 24 February 2026 (UTC)

Sure. Anything that lets me know something about it would be an improvement. DMacks (talk) 03:54, 24 February 2026 (UTC)

I just noticed it can also be disabled from any page just from the same menu/sidebar that controls light/dark mode, so there actually is a toggle on every page already. – Scyrme (talk) 03:54, 24 February 2026 (UTC)

There's also a "Learn more about Birthday mode" link under the toggle in the same menu/sidebar. Still a bit confusing if you have the settings hidden as a menu rather than docked to the sidebar. I didn't immediately think to look there. – Scyrme (talk) 03:58, 24 February 2026 (UTC)

I see just an empty sidebar. IIRC Birthday mode is on. ~2026-12471-74 (talk) 08:34, 25 February 2026 (UTC)

Many images display a “broken file” symbol instead, but that is something else (and might be why I can’t see it) ~2026-12471-74 (talk) 08:40, 25 February 2026 (UTC)

If anyone needs articles for testing where the baby globe appears: Animal, Paul Thomas Anderson, Chloé Zhao, 79th British Academy Film Awards, Sun, Venus, Earth, Mars, Computer science, Ney, Music, The arts, Journalism. —⁠andrybak (talk) 04:39, 24 February 2026 (UTC)

@DMacks: meta:Wikipedia 25/Easter egg experiments. You can turn it off for yourself Special:Preferences#mw-prefsection-rendering by unchecking the cryptic "Birthday mode (Baby Globe)". The list of pages it appears on is configured at Special:CommunityConfiguration/WP25EasterEggs.

Any admin could turn off the "Enable by default" option, and while I don't want to be the one to throw that switch, we shouldn't be enabling it by default unless those annoying animations also included a link to the preferences section to turn them off, and the preference was clearly labeled as something like "Display animated globe mascots on select pages". --Ahecht (TALK
PAGE) 15:11, 24 February 2026 (UTC)

Note that S Marshall's close at Wikipedia:Village pump (proposals)#requests for comment on enabling the 25th anniversary birthday mode was that there was consensus to enable this feature by default if there is a prominent button to disable it, preferably on every page where birthday mode affects the user experience. Since the latter didn't happen (just a cryptic checkbox buried in preferences), we should consider not enabling it by default. --Ahecht (TALK
PAGE) 15:24, 24 February 2026 (UTC)

Also pinging @Robertsky who implemented Special:Diff/1338834608/1340087942. --Ahecht (TALK
PAGE) 15:27, 24 February 2026 (UTC)

If there's no button to switch it off then this should be disabled instantly.—S Marshall T/C 15:29, 24 February 2026 (UTC)

The button to disable it is on every page, in the Appearance menu. – robertsky (talk) 15:51, 24 February 2026 (UTC)

A key is that it's if you have such a menu. And if you don't, you don't know you need to find it for this situation. DMacks (talk) 17:35, 24 February 2026 (UTC)

The menu is there. On Vector 2022 skin, the Appearance menu accessible from the glasses/eyewear icon next to your username in the top menu bar by default, unless you have the Appearance menu already opened in the sidebar. – robertsky (talk) 18:34, 24 February 2026 (UTC)

Right. I know I have that menu hidden there, but we're still in "you don't know you need to find it". Is this a site appearance thing? A new functional feature in general? Something specific to the one page where I see it? DMacks (talk) 18:57, 24 February 2026 (UTC)

I would say that off the bat, most readers (as there are many more anon readers than power users like us) would know where to look for the button to hide the baby globe and the learn more page as well as the Appearance menu is in the sidebar by default, and that's immediate below the baby globe image in the sidebar if it is appearing. It can't get anymore prominent than that.

Your personal experience indicates otherwise, which is why my ping below supporting the idea of have [x hide] button. To further refine that idea, the [x hide] or even a learn more link button should be around the baby globe only when the Appearance menu is hidden. – robertsky (talk) 19:17, 24 February 2026 (UTC)

I have more than twenty years of Wikipedia experience, and it took me about me about ten minutes to find it. Until presented with very convincing evidence to the contrary, such as a design research with multiple diverse people who aren't experienced editors, and who were able to easily find how to disable it, I will assume that it is hard for most people to find how to hide it.

The current situation is nowhere near the consensus of "place a reasonably prominent button to disable it".

It's unreasonable to place an unrelated (!) and animated (!!!) thingie on lots of articles in the first place, but if anyone at the WMF really wanted to put it there, it should at least be easy to hide. It isn't. Amir E. Aharoni (talk) 00:16, 26 February 2026 (UTC)

"I did find the notice...It was on display in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying ‘Beware of the Leopard'"

This needs to be removed immediately until a solution that clearly tells the user how to disable it is part of it. Masem (t) 02:02, 26 February 2026 (UTC)

@Robertsky Ahh yes, the button labeled "Birthday mode (Baby Globe)", which in no way says "Turn off this distracting animated cartoon that's taking up a large portion of my page". If I hadn't seen this conversation, there's no way I'd know what the heck that means. --Ahecht (TALK
PAGE) 15:56, 25 February 2026 (UTC)

The [x hide] idea might be a good thing to implement though. Pinging @CDekock-WMF. – robertsky (talk) 16:02, 24 February 2026 (UTC)

Why isn't the video even clickable? It should have linked to a landing page somewhere. When I saw the video there on its own, I thought my computer was hacked. ~2026-12306-86 (talk) 02:35, 25 February 2026 (UTC)

Hello @Robertsky, thanks for the ping! Unfortunately, changes to Birthday mode aren't possible due to the limited-time nature of the feature. Since Baby Globe will only be visible on a small number of pages for one month, it’s not something we can prioritize for any further iterations. CDekock-WMF (talk) 12:15, 25 February 2026 (UTC)

@CDekock-WMF Maybe a minor modification could fix the concerns voiced here. Here's what I get in mobile view with Vector 2022:

There's a bold blue link to the settings where I can turn off the globe with one click. Nice! As far as I can tell, everyone here would be happy with this.

But here's what I get in desktop view with Vector 2022:

No link, no indication how I can turn this off. :-(

Anyway, that's what I got a few minutes ago. Now I don't see the globe anymore, just empty space. What happened?

— Chrisahn (talk) 13:01, 25 February 2026 (UTC)

Now I see the globe again. Maybe my network was flaky. — Chrisahn (talk) 13:05, 25 February 2026 (UTC)

Mobile view is Minerva, not Vector 2022. The link to turn it off in Vector 2022 is under the "Appearence" menu, which is uncollapsed by default but is collapsed in your view (under the glasses icon). There's a switch that lets you disable birthday mode directly on the page without having to open preferences. SuperPianoMan9167 (talk) 13:21, 25 February 2026 (UTC)

I know how to turn it off. That's not the point. The RFC that decided to enable this on the English Wikipedia said it should only be enabled if there is a prominent button to turn it off. That hasn't been done. That's the point. — Chrisahn (talk) 17:05, 25 February 2026 (UTC)

@CDekock-WMF any qualms from the development team if a volunteer steps in and muck around the extension to bring the idea using with phab:T418428 then? I don't mind rolling up my sleeves over the weekend on this. – robertsky (talk) 06:46, 26 February 2026 (UTC)

Wow, @Robertsky, what an offer! Thank you! Let me check in with the team on whether there are any reasons not to do things this way around. I'll get back to you later today. CDekock-WMF (talk) 10:06, 26 February 2026 (UTC)

Hello again @Robertsky, apologies for our delay in responding here. Thank you again for the offer to collaborate on this and improve the feature! We have been doing some work in the background to make sure we can support any code contributions from editors on this. We now have an engineer on standby to help review tweaks you may want to make. CDekock-WMF (talk) 16:03, 3 March 2026 (UTC)

• Turn this off. Please disable this feature until there's a reasonably prominent button to disable it on every page where it affects the user experience. Not hidden in a menu. On the page. Turn it off. Please turn it off.—S Marshall T/C 12:02, 25 February 2026 (UTC)

  I'd like to apologise wholeheartedly to the community for my role in this. :( I'm appalled.—S Marshall T/C 12:27, 25 February 2026 (UTC)

  @S Marshall: Perhaps you can go to Special:CommunityConfiguration/WP25EasterEggs and turn it off ("Default state for Birthday mode" to "Disabled") directly? (I thought only intadmins could, but now I see Robertsky is not one.) Nardog (talk) 13:20, 25 February 2026 (UTC)

  @Nardog It's any admin, not just intadmins, but S Marshall is not an admin. --Ahecht (TALK
  PAGE) 15:57, 25 February 2026 (UTC)

  The button to turn it off is only hidden in a menu if you have the "Appearance" menu collapsed. Otherwise, it's very prominent. SuperPianoMan9167 (talk) 14:10, 25 February 2026 (UTC)

  The cryptically labeled "Birthday mode (Baby Globe)", which I'd have to follow a link to find out what it means? It should be, at the very minimum, indicate that "Baby Globe" is an animated figure -- I'd have no idea what that means otherwise. --Ahecht (TALK
  PAGE) 15:59, 25 February 2026 (UTC)

This thing is completely unacceptable. It's extremely distracting. It's literal torture for me to see an unrelated animated thing and try to read something at the same time.

It took me about ten minutes to find how to disable it deep in the sidebar, and I've been writing on Wikipedia for more than twenty years, and programming MediaWiki for fifteen. I cannot imagine what do less experienced readers go through.

I've just reported https://phabricator.wikimedia.org/T418428 . If it's not addressed by tomorrow, I plan to use my sysop rigts to force-disable it for everyone in Common.css. Can anyone give me a reason not to do it? --Amir E. Aharoni (talk) 23:53, 25 February 2026 (UTC)

Yes. Force-disabling it for everyone would violate the explicit consensus of the Wikipedia community to have the feature on by default. SuperPianoMan9167 (talk) 00:47, 26 February 2026 (UTC)

The consensus summary says that there must be a "reasonably prominent button to disable it". There is no such button. There is a button, but it's nowhere near being "reasonably prominent". So the consensus was violated by whoever enabled the button, not by who will disable it. Amir E. Aharoni (talk) 01:17, 26 February 2026 (UTC)

Every logged out user who views it (who are the vast majority of users) has a prominent button to remove it by default, and they are the 99%. That it took you 10 minutes to remove it is, accordingly, not going to be the average experience, even if it took that long for every logged in editor to find the "goodbye" button.

I'm not a fan of someone who has sysop rights threatening to remove it by CSS when there is a plausible consensus quite established that says it should be enabled.

Moreover, for someone who has been a MediaWiki developer for 15 years, it is shocking to find you entirely missed the deployment of the interface administrator user right close to a decade ago, which you do not hold. I would oppose your stated reason for requesting that right, should you choose to do so in the meantime.

If you are so firmly against it, you should instead use your knowledge as a developer to submit a patch to disable it and see if you can convince another developer to +2 that patch. Izno (talk) 01:52, 26 February 2026 (UTC)

Also, would it be possible to hack in a more prominent button to disable the feature by editing common.js and common.css? SuperPianoMan9167 (talk) 00:53, 26 February 2026 (UTC)

Definitely possible, but the time and the effort to do this should be invested by the people who want to show the animation and not by the people who don't want to see it. Amir E. Aharoni (talk) 01:18, 26 February 2026 (UTC)

A good reason might be that abusing admin tools to overrule consensus would probably get you desysopped, but don't let that stop you. -- asilvering (talk) 02:22, 26 February 2026 (UTC)

The editor who closed the discussion establishing the consensus has clearly stated that this feature is not implemented according to consensus (the close was "implement if X..." but the situation is "not X"). A good-faith read is that whoever enabled it did not realize that the effect would be against consensus, since they just turned on what someone else had implemented. WMF has stated that they will not change the implementation so that it "is X". Therefore we currently have a situation that is not consensus (it even looks contrary to consensus), and turning it off would not contravene the close statement. DMacks (talk) 02:57, 26 February 2026 (UTC)

A good-faith read is that whoever enabled it did not realize that the effect would be against consensus, since they just turned on what someone else had implemented. For what's it is worth, the effect in my opinion remains within the consensus, the button is prominent for most readers. My ask for enhancement was a request for enhancement for what I frankly think are edge cases like your experience. I thought that was pretty telling with my refinement of your [x hide] idea. I am of course miffed at the idea not being taken up by WMF staff, but they have priorities and also as what Izno alluded to, any volunteer developer can also submit a patch, and I would be one of the first to help clear and deploy it as long as the patch works within expectations.

A telling sign that most readers are not experiencing what you are experiencing is to look at WP:Help desk and WP:Teahouse where non-registered readers asks for help mostly, where the only two threads about the baby globe by TAs thus far were apparently, "Where can I find the baby globe?" (sic 1, sic 2). In previous major roll outs, like Vector 2022, going off from my recollection, the two venues got significantly way more complaints and queries about the change from anons than at this village pump, so much so that there was/were template reply/replies by experienced editors tending to the two venues. – robertsky (talk) 06:43, 26 February 2026 (UTC)

@Amire80, @DMacks To a non-logged in user on basically any non-tablet device there is a large toggle directly below to turn it off. This is very much consistent with community consensus. (See this image of how it looks to non-logged in users) On mobile there is a link to the appropriate section in settings to turn of the globe. The fact that we have a million tools and have reorganized our interfaces in different ways is not necessarily "WMF implemented something in a manner not in consensus", but rather "in a few cases logged in editors have the link to disable farther away than expected". Sohom (talk) 16:44, 2 March 2026 (UTC)

It's a time limited function that can be switched off by users (yes, it did take me some time because I hid the appearances menu some time ago). As as it's only going to be around for 7–8 weeks then let's just let it run it's course but people can offer whatever feedback they want to the developers about waht features and/or the associated documentation should contain. Nthep (talk) 09:06, 26 February 2026 (UTC)

Looking for help trying to find something

Singapore has some sort of flashing icon or figure at the beginning of the article can't figure out where it's coming from. Moxy🍁 03:03, 25 February 2026 (UTC)

I don't see it. If others don't see it either, you might want to consider uploading a video and linking to it here so we can see what you're seeing. –Novem Linguae (talk) 03:06, 25 February 2026 (UTC)

Birthday mascot. DMacks (talk) 03:15, 25 February 2026 (UTC)

I clicked on the thingy how do I get to stop? Who the hell thought this little child icon.... Why the hell would we make our readers scroll even more before the article begins... Do these developers not take into account basic accessibility concerns? Moxy🍁 03:20, 25 February 2026 (UTC)

See #Un-hidable(?) new UI decoration taking up lots of screenspace, wherein we learn they didn't even implement it in the way that was consensus for approval to implement it at all. DMacks (talk) 03:24, 25 February 2026 (UTC)

ohhhh. ...Wikipedia:CONTENTEDITOR nightmare.

Preferences → Appearance → Birthday mode → Birthday mode (Baby Globe)

Celebrate 25 years of Wikipedia with a cute reading companion}} Moxy🍁 03:34, 25 February 2026 (UTC)

Globe icon or animation

Hey folks. A little while ago, a globe icon or animation started appearing on the right side of some articles. I'm using a Windows desktop PC. In Firefox it's a big icon, in Chrome it's an animation. It only appears on some articles -- Dune: Part Two is a random example. I think this is what's being displayed. When I click on it nothing seems to happen. It's taking up valuable real estate on the screen, forcing the rest of the article into a smaller space, but I don't see a way to hide it. Yes, I'm so confused. What's going on? — Mudwater ^(Talk) 02:25, 2 March 2026 (UTC)

I'm seeing this as well, on Bryson Tiller. This is a useless nuisance and needs to be removed, ASAP. Stefen 𝕋ower ^{Huddle • Handiwerk} 02:31, 2 March 2026 (UTC)

And I should mention the animation I'm seeing is similar but not quite the same. Stefen 𝕋ower ^{Huddle • Handiwerk} 02:38, 2 March 2026 (UTC)

See the birthday mode discussion above. The gist is that this huge image was implemented in a way that went against the consensus here on the English Wikipedia that it be easy to disable or hide. It is clear that in some display modes, it is not easy to do so. You can go to Preferences > Appearance and uncheck "Birthday mode". – Jonesey95 (talk) 02:49, 2 March 2026 (UTC)

Preferences > Appearance and uncheck "Birthday mode" Thanks, I was wondering how to disable that dumb thing. Some1 (talk) 03:02, 2 March 2026 (UTC)

Thanks! — Mudwater ^(Talk) 03:43, 2 March 2026 (UTC)

Thanks all. Also, I think this calls for a /smdh. Stefen 𝕋ower ^{Huddle • Handiwerk} 04:22, 2 March 2026 (UTC)

Additional note: This is explained here -- though it took me a while to find it. — Mudwater ^(Talk) 12:07, 2 March 2026 (UTC)

• There is a basic concept that the developers appear to not have heard of. It's called consent. They should not randomly add things to the pages I read without my consent. Opt-in, not opt-out. At the very least, they should make the control for opting out part of the bloat they are stuffing down my throat, not an obscure setting in my preferences. Now I have to check my preferences regularly to see what else they decided to do to me without asking for my permission. :( --Guy Macon (talk) 16:13, 6 March 2026 (UTC)

  There was consent. It wasn't the developers who decided this feature should be opt-out. It was the community. SuperPianoMan9167 (talk) 16:43, 6 March 2026 (UTC)

Do i need approval from someone before i upload my user script?

Hello! i've been making a not so original user script that identifies common spelling errors. Im almost finished with it so im wondering how to upload it for wikipedia to use and if i need approval from someone first. Thanks! 203N7HN6 (talk) 07:57, 27 February 2026 (UTC)

No. See WP:USERSCRIPT for more details on what is or isn't permissible, but a spellchecking script shouldn't be very controversial, assuming it is used intelligently. Headbomb {t · c · p · b} 08:10, 27 February 2026 (UTC)

thanks! 203N7HN6 (talk) 08:22, 27 February 2026 (UTC)

@203N7HN6 See User:Polygnotus/Scripts/SourcerySpell.js for inspiration. It uses Hunspell. Polygnotus (talk) 11:45, 27 February 2026 (UTC)

im actually kind of new to js so im not sure how to implement other sofwtare in my code ehe 203N7HN6 (talk) 16:04, 27 February 2026 (UTC)

By the way, this (User:203N7HN6/Spellchecker.js#L-42) destroys all event listeners on the page content (breaks WP:Popups, WP:Media Viewer, etc.)

var bodyContent = document.getElementById('bodyContent');
// ...
bodyContent.innerHTML = highlightedHTML;

You could do mw.hook('wikipage.content').fire($("#bodyContent"));, but I'm sure this doesn't fix all other side effects that I can't think of right now. Better to just not replace the entirety of bodyContent's html. — DVRTed (Talk) 13:27, 27 February 2026 (UTC)

ill try to fix it when im available and try to contact you. thanks! 203N7HN6 (talk) 14:43, 27 February 2026 (UTC)

im fairly new to writing js in wp and would appreciate it if you could tell me what im doing wrong (PS: im using my current knowledge and inspect element to write stuff alongside with references from other scripts) 203N7HN6 (talk) 20:29, 27 February 2026 (UTC)

Oh, you're supposed to update the html and fire the hook afterwards. Try this (line 41):

bodyContent.innerHTML = highlightedHTML; 
mw.hook('wikipage.content').fire($("#bodyContent"));

— DVRTed (Talk) 20:43, 27 February 2026 (UTC)

ok thanks! 203N7HN6 (talk) 13:49, 28 February 2026 (UTC)

@203N7HN6, @203N7HN6.. no please don't do either. Use DOM manipulation, not replacing all contents by setting innerHTML. It can break all kinds of expectations of the software. .innerHTML should only be used to create NEW content, not to replace content. —TheDJ (talk • contribs) 08:00, 2 March 2026 (UTC)

@TheDJ You pinged 203 twice I think you meant to ping @DVRTed:. Polygnotus (talk) 08:11, 2 March 2026 (UTC)

I'm sure this doesn't fix all other side effects [...] Better to just not replace the entirety of bodyContent's html. I don't see a reason to ping me... lol. — DVRTed (Talk) 09:48, 2 March 2026 (UTC)

TreeWalker and createTreeWalker(). Polygnotus (talk) 09:12, 2 March 2026 (UTC)

Alignment issue with Tree chart

Hi everyone, some elements in the family tree under the Family and descendants section aren't perfectly centered. If anyone with more experience could help fix the alignment, I would be very grateful. Thanks! RiadS99 (talk) 01:06, 28 February 2026 (UTC)

I'm not very experienced, but it seems like the way you formatted the tables seems a bit messy and overutilizing '|' (vertical bar). Rhinocratt
c 13:51, 3 March 2026 (UTC)

Padding bug

Hello. I encountered a rather strange bug on Wikipedia when I tried to create padding in tables using NBSPs. So I've created a test template {{Padding bug}} and you can compare the results here:

This is the full code of my test template:

{| class="wikitable"
|-
| {{{1|}}} 
| {{{2|}}} 
| {{{3|}}} 
|}

Code used in article:

{{Padding bug|A|B|C}}

This output is correct:

A

B

C

Code used in article:

{{Padding bug
|A
|B
|C
}}

This output is incorrect:

A

B

C

Is there any way to fix this? Can you help me solve this mystery? Thanks, Maiō T. (talk) 08:40, 1 March 2026 (UTC)

There is no whitespace trimming of unnamed parameters. For example, the first parameter is two characters: A and a newline. Using 1=A (a named parameter) would trim any whitespace. Johnuniq (talk) 09:49, 1 March 2026 (UTC)

No, Johnuniq. This template is really crazy. Look at this next example:

Code:

{{Padding bug
|1=A
|2=B
|C
}}

Output:

C

B

Maiō T. (talk) 10:30, 1 March 2026 (UTC)

C is the first unnamed parameter according to MediaWiki and overwrites 1=A since only the last assignment of the same parameter counts. I would prefer if the counting continued after the explicit numbers and C becomes the third unnamed in your code but that's not how it works. C has an unstripped newline and it only takes one to force a taller row. The B cell only has B since the newline was stripped. The C cell is also vertically centered but has two lines, one with C and one blank. A common scenario is that the first unnamed parameter contains an equals sign so you have to add 1= to avoid it being interpreted as a named parameter. Then all the following unnamed parameters are forced to also use explicit numbers. It's rather annoying. PrimeHunter (talk) 12:05, 1 March 2026 (UTC)

Okay PrimeHunter. In other words, when creating a template, it is forbidden to add anything after the {{{1|}}} to avoid displaying a new line in the cell. Am I right? Maiō T. (talk) 15:46, 1 March 2026 (UTC)

Whitespace handling in MediaWiki is complicated but in a template like {{Padding bug}} I do suggest to omit &nbsp; around the parameters. Use CSS instead (see Help:Table#Cell content indenting and padding) if you want more cellpadding Then MediaWiki's table code will ignore some forms of whitespace in the caller. The two "Code used in article" in your original post will both give the first result. PrimeHunter (talk) 17:49, 1 March 2026 (UTC)

Maiō T.: The template is doing what you tell it to do. In the second example that you have marked "incorrect", you are telling it: parameter 1 should be the letter A and then a new line. If you want the template to trim that new line away, wrap the parameters in {{trim}} in the template, as I have done in the sandbox:

Code:

{{Padding bug/sandbox
|A
|B
|C
}}

Output:

A

B

C

I hope that helps. – Jonesey95 (talk) 18:26, 1 March 2026 (UTC)

Wow!!! Thank you both, PrimeHunter and Jonesey95. You have been a great help. Two great options for fooling that bug. 😉 Maiō T. (talk) 20:20, 1 March 2026 (UTC)

Can't add link to a userspace draft

As you may be able to see from my spam blacklist log, I was trying to add a link, djdave [dot] xyz, to a userspace draft. However it kept getting disallowed? It said xyz was the link that was flagged, so I removed it, and it worked, but when I look at the spam blacklist, I can't see an entry for all .xyz sites or just djdave [dot] xyz. I was directed to MediaWiki talk:Spam whitelist but the instructions there are confusing. Could I have some help? TheTechie^[she/they] | talk? 23:21, 1 March 2026 (UTC)

It appears to have been added in Special:Diff/961623463 after MediaWiki talk:Spam-blacklist/archives/June 2020#h-the whole .xyz TLD-.xyz TLD-2020-05-19T18:41:00.000Z. If you want that site whitelisted, MediaWiki talk:Spam-whitelist is the place to request it. Looking at the instructions there and a glance at the history, as long as you include the relevant information (the specific link, the specific articles you want to use the link on, and why you want it whitelisted), it looks like people will engage with it even if you don't get the formatting exactly right. Anomie⚔ 00:20, 2 March 2026 (UTC)

Cyberbot not archiving RFPP...

I see Cyberbot is still working, but it hasn't archived WP:RFPP for quite some time - there's getting to be quite the backlog of processed requests, especially in the "Current requests for edits to a protected page" section, despite multiple entries having the "archive immediately" tag added to them. What's up? - The Bushranger _{One ping only} 01:23, 2 March 2026 (UTC)

categorylinks view in enwiki_p on enwiki.analytics.db.svc.wikimedia.cloud

Is it my imagination or has the cl_to column just vanished from the categorylinks view in the analytics database? It's still there for enwiki.web.db.svc.wikimedia.cloud. Sean.hoyland (talk) 17:37, 2 March 2026 (UTC)

Not your imagination; it had been deprecated for a while. phab:T299951. —Cryptic 17:43, 2 March 2026 (UTC)

Interesting. Thanks. Now I'm realizing that I don't really understand the relationships between page, category and categorylinks in a world without the cl_to column... Sean.hoyland (talk) 18:14, 2 March 2026 (UTC)

The titles that were in cl_to are now in the linktarget table, with cl_target_id as a foreign key to the appropriate row. See Special:Diff/1341322401 for a practical migration example. —Cryptic 18:26, 2 March 2026 (UTC)

Ah. Thanks very much. It also solves the mystery of what cl_target_id was pointing at... Sean.hoyland (talk) 04:08, 3 March 2026 (UTC)

The removal was also announced on the cloud-announce mailing list. Anomie⚔ 03:44, 3 March 2026 (UTC)

I guess over 50 database reports will stop working in the coming days. – DreamRimmer ■ 19:03, 3 March 2026 (UTC)

User:Cryptic has been fixing them. They fixed a few of mine. Thanks, Cryptic! – Jonesey95 (talk) 20:42, 3 March 2026 (UTC)

The {{database report}}-based ones are easy to find, since they show up in Category:SDZeroBot database report failures. I've only been taking care of queries I've worked on before, though, plus actual subpages of WP:Database reports - I figure the ones in userspace will be dealt with by their creators, if their owners are still paying attention to them. What's going to be more problematic are the bespoke bot reports and one-off queries on Quarry and such.

On that note, Jonesey95, could you do something about User:Jonesey95/Polluted categories? It's been the only page in the failures category for a long time now other than the recent flood, and the way it's set up it's basically never going to complete in anywhere near the bot's max time limit. —Cryptic 01:24, 4 March 2026 (UTC)

Blanked. Thanks for the reminder. That was a failed experiment to try to help Bearcat by creating a daily report. – Jonesey95 (talk) 02:21, 4 March 2026 (UTC)

Indeed. If I recall correctly, the regular report broke sometime last year or the year before (don't recall exactly) but its maintainer happened to be away from Wikipedia on vacation, so that report was created as a temporary workaround until they got back and could fix whatever had gone wrong with the regular one. Bearcat (talk) 02:51, 4 March 2026 (UTC)

At least 20 reports from HaleBot will break soon. I have pinged the operators below to see if they have time to fix the queries. I can help update the configuration on the report subpages, but the remote versions will also need to be updated. – DreamRimmer ■ 02:53, 4 March 2026 (UTC)

HaleBot has code that, in theory, keeps it from running when the report page transcludes {{database report}}, but I haven't tried migrating any more queries after it went ahead and overwrote Wikipedia:Database reports/Empty categories. (Though I see now there's a current attempt to steal it back again.) —Cryptic 03:07, 4 March 2026 (UTC)

@Cryptic: sorry! That report is a bit special and was bypassing the skip code. I'm fixing that now, it shouldn't affect any other reports.

Ideally at this point the only reports HaleBot continues to run are those that SDZeroBot can't because they're too complex or take too long. Legoktm (talk) 03:29, 4 March 2026 (UTC)

Category cleanup report issue

The Wikipedia:Database reports/Polluted categories report for categories with userspace content in them, which is supposed to run daily, appears to have failed to run yesterday. I know that the comparable Wikipedia:Database reports/Polluted categories (2) for categories with draftspace content was also temporarily borked yesterday due to an SQL thing, although it now seems to have been fixed — but because the reports are structured differently, I don't know if the user report failed because of the same issue or not.

So could somebody with more expertise in this kind of thing look into what happened and get it fixed so that the report runs properly today? Thanks. Bearcat (talk) 16:55, 3 March 2026 (UTC)

The cl_to column was removed from the categorylinks table. The query needs to be updated to use cl_target_id with linktarget. cc @Dbeef and @Legoktm – DreamRimmer ■ 17:07, 3 March 2026 (UTC)

Thanks for the ping, I'm starting to take a look... Legoktm (talk) 03:19, 4 March 2026 (UTC)

I fixed a number of reports, mostly by converting them to use the on-wiki template. I can probably get to the rest tomorrow. Legoktm (talk) 05:02, 4 March 2026 (UTC)

OK, All the reports managed by HaleBot should be fixed now. Legoktm (talk) 03:54, 5 March 2026 (UTC)

Tech News: 2026-10

Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.

Weekly highlight

• Wikipedia 25 Birthday mode is now live on Betawi, Breton, Chinese, Czech, Dutch, English, French, Gorontalo, Indonesian, Italian, Luxembourgish, Madurese, Sicilian, Spanish, Thai, and Vietnamese Wikipedias! This limited-time campaign feature celebrates 25 years of Wikipedia with a birthday mascot, Baby Globe. When turned on, Baby Globe is shown on ~2,500 articles, waiting to be discovered by readers. Communities can choose to turn Birthday mode on by getting consensus from their community and asking an admin to enable the feature and customize it via community configuration on the local wiki.

Updates for editors

• Sub-referencing, a new feature to re-use references with different details has been released to Swedish Wikipedia, Polish Wikipedia and a couple of other wikis. You can try the feature on these projects or on testwiki and betawiki. Learnings from the first pilot wiki German Wikipedia have been published in a report. Reach out to the Wikimedia Deutschland team if you are interested in becoming a pilot wiki.
• Paste Check will become available at all Wikipedias this week. The feature prompts newcomers who are pasting text they are not likely to have written into VisualEditor to consider whether doing so risks a copyright violation. Paste Check tags all edits where it is shown for potential review. Local administrators can configure various aspects of the feature via Special:EditChecks. Research across 22 wikis found that Paste Check resulted in an 18% decrease in relative reverted-edits compared to the control group. Translators can help to localize this and related features.
• The Reader Experience team will be standardizing the user menu in the top right for all mobile users so that it is closer to the desktop experience. Currently this user menu is only visible to users with Advanced Mobile Controls (AMC) turned on. The only change is that a couple buttons previously in the left-side menu will move to the top right for users who do not have AMC turned on. This change is expected to go out March 9 and seeks to improve the user interface. [9]
• Starting in the week of March 2, the emails sent out when an email address was added, removed, or changed for an account will switch to a substantially nicer and clearer HTML email from the prior plaintext one. [10]
• Notifications are currently limited to 2,000 historic entries per user, and extend back to 2013 when the feature was released. This is going to be changed to only store Notifications from the last 5 years, but up to 10,000 of them. This will help with long-term infrastructure health and help to prevent more recent notifications from disappearing too soon. [11]
• The Global Watchlist which lets you view your watchlists from multiple wikis on a single page continues to see improvements. The latest update improves label usage experience. The extension now allows activating the language fallback system for Wikidata items without labels in the viewed language, and showing those labels in the user’s preferred Wikidata language if no uselang= URL parameter is provided. [12][13]
• The Wikipedia Android team has started a beta test of hybrid search on Greek Wikipedia. Hybrid search capabilities can handle both semantic and keyword queries enabling readers to find what they’re looking for directly on Wikipedia more easily.
• For security reasons, members of certain user groups are required to have two-factor authentication (2FA) enabled. Currently, 2FA is required to use the group, but not to be a member of it. Given that this model still has some vulnerabilities, the situation will gradually change in March. Members of these groups will be unable to disable last 2FA method on their account, and it will be impossible to add users without 2FA to these groups. Users will still be able to add new authentication methods or remove them, as long as at least one method is continuously enabled. In the second half of March, users without 2FA will be removed from these groups. This applies to: CentralNotice administrators, checkusers, interface administrators, suppressors, Wikidata staff, Wikifunctions staff, WMF Office IT and WMF Trust & Safety. Nothing will change for other users. See the linked task for deployment schedule. [14]
• View all 27 community-submitted tasks that were resolved last week. For example, the issue preventing users from creating an instance in Wikibase.cloud has now been fixed. [15]

Updates for technical contributors

• To help ensure fair use of infrastructure, over the next month the Wikimedia Foundation will implement global API rate limits across our APIs. In early March, stricter limits will be applied to unidentified requests from outside Toolforge/WMCS and API requests that are made from web browsers. In April, higher limits will be applied to identified traffic. These limits are intentionally set as high as possible to minimise impact on the community. Bots running in Toolforge/WMCS or with the bot user right on any wiki should not be affected for now. However, all developers are advised to follow updated best practices. For more information, see Wikimedia APIs/Rate limits.
• The Wikidata Query Service Linked Data Fragment (LDF) endpoint will be decommissioned in February. This endpoint served limited traffic, which was successfully migrated to other data access methods that were better suited to support existing use cases. The hardware used to support the LDF endpoint will be reallocated to support the ongoing backend migration efforts. [16]
• The new Parsoid parser continues to be deployed to additional wikis, improving platform sustainability and making it easier to introduce new reading and editing features. Parsoid is now the default parser on 488 WMF wikis (268 Wikipedias), now covering more than 10% of all Wikipedia page views.
• The process and criteria for requesting exceptional access to the high volume feed of the Wikimedia Enterprise APIs (at no cost for mission-aligned usecases), have now been published. This is to provide more thorough and clearer documentation for users.
• Tech Blog, the blog dedicated to the Wikimedia technical community will be migrating to Diff, the community news and event blog. The migration should be complete in April 2026, after which new posts will be accepted for publishing. Readers will be able to access posts – old and new – on the landing page at https://diff.wikimedia.org/techblog.
• Detailed code updates later this week: MediaWiki

Tech news prepared by Tech News writers and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.

MediaWiki message delivery 17:49, 2 March 2026 (UTC)

requesting exceptional access should link to m:Special:MyLanguage/Wikimedia Enterprise#Access. — Qwerfjkltalk 18:56, 2 March 2026 (UTC)

Problem with bots' reporting

Is there a problem with toolforge? The bots I reply on, like Hale Bot and DreamRimmer Bot II have not been updating their reports. Thanks for checking. Liz ^{Read! Talk!} 19:15, 2 March 2026 (UTC)

Please request assistance from the bot operators. I suspect, like #categorylinks view in enwiki_p on enwiki.analytics.db.svc.wikimedia.cloud, that these bots rely on categorylinks in this way, but you will need to ask them to verify. Izno (talk) 19:48, 2 March 2026 (UTC)

It didn't seem like a bot problem but a system problem. This is where I come with these questions because editors here know how to create tickets reporting bugs or making inquiries. Sorry if it this displays technological ignorance on my part but I really don't understand how these aspects of the project work and you all seem to be able to look into issues more adeptly than I can. I'm just surprised that I'm often the only person reporting problems when they seem like issues that involve the functioning of bots or scripts that many, many editors rely on.

Also, I did post inquirites on the User talk pages of the bot operators. I just also usually come here as well. Liz ^{Read! Talk!} 04:30, 3 March 2026 (UTC)

All pages using template:plain image with caption with "image override" parameter

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

---

Could someone create such list? sapphaline (talk) 21:29, 2 March 2026 (UTC)

@Sapphaline Maybe this? Ponor (talk) 21:40, 2 March 2026 (UTC)

I also need pages using this parameter unnamed. sapphaline (talk) 21:42, 2 March 2026 (UTC)

It is basically impossible to find such instances. If you want them, you will have to add TemplateData and then use bambot. Izno (talk) 22:21, 2 March 2026 (UTC)

There's under a thousand transclusions (less than half that in mainspace, if it matters). That's not trivial to look through manually, but still feasible. —Cryptic 22:30, 2 March 2026 (UTC)

---

Fortunately there were no instances of pages using this parameter unnamed, and the only mainspace page which used it named was Chloroplast. sapphaline (talk) 07:53, 3 March 2026 (UTC)

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

Mobile diff errors

This is the second time within a week that I've misjudged someone's edit because the diff in mobile view was wrong. Take a look at this edit to Malaysian Malay in both desktop and mobile views. Desktop view clearly shows that one ancestor2 infobox parameter was replaced by another, and the source code at the revision created by that edit confirms that there's only one ancestor2 parameter.

But I was reviewing my watchlist on my phone, and what the mobile view of the diff showed was an extra ancestor2 parameter being added while leaving the one that was already there in place. Based on that, I reverted the edit as an error, explained in my edit summary along with a suggestion that the other editor might want to "Try again?" But right after that it occurred to me to check what the actual source code had been and I found that the diff lied to me and that the edit had been fine, so I restored it. Largoplazo (talk) 23:10, 2 March 2026 (UTC)

This is some flavor of phab:T349335. Izno (talk) 23:15, 2 March 2026 (UTC)

@Largoplazo: The mobile diff is supposed to show an indicator that a paragraph was moved. It's an inline diff and shows the paragraph at both the before and after location. So does a two-column desktop diff but there it's shown in a before and after column. I can see hover text "Paragraph was moved. Click to jump to new location." for the indicator on a blank line and click it but not see the actual indicator. I think the only error is that the indicator is invisible. I can toggle "Inline" in the desktop diff to see an inline diff where an indicator is visible as arrows. wikEdDiff at Special:Preferences#mw-prefsection-gadgets gives a better diff. Sometimes it gives a worse diff but the normal diff is still shown and wikEdDiff just adds an option to see an alternative diff. I recommend it. PrimeHunter (talk) 19:02, 3 March 2026 (UTC)

Or w:de:Benutzer:Schnark/js/diff (for alternative diff). — Qwerfjkltalk 12:31, 4 March 2026 (UTC)

Search prefix in InputBox doesn't work on mobile web on iPhone

I don't know if this issue is related the InputBox extension or the MediaWiki software, but the prefix parameter is ignored on the mobile web version of Wikipedia when <inputbox> is used to create a search form. When I enter something into the text field and press Enter, the form acts as if I'm doing a search in the article space. This affects the iOS version of Safari on my iPhone, but there are no issues on the iPad. Ixfd64 (talk) 11:53, 3 March 2026 (UTC)

sounds a bit like phab:T402078? Johannnes89 (talk) 13:43, 3 March 2026 (UTC)

Thanks for linking the ticket. So it's a MediaWiki issue, then. Ixfd64 (talk) 18:19, 3 March 2026 (UTC)

Article doesn't collapse in mobile view

The article 2022 European Curling Championships doesn't collapse in mobile view. I've tried to figure out why, but with no luck. It seems that this edit somehow is to blame (when I go through the revision history, it's from this revision onwards the collapse function won't work), though the edit looks completely normal. I've used my sandbox to try to find the solution, and it seems to have something to do with adding more nation templates, like {{CZE}}, to the page. Is there an upper limit to how many templates av this type that can be included in an article before problems like this one are caused?

I've earlier tried to get help with this subject on my own talk page, see User talk:Marima#Help me!. I hope someone more tech savvy than I can help me find the solution! Marima (talk) 12:01, 3 March 2026 (UTC)

IIRC, once there are sufficient images on the page, the mobile site turns off its collapsing. Those templates like {{CZE}} each add a flag image. Anomie⚔ 13:35, 3 March 2026 (UTC)

Yes, this would be the cause of it. Izno (talk) 17:57, 3 March 2026 (UTC)

The limit is 1000 images: phab:T232690. 2022 European Curling Championships currently has 1057 so it's not far off. File:Font Awesome 5 solid hammer.svg occurs 183 times so changing this indicator to a character would more than solve it. Maybe men and women should have separate articles anyway for length reasons. PrimeHunter (talk) 18:27, 3 March 2026 (UTC)

I replaced the image with "🔨". --Ahecht (TALK
PAGE) 19:21, 3 March 2026 (UTC)

Big thanks for the explanation and the measure taken! Marima (talk) 22:18, 3 March 2026 (UTC)

Ellman's

I have no idea what's going on here. Even after the nominator withdrew, the AFD for Ellman's was put back on the page by a bot. Ten Pound Hammer • ^{(What did I screw up now?)} 19:12, 3 March 2026 (UTC)

It's because they didn't remove the template that says {{REMOVE THIS TEMPLATE WHEN CLOSING THIS AfD}}. I fixed it. SuperPianoMan9167 (talk) 20:09, 3 March 2026 (UTC)

Mobile twinkle

Hello there, I'm a mobile editor on Wikipedia. I would like to use twinkle mobile and it isn't working. I currently use a very watered down version of twinkle as a gadget. Thank you for your time. Dafootballguy (talk) 23:28, 3 March 2026 (UTC)

I would suggest leaving a message at User talk:Plantaest/TwinkleMobile. SuperPianoMan9167 (talk) 23:48, 3 March 2026 (UTC)

Can I have my IP unbanned please?

I had my IP banned for inventing a crawler to download Vital articles level 4 as text files, with the intention to print it and bind books. I have read different opinions on spiders on different pages, from don't use them at all to use them on off-hours with a sleep between queries of 60s. I would be totally fine with doing this and I didn't realise this would be a problem as I didn't see the guidelines before being banned. I'm sorry for any trouble this may have caused and I didn't realise I was doing something wrong. If Wikipedia is 100% against spiders maybe you would release the Vital articles as their own downloadable packages? Nellas Galadhon (talk) 01:54, 4 March 2026 (UTC)

We did not do that. The WMF might have, see mw:Wikimedia APIs/Rate limits. Please correct the issues that are likely present in your downloading script as a result of the change in API rate limits and then if that doesn't fix the problem get in contact with the WMF using phab:. Izno (talk) 02:42, 4 March 2026 (UTC)

@Nellas Galadhon Also see https://meta.wikimedia.org/wiki/Wikimedia_Enterprise#Access --Ahecht (TALK
PAGE) 17:58, 4 March 2026 (UTC)

@Nellas Galadhon When making automated requests to the web site or APIs, please always make sure to follow the Robot policy. Note in particular the requirement to set a compliant User-Agent header to help avoid being blocked. It's not clear from your message what the error is, but I suspect it might just be that.

@Izno The API rate limits have not yet gone into affect, the first phase will be rolled out end of next week. JTweed-WMF (talk) 14:46, 5 March 2026 (UTC)

Thanks for your help.I only really discovered the robotic agreement once I started having error by then.It may have been too late.I'll try to implement what you suggested ~2026-14281-92 (talk) 14:52, 5 March 2026 (UTC)

@JTweed-WMF Ok, I linked the wrong help page and I know the other exists. Maybe you should ensure those are well connected. Izno (talk) 17:18, 5 March 2026 (UTC)

OpenStreetMaps automatically added to the battle infobox on every page with co-ords defined

Hi, I've asked about this over on WP:MILHIST but possibly folk here can give a better answer, particularly as the OpenStreetMap project appears to be dead.

At some point in the last year or so OpenStreetMaps appeared in all of the battle-infoboxes. You can see an example of this at Battle of Jutland, and it's very typical - totally uniformative and useless since what it shows is a close-up map of an empty stretch of sea. The land versions are little better since the maps are modern (with modern location-names and boundaries) and always at the wrong scale to give you any idea of what the battle was. Most of these pages have far more informative maps on them already.

However, the maps were not added through ordinary editing. They appear to be added automatically by some kind of plug-in or gadget. There is nothing in the page that can be edited to remove them without removing the co-ordinates that they are based on. The only solution appears to be just deleting the co-ordinates from the infobox.

Is there no way of opting pages out of this without just removing the co-ordinates?

It is also passing strange that, were anyone to propose adding that map to the infobox in the Battle of Jutland article, editors would rebel against the whole idea, but that map and tens of thousands more just as uninformative could be added to tens of thousands of articles with (as far as I am aware, correct me if I am wrong) little or no discussion. FOARP (talk) 11:39, 4 March 2026 (UTC)

These map frames are causing issues in other places as well. See Template talk:Infobox civilian attack#Mapframe appearing by default, Wikipedia:Village pump (miscellaneous)/Archive 86#Automatic map generation from Wikidata, Template talk:Infobox settlement#Unreliable maps automatically imported from OpenStreetMap. I don't know when they started being added and what discussions led to it. CMD (talk) 12:28, 4 March 2026 (UTC)

From the look of it: not discussed at all? And 95%+ of the time they're useless, but taking up prime real-estate on the page.

I've tried looking at Template:Infobox military conflict, and if I've understood it correctly showing the mapframe should be default no? That's how I read the documentation anyway. Adding |mapframe= no to Battle of Jutland's infobox removes the silly map.

But it's defaulting to yes across tens of thousands of articles and that should end ASAP. FOARP (talk) 13:37, 4 March 2026 (UTC)

Pinging @Joy (on a completely no-blame basis) as it looks like it might be their edits to Module:Infobox military conflict last October which have generated the |mapframe=onbydefault behaviour. Nthep (talk) 14:03, 4 March 2026 (UTC)

Yes, if you're talking about Module talk:Infobox military conflict#mapframe implementation. We had a similar discussion about the default zoom on sea locations already, and I actually tried to fix it already in this template, but because of this specific Lua implementation in that particular template, I didn't figure out how to do it. I'll attend to the article mentioned above now.

Is there a Lua-related noticeboard where one could ask for help? --Joy (talk) 14:09, 4 March 2026 (UTC)

Hmm, on a more general note, this template and this use case is actually pretty odd from the get-go. Usually the infobox templates have an image parameter for descriptive pictures, and a map parameter for maps. In this case, however, a map is attached as an image, so the code that autodetects whether to make a mapframe thumbnail from coordinates can't detect that. We should implement a map_image (or similar) parameter to improve this situation. This should be discussed at Template talk:Infobox military conflict. In the meantime I see FOARP has found that talk page 15 minutes ago, so I'll move over there. --Joy (talk) 14:15, 4 March 2026 (UTC)

Joy, this feature needs to be switched off by default ASAP until a consensus in favour of including them is decided. Not just for Battle of Jutland, but for all military conflict articles because in very, very few cases are these maps actually helpful. The zoom-level is only one of the many problems with them. FOARP (talk) 14:16, 4 March 2026 (UTC)

We can certainly revert the addition.

At the same, we could also observe that the feature has been live since October 2025, and you found 1 bad example after 4.5 months. Maybe the insistence that something needs to be done as soon as possible is not necessarily the best course of action. We could also try to analyze the available information further, and find more examples that actually demonstrate the extent of the issue, which should help us assess the risks here better.

For example, at https://bambots.brucemyers.com/TemplateParam.php?wiki=enwiki&template=Infobox+military+conflict we can currently see:

• 5,795 detected mapframe-coordinates parameters - this is mapped from coordinates automatically, so that sounds like the overall usage right now
• 34 detected mapframe parameters - usually interventions to enable or disable, where we further see:
  • CEM-36-Huguang-2433.jpg (1) - random bug?
  • This victory had the effect of breaking up the Hindu confederation (1) - random bug?
  • Yes (1) - explicit enabling
  • n0 (1) - attempt to disable that went awry?
  • no (12) - explicit disabling
  • yes (18) - explicit enabling
• 8 mapframe-marker (7 monument, 1 battle)
• 7 mapframe-zoom
• 7 mapframe-area_km2 - this can also be zoom/scale tuning
• 2 mapframe-caption
• 2 mapframe-frame-height (=250)
• 2 mapframe-frame-width (=180)
• 1 mapframe-wikidata (=yes)

So comparing 34 to 5795, we've had about 0.5% intervention rate of some sort. This could mean that nobody knows how to edit these things so we don't see much (iceberg effect), or it could mean that there wasn't a pressing need for interventions, or something inbetween.

The use of other options being comparable to the 34 seems to indicate that at least some editors have used these options for good. The ratio of explicitly disabled to explicitly enabled ones (13 vs 19) is not really in favor of the idea of there being a huge issue that requires urgent mass disabling. Of course, likewise there's the possibility of the iceberg effect as mentioned above.

I recommend we continue analyzing this in more depth at the infobox talk page, and really try to figure it out. --Joy (talk) 14:44, 4 March 2026 (UTC)

I found out about this because of an editor complaining in a comment that was posted soon after this feature went live. What people lacked was sufficient knowledge to know where even to complain about the issue - it's the iceberg effect. FOARP (talk) 14:51, 4 March 2026 (UTC)

I don't think this is straightforward evidence for that, both because that complaint indicated a variety of other issues (slow to display? Apple products?), and was by @Malchemist, an editor of fifteen years here. While we can and should appreciate others like ourselves :) we are not necessarily indicative of the general readership by default. A hundred thousand readers were there since, so even if iceberg ratio is 1000 : 1 this could well still be fine.

Likewise, if the solution was to actually remove the coordinates, not just the mapframe, because the location just wasn't right, then the mapframe merely made an existing issue more obvious, it didn't really introduce a fresh one. In that sense, mapframe thumbnails can be a useful tool to keep the base information proper.

At the same time, there's possibly a bit more nuance still - maybe if we better honored the resolution implied by the formatting of those coordinates, 49°1′N 3°23′E, (WP:OPCOORD), with a derived mapframe zoom that would better match that precision, maybe the context wouldn't be so bad by default. Comparison below:

For the average reader who doesn't really know where the Marne river valley might be, this basic illustration of it being east of Paris seems like a generally useful default. Unlike with Chateau-Thierry, which isn't even mentioned in the battle article, only in another map caption. --Joy (talk) 16:13, 4 March 2026 (UTC)

Hi Joy, I hope you don’t mind me saying this, but I am getting the strong impression that neither my concerns nor those my fellow editors in the Milhist space are entirely being listened to. Multiple editors here and at the template page have now told you that we don’t want these maps, that were added without discussion to thousands of articles, against what the documentation in the template says.

Please revert this addition ASAP. FOARP (talk) 21:37, 4 March 2026 (UTC)

I'm listening, but you're not apparently listening to me (at least I'm not seeing much other than blanket assertions in response), and seem to be intent on insisting something is done ASAP (Likewise here) Are you upset about this? What is the reason for this apparent urgency? Besides, you have the same permissions as I do, why wouldn't you just undo the change yourself, instead of poking me in the eye about it like this? --Joy (talk) 08:14, 5 March 2026 (UTC)

Could you please explain how exactly to do it? I honestly don't know how, otherwise I wouldn't be asking you. FOARP (talk) 09:06, 5 March 2026 (UTC)

The changes are in the history of Module Infobox military conflict, I had added a single block of code, it should be safe to just take it out. You can also test it first in Module:Infobox military conflict/sandbox. --Joy (talk) 09:20, 5 March 2026 (UTC)

Many thanks. Hopefully my inexpert deletion has not caused any problems.

As a word of advice, making sweeping changes to many thousands of pages is not something that should be done lightly and if I were you I would definitely at least drop a comment on to the relevant talk-page discussing what it is you want to do, and wait to see what the response is, before doing something like this again. FOARP (talk) 10:13, 5 March 2026 (UTC)

I think that's an issue also exacerbated by the weird division of talk between the two namespaces in that case. --Joy (talk) 13:09, 5 March 2026 (UTC)

Would a merge fix that? FOARP (talk) 13:19, 5 March 2026 (UTC)

I think we should do that, I can't imagine that there'd ever be a huge amount of discussions that would be so annoying to either audience to make it not worth it. --Joy (talk) 13:28, 5 March 2026 (UTC)

I should also mention one more thing with regard to iceberg effect - mapframes are much more common these days, and more and more readers are accustomed to them, and are aware of the fact one can click them, and then zoom in and zoom out (either by clicking, or by scrolling, or by pinching). Even in the worst case scenario where a reader encounters an ugly bland blue or white box, they might be aware that they can fiddle with the box, get in, zoom out, and get the geographical context information, which may or may not be useful, but it's typically not harmful. That is also why I would tend not to be alarmed in this situation. --Joy (talk) 14:51, 4 March 2026 (UTC)

Barely any mapframe maps in the first 50 at Special:WhatLinksHere/Template:Infobox_military_conflict. In 2026, I'd rather see people complain about unzoomable location maps or other static maps with tiny unreadable labels. Ponor (talk) 15:00, 4 March 2026 (UTC)

I found 10 mapframe maps in those 50. The infobox is used in 23,810 articles so that's an estimated 5,000 maps. PrimeHunter (talk) 22:18, 4 March 2026 (UTC)

I didn't find any mapframe maps improperly used in my sample. I thought there should be a few more, where there were no maps shown at all: I would like to see where the main battle of the Morean War was (maybe there's a museum), zoom in and out to see what towns are around today, etc. Ponor (talk) 10:05, 5 March 2026 (UTC)

I have no objection to adding mapframes where helpful. I believe this can still be achieved by changing the mapframe attribute to “yes”.

But in this case there was already a long-standing consensus that they should not be on by default documented in the template documentation. That consensus still appears to be valid based on the feed back here, at WP:MILHIST, and on the template talk-page. FOARP (talk) 12:00, 5 March 2026 (UTC)

These modern maps are confusing and misleading in historic articles and should not be used, IMO. Donner60 (talk) 03:37, 5 March 2026 (UTC)

Image thumbnails often failing to load

Tracked in Phabricator
Task T418323

This may have begun about a week ago or so. It's not always, but I see it regularly: in any page with images some thumbnails load, others fail to. Refreshing the page usually causes them to load, or requesting the browser to reload one that failed. I've been checking VPT from time to time for someone reporting the same problem but failed to identify a related thread, so thought I'd post this one. Thanks, ~2026-10830-00 (talk) 13:44, 4 March 2026 (UTC)

Please could you link to an example article where you are seeing a problem? I tried checking a few articles which have many images, e.g. List of paintings by Thomas Cole, but I cannot reproduce this bug. [Examples/links almost always help in bug-reports!] Thanks. Quiddity (WMF) (talk) 21:07, 4 March 2026 (UTC)

This could be the same problem as T418323. Matma Rex talk 22:40, 4 March 2026 (UTC)

This has been happening for at least a week. In articles but also in CentralNotice banners. Here's an example from 2026 Winter Olympics just now: <https://i.imgur.com/li1042k.png>. It's HTTP 429 Too Many Requests errors from URL such as <https://upload.wikimedia.org/wikipedia/commons/thumb/2/29/Flag_of_Eritrea.svg/60px-Flag_of_Eritrea.svg.png>. I'm running Google Chrome Version 144.0.7559.110, but this is almost certainly not a browser or ISP issue. This is some change that Wikimedia Foundation Inc. made to its media server configuration. Possibly related to phabricator:T414805. --MZMcBride (talk) 22:50, 4 March 2026 (UTC)

Yes, I would expect it to be 414805. Izno (talk) 23:32, 4 March 2026 (UTC)

But 60px is a standard thumbnail width, so it can't be that. Ladsgroup, who's been working on that task, also says that's not it. Matma Rex talk 10:11, 5 March 2026 (UTC)

It would be really helpful if someone could get a trending graph of HTTP 429s from upload.wikimedia.org over the past X days. --MZMcBride (talk) 22:58, 4 March 2026 (UTC)

I figured out where to find this, and added it to this dashboard: https://grafana.wikimedia.org/d/000000034/media. The number of 429s has been increasing over the last 3 weeks or so; note that the lines on this graph have different scales, so it's a steady 40k/sec of HTTP 200 responses, and recently up to 8k/sec of HTTP 429 responses. Looks like some tweaks are being made (T418323#11677204). Matma Rex talk 12:15, 5 March 2026 (UTC)

I had assumed that it was a slow connection. In the last month, I've used Wikipedia on three different devices using at least five different ISPs with widely varying load times. --Redrose64 🌹 (talk) 23:33, 4 March 2026 (UTC)

Thanks for looking into this, I'm glad that the source of the issue was found. ~2026-10830-00 (talk) 18:01, 5 March 2026 (UTC)

Today's outage — user scripts are disabled

Meta-Wiki is compromised. DO NOT ACCESS it with JavaScript enabled or without [?&]safemode=1. Nardog (talk) 15:31, 5 March 2026 (UTC)

The issue is being looked into. See the status page for updates. ~Oshwah~^{(talk) (contribs)} 17:10, 5 March 2026 (UTC)

Wikimedia sites were in read-only mode after the incident. Editing is back but user scripts appear to be disabled. A hacker apparently used a compromised account to load sitewide JavaScript at meta. The script made malicious edits with the accounts of users who visited meta with JavaScript enabled. PrimeHunter (talk) 17:12, 5 March 2026 (UTC)

Another hacker with Russian as their language of choice, I see. Cremastra (talk · contribs) 17:17, 5 March 2026 (UTC)

I can confirm that the user scripts that I load in my personal .js file appear to be disabled here on the English Wikipedia. This seems like an outage that would merit a sitewide notice of some kind. Maybe it's enough to have a topic here on VPT. – Jonesey95 (talk) 17:18, 5 March 2026 (UTC)

Yeah, it seems as if someone force-enabled safe mode for all sites when this happened. SuperPianoMan9167 (talk) 17:21, 5 March 2026 (UTC)

I'd say they're rightfully more concerned about the attack than user experience at the moment. FaviFake (talk) 17:22, 5 March 2026 (UTC)

+5,000,000,000 Security is way more important than me being able to look at WP:VPT with #F0FFF0 as the background color. mdm.bla 17:23, 5 March 2026 (UTC)

Someone added a watchlist notice in the meantime. --Joy (talk) 18:15, 5 March 2026 (UTC)

It does make me think that custom JavaScript should go through some approval process like device drivers for operating systems, and anything not on a whitelist of verified, tested and approved code doesn't run at all. Ritchie333 ^{(talk) (cont)} 17:14, 5 March 2026 (UTC)

I think a maybe simpler intervention would be that code from someone's userspace cannot take any actions that author could not take. For example, if a page mover writes a userscript in their userspace and I install it, and their script is then compromised, they might be able to mess with my page-moving ability, but they couldn't do anything worse. If someone wants a script to be exempt from these requirement, get an intadmin to move it into MediaWiki space and then it'll only be editable by intadmins. theleekycauldron (talk • she/her) 21:29, 5 March 2026 (UTC)

That would be impossible to enforce technically. Socially, we could have a rule like "admins are prohibited from importing scripts from non-admins" but I suspect that would lead to a lot of copy-pasting, which, for the reasons discussed here, might be worse. Suffusion of Yellow (talk) 21:51, 5 March 2026 (UTC)

I think it's not unreasonable to want a software change ot get a workable solution here, but hopefully there's a workable solution that doesn't require that. theleekycauldron (talk • she/her) 22:09, 5 March 2026 (UTC)

There isn't a software change that can "selectively" control what a script can and cannot do. As far as the browser knows, a "user" script is just another part of the site, and can do whatever it wants. You either import it or you don't. I suppose you could run the script in an iframe sandbox, but then it would live in its own little world, unable to even interact with the page. Suffusion of Yellow (talk) 22:24, 5 March 2026 (UTC)

The software can disallow editing site-wide javascript without reauthenticating, which should prevent a script from doing so non-interactively (especially since intadmins have 2FA enabled). --Ahecht (TALK
PAGE) 23:11, 5 March 2026 (UTC)

Yeah, but there's no way to say "Scripts from User:Trusted are allowed to do this, but scripts from User:LessTrusted can only do that..." Suffusion of Yellow (talk) 23:29, 5 March 2026 (UTC)

I mean, my understanding is that the browser knows the source of the import, and has to make an API call to take an action on behalf of the user; can't the API backend do a permissions check based on the permissions of the author of the source (i.e. whichever user is hosting the subpage of the userscript)? theleekycauldron (talk • she/her) 23:13, 5 March 2026 (UTC)

The API backend has no idea which script is performing the request, unless it provides that information voluntarily (e.g. with Api-User-Agent). Which is good practice in case of an accidental DoS, but obviously a malicious script can just provide fake information. Suffusion of Yellow (talk) 23:35, 5 March 2026 (UTC)

(this would not extend to blocks, but an intadmin should have an option to disable all userscripts a person has authored in blocking them.) theleekycauldron (talk • she/her) 21:31, 5 March 2026 (UTC)

See also MEGATHREAD Wikimedia wikis locked / Accounts compromised FaviFake (talk) 17:19, 5 March 2026 (UTC)

The malicious code has since been deleted. Some discussion at T419143. According to @MBH, @SBassett (WMF) added the script, causing this whole thing.

I have a copy of the code, if someone wants to take a look I can send it their way. JayCubby 17:25, 5 March 2026 (UTC)

Wait. What exactly happened? Did someone hack Meta-Wiki? VidanaliK (talk to me) (contributions) 17:25, 5 March 2026 (UTC)

we have to send someone to the WP:STOCKS for this, but who? ltbdl (operate) 17:25, 5 March 2026 (UTC)

Are you sure it was a well-intentioned Wikipedian that accidentally inserted "malicious code"? VidanaliK (talk to me) (contributions) 17:27, 5 March 2026 (UTC)

It seems more likely the account was hacked. It loaded a malware script stored at the Russian Wikipedia. There was no apparent reason to think it would be a good idea to load the script sitewide at meta. I don't know how the account was compromised but being hacked (even with a high-permission account) is not usually grounds for the stocks. Maybe if they had a ridiculously easy password. PrimeHunter (talk) 17:41, 5 March 2026 (UTC)

Actually, they may have loaded the script deliberately in their personal js and then the script used the account to change sitewide js. PrimeHunter (talk) 17:44, 5 March 2026 (UTC)

Nope, it seems he was testing userjs loads and he just imported a ton of random scripts, see [17] FaviFake (talk) 17:49, 5 March 2026 (UTC)

I'm definitely glad the wiki was in read-only mode by the time I logged on. Wait, if I had the "Keep me logged in for one year" might something have happened? What did the code even do? VidanaliK (talk to me) (contributions) 17:47, 5 March 2026 (UTC)

"What did the code even do?" - here's the user script and here's what was inserted into hacked users' common.js. Unfortunately I can't fully explain the user script, but in the second script the only relevant lines are 1-5, everything other than that is just a filler. sapphaline (talk) 18:00, 5 March 2026 (UTC)

Ahecht responded here. VidanaliK (talk to me) (contributions) 18:02, 5 March 2026 (UTC)

Scott Bassett (User:SBassett (WMF), the WMF's "Staff Security Engineer" JayCubby 17:27, 5 March 2026 (UTC)

 Done, see Wikipedia:Village stocks#Scott Bassett for the Закрываем проект award mdm.bla 17:51, 5 March 2026 (UTC)

So this is why I was logged out? Οἶδα (talk) 17:29, 5 March 2026 (UTC)

In 2023, vandal attacks was made against two Russian-language alternative wiki projects, Wikireality and Cyclopedia. In 2024, ruwiki user Ololoshka562 created a page ru:user:Ololoshka562/test.js documenting the script used in these attacks. It was inactive next 1.5 years. Today, sbassett massively loaded other users' scripts into his global.js on meta, maybe for testing global API limits: [18]. In one edit, he loaded Ololoshka's script: [19] and ran it. Source: https://phabricator.wikimedia.org/T419143 FaviFake (talk) 17:31, 5 March 2026 (UTC)

More info about previous attack is on n:ru:Википедия по ошибке сотрудников фонда Викимедиа была взломана хакерами MBH (talk) 17:36, 5 March 2026 (UTC)

So it was basically putting "Cyclopedia" onto every page on Wikipedia? What was Cyclopedia? How did they get access to SBassets account? VidanaliK (talk to me) (contributions) 17:57, 5 March 2026 (UTC)

It was a complete accident. SBasset was randomly importing user scripts, probably for testing, and just so happened to load a malicious one. SuperPianoMan9167 (talk) 17:59, 5 March 2026 (UTC)

• Wait.. was this a Chernobyl where the testing of a potential fault caused it to go critical? -- GreenC 17:54, 5 March 2026 (UTC)

FWIW that page has now been oversighted and the account globally locked. JavaHurricane 18:52, 5 March 2026 (UTC)

I linked to the scripts' source codes earlier in this discussion, if anyone is interested. sapphaline (talk) 18:57, 5 March 2026 (UTC)

@FaviFake I don't buy that Ololoshka562 was just documenting the script used in these attacks, as the script had a hardcoded check to not run from accounts with the username "Ololoshka562". --Ahecht (TALK
PAGE) 19:37, 5 March 2026 (UTC)

How would they know that this would be the end result? Did they know their script would be loaded? I'm not too sure. It feels more like a coincidence that script ended up being run rather than an intentional attack. Cutlass^Ciera 19:43, 5 March 2026 (UTC)

Maybe, but the script was modified so that if it were run, it would never run on the account that uploaded it. It wasn't a simple "here's a script someone else wrote on another wiki" situation. --Ahecht (TALK
PAGE) 23:13, 5 March 2026 (UTC)

So this is why it was in "read-only mode"? VidanaliK (talk to me) (contributions) 17:32, 5 March 2026 (UTC)

Yes, they shut wikipedia down to prevent the malicious javascript from spreading. FaviFake (talk) 17:35, 5 March 2026 (UTC)

The malicious code would also WP:NUKE all of the user's contributions as many pages as possible on each page load, so it was set to read-only to prevent further damage. --Ahecht (TALK
PAGE) 17:58, 5 March 2026 (UTC)

Possibly useful context: User:NYKevin/Interface administrators and trusting trust. --NYKevin 17:39, 5 March 2026 (UTC)

However, you can put arbitrary JavaScript code on that page, and it will run on every page load when you are logged in. Since the attacker can force you to take actions without being aware of it, they can install malicious JavaScript on your personal common.js page, and continue to manipulate your account even after the attack has been removed from the sitewide JavaScript. There's nothing stopping an attacker from doing this to literally everyone who has ever been impersonated. Or, if that's too obvious, they could do it to a very small selection of high-privilege accounts, and hope that the community does not notice.

concerning... Οἶδα (talk) 17:47, 5 March 2026 (UTC)

Does this factor into why I cannot load external images for my user styles? I liked browsing Wikipedia with Sonic Riders images in the background. ❤︎PrincessPandaWiki (talk | contribs) 17:49, 5 March 2026 (UTC)

Yup, see https://www.wikimediastatus.net/. Monitoring - A fix has been implemented and we are monitoring the results. Some editing functionality will still be disabled. FaviFake (talk) 17:51, 5 March 2026 (UTC)

Can someone explain what the Scott Bassett-uploaded code was doing? Wait, was that the code that shut down editing for an hour? VidanaliK (talk to me) (contributions) 17:54, 5 March 2026 (UTC)

@VidanaliK It would install itself in both the user's common.js as well as the site-wide common.js, and then WP:NUKE the user's contributions. This means that all users visiting the site would get infected, and any attempts to remove it from the site's common.js would automatically get reverted by users that still have it in their personal common.js. --Ahecht (TALK
PAGE) 18:01, 5 March 2026 (UTC)

So it would basically delete every single person's contributions if they logged on with JS enabled, and make it impossible to remove the script? Is that why the edit summaries were Закрываем проект (Closing the project)? VidanaliK (talk to me) (contributions) 18:04, 5 March 2026 (UTC)

@VidanaliK: Actually, I read it wrong. It would just do a blank Nuke in namespaces 0, 1, 2, and 3 on every page load, which would delete 500 random pages from each namespace. --Ahecht (TALK
PAGE) 18:11, 5 March 2026 (UTC)

So would it do that over and over again for a bunch of admins? VidanaliK (talk to me) (contributions) 18:11, 5 March 2026 (UTC)

Wait, what are namespaces 1 and 3? I don't see that on WP:NAMESPACE. VidanaliK (talk to me) (contributions) 18:12, 5 March 2026 (UTC)

They're in the floating table (1 = "Talk", 3 = "User talk"). sapphaline (talk) 18:13, 5 March 2026 (UTC)

Odd-numbered namespaces are for talk pages. 1 is Talk: and 3 is User talk:. mdm.bla 18:14, 5 March 2026 (UTC)

Wait, so after only 15,000 page loads every page on the English Wikipedia would be gone... VidanaliK (talk to me) (contributions) 18:15, 5 March 2026 (UTC)

The code as dormant for 1.5 years until he started massively adding userscripts to his global.js page to test its limits. One of these edits imported the malicious code and it worked because he had enough privileges. See Wikipedia:Village stocks § Scott Bassett for the Закрываем проект award FaviFake (talk) 18:03, 5 March 2026 (UTC)

The meta version of MediaWiki:Common.js was edited to load a malicious script which made bad edits from the accounts of innocent users. MediaWiki:Common.js automatically runs for all users of the wiki with JavaScript enabled which is nearly all users. All wikis were put in read-only mode by the Wikimedia Foundation to prevent spreading and investigate what was happening. MediaWiki:Common.js can be edited by a limited number of trusted users, some with global permissions for all Wikimedia wikis, and local Wikipedia:Interface administrators (we have 15). Normal administrators cannot edit it (they could years ago). PrimeHunter (talk) 18:07, 5 March 2026 (UTC)

A good argument for the next "please enable Javascript" debate, it seems... ~2026-10830-00 (talk) 17:57, 5 March 2026 (UTC)

For the time being, I'd recommend to install Greasemonkey and import everything there. Unfortunately scripts which rely on jquery won't work with this approach. sapphaline (talk) 18:17, 5 March 2026 (UTC)

I was wondering why the gadgets like DYK Check, Cite Unseen, etc. are not working. Just came to know this, sad! M. Billoo 18:23, 5 March 2026 (UTC)

Can't wait for the mainstream media to mention the incident. Ahri Boy (talk) 18:26, 5 March 2026 (UTC)

"Wikipedia gets hacked by administrator!" Pretty much every outlet criticising Wikipedia for all the world's problems (plus the teachers for which it is heresy to even say the word "Wikipedia") is going to have a field day with this. The question is, how do they get their reports? Do they go to a page called Village pump (technical) searching for the tiniest incident of something weird happening with Media-Wiki? VidanaliK (talk to me) (contributions) 18:31, 5 March 2026 (UTC)

Yes, they do. They also do it with all other village pumps, ANI, Wikipedia:Requests for comment/All, etc. sapphaline (talk) 18:34, 5 March 2026 (UTC)

They'll find out when the WMF puts out a statement, which I'm sure they will do. Most media doesn't troll projectspace. voorts (talk/contributions) 18:35, 5 March 2026 (UTC)

At least Reddit thread covered the incident. I guess only time will tell mainstream media will disseminate statement from the WMF. Ahri Boy (talk) 03:09, 6 March 2026 (UTC)

tiniest incident

? This was a major outage! FaviFake (talk) 18:35, 5 March 2026 (UTC)

It could be a fun story for the general public. The media may omit some details like the WMF/Wikipedia/meta distinction: A security engineer working for Wikipedia decided to run a large number of random unexamined scripts to see what would happen. He found out. He did it with his high-permission account which could infect every user if a single of the random scripts was bad. It was. PrimeHunter (talk) 18:46, 5 March 2026 (UTC)

This is better:

On Thursday a Wikimedia security engineer ran several scripts on the Wikimedia server without examining the code to check for malware. One of the scripts was a malicious program originating on the Russian-language Wikipedia, which when installed caused the accounts of all administrators on Wikipedia, Wikisource, Wiktionary, and several other projects to mass-delete pages. This resulted in Wikipedia being frozen for several hours as other security engineers tried to patch the issue. VidanaliK (talk to me) (contributions) 20:06, 5 March 2026 (UTC)

Any post to WMF or the media should have arguments with it like best practices for whitehat testing. Snævar (talk) 21:54, 5 March 2026 (UTC)

FYI phab:T419154 for the site scripts disabled thing, it's being tracked - plan is to get it back soon. — xaosflux ^Talk 18:37, 5 March 2026 (UTC)

We really need something like bot passwords for the web interface. You don't stay logged in to your machine as root all the time, do you? Yet there's no choice but to do that here. Suffusion of Yellow (talk) 18:55, 5 March 2026 (UTC)

Yeah, I'm also baffled by how Scott Bassett just ran these scripts on their main account with all rights without any second thought. sapphaline (talk) 18:57, 5 March 2026 (UTC)

Perhaps highly-privileged accounts with interface administrator permissions should have mandatory Always Safe Mode enabled.

I personally have a few userscripts that I use (and I've made sure to copy them to my own userspace now). But it doesn't seem unreasonable to encourage using a separate account for those routine tasks where scripts can save a lot of time. If today is a day where you do need to juggle chainsaws and other scary tools, it would seem wise to use a safe mode account. Mlkj (talk) 19:16, 5 March 2026 (UTC)

and I've made sure to copy them to my own userspace now: That only protects you if the script's owner is the compromised account. Doesn't help if an intadmin (or crat or steward ...) is compromised. But if there's an unintentional security problem with script (XSS, etc.), your copy won't get fixed if it's discovered. If the script has only one component (e.g. foo.js doesn't load foo-core.js) you can use a Subresource Integrity check instead of copying it. Suffusion of Yellow (talk) 19:26, 5 March 2026 (UTC)

Oh, looked at your userspace, I see the script in question is just a few lines long. Yeah, then it's probably better to just review and copy it. Suffusion of Yellow (talk) 19:28, 5 March 2026 (UTC)

The problem with forced safemode for intadmins is that they would no longer be able to run admin scripts like these because you are not permitted to have more than one account with admin permissions. SuperPianoMan9167 (talk) 19:30, 5 March 2026 (UTC)

I like scripts, so I'm sympathetic to that. But I see there's already an exception for WMF, how about another one for the baker's dozen of interface admins out there? Mlkj (talk) 19:45, 5 March 2026 (UTC)

See T419152 RoySmith (talk) 19:00, 5 March 2026 (UTC)

Cool, another feature request that can be ignored for the next 8 years. --Ahecht (TALK
PAGE) 19:09, 5 March 2026 (UTC)

I assume this is why my .js are not loading? - FlightTime (open channel) 19:24, 5 March 2026 (UTC)

Yes. RoySmith (talk) 19:28, 5 March 2026 (UTC)

And stop testing in prod. OhanaUnited^{Talk page} 19:26, 5 March 2026 (UTC)

It's not correct to say attack scripts was created in 2023. As written on wikireality.ru/wiki/РАОрг, they (or their earlier versions) more likely created in 2013. Also, their author, wikireality.ru/wiki/Скрипты_WikiUserFS, is still not blocked: https://ru.wikipedia.org/wiki/special:CentralAuth/WikiUserFS. MBH (talk) 20:00, 5 March 2026 (UTC)

• Noting that @Rhododendrites has started a discussion at the BLP noticeboard: WP:BLPN#Wikipedia:Village stocks and this morning's incident SuperPianoMan9167 (talk) 20:06, 5 March 2026 (UTC)

Post from WMF staff member on Discord:

Hey all - as some of you have seen, we (WMF) were doing a security review of the behavior of user scripts, and unintentionally activated one that turned out to be malicious. That is what caused the page deletions you saw on the Meta log, which are getting cleaned up. We have no reason to believe any third-party entity was actively attacking us today, or that any permanent damage occurred or any breach of personal information.

We were doing this security review as part of an effort to limit the risks of exactly this kind of attack. The irony of us triggering this script while doing so is not lost on us, and we are sorry about the disruption. But the risks in this system are real. We are going to continue working on security protections for user scripts – in close consultation with the community, of course – to make this sort of thing much harder to happen in the future. FaviFake (talk) 20:14, 5 March 2026 (UTC)

That still doesn't explain why they were running random scripts from an account with intadmin permissions. --Ahecht (TALK
PAGE) 23:15, 5 March 2026 (UTC)

huh?? Weren't they doing that just to test the limit of script imports, i.e., how many mw.loader.load()s they can do before something breaks? That's not a security review as part of an effort to limit the risks of exactly this kind of attack. Sure, call it a "security review," whatever, but how exactly is that relevant to limiting "exactly this kind of attack"? — DVRTed (Talk) 02:57, 6 March 2026 (UTC)

Surely not; there is no limit to how many mw.loader.load()s you can do, other than what your computer can handle. I think the review was to see how the scripts would handle changes to the Content Security Policy that would disallow loading some external scripts, which would indeed limit this kind of attack, and which were indeed deployed today as part of the response. Matma Rex talk 03:28, 6 March 2026 (UTC)

@Matma Rex Sure. Thx. Is there a phab ticket related to these changes to CSP? meta:Wikimedia Foundation/Product and Technology/Product Safety and Integrity/March 2026 User Script Incident is way too vague and says pretty much close to nothing as to why this incident occurred, so I'm just going off of whatever random thing I find people saying about it online. — DVRTed (Talk) 04:23, 6 March 2026 (UTC)

@DVRTed There doesn't seem to be one. I'm just going by the configuration changes I saw, e.g. [20]. Matma Rex talk 14:42, 6 March 2026 (UTC)

@DVRTed See phab:T419237 and its various parent tasks. --Ahecht (TALK
PAGE) 15:37, 6 March 2026 (UTC)

@OhanaUnited, Oshwah, PrimeHunter, and Ritchie333: Pinging a few random admins from this thread. Could someone please update the watchlist notice to link to this discussion? The notice currently reads Userscripts are temporarily disabled for security reasons but does not link to anywhere to provide context. I'm sure many users will be unaware of this thread unless it's linked in the notice. Zeibgeist (talk) 21:10, 5 March 2026 (UTC)

A link from the watchlist notice would be nice, but this thread (especially at the top) is a lot of people trying to figure out what's happening rather than a concise summary of what happened and what editors might need to know. Sdkb ^talk 21:12, 5 March 2026 (UTC)

Well we've pretty much already figured out everything. Ideally there should be a link pointing to the summary of the incident, but that's been deleted from the village stocks. FaviFake (talk) 21:15, 5 March 2026 (UTC)

The watchlist notice definitely needs to link somewhere. There are already threads at WT:NPP/R and the Teahouse with people confused about their userscripts being disabled. Linking to a centralized thread where that is being discussed is better than no info at all. Adding a couple more admins @Xaosflux and Ahecht: to get an opinion on this. Zeibgeist (talk) 21:19, 5 March 2026 (UTC)

@Zeibgeist Would linking to phab:T419154 be enough? — xaosflux ^Talk 21:59, 5 March 2026 (UTC)

Thanks for the prompt response. It looks like Oshwah has it handled. Zeibgeist (talk) 22:06, 5 March 2026 (UTC)

That doesn't seem unreasonable at all; stand by... ~Oshwah~^{(talk) (contribs)} 21:49, 5 March 2026 (UTC)

Zeibgeist -  Done. ~Oshwah~^{(talk) (contribs)} 22:04, 5 March 2026 (UTC)

Excellent, thank you! That will hopefully clear up some of the confusion. Zeibgeist (talk) 22:06, 5 March 2026 (UTC)

Wait, I have an idea for patching! An edit filter preventing pages from being deleted using automatic scripts. VidanaliK (talk to me) (contributions) 22:03, 5 March 2026 (UTC)

This would be a drastic overhaul of administrator workflow. It would also only address one type of action a malicious script can take -- I would think a solution to this problem should address the root issue of a script taking control, not just preventing damage in one or more ways. Giraffer (talk) 22:14, 5 March 2026 (UTC)

Or maybe requiring administrator approval for high-stakes tasks performed by automatic scripts? VidanaliK (talk to me) (contributions) 22:15, 5 March 2026 (UTC)

On a technical level once you have a script running it's hard to know whether the user or the script took the action. It's different from the bot API, because a script just uses your own web browser on your behalf. It can silently submit any form and click any button that the user has access to, and it'll look like the user did it. Mlkj (talk) 22:32, 5 March 2026 (UTC)

You can force people to reauthenticate through a page loaded in safemode, though, and a script cannot hijack that (if implemented properly). This would probably be a bit annoying (like it'd make intadmins put in their password every time they edit a sitewide js page), but perhaps worth it. Elli (talk | contribs) 22:36, 5 March 2026 (UTC)

Yeah, it's better that people have a slight inconvenience when performing automatic actions than a malware script from Russian Wikipedia in 2013 take over the Wiki and delete thousands of pages en masse. Restoring such pages is probably going to take even longer. VidanaliK (talk to me) (contributions) 22:39, 5 March 2026 (UTC)

I assume initadmins editing a sitewide JS page is an infrequent enough event that requiring a re-authentication would not be an excessive burden.

The trick with these sorts of things is to make them painless enough that people don't invest effort to find ways around them. In the command-line world, there's the "sudo" command which requires a reauth before allowing somebody to do dangerous things. A well-configured setup will make doing the right thing easy enough that people don't mind doing it. If you make it really painful, they'll start doing things like "sudo bash" and live in that shell all day (and when you disallow that, they'll find more creative ways around it). RoySmith (talk) 22:43, 5 March 2026 (UTC)

Yes. The best attack I can see against that is the risk of reauth/2FA fatigue. Wait until the user is about to click a button that will send them to the safemode reauth page and hijack the action to be "edit common.js" instead of whatever it was, or show a phishing reauth page (e.g. steal credentials, show a fake error, then display the real reauth page).

I like this idea though. I hope it's not too much work, I feel like we really need something more around sensitive actions like these. Mlkj (talk) 22:45, 5 March 2026 (UTC)

Noting that there is a statement about this incident on Meta, see Meta:Wikimedia Foundation/Product and Technology/Product Safety and Integrity/March 2026 User Script Incident. 45dogs (they/them) (talk page) (contributions) 00:30, 6 March 2026 (UTC)

Which strikes me as corporate-speak that explains much less than is explained on this thread. - Jmabel | Talk 01:14, 6 March 2026 (UTC)

True, true. I was pissed that Reftoolbar wasn't working, and reading this live thread (before the resolution) I could bear the pain.;-) Carlstak (talk) 02:28, 6 March 2026 (UTC)

@Jmabel and Carlstak: Well, anyone can edit it, but I wouldn't go any further with it than I just did. Graham87 (talk) 03:32, 6 March 2026 (UTC)

Well, that's not very far. It may be accurate as far as it goes, but it sounds like boilerplate. Needs one of those people who love to add plots to WP movie articles to write up a summation of the thread. Carlstak (talk) 07:02, 6 March 2026 (UTC)

I subsequently got reverted anyway. Meh ... there was an edit button there. Graham87 (talk) 08:09, 6 March 2026 (UTC)

@Jmabel: It's called "need-to-know". If you need to know exactly what happened, they will have told you already. If they've not told you, you don't need to know. As with any security issue, the fewer details that are public, the less likely it is to occur again. See also WP:BEANS. --Redrose64 🌹 (talk) 09:15, 6 March 2026 (UTC)

@Redrose64: sorry, I'm not buying it. The discussion here is totally public, and black-hat types will find it and absorb it. There is no security advantage in failing to say that a "bomb" script lay around, visible, for over a year, no one in the community noticed it, and a WMf employee (one involved in security, no less) accidentally triggered it. - Jmabel | Talk 16:29, 6 March 2026 (UTC)

Syntax Highlighter broken?

The Syntax Highlighter gadget was working yesterday, but today it no longer works in Brave Web Browser. I tried it on two different systems, one running Microsoft Windows 11 and the other Linux Mint 22. The gadget still works in Firefox. I have made no changes to the settings in my Wikipedia account and the browser was not updated on either machine. What gives? — Foxtrot1296 (talk) 19:58, 5 March 2026 (UTC)

@Foxtrot1296: See the "Meta-Wiki compromised" thread above. BD2412 T 20:04, 5 March 2026 (UTC)

The Syntax Highlighter I'm assuming that Foxtrot1296 is referring to is not a user script or gadget; it's a MediaWiki extension. So the above discussion will not provide any answers. SuperPianoMan9167 (talk) 20:11, 5 March 2026 (UTC)

There are multiple syntax highlighters. Some of them are actually JS gadgets. * Pppery * _{it has begun...} 20:19, 5 March 2026 (UTC)

If the one Foxtrot is using is a gadget, it shouldn't be working in any browser at all. But since it's working in Firefox, I think they're talking about the built-in one. SuperPianoMan9167 (talk) 20:28, 5 March 2026 (UTC)

Please note that Foxtrot1296 has User:Foxtrot1296/common.js, which will not be run for the time being (for the reasons above). Foxtrot1296, if there's a gadget at Preferences → Gadgets that will perform the same function, you should enable that instead. --Redrose64 🌹 (talk) 22:22, 5 March 2026 (UTC)

Syntax Highlighter is now working again in my account. The malfunction was most likely due to the Meta-Wiki security compromise. Thanks for all your responses. — Foxtrot1296 (talk) 04:07, 6 March 2026 (UTC)

Manual archive button not working on talk pages?

Just wondering if anyone else has run into this issue. I have "User:Elli/OneClickArchiver.js" installed on my common.js but today the archiving link has gone missing from actual talk pages. - Shearonink (talk) 20:21, 5 March 2026 (UTC)

All user scripts and gadgets are currently disabled. See #Today's outage above. SuperPianoMan9167 (talk) 20:22, 5 March 2026 (UTC)

@SuperPianoMan9167: Gadgets enabled at Preferences → Gadgets are all still working for me. --Redrose64 🌹 (talk) 22:27, 5 March 2026 (UTC)

Right, I still have Edit Conflict which I used recently. VidanaliK (talk to me) (contributions) 22:30, 5 March 2026 (UTC)

That explains why Twinkle (but not TwinkleMobile) is still working for me. It seems that gadgets are working again. SuperPianoMan9167 (talk) 22:35, 5 March 2026 (UTC)

Ok, read most of the "today's outage" section. I sort of understand it but wanted to mention that the Archive functionality for talk pages (from a script installed on common.js) is still not restored/working. - Shearonink (talk) 23:16, 5 March 2026 (UTC)

That's because scripts are still disabled. Headbomb {t · c · p · b} 23:27, 5 March 2026 (UTC)

See, I had missed that tidbit. Thanks for the news. - Shearonink (talk) 23:54, 5 March 2026 (UTC)

T419154 was just updated with "Most user JS scripts should be working again". RoySmith (talk) 00:14, 6 March 2026 (UTC)

And to head off the inevitable question: no, I don't know what "most" means. RoySmith (talk) 00:14, 6 March 2026 (UTC)

Based on the config settings which were changed during the incident and haven't been reverted, it seems that it refers to the fact that the Content Security Policy for Wikimedia sites has been changed and will now prevent some scripts from external domains from being loaded. I think Scott's ill-fated testing of user scripts was actually meant to determine how many of them would be affected by these new CSP rules (as hinted in #c-FaviFake-20260305201400-Nardog-20260305153100). I would guess the security folks are not as confident as they'd like to be about this accelerated rollout, but a lot of testing has gone into it already, so… most scripts should be fine. Matma Rex talk 02:45, 6 March 2026 (UTC)

userscripts were temporarily disabled but they should work again Laura240406 (talk) 00:33, 6 March 2026 (UTC)

Thanks everybody. Yes, the archive script is working again. Huzzah! - Shearonink (talk) 00:54, 6 March 2026 (UTC)

Stats at page top

Not sure what you call this, but at the top of every page, we usually have an update on things like how many page viewers, etc. That's been missing in the last couple of days. — Maile (talk) 20:47, 5 March 2026 (UTC)

See #Today's outage. Headbomb {t · c · p · b} 21:24, 5 March 2026 (UTC)

Thanks for the info. — Maile (talk) 21:40, 5 March 2026 (UTC)

Looks like the issue has just teen taken care of. Hooray, ! — Maile (talk) 22:12, 5 March 2026 (UTC)

"Hide top contributions" no longer working?

I guess there was some kind of upgrade since Wikipedia was "read only" for a bit today. Since then I have not been able to use the "Hide top contributions" function on my history (User:Markhurd/hidetopcontrib.js - this user hasn't edited since 2017 [edit: they are deceased apparently]). I use this a lot to keep track of vandalism on particular articles. Is there a way to bring it back? I'm not a coding person so I wouldn't know how to fix it myself. ... discospinster _talk 22:32, 5 March 2026 (UTC)

discospinster, this is another side effect of the read-only issue – all users' .js/userscripts are currently disabled. The Phabricator task says they should hopefully be back soon. Perfect4th (talk) 22:39, 5 March 2026 (UTC)

(edit conflict) discospinster, userscripts are currently disabled. See Wikipedia:Village pump (technical)#Today's outage. 45dogs (they/them) (talk page) (contributions) 22:41, 5 March 2026 (UTC)

Thank you @Perfect4th: and @45dogs:, I did not know about this issue. ... discospinster _talk 22:58, 5 March 2026 (UTC)

Hello, and please don't shame me publicly for asking this if already answered above, but my anxiety impedes my understanding in such a long thread. Help me with my paranoid-ish OCD problem: is there any risk now if I was logged in when the attack took place? How do I know if everything is clean? Thanks, and I do know it is more pathological of my mind than real, but if anyone can bring relief to my mental health, I tenderly appreciate it. --CoryGlee 00:37, 6 March 2026 (UTC)

Nope, everything has been patched now! VidanaliK (talk to me) (contributions) 00:41, 6 March 2026 (UTC)

Thanks. As stupid or immature it may sound, a reaffirming word clears the dark skies of a (my) mind. LOL. CoryGlee 00:43, 6 March 2026 (UTC)

Of course! I get super paranoid sometimes too. VidanaliK (talk to me) (contributions) 00:48, 6 March 2026 (UTC)

What just happened?

Has the JS/user script vulnerability been addressed? Holy hell. I think we seriously need guardrails regarding user scripts. --- n.h.huit 04:15, 6 March 2026 (UTC)

@.nhals8 Unsurprisingly this wasn't really a userscript problem but more a PEBKAC problem. It's fixed. Polygnotus (talk) 12:42, 6 March 2026 (UTC)

A failed Interwiki link

en:Pozzato and it:Pozzato are essentially the same. The overlap isn't complate, but they're both surname pages. On attempting to create an Interwiki link in either direction, I get the error messge "Could not link pages: failed to merge corresponding Items on Wikidata. Attempted modification of the Item failed." in the en:it direction and "The save has failed. The link enwiki:Pozzato is already used by Item Q56245816. You may remove it from Q56245816 if it does not belong there or merge the Items if they are about the exact same topic. If the situation is more complex, please see Help:Sitelinks." Can anyone resolve this silly problem? I have zero interest in learning how to do this trivial piece of useful housekeeping.Narky Blert (talk) 19:44, 5 March 2026 (UTC)

I added it manually. No issue reared its head. BD2412 T 20:04, 5 March 2026 (UTC)

@Narky Blert: The English article is linked to the Wikidata item for the family name, whereas the Italian is linked to the one for the disambiguation page. Per the "different from" statement, "family name has to use a different item than disambiguation page". This mutually exclusive criterion is probably why the merge failed.

Per WP:SETNOTDAB, the English article should not be moved to the Wikidata item for the disambiguation page. The Italian article is categorised as Pagine di disambiguazione, so also seems to be at the right item. I'm unsure if the Italian Wikipedia has the same distinction between set indices and disambiguation pages. Wikipedia:Set index articles and {{Set index article}} don't appear to have versions on the Italian Wikipedia (or if they exist, they don't share a Wikidata item). – Scyrme (talk) 20:15, 5 March 2026 (UTC)

Missing talk page history?

I feel certain that there have been discussions at Turkish Roma of the terminology used to discuss the group that's the article's topic, and possibly even a prior move discussion. Following a move war that I hope I just put an end to, the article's back at Turkish Roma, where it has been since September 2022, but the talk page has nothing but WikiProject banners on it. Did something get lost somewhere during or before the move war? I can't figure out where to look. Largoplazo (talk) 23:22, 5 March 2026 (UTC)

Are you sure there were in fact any such discussions? DS (talk) 00:48, 6 March 2026 (UTC)

OK, never mind, I found what I'd been thinking of. It did include discussion of naming with respect to Turkish Roma in particular, but it was an overall more general discussion, a move discussion that's now at Talk:Romani people/Archive 13. Largoplazo (talk) 01:11, 6 March 2026 (UTC)

I'm not sure if this is what you were looking for: Talk:Turkish Romani. I used the Special:PrefixIndex/Talk:<page> on existing redirects in case some archive subpage was not moved and I didn't locate one, but have noticed this. ~2026-10830-00 (talk) 01:19, 6 March 2026 (UTC)

It appears there was a WP:HISTMERGE given the oldest revision is a move from Turkish Romanian to Turks of Romania yet the next is a move from Turkish Romanian to Turkish Romani 14 years later. Nardog (talk) 03:51, 6 March 2026 (UTC)

I noticed those long-ago moves while going through this but didn't take the time to investigate. The move from "Romanian" to "Romani" seems suspicious, unless the situation was that the article was written by someone who didn't the difference in English between Romanians and Romani and had used the wrong term, followed by someone fixing it. I'll try to take a look later if curiosity gets the better of me. Largoplazo (talk) 13:19, 6 March 2026 (UTC)

Fix self-linking

If somebody understands how to, can you please fix the "MAGA Inc." not to appear as link in this section (I tried using the {{#section}} template but didn't get it to not self-link that): Make America Great Again Inc. # "Pay-for-Access" Or does use of Template:No self link make sense here? D4n2016 AMD  RYZEN  ZEN 3 user Talk 03:02, 6 March 2026 (UTC)

{{No self link|MAGA Inc}} fixed it. PrimeHunter (talk) 03:28, 6 March 2026 (UTC)

Template-defined text colours in dark mode

I've noticed on several sidebar templates that black text becomes white in dark mode, even if the template has color:black set in its style parameters. Adding the class skin-invert inverts everything except the text, which stays white. Adding class mw-no-invert instead has no effect, and the text is still white. Adding {{black}} directly to the title/heading makes it black, but adds a white background because for some reason that template also uses background: white.

An example of such a template is {{Tibetan Buddhism sidebar}}, where the white headings are difficult to read in dark mode because the background is light.

Is there a way to fix this without throwing out their styles and making every sidebar use dark background or stripping it down to the default so dark mode works as intended? Given {{black}} somehow accomplishes making the text black when the background is white, surely this is possible? Or does it only work with white? Would this require changing something about how dark mode itself is implemented to fix? – Scyrme (talk) 08:40, 6 March 2026 (UTC)

The mw-no-invert class isn't part of the dark mode that is available in the default skins, as indicated on top of the page of the extension that uses that class. I would recommend to follow-up the instructions on mw:Recommendations for night mode compatibility on Wikimedia wikis instead. Sjoerd de Bruin (talk) 08:44, 6 March 2026 (UTC)

@Sjoerddebruin: Copying pane notheme mw-no-invert from the "good example" listed there seemed to work. However, I also found that notheme by itself worked. Do you happen to know why the other two classes are included? I'm particularly unsure what pane is for. – Scyrme (talk) 09:09, 6 March 2026 (UTC)

Using color:var(--color-base,#202122); instead of color:black often has the desired effect. – Jonesey95 (talk) 14:25, 6 March 2026 (UTC)

In addition to the styles you see in various places over here, there are styles sitting on top of everything that come with the software itself, see here. Ponor (talk) 10:30, 6 March 2026 (UTC)

Sidebars are unaffected by anything in the relevant CSS. Izno (talk) 17:19, 6 March 2026 (UTC)

{{sidebar}}s support |templatestyles= and should use that as a solution if you want to guarantee them to appear a certain way. (There is a category for someone who wants to convert styles to TemplateStyles but personally it is the lowest of any low priorities.) Izno (talk) 17:18, 6 March 2026 (UTC)

Finding more malware

Has anyone bothered search all Wikipedia's for more naughty scripts, e.g. scripts that contain the string "nuke" or "action=delete"? Also scripts with obfuscated stuff like percent encoded stuff. Polygnotus (talk) 16:35, 6 March 2026 (UTC)

There are about 40 such scripts on English Wikipedia containing the word nuke. You may consider global search if you want to review others. Izno (talk) 17:15, 6 March 2026 (UTC)

@Izno Thanks! But it looks like I can't use global search to detect percent encoded Javascript by searching for the percent encoded versions of strings commonly found in Javascript (like var and let). Do you happen to know how to do that? SQL? Looping over each endpoint using insource:? Polygnotus (talk) 17:29, 6 March 2026 (UTC)

External images still not loading for my user styles

I have custom user styles that decorates the interface with images hosted elsewhere. However, even after user scripts were re-enabled after the incident, the images are still not loading. What can be done? My user styles' code can be accessed at User:PrincessPandaWiki/common.css and User:PrincessPandaWiki/vector.css. ❤︎PrincessPandaWiki (talk | contribs) 17:06, 6 March 2026 (UTC)

Yes, these are due to the CSP that has been enabled as a result of yesterday (but which was coming regardless). Your only recourse is to request these websites be allow-listed on phab:. I do not anticipate your success given the specific domains of interest. Izno (talk) 17:11, 6 March 2026 (UTC)

Mobile site is forced

I'm on a Chromebook and can't figure out how to get the desktop version of Wikipedia. It won't let me change skins, and all my edits are tagged with "mobile edit". --FishOnSkates 17:17, 6 March 2026 (UTC)

@FishOnSkates: Click "Desktop view" at the bottom of a page. In some browsers you may have to scroll to the bottom of the page a second time to see it. PrimeHunter (talk) 17:24, 6 March 2026 (UTC)

@FishOnSkates also if you want to make it permanent on all devices detected as mobile see User:Þjarkur/NeverUseMobileVersion as an option. Cheers KylieTastic (talk) 17:36, 6 March 2026 (UTC)

Strange hashtag

Hello. I'm testing something with templates and subtemplates, #switches and #ifs, (not on en:wiki, sorry) and then when I use a parameter like this |color=#ccffcc in an article, it doesn't appear as the lightgreen cell background, but as follows:
style="background:

1. ccffcc;"

I think my code is pretty good because when I use, for example |color=green, everything is fine. Parameter |color=#ccffcc also works, but that's not the solution I want. Do you know of any trick to fool that strange hashtag? Thanks, Maiō T. (talk) 17:44, 6 March 2026 (UTC)

@Maiō T.: You didn't name the wiki but here we have {{Encodefirst}}. PrimeHunter (talk) 17:52, 6 March 2026 (UTC)

Proposals

Guideline status for WP:CLOSE

Should WP:Closing discussions be made a guideline? Aaron Liu (talk) 17:22, 26 January 2026 (UTC)

Survey (WP:CLOSE)

• Support as proposer: WP:Close is an information page that well-documents current community practice with the level-of-detail one'd expect from a guideline, with the exception of the "Closing procedure" section mostly of uncontroversial technical details, but it's not unheard of for guideline pages to include such sections either (e.g. Wikipedia:Signatures#Dealing with unsigned comments). Despite the widespread practice of consensus being the counted supermajority when arguments are of equal weight, this determination is only documented in essays and this information page (If the discussion shows that some people think one policy is controlling, and some another, [...]). An experienced editor in a discussion I closed a few months ago pointed this out to me and thus argued my close should've said "no consensus" instead as a small number of participants !voted oppose. The increased visibility of this page as a guideline would reduce the amount of editors (including newcomers) who aren't caught up on our closing standards.
  It is my opinion that the practices documented in this information reflect the current community standard, and the situation I mentioned above marks a need for such practices to be included in guidelines. Aaron Liu (talk) (timestamp omitted deliberately to improve the permanent discussion link)

  To address concerns of Creep/excessive rulemaking: Creep-avoidance's purpose is to keep Wikipedia policy and guideline pages easy to understand, but currently we have absolutely no guidelines on how consensus is determined from a discussion, save overall concurrence. Wikipedia:Consensus#In talk pages is worthy of mention as it does list some qualities to weigh for arguments, but it doesn't mention critical things like how arguments of equal weight are compared numerically and when discussions should be closed.(Other than WP:ROUGHCONSENSUS, which misleadingly lives on Wikipedia:Deletion guidelines for administrators—it is outdated to imply these standards only apply to deletion. It should live on a dedicated page to increase visibility and reduce the overlapping maintenance work needed, and WP:Close is pretty much what it says.)

  As opposed to WP:Snow and the much more redundant WP:Poll, I think this is something newcomers need to read like the other major guidelines. I don't see these things mentioned anywhere else, and I feel like things so normative should be mentioned in our PaG, accessibly, as Creep intends. Aaron Liu (talk) 21:23, 9 February 2026 (UTC)

• Support per Aaron Liu. I've long found this a useful guide and personally never had it questioned as only an info page, but I can see the issue of it not being an official guideline as an issue, especially given it's the guidelines that closers follow. It might be worth considering some other pages in this area for review and promoting; Wikipedia:Non-admin closure (widely accepted essay, referenced in hatnote at WP:INVOLVED as guidance on involvement for non-administrator actions - also not a guideline but quasi-advertised as such. Likewise we have Wikipedia:Requested moves/Closing instructions, as a subpage of RM no less, which again is nothing more than an essay, even if widely used as guidance. I think it might be time to start making the effort to categorise certain pages more accurately, reflecting their status quo as defacto guidelines. CNC (talk) 13:30, 30 January 2026 (UTC)

  I’m less supportive of NAC as that seems overly prescriptive. Maybe it’s key points can be brought into CLOSE. Dw31415 (talk) 14:12, 30 January 2026 (UTC)

  We also have Wikipedia:BOLD, revert, discuss cycle, which is "nothing more than an essay", even though there are editors who think that this optional process is mandatory in all cases. (Wikipedia:Nobody reads the directions; if they did, they'd see that it's explicitly described as optional.) Wikipedia:Five pillars isn't marked as a policy or guideline, because Wikipedia:Not every page needs a tag. There is no requirement for good advice to be marked as a guideline or policy. WhatamIdoing (talk) 15:57, 30 January 2026 (UTC)

  You're not wrong, "enforced BRD" is referenced in WP:STANDARDSET, whereas BRD is only an essay intended as advise. Given it describes an optional strategy rather than any fixed rules, the categorisation doesn't seem off to me at all. Realistically it's evolved into an infopage as documents the cycle in-depth, rather than pov-led like essays often are.

  I'm aware not everything needs a tag, but if there are sets of best practices supported by consensus, then promoting to guideline satus is logical for sake of clarity. Five pillars is otherwise a higher-level summary page, so acts more like an infopage than policy or guidelines. There doesn't appear to any independently crafted policies or guidelines, only references to them. Thus, it's categorised correctly as a page that either isn't confirmed to have widespread consensus, or doesn't require it. CNC (talk) 16:48, 30 January 2026 (UTC)

  Pinging @Awilley: could you get the link in WP:STANDARDSET changed to User:Awilley/Consensus Required vs Enforced BRD or some other page? There is no reason to send people to WP:BRD itself, as it's largely irrelevant except as a metaphor. (Also, while you're there, do you know how to fix the includeonly mess that broke all the ==Section headings== on that page?) WhatamIdoing (talk) 19:13, 30 January 2026 (UTC)

  Good suggestion, also the notes on that page that are linked need anchors, or ideally resolve the duplicate lists of restrictions. There is one at the base page and the other transcluded to subpages; one with useful links, notes, and a set of other restrictions; and the other without. Hopefully an arb can bring some sanity to that. CNC (talk) 20:19, 30 January 2026 (UTC)

  No, I can't. The Enforced BRD sanction in my userspace is historical and part of the point of STANDARDSET is that it eliminated custom sanctions like the ones in my userspace. ~Awilley (talk) 22:06, 1 February 2026 (UTC)

  (Pedantic note: it didn't eliminate custom sanctions. It made them so only a rough consensus of uninvolved admin at AE could do them.) Best, Barkeep49 (talk) 03:08, 2 February 2026 (UTC)

  Wikipedia:Contentious topics documents a procedure defined by the arbitration committee, and thus only the committee can modify the page. isaacl (talk) 01:21, 2 February 2026 (UTC)

  Great. What's the procedure for getting the committee to stop linking to a page that says it is "one of many optional strategies" (emphasis in the original)? WhatamIdoing (talk) 06:19, 2 February 2026 (UTC)

• Support because that part of guidance with an official stamp of approval was sorely lacking as an explanation of how consensus is actually evaluated. I think it would benefit from inclusion of some fragments of WP:NAC and WP:SUPERVOTE, which are de facto standards anyway. Szmenderowiecki (talk · contribs) 18:56, 30 January 2026 (UTC)

  I support better documenting the de facto approach to consensus. I do find this sentence weird: The desired standard is rough consensus, not perfect consensus. I understand it’s the de facto approach, but should there be an effort to revise consensus, rather than having a separate guideline that sorta says, “we didn’t mean that page, we mean this page”? Dw31415 (talk) 01:09, 31 January 2026 (UTC)

  @Dw31415, do you mean to revise the Wikipedia:Consensus policy page?

  AIUI our notion of Wikipedia:Rough consensus is derived from the Internet Engineering Task Force. "Rough consensus and running code" is the goal for their decision-making process. The first half means that it's unnecessary to have unanimity, to have agreement on the details, or to have a formal vote. In the case of decisions made under RFC 7282, it literally means that support sounds louder than opposition. They are looking for an absence of significant opposition, rather than strong support. The second half means that the group should defer to the people doing the work instead of someone pontificating about theory. WhatamIdoing (talk) 01:51, 31 January 2026 (UTC)

  I'm not sure why we should expect people to know the IETF's protocol.

  That said, I think WP:C already appropriately summarizes consensus as Consensus is ascertained by the quality of the arguments given on the various sides of an issue, as viewed through the lens of Wikipedia policy. Detailed, further explanation is what WP:Close provides. Aaron Liu (talk) 02:26, 31 January 2026 (UTC)

  I think that knowing where some of our concepts came from can help editors understand what ours are supposed to mean. WhatamIdoing (talk) 02:36, 31 January 2026 (UTC)

  I’m not sure about the best solution and don’t want to distract too much from the main question. I just think there’s an odd smell about this (as a guideline) saying we don’t use policy (consensus) we use an essay (rough consensus). If no one else sees a problem with it I’ll defer. Dw31415 (talk) 03:17, 31 January 2026 (UTC)

• Oppose (until harmonized with RFCEND): After some reflection, I oppose based on my understanding that it will make it harder for involved editors to close RfC's with an obvious outcome.Comment: As an example, I tried to close an RfC as an involved editor because the outcome was obvious. The nominator (whom I respect tremendously) wrote that the RfC did not need closure citing the page under discussion. I was relying on RFCEND. I'm concerned that elevating this page to guideline will then give it more weight than RFCEND. My concern would be addressed by changing this page from formal closure is neither necessary nor advisable to RFCEND's involved editors should be able to close most discussions. Thanks for considering! Dw31415 (talk) 14:26, 3 February 2026 (UTC)

  Thank you for your kind words. The exact same wording is present at WP:RFCEND: If the matter under discussion is not contentious and the consensus is obvious to the participants, then formal closure is neither necessary nor advisable. In fact, that's where I imported the sentence at WP:Close from. This is in line with RfCEnd's Editors are expected to be able to evaluate and agree upon the results of most RfCs without outside assistance, uninvolved closers being one kind of outside assistance.

  I unfortunately couldn't find where RfCEnd says involved editors should be able to close most discussions. If it does, that should be removed as it directly contradicts WP:Involved: editors closing such discussions should not have been involved in the discussion itself or related disputes. Aaron Liu (talk) 18:20, 3 February 2026 (UTC)

  It's in Wikipedia:Requests for comment#Reasons and ways to end RfCs: "if consensus is undoubtedly clear, even an involved editor may summarize the discussion".

  See also the FAQ on the talk page:

  Can the person who started the RFC, or another involved editor, write a summary of the discussion?

  Yes. In particular, when a proposal is soundly rejected, proponents are encouraged to accept defeat with grace. However, if the outcome could plausibly be disputed, then involved editors (on all sides of a dispute) are encouraged to let someone else write a summary.

  The RFC process is looking for a good, shared understanding rather than bureaucratic niceties. If the outcome is clear rejection, then having the OP post something like "Everybody hates my idea. Sorry for wasting your time" is a valid summary, and it is not improved by having an uninvolved editor get involved. WhatamIdoing (talk) 18:53, 3 February 2026 (UTC)

  Ah, I misunderstood what "most discussions" meant; sorry Dw3. The sentence you mentioned needs some work, though. It's a 2021 addition that contradicts the bolded sentence I mentioned on what to do when the consensus is obvious, though I do see ways to make it not contradictory. I'll elaborate on WT:RFC and invite you two. Aaron Liu (talk) 14:13, 4 February 2026 (UTC)

  In any case, I don't think this is a problem with WP:Close as WP:RfCEnd says the same thing. Aaron Liu (talk) 14:50, 4 February 2026 (UTC)

  I think there’s some ambiguity of whether CLOSE applies to RfC’s. Does it? Does RFCEND take priority with respect to RfC’s? Dw31415 (talk) 15:45, 4 February 2026 (UTC)

  Both do, and as Whatam mentioned the two pages should (as in the goal) have little overlap and no contradictions. Aaron Liu (talk) 17:59, 4 February 2026 (UTC)

  Changed my "oppose" to a "comment" with the expectation that elevating this doesn't impact the ability to change it or impact the discussion around involved closure. Dw31415 (talk) 16:07, 7 February 2026 (UTC)

• If I had been asked from memory if that page is a guideline, I'd have said yes. It would be fine if it were. ~ ToBeFree (talk) 06:44, 6 February 2026 (UTC)
• I don't think we should mark this as a guideline right now. Compare it to something like WP:NAC which is much closer to being a guideline in form and covers a topic the proposal doesn't: who should close discussions. The proposal is also redundant with many of our existing P&Gs, and WhatamIdoing points some out in the discussion section below. Redundancy adds a maintenance burden---there are many discussions where editor time was spent resolving a policy conflict because two pages drifted apart and no one noticed. Redundant P&Gs also harm editor recruitment and retention when newcomers need to navigate 14 15 policies, see the sources at Criticism of Wikipedia#Excessive rule-making for more on this. WP:CLOSE is a good informational page, but I don't think it's a good idea to make it a guideline.
  Marking this as a guideline won't make newcomers better understand our unique governance system or stop wikilawyers from coming up with a tortured reason to challenge a close. Those are non-starters for me. Frankly, if an editor is starting to interpret P&Gs about closing discussions, they are already so deep into "wikilaw" that they should be evaluating essays by their quality and level of community acceptance, not the banner at the top. Essays like WP:SNOW, WP:NAC, and WP:POLL have incredibly broad consensus and 10x as many links as WP:CLOSE, but they lack a guideline banner because they're not good guidelines. Level of consensus is only part of it. — Wug·a·po·des 08:44, 8 February 2026 (UTC)
• Oppose per WP:CREEP. The current text is quite debatable, starting with the first sentence (Consensus is Wikipedia's fundamental model for editorial decision-making.) WP:BOLD is actually more fundamental because nothing gets written until someone boldly decides to make a start. Insofar as the proposed change would make any difference, it would be to make it more difficult to change this debatable text.
  And formal closing seems quite abnormal and exceptional. The typical talk page discussion consists of someone saying something and no-one responding. And even when there are responses, you rarely get a formal close. Consider the talk page for the page in question, for example. If you look at that or its archive, you'll find about 30 discussions, including a formal RfC, and not a single one has a formal close that I can see. It's a farce.
  Andrew🐉(talk) 17:26, 9 February 2026 (UTC)

  BOLD is actually more fundamental

  WP:Bold is WP:EditConsensus. The very next next sentence after the one you quoted summarizes Bold: Consensus is typically reached as a natural and inherent product of the wiki-editing process; generally someone makes a change to a page content, and then everyone who reads the page has an opportunity to either leave the page as it is or change it.

  The sentence you quoted is the first sentence of WP:Consensus, so I don't think WP:Close would elevate Consensus over Bold here. I definitely could remove it from WP:Close but I unfortunately can't figure out how to do so without making the lede read weird. I'd welcome any suggestions on how to do so!

  formal closing seems quite abnormal and exceptional

  The page does mention that! Besides the second paragraph saying closes are only advised to happen when discourse [is] lengthy and the results hard to determine, half of § When to close discussions is dedicated to explaining what you said here.

  I think we agree on what the page should say, just not whether it says them. I believe making sure the page says these and would be seen is our chance to clarify that these are in fact the community norms. Aaron Liu (talk) 21:30, 9 February 2026 (UTC)

  No, we don't agree. I've looked through this material and it's trash. Let's look at that first sentence again. It's a copy of the first sentence of WP:CON which is a different policy. Why does the page start by talking about consensus rather than talking about closing? These are not the same thing.

  If you look at the first draft of this page, it doesn't say anything about consensus. It is all about closing instead -- terminating a discussion so that no further comments may be made. And this is done mainly to stop disruption and time-wasting.

  Another editor then comes along then then rewrites the page. He's the one who is focussed on determining consensus rather than the process of closing. The page is then confused from that point.

  The page waffles indecisively about how discussions may be left open for years or not closed at all. It repeatedly says that there are no policies for this. It seems to understand that there are different discussion processes such as RfC but it doesn't catalog these and explain their closure rules.

  For example, consider a process page such as WP:ERRORS, which is quite busy and which I attend often. This is quite sui generis in that discussions are resolved rapidly as time is of the essence. They are typically actioned by admins as the main page is protected. After the action is taken, the discussion is typically then blanked. It's not hatted or archived, it's just deleted from the page. Any discussions left open at the end of the day are typically cleared en masse and there is an admin button to do this. There's often not much in the way of consensus or appeal and it doesn't much resemble processes used elsewhere. I don't much like the process but so it goes.

  Other forums such as Arbcom, AE, DYK, ITN or the reference desk have their own old Spanish customs which have evolved over the years. There are lots of discussions at these but they have their own mechanisms and rules for closing them. This page displays no understanding of this and so, as a general guideline, is useless.

  Andrew🐉(talk) 23:54, 9 February 2026 (UTC)

  Closing has two parts: terminating the discussion (with e.g. {{atop}}) and summarizing it (i.e. determining its consensus). (Other forms of terminating are not closure.) I have not seen the former happen without the latter.
  I only see "there are no policies" mentioned once, and of course that would be removed if the page becomes a guideline.
  

  The page waffles indecisively about how discussions may be left open for years or not closed at all

  That would be a problem. Could you specify where you see that?
  

  it doesn't catalog these and explain their closure rules

  I feel like the closure guidelines included on this page are generally applicable. WP:Close's ways of assessing consensus are used on all the pages you've mentioned.
  I think it would be both unwieldy and unnecessary for a page to document the closing procedures of every process page on Wikipedia; I don't see the problem in having the reader just read the relevant process page. Aaron Liu (talk) 12:58, 10 February 2026 (UTC)

• Oppose. If this were to become a guideline about closing, closing would still be described better and in more detail in PAG outside of this page. This alone means that the page should not be promoted to a guideline, and that its nature really is that of an information page. The page's content does not match what would be needed for a comprehensive guideline about closing and lacks unique substantive normative content relative to existing PAG. The actual PAG-grade norms about closing (and highly-specific at that) already exist and they are at:
  • WP:ROUGHCONSENSUS (guideline) -- basically, this section is pretty much the "closing discussions" guideline; it is applied universally -- outside of the deletion process by analogy. The last paragraph significantly references WP:IAR ("shockingly", a local consensus can suspend a guideline)
  • WP:NOTBURO and WP:IAR (policies) through WP:SNOW (titanium-clad interpretation of policy) -- the other closest thing to a substantive guideline about closing discussions. A guideline about closing has to explain WP:SNOW in the prose.
  • Wikipedia:Talk page guidelines#Closing discussions (guideline) -- general informational material about closing discussions already existing in the form of a guideline + one important provision, effectively stating: do not demand an uninvolved close unless the consensus is unclear, the issue is contentious, or the decision has wiki-wide implications, i.e., involved closes are not a priori bad.
  • WP:INVOLVED (policy) -- "involved status" does not matter with respect to closes where the issue is non-contentious and straightforward (that is the correct interpretation).
  • Wikipedia:Administrators#Administrators' abilities (policy) -- It is administrators who are, in general, responsible (normally, by convention) to close discussions.
  • Wikipedia:Deletion process#Non-administrators closing discussions (guideline) -- Even though administrators are, in general, responsible for closing discussions, there are times when it is also appropriate for non-admins to close discussions. This is then significantly elaborated upon. This is another "lost fragment" of the existing one and true "closing guideline", also applied universally, of course -- outside of the deletion process by analogy
  If we were to assemble these genuine norms about closing disussions, we would get an actual standalone, comprehensive Wikipedia guideline about that. But the page nominated for promotion is not that page.—Alalch E. — Preceding undated comment added 17:41, 11 February 2026 (UTC)

  The goal is for this to be that page. I'll go through the sections you mentioned:

  • RoughConsensus is covered far more clearly at § How to determine the outcome except for the last paragraph, which I agree we should add to the "Policy" subsection.
  • I'm not sure what NotBuro says about closes; I only see it discussing the role of rules. I think Snow is adequately summarized in the "When further contributions are unlikely to be helpful" bullet point.
  • I think the TPG section is well-summarized at § Closure procedure.
  • Explained in footnote [5], which is used where how closers should be uninvolved is mentioned. I think this is the right level of prominence.
  • Ooh, this is really good! I think I can consolidate this and WP:Close's explanation of closure qualifications in the Closure procedure section into a new "Who should close discussions" section. Would you support making this a guideline when that is done, or are there other additions you think are necessary?

  Aaron Liu (talk) 03:22, 12 February 2026 (UTC)

• Oppose. My view (pretty similar to Wugapodes) is that this page serves its current purpose pretty well but isn't written with the precision we'd expect from a guideline in this area. WP:NHC in particular is something that is really useful in its current "tips and tricks on determining consensus" role but would lead to more wikilawyering rather than less if people started treating it as authoritative and parsing its every word (example). More generally, although I never used to feel this way, I've come to think that leaving things vague in this area (as illustrated by the one sentence at WP:DETCON) has really been a very wise choice, and I'd encourage people not to knock down Chesterton's fence here unless they're sure the benefits outweigh the costs. Extraordinary Writ (talk) 02:41, 12 February 2026 (UTC)

  For clarity for onlookers, I think the intended diff was Special:Diff/1077853382. I could amend the sentence referenced to add "or different interpretations of the same policy".

  Could you elaborate on the benefits of leaving things vague?Aaron Liu (talk) 03:22, 12 February 2026 (UTC)

  If you're interested in closing, I'd encourage you to reflect on that question yourself for a bit longer. Then come back and share your own thoughts on what this metaphorical fence is for. — Wug·a·po·des 10:19, 12 February 2026 (UTC)

  I have done a dozen closes (and a successful close challenge for someone else's). I do see that there is nice leeway for different closers to weigh arguments differently, but I've never seen that to such an extent that it contradicts WP:Close's guidance. (or did I misinterpret as "it would be bad to have a new guideline on closing" your concerns that were simply on specific sections instead?) Aaron Liu (talk) 12:35, 12 February 2026 (UTC)

• Oppose Information pages shouldn't be turned into guidelines at all, because they serve different purposes. And the information page is not great currently, and turning it into a guideline makes it harder to fix the problems. instruction creep and generally ill-thought out. Much of it is more a weapon for wikilawyers than actually useful. Polygnotus (talk) 01:06, 28 February 2026 (UTC)

Discussion (WP:CLOSE)

Wikipedia:Consensus#In talk pages and Wikipedia:What Wikipedia is not#Wikipedia is not a democracy appear to cover some of the same territory, so I'm not convinced this is necessary. Also: When the other editor pointed out that your close might have been imperfect, am I correct in assuming that said editor was on the "losing" side of that discussion, and thus motivated to find any possible rule that might extend the dispute instead of having it resolved the "wrong" way? WhatamIdoing (talk) 20:11, 26 January 2026 (UTC)

Mostly, I don't see why not make clear a series of practices are standard. Your assumption is correct but I don't see why that lessens the argument for clarity, and said editor is someone I usually wouldn't assume obstructionist motivations. Aaron Liu (talk) 21:14, 26 January 2026 (UTC)

I think that "Why not?" is a fair view. I don't oppose this proposal. WhatamIdoing (talk) 00:26, 27 January 2026 (UTC)

Meta comment: A WP:PROPOSAL is supposed to be made on the talk page of the proposed guideline. I don't think we need to take any action right now, but if this discussion gets long (RFCs on Village pump pages frequently need to be WP:SPLIT to keep the overall page size under control), maybe it could be moved there instead of to a subpage. WhatamIdoing (talk) 20:25, 26 January 2026 (UTC)

Hmm, doing the RfC on the talk page was the original plan but I forgot that was what WP:Proposal prescribes and followed the last guidelinification I knew (Wikipedia:Village pump (proposals)/Archive 219#Superscript and subscript typography guideline). Aaron Liu (talk) 21:14, 26 January 2026 (UTC)

I agree that there should be a guideline on closing discussions, but it might be worth fine-tuning it a bit and getting everything in one place first. Right now it's not as concise as it probably could be. Thebiguglyalien (talk) 🛸 22:08, 26 January 2026 (UTC)

I'd love to hear feedback on that! We could discuss more specific areas of improvement at Wikipedia talk:Closing discussions#Guideline. I'm personally not that great at concision and don't see much myself. Aaron Liu (talk) 22:23, 26 January 2026 (UTC)

I think that concision (fewest words) is less important than being focused (all the necessary points, without wandering off on tangents). WhatamIdoing (talk) 00:25, 27 January 2026 (UTC)

I agree; I did assume the latter is what Thebig meant. Aaron Liu (talk) 03:14, 27 January 2026 (UTC)

+1 Also we should review Wikipedia:RFCEND for conflict / overlap. Dw31415 (talk) 20:42, 27 January 2026 (UTC)

I compared and corrected those two a few years ago, but it's probably time for another review. WhatamIdoing (talk) 20:57, 27 January 2026 (UTC)

I've finally looked over both; I don't believe there is overlap, other than If the matter under discussion is not contentious and the consensus is obvious to the participants, then formal closure is neither necessary nor advisable. which I don't see a problem with. Aaron Liu (talk) 03:22, 28 January 2026 (UTC)

Hi Aaron, I boldly added a link to the RfC close template. Feel free to revert if it should get more review. I would like there were more consistency in using the RfC closure template or to have it deprecated. Dw31415 (talk) 14:34, 30 January 2026 (UTC)

diff Aaron Liu (talk) 17:19, 30 January 2026 (UTC)

Thanks for improving! Dw31415 (talk) 18:15, 30 January 2026 (UTC)

This part of RFCEND strikes me as out of touch with current practice but maybe I’m looking at a controversial subset. Editors are expected to be able to evaluate and agree upon the results of most RfCs without outside assistance. I guess that’s not immediately relevant to this discussion. I support the proposal to make it a guideline. Dw31415 (talk) 03:33, 28 January 2026 (UTC)

I looked through a handful of consecutive RFCs from November-ish. About two-thirds got a closing statement. However, almost half of those didn't need a closing statement (e.g., Andrew Huberman, Advance UK, Scientology) because the responses were so lopsided. That said, sometimes editors want a closing statement for social/behavioral reasons rather than because they don't know what the result is. WhatamIdoing (talk) 06:00, 28 January 2026 (UTC)

It helps prevent the (factually incorrect) wikilawyering over "well that discussion was never closed so there's not a true consensus". Katzrockso (talk) 13:54, 30 January 2026 (UTC)

I don't think I've ever seen that particular claim before, but I'd expect that to be solved by educating the editor about Wikipedia's processes. If that happens a lot (more than a couple of newbies a year), then I'd like to have a few examples (drop some on my talk page? It's kind of off-topic for this discussion), then we should address that error somewhere. Maybe Wikipedia:Tendentious editing#Concerning discussions would be the place for that. WhatamIdoing (talk) 16:02, 30 January 2026 (UTC)

That's the best line on the whole page IMO. Levivich (talk) 03:35, 3 February 2026 (UTC)

Agree it's a good thing so just added an oppose !vote because of a concern about elevating "don't close" over "close most". Dw31415 (talk) 14:29, 3 February 2026 (UTC)

I’d like to propose moving “If the matter under discussion is not contentious” to a L3 section under closing procedure and include the same involved closure language from RfC end. The current bullet is a bit odd (it’s a stand alone bullet and it’s a bit redundant to the following paragraph). Any thoughts on whether I should boldly edit or make a sandbox version? Dw31415 (talk) 18:40, 6 February 2026 (UTC)

I suggest that you let this discussion wrap up, and then boldly make the change. WhatamIdoing (talk) 00:56, 7 February 2026 (UTC)

Dumb question: Is the page harder to change after it’s a guideline? Dw31415 (talk) 02:59, 7 February 2026 (UTC)

No, not usually. It's just awkward to have something change while people are voting. Someone who dislikes the outcome might claim that the change in the middle of the discussion invalidates all the votes they disagree with. So I suggest avoiding changes, even as minor as rearranging. WhatamIdoing (talk) 05:15, 7 February 2026 (UTC)

RfC: Should we deprecate WP:RfA?

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

No previous discussion. And the premise is false, Wikipedia:Requests for adminship/Vacant0 was closed just a week ago Cambalachero (talk) 19:03, 6 February 2026 (UTC)

---

This process has seen rare usgae, even its counterpart WP:RfB is not even used. Should we deprecate it? ~2026-36939-5 (talk) 15:56, 6 February 2026 (UTC)

Survey

• Deprecate per my ratioanle. ~2026-36939-5 (talk) 16:47, 6 February 2026 (UTC)
• Comment in the absence of an WP:RFCBEFORE, this should be speedily closed as premature. It would only be feasible if WP:AELECT were significantly expanded anyway. ~2026-80954-2 (talk) 16:41, 6 February 2026 (UTC)

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

Should we have an essay or something on "Jew tagging"? continuation of archived discussion

Doug Weller talk 15:34, 16 February 2026 (UTC)See archived discussion.[21]

Well, in theory at least anyone can write an essay, though with a topic like this I'd not recommend anyone trying unless they are very familiar with both relevant policy, and with long-running debates over the issue. Any volunteers? I'd offer, but I have my doubts that some in the community would accept my position on this.

Given that some have found reasons to object to the phrase, it would probably be better to avoid actually using 'Jew tagging' in the title. And maybe it might be better to try to broaden the scope out a little: Wikipedia:Ethnic and religious tagging? The problem isn't confined to content on Jewish individuals only, though some of the worst examples can be found there. AndyTheGrump (talk) 15:47, 16 February 2026 (UTC)

I was thinking about writing one, but Real Life caught up with me and I haven't had the time to devote to doing a good job with it. I like Andy's suggestion for a title and focus, since it's a broader problem and shouldn't single out a particular religion or ethnicity, any more than it's permitted in articles, but I don't think we should completely expunge the term or minimize the observable fact that it's the most troublesome example. I've noticed a recent uptick in malicious tagging, and a relative decline in what I would term benign Judeophilic descriptors. If I start one I'll link here so others can participate.

I would welcome examples of similar phenomena with other religions or ethnicities to cite - I've seen some tagging of Muslims, for example, in India-related topics.

There's also a parallel issue of nested nationalities, such as English/British, that has caused strife, especially if the subject is perceived as a different ethnicity. I'm not prepared to work that out. Acroterion (talk) 15:56, 16 February 2026 (UTC)

I didn't intend to propose omitting the term 'Jew tagging' entirely, just not using it as a title: sorry if that wasn't clear. And I'd think that any essay on the topic should clearly include a link to Edward Kosner's Wikipedia-focussed article with that title [22] in Commentary , as a useful outsider's perspective. An essay clearly needs to distinguish between relevant and proportional discussion of a subject's ethnicity and/or faith and the context-free, reductionist/stereotyping bald-assertion-sentence 'X is Jewish' tagging that Kosner and so many others object to, and I think that Kosner's piece expresses it better than most of us could. AndyTheGrump (talk) 18:09, 16 February 2026 (UTC)

The Jewish version of this tagging does have it's own specific issue. The tagging is done by either those who feel the Jewish identity is being hidden, and those who want to (((tag))) Jewish people. This is opposite to the issue found in most articles, where people attempt to exclude individuals from a given ethnicity. Of course the solution is always to follow the sources, but that regularly differs from the POV of editors. -- LCU ActivelyDisinterested «@» °∆t° 18:01, 16 February 2026 (UTC)

Sorry, but if you really think that with the exception of Jewish subjects, 'exclusion' is the only issue, I don't think you've been looking very hard. And no, 'following the sources' isn't necessarily sufficient. It is entirely possible to engage in the most egregious tagging while using an impeccable source. Which is one of the reasons why it can be difficult to deal with. AndyTheGrump (talk) 18:13, 16 February 2026 (UTC)

How is including a factual detail that "impeccable sources" say "the most egregious tagging"? PARAKANYAA (talk) 00:57, 17 February 2026 (UTC)

Often, it isn't the 'what' but the 'how' that matters. As an example, I once got into a dispute with arch Jew-tagger User:Bus stop (now CBANNED) because he wanted an article to merely say 'X is Jewish' in a biography, rather than actually going into any detail regarding the subject's attitude to his faith and ethnicity, which was in my opinion much more enlightening for the biography. Bus stop seemed to see Wikipedia as a Jew-tagger's database, refused to countenance any content that might suggest that the Jewishness of any individual was anything but objective fact, even if the individual concerned was equivocal (which isn't that rare), and routinely resorted to the most ridiculous arguments in order to justify his obsession. In my opinion, any article that has the sentence 'X is Jewish' in it, without further context, needs looking at as potential tagging. You just don't see that in biographies elsewhere. It is reductionist, if not outright stereotyping, and reduces a human being to a mere label. At best it is bad writing. At worst, it is obnoxious. AndyTheGrump (talk) 01:29, 17 February 2026 (UTC)

This is a more general issue with "tagging" (possibly better described as "labelling"), in that often an effort to get a specific word into prose is the end in itself rather than expanding the context or even writing the same thing in a less provocative style. CMD (talk) 05:38, 17 February 2026 (UTC)

See WP:NOTEVERYTHING. Something must be stated in sources in order to qualify for inclusion, but it's up to editors to determine what is or is not relevant and represents the most neutral presentation of facts. You don't need to mention someone's ethnicity any more than their weight or hair color unless it's directly relevant to the rest of the article - for example, the weight of a professional wrestler might be listed, as might the ethnicity of a prominent rabbi - but not for a botanist. Would you include "Caucasian" or "Anglo-Saxon" for every generic white person? ChompyTheGogoat (talk) 05:34, 5 March 2026 (UTC)

Well, it's not only rabbis who can have their Jewish identity be relevant to their life and biography. There are indeed many people whose biographies mention their ethnicity as a relevant biographical fact. Some of them are even botanists. Andre🚐 06:18, 5 March 2026 (UTC)

And wrestlers aren't the only people whose weight is relevant. I just used obvious examples. If you have reliable sources that clearly link someone's Jewish identity to their prominence as a botanist, go for it - but the fact that they're a botanist who happens to be Jewish isn't enough. Keep in mind biographers can be biased too. ChompyTheGogoat (talk) 06:28, 5 March 2026 (UTC)

People can be notable for multiple things. Connecting their Jewishness to their primary thing isn't the standard. It's whether multiple reliable sources have something to say about that biographical fact. For example, Aaron Aaronsohn or Otto Warburg (botanist). They were botanists and also other things. A notable wrestler could also be noted for being a Jewish philanthropist. Etc. Andre🚐 18:51, 5 March 2026 (UTC)

I don't believe I ever said it had to be their primary occupation, but again both their other activities and the relationship between that and their heritage need to qualify as notable. Enough to discuss rather than just "tag". Again, I was keeping examples deliberately simple to make a point. ChompyTheGogoat (talk) 21:01, 5 March 2026 (UTC)

• As I said in the previous discussion, you can just write the essay yourself? Essays are cheap. But I would focus mostly on "how to recognize it" and "here are the relevant policies" (eg. MOS:ETHNICITY, WP:DUE), plus maybe some convenience links to previous discussions or external coverage of the problem. I don't think trying to get consensus out of the gate is a productive use of time for an essay - just write it, see what people say, tweak it if there are minor problems or quibbles, and if there are larger disputes or irreconcilable problems, someone else can just write a competing essay. --Aquillion (talk) 21:04, 16 February 2026 (UTC)

I see way more Jews online offended that we are "erasing Jewish history" by removing that people are Jewish, honestly. See, for example, [23] [24], or objecting to our sort of compromise phrasing of "raised in a Jewish family" as also antisemitic. We can never win.

You're already not supposed to add it if it is not in a reliable source. I don't know what else we're supposed to do, hide that people are Jewish even if reliable sources say they are? Is that not ridiculously antisemitic? And sure, people often break that rule. But that goes for every guideline we have. Perfect enforcement does not exist here. PARAKANYAA (talk) 00:55, 17 February 2026 (UTC)

Is that not ridiculously antisemitic? I hope you don't mean that the way it reads.

This isn't about hiding anything. If someone's ethnicity or religion is a significant feature of their life, it should be mentioned, as long as it's backed by sources, in conformance with the MoS. What we're discussing here is the frequent tendency to substitute ethnicity for nationality in the lede, of qualifying nationality with ethnicity, or guessing about it with no sources or no relevance to the facts of a subject's life. I'd estimate that 75-80% of such edits are malicious. Frequent targets are people who've conducted themselves in a manner that draws criticism or negative attention, whereupon they get tagged as plainly as possible. This rarely happens when someone's Presbyterian.

An essay would be helpful in explaining all this to well-intentioned editors who wish to celebrate someone's ethnicity, and are disappointed or upset that it's not appreciated. It also helps cut off debate with the malicious who are cloaking themselves with the same ostensible motive.

And please, read Kosner's piece linked above on the subject. Acroterion (talk) 01:06, 17 February 2026 (UTC)

I think systematic efforts to erase Jewish history in the sense where we would hide cited information would be very antisemitic. If that's not what is being suggested, then no.

Kosner's article is him personally objecting to the fact he is labeled as being born to a Jewish family, and speculating that this was added by antisemites. Judaism is not just a religion. Where was it mentioned that we're just talking about the lead? The discussion, or Kosner's article, say nothing of the sort. The case at issue in Kosner's had nothing to do with substituting "ethnicity for nationality in the lede, of qualifying nationality with ethnicity, or guessing about it with no sources or no relevance to the facts of a subject's life".

The issue wrt Kosner was a sentence in the body of the article cited to a scholarly article from the Oxford University Press's Studies in Contemporary Jewry, from a Jewish author, solely about Jews and journalism, which names Kosner as a prominent Jewish journalist, added to the article by a seemingly well-respected editor without nefarious intentions [25]. And the article did not even say "x is Jewish", but that he was born to a Jewish family. If that is problematic Jew tagging then how is, by comparison, discussing anyone's ethnicity or background ever acceptable regardless of sourcing? PARAKANYAA (talk) 01:25, 17 February 2026 (UTC)

Yes, erasing Jewish history would be worse than the problem we're discussing. I mention the lede because 90% of the time this is where it pops up, peoples' attention spans being what they are. Often it's in very short articles that are nothing but lede. Kosner offers a different perspective, the out-of-context or gratuitous insertion of ethnicity. Acroterion (talk) 01:34, 17 February 2026 (UTC)

Again, if this is out of context or gratuitous then what mention of ethnicity or religion isn't? PARAKANYAA (talk) 01:48, 17 February 2026 (UTC)

One that treats the subject like a complex human being, not a series of entries in a database. AndyTheGrump (talk) 02:07, 17 February 2026 (UTC)

And by that you mean what? If we're going to be making guidelines we need specificity about what behaviors are and aren't okay. What makes the portrayal of one as Jewish "complex"? In an ideal world every article would be perfect, but none are. PARAKANYAA (talk) 02:39, 17 February 2026 (UTC)

We are discussing an essay, here, not 'guidelines'. As for what makes the portrayal of someone as Jewish "complex", mostly the fact that it is. Because people are complicated, whether they are Jewish or not. Ultimately what we are discussing here is good writing vs bad writing, and the need for biographical content aimed at portraying human beings in all their complexity. Or at minimum, to avoid reductionist labelling. Possibly it is too much to expect this in Wikipedia, but that's no reason not to aspire to it. It requires editorial judgement, which isn't something you can create rules on. Fortunately, at least some of us (probably most, if they bother to put in the effort) have at least a little of this. That's one of the things that distinguishes us from the chatbots. AndyTheGrump (talk) 02:59, 17 February 2026 (UTC)

While I completely agree that ethnic identification is relatively complex, and no less so or not much less than Jews for the Scots-Irish or Basques or Cajuns or black Americans, especially in the age of 23andme, by the very same token, describing someone as Jewish is not reductionism. That descriptor contains multitudes. Andre🚐 03:06, 17 February 2026 (UTC)

Depends how you do it. Would you consider a paragraph in a biography consisting in its entirety of 'X is Jewish' as appropriate? AndyTheGrump (talk) 03:09, 17 February 2026 (UTC)

No, of course not. But every once in a while, I do read a biography that doesn't at all mention whether a person is Jewish, or mentions it very minimally, despite probably that it should. I've also occasionally seen people removing it. That Jewish identity might be a large or a small aspect of that person's overall identity or their biographical outline. I'm just saying it's possible that the pendulum may have swung compared to where it was last. Andre🚐 03:18, 17 February 2026 (UTC)

Yes, Wikipedia contributors, even good-faith ones, can disagree over content. Which is why we try to encourage discussing things. AndyTheGrump (talk) 03:39, 17 February 2026 (UTC)

@AndreJustAndre Very few articles say, for example, that "x is Presbyterian" when discussing a scientist or whomever and including many other detailsabout their life. Why mention Jewishness for those who happen to be Jewish?

We also don't normally mention left-handedness or eye color. David10244 (talk) 18:49, 25 February 2026 (UTC)

Well, first of all, it's not really true. Consider Joseph Lister, Ian Barbour, more at List of Christians in science and technology. Second of all, Jewishness is not strictly a religion, but an ethnicity and a culture as well. So it's more analogous to saying a scientist is Italian-American. Andre🚐 20:04, 25 February 2026 (UTC)

We too often say a scientist is Italian-American, “Chinese-American” etc. while others are just “American”. MarkBernstein (talk) 20:13, 25 February 2026 (UTC)

Well, it depends on the relevance of that identity to their notability. Enrico Fermi is an FA and he is an Italian-American scientist, and I think should be. We say John von Neumann is Hungarian and American in the first sentence. But " a wealthy, non-observant Jewish family." in the first paragraph of the background bio. Andre🚐 20:16, 25 February 2026 (UTC)

Sure, everything is complicated, and we should strive to portray that. This goes for literally every topic we can cover. So what? PARAKANYAA (talk) 14:36, 18 February 2026 (UTC)

I think I agree with PARAKANYAA. I left my thoughts in detail on the previous thread, so I won't repeat myself too much. But I think PARAKANYAA raises several strong points, that I may or may not have touched on last time this came up. While in the past there may have been issues with people trying to identify Jewishness in an article for poor reasons, there are a lot of people nowadays who are more concerned with the erasure of Jewish identity or history, so it's a bit of a delicate balancing act, which is why I don't think a special guideline is a good idea. I can't stop anyone from writing an essay in their userspace or wherever, but in my view this is probably unhelpful at best. As PARAKANYAA points out, Jewishness is not only a group of religious groups, but an ethnicity (and a cuisine, a literature, an art, a music, etc. several of each, actually) The Kosner diff as noted is not necessarily bad faith and is well-sourced, so it comes down to the subject's personal preference? A related problem is subjects that don't like their bad photos. But the point is well taken that we already have a guideline, and that guidelines are routinely disregarded. So it's hard to see how this would help, except to give admins a clearer excuse to block people, which I don't think is a good idea either in this case. Because it is hard to know if someone is "Jew tagging" out of pride or philosemitism, or bigotry. Good faith would suggest we assume the former, and politely correct people who don't follow MOS:ETHNICITY adequately rather than blocking them for a proscribed activity. Andre🚐 02:26, 17 February 2026 (UTC)

I can't see anyone proposing a specific guideline here. In fact I can't really think how one would even write such a thing. Essays advise. They don't mandate, and what we (or at least some of us) are advising is a little more care about reductionist labels, and a little more consideration for the complexities of real people. That, and being prepared to deal with those who resort to reductionist labelling to push their PoVs of one sort or another. AndyTheGrump (talk) 03:05, 17 February 2026 (UTC)

You are right. Nobody is proposing a guideline, so that is a straw man that I am conjuring. However, it is also the case that Doug suggested in the prior thread perhaps this would help admins block more easily, so that is what I am alluding to. It's also the case that advisory essays can sometimes obtain a high level of community consensus. I don't think this one would, and inherently, the writing of thoughts isn't a harmful or discourageable activity, but there are also other things to do that could be more helpful. For example, as I offered last time, there are plenty of redlinked people that it wouldn't be inappropriate to call Jewish prominently. Andre🚐 03:08, 17 February 2026 (UTC)

Well yes, there are no doubt many missing biographies, including those for people who's Jewishness is an entirely appropriate topic. I can't see how that is particularly relevant to the issue here though, which is what a fair number of us perceive as inappropriate tagging-style content in existing articles. AndyTheGrump (talk) 03:13, 17 February 2026 (UTC)

Everyone is free to spend or not their volunteer hours where they see fit and what interests them. I'm just pointing out that you could say as a community Wikipedia sometimes allocates more time to the litigation of teh drama than content creation. I noticed you mentioned tagging by Bus stop, a user that has been CBANned for over 4 years. Do you have any more recent diffs that show inappropriate Jew tagging? Or examples of articles where you think the old tagging has managed to stick around? Because my experience is that any such tagging is generally promptly dealt with, and there are also false positives in that area. Andre🚐 03:23, 17 February 2026 (UTC)

As you say, everyone is free to spend their volunteer hours where they see fit, and I see no particular reason to spend mine looking for diffs to support my position when you have provided none to support yours. We clearly see things differently as far as this issue is concerned, and it seems its not just me who still sees 'tagging' (not just in regard to Jewishness) as a problem. And please drop the 'litigation and dramah' hyperbole, since we have already established that we aren't advocating rules to litigate over. AndyTheGrump (talk) 03:37, 17 February 2026 (UTC)

Rather than diffs, how about a little searching exercise? Enter "is Jewish." (with the double quotes and period) into an article-space search. You have already agreed with me that a paragraph consisting solely of 'X is Jewish' is inappropriate. Here's the first three I found, in a couple of minutes. [26][27][28]. There are also many more with the same phrase just slapped, context-free, into a paragraph on other things. Given that I've got better things to do with my time than go through all 3912 results the search throws up to find them all, I'll leave that to you. AndyTheGrump (talk) 04:03, 17 February 2026 (UTC)

I agree those articles and "paragraphs" aren't good, but they're all very short and borderline non-notable. For Judith Seidman, looks like the user who added that line was indeffed as a sock later but it at least has a reliable source[29] which is a dead link but at least provides some context: [30] Joel Sherman it was added in November by a temp account without a source: [31] So potentially revertable. The third has a directory entry in the big book of Jewish sports legends. Frankly, all three could potentially be merged to a list or AFD'd. Anyway, I am sure that there are many articles where they do say that the person is Jewish, but it's not really a given that all of those the appropriate remedy is to remove the line, rather than to expand the context. Andre🚐 04:13, 17 February 2026 (UTC)

I fail to see why being 'borderline non-notable' has any bearing on the appropriateness or otherwise of tagging. And if anything, an article being short makes it more noticeable. As for removal or expansion, as I illustrated with my User:Bus stop example, I'm quite prepared to support either, depending on what the source material available has to say - and in that specific case was arguing for more content. I may not always do so, but please don't make out that I'm advocating erasure. AndyTheGrump (talk) 04:25, 17 February 2026 (UTC)

OK, well then I think we agree. These, and the other articles like them, are pretty bad articles, and those lines in those bad articles are also bad. They could potentially in some cases be fixed by expansion. If the eventual Jew-tagging essay says that, then I think it will be hard to criticize it from the angle I am currently taking. Andre🚐 04:29, 17 February 2026 (UTC)

I just ran across some in the last few days, although I'm not going to attempt to find where it was. IMHO the purpose of an essay should be to help clarify when it IS or ISN'T appropriate to mention someone's religion, ethnicity, sexuality, etc as well as discuss the best phrasing. It should be expansive to cover various possible scenarios but with subsections for topics where it comes up frequently, such as said Jew tagging. Questions for editors to ask themselves would be things like "Would there be any reason to mention this person's ethnicity if they WEREN'T Jewish", and "Can I explain why it's is relevant to their notability?" If the only thing you can say (supported by sources) is a one sentence statement confirming that is their ethnicity it probably isn't appropriate to include. ChompyTheGogoat (talk) 05:58, 5 March 2026 (UTC)

The second question, yes. The first question, in my view, not so much. For example, there are people for whom Jewish ethnicity is relevant to their notability, but if they weren't Jewish, it wouldn't be. Andre🚐 06:06, 5 March 2026 (UTC)

I'm not saying the answer to those questions has to always be the same, but that they're things to keep in mind. Sometimes the fact that they aren't Jewish might be specifically relevant, like someone who converted and whose faith is directly relevant to their notability. They're a religious Jew, but not ethnic, which means their faith has different cultural context, and that's probably something that ought to be discussed (and I hope would be covered by sources). Similarly for someone who's raised Jewish but converted to something else (again, if related to notability). If they only have Jewish DNA but the family has been non-observant for multiple generations then not so much.

It might be better to think of it as the first question helping to support the second one. "Their ethnicity isn't related to their notability, but I still think it should be included anyway" > "Would I still want to mention their non-notable ethnicity if it was something different?" The idea is to help people consider their bias and motivations to determine whether inclusion truly aligns with WP:NPOV. ChompyTheGogoat (talk) 06:24, 5 March 2026 (UTC)

The standard is whether reliable sources have something meaningful to say about that aspect of their biography. Andre🚐 18:52, 5 March 2026 (UTC)

You may not mean this but I don't think we should suggest that that journalist is a "self-hating Jew" (a term found in another journo's article, Ben Hecht) or "internalized antisemite". He just views it, and himself, as he sees it, which may be differently from any of us. Alanscottwalker (talk) 16:25, 17 February 2026 (UTC)

In the past, every baseball player whose ancestors were Jewish was described in Wikipedia as a "Jewish-American baseball player", while those whose ancestors were not Jewish were described as an "American baseball player". (Black American players were separately tagged.). This is, of course, offensive. The euphemism "from a Jewish family" can be deployed to tag Jews whose families have not identified as Jewish for generations. It is a particular irony that Wikipedia continues to employ the Nüremberg laws to define who is a Jew. MarkBernstein (talk) 04:45, 17 February 2026 (UTC)

Is that happening in 2025-2026 though? Andre🚐 04:59, 17 February 2026 (UTC)

If it isn't, it is presumably those objecting to the earlier gratuitous Jew-tagging (along with other ethno-tagging etc) who deserve thanks for cleaning things up. And it seems there are those of the opinion that there is still work to do: hence the proposal for an essay. AndyTheGrump (talk) 05:11, 17 February 2026 (UTC)

Maybe. I've been around for a while but there are some significant gaps in my contribution history. And I really wasn't tuned into this problem or editing in these areas in some of the older timeframes when it may have been happening. But a lot has changed on Wikipedia since then. I've been editing pretty regularly since returning in 2022. And I've definitely noticed that emphasis on reliable sourcing, BLP policy, due and undue weight, and other stuff like that is significantly greater than say, 2004-7ish. Plus the evolution of the contentious topics regimes that deal with a lot of political things. So that might have something to do with why so-called Jew or ethnicity tagging is less troublesome or dealt with more easily. I think there is also a shorter leash for tendentious and problematic editors. Which is for the good, in my view. That's why I challenged the idea that it is a current problem. I am aware of some concrete situations where a Jewish background was removed or omitted and I thought it should be there. But I'm not talking about celebrity actors or ball players, I'm talking about long-dead historical personages. At any rate, I wonder what MarkBernstein makes of the idea that the fix for it might be to expand, not remove, the mention of Jewish heritage. It is also possible that if a Jew-tagging essay is created, perhaps a counter-essay would be needed. I think Wikipedia, at least in its present-day incarnation, has a skew toward post-national, citizen of the world-type philosophy. That often means that mention of heritage or cultural context can not seem very relevant or important. I think in the last discussion, someone said they didn't believe it was ever relevant to a biography to say. Anyway, I just want people to consider both sides of this and check whether some perceptions of how prevalent this problem is or how it is handled might be outdated. Andre🚐 05:34, 17 February 2026 (UTC)

Undenting a little, we're talking about an essay, not the sixth pillar, and people are free to ignore it. I am of the opinion that there is a recurring problem with editors, often, but not always, malicious, focusing on reductive descriptions of race/ethnicity/religion in biographies, in circumstances where that emphasis is dubious. We ought to have a somewhat standardized essay or guideline to point them to, so at least the persuadable can read it and understand why it's frowned upon in both practice and the manual of style, and the underlying reasons why putting people into ethnic boxes can be pernicious. It will not fit all circumstances. Perhaps I've seen too many ethnonationalist warriors or just plain bigots. In any case, I will start an essay in the next few days. I'm fighting a mild cold and am not feeling excessively smart at the moment, so when I'm feeling less fuzzy I'll give it a try and link it. Acroterion (talk) 14:42, 17 February 2026 (UTC)

There are two problems with “ethnicity/natonal labeling”… a) adding the label because the subject is “one of us”, and b) adding the label because the subject is “one of them”. Both are taking the wrong approach. The flaw is that the label is being added because the ethnicity/national identity is in some way important to the editor who added it, not because the ethnicity/nationality is important to the subject. Blueboar (talk) 15:00, 17 February 2026 (UTC)

Yes, it boils down to editors who are primarily motivated to draw a line between "are they one of us" and "are they one of them." So in my mind it's a behavioral issue as much as anything else, and part of the theme I propose is examination of one's motives. Acroterion (talk) 15:08, 17 February 2026 (UTC)

Re the “one of us” aspect of this… It is very difficult to convince those who care deeply about their own identities (and consider it “defining”) that the identity may not be all that important (defining) for someone else. Blueboar (talk) 15:22, 17 February 2026 (UTC)

And there are also cases where the ethnic or national or religious identity is deeply important and private and personal to the subject, and a constant thread throughout their lives. This is I think a blind spot that Wikipedians may have in thinking that this is less likely to be the case. Andre🚐 15:43, 17 February 2026 (UTC)

Well, a very public biography is likely not treating it as personal and private. Alanscottwalker (talk) 15:52, 17 February 2026 (UTC)

That depends if the subject is still alive. And if they have had a biography written about published about their life. Andre🚐 15:53, 17 February 2026 (UTC)

If they have a biography on Wikipedia, the X-most visited site in the world, they have a very public biography written about them. Alanscottwalker (talk) 15:59, 17 February 2026 (UTC)

My point is that many Wikipedia biographies are not as complete as a 300 page book that a biographer researched and wrote about them over years. Andre🚐 16:04, 17 February 2026 (UTC)

Why should something being 'private and personal' to the subject of a biography be a reason to include it? Aren't we supposed to build biographies around what secondary sources have to say on the subject, rather than trying to read the subject's mind and decide for them what we think they might want included? AndyTheGrump (talk) 16:26, 17 February 2026 (UTC)

I'm not saying to try to read the subject's mind. I'm referring to a situation where a subject's private life might not be known during their heyday, and comes to light later due to a biography being published at the end of their life or after their death. For example, I recently watched the HBO documentary about Mel Brooks, Mel Brooks: The 99 Year Old Man!. Not that Mel Brooks' connection to Jewishness is a secret or under-publicized. The article does mention it, mostly under the section called "Religious beliefs." But if you watch the doc, which is a roundup of Brooks' career, it talks more about his relationship to his Jewish identity and what that meant early in his career and as time went on, why he had an obsession with satirizing Hitler, etc. But you certainly might not have known as much about it in the 70s or in the 90s. Andre🚐 16:35, 17 February 2026 (UTC)

Wikipedia bases articles on published works. It does not base them on hypothetical content that might possibly be published later. AndyTheGrump (talk) 16:49, 17 February 2026 (UTC)

Yes, of course. But there are many articles where the published works have been published already. WP:10YEARSTEST tells us to take a long view. Andre🚐 16:53, 17 February 2026 (UTC)

If currently published works state that a subject's ethnicity/race/religion is an important aspect of their lives, we should include that with sources and with context.

If currently published works do not state that then we should not include it, with or without context.

If currently published sources are unclear about whether it is important to them, discuss the matter on the talk page and get consensus prior to inclusion.

I don't understand what the difficulty with this is? Thryduulf (talk) 17:18, 17 February 2026 (UTC)

Yes, there's no disagreement or difficulty with that. Andre🚐 17:32, 17 February 2026 (UTC)

The key is to ask: do sources indicate that the identity is a defining characteristic for the subject? Do sources indicate that the identity is important to understanding the subject, or am I assuming that it is important - because it is important to me? If the latter, don’t include the identity. Blueboar (talk) 16:40, 17 February 2026 (UTC)

Indeed, but many cases are not clear-cut. In the case of the French techno artist Gesaffelstein, real name Mike Levy, we mention he was born to Jewish parents. According to Hey Alma[32], "Though Gesaffelstein is a fairly private figure and hasn’t shared how he identifies, there are a few clues that he finds meaning in his Jewish ancestry. The name of his first album is “Aleph,” ... Canadian DJ A-Trak, ... referred to himself and Gesaffelstein as “Sephardic boys” and “Techno altjews” on Instagram." This source is cited in the article, but nothing about this is mentioned. Probably because it is personal and private to the artist and somewhat speculative. But one can imagine that if a biography is written in 30 years, it might have access to private correspondence. Looking at the page history, in this very month, there is a big edit war back and forth about this very thing. Andre🚐 16:52, 17 February 2026 (UTC)

Feel free to imagine what you like. Meanwhile, since Wikipedia doesn't (or shouldn't) base content on the precognition of contributors, you'll have to do what the rest of us do, and argue on the relevant talk page that sources currently support your proposed text. AndyTheGrump (talk) 17:11, 17 February 2026 (UTC)

I think the number of issues brought up here indicates that this is something well worth having an essay or guideline about so we can all get on the same page, both literally and metaphorically. I think it would be good to set out when it is legitimate to refer to a person's Jewish religion or descent and when it becomes gratuitous. The guideline should give advice on how to distinguish deliberate bad faith Jew Tagging from everyday good faith mistakes. The guideline should also be clear that Jew Tagging can apply to people who are not actually Jewish but who are merely thought to be by deranged antisemites. I don't think that the guideline would need to be generalised beyond Judaism. As far as I am aware, there is no similar phenomenon affecting other religions but it would be just as egregious if there were and that might even merit a separate guideline if it were to become a comparable problem. --DanielRigal (talk) 17:57, 17 February 2026 (UTC)

Sartre's commentaries are relevant to some of the bad-faith issues noted in this discussion: Anti-Semite and Jew. Acroterion (talk) 19:12, 17 February 2026 (UTC)

That's basically at the top of the list of philosophy essays I'd like all Wikipedians who work on politics to read. Simonm223 (talk) 19:13, 17 February 2026 (UTC)

But as David Nirenberg points out on p.475 of Anti-Judaism, even Sartre, in passionately defending a Jewish return to France, still engages in idealism and universalism in defining Jews in terms of antisemitic gaze rather than Jewish historical and cultural continuity. Sartre's worldview is that in a perfect world, the Jewish identity would disappear and be subsumed into a universal French identity. That's not realistic and not necessarily desirable either.[33] Andre🚐 19:24, 17 February 2026 (UTC)

Sartre felt that way about religion in general. However, that's a meta-discussion, we're only concerned with his views on anti-Semitism. Acroterion (talk) 19:33, 17 February 2026 (UTC)

My point is that Wikipedians might as a general rule, sympathize more with the postmodern, post-religious or post-ethnic viewpoint, that particularities or differences are less relevant than commonalities, a materialistic worldview that is just one view of things and may not be applicable to all biographies or other articles or situations. For a modern day American celebrity with limited information about any Jewish or other ethnic identity, yes. But let's make sure that we don't apply that also to cases where it shouldn't apply. Medieval individuals often lived a daily reality of different, such as residing in a ghetto or being forced to wear certain clothing or have certain special taxes and other restrictions. Andre🚐 19:50, 17 February 2026 (UTC)

At any rate, forms of "jew-tagging" was an issue in medieval European history, the hat, the yellow badge. We are post WW II, and the vivid example there, of making a racial list. Alanscottwalker (talk) 20:53, 17 February 2026 (UTC)

I definitely do not agree that writing about whether someone is Jewish in their biography is equivalent to making them wear a yellow star. That is exactly the type of thing I hope is NOT written in an essay. Respecting and tolerating other cultures doesn't mean erasing or hiding them. We can embrace our differences. Andre🚐 23:32, 17 February 2026 (UTC)

Again, it depends how you write about it. I've seen (and reverted) numerous examples over the years of biographies of individuals where some negative event or another (criminal charges etc) is followed by a rapid tagging of the three-word reductionist variety. Not quite a yellow star, but the motivation seems much the same: marking as 'one of them'. AKA antisemitism. AndyTheGrump (talk) 00:08, 18 February 2026 (UTC)

Believe me, it's not lost on me that making lists of Jews sounds worrisome, but Wikipedia has lists of every type of person, place, and thing, not just Jews. I don't doubt that there are antisemites who tag and list Jews just like the "triple parentheses" on social media. But as I'm sure you are aware, that has been reclaimed by some people. There are also many biographies about notable non-criminal, famous and successful Jewish people that fail to mention or even minimize their Jewishness, even though the subject probably wouldn't mind and might even prefer that, but more importantly the biography (the real ones, not the Wikipedia article) does include that fact prominently. As Thryduulf says, this should be simple, right? If it's an important, well-attested, reasonably comprehensive descriptor or identification that is relevant, it should be included. In fact, I'd be hard-pressed to think of an article about a Jewish person who isn't known primarily for something related to being Jewish like rabbinics or academia, that gives more than a few sentences to their Jewish identity. Mel Brooks' Jewish identity could probably be an entire article. Andre🚐 04:24, 18 February 2026 (UTC)

If you want to respect differences, you would surely acknowledge that the Commentary essay linked above does not take such a sanguine view. Not everyone is going to see everything the way you do in every editing situation, especially something personal or private to them. Alanscottwalker (talk) 01:33, 18 February 2026 (UTC)

A couple of recent examples I've run across: Margo Kaplan and Ron Castan, both people who have done something or have views that cause people to insist on pinning "Jewish" on them for, oh, no reason, it's just a fact that's very important to those editors. Magnus Hirschfeld is a perennial target. I'm working on an essay offline until I get something succinct together that doesn't look like a set of disconnected thoughts. Acroterion (talk) 13:22, 25 February 2026 (UTC)

Is it just me or is it becoming more common? I feel like I've run into a bunch of such incidents just in the past few weeks (since I got back from a wiki hiatus), and in about two cases the users in question immediately lapsed into vicious antisemitism on their talk pages when challenged. AntiDionysius (talk) 14:12, 25 February 2026 (UTC)

It ebbs and flows. I think it's at a higher level since the new year. I've seen relatively little of the Judeophilic type, more of stubborn insistence and the occasional virulent anti-Semite. Since edit filters started to catch triple parentheses this is the best they can do. Acroterion (talk) 14:24, 25 February 2026 (UTC)

I've gone ahead and written a userspace essay: User:Acroterion/Jew-tagging. It solely reflects my own opinions and experience, and should not be confused with a guideline or a policy statement, or a Wikipedia-space essay. Acroterion (talk) 00:39, 27 February 2026 (UTC)

Thank you for being thoughtful and balanced. Andre🚐 01:05, 27 February 2026 (UTC)

You're welcome. I was influenced by the discussion above, including your thoughts. Acroterion (talk) 01:25, 27 February 2026 (UTC)

That is evident, and I am grateful for that, not the least because it justifies the time I spend engaging on these issues. I feel much better about it knowing that my thoughts were taken into account, which I can tell, and that the essay urges civility, thoughtfulness, tact, understanding, and conscious engagement knowing that there can be reasonable editors reasonably disagreeing. If I had to add anything, I would add that there is nothing wrong with someone spending their volunteer editing hours editing on their own culture or heritage if that is the topic that they know about and are interested in, which necessitates some amount of distance and conscious effort at neutrality as well. Andre🚐 02:41, 27 February 2026 (UTC)

That was what I had in mind, well done, and thanks again. Andre🚐 04:15, 1 March 2026 (UTC)

Well said. I think the question of erasure might possibly be clarified. MarkBernstein (talk) 02:21, 27 February 2026 (UTC)

Suggestions are welcome. Acroterion (talk) 02:41, 27 February 2026 (UTC)

Bookmarked for future reference. If this had existed last week, I would have pointed a certain editor to it. Which reminds me, categorization may also be a means of Jew-tagging, i.e., categorizing someone as "Jewish whatever" when the article only mentions Jewish ancestry without any discussion of the subject's religion or cultural identity. Donald Albury 17:09, 27 February 2026 (UTC)

• I thought about that, but it seemed a little down in the insider weeds for the time being. I will give thought to adding a very brief note, I don't want it to turn into a thesis. Acroterion (talk) 18:36, 27 February 2026 (UTC)

• User:Acroterion would you want to make shortcut WP:JEWTAG because I'll never remember where otherwise and not so organized with bookmarks. -- GreenC 17:48, 27 February 2026 (UTC)

  Must we? Andre🚐 18:00, 27 February 2026 (UTC)

I would prefer to have a more general consensus before we make a shortcut from WP space. Acroterion (talk) 18:36, 27 February 2026 (UTC)

General Background Color

Faint Brown

Sepia

Cosmic Latte

I put this here. mdm.bla 22:31, 20 February 2026 (UTC)

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

Wikipedia has always conveyed with its bare appearance that it was set up in someone's spare time, even though the content elements have become very sophisticated. A slightly fancier presentation appears long overdue. It will also help people read longer.

Please add a readily available option to make the background of your pages a faint beige. It adds a touch of class and generally makes text easier to read, given that it provides a tiny bit less contrast, as black on white glows fairly quickly. And you already have the option for dark mode (which takes contrast to its own level).

Three variations of this color have come out of discussion. They are best assessed at scale, behind actual content. One is more brown, and two are more peachy. The peachy ones come from popular situations, but I think that the brown one is easier to read from.

The faint brown tint is: #EEEDDC.

The peachy tints are: #F8F1E3 is Sepia, from the Wikipedia app (on a smaller screen). #FFF8E7 is known as Cosmic Latte, which has a Wikipedia article.

Other ideas were mentioned, built on this one; for example, applying this to every Wikimedia project. It's likely that this one simpler idea stands best on its own, for straight-forward implementation, and any others can be considered separately.

Thanks for your time and consideration. ~2026-90420-1 (talk) 09:28, 18 February 2026 (UTC)

Imho it needs to be either #ffffdd or #ffffec because these were canonically used for faint beige on desktop (see Wikipedia:Software updates#July 29th, 2003). sapphaline (talk) 15:18, 18 February 2026 (UTC)

The main ongoing objective, besides looking classy, is to help people read Wikipedia articles longer. The shades of brown seem to enable this best. #FFFFDD is comparatively yellow, which doesn't seem to especially satisfy either objective. And #FFFFEC is somewhat faint yellowish green, which accomplishes both a little better, but not as well the more brown. In the idea lab, it was mentioned that #FFFFEC appears too subtly different from white. ~2026-90420-1 (talk) 16:24, 18 February 2026 (UTC)

Hi! What do you mean by "came out of discussion" and "were mentioned"? If there was a previous on-wiki discussion on the topic, or if you are organizing off-wiki about this, it is ideal to be transparent about it. Regarding the beige color, it is already implemented as an option on the mobile app, so that tint could probably be a good start to extend the implementation! Chaotic Enby (talk · contribs) 19:06, 18 February 2026 (UTC)

The TA appears to be referring to Wikipedia:Village pump (idea lab)#General Background Color, which they posted last week. Belbury (talk) 19:12, 18 February 2026 (UTC)

Oh neat, thanks a lot for the link! Chaotic Enby (talk · contribs) 19:47, 18 February 2026 (UTC)

As mentioned in the proposal: Three variations of this color have come out of discussion. They are best assessed at scale, behind actual content. One is more brown, and two are more peachy. The peachy ones come from popular situations, but I think that the brown one is easier to read from. #F8F1E3 is Sepia, from the Wikipedia app (on a smaller screen). It's one of the peachy tints. ~2026-90420-1 (talk) 05:23, 19 February 2026 (UTC)

Here's a simple tool for comparing the colours :

HTML Hex Color Visualiser Cdr. Erwin Smith (talk) 07:15, 19 February 2026 (UTC)

Thank you for the link to the color tool. Please note that, for some reason, it appears to show the colors in a specific order -- in this case, #F8F1E3 Sepia, #FFF8E7 Cosmic Latte, and then #EEEDDC. And it might still be most helpful to test the colors as backgrounds to text, to see which seems most readable for long periods. --- As mentioned in the Idea Lab, I do that in Word, using its Design > Page Color > More Colors > RGB setting. ~2026-90420-1 (talk) 15:33, 19 February 2026 (UTC)

I haven't tested reading them long term, but to the right of this discussion I've put a screenshot with each color for reference. Personally, I use my own background colors (normally I look at project pages in #F0FFF0 "Honeydew"), but I am most partial to Sepia of these three options. mdm.bla 22:27, 20 February 2026 (UTC)

No replies for two days.

That's why I recommended opening an RfC, for an active discussion and a prompt resolution. Can't TAs open one ? Cdr. Erwin Smith (talk) 10:51, 23 February 2026 (UTC)

Hi! I would like to add my opinion: I much prefer the normal background color, but I'm sure we could just make a skin for this. In fact, I'll try and make one. Thanks! SeaDragon1 (talk, contributions) 17:27, 23 February 2026 (UTC)

Hello. This is proposed as a readily available option, like Dark Mode. How many people know what a "skin" is or how to use it? ~2026-90420-1 (talk) 06:54, 24 February 2026 (UTC)

 Done see User:SeaDragon1/sepia.css. SeaDragon1 (talk, contributions) 13:41, 24 February 2026 (UTC)

In the early 2000s, Wikipedia used an alternate background color for special pages. We should revive this idea for non-mainspace pages. 3df (talk) 01:09, 27 February 2026 (UTC)

Hello. As stated at the end of the proposal: "Other ideas were mentioned, built on this one; for example, applying this to every Wikimedia project. It's likely that this one simpler idea stands best on its own, for straight-forward implementation, and any others can be considered separately." ~2026-90420-1 (talk) 09:10, 27 February 2026 (UTC)

As I stated in the Idea Lab, where this proposal was refined, I have not done this previously, so I don't know the details of the procedure. And I haven't seen anything that explains them. What happens next? Cdr. Erwin Smith recommended an RfC (Request for Comments) a week ago, likely to choose the best color for the objectives of the proposal. How does that occur? Thank you. ~2026-90420-1 (talk) 10:24, 2 March 2026 (UTC)

Renaming of Articles for creation

Should we rename "Articles for creation" to "Pages for creation"? WP:AFC/C does not only apply to articles but to othe rpages in namespaces as well. ~2026-36939-5 (talk) 11:30, 18 February 2026 (UTC)

AfCs are for articles, but the fact that WP:CFC is a subpage of WP:AfC is interesting. SeaDragon1 (talk, contributions) 19:17, 20 February 2026 (UTC)

It might be more relevant to rename it "Articles for approval".

AFC exists because back in the day, we took away the ability of IPs to create pages, except for talk pages. So they'd post "I want to write about Alice Expert", or create a talk page, and someone had to help them create the article. It's really quite a different thing now. WhatamIdoing (talk) 08:51, 26 February 2026 (UTC)

Huh. SeaDragon1 (talk, contributions) 14:29, 26 February 2026 (UTC)

Uh... they're still not allowed to create Articles directly. Primefac (talk) 22:14, 28 February 2026 (UTC)

Where does it say that? ChompyTheGogoat (talk) 05:22, 5 March 2026 (UTC)

WP:UNREGISTERED and WP:ACPERM. Primefac (talk) 12:15, 5 March 2026 (UTC)

Yes, but they were, many years ago, and when we took that away, Legal said we had to create an alternative route that allowed as many people to edit as possible, including creating pages. AFC was the alternative route. Pre-creation of the Draft: space (which is m:where articles go to die), IPs would post their content to a page such as Wikipedia:Articles for creation/2006-06-30, and a registered editor would copy/paste it to the mainspace for them. Sometimes people created articles in the Wikipedia_talk: namespace. Eventually, we created the original ArticleWizard and moved to a category-based system (around 2008?). WhatamIdoing (talk) 22:10, 5 March 2026 (UTC)

IPs could create articles directly until 2017. Primefac (talk) 09:59, 6 March 2026 (UTC)

Oppose. The disruption caused by renaming would be much greater than the benefit of having a more accurate/precise WikiProject title. –Novem Linguae (talk) 08:10, 1 March 2026 (UTC)

Oppose - meretricious. ChrysGalley (talk) 09:05, 2 March 2026 (UTC)

Not really worth changing. Anyone who is making anything other than an article probably doesn't need AfC anyway. Mrfoogles (talk) 03:22, 4 March 2026 (UTC)

Request for community consensus – CentralNotice for Wiki Loves Ramadan 2026

Hello everyone,

I am the Project Lead of the international team for Wiki Loves Ramadan, and the local organizer of Wikipedia:Wiki Loves Ramadan 2026 on English Wikipedia.

I am writing to request community consensus to run a CentralNotice banner globally for Wiki Loves Ramadan 2026.

This year, the campaign includes:

• An international photo competition on Wikimedia Commons (with participating countries running local editions), and
• A global writing competition on English Wikipedia.

For English Wikipedia, the banner should clearly reflect the writing competition and link directly to Wikipedia:Wiki Loves Ramadan 2026, in addition to linking to the relevant Commons competition pages for participating countries where applicable.

For reference, the detailed CentralNotice plan (including banner structure and implementation notes) is available at: m:Wiki Loves Ramadan 2026/CentralNotice.

Before proceeding further with the CentralNotice process, I am seeking consensus from the English Wikipedia community. Feedback on banner wording, linking structure, targeting, and overall scope is very welcome. Warm Regards, ZI Jony ^(Talk) 06:38, 26 February 2026 (UTC)

A central notice banner will go a long way to promote the project, Wiki Love Ramadan on English Wikipedia. Tesleemah (talk) 10:41, 28 February 2026 (UTC)

@ZI Jony Please make the central notices compatible with dark mode if you plan to run it on the English Wikipedia. The current designs appear to be very much incompatible with dark mode. Sohom (talk) 16:52, 2 March 2026 (UTC)

@Sohom Datta, our technical team already updated that code, hopefully CN admins will update at thier earliest convenience. Warm Regards, ZI Jony ^(Talk) 18:00, 2 March 2026 (UTC)

I was going to suggest a different name until I saw meta:Wiki Loves X campaigns, which endorses the current name. My only suggestions are:

1. Comply with Wiki Loves X campaigns.
2. Cover any variations among different branches of Islam and among different regions.
3. Use the Arabic terms with English translations and transliterations.

I don't see any issues. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 18:14, 2 March 2026 (UTC)

@Chatul, thanks for thinking about a different title, and it does make sense to check how the campaign is positioned first.

Just to ground this in how the project is framed: Wiki Loves Ramadan exists as part of the Wiki Loves X family of campaigns and explicitly carries that name on Meta-Wiki, so sticking with it aligns with Wikimedia branding.

The campaign’s mission is to empower communities to contribute high-quality, freely accessible knowledge about Ramadan and the wider Islamic world, highlighting diverse traditions and practices for broader understanding and heritage preservation. Its vision is to build a comprehensive, multilingual repository of knowledge that celebrates both the diversity and shared aspects of Muslim heritage globally.

In terms of areas of focus, contributions are encouraged across:

• core Islamic topics - beliefs, practices, branches of Islam and regional traditions,
• the many facets of Ramadan - fasting traditions, prayers, Eid celebrations, and how it’s observed in different cultures,
• religious structures, landmarks, figures, and broader cultural expressions like art and cuisine.

Given that, your points about complying with Wiki Loves X campaigns, ensuring coverage of different branches of Islam and regional variations, and using Arabic terms with English translation/transliteration all sit well with the campaign’s goals. I don’t see any blockers either. Warm Regards, ZI Jony ^(Talk) 06:10, 3 March 2026 (UTC)

Not a Muslim, Love the project. Topic: Ramadan in the Far North/Arctic Circle. All I know is that Canadian towns have different customs. ~2026-14035-61 (talk) 14:04, 4 March 2026 (UTC)

I do not give my consensus. Wikipedia should not be a religious Bleeding Kansas over banners about religious holidays. This site is supposed to be an encyclopedia, not a chapel. ~2026-11404-95 (talk) 13:54, 4 March 2026 (UTC)

To clarify what i mean by "Bleeding Kansas", i am referring to when the Kansas territory turned into a battlefield over slavery. In this instance, the banners would end up turning Wikipedia, which is supposed to be an encyclopedia, into a battlefield for religious missionaries. ~2026-11404-95 (talk) 13:57, 4 March 2026 (UTC)

• (ec) The only people who are turning this into a battlefield seem to be those predisposed to distrust Islam (i.e., Islamophobes). It has been explained multiple times at the talk page of the project that a) Wiki Loves X is the standard format for projects of this type, and b) anyone is welcome to work to create a Wiki Loves Christmas, Wiki Loves Diwali, Wiki Loves Passover, or even Wiki Loves Festivus. That one project has been launched does not mean other projects are precluded. — Chris Woodrich (talk) 16:09, 4 March 2026 (UTC)

I am not a Moslem. I've had issues with abusive and aggressive missionaries, but none of them have been Islamic. I see nothing in this proposal that is objectionable or in conflict with the umbrella Wiki Loves X campaigns. In the US at least, Moslems are more likely to be the victims than the perpetrators. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 16:54, 4 March 2026 (UTC)

While I'm okay with Wiki Loves X campaigns in general, may I suggest that ones focused on a particular religion not run as central notice banners, due to the possibility of it being seen as proselytism? Not saying that they shouldn't exist at all of course, just that it might be more sensitive to not have these particular ones as banners. Chaotic Enby (talk · contribs) 16:05, 4 March 2026 (UTC)

I'm inclined to agree. I am not religious and have no issue with Islam as a whole, but I feel that promoting any particular religion or religious holiday globally is non-neutral and should be avoided for the same reason we don't allow religious promotion in public schools. Articles, discussions, and the project itself are of course perfectly fine since they support information and education without Wikipedia itself appearing to endorse anything in particular. Particularly considering that holidays among various religions overlap, and this would appear to prioritize one above others. ChompyTheGogoat (talk) 05:20, 5 March 2026 (UTC)

There appears to be no intention in this campaign of proselytizing or endorsing any religion or religious holiday over the others. For what it's worth, I also personally fail to see how this campaign is fundamentally different from (say) Wiki Loves Onam which promotes a Hindu festival in Kerala that has been running for the last 3 years without any accusations of proselytization or endorsement of hinduism and appears to already have the silent consensus of the community. If we were to treat this campaign differently due to concerns over the optics of bias and block it, that would actually risk introducing actual bias into the process. Sohom (talk) 05:52, 5 March 2026 (UTC)

I don't mean to imply that it's intended, only that it might be interpreted that way.

Does Onam run a CentralNotice? That's the only thing I object to, not the existence of the campaign. If they do I haven't seen it, and my opinion applies to all religions equally - none should be singled out either by promotion OR suppression. If you were to compile a list of every holiday in every extant religion I'm fairly confident you'd have conflicts on every single day of the year. ChompyTheGogoat (talk) 06:57, 5 March 2026 (UTC)

As a side-note, a hatnote in meta:Wiki Loves Ramadan 2026 linking to meta:Wiki Loves X campaigns would be helpful. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 16:54, 4 March 2026 (UTC)

• Oppose any central notice banner that could reasonably be interpreted by readers as Wikipedia showing favoritism to any religion (or irreligion), as per Chaotic Enby and ChompyTheGogoat. BD2412 T 14:24, 5 March 2026 (UTC)

• Oppose banner per @Chaotic Enby and @BD2412. I agree that this could be interpreted as endorsing one religion over all others. It also puts Wikipedia at risk of actually prioritizing one religion over all others - if there were WikiLoves projects for Hanukkah or Lent that made the same banner request but community consensus was against it, that could set a very bad precedent. PositivelyUncertain (talk) 01:52, 6 March 2026 (UTC)

• Oppose per BD2412 Andre🚐 02:10, 6 March 2026 (UTC)

• Oppose I'm in agreement with PositivelyUncertain.--Wehwalt (talk) 02:20, 6 March 2026 (UTC)

• Meh, whatever decision we make here, we should be consistent and apply that result to other future religion-related Wiki loves X campaigns, because it would be weird if the community denied a banner for Wiki Loves Ramadan 2026, but in the future, approved one for hypothetical Wiki Loves Christmas, Wiki Loves Diwali, Wiki Loves Passover, or even Wiki Loves Festivus (to use Chris Woodrich's examples above). Some1 (talk) 02:38, 6 March 2026 (UTC)

  I'm fine with that. Remind us when such a banner is requested, we'll help vote it down. Wehwalt (talk) 02:42, 6 March 2026 (UTC)

  If I see it, I'll also say so. There is also no limiting principle to such a thing. If we allow this, how would we be able to deny a banner for the Church of Cannabis, or the Church of the Flying Spaghetti Monster? BD2412 T 02:46, 6 March 2026 (UTC)

  I would be happier if we could get a general binding consensus, instead of doing it as a case-by-case basis (which may introduce systemic bias regarding who does/doesn't vote in specific cases). Chaotic Enby (talk · contribs) 09:03, 6 March 2026 (UTC)

  Agreed again. My position applies to any banners associated with any religion, and I think an official proposal to clarify that it applies universally is a good idea to prevent exactly what I'm concerned about. Perhaps there should also be a broader standard relating to banners for any contentious topics, or ones that might be. The individual campaigns are volunteer run so as long as they comply with guidelines I'm not concerned about their subject matter, but the appearance of an official endorsement needs to be considered for banners.

  
  

  I'm not familiar with the technical side of things, but perhaps these campaigns that might be disallowed from central banners under such proposals could be allowed to add something just to specific articles they agree are directly relevant? That allows the possibility of multiple running at once. It would need to be limited to ones that are clear such as "Holiday within X religion", not "Holy site significant to multiple religions".

  
  

  I don't have much experience with pump - should additional aspects like this be broken down in new sections, or are spurs expected to split off within the initial proposal? It seems to be a somewhat looser format than many areas. ChompyTheGogoat (talk) 09:48, 6 March 2026 (UTC)

  It's a looser format indeed, but (at least at Wikipedia:Village pump (policy) and here) it can absolutely be helpful to break down the discussion into separate clear proposals for people to discuss, while Wikipedia:Village pump (idea lab) is more of a completely open discussion. Chaotic Enby (talk · contribs) 09:52, 6 March 2026 (UTC)

  Wikipedia loved the Jewish Museum in the past, but I don't remember seeing a banner for it. Andre🚐 02:44, 6 March 2026 (UTC)

• Conditional agree This is, of course, a marvellous idea. However, there is the obvious rider, that this initiative must be balanced by extending the same courtesy to the many other areas that deserve the same consideration. Otherwise Wikipedia would be guilty of crass discrimination. The "Wiki loves Ramadan" initiative needs to be followed by other initiatives such as "Wiki loves Lent", "Wiki loves the Heart Sutra", "Wiki loves Passover", "Wiki loves the elephant goddess Vināyakī"... in fact we are just getting started, there are so many seriously overlooked areas: "Wiki loves black men", "Wiki loves elderly white men", "Wiki loves young brown men", "Wiki loves white boys", "Wiki loves young British working class girls", "Wiki loves cis white men"... Our time will be entirely taken up with all the things Wiki needs to love, and with posturing about how virtuous we are for being so virtuous. I guess there won't be time left for writing an encyclopaedia, but if Wikipedia keeps indulging this sort of stuff, there won't be an encyclopaedia. If Wikipedia is to survive the challenges of AI, it needs to focus on what it would take for Wikipedia to become a gold standard for epistemological reliability or truth so it can be a trusted resource as a core training ground for AI. That's a big ask, but if we can't take up that challenge, then there is no future for Wikipedia, and we may as well let it implode into sectarian ideological dementia. — Epipelagic (talk) 09:51, 6 March 2026 (UTC)

  I think the underlying goal for campaigns of increasing and improving the quality of articles on underrepresented topics is admirable - but splashing a banner across the whole site to point it out is probably less so. ChompyTheGogoat (talk) 10:13, 6 March 2026 (UTC)

I see the potential for future misuse here, by projects whose main goal is simply to display their banner on Wikipedia for several weeks. To prevent that, there should be a clear time limit (around five days), and any future requests should need to demonstrate clear community interest in the project in previous years.Ponor (talk) 10:59, 6 March 2026 (UTC)

Zoom-in for fossil ranges

Palaeotherium Temporal range: Middle Eocene – Early Oligocene Da. S T Ypr. Lut. B Pr. Rup. Ch.
Scientific classification
Kingdom:	Animalia
Phylum:	Chordata
Class:	Mammalia
Order:	Perissodactyla
Family:	†Palaeotheriidae
Genus:	†Palaeotherium Cuvier, 1804
Type species
†Palaeotherium magnum Cuvier, 1804
Other species
†P. medium Cuvier, 1804 †P. crassum Cuvier, 1805 †P. curtum Cuvier, 1812 †P. duvali Pomel, 1853 †P. castrense Noulet, 1863 †P. siderolithicum Pictet & Humbert, 1869 †P. eocaenum Gervais, 1875 †P. lautricense Stehlin, 1904 †P. muehlbergi Stehlin, 1904 †P. renevieri Stehlin, 1904 †P. ruetimeyeri Stehlin, 1904 †P. pomeli Franzen, 1968 †P. crusafonti Casanovas-Cladellas, 1975 †P. llamaquiquense Casanovas-Cladellas & Santafé Llopis, 1991 †P. giganteum Cuesta, 1993 For subspecies suggested, see below.
Synonyms
Genus synonymy Paleotherium Cuvier, 1804 Paloeotherium Cuvier, 1804 Palaetherium Rafinesque, 1814 Paloetherium Rafinesque, 1814 Salaeotherium Roulin, 1829 Palacotherium von Meyer, 1838 Synonyms of P. magnum Palaeotherium girondicum Blainville, 1846 Palaeotherium aniciense Gervais, 1848–1852 Palaeotherium subgracile Aymard, 1853 Palaeotherium magnum parisiense Gervais, 1859 Palaeotherium stehlini Depéret, 1917 Palaeotherium franzeni Casanovas-Cladellas & Santafé Llopis, 1980 Synonyms of P. medium Palaeotherium brivatense Bravard, 1843 Palaeotherium suevicum Fraas, 1869 Palaeotherium möschi Stehlin, 1904 Palaeotherium euzetense Depéret, 1917 Synonyms of P. crassum Palaeotherium indeterminatum Cuvier, 1822 Synonyms of P. curtum Palaeotherium latum Cuvier, 1822 Palaeotherium buseri Stehlin, 1904 Synonyms of P. duvali Palaeotherium heimi Stehlin, 1904 Palaeotherium kleini Dietrich, 1922 Synonyms of P. castrense Paloplotherium magnum Ruetimeyer, 1891 Synonyms of P. siderolithicum Plagiolophus siderolithicus Pictet & Humbert, 1869 Synonyms of P. eocaenum Paloplotherium depereti Stehlin, 1902 Synonyms of P. muehlbergi Palaeotherium velaunum Blainville, 1848 Dubious species Palaeotherium gracile von Meyer, 1839 Palaeotherium parvulum de Serres, 1844 Palaeotherium commune Blainville, 1846 Palaeotherium primaevum Aymard, 1853 Palaeotherium gervaisii Aymard, 1853

Hi folks! A proposal for providing zoomed-in fossil ranges focusing on a single period, with {{Period fossil range}}, was discussed on Wikipedia talk:WikiProject Palaeontology, which received broad support for being used in specific cases. It would show up in addition to the main range generated by {{Geological range}} (for example in taxoboxes or formation infoboxes). Some editors suggested querying broader input outside of the WikiProject, so I am asking here if anyone has feedback about it!

Here is an example to the right, suggested by User:IJReid! Beyond this one, all 12 possible bars can be found at {{Period fossil range/rangebar}}. Courtesy ping to people in the earlier thread: @The Morrison Man @Hemiauchenia @African Mud Turtle @LittleLazyLass @IJReid @Jens Lallensack Chaotic Enby (talk · contribs) 20:27, 3 March 2026 (UTC)

It feels like a useful inclusion for us at our WikiProject, but there is always the worry that by including additional "technical" details we could oversaturate the infobox with details that are in some way against the interest of informing those who aren't as knowledgable about the geologic time scale. Input on its appearance and intuitive use would be appreciated; does it make sense in the example infobox on the right here how the timescale bars are related among other things. IJReid ^{{{T - C - D - R}}} 03:40, 4 March 2026 (UTC)

I appreciate your reasonable concern about oversaturation, but the infobox on the right seems way shorter than the chemboxes that we currently have at pages like Calcium. LightNightLights (talk • contribs) 17:26, 4 March 2026 (UTC)

For the sake of completion I have modified it to include the entire contents, originally it was abbreviated to focus just on the upper region. IJReid ^{{{T - C - D - R}}} 17:38, 4 March 2026 (UTC)

(partial-contents permalink) I see; thank you for that! That does change things a bit: still shorter with lists collapsed than Calcium, but still long. We probably should have a mandatory maximum infobox size but thinking about it, that's a discussion for Wikipedia at large, not Wikipedia's taxonomy infoboxes in specific. LightNightLights (talk • contribs) 19:30, 4 March 2026 (UTC)

For what it's worth, Palaeotherium is a bit extreme in having such a long list of species and synonyms. Many fossil genera have only one species and few if any synonyms, and thus have very short taxoboxes. Giving a "see text" notice as with Dimetrodon is also an option when it simply becomes too much, or collapsing the list as at Titanosauria. LittleLazyLass (Talk | Contributions) 19:39, 4 March 2026 (UTC)

Horodyskia Temporal range: Middle Calymmian – Late Ediacaran Paleoprot. Mesoprot. Neoprot. Calymmian Ectasian Stenian
The holotype fossil of Horodyskia
Scientific classification
Domain:	Eukaryota
Kingdom:	incertae sedis
Genus:	†Horodyskia

Primates Temporal range: Early Paleocene to Present
Scientific classification
Kingdom:	Animalia
Phylum:	Chordata
Class:	Mammalia
Clade:	Pan-Primates
Order:	Primates

I've been playing around with this template in my sandbox and I really like the idea. Is there a plan to add graphical support for the Precambrian? I see that the template documentation says that Periods before the Cambrian are not formally subdivided into epochs or ages, and this template will not work on them, however, I feel like it could be possible to add this support, maybe on a different scale? As an example, I added an infobox excerpted from Horodyskia with the template added twice. The first bar is using the parameter Proterozoic (an eon) and the second bar is using the template Mesoproterozoic (an era). The bar appears to display correctly in both cases (the runoff is expected as the Mesoproterozoic ends midway through Horodyskia's range), just without the graphics. mdm.bla 18:00, 4 March 2026 (UTC)

Yep, now that I think about it, that could also be a great addition! I'll try to see if I can set this up for the Proterozoic as a demo. Chaotic Enby (talk · contribs) 18:25, 4 March 2026 (UTC)

Additionally, not sure of the reason behind this, but the {{All time 250px}} template is wider than the Phanerozoic one (which is 220px). Should they be uniformized, or should I make a separate 250px wide template for Precambrian subdivisions? Chaotic Enby (talk · contribs) 18:32, 4 March 2026 (UTC)

They can probably just be uniformized. Template:All time 250px also appears to display as a larger font than Template:Phanerozoic 220px. mdm.bla 18:40, 4 March 2026 (UTC)

Added a slight fix so the bars wouldn't have runoff, and are instead displayed as open on that side if there would have been some. Chaotic Enby (talk · contribs) 19:36, 4 March 2026 (UTC)

• In the first example, the meaning is not intuitively accessible from the display. I spent awhile thinking the longer green bar was intended for the upper line of geological periods, as its green bar is very small. Would it work if the second bar is below the zoom in? CMD (talk) 08:17, 5 March 2026 (UTC)

  That could work! Although I'm not sure of the effect of having the more detailed/technical bar first. Alternatively, we could have the green bar on the bottom side of the second bar, or even just space them up by a few more pixels? Chaotic Enby (talk · contribs) 09:24, 5 March 2026 (UTC)

  I believe having it on the bottom of the second bar is what they were suggesting. LittleLazyLass (Talk | Contributions) 14:20, 5 March 2026 (UTC)

  How would that work when there are more than two bars?

  Either some sort of highlight (surrounding circle?) when a bar is narrower than (some amount) to make it more prominent or (probably more difficult to implement) a link between the bars would be clearer imo. c.f. File:Vatican_Europe_Location.svg. Thryduulf (talk) 14:42, 5 March 2026 (UTC)

  From what I understand, there shouldn't be more than 2 bars per infobox if/when this is added to mainspace. mdm.bla 14:47, 5 March 2026 (UTC)

  Yep, that's also what I'm having in mind. The only case where nested bars could be possible is the one to the right (as both the Proterozoic and its eras have bars), but in that case we should just pick the most precise one that fully covers the range (in this case, the Proterozoic as a whole, as the Mesoproterozoic one sees half the range be cut off).

  A link between the bars could also be possible, I'll have to look into it. Chaotic Enby (talk · contribs) 15:01, 5 March 2026 (UTC)

  I mean, theoretically you could have era-level bars for the Phanerozoic as well (see example for Primates with the parameter Cenozoic), but at that point you might as well just also create Template:Era fossil range. mdm.bla 15:11, 5 March 2026 (UTC)

  Honestly, it makes sense for the Cenozoic as its periods are already quite short and you're likely to see ranges overlapping (especially between Neogene and Quaternary), but in that case, you wouldn't want another period-level range below it. Also, given the already broadened scope, I'm open to renaming the template something like {{Detailed fossil range}}. Chaotic Enby (talk · contribs) 15:21, 5 March 2026 (UTC)

Palaeotherium Temporal range: Middle Eocene – Early Oligocene Da. S T Ypr. Lut. B Pr. Rup. Ch.
Scientific classification
Kingdom:	Animalia
Phylum:	Chordata
Class:	Mammalia
Order:	Perissodactyla
Family:	†Palaeotheriidae
Genus:	†Palaeotherium Cuvier, 1804

• For comparison, here's the sandbox version with the zoom-in and the bars on the lower side. Not especially a fan of that alternate design, although if the community prefers it I'd be happy to go with it. Chaotic Enby (talk · contribs) 13:16, 6 March 2026 (UTC)

  On second thoughts, that design is starting to grow on me, especially on a full-width infobox where it doesn't look too busy. Still torn between both, personally. Chaotic Enby (talk · contribs) 16:18, 6 March 2026 (UTC)

  I do think the addition of the zoom-in makes this a favourable version, could help with any confusion as to how the bars relate to one another. LittleLazyLass (Talk | Contributions) 16:32, 6 March 2026 (UTC)

Make Wikipedia:No Nazis a policy?

Inspired by Athanelar's comment at @ Wikipedia:Administrators' noticeboard/Incidents#Homophobic hatred by ~2026-13552-25:

Consensus is king and PAGs should be descriptive, not prescriptive. If the community norm is (as it should be and seems to be) to promptly block those who display unabashed bigotry, then the only thing stopping NONAZIS, NORACISTS, NOQUEERPHOBIA etc from being a policy/guideline rather than an essay is that nobody's taken the effort to write up the proposal and run the RfC.

I thought I'd start a discussion here. What are your thoughts on potentially turning Wikipedia:No Nazis or Wikipedia:Hate is disruptive into a Wikipedia policy? (Note: This is not an RfC.) Some1 (talk) 03:19, 5 March 2026 (UTC) Added Wikipedia:Hate is disruptive. Some1 (talk) 04:13, 5 March 2026 (UTC)

That inevitably brings us back to the intractable problem of asking which items under List of political ideologies and Category:Prejudice and discrimination by type count as ban-worthy bigotry. See the past kerfuffle at Wikipedia talk:No Nazis. Thebiguglyalien (talk) 03:39, 5 March 2026 (UTC)

I forgot to add Wikipedia:Hate is disruptive -- I remember some editors wanting that essay to be a policy/guideline. Some1 (talk) 03:45, 5 March 2026 (UTC)

I much prefer this one, both because it mitigates the issue a little bit and because it avoids the uneducated use of "Nazi" that makes it harder to discuss. But ultimately because you can conclude that we just need to enforce WP:DISRUPTIVE when someone is being disruptive. Thebiguglyalien (talk) 03:50, 5 March 2026 (UTC)

Turning NONAZIS into policy was snowball opposed last year, see Wikipedia:Village pump (proposals)/Archive 216#Upgrade WP:NONAZIS to policy. 45dogs (they/them) (talk page) (contributions) 03:54, 5 March 2026 (UTC)

As @Snow Rise already said in the original discussion. I don't think rehashing it is going to improve the outcome. ChompyTheGogoat (talk) 03:58, 5 March 2026 (UTC)

Thanks for the link. Apparently I did not see or remember that discussion (even though I made like 5 edits around that time, ctrl+F my username in that archive page). Too late for me to change the section header now, I suppose, but perhaps the focus could be on Wikipedia:Hate is disruptive instead. Some1 (talk) 04:13, 5 March 2026 (UTC)

I don't really see the point of making it policy? It is an explanatory essay on disruptive editing, rather than a new policy proposal. I think what Tamzin says here is apt, that WP:HID is a straightforward application of existing policy, not new pseudo-policy. 45dogs (they/them) (talk page) (contributions) 04:33, 5 March 2026 (UTC)

Under this essay, bigoted editors are not sanctioned for their ideologies; they are sanctioned for their behavior. That says it all. And the initial debate was over the EXTENT of the sanctions - no one suggested we should just let it slide, but supporters argue the indef was justified because of the editor's beliefs rather than the actual disruption caused. ChompyTheGogoat (talk) 04:45, 5 March 2026 (UTC)

Their comment was before you started this, however - just above yours - and said it's been discussed numerous times. I don't think utilizing a different essay on the same overall issue will change anything. The underlying problem is that you cannot expect a community like this to actually agree on what is or is not morally acceptable. I'm sure there are plenty of editors who agree with the statement that original TA made, but just know better than to base their editing on it. Basing sanctions on whether or not their edits are disruptive as a result seems like the only practical option. There are plenty of moral statements that I would support in general, but recognize would be disruptive on Wikipedia and still !vote against someone who used them in such a way. I would not do so in terms of blocking them for having the opinion. That's the reason the block is being questioned in the first place - it IS disruptive, but only a first offense, and a very minor one at that. ChompyTheGogoat (talk) 04:33, 5 March 2026 (UTC)

Not just that, it was opposed by the author of the essay: I wrote this essay as guidance, not policy. [...] The only benefits I see to this proposal are minor, and of questionable (at best) utility to this project. And the drawbacks range from measurable (in the form of increased drama-board activity) all the way up to cataclysmic (if a group of senior editors/admins ever embark upon a nazi hunt). Gnomingstuff (talk) 20:17, 5 March 2026 (UTC)

Utterly pointless, per Tamzin's comment linked above. It adds nothing to existing policy beyond labels to argue over. AndyTheGrump (talk) 04:37, 5 March 2026 (UTC)

• Personally I do think that NONAZIS or Hate is Disruptive should be a policy. It's pretty remarkable to me that hateful positions aren't against policy. But, unfortunately, the community has time and time again maintained a position of postmodernism and defiance of norms of internet media moderation. Andre🚐 04:47, 5 March 2026 (UTC)

  Define hate and what is or is not hateful in a way that's internationally consistent, relevant, and likely to be agreed on by most editors.

  Wikipedia isn't standard "Internet media", and there are plenty of sites that explicitly ENDORSE hate just like there are ones that ban it. Said policies are based on both the culture and personal beliefs of whoever runs it, not a consensus among thousands of users around the world. If this was a small wiki for a language spoken in a single nation you might have better luck - but not here. ChompyTheGogoat (talk) 05:05, 5 March 2026 (UTC)

  The policy doesn't have to define hate. It just has to empower admins to use that to block. Admins know what hate is. Admins know that if some editor comes on and makes edits or comments that denigrate a specific group or protected class, that is hateful. So long as the policy defines it that way, it would give admins another easy way to block hateful contributors. Some people argue, well, as long as they make good edits, who cares if they write antisemitic or anti-trans stuff or whatever it may be? Well, that is a matter of opinion. Just like we don't allow sockpuppets, because of the moral hazard and the cost of deception, hate is indeed corrosive to the atmosphere. It creates a hostile editing environment. In my opinion having a policy that explicitly allowed warnings and blocks for hateful speech, similar to personal attacks, would create a more inclusive environment for editors who happen to be in a minority or a protected class. The absence of this is the absence of something that is standard in the vast majority of workplaces, public fora, and so on in the Western world. Andre🚐 05:32, 5 March 2026 (UTC)

  Does writing antisemitic or anti-trans content not count as disruptive editing, which is already covered by policy? 45dogs (they/them) (talk page) (contributions) 05:35, 5 March 2026 (UTC)

  I'm sure I can come up with an example of hateful civil POV pushing that is hateful but not obviously prima facie disruptive, but let's leave that exercise to the reader, n'est-ce pas? Andre🚐 05:41, 5 March 2026 (UTC)

  I see your point, I just don't really see how HID or NONAZIS will actually solve the fundamental issue of civil POV pushing. I worry that NONAZIS especially would make civil POV pushing harder to detect. HID probably wouldn't (at least not to the same degree), but its mostly just an explanatory essay on why hate is disruptive editing, and doesn't really seek to propose anything new. 45dogs (they/them) (talk page) (contributions) 05:55, 5 March 2026 (UTC)

  The policy doesn't have to define hate. It just has to empower admins to use that to block.

  It absolutely has to if you're proposing granting additional authority. Anything else would leave "hate" up to their personal interpretation, and I shouldn't have to explain why that's a problem. If someone has managed to squeeze in a comment that's somehow hateful without constituting disruption, PAs, or anything else that's already actionable (I'd welcome examples) then a warning that they're on thin ice and should take care not to put a single whisker over the line would likely suffice. In my experience (and other editors have already concurred) bigots are not prone to subtlety, and even if they did manage it once said warning would probably be enough to set them off and justify sanctions under policies that already exist. ChompyTheGogoat (talk) 06:38, 5 March 2026 (UTC)

  I hate this comment. Thebiguglyalien (talk) 05:25, 5 March 2026 (UTC)

  I know you're being at least somewhat facetious, but this type of hate isn't the type I meant. I meant hate to a specific group or class of people. Hating comments because they are wrongheaded is fine. That is argument. Hate is about discriminating against someone's identity or religion or gender etc. Andre🚐 05:34, 5 March 2026 (UTC)

  The next step in the facetiousness would be to say "I hate the group of people who write that comment", but that would actually be rude toward you, and that fact might prove your point in this respect. But to address the overall issue, there will always be disagreement over what a "hateful" position is. If admins are actively looking for "is this hate" as opposed to "is this disruptive" (which still includes things like white supremacy), then you'll find admins with different definitions of hate than your own. I guarantee you that for any major country's foreign policy, there's a non-zero number of admins who would consider supporting it to be a form of hate. Thebiguglyalien (talk) 05:48, 5 March 2026 (UTC)

  This type of hate isn't the type I meant.

  Exactly. ChompyTheGogoat (talk) 06:40, 5 March 2026 (UTC)

  Andre uses "hate" to mean racism, sexism, queerphobia, etc. Thebiguglyalien uses "hate", probably maliciously, to mean a personal dislike of a thing. Do you really want to argue that an unintended alternative definition invalidates a word? If so, I would like to see that energy towards "notability", "neutral point of view", and "fringe". LightNightLights (talk • contribs) 14:04, 5 March 2026 (UTC)

  Even then, the lines on those words are not clearly defined and what one person thinks is racist, sexist, ect. could seem to not be that way to another person. (Talk) PHLOGISTON ENTHUSIAST 14:06, 5 March 2026 (UTC)

  I am not arguing against reasonable disagreement. I am arguing we begin with being against the idea of discrimination. LightNightLights (talk • contribs) 14:26, 5 March 2026 (UTC)

  We are against discrimination. We are also against thought crimes. (Talk) PHLOGISTON ENTHUSIAST 14:30, 5 March 2026 (UTC)

  We are, but not in the way you think. LightNightLights (talk • contribs) 15:08, 5 March 2026 (UTC)

  None of these are thought crimes. (Talk) PHLOGISTON ENTHUSIAST 19:15, 5 March 2026 (UTC)

  I'm arguing that we have argue over the definition if it's to be used to justify administrative sanctions. ChompyTheGogoat (talk) 14:31, 5 March 2026 (UTC)

Oppose. This issue has been brought up before. We cannot be the thought police, and there's another issue here. You would either have to:

• Define hate in a way that fits the majority of editors opinions, which would be nearly impossible, and block based on that.

OR:

• Leave it to admin discretion what is and isn't acceptable, which lets them choose what type of speech they will tolerate by their own opinions. This is obviously not a good idea.

(Talk) PHLOGISTON ENTHUSIAST 13:43, 5 March 2026 (UTC)

• Personally, I disagree with every single line of this comment, and I consider myself apolitical, or rather, nonpartisan. It reminds me of an old post that suggested dividing every social network into a "left-wing Facebook" and a "right-wing Facebook," each with its own rules about what opinions are acceptable and what is "hateful." For the record, having a critical or negative stance on controversial topics is legitimate. The opposite is censorship and "moral" tyranny.

And, generally speaking, every pro or con position on any topic refers generically to a "class of people," since it's impossible to engage in "ad personam" discussions when discussing ideologies of any kind. What pre-legitimizes one position and pre-delegitimizes the other if not the ideological convictions of the editor in question? Sira Aspera (talk) 12:00, 5 March 2026 (UTC)

• For the record, having a critical or negative stance on controversial topics is legitimate. it isn't when the 'controversial topic' is whether being trans makes someone a child predator... Athanelar (talk) 12:05, 5 March 2026 (UTC)

• No. We are not, cannot be and should never attempt to be, thought police. Everybody should be welcome to edit here if they can do so constructively, regardless of what beliefs they do or do not hold. People who cannot edit constructively should not be allowed to contribute, regardless of whether the reason for that is financial, ideological, a language barrier, immaturity, intellectual disability, a desire to vandalise, or anything else. Pick any ideology you personally find distasteful and chances are there is at least one person who genuinely subscribes to that belief who is productively and competently contributing, entirely uncontroversially, to the encyclopaedia right now. The more extreme the ideology the more likely it is they are contributing to topic areas unrelated to that ideology, but even in related topic areas as long as they are able to edit in accordance with NPOV and our standards of behaviour nobody will know even if they do contribute to directly-related subject. Thryduulf (talk) 05:07, 5 March 2026 (UTC)

As soon as you try to make it a policy that we can ostracize an editor for their political or ideological elements, you open the door to apply that to any one else, and that's just not a smart idea. It doesn't matter if the editor considers themselves a Nazi or similar as long as all of their mainspace editors follow policies and guidelines, and they follow all expected behavior aspects on talk pages particularly in how they talk to other editors.

Now, of course, if someone comes anew to WP and their editors are very disruptive in mainspace/aggressive and impolite in talk page, and indicate they follow such extreme ideologies, that's a good reason to go ahead and block if they don't change their ways after a warning. But that applies to anyone, not just someone that claims they are a Nazi or equivalent. Masem (t) 05:11, 5 March 2026 (UTC)

What do you think about the indef block on User:~2026-13552-25 then? The TA wasn't exactly disruptive in article space / mainspace. The admin cited WP:NOTHERE as the reason for the block, but it seems like it would fall more under Wikipedia:Hate is disruptive. Some1 (talk) 05:18, 5 March 2026 (UTC)

And they follow all expected behavior aspects on talk pages particularly in how they talk to other editors.

As always, that includes edit summaries, which get brought up at ANI all the time. I haven't seen anyone there try to claim it's acceptable behavior - just questioning whether an indef is appropriate for their very first edit, particularly since it's not in a live article. WP:HID > WP: DISRUPTIVE, rather than assuming WP:NOTHERE from three whole words. ChompyTheGogoat (talk) 06:49, 5 March 2026 (UTC)

The above is exactly why nobody's bothered to write the proposal and run the RfC, by the way; there's no way to do it in a way that's satisfactory. I worry that our policy on hate will forever float in the grey area.

Admins will block people for being hateful, people will say "NONAZIS is an essay!" Someone will try to get it promoted, and people will say "you can'r define ir so you can't block people for it!" Athanelar (talk) 11:45, 5 March 2026 (UTC)

I would greatly appreciate if you could present diffs of this scenario happening. (Talk) PHLOGISTON ENTHUSIAST 14:33, 5 March 2026 (UTC)

It's literally what happened in the ANI thread linked at the top of this thread.

Despite a perennial inability of ANI complainants to accept the fact, WP:NONAZIS is an essay, which the community has consistently declined to adopt as policy. In other words, having social views which depart from the norms of our typical editor is not in itself grounds for sanction Emphasis mine. Athanelar (talk) 17:09, 5 March 2026 (UTC)

That's a very biased view of what happened there. (Talk) PHLOGISTON ENTHUSIAST 17:49, 5 March 2026 (UTC)

Biased how? Athanelar (talk) 18:01, 5 March 2026 (UTC)

Alright, this one's my bad. I got WP:Hotheaded here. You are correct in saying that, and it was rude of me to call that biased. Won't happen again. (Talk) PHLOGISTON ENTHUSIAST 19:20, 5 March 2026 (UTC)

I'll try to summarize it for those who didn't click on the link:

• User:~2026-13552-25 made 2 edits in a span of a minute or two. Neither of the edits to the article space is bad, per se.
• They were brought to ANI because their very first edit, to Political positions of Javier Milei, included the edit summary: MOS:QUOTE (Milei is right).
• If readers click on the diff[34], they might assume that the TA meant "Milei is right" about:

  Milei argued there was an "LGBT agenda", saying, "In its most extreme version, gender ideology simply and plainly constitutes child abuse. They're pedophiles."

• Their last edit was made around ~08:48, and they were blocked at 20:10 by an admin for "Clearly not here to build an encyclopedia".
• As for the editors' reactions, you (not you specifically) can read them in the ANI thread linked in the initial comment. Some1 (talk) 00:26, 6 March 2026 (UTC)

@Athanelar, I think something constructive that we could do is provide a clear, wikilawyer-resistant statement somewhere that says that admins are allowed to cite "mere essays" as explanations for blocks. Then we can shift the conversation from "You can't do that to me!" to this:

• A: That's just an essay, so you can't block people over it.
• B: I can and will. See WP:BLOCKESSAY, which explicitly authorizes admins to block people for "violating" an essay.

Off hand, I think that this would fit into either WP:EXPLAINBLOCK (perhaps in the paragraph beginning "Administrators must supply a clear and specific reason why a user was blocked") or WP:NOTBURO (perhaps adding something like "For example, admins are not required to cite an official policy when blocking someone; they are allowed to instead cite essays and other informal explanations, such as WP:NOTHERE and Wikipedia:Tendentious editing, if the admin believes those pages provide a relevant explanation of the reason for the block"). WhatamIdoing (talk) 07:30, 6 March 2026 (UTC)

The problem is that a lot of essays don't have community consensus, or are even opposed by a majority of editors. Admins are supposed to enforce consensus, and letting them block over any essay could lead to some enforcing their personal opinions of what the community norms should be, and consequently make it much harder for newer editors to navigate what is or isn't acceptable behavior ("What if there are two contradicting essays? Am I at risk of being blocked either way?") Chaotic Enby (talk · contribs) 09:08, 6 March 2026 (UTC)

My concerns with this are similar to Chaotic Enby's - am I allowed to block per WP:MANDY and/or per WP:NOTMANDY? What about WP:IARUNCOMMON?

I also thought about the possibility of an admin writing an essay saying that $thing is mandatory/prohibited and blocking people for (not) doing that, even if almost no other editors even know the essay exists - e.g. Could I write an essay saying that people leaving a user talk page message on a Sunday must include a cute picture with the message and use this policy as a justification for blocking people who do not comply? Hopefully your answer is "no", but where is the objective line between a brand new essay that contradicts consensus and something like WP:IDONTLIKEIT that has very widespread consensus? Where and how can new editors find which side of this line any given essay sits? Thryduulf (talk) 09:47, 6 March 2026 (UTC)

Yeah, I think it presents the the same problem, it's just gone from "admins can define hate how they want" to "admins can choose which essays on hate to enforce". Isn't there something I read about that defines admin powers? I have a hard time accepting that a standard consensus (even if one could be passed) would be sufficient to extend their authority to that degree. In practice it would be nearly free rein - and it would essentially elevate all essays to guidelines, including a huge number that were never intended to be (see NONAZIS' creator's statement below) as well as those written to intentionally make someone's particular ideology enforceable. I've ran (and still do to some extent) other platforms where it was my way or the highway because i was cultivating a specific community for a specific purpose - but that's not what Wikipedia is, and a lot of this discussion seems to violate the general spirit of site (and foundation). ChompyTheGogoat (talk) 10:08, 6 March 2026 (UTC)

I think there's a slight, but important, distinction concerning blocking somebody for violating an essay (please don't) and blocking somebody for violating one of the many PAGs or pillars (WP:CIVIL, WP:CV, WP:BLP, what have you) while pointing to an essay as the explanation as to why you, as an admin, believe this particular behavior is in violation of a PAG, and why you chose to block rather than warn. And I'm pretty sure that the second is what WAID is suggesting, given the scare quotes? GreenLipstickLesbian💌🧸 12:08, 6 March 2026 (UTC)

Very good distinction, thanks a lot! I didn't catch this nuance, but such a clarification should make it explicitly clear, as it could otherwise be read as allowing admins to block based on any essay. While I do of course agree with WP:NOTBURO, admins have a lot of power, and having a clear framework on how to apply it does help for purposes of accountability. For example, we could require admins to cite the relevant PAG or pillar alongside the explanatory essay (as many essays aren't directly tied to one), to avoid cases such as the ones described by Thryduulf and ChompyTheGoat.

In general, as anyone can write an essay, I see them more as a "shorthand for detailed reasoning" than as anything binding, and disagreement with the essay's interpretation of policy should still be open to a resolution at WP:AARV, just like disagreement with any other admin interpretation of policy. Chaotic Enby (talk · contribs) 12:27, 6 March 2026 (UTC)

As an addition: we can and already do block users based on essays (WP:NOTHERE probably being the most famous one), although these are again used as shorthand for explaining aspects of policies/guidelines, and have broad acceptance for their use. Thinking about it a bit more, citing the relevant PAG or pillar in the case of explanatory essays explicitly marked as such may be silly (my worry being mostly over essays not directly based on one of those), although a blanket allowance of all essays wouldn't be the best way to go at it. Again, they're shorthand for explanations, and making blanket rules such as "all explanations are allowed" or "no explanations are allowed" won't bring us very far. Chaotic Enby (talk · contribs) 12:35, 6 March 2026 (UTC)

Why doesn't someone propose NOT HERE as policy? (Talk) PHLOGISTON ENTHUSIAST 12:37, 6 March 2026 (UTC)

Oppose for the same reasons this has been shot down before. If someone is being disruptive then there are other adequate policies that will cover that. — Czello ^(music) 14:11, 5 March 2026 (UTC)

Is Wikipedia really "an encyclopedia that anyone can edit" if some of those editors are discriminated on? Is it not taking sides already to be pro-knowledge? LightNightLights (talk • contribs) 14:17, 5 March 2026 (UTC) (edited 14:23, 5 March 2026 (UTC))

Being pro-knowledge on an encycopedia is not really taking a side so much as it is a requirement to be on the encyclopedia, because if you are anti-knowledge you probably aren't on the encyclopedia. (Talk) PHLOGISTON ENTHUSIAST 14:31, 5 March 2026 (UTC)

Anybody who argues to delete something that is verifiable is anti-knowledge. Thryduulf (talk) 14:37, 5 March 2026 (UTC)

I don't think we need to drag WP:NOTEVERYTHING into this. ChompyTheGogoat (talk) 14:39, 5 March 2026 (UTC)

I'm not arguing there aren't reasons to delete verifiable information (I've argued for it plenty of times myself), I'm just pointing out that even something like being "pro-knowledge" isn't black-and-white. Thryduulf (talk) 14:44, 5 March 2026 (UTC)

Wikipedia only summarizes existing information. The sources still exist and anyone is free to educate themselves in more detail. Choosing what to include or not isn't a book burning. ChompyTheGogoat (talk) 15:13, 5 March 2026 (UTC)

That's just plain and simple not true. (Talk) PHLOGISTON ENTHUSIAST 15:25, 5 March 2026 (UTC)

Then please explain, objectively, in plain and simple language why excising knowledge from the encyclopaedia is not, by definition, anti-knowledge. Thryduulf (talk) 17:10, 5 March 2026 (UTC)

Because "anti knowledge" implies an ideology, even philosophy. "This particular information doesn't belong in this one location" doesn't even approach that. Removing something that doesn't belong there is no different than not adding it in the first place. I'm not anti-car for saying cars don't belong on sidewalks, or calling for them to be removed if they ended up there. The fact that it's verifiable doesn't make removing it worse than removing vandalism or typos, it just means the decision requires more critical thinking. ChompyTheGogoat (talk) 17:24, 5 March 2026 (UTC)

Because removing information that is true is not always a bad thing. I could go to an article about bears and write that there are a lot of pencils in the world. True? Yes. Should it be removed? No. (Talk) PHLOGISTON ENTHUSIAST 17:42, 5 March 2026 (UTC)

That is my point. In building an encyclopedia, we editors take the side of building an encyclopedia. Why, then, are other editors in this discussion complaining that that encyclopedia takes sides? LightNightLights (talk • contribs) 15:19, 5 March 2026 (UTC)

Because this entire thing is frankly ridiculous. Wikipedia is not for thought crimes. It's a slope with no clear set of rules or definitions and allowing admins to choose what they find offensive instead of having a guideline (that would frankly be near-impossible to craft to everyone's satisfaction) is the worst possible outcome. (Talk) PHLOGISTON ENTHUSIAST 15:23, 5 March 2026 (UTC)

Thankfully, NONAZIS guides us by listing the beliefs of Nazis:

• "that white people are more intelligent than non-whites",
• "that white people are morally and ethically superior to non-whites",
• "that Jews present an existential threat",
• "that the Holocaust never happened, was greatly exaggerated, or that historians have inflated the death toll",
• "that Adolf Hitler was a great leader for the German people, despite (or even because of) Nazi Germany's innumerable atrocities",
• "that there exists a Jewish or "elite" cabal as purported in any of a variety of implausible conspiracy theories, such as QAnon, the New World Order, the white genocide, or the Great Replacement",
• and more.

It also has a section called "Don't use claims of racism as a coup de grâce". Please read the essay in hand. LightNightLights (talk • contribs) 17:16, 5 March 2026 (UTC)

That is one editor's opinion. Essays aren't guidelines for a reason. Even if we adopted that it would ONLY apply to white supremacy - does that mean other forms of hatred are more acceptable? ChompyTheGogoat (talk) 17:25, 5 March 2026 (UTC)

I am getting tired of fucking linking and reading guidelines and policies only to be given back these uneducated posts. Yes, the page edited by 273 editors is "one editor's opinion". Yes, "racism is bad" definitely means "transphobia is good" and not "we are still working on it". No, NONAZIS does not say "compiled by multiple people". Zero truths and three lies. LightNightLights (talk • contribs) 17:38, 5 March 2026 (UTC)

Being aggressive isn't helping your case here. (Talk) PHLOGISTON ENTHUSIAST 17:42, 5 March 2026 (UTC)

Any comments on the actual substance? LightNightLights (talk • contribs) 17:54, 5 March 2026 (UTC)

Four, actually, if you care to read them. (Talk) PHLOGISTON ENTHUSIAST 17:55, 5 March 2026 (UTC)

I take it you missed the recent WP:BOOMERANG case over WP: INCIVILITY? ChompyTheGogoat (talk) 17:56, 5 March 2026 (UTC)

You two suck. LightNightLights (talk • contribs) 18:01, 5 March 2026 (UTC)

So that's a no. Adding WP:PAs doesn't help your case. What it does do is illustrate exactly why this is entirely too contentious to ever pass. ChompyTheGogoat (talk) 18:06, 5 March 2026 (UTC)

WP:ICA and WP:NPA. (Talk) PHLOGISTON ENTHUSIAST 18:41, 5 March 2026 (UTC)

I did miss that, actually. Could you link that to me on my talk page? (Talk) PHLOGISTON ENTHUSIAST 18:43, 5 March 2026 (UTC)

The user did not say that the policy meant that transphobia is good. But if you're still working on it, maybe finish working on it first before suggesting it to become official wikipedia policy. We don't implement policies before they're done. (Talk) PHLOGISTON ENTHUSIAST 17:48, 5 March 2026 (UTC)

Re: “We don’t implement policies before they’re done”… Given that we are constantly tinkering with and changing our policies, I would say our policies are NEVER “done”. Blueboar (talk) 18:53, 5 March 2026 (UTC)

I agree. However, it seems to me that we really shouldn't implement a policy that is so not done that it cannot handle a large of the issues it aims to target, and could in fact create a good many issues. (Talk) PHLOGISTON ENTHUSIAST 19:00, 5 March 2026 (UTC)

Phlogiston, it appears you've been editing here for almost three months now. Have you found WP:NAVPOPS yet? It has this very cool feature that lets you hover over another editor's name, and shows you how long they've been editing Wikipedia. For example, if you used it in this thread, you would have discovered that you're talking to a person who has been editing Wikipedia, including its policies and guidelines, for twenty (20) years. WhatamIdoing (talk) 07:41, 6 March 2026 (UTC)

I am aware. I am also aware that this does not mean compliance is required, and I am acting well within what is allowed. (Talk) PHLOGISTON ENTHUSIAST 12:05, 6 March 2026 (UTC)

I did in fact know of the account's age, to clarify. I am also aware that the account being vastly older than mine only means that they have more experience, not that they are more correct. For example, an editor whos account is years older than mine has just told me that I 'suck' twice. Does this make them correct because they are older and have more edits, so suddenly this is acceptable conduct? I would say probably not. I am also not entirely inexperienced, as I am a pending changes reviewer and am familiar with policy there. (Talk) PHLOGISTON ENTHUSIAST 12:15, 6 March 2026 (UTC)

Respectfully, an older account doesn't necessarily make someone more correct, and dismissing a newer user's suggestion only based on their age can come across as WP:BITEy. Chaotic Enby (talk · contribs) 12:19, 6 March 2026 (UTC)

Yeah, it felt weird and I feel like there's a policy about this but I can't quite remember the name. (Talk) PHLOGISTON ENTHUSIAST 12:26, 6 March 2026 (UTC)

Wikipedia:Please do not bite the newcomers is as far as I know the closest thing we have to one (Wikipedia:No personal attacks doesn't mention account age as a kind of ad hominem, although its list is not exhaustive). I did write the explanatory essay WP:NOELDERS some time ago, but it is only an essay rather than anything binding. Chaotic Enby (talk · contribs) 12:30, 6 March 2026 (UTC)

Ok, a few people. How many editors are active to some degree on all of English Wikipedia? You think you'll get consensus from all of them on that - and additional proposals on every other form of hate that anyone thinks should be banned? ChompyTheGogoat (talk) 17:49, 5 March 2026 (UTC)

I feel warm. Is it 451 degrees in here right now? (Talk) PHLOGISTON ENTHUSIAST 17:52, 5 March 2026 (UTC)

Banning constructive editors over personal beliefs feels a lot more "anti-knowledge" than prudent trimming, TBH. ChompyTheGogoat (talk) 17:58, 5 March 2026 (UTC)

Fair. (Talk) PHLOGISTON ENTHUSIAST 18:42, 5 March 2026 (UTC)

Also, I did read the essay. If you read my comment, you can see I said a guideline to everyone's satisfaction, not just a guideline. (Talk) PHLOGISTON ENTHUSIAST 17:44, 5 March 2026 (UTC)

• Opposition. For reasons already expressed by other editors, and because it's a proposal that introduces a multitude of problems without solving any of them, and without even demonstrating that there is a problem that needs to be solved, especially considering that Wikipedia, in independent sources, is already considered politically biased to the left. Making this won't improve matters. And this doesn't even begin to address the fact that the standard for what is "hate speech," "unacceptable," "offensive," or anything else is fluid. Today, it matches OP's. Tomorrow, the same politicians might decide that their opinions also fall under these labels. Who knows, maybe in five years it will be "unacceptable" to say you don't want dogs on the beach because we have a different animal rights policy, or to support an omnivorous diet out of sensitivity toward vegans. Sira Aspera (talk) 15:25, 5 March 2026 (UTC)
• Unsure While I do feel that Wikipedia stating that it is aware of how the Paradox of tolerance affects its neutrality goals is a good thing, the NONAZIS essay describes application of existing policy. It doesn't really contribute much language that would be impactful upon policy since it's already WP:NOTHERE behaviour to be spouting off racist nonsense or what have you. Simonm223 (talk) 17:16, 5 March 2026 (UTC)

  The origin of the debate here is an ANI thread in which a TA was banned for stating in an edit summary that Javier Milei was 'right' to describe the adherents of 'gender ideology' (read: trans people and their supporters) as 'pedophiles'. They were indeffed as an admin action for this which led numerous editors to raise their concerns that the block was hasty or excessive, with some specifically pointing out that NONAZIS, NOQUEERPHOBIA etc are merely essays and not enforceable policy. Athanelar (talk) 17:23, 5 March 2026 (UTC)

  I'd say that WP:TEND covers that specific issue as does WP:NOTHERE on the basis of being an egregious violation of WP:CIV that is a personal attack against a broad demographic of Wikipedia editors. As such, I don't know if I participated in that discussion, I think I didn't, I'd say the admin was operating within existing policy and doesn't need WP:NONAZIS to be policy in order to keep off someone who would make such inappropriate statements. Simonm223 (talk) 19:20, 5 March 2026 (UTC)

  The main concern is that it was literally the user's very first edit - followed by a single revert that appeared appropriate - and going straight to indef seemed over the top. Since it's a TA it's entirely possible there were indeed NOTHERE, but it's a poor precedent to set for newbies who might have potential to be constructive with some guidance (and firm lines regarding repeat behavior). Especially since it was a three word edit summary and they didn't add anything hateful to the live article. Some kind of action is certainly warranted, but a lot of people think it should have been reined in a touch given those considerations. ChompyTheGogoat (talk) 21:52, 5 March 2026 (UTC)

  Also re precedent of thought policing. We need to separate the extent of the actual behavior from the belief behind it. ChompyTheGogoat (talk) 21:54, 5 March 2026 (UTC)

• Oppose any elevation of NONAZIS—we are already on the proverbial slippery slope; an editor was last week almost community banned for the cardinal sin of daring to believe that AI might in the future be superior to Wikipedians. WP:HID simply describes the application of existing policy. ~~ AirshipJungleman29 (talk) 17:21, 5 March 2026 (UTC)

  To be fair, that editor has a long history of disruptive behavior (as opposed to literally their first ever edit) and had previously explicitly stated that they would repeat it given half a chance. They only agreed to stop after having their arm twisted, and the general concern was that they would indeed repeat the behavior - not just over the beliefs themselves. If they'd only posted on their user page and not made ongoing problematic edits the subject wouldn't even have come up. But that is why the current standards for disruption SHOULD be sufficient if they're applied correctly. ChompyTheGogoat (talk) 17:33, 5 March 2026 (UTC)

• Oppose - Creating a situation where editors can be site-banned because of their beliefs? is not a good idea. GoodDay (talk) 17:27, 5 March 2026 (UTC)
• Oppose: Existing guidelines such as WP:NOTHERE adequately cover this type of situation. No need for rule creep.--♦IanMacM♦ ^{(talk to me)} 17:34, 5 March 2026 (UTC)
• Oppose Wikipedia is supposed to be WP: IMPARTIAL. And people are supposed to be here to work towards an impartial encyclopedia. People who aren't can be removed by our normal behavioral policies. --Kyohyi (talk) 18:03, 5 March 2026 (UTC)

  Please tell us how WP:IMPARTIAL as written relates here. LightNightLights (talk • contribs) 18:08, 5 March 2026 (UTC) (edited 18:10, 5 March 2026 (UTC))

  How facts are selected, presented and organized is subjected to community consensus and should be impartial per WP: IMPARTIAL. Community consensus is dependent on community membership, if community membership is not impartial, consensus cannot be impartial, and in turn content cannot be impartial. This should not be construed as tolerance however. We are not, and should not be tolerant to POV pushing or WP: ADVOCACY style behaviors. --Kyohyi (talk) 18:23, 5 March 2026 (UTC)

  Wikipedia is partial towards reliable sources:

  • We need sources. (WP:V, WP:NOR)
  • We need them to be reliable. (WP:RS)
  • We especially need them on contentious stuff about people. (WP:BLP)
  • And medical articles too. (WP:MEDRS)
  • Reliable sources are not required to be impartial. (WP:RSBIAS)
  • We follow the proportion of reliable sources. (WP:NPOV)
  • We treat uncontested facts from reliable sources as facts. (WP:YESPOV § "Avoid stating facts as opinions")
  • We only present accepted ideas. (WP:FALSEBALANCE)
  • We do not present fringe ideas as accepted. (WP:FRINGE).

  These point to the fact that Wikipedia is not required to be unbiased. Wikipedia editors need to be when writing articles (WP:NPOV).

  Stepping back, IMPARTIAL is content, not conduct. How we write articles is not how we expect editors to act. We disallow personal attacks even though we write about the lot of them that happens in real life. LightNightLights (talk • contribs) 19:11, 5 March 2026 (UTC)

  Wikipedia is Impartial on to what sources are reliable. It applies to how and what we determine are reliable sources and that is a behavioral constraint. Not just a content constraint. --Kyohyi (talk) 19:37, 5 March 2026 (UTC)

  We really are not. Also, everything then is behavioral, even most – if not all – content policies. That fact just makes that definition of "behavioral" useless. LightNightLights (talk • contribs) 06:20, 6 March 2026 (UTC)

  That's just demonstrates a problem with WP: RSP, or more accurately that the consensus model doesn't achieve the standards set out in our core content policies. And yes, not applying our content policies is a behavioral issue. Editors who regularly insert content that doesn't meet WP: V get blocked even though Verifiability is a content policy. --Kyohyi (talk) 14:30, 6 March 2026 (UTC)

  I would honestly reccomend stepping away from this discussion after doing a WP:PA. It's clearly got you agitated, and I recommend you take a few hours to breathe and remember that this is just the internet, and this is not life or death. I promise whatever happens will be okay. (Talk) PHLOGISTON ENTHUSIAST 19:14, 5 March 2026 (UTC)

  Also, it is kind of ironic to tell someone 'you guys suck' and then talk about how personal attacks are banned. (Talk) PHLOGISTON ENTHUSIAST 19:28, 5 March 2026 (UTC)

  I took a few hours: you two still suck. I will just voluntarily not further interact with you two. LightNightLights (talk • contribs) 06:13, 6 March 2026 (UTC)

  I hope that helped; but telling people they 'suck' is still not how we are supposed to act here. Please read WP:CIVIL, if you haven't already. Not that you have to, but I feel it really would benefit you. (Talk) PHLOGISTON ENTHUSIAST 12:07, 6 March 2026 (UTC)

• Support Readily definable and identifiable, clearly actionable. This would align policy with our practice. This is not idle conversation but actively relevant. Everyone has the right to read Wikipedia and everyone has a right to edit Wikipedia. There are a few hate-based ideologies which are directly contrary to those things. Wikipedia is tolerant of everything except intolerance of the right of others to participate. Bluerasberry (talk) 18:07, 5 March 2026 (UTC)

• Comment For anyone saying that Wikipedia ought not have a "no Nazis" policy because Wikipedia prohibiting users for an ideology is unprecedented - this is an error, because there already is an ideology for which we have consensus to block or ban users on recognition. Wikimedia projects do not permit users to have pedophilia ideology. It is not uncommon for people with this ideology to treat the condition as a mental disorder, be in mental health counseling, and be non-active in pedophilia, and yet despite this community's apologetic existence, Wikipedia practice is still to purge any persons known to identify in this way. In 2025 we had a registered Wikimedia editor with an edit history travel across the country to attend WikiConference North America to make a choice whether to use the gun they brought out in front of the crowd, as described in Wikipedia:Wikipedia_Signpost/2025-10-20/In_the_media. This person identified as a "non-offending pedophile", and was protesting English Wikipedia's practice of not tolerating their identity. They were just one person and we have other such cases. I think everyone would be better off, included the excluded users, if we openly and directly said that we do not allow people with certain ideologies in Wikipedia's community spaces, so that no one has lack of clarity in what ideologies are welcome here, and who can develop peer-to-peer collaborative relationships here.

Based on our precedent of disallowing non-offending self-identified pedophilia people who merely express identity and do not otherwise disrupt Wikipedia except with the presence of their identity, I would like to add Nazis to that group. If someone merely says, "I share parts of this ideology", then it is a major disruption to other editors' ability to participate in the projects. I think we should be careful about excluding ideologies, but when we list the ideologies that we do not allow, Nazism and pedophilia ideologies are both intolerably disruptive just by being known to be allowed to exist in our community.

Having a "no nazis" rule would not take new social or technical infrastructure. We could put that rule right in the box with the no pedophilia rule.

To the good people of any ideology who try to avoid self identifying a taboo ideology and who causally edit Wikipedia articles constructively on topics unrelated to their ideology, I am sorry, but Wikipedia operates at scale and some demographics are so disruptive in society that for the social machine to function, we discriminate against the class based on known ideology. Bluerasberry (talk) 22:01, 5 March 2026 (UTC)

Wikipedia:Child protection was added for legal reasons and is enforced by the WMF. If we're going to add more on our own perogative, which pages in Category:Prejudice and discrimination by type and its subcategories describe immediately blockable sentiments? You can say just Nazis, but because the essay is written with a poor understanding of history and politics, it encompasses all white supremacist ideologies, including ones that pre-date Nazism. You could then say just white supremacists, but that wouldn't ban transphobes and misogynists, among others. You could say all types of discrimination based on identity, and you'd think that would include Linguistic discrimination, but telling people who don't speak English to leave is embedded into the project. So that brings us back to the original question. Maybe we can narrow it down to the identities named at Template:Uw-derogatory (nationality, race, ethnicity, color, religion, sex, gender, gender identity, sexual orientation, disability, or other factors)? I just had to drop three of them a few days ago on people who were attacking each others' intelligence on the basis of them being American and European, respectively. Should I have reported them all straight to ANI instead for immediate indefs? These are hard questions that would be answered differently by different admins, and each answer someone deemed wrong would be challenged at WP:XRV. Thebiguglyalien (talk) 22:30, 5 March 2026 (UTC)

Boy, I sure do hate them [other factors]. ChompyTheGogoat (talk) 22:45, 5 March 2026 (UTC)

Per Wikipedia:Child protection, that rule exists specifically because there's potential for real world danger to underage users if it was allowed - not to mention an absolute mountain of possible legal trouble. When I used to work on search results for Big G there were exactly two things we were required to report (which went straight to LE), and that was one of them. Not just overt CP but anything remotely adjacent.

And again, if you move to classify Nazis in the same way, you either need to do so for all other forms of bigotry, or try to justify why the rest are less serious. ChompyTheGogoat (talk) 22:40, 5 March 2026 (UTC)

If someone merely says, "I share parts of this ideology", then it is a major disruption to other editors' ability to participate in the projects. What of people for whom ideological blocks, absent actual behavioral problems, are a disruption to their ability to participate in the projects? Anomie⚔ 23:02, 5 March 2026 (UTC)

• Support Not seeing the merit of arguments against this proposal. I am aware that disruptive editing covers just about everything, but feel that there is no reason not to codify what is in fact already our practice. Hawkeye7 (discuss) 19:39, 5 March 2026 (UTC)
• Oppose Agree entirely with Thryduulf. * Pppery * _{it has begun...} 19:55, 5 March 2026 (UTC)
• Opposed - there is no need to elevate these essays into guidelines or policies. Soapboxing for any viewpoint (even views that are not deemed “hateful”) is disruptive behavior… and we already have policies to deal with disruptive behavior. Blueboar (talk) 20:19, 5 March 2026 (UTC)

Oppose per User:MjolnirPants (who wrote the damn thing) in the last proposal. Gnomingstuff (talk) 20:18, 5 March 2026 (UTC)

• Oppose as this is written as an essay and not a policy. Although I would agree with much of the essay, not 100%. On Wikipedia others whose opinion we disagree with, should be able to edit. What counts is what they actually do, rather than what they believe. Being hostile to other editors is a reason for action to prevent, eg by revert, warn, block etc. We don't need hostility because of a disagreement with someone. On AN/I there is a fair bit of that shown, and perhaps we should be more generous with warnings for incivility and expressions of intolerance. Graeme Bartlett (talk) 20:30, 5 March 2026 (UTC)

• Oppose, for all of the reasons which the community has historically declined to adopt this essay as policy, including in last year's widely attended RfC. The desire to create additional bulwarks to protect the project and our community members from exposure to objectionable beliefs is an eminently understandable motivation, but this is just not the way to go about it. While NONAZI's is chock full of observations that I would describe as common sense, the general thrust/operational idea that most people seem to want to integrate into policy--that we should purge from the community and the pool of editorial talent anyone who makes the mistake of admitting to a belief that a significant number of community members would view as ignorant, bigoted, offensive, or hateful--is simply completely infeasible for a project of this sort. Far from expediting and facilitating control of problematic behaviour, it would undermine the existing scheme for responding to such conduct and provide fertile grounds for a vast expansion disruption and misdirection of volunteer effort by introducing essentially inexhaustable ideological debate about the values of editors. Even where the majority of editors could agree to label a spade for a spade (and I think the proponents of this idea vastly overestimate the proportion of cases that would fall under that category), the result would still be a huge uptick in volunteer time wasted, other loss of community resources, and huge amounts of needless rancor.
  The reason this project uses the WP:disruption model for dealing with problem editors, including those of the bigoted variety, is in many respects a parallel example of why we use a WP:Verifiability model instead of a WP:truth model for content: it's by no means because we do not, as individuals, care about the truth, but rather because basing our approach in such a nebulous and idiosyncratic principle is impractical. Using a more objective standards like WP:V and WP:WEIGHT is a way to side-step infinitely recursive debates about our personal beliefs of the reality of a situation as it relates to content.
  Similarly, I believe that the average Wikipedian, and certainly the average veteran editor, tends to be strongly aligned against movements predicated in bigoted rhetoric--and not just because of personal values but because these movements tend to be heavily reliant on the kind of misinformation that runs counter to the objectives of the project, and which is in itself typically found obnoxious to the type of people our movement attracts. But in the same way a "truth" model for content is untenable, the model suggested by NONAZIs is untenable for responding to problems resulting from objectionable beliefs, because it paves the way for intractable quagmires regarding the "truth" of what constitutes hate, bigotry, ignorance, or small-mindedness, and the borders therebetween. That's why the more objective standards of a WP:DISRUPTION model, already adequately implemented in existing policy, is not only the most efficient means for dealing with objectionable rhetoric and conduct, but arguably the only feasible one for this project, given it's scope and nature, and the intentionally pluralistic make-up of its volunteer base. SnowRise ^{let's rap} 20:43, 5 March 2026 (UTC)

  See this is a much lengthier version of where I'm coming from above. I see NONAZIS as descriptive of an application of policy. I would like to see Wikipedia formally adopt the Paradox of Tolerance within our governance model but, informally, we already have and I'm uncertain this essay would actually accomplish that. And note, while I did not draft the essay I was literally the first editor to endorse it. It's not like I disagree with its content. I just, you know, have come to recognize what is and how it is best used. I will say that I don't really have a problem with admins who use NONAZIS as a block rationale, despite this, because it's a nice, abbreviated, way of saying "blocked for disruptive editing on the basis of hateful conduct." Like I said: NONAZIS describes how we should apply policy in a specific use case. I would expect that the same would apply to a Stalinist who says "libs get the wall" on Wikipedia too and yet there is no WP:NOSTALINISTS policy. Simonm223 (talk) 20:59, 5 March 2026 (UTC)

Yes, I agree--although at the same time I understand why most admins seem to avoid doing that, presumably because they believe it will invite criticism. But the main utility I see in NONAZIs is in how it contextualizes why various racist and phobic belief systems will tend to put those who believe in them at cross purposes to legitimate editorial objectives under our policies. Indeed, I'd say the vast majority of times WP:NONAZIS is linked in a discussion, it is appropriate as a diagnostic term. The problem situations tend to arise mostly at ANI, I think, where parties hoping to secure a sanction against a user (often with very good cause) can be more prone to attempting to use it in a more prescriptive manner than is appropriate, given the context and its role as an essay. SnowRise ^{let's rap} 22:44, 5 March 2026 (UTC)

• Is there any way to make some kind of ruling on how often the same issue can be raised? I know situations change and it wouldn't be appropriate to say something is decided permanently, but just rehashing the same arguments over and over is also a waste of editor time. This is my first time dealing with one and I'm already sick of it. Maybe something along the lines of how requested edits are done, where the editor needs to explain why they think reopening it is justified? ChompyTheGogoat (talk) 22:06, 5 March 2026 (UTC)

  In theory, sure, we can make all sorts of rules. In practice, we don't usually do moratoria like that, so the disruption of people re-proposing the thing would have to be pretty severe for enough people to back a moratorium. At this point for this particular discussion someone could try to WP:SNOW-close it as being extremely unlikely to pass and a waste of time having people arguing over it. But that might be reverted. Anomie⚔ 22:55, 5 March 2026 (UTC)

(edit conflict)Well, there isn't a formal process to addressing that situation per se, but the way it tends to play out is that if a given editor misreads the room and tries to revive a discussion one-too-many times within an unreasonably short period of time, they start to get warnings from their fellow editors, with the prospect of a TBAN not unheard of in the most exceptional cases of inability to WP:DROPTHESTICK. But precisely because of the concern that you point to (the community not wanting to chill discussion or run the risk of being inflexible on revisiting issues), historically there has been a high level of reticence to be too aggressive about shutting down redundant discussions.

In any event, I don't think there is anything needing doing in the instant case: from what I have seen above, the OP seems to have been unaware of, or did not recall the last proposal. To be fair to them, when I pointed out at the ANI thread that this had already been discussed repeatedly in recent years, I intentionally omitted mentioning last year's RfC, because I couldn't recall with any precision how long it had been. Given that string of discussions and now two formal WP:PROPOSALs within a year that each got WP:SNOWBALLed down, I expect the next time the permalinks will come out fast. Beyond that, I don't think anything needs doing. Much as I am opposed to the proposed change, I do think it's reasonable to expect this to be a perennial topic of discussion. SnowRise ^{let's rap} 23:00, 5 March 2026 (UTC)

• WP:DISRUPTIVE is itself a guideline, and these are guides to how non-disruptive editing can be achieved. Phil Bridger (talk) 20:57, 5 March 2026 (UTC)

• Oppose as author. It was written as an explanatory essay about a specific problem we experience here on WP. It is not, and never has been, written as a policy that editors must follow. ᛗᛁᛟᛚᚾᛁᚱPants Tell me all about it. 21:21, 5 March 2026 (UTC)

  Okay, so how should a policy be written? How do we avoid rubbish like WP:BLP? Hawkeye7 (discuss) 23:14, 5 March 2026 (UTC)

  How is BLP trash exactly? (Talk) PHLOGISTON ENTHUSIAST 12:08, 6 March 2026 (UTC)

  How, exactly, is WP:BLP 'rubbish'? ᛗᛁᛟᛚᚾᛁᚱPants Tell me all about it. 13:13, 6 March 2026 (UTC)

• Oppose Wikipedia:Civility, Wikipedia:Neutral point of view, and Wikipedia:Verifiability pretty much covers the problems that a Nazi could cause. Singling out one ideology would open the door to debates about what other ideologies we can blacklist, which would be as much fun as watching a dumpster fire outside a slaughter house down wind from the smoke.

GeogSage ^{(⚔Chat?⚔)} 23:13, 5 March 2026 (UTC)

That might be cool to watch if it was in a horror movie. (Talk) PHLOGISTON ENTHUSIAST 13:40, 6 March 2026 (UTC)

Oppose: One: We already have policies to deal with those problems. Two: A problem with Nazism (or with any sufficiently known hateful ideology) is that discussions will likely fall into Godwin's law terrain if Nazism becomes a blocking reason just by itself. Three: Nazism is an archetypical example, but there are loads of local hateful ideologies all around the world. And worse, not all anti-ideologies and Anti-national sentiments are necessarily hateful (sometimes it's just a feud over a territory or a historical event), so there would be overlap. And four: hate is wrong... in theory. In practice, some people like to dismiss critics as "hateful" in order to ignore valid criticism, or even to completely shield themselves from criticism that way. See Appeal to motive and cancel culture. As with Nazism, if we make a "hate is a good reason to block" policy, we'll have loads of people pointing fingers that this or that is "hateful". Cambalachero (talk) 00:19, 6 March 2026 (UTC)

I believe that anti-national sentiments are hateful and bigoted by definition, regardless of the cause or whether it's understandable. Conversely, hate against an ideology is not directed against an innate characteristic, so while you can argue it's still a form of "hate", I don't see it as the same type of hate that's directed toward people for things like race or gender. My point? The fact that we have these different thoughts on the subject demonstrates the problems with enforcing something like this, and it's not merely a hypothetical disagreement like much of the discussion above. Thebiguglyalien (talk) 00:39, 6 March 2026 (UTC)

Cancel culture is a conservative fantasy born from spending too much time on Twitter dot Com. I don't think this needs to be a policy but let's avoid whataboutism. Simonm223 (talk) 00:49, 6 March 2026 (UTC)

Cancel culture is a new word for an old human behavior. It is essentially the same as boycotting something, or shunning an individual for behavior not in line with the group. There are many examples of people boycotting individuals or organizations they disagree with, on both sides, and it is often referred to as canceling them. The Wikipedia page has a few examples of people criticizing it, but online campaigns against individuals and organizations online are very real phenomena. Calling it a "conservative fantasy" is a bit odd. GeogSage ^{(⚔Chat?⚔)} 05:34, 6 March 2026 (UTC)

Do you have any evidence of this claim? (Talk) PHLOGISTON ENTHUSIAST 12:19, 6 March 2026 (UTC)

• Oppose. Essays are not written in a way that makes them useful as policies, and this is reasonable. The only way to get a policy out of them is to write it from scratch, but then I believe it won't actually have much that is not already covered adequately by existing policies. Zero^talk 05:07, 6 March 2026 (UTC)

Idea lab

Five strikes down to three

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

LLM harm reduction policy

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  Posting some kinds of LLM output (e.g., a couple of sentences of new content) without disclosure would AIUI fall afoul of our local rules against Wikipedia:Plagiarism, but it isn't a copyright or license problem. WhatamIdoing (talk) 07:17, 22 February 2026 (UTC)

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

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

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

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

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

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

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

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

  If morality prevents you from improving or maintaining Wikipedia, ignore it. Cambalachero (talk) 18:13, 24 February 2026 (UTC)

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

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

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

  To quote from there

“ Main concerns

• Edit quality: OKA editors are making large-scale changes that introduce errors and LLM artefacts.

  Overwrites: repeated overwrites of existing articles during LLM-assisted translation which breaks templates/infoboxes, and makes it hard to review because they're not incremental changes.

  Coordinated mass-editing: OKA trackers indicate various planned campaigns for mass changes (e.g. the Simplify lead campaign) affecting large numbers of pages without on-wiki discussion or consensus.

”

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

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

The rate limiting measures could possibly end up creating a Streisand effect to editors who were not planning to use an LLM to generate wiki content. ~2026-11404-95 (talk) 16:47, 24 February 2026 (UTC)

Using a bot to apply Template:New archival link needed to references

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  where step 7 is:

  Remove hopelessly-lost web-only sources

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

References

Preparing for proposal

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

RFC: Automating the deprecation of archive.today

Please answer each of the following questions:

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

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

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

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

better calculation where to suggest on a zero return search.

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

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

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

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

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

Baby Globe Fear

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

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

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

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

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

What I meant was:

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

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

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

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

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

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

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

Pseudocode:

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

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

Trending topics : Robert Carradine and Related to Current events

Robert Carridine in 2004

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Process wikipedia into tree knowledge dependency data structure using AI for human use in MMU RAG chats via api (et cetera)

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

---

Techniques: WCN Transformation, Recursive Clustering & LLM Labeling, Recursive Leiden Partitioning, and SVM; Key Projects: Wikitop, Wiki-Qdrant, STORM, and HLTA; Constraints: Cyclic dependency and semantic drift—Wikipedia should stop "cleaning up llm content" and instead "use llms to clean" its internal structure into dependency trees that explain required knowledge, and link it, for educational efficiency. — Preceding unsigned comment added by ~2026-12576-31 (talk) 21:31, 25 February 2026 (UTC)

I have no idea what this is supposed to be (it reads like MBA vomit), but I can tell you what it isn't: A thoughtful proposal that considers the community's attitudes and priorities and understands the consequences of what it advocates for. —Jéské Couriano v^_^v ^{threads critiques} 21:41, 25 February 2026 (UTC)

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

Limiting Temporary Accounts to Article Edits and Article Talk Pages

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Following talk page only?

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

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

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

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

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

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

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

book reading mode

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

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

Searching by category with a higher depth

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

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

Language redirect idea

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

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

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

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

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

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

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

Thanking for things other than edits.

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

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

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

WMF

Planned short test of mobile banners promoting the Wikipedia app

Hello,

The Wikimedia Foundation’s Communications and Product teams would like to implement a small test on centralized notice banners to encourage more people to download and use the Wikipedia app. It will be a simple banner, targeting logged out mobile users and will run for just a few days, starting on December 15. The goal is to get more people using the app so that they become more engaged with Wikipedia in the long term. This is increasingly important as our Wikipedia traffic is changing, and it is part of our Foundation’s annual plan. If you have any questions or concerns, please let us know. Thank you so much.

--ARamadan-WMF (talk) 18:16, 20 November 2025 (UTC)

Is the rate of app downloads decreasing significantly? We should probably have a specific reason for implementing another advertising banner, as these seem to be somewhat unpopular within the community. ✨ΩmegaMantis✨^blather 02:48, 21 November 2025 (UTC)

@ARamadan-WMF Are you sure that "get[ting] more people using the app [will cause them to] become more engaged with Wikipedia in the long term"?

I prefer web browsing over apps. (I don't understand why, for example, Home Depot even HAS an app. Browsing their inventory and ordering online works perfectly well from a web browser. Similarly, when reading The New York Times online, their web page nags you to use their app. Why? Reading the NYT using a web browser is perfect, in my opinion.)

Reading plus editing Wikipedia on a tablet and also a Windows PC, using a browser, is a great experience for me. I read WP using my phone. I don't generally edit from my phone, but some long-term editors do. Does using the app really drive engagement, and how can you tell? David10244 (talk) 05:06, 21 November 2025 (UTC)

@David10244: Are you sure that "get[ting] more people using the app [will cause them to] become more engaged with Wikipedia in the long term"?: Apparently the Wikipedia mobile app has games that are supposed to keep people engaged now. T400512 says they're going to add even more in the future. Children Will Listen (🐄 talk, 🫘 contribs) 23:23, 23 November 2025 (UTC)

Note most of these new features only come to Android in the first place. Sjoerd de Bruin (talk) 08:39, 24 November 2025 (UTC)

@ChildrenWillListen OK, thanks for that info. (Personally, I dislike games on mobile devices, but of course people do have their own preferences.) Are people really "engaging" with Wikipedia if they are playing games? Even if the games are hosted within the app, time spent playing the games is time not really spent engaging with WP...

Oh well, we don't need to drag this out. David10244 (talk) 07:21, 4 December 2025 (UTC)

Okay. I didn't think it was possible lower my opinion of the Wikipedia app. Yet they have managed it. --User:Khajidha (talk) (contributions) 22:44, 18 February 2026 (UTC)

The mobile app has had games for a while now. Guz13 (talk) 15:50, 24 February 2026 (UTC)

@ARamadan-WMF: I haven't used it in while, but if the app restricts editing or has missing features compared to mobile web (due to underdevelopment) it should make it clear that mobile web is better for that task. Otherwise, you are pushing Wikipedia-lite: a watered down, crappy version of Wikipedia and people will disengage entirely out of frustration. There must be a list of restrictions somewhere (or the app is better in every way?) that you have evaluated before pushing the app with a banner.

@David10244: not that I am a proponent of a Wikipedia app, given the development costs, but apps can have more features compared to the web. From my hazy understanding, apps can:

• allow easier payments (didn't the WMF just announce you can donate from the app using Google/Apple pay?)
• securely store the number page visits locally (the WMF is developing donation banners based on number of views)
• Allow users to upload a photo in a free file format when your phone uses a proprietary format
• Send push notifications to your device (e.g. you have new messages), etc

Commander Keane (talk) 08:36, 21 November 2025 (UTC)

2 isn't planned to my understanding. Sohom (talk) 04:38, 28 November 2025 (UTC)

I don't like mid-thread posting, but here goes...

@Sohom Datta maybe I am confused or didn't explain it well, but on on mediawiki.org: "The apps already locally store and surface the user's reading history" and in relation to the new banner placement widget, "Readers will be able to [...] choose how often they want to be reminded, based on the number of articles they read". Commander Keane (talk) 10:39, 28 November 2025 (UTC)

It is not "securely" stored so much as available due to the nature of such apps, but sure. Sohom (talk) 15:42, 28 November 2025 (UTC)

@Commander Keane Hmmm. I can see some of that, but:

• Payments: You can pay from Web pages. I buy stuff all the time online. Some web pages accept Google Pay and Applepay.
• Web pages could do different donation banners server-side, or with cookies.
• I certainly don't want push notifications, but to each their own...

David10244 (talk) 07:29, 4 December 2025 (UTC)

Ironically, I am leaving this comment using a mobile browser because the app doesn’t allow access to any of these notice boards. ~2025-35367-57 (talk) 14:11, 21 November 2025 (UTC)

I am leaving this comment from the app after the reading comment above. With an account I can manually leave a comment here by editing the wikitext of the whole page. I don't see any "reply" buttons anywhere though.

A streamlined way to upload freely licensed photos would be a great addition to the app and one of the few clear advantages to editing on a phone (while we are apparently trying to get people to download the app). Right now (on Android using the official app), I have to switch over to the Commons app and it's all but clunky. I imagine it's also a more straightforward addition than improving the mobile's editing interface. Rjjiii (ii) (talk) 20:17, 28 November 2025 (UTC)

Maybe the IOS app lags behind in capabilities? I tested logging in and there is no way to navigate to these boards; the Home page simply scrolls endlessly back in time. ~2025-37129-61 (talk) 23:21, 28 November 2025 (UTC)

Ah, okay, then yes they are different. On Android, if you open a new tab it begins on the Main Page. This may be coming to IOS as well, because I think that new tabs only started showing the Main Page this year. Rjjiii (ii) (talk) 05:43, 30 November 2025 (UTC)

@Rjjiii (ii) So the app has lagged behind the functionality of the Web page for many years then, if the Main Page is just now coming to the app! 🙂 David10244 (talk) 07:32, 4 December 2025 (UTC)

@Rjjiii (ii) I would hate not seeing the Reply buttons! David10244 (talk) 07:30, 4 December 2025 (UTC)

Is there a issue on phabricator or a wish about enabling app users to make comments on meta pages like this one? Prototyperspective (talk) 17:36, 8 February 2026 (UTC)

• Aside from the editing issues mentioned above, the app also mostly ignores the main page content which our community has decided to show on any given date. Aside from the featured article, it substitutes its own things without community approval, such as having a Most-viewed article section, using the Commons featured picture of the day instead of our choosen WP:POTD, and replacing our set of anniversary articles with its own OTD that isn't vetted or necessarily on our list. I've no idea who curates that, but I don't think we should be promoting something that fights against the community's editorial decisions. It also sucks in incoming links from browsers, making it more difficult to view the project on the Web even if you want to.  — Amakuru (talk) 07:29, 28 November 2025 (UTC)

  That's terrible, and should be discussed at an RfC at VPP, and then probably removed from the app. I thought the WMF didn't do content and left that to the wikipedia's? At the very least they should be able to tell us how / by whom the sections on the App main page are created, and why they don't use the local ones. I don't have the app so haven't checked this, I do remember the reluctance they had to remove the Wikidata short description from it: I hope any necessary changes this time will be quicker and in a more collaborative spirit. Fram (talk) 09:10, 28 November 2025 (UTC)

  @Amakuru, @Fram It is very hard at a technical level to exactly extract the on-this-days section of the main page in a reliable manner due to it's free flowing nature, as a result to my understanding of what the underlying code is going for a compromise, it is parsing November 28 (today), using the much more standardized format of those pages to serve chronological information from the page. The first OTD entry on the app is "Over seven hundred civilians are massacred by the Ethiopian National Defense Force and Eritrean Army in Aksum, Ethiopia" which corresponds to a community generated entry on November 28. For what it's worth, I don't think there is a conflict with the communities editorial decisions here, the content being shown here is community generated and is prominently linked to in the first link in our OTD section. This is not WMF generated content, it is literally content we have decided is good enough to link from the main page. Sohom (talk) 16:47, 28 November 2025 (UTC)

  There is a huge difference between content linked from the main page, and content shown on the main page. Basically, this gives vandals a clear method to vandalize the main page on the App. Fram (talk) 16:52, 28 November 2025 (UTC)

  I personally don't buy this argument, if content is one click away, people going to the page, through mind you the literal first link on OTD will have a pretty bad impression of Wikipedia anyway. Not to mention that this concern is effectively the same threat model as if somebody where to vandalize a DYK or OTD and the preview of the article showing up on hover on the main page, however, we as a community typically do not fully protect DYKs or OTDs. For what it's worth, I think there are mitigations against this kind of scenarios, in that I think there is aggressive caching and if the code sees a empty page, they will revert to showing a cached version + the app randomizes and caches which entry folks see, and so the chances of a person vandalizing the page and it immediately showing up on the main page are pretty slim. Sohom (talk) 17:03, 28 November 2025 (UTC)

  The clickthrough is minimal compared to the impressions the main page gets though. Vandalizing a linked page will reach a few dozen people or so (assuming the vandalism is up for a few minutes), vandalizing the main page reaches thousands of people in the same timeframe, and is much worse for PR as well. I don't know about the caching and whether that helps (though the "empty page" is a very uncommon type of vandalism). Would probably be best to test this (not with vandalism, but by constructively changing some text which is visible on the App main page, and seeing how long it takes to change on the main page). Fram (talk) 17:23, 28 November 2025 (UTC)

  Hmm, I went to edit November 28, and realized that it seems to be protected under pending changes, that would make it much harder to get vandalism over to the main page for today. (it might be instantaneous for us cause both of us would bypass pending changes). Sohom (talk) 17:57, 28 November 2025 (UTC)

  The incoming link issue has been a particularly pernicious issue for me, the only obvious end-user solution for it is to delete the app which is presumably not what is wanted. CMD (talk) 09:17, 28 November 2025 (UTC)

  I really like some of the app landing page features, and some of the editorial(!) decisions like the POTD and OTD can be refreshing. However, the 17 fair use images shown (I stopped scrolling after a few days worth of feed), often cropped and with no way to tell they do not have a free licence, was disappointing. I am guessing there were 17 fewer fair use images on the Main page during that period.

  I think the app is getting ignored by the community and, for better or worse, pushed by the WMF. Commander Keane (talk) 10:58, 28 November 2025 (UTC)

  It seems that POTD corresponds to c:Commons:Picture_of_the_day. – robertsky (talk) 11:24, 28 November 2025 (UTC)

  I agree the incoming links issue has been one of the reasons I have the app set to never open wikipedia links, and Android somehow still disobeys me sometimes :(. Sohom (talk) 16:52, 28 November 2025 (UTC)

  I tried the app the other day, it is dreadful. How they do the lead image is really strange, and some of the features don’t make sense. The app should be designed with the community, idk what they think they’re doing Kowal2701 (talk) 12:39, 28 November 2025 (UTC)

  @Kowal2701, Please provide actionable feedback, what exactly is "dreadful", why is it so ? What is "strange" about the lead image? Sohom (talk) 16:50, 28 November 2025 (UTC)

  First off it's horrendously impractical for editing, I could list dozens of things but it's very clear it's not intended to be used by editors so I won't waste my time. I deleted it after 10 minutes. Just on the tabs:

  • the Explore tab, I don't understand what they were going for. The Main Page is carefully curated, idk why it wouldn't be kept (the layout is ugly and monochrome as well). For something called Explore, I'd expect them to use Wikipedia:Contents, or propose random topics for people for people to learn about, or whatever. Something that actually lets the reader explore the encyclopedia, ie. where they can navigate themselves rather than getting random articles on Polish towns etc.
  • Places is an interesting idea, but what is its purpose? Is it for Americans to learn geography? Why is it only limited to settlements, administrative divisions, and landmarks? Why are administrative divisions presented as a point? Could it be tied into country outlines (eg. Outline of Myanmar)?
  • The others, sure they make sense, I wouldn't really use them or find them helpful other than "Search"

  On the app, it just isn't a wiki anymore. I can't edit any of the tabs. I don't like the personalisation. The lead image appears as a banner at the top, and the infobox is collapsed under "Quick facts". It boggles my mind that the team working on this thinks they can redesign everything without community consensus, especially when it's done so poorly. The website is brilliant, just copy that over and maybe add a couple more features for exploring, that's all that needs to be done. It being awful for editing also means we'll get less new editors, which is what we really need to have begging banners for. A "reader" version and an "editor" version that people can switch between might make more people aware of their ability to edit and make it more accessible so they try it out. This being said, the idea of prioritising the app is great, it bypasses Google's LLMs, but the execution and process was very poor. Kowal2701 (talk) 17:23, 28 November 2025 (UTC)

  I've been somewhat involved in discussions related to the Android app so I can give you the high-level "why" of the design choices. Back in the day of Vector, when the app was first created our UI, infoboxes, image placement, warnings and even our main page sucked on mobile, taking up often more space than was available on mobile. As a result, the team at the foundation had to make certain optimizations/tradeoffs (like hiding the infobox, lifting the lead image etc), and changes to the layout of a variety of elements to get it to work on mobile. Since then, there has been significant improvement in our ability to serve mobile-first content, particularly due to collaborations between technical editors and WMF teams to overhaul and improve Wikipedia's templates and user interfaces to be mobile oriented. There is still a significant amount of work to be done before we can get to your standard of "hey they could just put the website into the app" and for folks to be happy with it (not to mention that even then, a significant amount of engineering will be required to replicate mobile-web-only features using Java code).

  To a few of the more specific points, the explore tab was developed to copy the essential features of the current main page back when showing the main page wasn't a option, similarly, the way the "places" feature works is that it uses your geolocation to find articles close to you, unfortunately, we only use coordinates in administrative divisions and such, limiting the feature. To the point of using outlines, our outlines are free flowing and outside of using a LLM, there is not a lot of ways to extract structured data that can be used to augment this features through outlines. I can see a situation where we use Wikidata to augment some of this data, but such uses have been frowned upon by the community back in the day (see also short description), which is why I think the app avoids it Sohom (talk) 17:52, 28 November 2025 (UTC)

  To that point, @ARamadan-WMF, is there a place we can leave feedback on the design of the Android app? Sohom (talk) 17:59, 28 November 2025 (UTC)

  Thank you. The technical aspects are beyond me, I just find the website on mobile pretty good all considering (on iOS btw). I can understand some of the design changes like collapsing the infobox, I just wish things like this were run past the community, like in batches. This project operates by consensus. I'm sure WMFers see it as given that some in the community are going to rage against anything they do, but involving the community at earlier stages would negate a lot of that. Kowal2701 (talk) 18:19, 28 November 2025 (UTC)

  I installed the App. It gave me Dutch as default language, but allowed me to another language. But after adding English, the app hecame quite a mess with the two languages mixed. I thought I would get some switch to see enwiki only or nlwiki only, but no, I got something unwanted. I have removed it again, as it also interfered with my standard Wikipedia editing on the phone here. Not a fan... Fram (talk) 19:10, 28 November 2025 (UTC)

  Eh no I agree, the "using different languages" thing is weird for me as well. It's always given me English though, maybe it picks the language based on location now ? Sohom (talk) 19:44, 28 November 2025 (UTC)

  I got Lao, Italian, and Arabic IIRC Kowal2701 (talk) 19:57, 28 November 2025 (UTC)

  @Sohom Datta I know this is a few weeks old, but... Why do we have a Wikipedia app at all? The effort devoted to creating such an app could have been used to improve the layout on smaller screens, as you mention.

  I wonder why many apps exist today. Why does Home Depot, or Wal-Mart, for example, even have an app? Their web sites work fine on mobile and tablets.

  What does the Wikipedia app do for us? David10244 (talk) 23:07, 19 January 2026 (UTC)

  Having an app makes it easier to track users, push ads and take payments. Those features are of interest to commercial companies, and presumably to the WMF, but are not goals of Wikipedia. To lure users in also requires some content. That content is taken from Wikipedia but this piece of software is a WMF app, not a Wikipedia app. Promotion for it is no more welcome than the annual begging banners. Certes (talk) 18:30, 8 February 2026 (UTC)

  Well for one, the talk page button isn’t easily accessible while reading a page, you have to click the “more items” ellipses to find it. Worse, the “learn more about this page” link appears as broken HTML, making it vastly less likely for app users to click in and read it. There’s no ability to access category pages, and the notice boards are completely walled off from the IOS app. ~2025-37100-27 (talk) 23:43, 28 November 2025 (UTC)

  No VisualEditor (and the joys of visual citation insertion, etc), no access to Help desk/Teahouse (without pushing you to the web on Android, ~2025-37100-27 suggest zero access on iOS). Not suitable for new editors. Not suitable for experienced editors. There are more limitations.

  I thought the app was just a bit of fluff that the WMF was going to half-develop because cash was slushing around. Without VisualEditor (a 13 year regression) and Noticeboards (a 21 year regression) it is. Minor landing page issues, as discussed above, are not my major concern. If the WMF intends to make the app equivalent to mobile web then I am on board. I will test, and file bugs/features 'till the cows come home. We all could.

  If it going to remain dreadful, then I would like to keep editors on mobile web (and lets face it, mobile desktop), or push them away from the app ASAP. This would not involve a mobile banner promoting the app. I do think the reading experience is superior on the app. But people read Wikipedia because those before them have edited to create that content. Appealing to financial reasoning: over time, you will get less and less donations with less and less editors. Commander Keane (talk) 01:04, 29 November 2025 (UTC)

  In the iOS app, talk pages are often difficult to get to. But what’s much worse is that it appears impossible to reach an article from its associated talk page. MichaelMaggs (talk) 09:25, 14 January 2026 (UTC)

  The most-viewed articles section is one of the only interesting engaging parts of the app so I strongly disagree with what you said. Regarding POTD, I thought it would show the picture selected by Wikipedia but also note that WMF doesn't even develop a Commons app so the project being in the disadvantage and not cared about here is Commons, not Wikipedia. At least now the main page is linked from the main feed; I wished it was integrated into it better and if you'd like to see that I suggest you at least create issues and/or wishes about that instead of complaining here in this format. Prototyperspective (talk) 17:31, 8 February 2026 (UTC)

To you and everyone else at the WMF: Stop trying to make Wikipedia popular. Focus on making it good. We aren't here to make money, or gain users, or have power. We're here to make a good encyclopedia with a strong set of moral principles. The WMFs recent actions do not seem to reflect this goal, instead believing that more users equals a better encyclopedia when it is the other way around mgjertson (talk) (contribs) 19:15, 26 January 2026 (UTC)

Strongly disagree working on making it good is what Wikipedia editors do, WMF can and should do some things that can make Wikipedia substantially more popular and since technical development is needed for such, only they really can. I very much oppose people who want to keep Wikipedia down. I would hope such calls would be coming from Chinese officials and Trump-lovers only but there's one thing a vocal minority can do pretty well and that's shooting ourselves in the food without much thought whenever there's a chance. Prototyperspective (talk) 17:34, 8 February 2026 (UTC)

I think it's a good idea. Still only a small fraction of users (or of mobile users) are using the mobile app. Many things are possible only with a dedicated native app as opposed to web app of sth people open in the browser (usually by first typing the subject into a search engine). One of the biggest advantages I see in the mobile app is the Places map which allows me to see a map of nearby places with Wikipedia articles. I'm for example using it when discovering a new city. However, there is little attention paid to whether this functionality is useful much in real-world practice: the main functionality is there now but you didn't go the last mile to enable users to filter out mundane articles to their liking so that the map mostly shows truly interesting notable places (or for whatever things relating to whatever other application one is using this for). W295: See Filters for types of items shown on the Wikipedia app Nearby places map.

-

In quite a similar way, the Discover feed is a great concept and has lots of potential but then the only truly somewhat interesting content in it is Most viewed articles (society is mostly interested in things that isn't quite that interesting but it's interesting to stay up to date on what people are interested in / reading on WP), In the news (new items are added only very rarely; see here), and recommended articles (just a small bunch relating to just 1 article). The low-hanging fruit there is to simply allow users to also see recommended articles also for other articles, not just one. Maybe some the user selected for selected interests or just other articles one has read. phab:T416796 To me it seems like you're working on functionality to just complete the addition of a functionality but not thinking it through how it would be used – having just 1 set of recommended articles means it's relatively unlikely I'm interested in that particular set. So for some features, the more difficult part has already been built but you didn't maximize out the potential and not just that, you often made it so abbreviated it's no wonder people don't use/like it because in that format, it's not yet useful and more like just a demo. Prototyperspective (talk) 17:55, 8 February 2026 (UTC)

I use the iOS App daily and also use the mobile and desktop views on my phone too. And I use the desktop mode on a larger monitor too. I find all of these different views useful in their own way. It's good to encourage our readers to understand and experiment with these as they will have have their own needs and preferences. Andrew🐉(talk) 21:38, 12 February 2026 (UTC)

Hi all, thank you for the thoughtful questions and concerns raised here. My name is Jaz, and I am the Lead Product Manager for the Mobile Apps Team.

The banner is intended to be a time-limited test that would only be shown to logged-out mobile readers on Japanese Wikipedia (in Japan) December 15-16 and English Wikipedia (in South Africa and India) December 15-18. The purpose is to understand whether a simple banner can help raise awareness that the Wikipedia app exists, especially among new readers, and if those readers retain at the same rate as readers that discover the app organically through the app stores.

Why do we want to drive more traffic to the apps?

Our broader goal is to help new and existing readers return to Wikipedia because they find it a compelling place to learn. To address this we want to experiment with ways that help new generations of readers find Wikipedia useful, return frequently and eventually become the editors we need to keep the projects healthy.

There are two shifts in reader behavior that are driving this:

• The number of people visiting Wikipedia, and the ways that they visit, have been changing for several years, with fewer people arriving to the site through external search engines.
• Based on our existing data, we know that readers on the apps return more frequently and engage more while they are reading than readers on the mobile web, thanks in part to built-in platform features. Readers who install the app tend to come back more often and explore more content directly on the platform. However, install rates are stagnant and primarily come through organic searches in the app store.

In short: We think that having people come to us through a platform we control, instead of mostly through search where we have no way to ensure we remain as visible as we have been, is key to remaining a vital, viable movement. This is a small test to see if this could be one way of helping that.

Because long-term sustainability depends on new readers returning and eventually becoming editors, as outlined in the Wikimedia Foundation’s annual plan and the Readers work, we want to connect people with the reading environment where they are most likely to stay engaged. For new generations there is a higher tendency to rely more on mobile apps and personalized experiences when learning online.

The difference between apps and mobile web

Several people raised very valid concerns about the apps not fully matching mobile web functionality. This is correct, and we want Web to remain the primary environment for editing workflows that are not supported, or are less than ideal, in the app. For users interested in editing on the apps, we will ensure that easy and intuitive ways to transfer over to the web are available: We want readers to be able to easily use the apps for all the things the apps do well, and lead editors to the web for editing. If you are interested in efforts to improve mobile web editing you can read more here.

On the apps, we want to focus on the needs of readers who prefer mobile-native experiences and are accustomed to personalization, like enabling readers to pick topics they want to see more, showing them trends in their reading patterns or notifying them if they haven’t met a reading goal. This shift allows the apps to focus on what they are uniquely good at, including reading on the go, offline capabilities, personalization that respects privacy, push notifications, and other mechanisms like widgets that help readers return more consistently.

New capabilities we’re exploring on the apps

Explore feed

You are right that the Explore Feed could use an upgrade. We want it to be easy for people to discover content of interest when they are browsing. We have plans to revamp the Explore Feed in May to address some of the gaps that have been raised (for example, surfacing content across wikis in more useful ways). There will be outreach to shape the new explore feed in late January, in the meantime, consider signing up for the app's newsletter so you can receive updates directly on your talk page.

WikiTrivia game

It is also understandable to have curiosity as to why features like the WikiTrivia game exist. With the challenge of readers coming to Wikipedia for a single question and leaving, simple, low-effort interactions can help people discover articles they might not have found otherwise, which in turn can lead to them to read more and return more often.

WikiTrivia is one example of this and actually leverages the On This Day page curated by the community. It gives readers an enjoyable way to discover articles that they can then read, save, or share. We have received positive feedback and requests for more games through in-app feedback forms, our support emails, project pages, press and play store reviews. Based on the positive feedback and data from Android, we plan to bring it to iOS as well in 2026.

Why do some features vary by platform?

I see there is a question of why some features are on one platform but not another. The way our team works is to see if a feature performs well on one platform before bringing it to the other so we are being thoughtful about where we put our time and energy and not scaling features that do not work or aren’t desired. Tabs is a recent example of a feature that was originally released on Android and highly requested by iOS app users, so we prioritized releasing it there recently. You can see a similar approach to Year-in-Review which was only available on iOS last year but is currently available on both platforms this year, with improvements based on feedback the team received.

How can you get involved?

We welcome ongoing feedback about the apps, especially from editors who use them or want to use them more effectively. App development is shaped by community input through Village Pump discussions, project pages, the support email channel, and app reviews. You can leave feedback at any time on our discussion page and stay informed by subscribing to the app newsletter. I’ve tried to respond to all of the great feedback here, but will also take a pass at individual comments again and will respond inline if I missed something over the next few days.

Ultimately our goal is to run this test thoughtfully, learn if it increases retained installs, and discuss the results with you all to determine if efforts like these could support the overall health of Wikipedia’s reader and editor ecosystem. If the apps are not personally your preferred platform or you do not have strong opinions about their direction, that is okay, we understand we have a diverse community with diverse preferences and interests, that’s what makes it so great. The web teams also regularly welcomes feedback on how to improve the mobile and desktop web experiences for readers and editors.

But the key thing is this: The internet is changing and fewer readers are finding their way to Wikipedia, or come less often, because search traffic doesn’t work the way it did in 2003 or 2014 or even 2021. This means we have less chances of making more people edit. We want to find ways to make it easier for readers to return to our articles. This is a small, limited experiment to see if this can help readers return. If we can make readers come to our own platform, and return, then we can send them to the mobile web for editing, keeping our ecosystem healthy. JTanner (WMF) (talk) 20:21, 2 December 2025 (UTC)

Thank you. Is there anything on the app that pushes/nudges people into editing on the website? Another concern is that a lot of people make their first edits by correcting spelling errors etc. while reading, if the app is cumbersome for editing it'll drive away would-be-editors and would mean people who get into 'full-on' editing slowly and gradually are lost since it's a big step to visit the website purely to edit. Could the 'edit' button on the app redirect to the web? Kowal2701 (talk) 20:55, 2 December 2025 (UTC)

Hi @Kowal2701, thank you for this question. You’re right that many people make their first edits while reading, and we don’t want the app to make that harder. Some experienced editors have told us they want to be able to make small, quick edits directly in the app using wikitext, while others prefer to be redirected to the mobile web and use VisualEditor. We want to strike the right balance so both groups are supported and are able to execute handoffs seamlessly between platforms. A part of us exploring this problem space is also determining the best approach and timing for sending new editors to mobile web. We want to provide a good user experience.

From a technical standpoint, the app currently sends people to the web for certain workflows, so redirecting the edit button when it’s the preferred experience is absolutely possible. At the moment we are gathering existing research on this topic, and early next year we’ll reach out to request feedback. I’ll make sure you’re notified so you can participate in shaping the path forward. In the meantime you’re welcome to subscribe to the related Phabricator task where you'll get automatic updates via email and can weigh in along the way. JTanner (WMF) (talk) 22:50, 2 December 2025 (UTC)

Hi @OmegaMantis, @ChildrenWillListen, @Sjoerddebruin, @Sohom Datta, @Commander Keane, @Rjjiii (ii) tagging to ensure you were able to see my reply. Looking forward to talking with you more. JTanner (WMF) (talk) 23:05, 2 December 2025 (UTC)

Thanks for the ping. So the app is a reading companion (with fringe benefits like push notifications). That is fine. As I said above, the reading experience is better than browser and I can see the WMF's motivation. Maybe I will end up using the app for reading Wikipedia too :-).

Ideas to evolve readers to editors:

• phab:T409603 (as mentioned above) is a priority - put a VisualEditor browser link at the top of the wikitext edit box, and a link back to the app once the edit is completed. As mentioned, the wikitext editor is for experienced editors but it is probably a good idea to show the wikitext when they hit the pencil for responsiveness and so they know that Wikipedia can be edited by them - and after the shock of seeing 2025 wikitext they can retreat to the palatable VE. Or maybe they will give it a go in the app.
• There absolutely needs to be a link to a help page, with the forums (on browser, DiscussionTools is essential) and editing documentation. Whether that is Help:Contents or a newly tailored page I don't know.
• Somehow, each article's talk page (and what it is for) needs to be easier to find than right at the bottom. Possibly at the top of the collapsed right side bar. I know years ago got the community rejected the software feature for people to report errors and it got removed, but new editors are hesitant to make changes and more likely to ask on a talk page.
• Allow users to curate the content in games. After they play, have a "write your own question" link. I have always wanted games for Wikimedia projects, and they are wikis after all. The user supplied content system does not need to be sophisticated.
• Given the editing limitations on the app, the community could leave a talk page message for anyone that has edited using the app and not progressed to browser and let them know about browser and its advantages. And how to disable the OS deeplinking (app launching when clicking a link), that is mentioned above.
• Put the tagline "the free encyclopedia that anyone can edit" on the landing page. Given the fall in Main page views, I thought it would disappear forever. Anecdotally, the idea that anyone can edit and everyone is a volunteer has never been effectively conveyed.
• I am not sure how the new user on-boarding works with the app, but I assume we get them to mobile web efficiently somehow for the dashboard, mentorship etc.

Commander Keane (talk) 11:05, 4 December 2025 (UTC)

@Commander Keane, hey I meant to reply to this and totally forgot. You wrote, "Allow users to curate the content in games. After they play, have a "write your own question" link. I have always wanted games for Wikimedia projects, and they are wikis after all. The user supplied content system does not need to be sophisticated." They are sort of doing this. Those dates are pulled from Wikipedia:Selected anniversaries. That builds on the scrutiny that all main page sections get for fact-checking and spam-checking. I don't know to what extent it would be good to encourage this, but there might be a way to direct people to that project where they could suggest dates? I believe the WMF's short videos did something similar by leveraging DYK hook facts. Rjjⁱⁱⁱ (talk) 18:25, 13 January 2026 (UTC)

Thanks Rjjiii. I did read somewhere that is where they pull the questions from, I didn't expect them to write the questions themselves, or hire a consultant ;-). I played the guess which event happened first and the questions were robotic, mundane, and the difficultly didn’t ramp up (they were really hard to begin with!). A timer, search box and time penalties for hints would add elements of risk and adventure. It seems to be a trend of WMF development that doesn't lean on Wikimedian (human) involvement: the games, the short videos, the current Semantic Search discussion I see you at. Commander Keane (talk) 06:14, 14 January 2026 (UTC)

Yeah, perhaps an unfair comparison, but Microsoft Encarata's "Mind Maze" let you pick a topic and ramped up in difficulty. I am both hopeful and skeptical about these projects getting more readers and therefore more editors, Rjjⁱⁱⁱ (talk) 06:19, 14 January 2026 (UTC)

I used to love Mind Maze! And the small set of words spoken in various languages. I also don't know if games would be worthwhile long term, but I know they will not be good in their current state and approach. I will add there is no need for games to be app-only. Commander Keane (talk) 06:40, 14 January 2026 (UTC)

@JTanner (WMF), hey sorry for the late reply. (This is my main account; I'm Rjjiii (ii) above on mobile.) I get why the app is valuable and wish you all luck with it. I want to address a specific part of your message because I think it overlooks something: "Several people raised very valid concerns about the apps not fully matching mobile web functionality. This is correct, and we want Web to remain the primary environment for editing workflows that are not supported, or are less than ideal, in the app. For users interested in editing on the apps, we will ensure that easy and intuitive ways to transfer over to the web are available: We want readers to be able to easily use the apps for all the things the apps do well, and lead editors to the web for editing."

One problem with that is that for whatever reasons right now, the mobile app does not render articles the same as the desktop or mobile web versions of Wikipedia. @Kowal2701 wrote above, 'The lead image appears as a banner at the top, and the infobox is collapsed under "Quick facts".' I get the explanation on why this might have been done, but so long as the rendering is different, it's going to result in content that does not look right on the mobile app. Here is a concrete example:

Some images are diagrams:

Diagrams are one case where an editor making decisions is going to be taking into consideration (most likely) the desktop environment first as it is where most people edit, and the mobile web environment second as it is now the main place where people read Wikipedia articles. There are a lot of articles where a diagram makes even more sense as a way to explain the topic than these welding ones. Take the citric acid cycle, which has a great diagram that makes no sense for the mobile app's top image.

This is not the only difference in content choices, but it's one that often sticks out to me when I check things on the mobile app. Take for example, 3 welding articles: Shielded metal arc welding, Oxy–fuel welding and cutting, and Flux-cored arc welding. Their lead images are respectively a photograph, a diagram with embedded text, and a labelled diagram with text in the caption. The photo works great on the app, and the SMAW article has its diagrams in a body section. The two diagram lead images both look a bit weird when the diagram is blown up as the top image. The labelled diagram is better for accessibility, but becomes almost meaningless as the top image.

It's even worse in the cases where a complex diagram and an infobox both make a good introduction to the topic. In the featured article, electron, which is a topic inherently too small to photograph, there is a great diagram of orbitals with a caption explaining in accessible plain text in the infobox. For the mobile app, a reader is shown half the diagram in the top image and the explanation is hidden away in the collapsed infobox.

→ TL;DR

Regardless of the reasons why the mobile app is rendering differently, it's going to result in the mobile app often delivering suboptimal or even broken content to readers who are editing on mobile web or desktop and therefore testing on mobile web or desktop Rjjⁱⁱⁱ (talk) 18:41, 2 January 2026 (UTC)

@JTanner (WMF) How does an app help people "return" to Wikipedia in any way that a browser bookmark would not? David10244 (talk) 23:09, 19 January 2026 (UTC)

@David10244 (I am not JTanner): in a browser, a websearch is forced down your throat. Every time I open my a browser I see a tantalising Google search bar, why should I choose to click a Wikipedia bookmark? Google summarises Wikipedia's information without making you visit and offers to sell you something all at the same time! (This is sarcasm). The app can also personalise your feed based on previous reading habits, should be smoother for loading and can send you notifications - a sure reason to return. On a mobile device, which includes most readers, hopefully they will launch the Wikipedia app rather than their browser. Having said all that, the app ignores editing in favour of reading. Also, Wikipedia's search is bad and Wikipedia poorly presents information to answer questions. Commander Keane (talk) 00:59, 20 January 2026 (UTC)

@Commander Keane Hmmm. OK, I see how that might apply to some people... I am not sure why, but I don't like most apps (even though I use them). I said elsewhere that Web sites like Home Depot or Best Buy are perfectly fine for me in a browser, even on my phone, and I find that Home Depot's app (in particular) is slow and badly designed. These companies don't need an app, IMO!

I generally read and edit Wikipedia on a tablet. I can't imagine trying to read OR edit on a phone, although I know that some people do.

Not to discount your answer, and I appreciate it, but for me: My reading habits are pretty random; loading pages is fine (perfectly smooth) on my Android tablet and on my Windows 11 PC; and I get notifications in either place. I think that phone users get notifications now too, and that was a big problem for a long time.

I often do a Web search for topics, knowing that a result from WP will be near the top. I'll read that and/or click on some of the other search results. (When I read WP articles, I get sucked in to editing, then I'll go read VPT, or some Phabricator tickets, or the Help desk questions for fun.)

Thanks! David10244 (talk) 05:31, 22 January 2026 (UTC)

I don't even have bookmarks in Firefox Focus nor do I want or need them. Also one has neat Wikipedia-specific bookmarks and open tabs just for Wikipedia instead of in between lots of other tabs. There's also additional reasons...for example I find native apps much sleeker, faster and comfortable to use than mobile browsers. Prototyperspective (talk) 17:41, 8 February 2026 (UTC)

Blind People

Blind People

• https://phabricator.wikimedia.org/T6845
• https://www.mediawiki.org/wiki/Product_Safety_and_Integrity/Anti-abuse_signals/hCaptcha
• https://www.mediawiki.org/wiki/Talk:Product_Safety_and_Integrity/Anti-abuse_signals/hCaptcha#Blind_users
• https://upload.wikimedia.org/wikipedia/commons/5/5e/Let%27s_Raise_the_Roof_-_A_Social_Model_of_Disability_-_a_Welsh_Government_video_-_2021.webm

--Guy Macon (talk) 04:58, 3 February 2026 (UTC)

https://upload.wikimedia.org/wikipedia/commons/5/5e/Let%27s_Raise_the_Roof_-_A_Social_Model_of_Disability_-_a_Welsh_Government_video_-_2021.webm

I mean, I get the point of the video (and it's a good message), but it's not the best example. Why can't Sam sit in a wheelchair, why does he need a non-wheeled chair? Why is everything in braille? Are the wheelchair users all blind? Someone didn't think the video through... TurboSuperA+_[talk] 07:54, 15 February 2026 (UTC)

Do we have any sort of working group of existing blind editors? We should ask them for feedback. Guz13 (talk) 15:51, 24 February 2026 (UTC)

To scrape data from Wikipedia, do you need to go through Wikipedia Business

Just wondering. ~2026-82871-0 (talk) 00:59, 7 February 2026 (UTC)

This isn't really answerable without a lot more context, but I think the answer is "no". * Pppery * _{it has begun...} 02:20, 7 February 2026 (UTC)

From a Foundation article from November: "Financial support means that most AI developers should properly access Wikipedia’s content through the Wikimedia Enterprise platform. Developed by the Wikimedia Foundation, this paid-for opt-in product allows companies to use Wikipedia content at scale and sustainably without severely taxing Wikipedia’s servers, while also enabling them to support our nonprofit mission."

I would try looking at Wikimedia Enterprise. From what I am getting from this TechCrunch article, I think it might be what you are looking for or in the right direction. --Super Goku V (talk) 02:34, 7 February 2026 (UTC)

How much data and how frequently? Aaron Liu (talk) 16:49, 8 February 2026 (UTC)

You don't need to as long as you comply with Wikipedia's content licence, but if you are copying a lot of data it would probably be better (for both you and Wikipedia) to. Phil Bridger (talk) 17:01, 8 February 2026 (UTC)

Considering that our API is free for most small usecases and we freely provide dumps for everyone to use, no? Wikimedia Enterprise is if you usecase meets the brief "if I do this, I will cause production outages" Sohom (talk) 18:37, 8 February 2026 (UTC)

See WP:Database download for an overview of ways to get at our data. —Cryptic 21:16, 8 February 2026 (UTC)

Hi @~2026-82871-0,

Yes as other people have said here - it depends on "how much" or "how fast" you want... There are various APIs and database dumps that exist. Here's the User-Agent Policy and API Usage Guidelines for starters.

You can also access and download content via the enterprise API service directly, at no cost, up to a fairly high limit. That same dataset is also available via several alternative methods including WikimediaCloudServices and external platforms. For information on those options see meta:Wikimedia_Enterprise#Access.

LWyatt (WMF) (talk) 14:59, 16 February 2026 (UTC)

There are even companies that will put all of Wikipedia on a hard drive and ship it to you for a fee. See prepperdisk.com (don't know if they are any good - I just picked the first one duckduckgo listed). --Guy Macon (talk) 15:22, 16 February 2026 (UTC)

https://what-if.xkcd.com/31/ RoySmith (talk) 16:24, 24 February 2026 (UTC)

Wikimedia Foundation Bulletin 2026 Issue 3

Here is a quick overview of highlights from the Wikimedia Foundation since our last issue on January 30. Please help translate.

---

Highlights

• Wikipedia Library: Wikipedia Library gained new content partnerships, restored access to the British Newspaper Archive, and added an Arabic language academic resource with more than 7 million records.
• Gender gap: The Celebrate Women 2026 campaign will run from March 1–31 to advance the achievements of the women’s rights and gender equity movement globally.
• Annual Planning: The Annual Plan is the Wikimedia Foundation’s description of what we hope to achieve in the coming year. We invite you to shape this plan together with us. Between now and the end of June 2026, we will have continuous conversations about how global trends may shape our future, how we can experiment, adapt and respond together.

Annual Goals Progress on Infrastructure
See also newsletters: Wikimedia Apps · Growth · Product Safety and Integrity · Readers · Research · Wikifunctions & Abstract Wikipedia · Tech News · Language and Internationalization · other newsletters on MediaWiki.org

• Patrolling improvements: A new feature available on Special:Contributions shows temporary accounts that are likely operated by the same person, and so makes patrolling less time-consuming.
• Wikifunctions: How Abstract Wikipedia articles can be integrated into Wikipedia language editions to enable Wikipedians to write an abstract article once and have it available in many languages.
• Suggestion Mode: A new Beta Feature for the VisualEditor, Suggestion Mode, is now available on English Wikipedia for experienced editors. This features proactively suggests actions that people can consider taking to improve Wikipedia articles, such as "add citation", "improve tone", or "fix an ambiguous link".
• WDQS Blazegraph Migration: As part of the migration away from Blazegraph (the current backend of the Wikidata Query Service), an initial evaluation of open-source triple store candidates has been completed. Using the published evaluation methodology, performance, stability, and compatibility was assessed.
• Tech News: Latest updates from Tech News week 06 and 07 include the new Watchlist labels feature that allows logged-in contributors to organise and filter watched pages in ways that improve their workflows. They also link to the 44 community submitted tasks that were resolved over the last two weeks.

Annual Goals Progress on Volunteer Support
See also blogs: Global Advocacy blog · Global Advocacy Newsletter · Policy blog · WikiLearn News · The Wikipedia Library · list of movement events

• Funding Principles: The interim Global Resource Distribution Committee (GRDC) has published a first version of the Funding Principles which guides the broader grantmaking ecosystem across the Wikimedia Movement. Share your feedback in the Discussion page.
• Wikipedia 25: Celebrating 25 years of Wikipedia in Warsaw.
• Responsible AI: Why the Global Index on Responsible AI matters for Wikimedians.
• Open Knowledge: Why the Open Knowledge Movement and Public Interest Journalism must unite forces. Shared principles and interdependence, points of convergence and the path forward.
• Journalism Awards: Applications for the Open the Knowledge Journalism Awards are now open until March 1. Presented by the International Center for Journalists in partnership with the Wikimedia Foundation, the awards seek to recognize African journalists whose reporting helps close knowledge gaps about Africa on Wikipedia.
• UN General Assembly: Wikimedia Foundation was invited to speak at the UN General Assembly (UNGA) hall about Wikipedia’s role in global digital governance.
• Advocacy: Wikimedia Foundation has adopted new and updated policies regarding the use of banners, logo changes, and blackouts on the projects, particularly for advocacy purposes. Specifically, the new "Use of Wikimedia sites for advocacy purposes" policy, and updates to the guidelines for CentralNotice usage and requesting wiki configuration changes. The policies establish clearer processes for advocacy activities, and require notification of Foundation staff for some proposed uses of the Wikimedia sites.

Annual Goals Progress on Effectiveness
See also: Progress on the annual plan

• Wikimedia Futures Lab: Reflections from a Wikimedian who attended the Wikimedia Futures Lab.

Other Movement curated newsletters & news
See also: Diff blog · Goings-on · Planet Wikimedia · Signpost (en) · Kurier (de) · Actualités du Wiktionnaire (fr) · Regards sur l’actualité de la Wikimedia (fr) · Wikimag (fr) · Education · GLAM · Milestones · Wikidata · Central and Eastern Europe · other newsletters

Subscribe or unsubscribe · Help translate

For information about the Bulletin and to read previous editions, see the project page on Meta-Wiki. Let foundationbulletinwikimedia.org know if you have any feedback or suggestions for improvement!

MediaWiki message delivery 23:26, 17 February 2026 (UTC)

Error in above announcement

Re: "The Annual Plan is the Wikimedia Foundation’s description of what we hope to achieve...", the link to "Annual Plan" returns "This page doesn't currently exist". --Guy Macon (talk) 02:35, 18 February 2026 (UTC)

Fixed. Typically when there's an error in a link and the link has a slash at the end, removing the slash fixes the error (MediaWiki interpreting the slash as part of the page name). FWIW @whomever this concerns, it would be good to have a person's name in the signature of this bulletin, so we can ping someone in particular if there's an error. I just went to do a courtesy ping since I edited it, but don't know who I'd ping. — Rhododendrites ^talk \\ 18:07, 18 February 2026 (UTC)

The wikitext says:

<bdi lang="en" dir="ltr">[[User:MediaWiki message delivery|MediaWiki message delivery]]</bdi> 23:26, 17 February 2026 (UTC) <!-- Message sent by User:RAdimer-WMF@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Wikimedia_Foundation_Bulletin&oldid=30053915 -->

That URL isn't very helpful if you want to find the author. If you know where to look, "User:RAdimer-WMF@metawiki" eventually leads you to https://meta.wikimedia.org/wiki/User_talk:RAdimer-WMF but a straightforward signature is better than decoding a comment in the wikitext. --Guy Macon (talk) 23:01, 18 February 2026 (UTC)

AI agents are coming - what's the current state of protection?

This feels like something that must've come up already, but I'm not seeing it. As many interventions likely require WMF involvement, I'm putting it here.

With the sudden popularity of e.g. OpenClaw, AI agents are becoming more popular, and stand to be radically disruptive to our project (omitting potential applications for the time being, to avoid compiling a playbook). I'm curious what the current plans are to deal with an influx of agents.

Seems to me there are interventions that would intercept a large number of unsophisticated agent users, like using clues in the user agent (the web kind, not to be confused with AI agent). Then the question is about people who take steps to be sneakier. Rapid edits can be dealt with by captchas (assuming the captchas are hard enough). We could take action against data center IPs, but that would probably snag some humans as well (and pushing agents to residential IPs makes them more costly but not impossible to use). Then there are the various imperfect LLM output detection tools, of course.

Apologies if this discussion is already taking place somewhere - happy to receive a pointer link. — Rhododendrites ^talk \\ 15:51, 14 February 2026 (UTC)

But can AI agents press edit or even be able to navigate around the editing method? ~2026-68406-1 (talk) 16:50, 14 February 2026 (UTC)

You can edit Wikipedia through the API without using the front-end web interface. That's how bots, tools, etc. make edits. Both use the same process on the back-end, more or less, as I understand it. — Rhododendrites ^talk \\ 21:10, 14 February 2026 (UTC)

They have been shown to send emails on their own accord by navigating the Gmail interface, so I bet they would be able to edit Wikipedia as well (though I don't know about the CAPTCHA). OutsideNormality (talk) 06:02, 15 February 2026 (UTC)

I had a small moment of panic about agentic browsers in December and the consensus seemed to be that it wasn't time yet, but now the OpenClaw-enabled crabby-rathbun/matplotlib incident has me worried again. ClaudineChionh (she/her · talk · email · global) 07:13, 15 February 2026 (UTC)

That's either (1) a human pretending to be an agent or (2) a human prompting their agent to write a hit piece. SuperPianoMan9167 (talk) 18:19, 16 February 2026 (UTC)

Notified: Wikipedia talk:WikiProject AI Cleanup. ClaudineChionh (she/her · talk · email · global) 07:21, 15 February 2026 (UTC)

It would be interesting to encounter AI agents that you could try breaking their instruction prompts and have them dox their creator. That would be fun to attempt. There's so many good guides out there on how to destroy AI agents (under the guise of preventing such actions, but it's still informative on how to do it purposefully). Silverseren^C 07:29, 15 February 2026 (UTC)

i hope that the doxxing is said in jest and not an encouragement to do so. – robertsky (talk) 13:47, 15 February 2026 (UTC)

It was in jest, though also somewhat uncontrollable? There's been multiple instances of AI agents doing it spontaneously or with minimal prodding, giving up either personal details if they somehow have them or just account and password info, IP address and computer info, ect. Silverseren^C 18:14, 15 February 2026 (UTC)

Thank you for raising this. The LLM capabilities that the major providers have released in the last month pose an existential threat to the project today, let alone factoring in capabilities in future releases. Early 2025 GPT-4 era models were cute little toys in comparison; non-autonomous, with obvious output that was easily caught with deterministic edit filters. Autonomous agents are indeed coming, and output may improve to the point that detection is difficult even for experts. Big tech data center capex is ramping 20%+ YoY and given the improvements in LLM functionality in the last 6 months, much more must now be expected. The latest releases have shaken me personally and professionally. NicheSports (talk) 08:38, 15 February 2026 (UTC)

We have an obvious place to document how much of what we see on Wikipedia (and the Internet in general) is generated by AI. That page is Dead Internet theory. Alas, a single editor has taken WP:OWNERSHIP of that page and WP:BLUDGEONS any attempt to make the topic of that page the topic that is found in most reliable sources -- whether the Internet now consists primarily of automated content. Instead the page claims that the dead Internet theory is a conspiracy theory and that the theory only refers to a coordinated effort to control the population and stop humans from communicating with each other -- something no reliable source other that the few that bother to respond to the latest 4chan bullshit talk about. There does exist such a conspiracy theory -- promoted by Infowars and 4chan -- but that's not what most sources that write about the dead internet are talking about.

There was even an overly broad RfC that is being misused. The result was no consensus for a complete rewrite of article, but is now used (with the usual trick of morphing no consensus into consensus against) as a club against anyone who suggests any changes to the wording of the lead sentence.

It's sad really. It would be great if, in discussions like this one, we could point to a page that focuses on actual research about how big the problem is that human-seeming AIs are taking over the job formerly done by easily-detected bots. I gave up on trying to improve that page. Life is too short. --Guy Macon (talk) 13:29, 15 February 2026 (UTC)

4chan was the origin of the phrase and the conspiracy theory the original sense of it. It seems to have gone through semantic diffusion to now just mean "there are lots of bots on the internet". The process seems complete now though, inevitably the page will be rewritten, eventually... TryKid ^{[dubious – discuss]} 18:33, 15 February 2026 (UTC)

These can be easily blocked as unauthorized bots. sapphaline (talk) 16:46, 15 February 2026 (UTC)

Thanks for bringing this up. We have more time than usual here, since right now we're still in the phase of these tools being used by AI tech bros and not the general public. Which doesn't mean do nothing, obviously.

I will admit to being somewhat less concerned about this development, at least for Wikipedia. This could be premature or overly optimistic but it seems like the main benefit of agents vs. chatbots for the average person using AI to edit Wikipedia is that they don't have to copy-paste ChatGPT output, which doesn't seem like an enormous amount of friction for this use case compared to, say, doing shopping.

I also would expect that people, particularly the kinds of people who want to edit Wikipedia maliciously (which is a smaller subset of people, though) would find different ways to spoof User-Agent etc if they are not already. (Grok apparently is already.) Gnomingstuff (talk) 17:31, 15 February 2026 (UTC)

still in the phase of these tools being used by AI tech bros - There are some of those with access to lots of resources who have expressed an interest in messing with Wikipedia... But also, it wouldn't take a lot of careful agents to be seriously disruptive. But we're getting into WP:TECHNOBEANS territory. Hard to talk defense on a transparent project without encouraging offense. :/ — Rhododendrites ^talk \\ 18:19, 15 February 2026 (UTC)

"we're getting into WP:TECHNOBEANS territory" - would you be comfortable discussing this by email? sapphaline (talk) 18:21, 15 February 2026 (UTC)

By the way, none of the pre-emptive solutions proposed here are effective. Residential proxies are dirt cheap, user agents are easily spoofed and captchas are easily bypassed. sapphaline (talk) 18:01, 15 February 2026 (UTC)

That they aren't going to catch everyone doesn't mean they're ineffective at catching some. Only an unsophisticated sock puppeteer, for example, would be caught by a checkuser, but it's still a valuable tool because it does catch a lot of sock puppets. It's a starting point, not a solution. — Rhododendrites ^talk \\ 18:14, 15 February 2026 (UTC)

Thoughts and prayers PackMecEng (talk) 18:18, 15 February 2026 (UTC)

guess ECPing main and project space is a (temporary) last resort Kowal2701 (talk, contribs) 22:58, 16 February 2026 (UTC)

user agents are easily spoofed User agent spoofing can easily be detected. Look up TCP and TLS fingerprinting - while those can be spoofed, it's generally harder than spoofing a single header. With JavaScript (slightly outdated article), or even plain CSS (using a technique similar to NoScript Fingerprint), you can make it even harder to successfully spoof the user agent - especially if you don't outright block the user, but instead silently flag them in Special:SuggestedInvestigations, giving no feedback to attackers on if their spoof was successful or not, at least until they get blocked (although this may be undesirable, as the AI edits would be visible for a short while). OutsideNormality (talk) 23:03, 16 February 2026 (UTC)

(Of course I'm not necessarily suggesting any of this be implemented, I'm just outlining possibilities.) OutsideNormality (talk) 23:27, 16 February 2026 (UTC)

I haven't quit editing yet, but I will in the future due to the overwhelming flood that is coming from AI. As is usually the case, the WMF will barely lift a finger, and if they do it will be the wrong finger. Millions of jobs are being replaced by AI in the real world workforce. The impact here will be felt just the same. We can't really stop it. The project will be destroyed by it. It's already happening. --Hammersoft (talk) 15:51, 16 February 2026 (UTC)

Which fingers should they lift? — Rhododendrites ^talk \\ 16:25, 16 February 2026 (UTC)

Maybe cook up some AI agents that can spot fake references and references that don't support the content cited to them? I think such AI would fix roughly 90% of all AI related problems we have right now (and 50% of the future ones) and many problems from non-AI edits. Jo-Jo Eumerus (talk) 17:36, 16 February 2026 (UTC)

this won't work, if LLMs cannot accurately characterize a source then they definitely can't determine whether a source is accurately characterized, the same mechanism would be at work

outright fake references are pretty rare nowadays Gnomingstuff (talk) 17:45, 16 February 2026 (UTC)

That seems to assume that it's impossible for an AI - even a non-LLM AI - to compare sources to article claims, which is unproven (and likely false). Based on some complaints I have seen on AN and elsewhere, I am not sure that fake references are as solved as you seem to assume? Jo-Jo Eumerus (talk) 19:26, 16 February 2026 (UTC)

Fake references aren't solved, but they have become less common with newer LLMs that have search capabilities and/or the ability to provide sources to them. Which doesn't mean that the text doesn't extrapolate beyond the source. Gnomingstuff (talk) 23:30, 16 February 2026 (UTC)

OK, but this doesn't demonstrate that "this [cook up some AI agents that can spot fake references and references that don't support the content cited to them] won't work" at all. Jo-Jo Eumerus (talk) 08:15, 17 February 2026 (UTC)

...because the same process by which it summarizes a source is the process by which it "spots fake references"? Gnomingstuff (talk) 19:36, 17 February 2026 (UTC)

@Gnomingstuff, Not really? Looking up information can be reduced to a similarity search on a vector database using transformers, "summarizing" is different in that it requires the generation of novel information based on the existing mappings. Sohom (talk) 19:58, 17 February 2026 (UTC)

Thanks for the info, I didn't know that. At some point though, the information has to be actually conveyed, and then you're back to the LLM generating that. Gnomingstuff (talk) 04:26, 18 February 2026 (UTC)

But that still doesn't support the contention - minutiae about how LLMs operate do not demonstrate that "this [cook up some AI agents that can spot fake references and references that don't support the content cited to them] won't work", because, for one thing, a LLM can operate recursively in a trial-and-error. Never mind that LLMs aren't the only type of AI out there. Jo-Jo Eumerus (talk) 16:33, 18 February 2026 (UTC)

Thanks for raising this idea, @Jo-Jo Eumerus! We are actually beginning to explore exactly that: whether AI models might be able to help us surface to editors times when a reference appears not to support the claim it is being used to cite. Feel free to subscribe to or comment on that Phabricator task if you'd like to be involved!

As to your question, @Gnomingstuff, about whether or not this is work feasible for AI, we don't know either. So I want to emphasize that it is still at a very early stage, and if we ultimately find that it's not a suitable task for AI, we won't move forward with it. We'll seek community collaboration on the development of any features that come out of it long before they reach the deployment stage. Also, any such features will be informed by our AI strategy that centers human judgment. For instance, I could envision a future in which an editor opens up an article and a Suggestion Mode card appears next to a reference stating that an AI tool thinks it may not support the text it's being used to cite, prompting them to check it (this is one way to keep a human in the loop).

Cheers, Sdkb‑WMF ^talk 19:49, 23 February 2026 (UTC)

Given the capabilities recently released, with more coming, drastic action would be required. The following are the magnitude of changes that could even have a chance

• Negotiation with LLM providers to build guardrails into models preventing their use in generating wikipedia style content
• Banning TA editing, and requiring new editors to submit real-time typed essay responses during sign up to establish a semantic and statistical baseline
• Limiting new accounts to character-limited edits for their first N edits, to ensure that new users are willing and able to contribute without LLM assistance
• Obviously, completely banning LLM assistance in generation or rewriting of any content, anywhere on wikipedia. The latest releases are nothing like what came before; it will completely overwhelm the community's ability to even identify it. The strictest measures are the minimum measures

Of course, most of these will not happen, so we will turn the project over to the machines. Devastating stuff really NicheSports (talk) 18:10, 16 February 2026 (UTC)

There's already been a massive amount of traffic in having to deal with LLM using editors. From my chair, an immediate first step that must be taken is to ban the use of LLMs by any account, including TAs, and make it a bannable offense after one warning. That's just the first step that must be taken. --Hammersoft (talk) 18:14, 16 February 2026 (UTC)

Agreed this is the first step NicheSports (talk) 18:20, 16 February 2026 (UTC)

Disagreed. This violates a fundamental Wikipedia guideline. SuperPianoMan9167 (talk) 18:22, 16 February 2026 (UTC)

I feel like TAs are a red herring here -- maybe you are seeing a different slice of this since you focus on new edits that haven't stuck around long, but the vast majority of AI edits I see are by registered users. Gnomingstuff (talk) 23:36, 16 February 2026 (UTC)

We immediately indef anyone who's rapidly spreading harmful content, and I'd consider LLM-generated content to be a much more severe problem than something like placing offensive images in articles. Thebiguglyalien (talk) 🛸 23:44, 19 February 2026 (UTC)

Community Consensus is to allow LLM generated content with heavy guardrails and restrictions. Besides, most good faith editors, using LLM's or not would either not want to live type their essays, or would be creeped out by the privacy concerns of letting Wikipedia access their keyboard to that level. ~2026-11404-95 (talk) 16:44, 24 February 2026 (UTC)

requiring new editors to submit real-time typed essay responses during sign up to establish a semantic and statistical baseline You do realize someone could have their LLM open in another window and just type the words it generates into the form manually? SuperPianoMan9167 (talk) 18:15, 16 February 2026 (UTC)

This will leave a wildly obvious statistical pattern that conclusively demonstrates the response was not written by a human in real time. Key stroke sequence/timing would solve this robustly NicheSports (talk) 18:19, 16 February 2026 (UTC)

So we need to mandatorily require a keylogger installed on their computer before they even think about contributing to Wikipedia? Sohom (talk) 18:44, 16 February 2026 (UTC)

No, why would that be required for this to be implemented during sign up? The data could be collected as the user types into a response box in the browser. Possibly I'm missing something. Also these are not all firm suggestions... rather examples to demonstrate how far we are from the types of measures required. I need to stop responding now apologies NicheSports (talk) 19:00, 16 February 2026 (UTC)

Plus many people also write articles in word or in notepad. What would it do for that? ~2025-38536-45 (talk) 19:16, 16 February 2026 (UTC)

There's probably a set of smaller bandaid fixes:

• Gather data and collate findings about what newer LLM output tends to look like, and then publicize this better than we already are (and no I don't care about some rando using it to make their claude plugin go semi-viral). WP:AISIGNS has some things that still happen and a few that only started happening around 2025, but a lot of that page describes GPT-4 or GPT-4o era text. I'm sort of doing this but I need to add the current numbers; I've gotten bogged down in cleaning the data of template boilerplate so I haven't updated them in a while.
• Disable Newcomer Tasks or at least the update, expand, and copyedit tasks, in practice these have just encouraged users to become AI fountains because it makes numbers go up faster. They have proven to be a net negative.
• Create a tool, whether via edit filter, plugin or (optimistically thinking) actual WMF integrations with an AI detection service, that automatically flags and/or disallows suspect content. I've been tossing around doing this but nothing concrete thus far.
• Make WP:LLMDISCLOSE mandatory. I've said this before, but the most realistic best-case endgame is probably to disclose, as permanently as possible, any AI-generated content, and let readers make their own decisions based on that.
• Somehow convince more people to work on this than the handful who currently are. We need people working on detection, we need people working on fact-checking, and we need people doing the most grueling task of all which is getting yelled at by everyone and their mother about doing the former two.

Gnomingstuff (talk) 23:56, 16 February 2026 (UTC)

Disabling newcomer tasks is something we could get in motion right now. Thebiguglyalien (talk) 🛸 23:49, 19 February 2026 (UTC)

@Thebiguglyalien,@Gnomingstuff Disabling all newcomer tasks feels like taking a nuclear bomb to fight what is in general a good thing for newcomers. If you show numbers (and get consensus) I can/will support disabling the copyediting task pending the deployment of paste check or similar, I don't see a reason to disable (for example the "add a link" task or "find a reference" task) over this though. Sohom (talk) 23:57, 19 February 2026 (UTC)

At the very least, a warning not to use LLMs in the newcomer tasks would mitigate the issue to some extent. But even that is going to be a tough sell because there are enough people who support LLM-generated content and will come along with "well technically it's not banned therefore we can't say anything that might be interpreted as discouraging it". Thebiguglyalien (talk) 🛸 00:00, 20 February 2026 (UTC)

I don't really see how disabling one (1) feature that has proven to be a net negative for article quality is "a nuclear bomb." Gnomingstuff (talk) 00:37, 20 February 2026 (UTC)

@Gnomingstuff I think there has been significant effort poured into newcomer tasks by the WMF (and also community members) that disabling all newcomer tasks is probably be a significant undertaking that would see opposition from a lot of folks. This is not to mention, that I think we would kinda doing well meaning newcomers a disservice by potentially breaking the Homepage (which relies on the infrastructure of Newcomer tasks), which is the first glimpse of contributor workflows they see after registering.

I will don't think the same opposition applies to disabling specific tasks that are net negative, for what's worth I would not be averse to including a "don't use LLMs" notice to the prompt of the "copyedit article" prompts. And if you can show stats that for the copyediting tasks we are just creating a newbie biting machine/are creating a undue burden on Wikipedians, I would support turning off the specific tasks that are the problem. Sohom (talk) 01:21, 20 February 2026 (UTC)

(Please stop pinging me.)

This is just sunk cost fallacy. Significant effort is poured into a lot of things that turn out to be a bad idea.

At one point I was tracking this; will take a look at the recent stuff if I can find the link. Gnomingstuff (talk) 02:17, 20 February 2026 (UTC)

(Sorry about the pings, will keep that in mind. I prefer to be pinged, since I lose track of discussions on large threads like this -- and kinda assumed similar for you)

I don't see this as a sunk cost fallacy, my point is that I do think the newcomer tasks benefit well meaning newcomers (who go on to be long-term editors), what you need to convince folks of is that the downsides of any newcomer tasks outweighs any benefits that come from engaging well-meaning newcomers, (again stressing any here, I don't disagree that the copy-editing/expanding article ones are a bit of a mess, and I could pretty easily convinced that it is in the communities interests to turn it off). What I'm also saying is that my understanding is that the WMF views this similarly (especially talking about the whole set of features called "newcomer tasks" in aggregate). I don't think WMF will object to us turning off individual tasks that can be shown to be a undue burden on editors as you or TBUA were suggesting the copy-editing task has become (which again is a position I kinda agree with). Sohom (talk) 02:40, 20 February 2026 (UTC)

I just did a check of the 60 copyedit/expand task edits starting at the bottom of recent changes. tl;dr: not good!

Extended content

• Special:Diff/1339101704: Reverted for WP:OL.
• Special:Diff/1339102240: AI. Reverted by ClueBot.
• Special:Diff/1339101839: Reverted for WP:OL.
• Special:Diff/1339102298: Reverted for WP:OL.
• Special:Diff/1339102697: Minor but OK.
• Special:Diff/1339102709: Minor but OK.
• Special:Diff/1339102813: Reverted for WP:OL, and also bafflingly pipes "American" to American nationalism.
• Special:Diff/1339102986: Reverted for WP:OL, and also blanks a lot of tags when what was made was a one-word change.
• Special:Diff/1339103127: Reverted, I assume for inserting an inaccurate link.
• Special:Diff/1339103288: Arguably more WP:OL. (Functionally the same as the reverted edits above)
• Special:Diff/1339103417: Arguably more WP:OL.
• Special:Diff/1339103516: Arguably more WP:OL.
• Special:Diff/1339103606: A "copyedit" that removes tags and does literally nothing else. I reverted this myself.
• Special:Diff/1339103756: Reorders one list item, does no copyediting.
• Special:Diff/1339104117: Erroneously turns British spelling into American spelling.
• Special:Diff/1339222832: Minor but OK.
• Special:Diff/1339109210: Inserts a citation that doesn't verify the claim (which is itself AI-generated by someone else)
• Special:Diff/1339116218: Maybe OK, not great.
• Special:Diff/1339117894: Makes text wordier and inserts WP:WEASEL words, not an improvement.
• Special:Diff/1339119862: Maybe OK but removes claims for unclear reasons.
• Special:Diff/1339120724: Fixes one comma error but inserts another comma error.
• Special:Diff/1339123231: Maybe OK, not great.
• Special:Diff/1339126356: Arguably more WP:OL.
• Special:Diff/1339126545: Reverted per MOS:GEOLINK.
• Special:Diff/1339127172: Reverted for WP:OL.
• Special:Diff/1339127261: Makes text wordier, not an improvement.
• Special:Diff/1339127441: Reverted for inserting a grammatical error.
• Special:Diff/1339127664: Makes text less clear, not really an improvement.
• Special:Diff/1339128710: Maybe OK.
• Special:Diff/1339128838: Arguably more WP:OL.
• Special:Diff/1339129037: Changes a factual claim for unclear reasons.
• Special:Diff/1339129421: Arguably more WP:OL.
• Special:Diff/1339130272: Arguably more WP:OL and once again links to a "nationalism" article inappropriately.
• Special:Diff/1339130508: Arguably more WP:OL.
• Special:Diff/1339131029: OK.
• Special:Diff/1339132065: Maybe OK, maybe overlinked.
• Special:Diff/1338996086: Maybe OK, maybe overlinked.
• Special:Diff/1339133330: Inserts grammatical error.
• Special:Diff/1339134315: Reverted as it claims something happened in 2018 because it had a "When" inline tag from 2018, and erroneously turns British spelling into American spelling. (fixed, my mistake)
• Special:Diff/1339134948: Maybe OK, debatable.
• Special:Diff/1339135193: Blanks short description for no reason. I reverted this.
• Special:Diff/1339135269: Changes the meaning of a claim by editing "people of color" into "Black," inserts some links.
• Special:Diff/1339135583: Removes a sentence, you can debate whether the sentence was necessary but this isn't a copyedit.
• Special:Diff/1339135631: OK, removes what seems to be misplaced markup
• Special:Diff/1339136729: Improves one phrase, questionably edits one phrase, and erroneously turns British spelling into American spelling.
• Special:Diff/1339137264: Inserts a grammatical error (or "added grammar" as they put it) and makes the intro repetitive.
• Special:Diff/1339138358: OK but minor. Inserts an error at the end.
• Special:Diff/1339138925: Inserts a (probably accidental) error.
• Special:Diff/1339140099: Not a copyedit at all but inserts resume-like text.
• Special:Diff/1339147009: Makes concise text wordy.
• Special:Diff/1339148078: OK.
• Special:Diff/1339148176: OK but minor.
• Special:Diff/1339149000: OK but calling this "removing bias" is really over-egging the pudding.
• Special:Diff/1339149633: Deletes content for unclear reasons.
• Special:Diff/1339150811: OK but doesn't "fix a typo" as claimed.
• Special:Diff/1339153221: Copyvio.
• Special:Diff/1339154270: Copyvio.
• Special:Diff/1339156370: AI. I reverted this.
• Special:Diff/1339161657: Maybe OK but questionable.
• Special:Diff/1339162701: OK.

Of these 60 edits, only 19 18 of them did not contain obvious issues, and only a handful of those 19 18 were obviously good. This means that over two-thirds of the edits were obviously not improvements, and some were drastically not improvements.

These diffs are a little skewed since several the ones at the top are the same person, but based on my experience I don't think this is an unrepresentative sample. (You can check others by going to pretty much any of these articles; since people rarely remove the copyedit tags, the articles just accumulate more and more questionable edits.) Gnomingstuff (talk) 03:15, 20 February 2026 (UTC)

Hi @Gnomingstuff! I wanted to chime in on behalf of the Growth team, which is responsible for Newcomer Tasks. Overall, Newcomer Tasks arose out of a recognition that Wikipedia needs more editors, and to achieve that we first need to make editing easier for newcomers who may go on to become experienced contributors. We had found that many newcomers were unsure how they could contribute, or they tried to take on very challenging tasks like creating a new article immediately, so we developed Newcomer Tasks to point them toward easier edits and give them a little more guidance.

Our early analysis showed positive results: Newcomers with access to the tasks were more likely than other newcomers to make their first edit, less likely to have it reverted, and more likely to stick around and continue editing long-term. This led us to develop Structured Tasks that provide even more guidance. We deployed the first of these, "Add a Link", here last September after we saw similar results and gathered community input/consensus. Currently we’re testing out "Revise Tone" (see this discussion), and the early data is looking great; here’s the feed of those edits.

Now, to speak to your spot checks, first of all, thank you for doing them! It's really helpful to have that kind of information. The number of edits with issues in that sample certainly isn't great, but one thing it may be helpful to keep in mind is that these are all edits by newcomers, who by virtue of being new tend to struggle navigating Wikipedia's unfamiliar environment. I'd be curious how a random sample of 60 non-task newcomer edits would compare to your sample; the fact that task edits are reverted less often is one clue that it might be even worse. It shows the magnitude of the challenge we face.

Digging into the diffs, the most frequent issue you identified (in 16/60 edits) was overlinking. This is a known issue for which we're exploring possible solutions. Beyond that, it looks like 3/60 edits had signs of AI usage, although it's certainly possible others also used AI that wasn't immediately visible. One way we could discourage this would be to add a warning to the help panel guidance for relevant tasks. However, we find that adding too many warnings quickly causes editors to just stop reading guidance and miss other important info. A more targeted approach would be to identify the moment when an editor appears to be pasting LLM-generated content into the edit window and engage with them then, which is what we hope to do with Paste Check. That'll be available here next week.

We're hoping to continue developing and introducing structured editing and feedback opportunities so that we can help incubate the next generation of editors. That effort has already shown some fruits: There are more than 500 editors on this project who did a Newcomer Task as one of their first 10 edits and have since made over 1,000 edits. That said, I know from my own experience that patrolling newcomer edits is a lot of work, and we don't want to exacerbate that. We are always looking for your collaboration to design new tasks in a way that sets up newcomers for success without worsening the moderation burden experienced volunteers already bear.

Cheers, Sdkb‑WMF ^talk 20:18, 24 February 2026 (UTC)

Thanks for the update! In my experience the AI stuff comes more into play with expand/update, although the lines get blurred a lot, and like you said, a lot of times minor AI copyedits are either OK or pointless-but-not-bad. Gnomingstuff (talk) 20:50, 28 February 2026 (UTC)

My general sense of "newcomer tasks" is that they are a patch that tries to pretend away the fundamental problem, namely, it takes being a little odd to decide that writing an encyclopedia is a fun idea of a hobby. There's going to be a long tail of drive-by contributors, and a much smaller number of serious enthusiasts. Even the best automated scheme for suggesting edits will only push that curve a little bit. And they run the real risk of leading people to make useless-to-detrimental small edits, because by construction they necessarily lead the least experienced editors to make more edits faster. Unless editors get feedback about which changes were good and which were not, that's not a learning experience; it's just racking up points. Stepwise Continuous Dysfunction (talk) 23:59, 20 February 2026 (UTC)

Yes exactly, perfectly stated.

They're also not necessarily small edits, either -- one of the more insidious things here is the task encourages people, probably inadvertently, to mislabel what they are actually doing. Recent-ish example: This edit claims to remove promotional tone in the original text. I have no idea what the hell this is referring to; the original text was not promotional. And it introduces a few subtle changes of meaning -- for instance, claiming a series of books was "inspired, in part" by his wife, when the original text implies his wife took a more active role in introducing the topic. Gnomingstuff (talk) 03:42, 21 February 2026 (UTC)

Is the expand task still live? I assumed it was disabled when the obvious issues emerged. If it isn't, it should be disabled pronto. CMD (talk) 04:01, 20 February 2026 (UTC)

_I_ don't personally know which fingers to lift. I'm not an expert in this field. Following my recommendations would be decidedly ill-informed. That doesn't mean I can't recognize a problem. If my furnace fails to run, I know my abode isn't warm. I don't know how to fix the furnace, but I know it's broken. Where this goes to is competence, or lack thereof, of the WMF. While there's a number of things the WMF has done well, they have also demonstrated incompetence on a grand scale on a variety of occasions that are enough to inspire awe. I don't expect the WMF to be on the front edge of the curve on dealing with this problem. They will be reactive (if at all) rather than proactive. --Hammersoft (talk) 18:13, 16 February 2026 (UTC)

Millions of jobs are being replaced by AI in the real world workforce.

The project will be destroyed by it We were told this a month ago, and two months ago, and six months ago, and a year ago, and two years ago, etc. We were told agents would replace humans in 2025. That didn't happen. We were promised AGI by 2026. That didn't happen. The AI industry is filled with broken promises, over and over and over again. Further reading here. SuperPianoMan9167 (talk) 18:29, 16 February 2026 (UTC)

Citations aren't required for comments. A quick Google search will reveal many high-quality publications suggesting that it is different this time. I'm going to stop replying here but you definitely should too. This is not constructive NicheSports (talk) 18:40, 16 February 2026 (UTC)

My point is that all these posts saying "the project will die from AI" are starting to sound like Chicken Little saying "the sky is falling". SuperPianoMan9167 (talk) 18:43, 16 February 2026 (UTC)

Maybe the warnings are like chicken little, or maybe they are like the seven warnings of sea ice that the Titanic ignored. Or maybe the radar warning about a large formation of aircraft approaching Pearl Harbor on December 7, 1941. --Guy Macon (talk) 19:39, 16 February 2026 (UTC)

Sometimes they are just ballons. ~2025-38536-45 (talk) 20:25, 16 February 2026 (UTC)

See The Boy Who Cried Wolf. There have been so many equally hyperbolic previous predictions that were incorrect that many people are disinclined to believe you this time, and this will only increase with every mistaken assertion that this time the end really is nigh. Thryduulf (talk) 22:14, 16 February 2026 (UTC)

We should at the very least have a contingency plan, this is something the WMF should have done already Kowal2701 (talk, contribs) 23:23, 16 February 2026 (UTC)

You tell 'em! Look at all the hyperbolic previous predictions that this time Mount Vesuvius will erupt.

We have been living here since 1945 and it's been fine...

--Guy Macon (talk) 01:48, 17 February 2026 (UTC)

Blueraspberry's recent Signpost article seems very applicable here:

The solution that I want for the graph split, and for many other existing Wikimedia Movement challenges, is simply to be able to see that there is some group of Wikimedians somewhere who have active communication about our challenges. I want to get public communication from leadership who acknowledges challenges and who has the social standing to publicly discuss possible solutions. I want to see that someone is piloting the ship upon which we all sail, and which no one would replace if it ever failed and sunk. For lots of issues at the intersection of technical development and social controversy – data management, software development, response to AI, adapting to changes in political technology regulation – I would like to see Wikimedia user leadership in development, and instead I get anxious for all the communication disfluency that we experience.

Kowal2701 (talk, contribs) 14:42, 18 February 2026 (UTC)

I suspect the (now-inactive )account Doughnuted was operated by AI agent—seems like the operator just prompted it to provide suggestions and the agent created and followed a plan of action (a very poor one, but still). If true, it's very far from fooling. But it seems little different from mindless copy and pasters we've been dealing with years. I'm not too concerned. Ca ^{talk to me!} 09:39, 17 February 2026 (UTC)

This seems basically good-faith too. The larger suggestions aren't really improvements to me but the smaller copyedits seem clearly good and I'm implementing some of them (this for instance is good). Gnomingstuff (talk) 17:25, 17 February 2026 (UTC)

We should at least make it explicit that AI agents aren't exempted by the bot policy, to avoid future wikilawyering that might slow us down from actually doing something about the issue. Chaotic Enby (talk · contribs) 14:29, 18 February 2026 (UTC)

The bot policy applies to bots and to bot-like editing (WP:MEATBOT): For the purpose of dispute resolution, it is irrelevant whether high-speed or large-scale edits that a) are contrary to consensus or b) cause errors an attentive human would not make are actually being performed by a bot, by a human assisted by a script, or even by a human without any programmatic assistance. So I'm not sure what clarification is needed - if someone is engaging in high-speed or high-volume editing they need to get consensus first, regardless of what technologies they do or do not use. Thryduulf (talk) 15:27, 18 February 2026 (UTC)

There's no reason an AI agent would necessarily edit at high-sped or high-volume. Presumably they'd try to model real editors. CMD (talk) 15:35, 18 February 2026 (UTC)

Then what would be the point of using an AI agent? My concern with agents (and bots) is automated POV-pushing, and that is effective when it is high-volume and high-speed. It would be a good policy to require preconsensus for high-volume edits, with bans if the user and their tools strays from the type of edit they said they would do. It won't solve all problematic edits, but it will stop some of them. WeirdNAnnoyed (talk) 12:01, 19 February 2026 (UTC)

@WeirdNAnnoyed It would be a good policy to require preconsensus for high-volume edit the existing Bot policy already requires this. All bots that make any logged actions [...] must be approved for each of these tasks before they may operate. [...] Requests should state precisely what the bot will do, as well as any other information that may be relevant to its operation, including links to any community discussions sufficient to demonstrate consensus for the proposed task(s). Thryduulf (talk) 12:34, 19 February 2026 (UTC)

POV pushing can be very effective, perhaps more in some cases, at low volumes and low speeds. There are also other potential uses for AI agents, such as maintaining a specific page a specific way, a short-term task, or even plain old testing/trolling. CMD (talk) 13:12, 19 February 2026 (UTC)

AI agents could also be used in a good faith effort to improve the encyclopaedia. Whether the edits would be an improvement or not is both not relevant to the intent and also unknowable in the abstract. Thryduulf (talk) 13:23, 19 February 2026 (UTC)

Anything could potentially be used in good faith, but I don't see this alone as justifying an exemption from our current bot policy. Chaotic Enby (talk · contribs) 13:25, 19 February 2026 (UTC)

Not sure how to understand this reply, the purposes I noted could be used in good faith. The original point, that AI agents would not necessarily edit at high-sped or high-volume, is also applicable to good faith uses. CMD (talk) 13:27, 19 February 2026 (UTC)

@Chaotic Enby I was not suggesting anything of the sort. My main point in this discussion is that the existing bot policy already covers any bot-like editing from AI-agents.

@CMD I think I misunderstood your final "trolling" comment (which is not possible to do in good faith, whether by human or AI) as indicating the tone of your whole comment. My apologies. I agree with your original point. Thryduulf (talk) 13:43, 19 February 2026 (UTC)

Thanks, sorry for the misunderstanding. Chaotic Enby (talk · contribs) 13:52, 19 February 2026 (UTC)

Agree we should be explicit, if for nothing else than to be clear that use of agentic AI falls under "bots" and not under "assisted or semi-automated editing". — Rhododendrites ^talk \\ 15:37, 18 February 2026 (UTC)

The dividing line between "bot" and "assisted or semi-automated" is generally held to be whether the human individually reviews and approves each and every edit. If a use of agentic AI creates a proposed edit, shows it to the human (maybe as a diff or visual diff), and the edit is only posted after the human approves it, that would fall on the "assisted or semi-automated" side of the line (which, to be clear, could still be subject to WP:MEATBOT if the human isn't exercising their judgement in approving the edits). On the other hand, if the human instructs the AI "add such-and-such to this article" and the AI decides on the actual edit and submits it without further human review, that would almost certainly fall on the "bot" side of the line. There's probably plenty of grey area in between. Note that "high speed" or "high volume" aren't criteria for whether something is "a bot" or not, although higher-speed and higher-volume editing is more likely to draw attention and to be considered disruptive if people take issue with it. Anomie⚔ 23:57, 18 February 2026 (UTC)

I think it is inevitable that agents and AI will be the primary contributors to Wikipedia and eventually we'll only need a minority of editors to fix hallucinations and do general maintenance.

This is also happening in the open source community.

Writing articles the old way will still be an option for hobbyists, but we shouldn't be surprised if only 1% of the articles are done that way in a year or two... it's uncomfortable, but it is what it is and it doesn't make sense to resist it, IMO. Bocanegris (talk) 14:45, 20 February 2026 (UTC)

That seems to be quite the overestimation of AI's ability to actually generate factual and/or encyclopedic content. If it somehow manages to make up a majority of edits to Wikipedia, there would have to be a bunch of overworked fact-checkings attempting to make the content factual still. It's not the same as code-changes. ~2026-68406-1 (talk) 16:47, 20 February 2026 (UTC)

When AI was introduced, it could barely write a high school-level essay. Last year, when generating articles for Wikipedia, almost every source was hallucinated, so it was useless. This year, hallucinations still happen but are less common, and people have noticed that. That's why I said that maybe in a year or two, it could be as good as a person doing this (still making mistakes, as human editors do, but that's why we'll still need people fact-checking).

When this started, I dismissed people who said "just wait a year and it will be better" because they said that a lot and it didn't get good enough. Then it actually got good enough, so now I think twice before I assume AI will never be able to do X or Y.

They're using this (officially) in the medical and military fields. It's replacing programmers and artists... I don't think it's so far-fetched to think it will replace Wikipedia editors too, as uncomfortable as that sounds. Bocanegris (talk) 17:10, 20 February 2026 (UTC)

Articles with hallucinated sources are way less common to be encountered because said articles are being speedily deleted. Articles with hallucinated sources or communication intended for the user are still being produced, as a quick look at the deletion log suggests. SuperPianoMan9167 (talk) 17:38, 20 February 2026 (UTC)

There has been a significant change in LLM-generated content, though; instead of outright nonexistent references, it's more common for there to be real references that do not support the content they are cited for. SuperPianoMan9167 (talk) 17:45, 20 February 2026 (UTC)

This is discussion is yet another example of those who are vehemently against any use of AI/LLMs at all not actually listening to people with different views. LLMs are not good enough, today, to write Wikipedia articles on their own. That is unarguable. However, the combination of some LLMs and an actively-engaged human co-author is able to produce a quality Wikipedia article. That there are a lot of humans who are not engaging sufficiently does not change this in the same way that inattentive bot operators don't prove all bot operators are inattentive.

Additionally none of the above means that LLMs won't be good enough to produce quality Wikipedia articles with less (or even no) active supervision in the future. I'm less confident that this will happen than some in this thread, particularly on the timescales they quote, but I'm not going to say it can never happen. The technology is changing fast and we should be writing rules, procedures, etc. based on the outcomes we want (well-written, verifiable encyclopaedia articles) not based on hysterical reactions to the technology as it exists in February 2026 (or in some cases as it existed in 2024). Thryduulf (talk) 18:54, 20 February 2026 (UTC)

LLMs are not good enough, today, to write Wikipedia articles on their own. That is unarguable. However, the combination of some LLMs and an actively-engaged human co-author is able to produce a quality Wikipedia article. That there are a lot of humans who are not engaging sufficiently does not change this in the same way that inattentive bot operators don't prove all bot operators are inattentive. Completely agree with this. The question then becomes "How can we make sure that human co-authors are actively engaged?" SuperPianoMan9167 (talk) 18:59, 20 February 2026 (UTC)

the combination of some LLMs and an actively-engaged human co-author is able to produce a quality Wikipedia article, assuming you're correct, that's a teeny tiny part of the editor community who would have that competence, and can be perfectly addressed with a user right. We should be writing PAGs for the present and change them as things develop, not frustrating any attempt to because of some distant possibility or empirically-unsupported notion. Kowal2701 (talk, contribs) 21:50, 20 February 2026 (UTC)

Actually I'd say that the vast majority of the editing community have the competence. A smaller proportion have both the access to a good-enough* LLM and the desire to edit in that manner. A user right one option from a social perspective, but my understanding from the last time this was discussed is that it would be technically meaningless.

PAGs should work for the present but be flexible enough to also work as the technology develops without locking us in to things that only worked in 2026 without major discussions.

*How good "good enough" is depends on how much effort the effort the human is willing to put in and what tasks it's being put to (copyediting one section requires less investment than writing an article from scratch. My gut feeling is that the LLM-output when asked to write an article about a western pop culture topic would require less work than the same model's output when asked to write an article about a topic less discussed in English on the machine-readable internet (say 18th century Thai poetry), but I've never seen this tested). Thryduulf (talk) 22:09, 20 February 2026 (UTC)

In my opinion, the literal only way to use LLMs on Wikipedia without running afoul of PAGs or the risk of hallucination is to thoroughly check through the text you are going through and check if all the information is sourceable and verifiable, or even just feed sources to it and hope that it doesn't spit out a text that doesn't have source-text integrity. It's just not a good idea to write articles backward, text first, sources second. ~2026-68406-1 (talk) 05:36, 21 February 2026 (UTC)

The perfect AI policy should probably prohibit specifically raw or unedited LLM output to prevent wikilawyering of 'oh I made this article with LLM but I heavily edited it so you can't spot if its LLM or not BWAHAHAHAHAH'. ~2026-68406-1 (talk) 05:38, 21 February 2026 (UTC)

another reason why WP:LLMDISCLOSE should be mandatory; unironically, the most transparent I have ever seen anyone about their editing process was someone who almost definitely wasn't trying to be. (thanks to whoever showed this to me). Gnomingstuff (talk) 07:18, 21 February 2026 (UTC)

Imo starting out with a ban while the technology is rubbish and disruptive, and then gradually loosening it as they develop and get better makes the most sense. People who would oppose any loosening on moral grounds are in the minority, I think CENT RfCs would function fine and ensure we don’t get locked into anything Kowal2701 (talk, contribs) 11:34, 21 February 2026 (UTC)

Just to ring in here from the WMF team responsible for our work on on-wiki bot detection; we’re definitely thinking about the agentic AI issue as well. You’ll be hearing from us soon on how the bot detection trial described in that link has gone (in short: very well).

I do want to caution that there really is no panacea for detecting AI agents. Like all bots, it is an arms race with a hefty gray area. As mentioned elsewhere in this thread, the way a lot of bot detection works these days (and how we have been implementing it here) is more than just popping up a puzzle sometimes. It involves assessing clients along a spectrum of confidence, and it can often mean deferring immediate action in that moment, so as not to provide deceptive bots the ability to efficiently reverse engineer defenses.

So, while I don’t have a simple answer to the concern here, I mainly wanted to get across that we are very aware of AI agents as we work to dramatically level up Wikipedia’s bot detection game — and that dealing with those agents is an internet-wide not-fully-solved problem that is not unique to Wikipedia. EMill-WMF (talk) 23:17, 23 February 2026 (UTC)

Arbitrary Section Break: WMF needs your ideas

Hi all! I’m Sonja and I lead the contributor product teams (so Editing, Growth, Moderator Tools, Connections, as well as Language and Product Localization) at WMF. I’d like to take a step back and reflect again on the broader issue this thread is raising: Over the last year especially, we’ve had many discussions on how already big backlogs are increasing to unsustainable sizes because AI is making it easier for everyone to add content. At the same time we continue to see declines in active editors, leading again to larger backlog sizes. Only looking at one of these core problems without looking at the other is no longer an option at this point if we want to ensure the sustainability of the projects.

That being said, I see it as WMF’s role to both provide the tools to support and grow our ranks of editors and help experienced editors keep our content accurate, trustworthy, and neutral. The question is: how can we do that in a way that’s not overwhelming? Or said differently: what tools do we need to provide you all with to ensure that backlog sizes don’t keep increasing, even as we bring on new generations of volunteers? We’ve also touched on this in our discussion on meta as part of our annual planning process, and folks like @TheDJ , @pythoncoder, and lots of others helpfully chimed in with their perspectives. One of the requests we’ve heard the most often is building tools to identify AI slop - this is something we’re already working on but it can only do so much as the quality and sophistication of AI tools changes. So what I’d really like to know is, from your perspectives what other tools or processes could WMF build to keep up with the challenges we’re facing today? SPerry-WMF (talk) 19:12, 25 February 2026 (UTC)

If we're talking about detecting AI-generated content, then I can't think of anything that would be more useful than a tool to detect common AI patterns; if we're talking about unauthorized bot use, then there are already rate limits and hcaptcha in place. sapphaline (talk) 20:36, 25 February 2026 (UTC)

Talking about unauthorized bot use, maybe there could be some software in place to intentionally waste their power or bandwidth? Like Anubis, a script to completely hammer their CPU, or something different. sapphaline (talk) 20:44, 25 February 2026 (UTC)

There's MediaWiki:Editcheck-config.json. Something assisting that could be commissioning research to determine AI signs for some of the recent models (Gnomingstuff said our current signs are largely from GPT-4). Also phab:T399642 for flagging WP:V failures Kowal2701 (talk, contribs) 21:31, 25 February 2026 (UTC)

There's MediaWiki:Editcheck-config.json

@Kowal2701: thank you for sharing this here. There's also the newly-introduced Special:EditChecks. This page offers a more more visual view of the Edit Checks and Suggestions that are currently available. The suggestions that appear within the "Beta features" section of that page are available if you enable "Suggestion Mode" in beta features. Note: one of the experimental suggestions available via Suggestion Mode leverages Wikipedia:Signs of AI writing to highlight text that may include AI-generated content. PPelberg (WMF) (talk) 23:39, 25 February 2026 (UTC)

To clarify: With the caveat that we virtually never know which exact LLMs people use and whether they enabled "research mode" or whatever, our current signs are skewed toward 2024-era LLM text (GPT-4o, o1, etc), with a few historical ones (GPT-4) and one or two that are common in newer text.

The real problem with writing this page, though, is to write it in a way that people will A) believe, B) not misinterpret, and C) not see as the main problem. With "promotional tone," for instance, that isn't totally accurate; there's a way in which AI writes promotional text, that is distinct from pre-AI promotional text. With the "AI vocabulary" section much of it is used in specific parts of a sentence more than others, etc. The less specific you are, the more people will misinterpret; but the more granular you are, the less likely people are to believe you. Gnomingstuff (talk) 09:07, 3 March 2026 (UTC)

This feels important enough to merit marshalling some funds for some sort of in-person workshop (or at minimum a concerted effort, with outreach, to pull stakeholders into a call of some kind, rather than a subsection of a more generalized forum that will then be hidden in an archive). I know this board in particular is likely to receive a bunch of "wiki stuff should stay on-wiki" comments, but diffuse, complicated, multistakeholder conversations are just difficult to have on-wiki sometimes, and tend towards splintering, hijacking, and tangents in ways a focused events could avoid. I dare say it would also make sense to hold at least some of these conversations at a project-by-project level. Enwiki, for example, already has an awful lot of resources, guidelines, RfC decisions, a wikiproject, etc. and probably deals with a different quantity of AI-generated content than most other projects. Commons, for its part, has its own distinct needs and constraints. YMMV. — Rhododendrites ^talk \\ 21:26, 25 February 2026 (UTC)

Hi @Rhododendrites, great idea. We do regular calls on the enwp Discord where we discuss early-stage product features and brainstorm ideas together and this would be a perfect topic to talk through together. We've just scheduled a call for March 18, 20:30 UTC to focus on this topic. Would love to see you there, along with anyone else reading this thread. SPerry-WMF (talk) 15:45, 27 February 2026 (UTC)

Thanks a lot for bringing up that question! I believe that the Edit Check team is doing a great job in this direction already, and, beyond that, something that could help would be to make it more intuitive for editors to edit without relying on third-party AI tools (which give convincing results but are prone to hallucinations). For example, parsing the content of the edit and suggesting potential sources (that could be added to the edit text in one click), or evaluating the quality of existing sources. Getting an edit reverted for being unsourced can be a very frustrating first experience, and I believe it is a major roadblock towards editor retention, so anything that helps editors do this more intuitively could really help them not turn towards the authoritative-sounding promises of generative LLMs. Chaotic Enby (talk · contribs) 21:31, 25 February 2026 (UTC)

Thanks for these comments.

Re: Helping to remind editors/newcomers to add sources, Reference Check now does this and was deployed by default here on Enwiki just two weeks ago (cf. thread), plus the Suggestion Mode (currently a Beta Feature, cf. announcement) has a suggestion-type that highlights existing un-cited paragraphs. As always, feedback on that Beta Feature would be greatly appreciated, so that all aspects of it can be further refined/improved before it is shown to actual newcomers.

Re: "evaluating the quality of existing sources" - As Kowal2701 notes above, T399642 [Signal] Identify cases where reference does not support published claim is something we're planning on working on very soon, and are still gathering data/references/ideas for. There's also the closely related idea of T276857 Surface Reference survival signal which proposes providing information to editors (and perhaps readers) about how some sites/sources might need deeper consideration before they use them as references. If anyone has additional tools or info for those tasks, please do share.

Re: "parsing the content of the edit and suggesting potential sources" - I believe that idea is immensely more complicated, especially to do so reliably, and I'm not aware of any current WMF work/notes towards it, though I have seen some other editors mention it as a potential future goal once LLMs improve sufficiently.

HTH. Quiddity (WMF) (talk) 00:16, 26 February 2026 (UTC)

Thanks again, great to know all of these! Chaotic Enby (talk · contribs) 00:36, 26 February 2026 (UTC)

Love this—exactly the sort of AI-powered tools I've been advocating for in other discussions about this. Anything that can do quick checks or flag possible issues for editors has potential to be helpful. I imagine newer editors would use features more like Suggestion Mode while experienced editors would use tools more like Signal. I have reservations about LLM detectors since they have a poor track record elsewhere, but something narrowed specifically to Wikipedia's purpose might be worth exploring. I'm not against adding things that are visible to readers, but it would need to be very unintrusive; otherwise it will become a source of annoyance and mockery for readers like the donation banners. Thebiguglyalien (talk) 05:24, 27 February 2026 (UTC)

Coming back to the question "what other tools or processes could WMF build to keep up with the challenges we’re facing today?": aside from ideas related to AI, what other tools could help editors deal with the backlogs currently being created by newcomers? I'm especially thinking about backlogs that newcomers could potentially help with (at both Enwiki and globally), but also backlogs that require more experience. Are there more large-scale ideas that should be added for consideration in next year's annual plan? Is there anything missing that you think could have a big impact on these problems? SPerry-WMF (talk) 03:14, 6 March 2026 (UTC)

Why aren't we using Perma.cc?

Inspired by the recent archive.today drama, I now have the same question as this HN commenter: why aren't we using Perma.cc for web archiving?

Based on my understanding, the process would be something like this:

1. WMF will pay Perma.cc so that anyone with a Wikipedia account meeting the same threshold Wikilibrary has can archive an unlimited/very high amount of pages monthly or annually.
2. Automated archives will continue to be made on Wayback Machine.
3. Perma.cc uses the same technology as Ghostarchive so captures are very high-fidelity; you can also upload PDF files and webpages as a screenshot if it can't crawl them. Unfortunately it doesn't provide options to archive audio or video files.

This seems like the perfect solution to our web archiving needs when Wayback Machine isn't enough. Could WMF work in this direction? sapphaline (talk) 15:23, 22 February 2026 (UTC)

@Sapphaline Hi - I work on The Wikipedia Library at the Wikimedia Foundation, so I'm curious to learn more about this suggestion. We have partnered with organisations outside the typical paywalled-research category in the past (e.g. a translation website), so it's feasible that we could reach out to Perma.cc about this. I wanted to learn a bit more about this first though - when you say "when Wayback Machine isn't enough", could you be more specific? What is it that using Perma.cc would allow you to do that Internet Archive doesn't? Samwalton9 (WMF) (talk) 16:30, 24 February 2026 (UTC)

Archive.today is usually a lot better than the Wayback Machine at archving. Their archives sort of "freeze" the page, making their archives of e.g. Instagram work. They are also known for bypassing paywalls partly through giving the crawler subscriptions to the websites. I think @GreenC would explain this a lot better than I can. Aaron Liu (talk) 16:52, 24 February 2026 (UTC)

@Aaron Liu Is that 'freezing' something that Perma.cc also does better than Wayback Machine? Samwalton9 (WMF) (talk) 17:23, 24 February 2026 (UTC)

Sam, it's good that you are listening to volunteers, but it would be best, before any decision is made, if you could look at the whole market. There seem to be plenty of players in this space. Maybe Perma.cc offers the best service for the price, But we shouldn't just go for the first option suggested without checking first. Phil Bridger (talk) 18:06, 24 February 2026 (UTC)

That totally makes sense - I'm only asking about Perma.cc because it was the option proposed here, I'd like to understand what makes an archiving service good or bad, since I don't know very much about the options! Samwalton9 (WMF) (talk) 19:40, 24 February 2026 (UTC)

"What is it that using Perma.cc would allow you to do that Internet Archive doesn't" - Wayback Machine usually fails at archiving JavaScript-heavy websites, e.g. Mastodon. There's no option to upload a webpage manually - if Wayback Machine's crawler can't get it, it's unarchivable. It's also possible to directly download a webpage from Perma.cc in archived format (.warc) without using third-party tools like SingleFile. sapphaline (talk) 17:27, 24 February 2026 (UTC)

And many websites excluded from Wayback Machine aren't excluded from Perma.cc. sapphaline (talk) 17:29, 24 February 2026 (UTC)

Do you know if Perma.cc succeeds to do so? Aaron Liu (talk) 23:38, 24 February 2026 (UTC)

Note: Perma.cc WARCs are uploaded to the Internet Archive and indexed by Wayback Machine (due to being under the 'web' collection). Obviously still affected by exclusions and there's currently a backlog since they turned it off when IA went down in 2024 but just noting. --Nintendofan885^{T&Cs apply} 22:42, 24 February 2026 (UTC)

Question: Should perma.cc shut down, is the content duplicated somewhere else? Are there any legal or technical issues with someone making a backup copy? The day after it goes dead would not be a good time to try to save the data.... --Guy Macon (talk) 00:30, 25 February 2026 (UTC)

My bot has needed to remove many perma.cc links over the years. A significant percentage of them have stopped working. It's also my understanding their target audience are institutional clients (courts, journalists, scholars) and the archive are not for public viewing ie. you need a login/pass to view them. For example the NY District Court may have an account and where they upload millions of captures and you need a pass to view them. They do offer public access accounts but I don't think they are very interested in hosting copies of The Guardian there and if you do good chance they won't last. They seem to offload (some?) WARCs to the Wayback Machine probably as a backup option but in that case you might as well use the Wayback Machine. They are appear to be trying to keep a low profile on the legal radar. All web archives face this fundamental problem of copyright and there are only a couple strategies. Archive.today is the king of the judiciary arbitrage strategy nobody does it better it was a major loss there are no peers. -- GreenC 05:23, 25 February 2026 (UTC)

If Perma.cc links is able to be viewed by the public, then this is a good idea. Guz13 (talk) 23:34, 27 February 2026 (UTC)

• Funnily enough, myself and L235 just independently came up with a similar idea of using perma.cc with the Wikipedia library/some sort of gated way, which we mentioned to Eric Mill. I'm not sure that using perma.cc solves all our problems, but it could be part of a multifaceted solution. I think Kevin has a better sense of the upsides of using perma.cc so hopefully he chimes in ;) CaptainEek ^{Edits Ho Cap'n!}⚓ 21:40, 28 February 2026 (UTC)

Database server lag

What triggered this message:

Due to high database server lag, changes newer than N seconds may not appear in this list.

? sapphaline (talk) 11:01, 3 March 2026 (UTC)

Better to post this kind of thing at WP:VPT. Looks like phab:T418839. Looks fixed now. –Novem Linguae (talk) 11:23, 3 March 2026 (UTC)

Wikimedia Foundation Bulletin 2026 Issue 4

Here is a quick overview of highlights from the Wikimedia Foundation since our last issue on Feb 13. Please help translate.

---

Highlights
Let's Talk continues

• Birthday mode: This limited-time campaign feature celebrates 25 years of Wikipedia with a birthday mascot, Baby Globe. When turned on, Baby Globe is shown on ~2,500 articles, waiting to be discovered by readers. The feature is available for all Wikipedias to customise through Community Configuration until 6 April 2026. So far 17 Wikipedias have joined in the fun.
• Wikipedia's 25th birthday party celebrated on Commons: Content from the January 15th global birthday party selected as Media of the day.

Annual Goals Progress on Infrastructure
See also newsletters: Wikimedia Apps · Growth · Product Safety and Integrity · Readers · Research · Wikifunctions & Abstract Wikipedia · Tech News · Language and Internationalization · other newsletters on MediaWiki.org

• Etherpad cleanup: For security and performance reasons, all current pads on Wikimedia’s Etherpad instance, the web-based "ephemeral" editor for real-time collaborative document editing, will be permanently deleted after 30 April. We will continue running this Etherpad instance to support events and other short-term collaboration, but will be periodically deleting data going forward. If you have content in Etherpad you want to keep, please create local backups, as data will be permanently deleted and will not be able to be recovered.
• Activity tab: Wikipedia iOS app has rolled out the improved Activity tab to all users in version 7.9.0. A/B test results showed increased account creation among users with access to the feature. Updates include enhanced editing impact insights, module customization, and relocation of History into the Search tab.
• Reference Check: The feature Reference Check has been deployed to all Wikipedias. In A/B testing, the impact was substantial: newcomers shown Reference Check were approximately 2.2 times more likely to include a reference on desktop (or acknowledge/explain why they did not) and about 17.5 times more likely on mobile web.
• Semantic search: The Foundation has launched a limited Android mobile app experiment that tests hybrid search capabilities which can handle both semantic and keyword queries. The Phase 1 beta is now live on Greek Wikipedia. The goal is to understand whether combining meaning-based retrieval with keyword search helps readers find information more effectively. Testing will expand to English, French, and Portuguese Wikipedias in March.
• Navigation experience: The Foundation will run an experiment for mobile web users, that adds a table of contents and automatically expands all article sections, to learn more about navigation issues they face. The test will be available on Arabic, Chinese, English, French, Indonesian, and Vietnamese Wikipedias.

Screenshot of the current prototype of Abstract Wikipedia, showing a two sentence article about Kolkata.

• Site notices: Site notices (MediaWiki:Sitenotice and MediaWiki:Anonnotice) now will render on all platforms, not just on the desktop site. Users on mobile web will now see these notices and be informed.
• Tech News: Latest updates from Tech News week 08 and 09 include the new “Edit full page” button for people who are editing a page-section using the mobile visual editor. They also link to the 40 community submitted tasks that were resolved over the last two weeks.
• Wikifunctions: Abstract Wikipedia is going to have its public preview within the next few weeks, here is the preview.

Annual Goals Progress on Volunteer Support
See also blogs: Global Advocacy blog · Global Advocacy Newsletter · Policy blog · WikiLearn News · The Wikipedia Library · list of movement events

• Gender gap: The Celebrate Women 2026 is coming! The Wikimedia Foundation will host a kick-off celebration that will work as a welcome session for both organizers and participants on March 5 at 13:00 UTC.
• Language: New edition of the Language and internationalization newsletter highlights new feature developments and improvements in various language-related technical projects.
• Let’s Connect Learning Clinic: Watch the recordings of past learning clinics about Wikipedia’s 25th Birthday Tool and Strengthening Local-Language Admin Communities.
• Wikimedia Research Showcase: You can watch the recording of this month research showcase whose theme is about "AI and Communities".
• Hubs: Lessons from hub pilots.
• Banners & logo policies: Wikimedia Foundation has adopted new and updated policies regarding the use of banners, logo changes, and blackouts on the projects, particularly for advocacy purposes.
• Digital Safety: The next edition of Digital Safety Office Hours will be on Mar 27 at 9:00 UTC and 19:00 UTC. The session will explore practical threat modelling: a structured way to think about risks, assess your exposure, and make informed choices.

Annual Goals Progress on Effectiveness
See also: Progress on the annual plan

• Wikimedia Enterprise: Ecosia Enriches Search Results and AI Answers with Wikimedia Enterprise.
• Human centered AI: Members of the Wikimedia Enterprise team presented on "Wikipedia in the Age of AI and Bots" at the seminar of Stanford’s Institute for Human-Centered Artificial Intelligence.
• Inclusive AI: Advancing Open, Inclusive AI with Free and Open Knowledge at the India AI Impact Summit 2026.

Other Movement curated newsletters & news
See also: Diff blog · Goings-on · Planet Wikimedia · Signpost (en) · Kurier (de) · Actualités du Wiktionnaire (fr) · Regards sur l’actualité de la Wikimedia (fr) · Wikimag (fr) · Education · GLAM · Milestones · Wikidata · Central and Eastern Europe · other newsletters

Subscribe or unsubscribe · Help translate

For information about the Bulletin and to read previous editions, see the project page on Meta-Wiki. Let foundationbulletinwikimedia.org know if you have any feedback or suggestions for improvement!

MediaWiki message delivery 12:36, 3 March 2026 (UTC)

Really amazing progress the Foundation is making with new features. thank you for your hard work! Toadspike [Talk] 20:19, 3 March 2026 (UTC)

What happened?

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

Closing prematurely to avoid having two identical discussions per WP:MULTI, please see the discussion at Wikipedia:Village pump (technical) § Meta-Wiki compromised instead FaviFake (talk) 17:25, 5 March 2026 (UTC)

---

Editing was disabled for over an hour, while in Meta-Wiki, the foundation was editing many people's JS pages. Is there a reason why? Nighfidelity (talk) 17:15, 5 March 2026 (UTC)

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

Miscellaneous

RFC: Baltic bios infoboxes question

As a followup to 2025 RFC on Baltic bios infoboxes, 1940 to 1991.
Which versions of the 2025 RFC infobox decision, should be used? Examples:

• A - Panevėžys, Lithuanian SSR, Soviet Union
• B - Panevėžys, Lithuanian SSR, Soviet Union
• C - Panevėžys, Lithuanian SSR, Soviet Union
• D - Panevėžys, Lithuanian SSR, Soviet Union
• E - Panevėžys, then part of Lithuanian SSR, Soviet Union
• F - Panevėžys, then administered as part of Lithuanian SSR, Soviet Union
• G - Panevėžys, then governed by Lithuanian SSR, Soviet Union

GoodDay (talk) 18:33, 15 January 2026 (UTC)

Additonal options added. GoodDay (talk) 22:21, 15 January 2026 (UTC)

Note1: In essence, the question is whether (A) & (C) are compliant with MOS:GEOLINK

Note2: This question has no relation to the 'currently active' Kaja Kallas footnote RFC, fwiw.

Survey (Baltic bios)

• A E Both the Lithuanian SSR and the Soviet Union are defunct, so it makes sense to link to them. I don't think that runs afoul of GEOLINK, which is more focused on extant places. If you didn't know what the Lithuanian SSR was, you would have to copy and paste that into the search because even if you went to Panevėžys, that doesn't have a link to the Lithuaniun SSR or the USSR. CaptainEek ^{Edits Ho Cap'n!}⚓ 20:46, 15 January 2026 (UTC)

  @CaptainEek: I've added additional options. GoodDay (talk) 22:21, 15 January 2026 (UTC)

  Amended. E seems to solve the problem. F or G would be fine too, but that's just bikeshedding at that point. CaptainEek ^{Edits Ho Cap'n!}⚓ 01:13, 16 January 2026 (UTC)

• Missing options that seemed to be getting support in the discussion at Wikipedia talk:Manual of Style/Linking#A question:
  • "Tallinn, then part of Estonian SSR, Soviet Union"
  • "Tallinn, then administered as part of Estonian SSR, Soviet Union"
  • "Tallinn, then governed by Estonian SSR, Soviet Union"

WP:RFCBEFORE advises trying to resolve a question like this in a regular discussion before calling an RFC. As that discussion was proceeding well, this RFC feels a bit premature, especially since the RFC question seems to disregard it rather than using the outcome to refine. -- Beland (talk) 22:02, 15 January 2026 (UTC)

@Beland: - I've added the additional options, you've mentioned. GoodDay (talk) 22:21, 15 January 2026 (UTC)

Thanks. -- Beland (talk) 22:44, 15 January 2026 (UTC)

• A. Simple, informative, concice. Clarifications on status can be done in page text, not the infobox. - The Bushranger _{One ping only} 22:30, 15 January 2026 (UTC)
• E per MOS:GEOLINK, which gives very clear guidance to avoid [linking] [consecutive comma-separated sequences of two or more territorial units], and instead suggests to space the links out when feasible. I see no compelling reason to deviate from the suggestion given at MOS:GEOLINK, which is further supported by MOS:OVERLINK which states that Links may be excessive even if they are informative. For example, because inline links present relatively small tap targets on touchscreen devices, placing several separate inline links close together within a section of text can make navigation more difficult for readers, especially if they have limited dexterity or coordination. Balance readability, information, and accessibility when adding multiple links in one section of text. Katzrockso (talk) 23:49, 15 January 2026 (UTC)
• E or G, the other options are either too long (F), violate MOS:GEOLINK (A, C, D), or are insufficiently informative (B, which lacks the useful link to the SSR). Gawaon (talk) 02:35, 16 January 2026 (UTC)
• F or G but I prefer F. Anatole-berthe (talk) 08:49, 16 January 2026 (UTC)
• E, F or G. All satisfy MOS:GEOLINK by adding a qualifying phrase between extant and non-extant names. "part of" might be seen as less neutral than the other two, but WP:NPOV concerns would probably be better addressed by a footnote. Indrek (talk) 09:13, 16 January 2026 (UTC)
• E (Summoned by bot) E sufficiently establishes, place name, geographic location and succinctly establishes 'regime at the time', which is pertinent info in most cases. F & G, apart from being over-long, imply that that the place was administered from somewhere else (as a colony) or somehow 'irregularly' ruled. That kind of detail isn't necessary in an infobox and could be confusing.C or D would be acceptable, but lack the clarity of E. Pincrete (talk) 11:26, 16 January 2026 (UTC)
• A, B, C, or D. The other options diverge from one of the most consistent standards we have across en.wiki, consistent enough that readers probably expect it. They are also longer and thus more likely to mess with infoboxes. Give readers credit that they both understand the comma convention that we use everywhere from text to article titles, and that they understand the linear passage of time. "Dallas, administered as part of Texas, United States" is not something that brings the reader additional clarity. CMD (talk) 11:34, 16 January 2026 (UTC)
• E: seems to comply with WP:GEOLINK, is clear and helpful, and allows the user to access the historical area as well as the current place. The two links are all that we need. PamD 13:59, 16 January 2026 (UTC)
• A, C, or E. My feelings are generally that, when a place of birth/death in a person's infobox incorporates a no-longer-extant subnational entity, it's useful to the reader to link that entity so that (if they want it) they have access to further context about the location at that time. For that reason, I think the options that link Lithuanian SSR (or its equivalents) are preferable to those that do not. I'm willing to bend the guidance at MOS:GEOLINK for the sake of this point; I read that guideline as mainly focusing on linking in article prose, and I believe that infobox text serves different needs and so does not need to necessarily follow it strictly. However, I'm also open to E as an option that meets the letter of GEOLINK while losing the least amount of concision. I oppose F and G as essentially just more cumbersome ways of achieving the same compromise as E. ModernDayTrilobite (talk • contribs) 17:06, 16 January 2026 (UTC)
• E seems to me most appropriate to me. While nothing was actually decided in that RFC, there were people in the original discussion who supported the Soviet Union birthplace (including me) that had no problem with a clarifying footnote. This is a good solution, and less cumbersome than F or G, without ceding our preference to the de facto country rather than the de jure one. For the same reason, I don't think the Texas example above is comparable since I don't think the contextualization is as crucial to a typical reader here. CoffeeCrumbs (talk) 05:17, 17 January 2026 (UTC)

  Just to make this more complex for the poor closer, while my preference is E, I'd accept anything A-D over F or G. CoffeeCrumbs (talk) 10:52, 29 January 2026 (UTC)

• A, B, C, D - The first four options are highly common across other bios on Wikipedia GoodDay (talk) 05:34, 17 January 2026 (UTC)
• B (minus typo) or E/G per GEOLINK. Oppose A and C. Nikkimaria (talk) 05:44, 17 January 2026 (UTC)
• A - simple, factual, and informative. --User:Khajidha (talk) (contributions) 16:41, 17 January 2026 (UTC)
• E simple and informativeMwinog2777 (talk) 22:35, 18 January 2026 (UTC)
• E seems like a good compromise, I'd prefer A but can see that will conflict with MOS. I'm less a fan of F and G, rather keep it simple and explain in the related articles. -- LCU ActivelyDisinterested «@» °∆t° 20:39, 20 January 2026 (UTC)

• A > C > (E=F=G) >>> D>B We link to things we don’t expect our reader to understand. It would be stupid for GEOLINK to override that. I am neutral on the wordier options, as I do not understand the distinction between them. — HTGS (talk) 06:12, 21 January 2026 (UTC)
• F but all of these are inaccurate as they do not explain the fact that Baltic States were occupied by Soviet Union de facto, but de iure were still considered to continue to exist as sorveign entities due to illegality of Soviet actions. Tallinn, Soviet occupied Estonia or Tallinn, de iure Estonia, de facto Estonian SSR, Soviet Union would be factually correct and short enough for infobox --~~Xil (talk) 15:57, 24 January 2026 (UTC)

Some discussions I read suggest that some people truly do not understand what the issue is, so assuming good faith, I'll expand on this a bit. Since the first half of 20th century, for reasons hopefully obvious to anyone knowing the slightest bit of history, international law has been discouraging territorial expansion by force. As such an internationally recognised sorveign country being forced to become a part of another country is considered illegal. This includes any acts that attempt to create legal rights and justify land aquisition like establishing puppet states, administrative units etc. From legal perspective such acts are considered null and void, they do not create any rights and are treated as if they do not exist at all. Nobody, of course, is denying that the physical reality is what it is, but it is refered to in terms that only acknowledge the situation on ground, such as that there is military occupation, in this case the occupation of the Baltic states. The non-recognition of Soviet Union annexing the Baltic States is the objective historical reality, not some nationalist fringe view, Wikipedia has multiple, well sourced articles covering the topic , such as State continuity of the Baltic states, which shows that dozens of countries supported this interpretation of the international law during the Cold War. On basis of this being the international law, the Baltic States restored independence during the collapse of Soviet Union and as such it is now part of constitutional laws in these countries. As such options A to E solely listing Soviet Union and its internationally unrecognised Soviet republics are very problematic, and options F and G are only moderately better as they imply that something is up, but don't really explain to the reader that the mainstream view is that de iure the location in question belonged to another sorveign country. Furthermore the Baltic States now have regained contol over their territories, plus it potentialy appears in an article on a living person, who also doesn't think Soviet Union had any right to the land they were born on, there have been multiple cases outside of Wikipedia when such language has been chalanged [37] [38] [39] [40]. Therefore presenting information like this is misleading and can potentially cause problems to people, who whish to actually use Wikipedia as a source ofinformation and copy facts from here. Not to mention that the current debate has gained enough traction to get coverage in the mainstream media in Baltic States, which regard the current state of Wikipedia articles as disinformation and question if this is not a manipulation by Russian propogandists.[41][42] [43]. Ignoring it likely will just keep on provoking further controversies. It is far from WP:NPOV to complitely disregard, what entire countries consider the objective historical reality, on basis of having held a strawpoll, the result of which actually did leave otions for further discussion, such as on adding footnotes etc. In addition, Russia currently is using extrely simmilar tactics to what Soviet Union did in Baltics to justify its attempt to gain lands in Ukraine, which is met with very simmilar international reactions, in that case it appears that there is no problem with listing balanced information in the infoboxes, such as stating it is internationally recognised as Ukrainian territory occupied by Russia, adding footnotes, using de iure/de facto. There are plenty of ways to come up with neutral wording that is short enough e.g. Panevėžys, de facto Lithuanian SSR, Soviet Union, de iure Lithuania or Panevėžys, Soviet occupied Lithuania ~~Xil (talk) 16:42, 1 February 2026 (UTC)

Unfortunetly such option as you are offering is almost never an option to choose from in RFC. And wast majority of editors, wants to stick with maps show, that what we will use. Additionally im amaised of one user who wants to unify all infoboxes, have no idea how he will manage find single solution, to all worlds problems, Balcans, Isreal/Palestine, China/Taiwan, Baltics, Ukraine/Russia and others... BerzinsJanis (talk) 16:58, 1 February 2026 (UTC)

Personally I do not see a problem with there potentially being a broader policy on contested territories, although not all cases are simmilar to this one, Ukraine is, historically some cases of occupation by Axis powers might be, but issues in Balkans, Isreal/Palestine, China/Taiwan, as far as I know, are not. --~~Xil (talk) 18:17, 1 February 2026 (UTC)

• All of these options are highly biased. The only correct option is "Panevėžys, Lithuania" as this was the legal state under international law. If you insist to mention the de facto rule at the time, then the only correct option is "Panevėžys, Lithuania (Soviet occupation)". ~2026-52185-6 (talk) 15:53, 24 January 2026 (UTC)

  This first option is not being added as the consensus in the previous RfC was to include "Lithuanian SSR, Soviet Union" in the place name. The current RfC is about establishing the specifics of how it should be implemented (with regards to linking and wording), and does not intend to rehash the previous RfC. Chaotic Enby (talk · contribs) 17:49, 27 January 2026 (UTC)

• A, C, E, F, G - Lithuanian SSR needs to be linked. - Neptuunium (talk) 09:32, 29 January 2026 (UTC)
• A followed by C, assuming Soviet Union is seen as common word that shouldn't be linked. IMO it rhymes with "cases" like Gandhi and Miriam Adelson. Gråbergs Gråa Sång (talk) 11:01, 29 January 2026 (UTC)
• C/A - Linking to the administrative subdivision but not the administrative superdivision seems fine style wise, but have both linked isn't a problem either. -- Cdjp1 (talk) 17:39, 30 January 2026 (UTC)
• C for compliance with GEOLINK. I don't think the "then administered/governed as part of" needs to be added since it is too verbose for an infobox, which are supposed to be succinct. Aydoh8^{[what have I done now?]} 05:14, 31 January 2026 (UTC)

  Hmm, but C is actually not in compliance with GEOLINK, which states that normally only the first element should be linked? Gawaon (talk) 07:51, 31 January 2026 (UTC)

  Be sure to read the last part of MOS:GEOLINK, which says:

  If the smallest unit is an extant place, but the largest is not, it is preferable to space the links out when feasible, e.g. Kumrovec, then part of Austria-Hungary ([[Kumrovec]], then part of [[Austria-Hungary]]).

  -- Beland (talk) 08:26, 31 January 2026 (UTC)

  Yeah, that's what options E to F are for. They are clearly GEOLINK-compatible. Gawaon (talk) 08:30, 31 January 2026 (UTC)

  I don't believe that an extra 3 words is "too verbose" for an infobox. They don't have to be the shortest possible way to phrase something. I'm replying to you as a reply to anyone that has made this argument, not that I've singled you out specifically. Bluefist ^talk 23:39, 17 February 2026 (UTC)

• Comment There should be no consideration for the E, F and G options. The infobox person documentation is pretty clear on the three-way formula for listing geos. The previous proferring and edit warring for these has only been driven by off-wiki campaigning by nationalists. Another example: De-facto is how we go, a person born in the Islamic Emirate of Afghanistan is listed as such without consideration for the legitimacy of the government in the 1990s or now. Gotitbro (talk) 08:14, 31 January 2026 (UTC)

  I kinda doubt that? Certainly a simple Afghanistan is sufficient to such cases; no need to make things more complicated than they have to be. Gawaon (talk) 08:33, 31 January 2026 (UTC)

  Also, the form E is explicitly suggested by GEOLINK for such cases (where the second-level unit no longer exists), while A, C, D are arguably explicitly forbidden (or at least strongly discouraged) by GEOLINK. That has nothing whatsoever to do with nationalist feelings. Gawaon (talk) 08:37, 31 January 2026 (UTC)

  Islamic Emirate of Afghanistan (1996–2001) is what I was primarily talking about. Listing entities should not be a question of complication but a question of fact. The entire reason simply listing Lithuania, Estonia, Latvia was explicitly and overwhelmingly rejected at Infoboxes#RFC:_Baltic_states_birth_infoboxes.

  This RfC would then appear to be mostly semantics. As for GEOLINK and its 'preference', that is one without any major precedent for all the bios and BLPs I have trawled since I first opened Wikipedia haven't come across any major ones following it. It is safe to say we can ignore that preference.

  As for nationalist driven canvassing concerns, the only reason I mention it was after coming across the massive off-wiki media and social media campaign in the Baltics attempting to alter how we do things at enwiki (reported at the Signpost). The edit wars, disruptions, discussions et. al. and subsequent RfCs to tackle that, all stem from that very coordinated effort and editors should be very wary of that. Gotitbro (talk) 08:58, 31 January 2026 (UTC)

  Sure, I'm in agreement with the outcome of the earlier RfC. This one is about settling the details. However, E to G are fully in agreement with the outcome of the earlier RfC and are valid options, should one of them manage to gain (relative) consensus. Gawaon (talk) 11:09, 31 January 2026 (UTC)

  "Administered" is often used in lieu of "occupied" on enwiki which was of course rejectes. So no I would not say that these are in consonance with the earlier RfC. Gotitbro (talk) 14:06, 31 January 2026 (UTC)

  Characterizing any outcome as "overwhelming" misrepresents a discussion where significant concerns about WP:NPOV were raised regarding the unique international legal status of the Baltic states - whose Soviet annexation was never recognized de jure by most Western nations, a fact extensively documented in the article State continuity of the Baltic states.

  The RFC result remains disputed, and editors who disagree with its application have legitimate grounds for doing so based on policy concerns that were not adequately addressed in the original discussion. Seungsahn (talk) 19:49, 31 January 2026 (UTC)

  If you think the earlier RfC was improperly closed, you'll have to challange the closure. Otherwise there's nothing more to be done about it and we can really focus on the new one. Gawaon (talk) 20:24, 31 January 2026 (UTC)

  Noting that the closure has already been challenged once, twice, thrice, unsuccessfully. Chaotic Enby (talk · contribs) 21:33, 31 January 2026 (UTC)

  I did not know that, thanks for the heads up. To be noted that the editor above has been edit warring exactly over this [44].

  I will also inform editors of the failed RfC chsllenges at Talk:Kaja Kallas where a very related discussion is ongoing. Gotitbro (talk) 05:42, 1 February 2026 (UTC)

  I kind of expected as much, though thrice is indeed more than I expected! All right then, so we can well and truly consider the old RfC as settled for good and move on with the discussion. Gawaon (talk) 08:13, 1 February 2026 (UTC)

  The number of times a closure has been challenged doesn't address whether the underlying concerns have merit.

  The challenges occurred precisely because the RFC failed to adequately engage with the distinct legal status of the Baltic states under international law - a substantive issue that remains unresolved regardless of procedural outcomes. "Settled" and "correct" are not the same thing. Seungsahn (talk) 17:18, 1 February 2026 (UTC)

  Would you be satisfied with a footnote noting that the occupation was considered illegal by many countries, as proposed on the other RFC? -- Beland (talk) 19:39, 1 February 2026 (UTC)

  A footnote would be an improvement over the current format, but I have concerns that it still places the legitimizing framing ("Estonian SSR, Soviet Union") in the most prominent position while burying the critical legal context where most readers won't see it. The purpose of an infobox is to convey key facts at a glance - if the illegality of the occupation is important context, it shouldn't be hidden in a footnote. I'd prefer the infobox text itself to reflect the reality, such as "Tallinn, Soviet-occupied Estonia," with a footnote providing further detail. But I recognize this is a discussion and I'm open to hearing other perspectives. Seungsahn (talk) 19:50, 1 February 2026 (UTC)

  That ship has sailed since the three-part format (with SSR as middle part) was already established by the preceding RfC. Gawaon (talk) 20:05, 1 February 2026 (UTC)

• A, C, or E. per ModernDayTrilobite. Lithuanian SSR should be linked to provide context for those who seek it. Soviet Union is well-known enough that a link can be omitted to reduce consecutive linkage. Options F and G are too cumbersome and we'd probably need another RFC to decide on which (ad)verb exactly we should use (because it's foreseeable that someone will ask for the (ad)verb to be "occupied", like Xil already did above). We can avoid the whole (likely heated) debate about the question which (ad)verb describes the situation most accurate/neutral by simply not including an (ad)verb to begin with. Nakonana (talk) 17:25, 1 February 2026 (UTC)
• F though none of the options listed adequately address the underlying WP:NPOV concern. All options A through E present "City, SSR, Soviet Union" as the primary framing, which implies a legitimacy that was explicitly rejected under international law for over 50 years. The Soviet annexation of the Baltic states was never recognized de jure by the United States, United Kingdom, and most Western democracies — a position maintained continuously from the Welles Declaration (1940) until independence was restored in 1991. Baltic diplomatic missions operated in Washington, London, and other capitals throughout the entire Soviet period. This is extensively documented at State continuity of the Baltic states. F at least gestures toward the complexity of the situation, but the most accurate and neutral formulation would acknowledge the occupation context directly — for example, "Tallinn, Soviet-occupied Estonia" - which reflects both de facto Soviet control and the de jure continuity recognized by the international community. An explanatory footnote (as in the separate Kaja Kallas RFC) would be a further improvement regardless of which display option is chosen, as it provides readers with the context needed to understand why this situation differs fundamentally from other Soviet republics such as the Ukrainian SSR or Belarusian SSR, whose incorporation into the USSR was internationally recognized. I also note that this RFC's scope is limited to linking style within an already-contested format. The broader question of whether "City, SSR, Soviet Union" is itself appropriate for the Baltic states — given their unique legal status — remains unresolved and warrants a dedicated RFC that explicitly addresses this distinction. Seungsahn (talk) 20:08, 1 February 2026 (UTC)

  The question asked in your last sentence was already answered by the previous RFC. -- Beland (talk) 23:15, 1 February 2026 (UTC)

• A or C or E. Lithuanian SSR should be linked; if that is linked, I don't think linking Soviet Union hurts or helps much. And if we are going to separate the blue links, it should be as short as possible. LordCollaboration (talk) 20:48, 3 February 2026 (UTC)
• B:

1: Per WP:GEOLINK, the examples show only the first item of each list being linked. I propose the same be done here.

2: Also, we want to avoid MOS:OVERLINK. The more words are linked, the less likely each linked item is to be viewed. As such, links should be used sparingly, and only when necessary. I believe that only linking the first item here would be the best.

3: WP:INFOBOX states The purpose of an infobox is to summarize, but not supplant, the key facts that appear in an article. I believe this is farther evidence that links should be used sparingly in the infobox, especially when it comes to location lists.

4: We should avoid unnecessary controversy when possible, and just listing the location avoids extra debates over phrases such as "then part", which are included in some of the other options.

Because B only links the first item here, I think we should apply this one.

Wikieditor662 (talk) 07:19, 8 February 2026 (UTC)

One of the examples, the one for a former country, contains two links. -- Beland (talk) 09:05, 8 February 2026 (UTC)

My point is not that it's required to be this way, but that it should be preferable. Wikieditor662 (talk) 18:31, 9 February 2026 (UTC)

• B or E, given MOS:GEOLINK. Thedarkknightli (talk) 11:01, 8 February 2026 (UTC)
• E I believe is an acceptable compromise. I've been reading the past discussions about this subject and as an uninterested (well, not really uninterested, just someone who doesn't have a vested interest in either decision) editor it seems that every RFC discussion has been closed with a very shaky consensus. This sometimes happens when non-wikipedia edtitors are interested in a subject and it is continually reopened and discussed. I believe that there are some users who are very invested and perhaps some that have broken rules. However, to me that indicates that there is a real issue that really needs to be solved with a grumble rather than one side "getting their way". I have also seen seasoned editors, I think even an admin, acting very strong armed and rude. I think they had lost their assumption of good faith from rule breakers and frustration. E is a good compromise because it addresses both of the sides' problems. It is accurate, in that the Baltics were commonly understood to be subunits of the Soviet Union, and it is thoughtful of modern opinions and historical precedent in those countries about the rejection of those states as units of the Soviet Union. I also believe it has precedent in Wikipedial, though I cannot find any specific examples which may weaken this point. I speak of "X from Y formerly known as Z". I vageuly remember this for countries such as Rhodesia or British India persons. Bluefist ^talk 23:36, 17 February 2026 (UTC)
• E Probably works best here in terms of WP:GEOLINK. --TylerBurden (talk) 17:15, 23 February 2026 (UTC)

Discussion (Baltic bios)

Note that this is only about what to link. GoodDay (talk) 18:33, 15 January 2026 (UTC)

Why open this before Wikipedia talk:Manual of Style/Linking#A question has concluded? Even that discussion you started parallel to Wikipedia talk:Manual of Style/Infoboxes#Baltic birth places and linking (initial post by me). This looks like WP:forum shopping. Jähmefyysikko (talk) 19:03, 15 January 2026 (UTC)

My question at MOS:GEOLINK, was about what to link or not link. My questoin was not about altering the 2025 RFC decision or amending MOS:GEOLINK. GoodDay (talk) 19:18, 15 January 2026 (UTC)

Starting a new discussion just because editors are unwilling to operate strictly within the parameters you've set, does not seem appropriate. Jähmefyysikko (talk) 19:34, 15 January 2026 (UTC)

That's not why I began this RFC. GoodDay (talk) 19:40, 15 January 2026 (UTC)

And there was also Wikipedia talk:Manual of Style/Infoboxes#RFC: How to link Baltic birth/death places, 1940 to 1991 which was shut down. Jähmefyysikko (talk) 19:58, 15 January 2026 (UTC)

I shut it down per advice by @Szmenderowiecki:, as its scope covered (example:"then part of..." option) areas beyond just linkage. GoodDay (talk) 20:02, 15 January 2026 (UTC)

There is a best-of-both-worlds solution, which should've been brought up in the December 2025 RfC.

Why don't ya'll just add both de jure identifiers and de facto identifiers, possibly with a note explaining the irregularities. For example, the birth place of Vilnius, Lithuanian Soviet Socialist Republic should be changed to Vilnius, Lithuania (de jure)/Lithuanian Soviet Socialist Republic, Soviet Union (de facto), along with an explanatory note that Lithuania regained its de facto independence in 1990. The Act of the Re-Establishment of the State of Lithuania restored state continuity throughout the 1940–1941 and 1944–1991 Soviet occupation.

Proposed explanatory notes for use:

• Estonia: Estonia regained its de facto independence in 1991. Throughout the 1940–1941 and 1944–1991 Soviet occupation, Estonia's de jure state continuity was preserved by diplomatic representatives and the government-in-exile.
• Latvia: Latvia regained its de facto independence in 1991. The declaration On the Restoration of Independence of the Republic of Latvia restored and asserted state continuity throughout the 1940–1941 and 1944–1991 Soviet occupation.
• Lithuania: Lithuania regained its de facto independence in 1991. The Act of the Re-Establishment of the State of Lithuania restored and asserted state.

Have a nice day.~2026-67161-8 (talk) 20:32, 30 January 2026 (UTC)

This RfC is not about explanatory notes at all. They can be used (or not) independently of its outcome. Gawaon (talk) 21:29, 30 January 2026 (UTC)

EFNs are being discussed at Talk:Kaja Kallas#RfC: Footnote in infobox birthplace. I would say, though, that the "de jure" status is disputed. From the Soviet perspective, Lithuania was both de jure and de facto part of the Soviet Union. -- Beland (talk) 01:47, 31 January 2026 (UTC)

I've just crossposted my comment in there.~2026-67161-8 (talk) 08:48, 31 January 2026 (UTC)

Hello everyone! I will be monitoring this discussion as an uninvolved administrator, following GoodDay's request at Wikipedia:Administrators' noticeboard. GoodDay, I invite you to briefly read our RfC formatting guidelines, as the current format breaks the automatic transclusions. The RfC question should be signed (or at least timestamped with ~~~~~), and neutrally worded, without making references to policies or guidelines that might support some answers. These can be elaborated on separately, for example in an additional heading providing background context or in your own !vote. Chaotic Enby (talk · contribs) 20:36, 15 January 2026 (UTC)

I made adjustments to the 'RFC question'. Would appreciate advice on wording. Should I keep or remove mention of the 2025 Dec RFC? GoodDay (talk) 20:41, 15 January 2026 (UTC)

I also made a bit of an adjustment to note1, which was kind of snarky; it still might be better if it was just removed and GoodDay put a vote with a rationale focused on the problem, or had a background about why this is an issue. CaptainEek ^{Edits Ho Cap'n!}⚓ 20:43, 15 January 2026 (UTC)

It wasn't meant to be snarky (the note), but I thank you for re-writing it. I would be grateful, if you'd re-do the questionaire. GoodDay (talk) 20:47, 15 January 2026 (UTC)

Seconding these options. Writing an initial !vote that explains your rationale is a common practice in RfCs, and so is the alternative of a standalone background section, separate from the RfC question. Chaotic Enby (talk · contribs) 21:05, 15 January 2026 (UTC)

As pointed out in the earlier discussions I've linked above, an option "Panevėžys, then part of Lithuanian SSR, Soviet Union" should be included. Jähmefyysikko (talk) 21:14, 15 January 2026 (UTC)

I explained above, why I didn't include that option. That option would've went beyond the scope of this RFC. GoodDay (talk) 21:18, 15 January 2026 (UTC)

In the earlier discussion, that option had some support, which is why it should be included. As explained to you already, the RFC did not specify a particular format, only that the SSR and Soviet Union should be included. This was confirmed by @Beland, who closed the RFC. Jähmefyysikko (talk) 21:23, 15 January 2026 (UTC)

This RFC is about linkage. GoodDay (talk) 21:27, 15 January 2026 (UTC)

The RFC is not neutral if the options are artificially limited. Jähmefyysikko (talk) 21:35, 15 January 2026 (UTC)

The option you wanted included, was excluded because it went beyond the scope of this RFC, per advice from another editor. PS - If I'm given clearance to add your option? I will do so. GoodDay (talk) 21:38, 15 January 2026 (UTC)

From what I understand, there is a disagreement about the intended scope of the RfC. To make sure we're on the same page, do you both agree that this RfC aims to decide on specific details of the decision achieved at Wikipedia talk:Manual of Style/Infoboxes#RFC: Baltic states birth infoboxes? And the disagreement is on whether this RfC addresses it in part (only being focused on the linking style) or in full, am I correct? Has there been prior discussion about how a follow-up RfC was to be structured? Chaotic Enby (talk · contribs) 21:51, 15 January 2026 (UTC)

Yes, I agree on the aim. If the choice of options is limited, then this RFC is only partial in that it does not address whether City, SSR, Soviet Union (with the preferred linking) or City, then part of SSR, Soviet Union (or some other variant) should be used. I am not aware of a prior discussion. Jähmefyysikko (talk) 21:59, 15 January 2026 (UTC)

I would like to add this following information for consideration. [45]

That shows how many times Estonia, Estonia SSR and Solviet Estonia are used in literature and period publications, by years.

I believe that it shows clear data, how in this example Estonia was used a lot lot more often than Estonia SSR and Solviet Estonia combined.

There have been many arguments about using period correct names, then this data should be one of main criteria choosing period correct name. Just because Estonia SSR was on map, does not mean it as a name was commonly used, as per linked data. Also judjing by period ussage using only Estonia SSR does does violate Wikipedia:NPOV and Wikipedia:UNDUE

There are also many other ways to show period correct status and modern day status, like in Crimea example. BerzinsJanis (talk) 19:26, 10 February 2026 (UTC)

A previous RFC already decided which names to use. This RFC is just asking how they should be linked.-- Beland (talk) 23:59, 10 February 2026 (UTC)

There are new options in this RFC, so I assume, its only fair to add new data into considerations, especially since there were many arguments about common names in period. It just shows how poorly executed was last RFC. I will respect this RFC decision, but it doesn't mean, that this topic has consensus Wikipedia:NOCONSENSUS and Wikipedia:CONSENSUSCANCHANGE BerzinsJanis (talk) 07:18, 11 February 2026 (UTC)

I'm willing to add the option the other editor wants. If given clearance to do so. GoodDay (talk) 21:56, 15 January 2026 (UTC)

As the RfC has just started and there hasn't been substantial voting yet, I am giving you clearance to do so. An alternate suggestion I may offer, although it is not a requirement, is to pause the voting and allow a few days for editors to suggest additional options, then restart the RfC anew. Chaotic Enby (talk · contribs) 22:02, 15 January 2026 (UTC)

Additional options have been requested. I'll add them in & notify the 'two' suryer commentors of the update. GoodDay (talk) 22:04, 15 January 2026 (UTC)

Beland has pointed out a previous discussion at Wikipedia talk:Manual of Style/Linking#A question, which brought forward additional options. Do you wish to either continue the conversation there, or use the current state of that conversation as a basis for the RfC options? Chaotic Enby (talk · contribs) 22:07, 15 January 2026 (UTC)

Have it here, as I've added those options, too. GoodDay (talk) 22:30, 15 January 2026 (UTC)

Absolutely disingenuous. None of these options use the word occupied. If the USSR is mentioned at all, it should be "then occupied by the USSR". Otherwise, where are the options for simply Panevėžys, Lithuania?

Extremely biased "poll". ~2026-64380-6 (talk) 17:30, 30 January 2026 (UTC)

I agree. The RFC options were framed in a way that excluded the most defensible neutral position from the start. Where is the option for simply "Panevėžys, Lithuania"? The United States and most Western democracies never recognized the Soviet annexation of the Baltic states - this wasn't some fringe position, it was the official legal stance maintained continuously from the Welles Declaration in 1940 until independence was restored in 1991. Baltic diplomatic legations operated in Washington throughout the entire Soviet period. Under this interpretation, which was held by the majority of Western nations, Lithuania never ceased to exist as a sovereign state. Excluding this option from the RFC while offering multiple variations of "Lithuanian SSR, Soviet Union" predetermined the outcome toward the Soviet/Russian legal interpretation.

The inconsistency with Wikipedia's treatment of other unrecognized entities makes this even more glaring. Wikipedia consistently uses "Richmond, Virginia" for people and institutions from the Confederate era (1861-1865), not "Richmond, Confederate States of America" - despite the Confederacy exercising de facto control at the time. If de facto control by an unrecognized breakaway government doesn't warrant changing location designations, why should de facto control by an unrecognized illegal annexation? The RFC should have included "Panevėžys, Lithuania" as an option, or at minimum "Panevėžys, Lithuania (then under Soviet occupation)" - which would acknowledge the historical reality without adopting the Soviet legal position that Western nations explicitly rejected for 50 years.

It's also worth noting that the previous RFC did not reach real consensus. The closure stated that Option A was "most popular" - but popularity is not consensus per WP:NOTAVOTE. The closer acknowledged "competing interpretations of neutrality, clarity, and accuracy," which indicates genuine disagreement on policy grounds rather than consensus. The arguments grounded in international law and WP:NPOV were never properly weighed against raw participation numbers. And the RFC was initiated by User:Glebushko0703 (now blocked), who had already made mass edits to "SSR" format before starting the RFC - hardly a neutral process. Building a new RFC on top of that flawed foundation doesn't fix the underlying problem. Seungsahn (talk) 18:19, 30 January 2026 (UTC)

It doesn't matter who opened an RfC as long as it was completed and closed property – which was the case here, confirmed by subsequent discussion, for all I know. So it's time to respectfully step away from the horse carcass and instead constructively work on filling out the details – which is what this RfC is doing. Gawaon (talk) 18:31, 30 January 2026 (UTC)

Wikipedia:Polling is not a substitute for discussion Seungsahn (talk) 18:37, 30 January 2026 (UTC)

"A since it was under soviet rule"

Does this seem like a discussion to you? Is this vote as worthy as the others? Seungsahn (talk) 18:39, 30 January 2026 (UTC)

@Seugsahn: you should place your "A", in the survey subsection. GoodDay (talk) 21:31, 30 January 2026 (UTC)

User:Seungsahn should clarify, but I think they were quoting a vote from the 2025 RFC, rather than casting a vote in this one. Indrek (talk) 09:32, 2 February 2026 (UTC)

RFCs do not have to be "closed". They should stay open for as long as necessary to get an answer. If the answer is patently obvious, then nobody should waste time writing an official statement of what everyone else already knew. This is documented in WP:RFCEND. WhatamIdoing (talk) 23:24, 30 January 2026 (UTC)

"Panevėžys, Lithuania" was ruled out by the RFC which is linked to from this RFC's introduction. -- Beland (talk) 01:39, 31 January 2026 (UTC)

Im amaised also at that, as the most neutral would be mentioned both entities and status at that time. Somehow such option is never considered or offered in survey. In fact you don't even need to search for USA examples when there are plenty here in Europe, with far less nuances and legality questions. Yet there are users who push for only solviet narative. BerzinsJanis (talk) 10:40, 1 February 2026 (UTC)

Feel free to suggest options that haven't been discussed yet. Note that a footnote that would explain the disputed status has already been proposed at Talk:Kaja Kallas#RfC: Footnote in infobox birthplace. WP:AGF requires that we assume other editors have non-nefarious reasons for doing what they do, even if we don't agree with their positions. Editors are allowed to have a specific point of view. When I collaborate with editors who challenge me because they come from a different point of view, if we work for understanding and look at reliable sources, articles come out with stronger sourcing and we create a version we all find fair and neutral. -- Beland (talk) 11:38, 1 February 2026 (UTC)

What about Crimea option? stating de-jure and de-facto control? Im shure there was extensive RFC for it.

Like "Internationally recognised as Latvia territory occupied by USSR (see State continuity of the Baltic states)"?? Add links where needed. Its neutral, it gives facts, and Baltic situation require it. But im shure there will be people who will talk about maps, de-facto controll, too much text and so one, jsut to keep solviet union there. BerzinsJanis (talk) 17:05, 1 February 2026 (UTC)

And the RFC was initiated by User:Glebushko0703 (now blocked), who had already made mass edits to "SSR" format before starting the RFC - hardly a neutral process. For an account that has been created a mere two days ago you are surprisingly familiar with wiki processes and things that happened months before your account creation. Nakonana (talk) 17:38, 1 February 2026 (UTC)

I'd appreciate if we could focus on the substance of the arguments rather than speculating about my account. The point stands: the RFC was initiated by a now-blocked user who had already made mass edits prior to starting it. Whether that concern is raised by a new account or an established editor doesn't change its validity. Seungsahn (talk) 17:44, 1 February 2026 (UTC)

I would agree if there weren't massive news reports in the Baltic countries and reddit posts that tell people to come to those RfC and "control"* the English Wikipedia (*that word was used in at least one of the news articles). This violates WP:CANVASSING policies and is something that the closer of an RfC needs to be aware of (which you probably already know given your familiarity with wiki processes). You are also not the only new account in this RfC who doesn't have any contributions anywhere on Wikipedia outside the Baltic birth place question. Nakonana (talk) 17:52, 1 February 2026 (UTC)

Baltic birthplace is sensitive topic in Baltics, its a bit foolish to expect that there wont be any new editors, or reapearing ones when it has gained mainstream media attention in all 3 Baltic states. Like it or not, it will generate new editors, who will want to join topic and there is no way to figure out if they are here on there own wish, or someone asked them. BerzinsJanis (talk) 17:56, 1 February 2026 (UTC)

Tbh I think you guys are shooting yourself in the foot with this behavior. The more you push, the harder the pushback. This kind of behavior has even the potential to alienate people who'd usually be sympathetic towards you and your cause under different circumstances [46][47]. Nakonana (talk) 18:21, 1 February 2026 (UTC)

And would your opinion would be in this matter? Please provide neutral opinion on this matter. One that could be acceptable for most.

Also RFC are not popularity contest, but argument based. BerzinsJanis (talk) 18:24, 1 February 2026 (UTC)

Please provide neutral opinion on this matter. One that could be acceptable for most. Then are you actually asking for my opinion if you only want to hear a "neutral" opinion? And why would a "neutral" opinion need to be one that is acceptable for most? A third party expert could give their neutral opinion in a court, but that neutral opinion may not be liked — neither by the accusing party nor by the accused party —, because the neutral opinion might come to the conclusion that both parties are in the wrong.

Note: I have already voted in the Survey section.

At this point I also note that you are a new account who doesn't have any edits outside the Baltic birthday question and who also appears to be quite familiar with wiki processes despite being a newbie. Nakonana (talk) 18:46, 1 February 2026 (UTC)

Since wikipedia is place for neutral data sharing, and pushing single point of view is against policies, you should probably re read wikipedia policies.

Ahh how nice, if you would have taken an deeper look at my account you would find that i have made really many policies mistakes at start, because i had no idea what Im doing. Lucly university student council role, did help me to adjust to speak more policy based than feeling based. And since we are pointing things out, I do wounder why you are so against term "Occupied" when it is internationaly recognised fact, see State continuity of the Baltic states, is it because by your own words, you are from russia? You are entitled to your opinion, but please here provide arguments for and/or against it. So far your opinion of rest of variants beeing to "cumbersome" does not hold to well against Crimea example and Im shure it had its own fights in RFC. BerzinsJanis (talk) 18:57, 1 February 2026 (UTC)

Editors are allowed and expected to have non-neutral opinions. This is actually helpful because readers have non-neutral opinions, and it's necessary to look at any disputed topic from multiple perspectives in order to make sure that our text isn't taking a stand that any of them feel is non-neutral, and to make sure we're giving an overall fair description. -- Beland (talk) 19:47, 1 February 2026 (UTC)

I'm against "occupied" because this is not how those places are referred to most of the time when they are being talked about outside of the Baltic states themselves. Furthermore, several adverb have been suggested above, so simply for the sake of pragmatism, to not have another debate over which adverb is the most "accurate", most "neutral" one, I'd opt for an option that doesn't use any adverb at all, therefore my preferred phrasing would be "city, then part of xSSR, Soviet Union" with xSSR being a link to the corresponding article. This "then part of xSSR" is also the option that I've seen being used on German wiki for example, so it seems like a good middle ground. Nakonana (talk) 20:00, 1 February 2026 (UTC)

Also me being from Russia means I was born there. However, I have not lived there since the 1990s. Nakonana (talk) 20:02, 1 February 2026 (UTC)

Ahh I see.... So using simply Latvia, Estonia or Lithuania should be enought, since these were terms used to reffer to them outside strict political setting. So what are we going to do now? Now there are two terms used, unofficial common name and official used only in specific context.

As for being from russia, just an mention, like you mentioned my account age. All is fine ^^ BerzinsJanis (talk) 20:06, 1 February 2026 (UTC)

The previous RFC decided that Society Union should be included. -- Beland (talk) 23:13, 1 February 2026 (UTC)

This isn't about "pushing" or "causes" - it's about whether Wikipedia's treatment of the Baltic states complies with WP:NPOV given their unique legal status under international law. The arguments stand or fall on their merits, regardless of who makes them or how many people care about the issue.

Seungsahn (talk) 18:26, 1 February 2026 (UTC)

Wikipedia:NPOV means neutral editing, not neutral content. So, what BerzinsJanis asked of me above[48][49] is not necessarily what WP:NPOV means. Nakonana (talk) 18:54, 1 February 2026 (UTC)

If you have concerns about WP:CANVASSING, those should be raised through the appropriate channels, not used to dismiss arguments in this discussion. The same could be said about the original RFC - there was documented off-wiki canvassing on both sides, including editors who were later blocked. None of this changes the substantive point: the RFC was initiated by a now-blocked user who had already made mass edits, and the distinct legal status of the Baltic states under international law remains inadequately addressed.

As for new accounts engaging with this topic - the Baltic birthplace issue has recieved significant media coverage recently, which naturally draws attention from people who care about accurate historical representation. New editors becoming aware of Wikipedia discussions through news coverage and choosing to participate is not inherently improper. I'm here making policy-based arguments supported by verifiable sources. If those arguments are wrong, I welcome a substantive rebuttal. Seungsahn (talk) 17:56, 1 February 2026 (UTC)

What I'm doing is an appropriate way to address canvassing issues per WP:MEAT: In votes or vote-like discussions, new users may be disregarded or given significantly less weight, especially if there are many of them expressing the same opinion. Their comments may be tagged with a note pointing out that they have made few or no other edits outside of the discussion. I'm not aware of canvassing regarding the original RfC. The now blocked user was blocked for personal attacks iirc, not for canvassing.

status of the Baltic states under international law remains inadequately addressed. — why does it need addressing by the English Wikipedia though? Crimea also currently has a status of it not being accepted as legit part of Russia, yet wiki Commons is currently applying Russian freedom of panorama laws on contributions from Crimea instead of the more restrictive Ukrainian freedom of panorama laws. Wiki p rojects don't always do what you expect (or demand) them to do. Nakonana (talk) 18:35, 1 February 2026 (UTC)

I do want to remind that RFC is not a popularity contest and actual voting is discoridged if possible. Also if you look at Crimea info box you will find this text "Internationally recognised as Ukrainian territory occupied by Russia (see Political status of Crimea)" claiming that Crimea is accepted by Wikipedia as being part of russia, is clear missinformation and pushing single point of view. BerzinsJanis (talk) 18:39, 1 February 2026 (UTC)

I was talking about wiki Commons[50][51][52]. Nakonana (talk) 21:00, 1 February 2026 (UTC)

On WP:MEAT - noted, but these comments are in a discussion shaping a new RFC, not a vote. Arguments here should be evaluated on their merits regardless of account age.

On "why does it need addressing" - because this is literally what this discussion is for. We're here to shape a new RFC on Baltic bios infoboxes. If the distinct legal status of the Baltic states under international law isn't relevant to that RFC, what is? The Crimea/Commons example doesn't establish that Wikipedia should ignore internationally recognized legal distinctions - WP:NPOV is a core policy of this project and applies regardless of what other Wikimedia projects do. Seungsahn (talk) 18:43, 1 February 2026 (UTC)

In fact this RfC doesn't need to be "shaped", it's already well underway and will have an outcome of some kind. Gawaon (talk) 19:36, 1 February 2026 (UTC)

Would the following not be neutral enough? Considering the Baltic states were de-jure existing throughout the occupation.

- Panevėžys, Soviet-occupied Lithuania ~2026-57214-4 (talk) 02:47, 31 January 2026 (UTC)

@Chaotic Enby: I moved the IP's post to 'here', as it was located above the 'survey' sub-section. GoodDay (talk) 03:02, 31 January 2026 (UTC)

Thanks a lot. Noting that this is a follow-up to the previous RfC, which offered a "Panevėžys, Lithuania" option. There was consensus there that "Panevėžys, Lithuanian SSR, Soviet Union" was preferable, and the current RfC is only to figure out the specific linking and wording to implement that option. Chaotic Enby (talk · contribs) 11:30, 31 January 2026 (UTC)

I know this RFC covers Baltics bios, only. But I'm hoping whatever is decided here, will be applied to bios of all people born and/or died in all 15 Soviet republics. GoodDay (talk) 21:47, 30 January 2026 (UTC) IMHO, this "not a vote" notice should be deleted, as it may cause tensions. GoodDay (talk) 16:29, 31 January 2026 (UTC)

I've moved your comment to the discussion section, to not have it above the RfC question itself. Not commenting on the merits of the suggestion. Chaotic Enby (talk · contribs) 17:01, 31 January 2026 (UTC)

Yeah, that would make a lot of sense, unless options F or G are chosen. (They would be inapplicable to other SSRs.) Gawaon (talk) 18:00, 31 January 2026 (UTC)

Baltic states in solviet union are a bit special (They were never part of it de jure and almost no state recognised there occupation) compared to other solviet republics, to whom you can make arguments about there legality in solviet union. Trying to push for the same solution seams ood at the best, pushing some narative at the worst. BerzinsJanis (talk) 10:43, 1 February 2026 (UTC)

In principle yes, but it depends on the chosen option. A to E would work equally well for all. Gawaon (talk) 11:08, 1 February 2026 (UTC)

From offered variants I say F is the best then E. Im still amaised why there are no offers like Latvia, then occupied by solviet union. Especially since no one disputes the occupation fact, and only few countries in the world recognised it. BerzinsJanis (talk) 11:24, 1 February 2026 (UTC)

Option E, would be better suited for the 'body' of the bio, IMHO. Options F & G are a mess. GoodDay (talk) 15:28, 1 February 2026 (UTC)

I agree with BerzinsJanis. The Baltic states represent a unique case that cannot be treated identically to other Soviet republics. Unlike the Ukrainian SSR, Belarusian SSR, or other constituent republics, the Soviet annexation of Estonia, Latvia, and Lithuania was never recognized de jure by the majority of Western nations.

Applying the same infobox format used for republics whose Soviet status was internationally recognized to countries whose annexation was explicitly deemed illegal creates a false equivalence and raises serious WP:NPOV concerns. The RFC did not adequately grapple with this distinction, and treating the Baltic situation as identical to other SSRs does appear to advance a particular historical narrative rather than reflect the nuanced international legal reality. Seungsahn (talk) 16:53, 1 February 2026 (UTC)

The Baltics aren't special, IMHO. But of course, you & I won't likely ever agree on this matter. GoodDay (talk) 16:58, 1 February 2026 (UTC)

This isn't a matter of opinion or what either of us personally believes. The non-recognition of the Baltic annexation is a documented historical and legal fact.

The Baltic states kept functioning diplomatic missions in Western capitals throughout the Soviet period. This distinct legal status is extensively documented in the article State continuity of the Baltic states and is not comparable to the status of other Soviet republics. Whether the Baltics are "special" isn't a matter of IMHO - it's a matter of verifiable historical record. Seungsahn (talk) 17:01, 1 February 2026 (UTC)

We're not going to agree on this matter. GoodDay (talk) 17:03, 1 February 2026 (UTC)

I notice you haven't addressed the substantive point. The distinct legal status of the Baltic states isn't something we need to "agree" on - it's documented fact supported by decades of international state practice and extensive reliable sources. If you believe this documented historical record is incorrect or irrelevant to the infobox question, I'd welcome a policy-based argument explaining why. Simply stating we won't agree doesn't engage with the WP:NPOV concerns raised.

This was precisely the problem with the original RFC - these substantive legal and historical distinctions were never adequately addressed, with participants instead treating it as a matter of preference rather than policy. I'll leave it to other editors to evaluate the arguments presented here. Seungsahn (talk) 17:07, 1 February 2026 (UTC)

Each editor has their own interpretations. GoodDay (talk) 17:17, 1 February 2026 (UTC)

The non-recognition of the Soviet annexation of the Baltic states by most Western nations for fifty years is not an "interpretation" - it is documented historical fact. Interpretations vary; the historical record does not. Seungsahn (talk) 17:21, 1 February 2026 (UTC)

You're bringing up arguments, that have already been made. GoodDay (talk) 17:23, 1 February 2026 (UTC)

Arguments being previously raised is not the same as arguments being adequately addressed. Throughout this discussion, you have responded to documented historical facts with "IMHO," "we won't agree," and "each editor has their own interpretations" - none of which engage with the substantive policy concerns raised. With respect, if the response to sourced, verifiable facts is simply to express personal opinion without policy-based counterargument, I'm not sure continued participation in this discussion is productive. I remain open to hearing an actual rebuttal to the points raised about the distinct legal status of the Baltic states under international law. Seungsahn (talk) 17:26, 1 February 2026 (UTC)

If you are not being able to agree that Baltic states were illegaly occupied by solviet union. You should not take part of decision for this topic. If this is you stance, then you are directly pushing solviet union point of view!!! BerzinsJanis (talk) 17:09, 1 February 2026 (UTC)

If you are not being able to agree [...] You should not take part of decision for this topic. This is not how Wikipedia works. Nakonana (talk) 17:57, 1 February 2026 (UTC)

Again, its is not my opinion, but internationaly recognised fact that have its own wikipedia article State continuity of the Baltic states its the fact that should be taken in account for this discussion. If an editor simply wants to ignore it, or pretend its not a well documented fact, the said editor should not take part in a discussion where its an important point.

My understanding, is that wikipedia aims to provide netural accurate information, ignoring important facts, or making missleading comments (not aimed at editor at question) about them is definetly not how Wikipedia should work. BerzinsJanis (talk) 18:04, 1 February 2026 (UTC)

I guess Britannica is pro-Soviet/Russian because it says Mikhail Baryshnikov was born in the USSR.[53] Mellk (talk) 18:04, 1 February 2026 (UTC)

Britannica is not bound by WP:NPOV. What other encyclopedias choose to do is not a policy-based argument for what Wikipedia should do. The point remains: the Soviet annexation of the Baltic states was never recognized de jure by most Western nations, which distinguishes them from other Soviet republics. This distinction has not been addressed. Seungsahn (talk) 18:07, 1 February 2026 (UTC)

The point is we have our own manual of style, just like Britannica has its own manual of style. Mellk (talk) 18:09, 1 February 2026 (UTC)

In that case these people for example shouls have there birth place changed to city, Nazi Germany, since they all were born in place while under Nazi Germany occupation.

Tatyana Adamovich

Anatoly Glushenkov

Vasily Shuteyev

Vasily Melnikov

Wikipedia manual of styles is quite flexible, but some users are pushing for quite narrow interpretation of it. BerzinsJanis (talk) 18:19, 1 February 2026 (UTC)

The infoboxes of some biographies already mention Nazi German occupation (e.g. Miloš Zeman). That does not mean we endorse Nazi Germany's actions. Mellk (talk) 18:25, 1 February 2026 (UTC)

Assuming you raised these biographies in good faith, I would expect Wikipedia to treat people born in an occupied territory during a hot war quite differently to people who were born in an occupied state during a far more protracted cold war. But I would also expect those biographies to mention something in the body text along the lines of “Early life: X was born in Y Oblast in 1942, while the territory was under Nazi occupation.” — HTGS (talk) 23:47, 10 February 2026 (UTC)

Do you mean that births and deaths during the first Soviet occupation (1940-1941), or during the second Soviet occupation but before the end of the war (1944-1945), should be treated differently from those after the war, between 1945 and 1990/1991? Indrek (talk) 06:58, 11 February 2026 (UTC)

I was giving a rationale for why Nazi occupation might be sensibly treated differently to an enduring Soviet occupation. As for the initial Soviet occupation, I don’t have a good answer to that, and I could see good reasons to go both ways. And I am very much not an expert, so it’s probably best that I don’t take too strong a stance on the specific. — HTGS (talk) 09:40, 11 February 2026 (UTC)

I raised them to show that there is currently no consistently applied style, for example Tatyana Adamovich doesnt even mention Solviet union, just Russia. While Anatoly Glushenkov mentions birth place as both Russia and Solviet union.

This sugest there is no single practice across bibliograpfies. Before imposing a single style to Baltic states it would be helpfull to clarify what are principles to for such cases.

Additionally, common English-language usage appears to differ significantly (see Ngram data comparing “Estonia”, “Soviet Estonia”, and “Estonian SSR”) (Latvia and Lithuania show the same tendencies) which may be relevant under Wikipedia:COMMONNAME considerations. BerzinsJanis (talk) 07:32, 11 February 2026 (UTC)

Those articles are incomplete and imperfect. Is a consistently applied style not what we are working towards here? That is why I suggested the differentiation between temporary and extended occupations.

I don’t personally see how that ngram data is useful here, but maybe I’m missing something. — HTGS (talk) 10:01, 11 February 2026 (UTC)

I brought up the Ngram data for the same reason I raised the other examples, to show that there is no same applied style, and that actual language usage differs.

Ngram is relevant under WP:COMMONNAME because it reflects how terms are used in english sources over time. If the data shows that Estonia is used far more frequently than Soviet Estonia or Estonian SSR (and Latvia and Lithuania show the same pattern), this suggests that usage of these countries are generally used by their state name rather than by the Soviet name.

That seems relevant when we are discussing how to describe birth places or political entities in biographies. If the wast majority of English language sources use one form, that should at least be considered before imposing a single uniform style that forces to use only Soviet qualifiers while at the same time removing any other names.

Ngram is not proof on its own, but it does provide evidence of usage. If we are aiming for consistency, it would be helpfull to first clarify what principles/rulles we are applying COMMONNAME, usage in reliable sources orand tother info, rather than standardising one formula only for selected cases.

And honestly I do not understand this reasoning behind wish to keep only solviet names while excluding modern names. It seems like a really narrow application of policies. There are many examples on wikipedia where naming follows common usage rather than strict historical odities, so it is unclear why in this case policies are interpreted so narrowly. BerzinsJanis (talk) 10:53, 11 February 2026 (UTC)

That we use "Estonian SSR" etc. in infoboxes in these cases has already been decided in an earlier RfC. You continually act as if you don't know that, but of course you do. Gawaon (talk) 11:35, 11 February 2026 (UTC)

I know there was previous RFC about this and that it supported using Estonian SSR in infoboxes. I am not saying it did not happen. But that RFC had a lot of problems, and I think policy was applied in too narrow way there.

My point is not to ignore the result, but to question if it really follows WP:COMMONNAME and how english sources write. If most sources simply use Estonia much more often than Estonian SSR, then that should at least be looked at, at some point.

Consensus is not something fixed. It can change. Im saying that maybe the policies were read too strictly in that discussion, and that in many other cases on Wikipedia naming follows common usage, not only strict historical wording.

This can be discussed again in future. Right now I am just pointing out problems with it and asking what rules we are really following here COMMONNAME, usage in sources, or just keeping old decision no matter what.

If there are no problems with the previous reasoning, then it would be helpful to explain why these concerns do not apply. BerzinsJanis (talk) 12:18, 11 February 2026 (UTC)

There were at least 3 attempts to overturn that RfC, all failed. "Consensus can change" is not a defence for refusing to accept the consensus that has been found. Maybe after a few years have passed and if new information has been provided (unlikely since the issue was thoroughly discussed before, but who knows), the RfC decision will be revisited and possibly revised, but for now you would show more respect for your fellow-editors and their precious time by accepting the consensus as it stands and not venturing off-topic into already settled questions all the time. Gawaon (talk) 15:41, 11 February 2026 (UTC)

Two of the challenges were mine from earlier when I did not know any better, so those can be set aside. That leaves one chalange.

My point is: how exactly were WP:COMMONNAME and actual English language usage weighed in that decision? What policies were folowed here.

Im not ignoring RFC, im asking for policy based explenation why ngram data is not applicalbe and policy based ansver why such narrow rules (use only x SSR, Solviet union), for infobox are imposed. If the matter is considdered fully settled, then it would not be difficult for you to not mind give brief policy based explenation, how (ngram) data shows that, for exmaple, Estonia is used far more frequently in English language sources than Estonian SSR or Soviet Estonia — was evaluated and why that evidence was considered insufficient under WP:COMMONNAME and why its forbidden to use both modern and old names, when thats done in wast majority of rest of eroupes infoboxes. BerzinsJanis (talk) 16:37, 11 February 2026 (UTC)

The RFC didn't address article titles, only the infobox. CoffeeCrumbs (talk) 17:30, 11 February 2026 (UTC)

Editors have identified several problems with Google Ngram, WP:NGRAM. Not saying they all apply to this discussion, but we should be wary of using Google Ngram in general. TurboSuperA+_[talk] 17:38, 11 February 2026 (UTC)

While it is problematic, many of said problems should not reflect on 1939 to 1991 period. No new self published books can be added to it, and most UN protocols will use solviet name schema. It however does show, even with its all problems, that Estonia, Latvia and Lithuania were common names, even if say only half of data is accurate, they still are in common usage and should not be ignored. BerzinsJanis (talk) 17:47, 11 February 2026 (UTC)

You are still doing it. If you want to try overturn that settled RfC, you may take it to the admins, but this is not the place to have that discussion. Gawaon (talk) 18:34, 11 February 2026 (UTC)

Hi! To clarify, admins do not have additional power around starting or overturning RfCs. However, such a discussion is still off-topic here, and should be held in a separate thread, if at all. Chaotic Enby (talk · contribs) 10:04, 12 February 2026 (UTC)

Oops, sorry if I spread misinformation. My understanding is that CLOSECHALLENGEs for RfCs go to the Administrators' noticeboard, hence the reference to admins. My understand this also that this has already happened in this case (and the closure was upheld). Gawaon (talk) 11:30, 12 February 2026 (UTC)

Yep, that's accurate! It's an administrative matter, although from what I understand (correct me if I'm wrong) participation isn't limited to admins only. Chaotic Enby (talk · contribs) 11:37, 12 February 2026 (UTC)

@BerzinsJanis WP:COMMONNAME is policy for how we name articles. If you want to rename Estonian Soviet Socialist Republic, then you should discuss doing so at that article’s talk page. (I do not recommend doing so.) Otherwise I don’t see much relevance for common name or Ngrams here. You should try to stay on topic, to avoid disrupting the discussion at hand. — HTGS (talk) 09:52, 12 February 2026 (UTC)

Thanks for pointing me to the Manual of Style. As I understand it, MOS:Biography "Birth date and place" section does NOT specifically address what to do when a birth country was under illegal occupation that was never recognized de jure by most Western nations. In the absence of specific guidance, WP:NPOV should take precedence. Seungsahn (talk) 18:22, 1 February 2026 (UTC)

It also says Dalia Grybauskaitė was born in the USSR.[54] Somehow there is only outrage at Wikipedia. Mellk (talk) 18:07, 1 February 2026 (UTC)

Britannica doesn't actually list only Soviet Union, it has both countries listed. --~~Xil (talk) 18:23, 1 February 2026 (UTC)

@Mellk Your reasons why did you choose to not include that fact? for the reference link to mentioned article BerzinsJanis (talk) 18:27, 1 February 2026 (UTC)

I suppose you are referring to where it says "now Vilnius, Lithuania"? But per the infobox documentation we do not include the modern-day location. Mellk (talk) 18:28, 1 February 2026 (UTC)

Obviously the Soviet Union did not agree that its annexation was illegal, even if it was not recognized by its enemies. That non-recognition is objectively true, but the fact that the Soviet Union administered these territories is also objectively true. Pointing out the fact of Soviet control is not a moral endorsement of that act, it's an important piece of context our readers need to know. The task here is I think to represent the unusual situation concisely and with regard to due weight. -- Beland (talk) 19:33, 1 February 2026 (UTC)

Thank you - this is a fair point and I appreciate the substantive engagement. I don't dispute that Soviet control is relevant context. My argument isn't that Soviet administration should go unmentioned, but that presenting Baltic birthplaces in the same "City, SSR, Soviet Union" format as other republics implies a legitimacy that was explicitly rejected under international law. The occupation itself is also an important piece of context our readers need to know - and the "SSR, Soviet Union" format obscures rather than communicates that. A format like "Tallinn, Soviet-occupied Estonia" would acknowledge the de facto Soviet control while also reflecting the de jure continuity that most Western nations maintained, and would accurately convey to readers that this was an occupation, not an ordinary administrative arrangement. This seems more consistent with WP:NPOV. Seungsahn (talk) 19:38, 1 February 2026 (UTC)

Why are we only interested in the positions of "Western nations" anyway? The US-led bloc also recognized "Captive Nations". Mellk (talk) 19:42, 1 February 2026 (UTC)

OK, you can respond to the survey and advocate that option. There is also another RFC that asks if we should accomplish the same goal with an explanatory footnote. -- Beland (talk) 19:56, 1 February 2026 (UTC)

There's other birth/death places of bio infoboxes, that include other former countries, like Yugoslavia & Czechoslovakia. But, that's for down the line. GoodDay (talk) 15:12, 1 February 2026 (UTC)

To summarize the position I've outlined in this discussion: the Baltic states occupy a unique position under international law. Their Soviet annexation was never recognized de jure by most Western nations for fifty years, they maintained diplomatic missions throughout the occupation, and this is extensively documented in our own article State continuity of the Baltic states. This fundamentally distinguishes them from other Soviet republics and means applying an identical infobox format raises serious WP:NPOV concerns. The original RFC did not adequately address this distinction. I note that throughout this discussion, these substantive arguments have not been engaged with. The responses I've received have consisted of personal opinions ("IMHO," "we won't agree," "each editor has their own interpretations"), questions about my account age, references to what other Wikimedia projects do, and suggestions that raising these concerns constitutes "pushing." Not once has anyone provided a policy-based rebuttal explaining why the documented legal status of the Baltic states is irrelevant to how Wikipedia presents their history in infoboxes.I believe any new RFC on this topic must explicitly address this legal distinction rather than treating the Baltic states as identical to other Soviet republics. I'll leave this on the record for the RFC framers and closers to consider.Seungsahn (talk) 19:00, 1 February 2026 (UTC)

FWIW, Gigman is no longer blocked. GoodDay (talk) 19:11, 1 February 2026 (UTC)

The argument about state continuity in the Baltics was in fact made in Wikipedia talk:Manual of Style/Infoboxes#RFC: Baltic states birth infoboxes, so I don't see how it could be considered that they haven't been "adequately engaged with". I think it would be more fair to say the choices there were somewhat binary, but that's why participant suggested adding a footnote and that triggered a followup RFC, and that's also why "administered by" etc. are choices offered in this RFC. -- Beland (talk) 20:04, 1 February 2026 (UTC)

Their Soviet annexation was never recognized de jure by most Western nations for fifty years — just out of curiosity: what about non-Western nations? Nakonana (talk) 21:11, 1 February 2026 (UTC)

I am reminding everyone that this discussion is not the place to rehash arguments about the previous RfC, and that such continued back-and-forth may be seen as disruptive by other editors. Chaotic Enby (talk · contribs) 21:37, 1 February 2026 (UTC)

• I have collapsed the "vote" above by Seungsahn. Every comment and response by them has been LLM generated and cannot be engaged with in earnesty. Though I am leaving up comments already there with substantial engagement. Seungsahn, if you want to contribute here do so in your own voice; we are not here to entertain undisclosed chatbots. Gotitbro (talk) 09:02, 2 February 2026 (UTC)

  Do you have any proof these comments are LLM-generated? I don't think they are. sapphaline (talk) 09:14, 2 February 2026 (UTC)

  The bioler plate LLM cruft was clear as day. To further verify I checked the responses at GPTZero, Undetectable.ai, Copyleaks among others. He verdict is pretty clear for dishonest LLM usage and I am afraid this cannot be engaged with earnestly. Gotitbro (talk) 09:35, 2 February 2026 (UTC)

  LLM-detection tools aren't an ironclad proof, or proof at all. sapphaline (talk) 09:40, 2 February 2026 (UTC)

  Sure but we do not need 100% "ironclad proof". When you have enough experience dealing with LLM cruft and the biolerplate nonsense and hallucinations generated by them, you can substantially tell when that is the case as here. And when multiple tools and judgment tell me that is the case, it becomes pretty clear what has been done. WP:MANDY of course can never be defence for editors employing LLMs and then denying them. Gotitbro (talk) 09:47, 2 February 2026 (UTC)

  You obviously don't have enough experience dealing with LLM cruft. Your gut feeling is no proof at all. — Chrisahn (talk) 18:40, 2 February 2026 (UTC)

  You may refuse to see what is clearly there in front of everyone others won't, that the editor in question is still running around with boilerplate LLM cruft is all that needs to be said about this. Gotitbro (talk) 04:17, 3 February 2026 (UTC)

  Im shure you are aware that there might be false positives. No LLM or group of LLM can be 100% correct about detecting LLM. BerzinsJanis (talk) 09:42, 2 February 2026 (UTC)

  @Gotitbro: I wrote the comments myself. Accusing other editors of using AI without evidence is not constructive and borders on a personal attack per WP:AGF and WP:NPA. So far most of the responses to my contributions have been personal accusations (that my account is too new, that I'm using an LLM), rather than any engagement with the substance of my arguments. If you disagree with my position, address the policy reasoning. Please uncollapse my comment. Seungsahn (talk) 09:15, 2 February 2026 (UTC)

  Highlighting dishonest LLM usage is not a personal attack, neither is noting a new user (though I did not point this out at all) handily wading through contentious topics and obscure noticeboards all the while using LLMs, especially when that user is coming from recent sanctions. If you do not come with clean hands do not expect others to not be wary. Gotitbro (talk) 09:38, 2 February 2026 (UTC)

  AI detectors have well-known problems with false positives, especially for non-native English speakers - e.g. this Stanford study [1] found they misclassified over 61% of essays by non-native speakers as AI-generated. You've now collapsed two of my comments without once engaging with what I actually said. Please address the arguments or leave my comments alone.

  [1] https://hai.stanford.edu/news/ai-detectors-biased-against-non-native-english-writers Seungsahn (talk) 09:51, 2 February 2026 (UTC)

  I would obviously waste no time in engaging with chatbot responses. Do non-native speakers also generate bulleted, essay, flowy responses exactly like ChatGPT [55], do non-native speakers also make unabated use of em dashes exactly like LLMs, do non-native speakers also show very proficient familiarity with enwiki policies (though of course without knowing how they actually apply as LLMs do not know one thing from the next) despite barely beginning to edit. If the answer to all of that is no, which it is, you should know that absolutely no one is buying the MANDY here. Gotitbro (talk) 10:08, 2 February 2026 (UTC)

  Apparently someone reverted you. Gråbergs Gråa Sång (talk) 09:15, 2 February 2026 (UTC)

  @Gotitbro: I don't think an RFC is the proper place to 'claim' someone is using LLMs. If you're convinced someone is using LLMs? then your concern should be brought to administrators. GoodDay (talk) 15:34, 2 February 2026 (UTC)

  Other editors should fully know when subjected to LLM cruft, the exact reason we make no consideration of AI generated nonsense for consensus (e.g. RfC) and templates like {{Collapse AI}} exist. An ongoing discussion is the most apt place to being it, sorry. Gotitbro (talk) 15:49, 2 February 2026 (UTC)

  As the discussion moderator, I believe the original !vote should be left intact – it will the responsibility of the closer to judge how relevant it is to the conversation, and to weigh or discount it appropriately. However, @Seungsahn is reminded that conversations should not be bludgeoned, and that relitigating an already closed RfC can easily verge into disruptive editing. Chaotic Enby (talk · contribs) 09:19, 2 February 2026 (UTC)

  Noted, thanks. Seungsahn (talk) 09:20, 2 February 2026 (UTC)

  Seungsahn should also be reminded that Wikipedia does "de facto", not "de jure". The problem with de jure is that it's inherently not WP:NPOV: it depends whose jus you go by. However much we might not like it the fact is that the Baltic States were incorporated into the Soviet Union, and the rest of the world did nothing about it. Phil Bridger (talk) 09:56, 2 February 2026 (UTC)

  Unfortunetly its not always the case see info box Crimea, also there are multiple policies as use modern names and geolinks and others that give some choice in this matter. And that assuming that every article follows them. While I would prefere using only Latvia, Estonia and Lithuania as places of birth, there are good arguments to use them with solviet union, hell there are good argument to not use solviet union liek Names Latvia, Estonia and Lithuania were commonly used terms link to 1989 news video and not Latvia sssr or solviet union. The biggest problem is that many editors does not want to discuss what showing only solviet union is damaging to Baltic states. Including usage of LLM that harvest data from here. I believe such details about occupation are important to include in info box, or in its foot note. Im more than willing to discuss how it should look like, i'm willing to make compromises to it. BerzinsJanis (talk) 10:13, 2 February 2026 (UTC)

  Thanks, I am aware of that. However ignoring the fact that a significant and well-documented dispute exists is not informative for the reader.

  As for "the rest of the world did nothing about it" – that's not accurate. Most Western countries maintained non-recognition of the annexation for the entire occupation, the Baltic states kept functioning diplomatic missions throughout, and the Welles Declaration was never rescinded. Seungsahn (talk) 13:59, 2 February 2026 (UTC)

  Inserting WP:COATRACK mentions of disputes into tangential places is not informing the reader, it is pushing a viewpoint. CMD (talk) 14:54, 2 February 2026 (UTC)

  It is a mainstream "viewpoint" not some random factoid, it would be WP:DUE to reflect it --~~Xil (talk) 18:55, 2 February 2026 (UTC)

  There are a million mainstream viewpoints behind every link on this article. If the viewpoint of the footnote is so extraordinarily mainstream that the way the link itself is written is misrepresentative, then we should reinvestigate whether we should rewrite it. — HTGS (talk) 00:03, 6 February 2026 (UTC)

  I'm not aware of any policy that favors de facto over de jure. When there's a mismatch between the two, deciding whether to ignore one or neither comes down to how important and relevant the discrepancy is, and policies like WP:DUE. Hardly any laws are fully followed or even fully enforced, and when that matters (and shows up in reliable sources) we should say so. For example, Legality of cannabis maps out where laws are enforced, where they are not enforced, and where recreational use is legal. But on Free trade area and List of countries by tariff rate we don't mention smuggling, even though it's a way of de facto bypassing tariffs. -- Beland (talk) 21:54, 2 February 2026 (UTC)

Just a heads up. The RFC is approaching its end & when the template expires? I'll be heading to WP:Closure requests. -- GoodDay (talk) 16:43, 11 February 2026 (UTC)

There is no set end to RFCs. They end when editors have stopped discussing and !voting. You can stop the bot from removing the rfc tag. WP:RFCEND: To extend a current RfC for another 30 days, and to prevent Legobot from automatically ending the RfC during the next month, insert a current timestamp immediately before the original timestamp of the opening statement with either ~~~~ (name, time and date) or ~~~~~ (just the time and date). TurboSuperA+_[talk] 16:55, 11 February 2026 (UTC)

I would really advise against extending this RFC. Participants are just repeating arguments that have already been made, and the usual 30 days have been long enough to get a good sampling of opinion. We need to come to resolution on this so we can free volunteer time for other article improvements. -- Beland (talk) 18:22, 11 February 2026 (UTC)

Yeah, let a fearless closer have fun with this one once the template is expired. I deeply admire the brave people who dare to close such tricky issues. Gawaon (talk) 18:36, 11 February 2026 (UTC)

Quick bump to prevent bot from archiving this thread. Indrek (talk) 07:46, 5 March 2026 (UTC)

Table style template

In the work I have done, using tables on English Wikisource, I have found their s:Template:Table style and associated CSS extremely useful.

I think we should import the template, and styles, and usurp our little-used {{ts}} redirect, to match what is done there.

Would there be support? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:58, 16 February 2026 (UTC)

What's wrong with class="wikitable"? sapphaline (talk) 09:20, 23 February 2026 (UTC)

There's nothing "wrong" with it; but it doesn't do what {{ts}} does. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:12, 23 February 2026 (UTC)

Looks extremely cryptic to me. If this gets attention from the sort of people who like to do things like rename "Template:Ts" to "Template:Table style", I expect they'd not like the resulting wikitext that would look like {| class="wikitable" {{ts|ar|vtb|pr2}}. Anomie⚔ 13:08, 23 February 2026 (UTC)

I'm not clear how such hypothetical disruption is relevant. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:53, 27 February 2026 (UTC)

@Pigsonthewing We also have {{table}} for simplifying the CSS options. --Ahecht (TALK
PAGE) 17:47, 27 February 2026 (UTC)

Thank you, but that doesn't seem to be usable for styling rows, or individual cells. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:51, 27 February 2026 (UTC)

How the heck is Cebuano wikipedia the wikipedia with the second most articles?

List for reference

I'm nearly certain this isn't the right place for this, but I don't know where else I could bring this up. My apologies.

Despite only having 188 active users, 7 admins, and a depth of 2, the wikipedia for a language I hadn't heard of until now has twice the amount of articles as the german wikipedia.

Is this the result of lazy translation? A handful of filipinos somehow more dedicated than a few thousand germans? another Scots Wikipedia situation? My desire for closure must be fulfilled mghackerlady (talk) (contribs) 23:23, 23 February 2026 (UTC)

Because Lsjbot. * Pppery * _{it has begun...} 23:24, 23 February 2026 (UTC)

Some hints at Cebuano Wikipedia. Gråbergs Gråa Sång (talk) 06:55, 24 February 2026 (UTC)

Lots of articles, but not a lot of content: for my village there's location (from geonames.org) and climate (from NASA), full stop. Look at an en.wiki article and follow through to its ceb.wiki parallel to see. PamD 08:11, 24 February 2026 (UTC)

Are there any statistics on total size of different wikis in terms of words, rather than articles? I suspect Cebuano would plummet down the ranking, from the couple of articles I've looked at. Its "Zebra" is one unsourced paragraph, not by Lsjbot. PamD 08:18, 24 February 2026 (UTC)

I can't find anything about total size, but for other stats you will see Cebuano Wikipedia essentially does not rank; e.g. edits per article (en.wiki averages nearly 200; other major languages such as French and German are about half that; Cebuano averages only six - ahead only of Mazanderani wikipedia) or by featured article count (en.wiki has nearly 7000, or about 1% of articles; fr.wiki and de.wiki have a slightly smaller proportion of articles featured; ceb.wiki has only 26 and apparently no formal review process). Caeciliusinhorto-public (talk) 13:02, 24 February 2026 (UTC)

See also this article on Vice and this article on (Australian) abc. Long is the way (talk) 13:12, 24 February 2026 (UTC)

For anyone else wondering what 'depth' means, see here. That page doesn't really explain itself well, but if I'm reading the formula correctly, it's roughly the average number of edits per article, with some adjustments. I could very well be misunderstanding, though. ~2026-12499-02 (talk) 10:59, 25 February 2026 (UTC)

lsjbot. That one bot has created hundreds of thousands of articles there. There might be others too; that is the most prominent one. ~2026-12511-25 (talk) 11:03, 26 February 2026 (UTC)

How to give an archive page of a Facebook comment, if archive.today is not allowed?

As I learned from Wikipedia:Images from social media, or elsewhere#Facebook, a Facebook photo with comment from the creator such as "I agree to publish this image under the Creative Commons Attribution-ShareAlike 4.0 International licence" would be allowed to upload to Wikimedia Commons. I previously did so, but I can't archive the page in Wayback, and archive.today used to work. What can I do? The original comment of the licence statement is there, but as it is from Meta, I have no idea how to save it in case it (or the Facebook account, the original post etc., the source in general) disappears in the future. I mean, if the original source of licence statement is really gone, wouldn't someone regard such license to be invalid and request to delete the file? - George6VI (talk) 15:24, 26 February 2026 (UTC)

There's a process at Commons for having an admin or other trusted volunteer verify that the photo was indeed released under the claimed license. See c:Commons:License review. Basically, upload the image, make sure the documentation is all correct, and then slap {{LicenseReview}} on it. (It's even possible that the UploadWizard will add this template for you. WhatamIdoing (talk) 20:37, 26 February 2026 (UTC)

Just read the page, but for now I am still not a reviewer, while it seems like I am eligible to use the template only when I am in the said user group. (Or it doesn't?) Is there a way to submit the review request, did I miss something? - George6VI (talk) 03:50, 27 February 2026 (UTC)

No, there's one template for ordinary users like us to use, which requests that the correct people review it. When those people review it, they use a different template. WhatamIdoing (talk) 04:28, 27 February 2026 (UTC)

Hmm, is it like I adding {{LicenseReview}} to the file I wish for the request, and someone of reviewers may come later? - George6VI (talk) 08:27, 27 February 2026 (UTC)

Yes, that's how it should work. Gawaon (talk) 08:52, 27 February 2026 (UTC)

megalodon.jp can archive Facebook posts, much more efficiently than archive.todah. Katzrockso (talk) 00:03, 27 February 2026 (UTC)

Ah, it works, thanks. - George6VI (talk) 03:52, 27 February 2026 (UTC)

Ghostarchive also works, albeit in "Noscript" mode. sapphaline (talk) 09:18, 27 February 2026 (UTC)

Oddities in the birthday globe

I just noticed that a bunch of the letters on the side of the birthday globe seem to switch/turn into other letters. Is this intentional? Or is this just a side effect in animation? Or maybe it's AI generated? Theeverywhereperson talk here 17:17, 27 February 2026 (UTC)

Hi @Theeverywhereperson, yes the letters changing are one of Baby Globe's quirks. The shifting glyphs are part of how Baby Globe expresses itself, like when listening to music, dreaming or taking pictures. No AI involved, all the art and animation was done by humans. You can learn more about the Wikimedian who came up with the original sketch here! EBlackorby-WMF (talk) 18:50, 27 February 2026 (UTC)

Category talk:German dialects#Low German dialects

I've published this post on the talk page for the German dialects category. Can someone answer it? Karamellpudding1999 (talk) 00:11, 28 February 2026 (UTC)

City Class in the Leads of Kentucky City Articles

Kentucky has two city classes - home-rule, and first class. The main difference between the two is governance, first class cities must have a mayor-council government, while home-rule class cities have more choices, though often still choose to have a mayor-council government. Beyond this, there are little differences that are made from a city just being classified as first-class or home-rule. It is also important to note that the only first-class city in Kentucky is Louisville, which is disproportionately larger than all of the other cities.

However, for some reason, almost every single article about cities in Kentucky mentions the class of the city in the first sentence of the article. Is it really necessary for city class to be the first thing mentioned about a city, when it has little actual impact? Imagine if every article about cities in America had 'This city is smaller than New York" in the lead. My best guess for why this is the case is that city class used to actually be important, as before 2015 there were 6 different city classes, and there were many different laws that were specific to different city classes. Now, however, city class isn't anywhere near as important, so I believe we should move talking about city class later into these articles. Since this would be a decently large change that would affect a lot of articles, I wanted to talk about it with several other editors. Please provide any input you have, I would like to hear what other people have to say.

I am a new editor, so I apologize if this is the wrong place to post this. I didn't think it would fit in any specific Kentucky city talk section, so I put it here. Map Enjoyer (talk) 04:32, 28 February 2026 (UTC)

Hi @Map Enjoyer. I think you might get more responses from editors familiar with that issue by posting at Wikipedia talk:WikiProject Kentucky. Schazjmd (talk) 14:19, 28 February 2026 (UTC)

Oh, Kentucky has a wikiproject? Cool, I can join the other 2.5 people in this state on wikipedia. Thanks for letting me know Map Enjoyer (talk) 17:04, 28 February 2026 (UTC)

"Legal & safety contacts"

I just noticed that in the very bottom of the English Wikipedia site, there is now a "Legal & safety contacts" link. Archives say that it wasn't there before. When was this added? HyperAnd (talk) 23:49, 1 March 2026 (UTC)

In the middle of December, as announced. WhatamIdoing (talk) 23:59, 1 March 2026 (UTC)

Alternate History

At Miscellany for Deletion, we are seeing several alternate history pages each week, usually having to do with elections, sometimes for President of the United States, usually describing different results in the past, or sometimes describing future results. Sometimes they are in draft space, and more often they are in user space, either on user pages or on user subpages. They always get deleted for various reasons. Often they are by editors who are otherwise non-contributors, and so are web hosting by non-contributors, which is no longer U5, but Wikipedia is not a web host is still a policy, so they can be deleted after discussion and are deleted after discussion. Occasionally they are by users who are otherwise here to edit constructively, but they should be and are deleted anyway, sometimes citing Wikipedia is not for things made up. If they are set in the future, they are crystal balling. Often they use the names or images of living persons, in which case they are also BLP violations.

I have an open-ended question, and a request. About five years ago, when there previously were a moderate number of alternate history pages at MFD, I wrote an essay, Wikipedia is not for alternate history. The request is for other editors to improve the essay. I would then like to upgrade it to the status of a guideline. We are deleting the alternate history, but there is enough of it so that a special guideline about it would be useful. The open-ended question is whether anyone else has any ideas about dealing with it. Robert McClenon (talk) 02:41, 2 March 2026 (UTC)

Why are these being brought to MFD at all? Even if you're not willing to wait six months for them to be U7's (or don't consider them to be "creative or persuasive writing", which they may well not be), as described they sound like they should all be speedyable as G3's for being obvious misinformation. IIRC one of the motivating examples for expanding G3 to explicitly include hoaxes was an article about a war that "had" started the day after the article's creation, so a user subpage describing the results of a future election should qualify. Deliberately-incorrect results of past elections definitely do. —Cryptic 03:29, 2 March 2026 (UTC)

In an nontrivial number of cases, users have sprinkled language in their drafts (like adding the word "hypothetical") which pushes them just over the edge into technically not being a hoax, so they can't be speedily deleted under current policy. It's frustrating, especially since it seems to be deliberate. Omphalographer (talk) 04:31, 4 March 2026 (UTC)

I note that Wikipedia:Village pump (miscellaneous)/Archive 87#Alternate History in Sandboxen was just archived off this page, shortly after this new section was started. The only debate seems to be over userspace sandbox pages by established users, which apparently a few people want to be able to blanket-delete rather than considering whether established users experimenting with layout or the like using clearly marked fictional content is ok. IMO your time would be better spent focusing on the people actually WP:NOTHERE instead of trying to stretch PaG and create new PaG to justify going after established editors. If it's not going to be WP:U6 or WP:U7 eventually, slap a {{User sandbox}} or the like on it if you're worried someone would really think "User:Example/sandbox" is somehow an actual article and move on. Anomie⚔ 12:59, 2 March 2026 (UTC)

Monitoring of Wikipedia talk:IP block exemption

I was going to leave an inquiry at Wikipedia talk:IP block exemption but noticed that the last three inquiries, dating back to mid-May last year, haven't received any responses. Wondering whether that page is even actively monitored by anyone with answers, I looked back at the latest archive, which covers the period from January 2022, and found there had been three users who'd been answering a number of inquiries each: User:Xaosflux, User:Risker, and User:Zzuuzz. I'm not writing this to scold them—every one of us is of course a volunteer and, even within the context of our active participation on the project, our focuses can change—only to see if any of them might still be available to take a look at the latest entries. My intent here is to advertise that there have been inquiries seeking attention, to see if anyone qualified to respond to them might be interested in doing so. Largoplazo (talk) 15:24, 3 March 2026 (UTC)

That is a documentation discussion page, not a workflow page - thus the low engagement. It doesn't seem like there is much use of the page for its primary purpose: discussing improvements to the associated project page. Feel free to put a hatnote on it that for actual help with a block, pages such as Help:I have been blocked may be more useful. — xaosflux ^Talk 15:58, 3 March 2026 (UTC)

Project pages (unlike articles) are ordinarily also where people ask for clarification and guidance regarding the policies and guidelines the page is about. Largoplazo (talk) 16:29, 3 March 2026 (UTC)

The 3 comments probably are a commentary on the policy page, even though most seem to have answered or figured it out their own situations themselves. Users like the 3 mentioned tend to have watchlists numbering tens of thousands of pages, plus a thousand things to do, so it's easy for something to slip by. I'll see if I can add acquiring some inspiration for some policy wordsmithing to my todo list, though that's something open to everyone. -- zzuuzz ^(talk) 16:31, 3 March 2026 (UTC)

Fair enough, sounds good! Largoplazo (talk) 16:39, 3 March 2026 (UTC)

Activity of WikiProjects

Perhaps I wrongly assumed about WP:WikiProject Biography, WP:WikiProject Women artists, WP:WikiProject Actors and filmmakers, and so forth when I tried labelling them as "semi-active". Difference between activities of WikiProject talk pages and (somewhat?) active editing of related articles meeting any of these scopes? Or...? George Ho (talk) 18:07, 3 March 2026 (UTC)

What defines “activity” for a Wikiproject? Is it discussion, feedback and coordination at the project page level, or is it editing and collaboration at article level? A lot of our Wikiproject pages are essentially moribund… yet the articles under the project’s banner are actively edited. Blueboar (talk) 18:57, 3 March 2026 (UTC)

What defines “activity” for a Wikiproject? Is it discussion, feedback and coordination at the project page level, or is it editing and collaboration at article level?

I did judge the WikiProject activity primarily based on amount of responses in their talk pages. Too bad my efforts to label them as "semi-active" were reverted by SNUGGUMS and pburka. I was gonna discuss this with the former, but the latter also made one of the reverts. Thus, I'm discussing "activity" criteria here. George Ho (talk) 19:05, 3 March 2026 (UTC)

A lot of our Wikiproject pages are essentially moribund: If they can't be labelled as "semi-active", then how else can these "moribund" WikiProjects be handled? Reconstruct the pages, broaden the scopes, or...? George Ho (talk) 19:43, 3 March 2026 (UTC)

A revert can be a sign of activity in itself. The idea that editing of pages within a Wikiproject's scope means the Wikiproject itself is active is symbolic of the decline of Wikiprojects as a whole, from actual communities/hubs to a glorified tagging system. CMD (talk) 03:10, 4 March 2026 (UTC)

[Assumption that editing the pages that meet] a Wiki[P]roject's scope [makes] the Wiki[P]roject itself [...] active [exemplifies] the decline of Wikiprojects as a whole, from actual communities/hubs to a glorified tagging system.

Copyedited most of the quoted content for ya. ;)

In any case, shall I then ping SNUGGUMS and pburka, both who reverted my relabelling them? George Ho (talk) 03:23, 4 March 2026 (UTC)

Curiously, why have WikiProjects' talk pages been mostly lacking replies either recently or in recent years? George Ho (talk) 03:26, 4 March 2026 (UTC)

Sometimes people instead more actively post on the talk pages of articles within the scope or on their review subpages (e.g. FAC, GAN, PR). You clearly didn't account for this when incorrectly assuming that WikiProject talk pages alone determine activity levels. Adding "semi-active" tags there was hasty at best. I thought it was obvious that ongoing efforts to work on pages within a project's scope count as activity for that. SNUGGUMS (talk / edits) 03:39, 4 March 2026 (UTC)

Then why do you think WikiProjects are called "moribund" or something like that? (Sure, I was unaware of other factors of activity, but I'm still astonished by the broadening of what exemplifies an "activity", ya know.) George Ho (talk) 08:12, 4 March 2026 (UTC)

They might have gone with the overly narrow criteria that you did or perhaps judged statuses on whether the project members had been around any longer. Nevertheless, there are multiple factors to measure activity instead of just one. SNUGGUMS (talk / edits) 12:59, 4 March 2026 (UTC)

Note a WikiProject is a group of editors who share a common interest for a particular Wikipedia initiative, such as editing articles related to a certain topic. A WikiProject talk page is a place for these editors to discuss matters of interest to the WikiProject. I agree that a lack of replies to editors starting topics isn't a good sign that the group is active, but it doesn't necessarily mean that there is no longer a group of active editors interested in the initiative. isaacl (talk) 23:26, 4 March 2026 (UTC)

The definition of activity for a WikiProject is the interaction of the group's participants with each other. The fact that other people edit articles within the group's scope is not a signal that the group exists. A chat on the group's talk page is a good signal, but not 100% reliable.

As a general rule: Tag the group's page however seems accurate/descriptive to you, and then be happy if someone reverts you. WhatamIdoing (talk) 04:54, 5 March 2026 (UTC)

Deleted pages on the Wayback Machine

Hi everybody,

for around the last year or so I tried to stop one obscure neo-religious organisation from whitewashing their Wikipedia page and the page of their founder, for which they really used every conceivable tool (socks, meatpuppets, AI talkpage discussions, a massive amount of faked or extremely obscure sources, legal threats against another editor, whatever you want). After the ban of their last array of sockpuppets, I noticed that suddenly some central sources used in these articles both in the German and English wiki, which were already only available on archive pages, were deleted even there. This is obviously quite bad for verifiability, and I fear that in a few months/years another sockpuppet will come and delete parts of the articles on the basis that the sources aren't accessible anymore.

See for example:

>Focus article (deleted from the Wayback Machine)

>Tagesschau article (deleted from the Wayback Machine)

While there is some tohuwabohu about some legal proceedings against the Hessischer Rundfunk, I remember that the Focus article in particular only talked in a neutral way about the results of these proceedings, so I don't see how there is a basis to delete this. Both of these are nearly highest-quality sources in the German media landscape. I also couldn't find much information about when or how an URL can be excluded from the Wayback Machine by request of a third party, which does not own the website (which I assume is the case here). Does anybody know more about when/how such a thing can happen or about any similar events? Iluzalsipal (talk) 15:51, 4 March 2026 (UTC)

I don't think that third parties can get pages removed from archives. Are the articles no longer available on the original websites? (We don't need archives if they are.)

In Wikipedia:The Wikipedia Library, when I search for "Bhakti marga" "Vishwananda" I see five potential sources. Maybe those would be useful. Google Scholar has some potential sources, though I don't know how many of them will be reliable. WhatamIdoing (talk) 05:06, 5 March 2026 (UTC)

Does Iran have a single leader?

Is Ali Larijani or Alireza Arafi or somebody else, the sole leader of Iran? Clarification on this matter, would help with related articles. GoodDay (talk) 21:03, 4 March 2026 (UTC)

@MarketFruit:, perhaps all can be settled here. At least, until a new supreme leader is chosen. GoodDay (talk) 21:07, 4 March 2026 (UTC)

Thanks. I mean the issue of Alireza Arafi is already solved, but it's more complicated with Ali Larijani because he is already seen since the end of December 2025 was de facto leader. MarketFruit (talk) 21:14, 4 March 2026 (UTC)

Whatever the answer is to this question (and I certainly don't know) it needs to come with reliable sources. Phil Bridger (talk) 21:23, 4 March 2026 (UTC)

Some sources: MarketFruit (talk) 21:51, 4 March 2026 (UTC)

@MarketFruit, the sources unfortunately didn't post. WhatamIdoing (talk) 05:07, 5 March 2026 (UTC)

Oh, they are in the old version of the Ali Larijani article. MarketFruit (talk) 11:39, 5 March 2026 (UTC)

From Dec 2025 until his demise, the Supreme Leader wasn't the 'defacto' leader? GoodDay (talk) 21:26, 4 March 2026 (UTC)

After the sources, Khamenei let Larijani handle all things since the protests. MarketFruit (talk) 21:52, 4 March 2026 (UTC)

Relisting TfDs

Should TfDs be relistable? – MrPersonHumanGuy (talk) 20:46, 5 March 2026 (UTC)

How submit a possible WIKIQUOTE?

hi: can I trouble you to tell me how to submit a possible Wikiquote:

“The present is perfect, and sometimes there’s something funny waiting to be noticed and shared”. Writing is easy (talk) 23:18, 5 March 2026 (UTC)

Wikiquote is a separate project from Wikipedia, and only accepts notable quotations from prominent people. Omphalographer (talk) 23:23, 5 March 2026 (UTC)

@Writing is easy wikiquote is a separate project from wikipedia, with it's own rules and procedures. That being said, I'm guessing wikiquote:Wikiquote:Requested entries is what you're looking for. RoySmith (talk) 23:23, 5 March 2026 (UTC)

Whose quote is it, BTW? George Ho (talk) 23:43, 5 March 2026 (UTC)