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.
Discussions older than 7 days (date of last made comment) are moved to a sub page of each section (called (section name)/Archive).
Policy
RfC: Party affiliation in BLP infoboxes
I am an AMPOL editor and I often see articles with party affiliation assumed in the infobox. For instance, Adriana Kugler's infobox states that she is a Democrat, but no inline citation is provided. On the other hand, Todd Blanche does provide a citation for having registered as a Republican. I am questioning the purpose of this parameter for individuals who are not directly associated with politics—in other words, their profession does not pertain to being a politician or political consultant. "If relevant" in the {{Infobox person}} documentation is rather vague. The misuse of this parameter warrants some action.
The rationale for removing the party affiliation parameter is similar to the RfC over the religion parameter. As was stated then, "This would be consistent with our treatment of sexual orientation and various other things we don't include in infoboxes that are matters which may be nuanced, complex, and frequently controversial. The availability of a parameter encourages editors to fill it, whether they have consensus to do so or not, regardless of instructions in template documentation to gain consensus first; new and anon IP editors generally do not read documentation, they simply see a "missing" parameter at article B that they saw at article A and add it." elijahpepe@wikipedia (he/him)16:38, 10 August 2025 (UTC)[reply]
Survey (party affiliation in BLP infoboxes)
Question presented: Should the party parameter in infoboxes be deprecated for non-political BLPs?
Oppose, and I note that both of the examples given in the original RFC question are "political" BLPs (both of them were political appointees in a system that expects appointees to come from the president's own political party) – people who very much are "directly associated with politics". Whether an inline citation is needed directly in the infobox depends on the usual Wikipedia:When to cite rules, namely whether the information is also present and cited elsewhere in the article. While political party affiliation can be "nuanced, complex, and frequently controversial", it is usually not, especially for people, such as political appointees, for whom this is actually relevant. "If relevant" appears in the documentation for {{infobox person}} more than a dozen times. If you can figure out whether to add |employer= or |height= or amateur radio |callsign= "if relevant", then you can probably figure out whether to add |party= "if relevant", too. WhatamIdoing (talk) 04:12, 13 August 2025 (UTC)[reply]
Oppose - mostly per Thryduulf. If it's used to signify some sort of political engagement (such as Kugler and Blanche being appointees in a political appointments system), I think it's 100% relevant and should be included. For other biographies it's probably relevant if it's matched by relevant text in prose (i.e. a celebrity who is also openly a member of and advocates for a political party). AlexandraAVX (talk) 09:53, 5 September 2025 (UTC)[reply]
Discussion (party affiliation in BLP infoboxes)
I would say that unless they are running/elected in a position that requires a political affiliation to be made as part of the election process so that we have a clear basis to document it, this should be left out of the infobox and explained in the prose. Masem (t) 16:41, 10 August 2025 (UTC)[reply]
I think that if they are explicitly running as a candidate for/in affiliation with a given party, and this is cited in the pose, then it should be in the infobox. Otherwise it should not be. Thryduulf (talk) 16:56, 10 August 2025 (UTC)[reply]
I agree too. Too often I see a supposed party affiliation being added to judge infoboxes (Scalia, for example), based not on party registration or self-declaration but by some third party claiming it, and that opinion being claimed as a RS. Wehwalt (talk) 17:23, 10 August 2025 (UTC)[reply]
I am thinking of many local elections that are intended as non-partisan positions, though candidates often assert their position in their campaign materials, in comparison to partisan offices that usually require party primaries to be elected to. In the latter case, the political affiliation is part of the election process and can't be disputed (making it fair to include the infobox). Masem (t) 17:33, 10 August 2025 (UTC)[reply]
If someone is explicitly running on a partisan position then that position should be in the infobox. Even if the position is intended to be non-partisan if someone is running on a partisan platform then it is de facto partisan. The job of Wikipedia is to represent what the reality is, not what it is/was intended to be. Thryduulf (talk) 17:57, 10 August 2025 (UTC)[reply]
I would be more clear in this comment and state that the infobox should be following what sources say. Brad Schimel was nonpartisan in the Wisconsin Supreme Court election earlier this year, but he was described as a Republican across various outlets. elijahpepe@wikipedia (he/him)18:27, 10 August 2025 (UTC)[reply]
That's exactly a situation that I would *not* include the political affiliation in the infobox, because that's not a requirement for running in that election. In prose, absolutely. Its the same reason we restrict calling out religion in the infobox for only those people who's careers are specifically tied to the church/equivalent body of their religion, though we are free to include any stated religious beliefs in the prose of the article. Masem (t) 04:11, 11 August 2025 (UTC)[reply]
Schimel is in an interesting position because he ran as a Republican in the Wisconsin attorney general elections he was involved in. Most of the cases where a politician running for a non-partisan office is clearly affiliated with a party involve prior elections. I was reading a local news report from Wisconsin that made it clear that Schimel was de jure non-partisan. In cases where a candidate explicitly says they are of a certain party but they are running for office in a non-partisan role and they have not run in any other elections where they would be a candidate for that party, then that should not be in the infobox. elijahpepe@wikipedia (he/him)19:32, 11 August 2025 (UTC)[reply]
For a given individual, in some cases it's clear that they're "directly associated with politics," in some cases it's clear they aren't, but there are some people/positions where it's unclear. Todd Blanche is someone I'd put in the third group. He is a political appointee in an ostensibly non-political position, but in this administration, it seems that the position is political as well. I don't think political party is a "nuanced, complex" issue. I also don't think people should be adding this info without an RS. FactOrOpinion (talk) 02:24, 11 August 2025 (UTC)[reply]
I would argue that Blanche should not have "Republican" in his infobox. He is not a politician nor a political advisor. The argument that the "position is political" is a reach from what is being suggested here. Wikipedia shouldn't make its own conclusions. In reliable sources, Blanche might be described as a Trump loyalist, but not a Republican, a rather vague term that doesn't encompass Blanche's fealty to the president. The prose can handle describing Blanche properly. elijahpepe@wikipedia (he/him)04:10, 11 August 2025 (UTC)[reply]
I think we should limit listings of party affiliation to people who ran for office as a candidate for the party or people who served as officials of the party. I have seen party affiliation listed for people who served in political office in a position that was elected on a non-partisan basis, I do not think that is justified. There are of course people who have had multiple party affiliations. If they served in office for multiple parties that can be listed. One thing to keep in mind is on occasion a member of one party has appointed people from a different party to their cabinet, so even cabinet members we cannot assume they share the party of the president. This is even more clear in cases or any sub-cabinet position, for judges many times so. The same probably applies even more so to people who serve on the cabinet of governors. Many mayors and other local officials in the US are elected on a non-partisan basis.John Pack Lambert (talk) 15:57, 11 August 2025 (UTC)[reply]
I don't think there is a one-size fits all solution. There are the obvious cases, candidate runs as a partisan in a partisan election. And on the other side, there are non-partisans who run in non-partisan elections. But, there are many people who may be known (either in independent sources or verifiable non-independent sources) as a partisan. And, there are individuals who run as a partisan in a partisan election who change parties or disaffiliate at some point after that election. And, for many subjects, there are BLP considerations to account for. --Enos733 (talk) 16:07, 11 August 2025 (UTC)[reply]
Political party is a voluntary act, not something that can be otherwise discerned, even by RSs. Unless there is evidence of voluntary affiliation, through registration to vote or entering a party primary that requires party membership, or being a party official of some kind, I would exclude. RSs without evidence of this are just partisan name callers. Wehwalt (talk) 17:22, 11 August 2025 (UTC)[reply]
If this is an RfC then it needs to be formatted and advertised as such. If it's just a discussion, perhaps in advance of a potential RfC, it needs to be relabeled. ElKevbo (talk) 00:30, 12 August 2025 (UTC)[reply]
The two examples provided are political BLPs and the infobox used is {{Infobox officeholder}}, not the generic {{Infobox person}}. Party affiliation is a basic and often uncontroversial piece of information for office holders. I appreciate that there may be more complexity with non-partisan state and local races and political appointees whose personal party affiliation may differ from that of the leader or body who appointed them. I agree with the comments above that someone like Sydney Sweeney should not have their party affiliation listed; if relevant and appropriate per WP:DUE and other applicable standards it can be discussed in the article body. If this is meant to be an WP:RFCBEFORE discussion, which would be helpful, it should be clarified that this does not apply to {{Infobox officeholder}}. I'm not yet convinced party affiliation should be completely deprecated from {{Infobox person}} but I may get there. It is inappropriate for most public figures who are not/have not been office holders who are not primarily known for political, partisan work. For folks known primarily for and associated with politics but who are not office holders, like commentators and strategists, it may be case-by-case. --MYCETEAE 🍄🟫—talk18:32, 13 August 2025 (UTC)[reply]
It really seems like this is a field that belongs in office holder infoboxes or modules with a start/end, and not for a generic person. I'm really struggling to think of situations where party seems appropriate for a person. Even for non-office holders who are clearly very partisan, it seems like the better way to do it would be to have it in the occupation or known for fields. Something like "occupation: <party> strategist", or "known for: <party> political writings" or similar. That strikes me as more neutral and verifiable for a potentially nuanced fact like affiliation. Driftingdrifting (talk) 17:07, 21 August 2025 (UTC)[reply]
I think for info boxes we should only ever list party affiliation for people who held public or political office, and not list it for people whose primary office was a non-partisan elected office.John Pack Lambert (talk) 13:36, 15 August 2025 (UTC)[reply]
If we did want to partisan affiliation to a non-political person's infobox, we'd have to weed through what to make of people who are registered with one political party, but have given significant donations to candidates of a different party; or who are registered as (say) a Democrat but who ran for political office on the Green Party ticket 15 years ago; and other combinations like that. I think it gets complicated quickly and it would be better to avoid it altogether. Just askin' for trouble. Novellasyes (talk) 18:06, 19 August 2025 (UTC)[reply]
LLM/AI generated proposals?
We had an RFC earlier this year around how to handle LLM/AI generated comments. That resulted in WP:HATGPT after further discussion at WT:TPG. Recently, an editor started a requested move using LLM generated content. I ran that content through two different AI/LLM detection utilities: GPT Zero says "highly confident", and 100% AI generated; Quillbot stated 72% of the text was likely AI generated.
Should HATGPT be expanded to allow for the closure of discussions seeking community input (RFC/VPR/CENT/RFAR/AFD/RM/TFD/RFD/FFD/etc) that are started utilizing content that registers as being majority written by AI?
I’m hesitant still with suggesting the use of gptzero except as additional evidence alongside with conclusive proof. But otherwise I’m always of opinion that most use of LLM in discussion is a bad faith usage of editor time. Bluethricecreamman (talk) 00:57, 12 August 2025 (UTC)[reply]
As I say every time things like this come up, the focus is completely wrong. We really should not care whether it is or isn't AI-generated, that's just wasting everybody's time trying to determine something that is irrelevant. If the proposal is understandable, relevant to the page it's on, isn't just rehashing something that's already been discussed to death (even if you disagree with it) then whether it was written by a human or machine couldn't be less relevant: deal with it as a good-faith contribution unless you have evidence it is not (use of an LLM is not evidence of good faith or of bad faith, it's completely independent of faith). If it is in bad faith, not understandable, trolling, rehashing a settled discussion, etc. then close it to avoid wasting time - this applies regardless of whether it is LLM-generated or human-generated. One of the many advantages of this approach is that it doesn't require any changes to policies or guidelines, because that's how Wikipedia has worked for many years. Thryduulf (talk) 01:00, 12 August 2025 (UTC)[reply]
"Fair" points perhaps, but not good points. Real editors who could be doing real things to benefit the project should not have to spend their time parsing machine-generate bloat in the hope that it will turn out to be the one-in-fifty case that isn't anywhere from fatuous vacuity to bullshit hallucination. The OP's linked example is an unfortunately poor exemplar of the problem, but anyone who's been active in project space over recent months has seen examples of text which makes you angry that someone expected you to waste your time reading it. You know how you can tell a tsunami is coming because the ocean suddenly recedes, leaving asphyxiating fish flopping on the sand? That's the stage we're at right now. We should respond to AI-generated text the way we'd respond to text in Klingon: tell the author to come back when they can write in English. EEng01:32, 12 August 2025 (UTC)[reply]
And take a look at this [1] ANI discussion for a truly epic example of how one AI-drunk incompetent can waste hours of the time of a dozen competent editors. `EEng02:41, 13 August 2025 (UTC)[reply]
"AI-drunk" reminds me of drunk driving. Cars a powerful and dangerous tool. We have licenses to operate, competence restrictions (age, eyesight), training courses, rules of the road, consequences for violations, etc.. the alternative is ban cars entirely because horses, public transport and walking work fine. -- GreenC04:37, 15 August 2025 (UTC)[reply]
Except we don't have licenses, competence restrictions, training courses, rules of the road, consequences for violations, etc. for AI. All we have is doofuses careening left and right, knocking down pedestrians, tearing up the pavement, frightening the horses, jamming the roadways with their vehicles actually headed nowhere, and poisoning the air with noxious fumes. So yeah, until those issues can be addressed AI should be banned, and walking, cycling, horses, and public transit -- which have served WP very well to date -- will have to continue serve until AI gets to the point that it can magically transform those lacking competence in English, and/or an understanding of what an encyclopedia is, into useful contributors. EEng23:39, 21 August 2025 (UTC)[reply]
I agree. LLMs are getting better, and we will very soon be unable to spot their output.[2] We need to deal with problem posts and edits the way we always have. Donald Albury01:43, 12 August 2025 (UTC)[reply]
Some guy at some company says his people have trouble recognizing fake videos with their naked eyes. So what? You want to throw in the towel right now based on that? EEng03:40, 12 August 2025 (UTC)[reply]
To some extent I agree, but just because LLMs aren't improving fast doesn't mean they aren't improving at all. Especially the biggest and most obviously identifiable tells remaining are likely to be improved on, even if the strategy of just making bigger and more powerful models no longer leads to large increases in performance. Loki (talk) 22:57, 16 August 2025 (UTC)[reply]
If it makes you feel better, pretend we're enforcing our existing policy on meatpuppetry to remove text written by somebodything other than the user account editing it onto the page. —Cryptic01:57, 12 August 2025 (UTC)[reply]
I used to think that that agnosticism about the source of commentary is correct but I have changed my mind. The choice is not between using an imperfect heuristic like "is this LLM-generated" and sedulously evaluating the content of discussions. As others have pointed out, editor time is a limited and precious resource. Since LLMs make it easy for editors who would not have otherwise been able to do so to add superficially plausible content to a discussion, we can expect that volume of content to increase, without a corresponding increase in time to evaluate it. That means our standards for discussion are going to shift in the direction of being more BITEy and intolerant of imperfect contributions regardless of whether we adopt any rule regarding LLMs. If LLMs really do improve to the point of undetectability, as Donald Albury suggests, then we're probably going to be driven into a different set of heuristics with hard and stringently enforced limits on WP:BLUDGEON and so on. But for now, LLMs do seem to have a distinct "register", even if it's hard to prove with certainty, and I think it might be more fair to go after that while we can. Choess (talk) 03:43, 13 August 2025 (UTC)[reply]
@Thryduulf As I say every time you make comments like this, I disagree. The source matters and LLM use is evidence of bad faith, because it shows the editor doesn't care, doesn't respect the community's time, and is happy to outsource their brain to a machine. We should have a heavy bias towards proposals created by thinking, breathing humans, not something someone lazily asked a bot to slap together. The former has value, even if the proposal is dumb; the latter is slop and without any worth. Cremastra (talk·contribs) 13:45, 16 August 2025 (UTC)[reply]
LLM use is evidence of bad faith, because it shows the editor doesn't care, doesn't respect the community's time, and is happy to outsource their brain to a machine. I couldn't disagree with your rabid assertion (note it's not even an assumption) of bad faith more strongly. LLM use is not evidence of faith, good, bad or otherwise. What matters is the faith of the user, and that is not demonstrated by their using an LLM because some users of LLMs do so in good faith (for example those completely unaware of the attitude of some editors here towards it) while others do it in bad faith. Please stop assuming that everyone who has a different opinion of LLMs than you is inherently out to destroy Wikipedia - they are not. Thryduulf (talk) 13:53, 16 August 2025 (UTC)[reply]
By the way, I don't assume that everyone who has a different opinion of LLMs than you is inherently out to destroy Wikipedia. I assume that (1) article contributions based on AI are bad for the encyclopedia, even if the intent is good, and (2) talk page contributions based on AI are evidence of bad faith, (3) that AI is a bad thing. Cremastra (talk·contribs) 13:59, 16 August 2025 (UTC)[reply]
Now for some facts:
Some, but not all, article contributions based on AI are bad for the encyclopaedia. Good contributions based on AI are indistinguishable from good contributions that have been nowhere near an LLM.
Some, but not all, talk page contributions based on AI are left in bad faith. Use of AI alone is not evidence of good or bad faith.
Not all AI is LLMs. Not all AI, and not all LLM, is bad (or good) - it is vastly more nuanced than that.
In effect, the AI/LLMs-on-Wikipedia debate is divided between those like you who want to assess the content of the contribution, regardless of its origin, and those like me who think it's just simpler to ban LLMs because they're a net negative and more trouble than they're worth. The upside of your approach is that it's less likely to chase away potentially positive contributors; the downside is that it means a lot of cleanup work and AI slop to manage. The upside of my approach is that it's clean, simple, and effective; the downside is that it is best suited for cynical, paranoid people like myself. Cremastra (talk·contribs) 15:45, 16 August 2025 (UTC)[reply]
In general I agree with your last comment, but I have a few quibbles:
it means a lot of cleanup work and AI slop to manage is incorrect. Slop will continue to be posted whether LLMs are banned or not for multiple reasons - not all slop is LLM slop, we have absolutely no way of determining whether something is or is not LLM-generated before it is submitted, and bans don't stop people doing the thing that is banned (either in good faith because they don't know it's banned, or in bad faith because they do it anyway). Fortunately we already have all the tools we need to manage this as best we already can: slop can be closed/hatted/reverted (as appropriate to the situation) regardless of whether it is LLM-slop or human-slop, disruptive non-slop can be closed/hatted/reverted (diito) regardless of whether it is LLM-disruption or human-disruption. So in summary neither approach changes the amount of cleanup work required.
Your list of downsides to your approach neglects to include the significant harm to the project from driving away good-faith editors and the amount of needless disruption caused by arguments over whether something is or is not LLM-generated.
dividedWell... going by the outcomes of the last half dozen LLM P&G RfCs, I'd say this division is like an 80/20 split in favor of "ban all LLM slop", and closer to 90/10 if the opposition is at Thryduuulf's level... Anyway, it's not like copy-pasting LLM output in conversations or as scholarship is considered "okay" in the wider world, in which case we could AGF a bit more for newbies who don't realize it's not acceptable here. So frankly I have no qualms about biting an editor who needs an unfiltered LLM to communicate as they are either too lazy/incompetent to be a productive editor or they belong in a different language edition. JoelleJay (talk) 18:51, 16 August 2025 (UTC)[reply]
I am not okay with endorsing the biting of any editor, for any reason, let alone enshrining a requirement to do so in policy. Such is fundamentally incompatible with Wikipedia's basic philosophy and I'm horrified that people are seriously considering it. Thryduulf (talk) 20:40, 16 August 2025 (UTC)[reply]
I agree with Tryptofish's comment here on the matter. Correct me if I'm wrong, but I think you see LLMs and generative AI as a valid tool that can be misused; I, and many others, I think, see it as a tool that is fundamentally not appropriate for editing an encyclopedia. Cremastra (talk·contribs) 16:07, 17 August 2025 (UTC)[reply]
I think you see LLMs and generative AI as a valid tool that can be misused... yes and no. The current generation of LLMs are unsuitable for making edits to the text of articles without full human review (AI-generated images are not really relevant to this particular discussion and are best treated separately anyway); whether LLM+human review is more or less "efficient" than a fully-human edit is a matter of personal opinion that is likely to be impacted by the nature of the specific edit. In most, but importantly not all, cases unreviewed LLM-based contributions to talk pages are not a net benefit. However this misses the fundamental reasons I disagree with you, which is that you see any use of LLMs as automatically meaning that the person using the LLM is contributing here in bad faith whereas I see evidence of people using LLMs here in both good and bad faith. Specifically there are many people who make LLM-based comments with a sincere desire to improve the encyclopaedia without knowing that there are many editors here whose views regarding AI are so blinkered that they cannot or will not consider that someone can do such a thing.
My response to Tryptofish's comments are similar: we do not BITE those who are incompetent or NOTHERE because we give them a chance to demonstrate that they can contribute constructively before blocking them, and when we do block them we do so on the basis that they either cannot or will not do so. That is fundamentally different to someone who currently is not contributing in a manner we approve of but who may (or may not) be capable and willing to when they learn what that means - if it turns out that they cannot or will not then it is appropriate to deal with them in the same manner we treat those who are incompetent or NOTHERE but who do not use LLMs. Simply using an LLM is not evidence, on its own, of bad faith, incompetence or of not being here to improve the encyclopaedia.
UPE is also similar in this regard - while there are unarguably many undisclosed paid editors who are here in bad faith there are also such editors who are here in good faith but simply do not know our rules and do comply when they learn that they need to (and how to do that). There are additionally an unknowable number of undisclosed paid editors who exclusively make good quality contributions to unquestionably notable topics such that nobody even suspects they are paid editors and they never learn they should disclose. So again, simply being an undisclosed paid editor is not evidence, on it's own, that one is here in good or bad faith.
Separate from the issue of faith is that, as multiple other people have also pointed out, is that contributions that are actually bad, whether LLM-generated or not, can already be dealt with under existing policies and guidelines so there is simply no need for a policy/guideline specific to LLMs. Thryduulf (talk) 09:15, 18 August 2025 (UTC)[reply]
It is not a question of whether an LLM comment is necessarily bad and therefore should be removed. The point being made is that nearly all LLM comments are disruptive because of their length and thrown-at-the-wall details (and the fact that they are rarely helpful). Replying to such comments would require significant effort. Further, there is a good chance that replies will be ignored by the editor concerned. Debating LLMs would lead to their normalization which could easily overwhelm talk pages and noticeboards. Johnuniq (talk) 10:55, 18 August 2025 (UTC)[reply]
Comments that are disruptive can already be hatted/removed regardless of why they are disruptive and regardless of whether they are LLM-generated or not. Comments that are LLM-generated but not disruptive (which you acknowledge exist) should not be removed. Thryduulf (talk) 11:11, 18 August 2025 (UTC)[reply]
Comments that are LLM-generated but not disruptive (which you acknowledge exist) should not be removed. I disagree. I think it is not too much to ask to communicate with actual human beings. Talking with an actual user as opposed to through the screen of an LLM makes communication a lot easier. Cremastra (talk·contribs) 14:12, 18 August 2025 (UTC)[reply]
Then you are in luck, an actual person will be the one that posted the content and the one you are talking with. LLMs do not post on their own, they all require human thought and input. Thats how they work. PackMecEng (talk) 14:21, 18 August 2025 (UTC)[reply]
That’s not entirely accurate. While it’s true that an LLM doesn’t autonomously log in and hit “submit,” it’s misleading to suggest that posts generated by an LLM are purely human in origin. In practice, many edits and comments across platforms are authored almost entirely by machine output, with minimal or even no meaningful human oversight. The “input” may just be a short prompt, but the bulk of the content—including the structure, wording, and even factual framing—comes from the model.
Equating that to “human thought” risks blurring the distinction between genuine human authorship and machine-assisted or machine-generated text. Saying “an actual person posted it” ignores that the human role might be closer to pressing a button than actually creating the content. That distinction matters if we care about originality, accountability, and reliability of information. CMD (talk) 15:07, 18 August 2025 (UTC)[reply]
And if we know that they did not check what they are submitting you would be correct. But we cannot know that. Its just assuming bad faith at that point. So we go off the assumption that when someone hits submit they checked what they are posting. There is no other option. So yeah, I am going to ignore the distinction because it has no value and does not matter. PackMecEng (talk) 16:33, 18 August 2025 (UTC)[reply]
That’s not entirely accurate. It’s misleading to suggest that posts generated by an LLM are human in origin simply because a human hit the submit button. In practice, many edits and comments across platforms are authored almost entirely by machine output, with minimal or even no meaningful human oversight. The “input” may just be a short prompt, but the bulk of the content—including the structure, wording, and even factual framing—comes from the model.
Equating that to “human thought” risks blurring the distinction between genuine human authorship and machine-assisted or machine-generated text. Saying “an actual person posted it” ignores that the human role might be closer to pressing a button than actually creating the content. That distinction matters if we care about originality, accountability, and reliability of information. -- LWGtalk17:39, 18 August 2025 (UTC)[reply]
Equating that to “human thought” risks blurring the distinction between genuine human authorship and machine-assisted or machine-generated text. firstly there is a strong community consensus that machine-assisted and machine-generated text are not the same. There is a strong community consensus that the former is not inherently problematic, and a lesser consensus that only unreviewed LLM-generated text is.
Regardless, there is no benefit to making any of these distinctions because if the text is disruptive it can already be removed regardless of which of the three types it is. Nobody has given any justification for removing text (of any origin) that is not disruptive. Thryduulf (talk) 17:42, 18 August 2025 (UTC)[reply]
LLM-generated content, and even comments with a significant LLM assist, are disruptive because they are not written by a real human being. Is it too much to ask to communicate with people as opposed to having users export their minds to an AI? Is that really so radical? I simply cannot understand your perspective on LLMs. How is using an LLM to communicate ever appropriate? Cremastra (talk·contribs) 18:07, 18 August 2025 (UTC)[reply]
@Thryduulf I agree with you that there is a distinction between machine-assisted and machine-generated text, and that the former is not inherently disruptive. I also agree with the strong community consensus (against which you appear to be one of the few dissenting voices) that unreviewed LLM-generated text is inherently disruptive and is unacceptable on this wiki (though I share your concerns about feasibility and enforcement of some of the countermeasures that have been proposed).
I think where we differ is in our view of text that falls between the extremes. I think your insistence on ignoring source and judging text entirely on content disregards the fact that a large part of the meaning of any text is its surrounding context. The same text can be disruptive if it comes from one source in one context while being fine from a different source in a different context. One of the most essential pieces of context in any communicative act is who is the speaker. We already have firm rules here that it is totally unacceptable for editors to outsource their writing to a hired human, so I see no reason why we should tolerate outsourcing to a SaaS that does the same work. Likewise, we consider that any editor who copy/pastes content from an external website has an obligation to disclose where they copy/pasted the content from and their rationale in doing so, and I see no reason why we should tolerate undisclosed copy/pasting from an external website that dynamically generates the content on demand. I recognize that there's fuzzy space in the middle and I recognize that we should be cautious when making new rules, but I think your treatment of the issue is incomplete. -- LWGtalk18:40, 18 August 2025 (UTC)[reply]
Another consideration is copyright. If an editor posts an article that they did not write, that would seem to violate the existing copyright rules of Wikipedia. I was going to dig into the legal side of it, but got stuck on the answer that Google's AI came up with: "Copyright protection requires human authorship; works generated solely by AI are not copyrightable, but works that are assisted by AI can be if a human exercises sufficient creative control over the final output." I though this was actually a good starting point for policy, that is, the concept of "sufficient creative control". Rublamb (talk) 20:09, 26 August 2025 (UTC)[reply]
Wikipedia's legal policies don't require that every edit be copyrightable. It's okay to post public domain and non-copyrightable edits.
What we need is to not violate copyrights. If there is no copyright to be violated (something that can be difficult to determine), then there's no violation of our legal policies. However, we could always complain about Wikipedia:Plagiarism (a non-copyright problem of claiming that you wrote something when you didn't). WhatamIdoing (talk) 19:57, 27 August 2025 (UTC)[reply]
Oppose (kind of): I support the idea in theory. But the linked move request would have been WP:SNOW closed as oppose anyway. What happens if someone posts a LLM-generated RfC that people support (which will likely happen)? Or if someone posts a LLM-generated RfC on a perpetual source of drama, and people respond to it before the LLM use is noticed (which will also, maybe even more likely, happen)? Gnomingstuff (talk) 06:54, 12 August 2025 (UTC)[reply]
Current practice for discuassions that don't need closing seems to be someone asks if llm was used, and then either it is rather unbelievably denied, or there is some pivot to "you should focus on the argument rather than the method" which I'm pretty sure llms must be offering as a reply given how consistent it is. After that the discussion tails off. For those that do need closing and would otherwise linger wasting everyone's time, I would agree with the proposal that the guidelines should allow someone to quick close them, while not making it mandatory. CMD (talk) 07:18, 12 August 2025 (UTC)[reply]
If LLMs are to be allowed to generate such requests then simply ask an LLM to generate a reply based on your position, make sure to ask it to give detailed explanations now all the points it raises. If it's the case then maybe someone could create a script to autogenerate comments, or even the whole discussion. Editors shouldn't be expected to put more effort into replies than the original poster put into theirs. -- LCU ActivelyDisinterested«@» °∆t°09:37, 12 August 2025 (UTC)[reply]
If generating the original comment using an LLM isn't trolling then neither is the reply. If the reply would be trolling then the original comment should be hatted. If people think that editors should be allowed to use LLMs, then streamlining the process so everyone can use them is surely desirable. -- LCU ActivelyDisinterested«@» °∆t°14:41, 13 August 2025 (UTC)[reply]
I would tend to support this, although with two caveats. Firstly, that AI detection software, while useful, isn't perfectly accurate and shouldn't be exclusively relied on for that purpose. And, secondly, that proposals getting reasonable support shouldn't be closed just because the original proposal was AI-generated, while those with no support can be immediately closed based on that.The main issue for me (and the reason why I believe this is not comparable to existing human-written discussions) is that it is trivially easy to generate long proposals with AI, and that it comparatively takes a much larger amount of volunteer time to analyze (and usually dismiss) these proposals. This imbalance is simply not fair to our volunteers, and having to repeatedly deal with AI-generated proposals will just slow down community discussions and divert precious resources from more well-thought proposals. Chaotic Enby (talk · contribs) 13:21, 12 August 2025 (UTC)[reply]
Support - To address the concerns about good proposals written with AI being closed, if it's so obvious a good idea, it would certainly be proposed quickly anyway. I don't think the benefit of a theoretical wonderful AI-written proposal that wouldn't be suggested anyway is worth the massive downside of giving any kind of additional foothold to LLMs. LLMs are an existential threat to Wikipedia as a useful project, and I see it as our mission to stop it wherever it is possible to do so.CoffeeCrumbs (talk) 17:28, 12 August 2025 (UTC)[reply]
Support speedy-closes of formal discussions created primarily/entirely by chatbot - It's highly unlikely the people using the chatbots are willing (assuming they're able) to make coherent arguments based on policy and a reading of the available sources, but if they are there's no reason to bring in a fallible script that's huffing nutmeg. Even the most perfunctory human-written discussion is better than a long AI-written post simply because the human is far better at source critique and rebutting opposing arguments. As Enby says above, I wouldn't support speedy-closing any discussion which has already attracted some amount of commentary before its provenance was discovered. —Jéské Courianov^_^vthreadscritiques17:50, 12 August 2025 (UTC)[reply]
It's highly unlikely the people using the chatbots are willing (assuming they're able) to make coherent arguments based on policy and a reading of the available sources, but if they are there's no reason to bring in a fallible script that's huffing nutmeg. – Yes, this is another excellent point. I believe our attitude should be that use of AI to generate either article text, or discussion text, is ipso facto proof of incompetence as an editor -- because no competent person would think that AI-generated text is a useful contribution -- and should result in an immediate indef. I am not kidding about this. Shoot to kill. (Unblock only after a clear statement that they now understand the issue, but a second offense should be another indef, with a minimum 12 months before unblock may be re-requested).As for the wikt:bleeding hearts who worry about people who would not be able to contribute without relying on AI to write for them: well, if you can't write it yourself, neither can you review what AI wrote for you, so I'm afraid we can't use you on the project. EEng22:25, 12 August 2025 (UTC)[reply]
Questioning someone's competence is not questioning their good faith, but stupid sincerity is not enough. And I do not apologize for BITE-ing a robot, even if it speaks through a ventriloquist's dummy in human form. To paraphrase someone that I'm not likely to quote ever again: Extremism in defense of Wikipedia is no vice. Moderation in tracking down and stamping out AI-generated crap posted by script kiddies is no virtue.[3].If we don't take dramatic action immediately, our cherished Neutral Point of View will soon give way to the Neural Point of View. (You can use that quip free of charge.) EEng01:00, 13 August 2025 (UTC)[reply]
P.S. I dare anyone to take a gander at this [4] ANI discussion and not be angry at the time wasted by competent editors who are forced to wade through the AI slop being posted -- and defended! -- by this one incompetent. And I have no problem calling him incompetent, since he obviously lacks common sense. EEng02:41, 13 August 2025 (UTC)[reply]
Yeah, I don't people realize how bad the problem has already gotten. A lot of the AI slop has gone undetected despite being blatant; you can't really say anyone's being "forced to wade through the AI slop" considering how few people are actually wading through it. I haven't even really done much to fix it myself -- my main skill is tracking down and identifying problems, and I'm OK with that. (Maybe I should have been an auditor.)
But the AI cleanup backlog jumped from ~100 AI articles to ~400 in a couple of days, not due to a sudden influx of slop, but because I singlehandedly found 300 instances of slop that was already there. This isn't me being self-aggrandizing, just stating the facts. I didn't use any special tools besides a few simple targeted regexes -- I typed phrases we already know about into the Wikipedia search box and investigated the obvious cases. Anyone else could have done the same thing anytime in the past 2 years, rather than insulting people who often really do genuinely think they are helping the encyclopedia, sometimes because they've been encouraged to do so through edit-a-thons, Wiki Ed courses, or the Wikimedia Foundation itself. Their edit summaries often mention "improving the encyclopedia," "rewriting for a neutral tone," etc.
I've literally been tracking down hundreds of AI-generated articles for the past several days. Please don't tell me what I do and don't worry about. Gnomingstuff (talk) 23:08, 12 August 2025 (UTC)[reply]
If you're addressing me: I didn't tell you or anyone else what they worry about. I addressed any editors who happen to harbor a particular worry which I specified, and discussed that worry. EEng01:00, 13 August 2025 (UTC)[reply]
+1 to everything EEng has said. AI contributions have no value, and I'm tired of people tip-toeing politely around AI slop and pretending it's something other than a steaming garbage heap. Quite frankly it smells of appeasement. Cremastra (talk·contribs) 13:52, 16 August 2025 (UTC)[reply]
Except we're not tip-toeing politely around AI slop we're pointing out that AI slop can be dealt with under existing policies and guidelines because all slop can be dealt with under existing policies and guidelines regardless of whether it is human slop or AI slop. Thryduulf (talk) 13:55, 16 August 2025 (UTC)[reply]
Irrelevant - given that the actual proposal at an RM is simply “current title —> proposed title”, I don’t think it matters if someone uses an LLM to generate it. Similarly, an RFC question/proposal is supposed to be brief and neutral (example: “Should the article say ABC instead of XYZ?”) and, again, I don’t think it matters how that basic question is generated (In fact, I would love to train LLMs so they generate RFC questions this way).What I think is actually being objected to is using an LLM to generate the proposer’s opening statement (explaining why they think the move should take place, or why ABC should be replaced with XYZ) … but that is commentary on the proposal, not the proposal itself… and commentary is already covered by HATGPT. Blueboar (talk) 19:04, 12 August 2025 (UTC)[reply]
That is correct, and it's because the opening statement is essentially the proposer's argument for why XYZ should happen. It isn't something an LLM actually has the capacity to summarise or explain in most cases, especially if offline sources are being used for the argument (as LLMs generally cannot access those); using one for the purpose basically forces the proposer to waste time clarifying whatever the LLM said than actually defending their proposal, and that's outright ignoring the LLM's divinorum addiction. —Jéské Courianov^_^vthreadscritiques21:06, 12 August 2025 (UTC)[reply]
But HATGPT already covers this. We can discount comments generated by an LLM… It doesn’t matter whether that comment is the initial comment (by the proposer) or a subsequent comment (by an editor responding to the proposal). Blueboar (talk) 12:41, 13 August 2025 (UTC)[reply]
But, if someone opens a proposal and their original comment gets collapsed, should other volunteers have to spend their time opposing the proposal? That's the question this new policy tries to answer – they shouldn't. From what I understand, HATGPT would leave the proposal open (and taking volunteer time from more relevant proposals), just without the opening comment. Chaotic Enby (talk · contribs) 13:06, 13 August 2025 (UTC)[reply]
@Chaotic Enby: That's the wrong question. At present, without any change to any guideline or policy, editors already do not have to spend their time opposing any struck/collapsed proposal, even if a human had written it. We already can speedily close; a guideline saying "you can" when a policy already suggests "you should" (that policy being WP:NOTBURO) would be a bad guideline. If there is no driving rationale for a change from the status quo in the discussion, and everyone is supporting the status quo—and there is therefore no controversy—the formal process is a waste. Editors can keep talking about how they all agree that something is okay "in their spare time", not using resources of venues such as AfD, RM, etc.: The scaffolding of "7+ days' listed specifically-formatted discussion that must be closed" is not needed. Such processes are closed with a speedy endorsement of the status quo (such as Wikipedia:Speedy keep—an existing guideline about this). NOTBURO says: "Disagreements are resolved through consensus-based discussion, not by tightly sticking to rules and procedure". So, yes, some constraints of "rules and procedure" may help consensus-formation develop more harmoniously because there is disagreement (which may be accompanied by a little bit of tension and a human tendency to stonewall or overstep, especially when advanced tools with limited access are involved) ... but if there is no disagreement, why any rules, and why any procedure? The driving rationale for a change can evaporate in any discussion, turning a (seemingly or truly) controversial issue into a non-controversial one, and this can happen in a variety of ways. One such way is withdrawal/reversal of a !vote. Another is the nomination/comment being struck: ban/ARBECR violation, sockpuppetry, meatpuppetry, trolling, and AI content—already in WP:AITALK. So the only change might be: Should AI use be exempt from this general logic, and should editors become obligated to treat struck AI content as nominations/comments that are not struck. So this is fundamentally a relitigation of AITALK: If they are struck, but editors must begin to behave as if they were not, the striking of AI comments becomes striking in name only (just a visual change, no functional difference) and AITALK is effectively abrogated. So the proposal in this discussion is to overturn AITALK with the detail of leaving functionally meaningless striking-in-name-only in place. Blueboar is entirely correct. This discussion is badly framed and its no consensus outcome could improperly undermine AITALK.... and the oppose !votes reflect this, as they intuitively understand the stakes. So, for example, below, opponents say: Unless a detection method is found that is consistently accurate I don't really trust others vibes to remove users votes in something, I think any procedure such as hatting suspected LLM-produced material has the potential of encouraging the biting of newcomers, and similar. So, comments should not be struck/collapsed ("removed"). That is just a !vote to abrogate AITALK, indistinguishable from a comment opposing adoption of AITALK in a discussion on whether to adopt AITALK ... but AITALK has already been adopted. Now, editors are building consensus for AITALK again, trying to persuade opponents of AITALK that it should be understood to mean what it already means. As these opponents oppose AITALK to begin with (because of a total skepsis toward the possibility of doing something about the AI problem / deeply-held view that it is not a problem), they will of course never be persuaded about some particularity regarding the application of this thing that should not be a thing and will embrace the premise that the thing is toothless and that a consensus is needed to give it teeth. At the same time, supporters of AITALK will not !vote in favor of AITALK-as-AITALK (aware or unaware of its practical implications) believing that their support is not needed because it has already been adopted. Therefore, this time, acceptance of AITALK will fail. The starter of this discussion wanted to make AITALK "stronger", but instead caused it to be undone. This is why RfC questions need to be neutral and need to contain a proposal to change the status quo without misrepresenting the status quo. —Alalch E.23:58, 21 August 2025 (UTC)[reply]
This also gives AI comments extra priority and durability over human comments: While a human comment being struck could cause a discussion to be closed, an AI comment the same as that human comment being struck cannot cause a discussion to be closed, because showing this RfC to the errant speedy closer should lead that closer to concede that they acted in error, against community consensus, because treating struck AI votes the same as struck human votes is a rejected proposal: namely, policies and guidelines do notallow for the closure of discussions seeking community input (RFC/VPR/CENT/RFAR/AFD/RM/TFD/RFD/FFD/etc) that are started utilizing content that registers as being majority written by AI—the accepted status-quo premise of this discussion. —Alalch E.00:36, 22 August 2025 (UTC)[reply]
WP:CCC, as to The starter of this discussion wanted to make AITALK "stronger", but instead caused it to be undone, it was not my intent to undermine AITALK whatsoever. The language at AITALK definitely could have been written better to make clear there was already a consensus for this. And the only reason this was turned into an RFC was because of the constant bolded !votes. I had a feeling I didn't understand the full history of AITALK/HATGPT, hence why I explicitly said I was looking for feedback in advance of a proposal. —Locke Cole • t • c00:48, 22 August 2025 (UTC)[reply]
I do agree with your analysis, although I don't think WP:NOTBURO says "we should" to anything. But yes, if anything, AITALK should be at least retained: the current discussion is not specific enough to find a consensus to revert it in part or as a whole.However, as the example that started this whole discussion showed, I don't think AITALK made it explicit enough that hatted AI content was to be treated as a struck nomination and explicitly allowed for an instant closure. The spirit of the policy certainly did, but the letter didn't, thus this discussion. Mostly because "the spirit" is something vague and, ultimately, a bit subjective. And having the policy itself make it explicit would remove this disagreement. Chaotic Enby (talk · contribs) 10:38, 22 August 2025 (UTC)[reply]
I'm pretty sure the LLM generated the entire request. If you go back to the diff I posted, go look at that page as it looked during the first edits: they inserted it into the wrong place on the page, and I get the impression it didn't know how to fill in certain fields so it left some blank. But if it makes any difference, I also object to the "opening statement" being majority-written by an LLM. —Locke Cole • t • c03:14, 13 August 2025 (UTC)[reply]
By "entire request", you mean only the first of the 10 comments posted in that RM by the newbie, but none of the significant and substantive arguing you and the OP did over (a) the actual question and (b) whether an LLM was used in the first comment, right?
Support — Blueboar presents a convincing enough argument in favor of this proposal. I consider this to be an extension of existing policy. Talking about discussions over whether a proposal is AI-generated should be conducted in criticisms of the existing HATGPT rule. elijahpepe@wikipedia (he/him)03:38, 13 August 2025 (UTC)[reply]
Support clarifying existing policythis wasn't a formal RFC when I initially commented and as of now it's unclear what exactly people are !Voting on to make it clear that using an LLM to generate opening statements of discussions is just as unacceptable as using an LLM to generate replies. As Cryptic alluded to above, using LLM to generate substantive content in discussions (as opposed to minor copyediting/formatting) is essentially the same or allowing someone else to log in and edit using your account. If we do not allow editors to direct their (human) personal secretary to edit on their behalf, why would we tolerate the same conduct when the secretary is replaced by an LLM? Or, from a different angle, content that is substantively copy/pasted from LLM output should be treated like content that is copy/pasted from other sources, which if not attributed goes against WP:PLAGIARISM. Policy aside, I believe any editor who generates content wholesale with an LLM should as a matter of courtesy/transparency indicate that they have done so, and indicate the model and prompt used. -- LWGtalk18:34, 13 August 2025 (UTC)[reply]
why would we tolerate the same conduct when the secretary is replaced by an LLM – What we're seeing in AI use is way worse than that. It's less a human using an AI secretary to generate content, and more an AI entity using a human (or ventriloquist dummy in human form) to post its content. It's not a human using AI -- it's AI using humans. EEng19:53, 13 August 2025 (UTC) P.S. BTW, indicating the model and prompt used isn't enough, since in general an LLM's response to whatever you just asked it is shaped by the entirety of one's prior interactions with it.[reply]
I think you'd be fully within your rights to close that discussion per existing consensus. If anything, the text at WP:HATGPT is too watered down from the RfC closure, which said that "if a comment is written entirely by an LLM, it is (in principle) not appropriate". IMO, something to that effect should be added to the policy text. —pythoncoder (talk | contribs)21:45, 13 August 2025 (UTC)[reply]
Whether or not we need to expand HATGPT, I'm all in favor (aka support in a broad sense) of shutting down any discussion that wastes the community's time, and anything that resulted from some software "thinking" about it, rather than a human thinking about it, falls in the category of shut-it-down. Base it on IAR, or base it on common sense. I see some pearl-clutching about BITE and AGF, but that strikes me as so 2024. We are facing something that can scale to a magnitude that we will be unable to deal with it, unless we are realistic about the need to deal with it assertively. --Tryptofish (talk) 23:08, 13 August 2025 (UTC)[reply]
Just to add to my previous comments… If it is felt that HATGPT needs to specify that it applies to the explanatory language of a proposal as well as subsequent comments, I don’t object to amending HATGPT. Blueboar (talk) 00:06, 14 August 2025 (UTC)[reply]
Seeing the ongoing disagreements about BITE, something additional that occurs to me is that the community has long been at least reasonably comfortable with WP:Competence is required. It seems to me that editors who feel like the only way that they can participate in the community is by letting LLMs do their writing for them are running afoul of competence. (I'm referring here to LLMs, not assistive technologies such as screen readers.) We don't regard it as a BITE situation when we issue a WP:NOTHERE block, and I think that a user who equates LLM-generated content with encyclopedic content is likely to be not-here. --Tryptofish (talk) 22:14, 16 August 2025 (UTC)[reply]
Support. WP:AITALK already allows for the collapsing and striking of LLM-generated proposals, since they are a subset of LLM-generated comments, but this particular bullet point does not yet comment on whether the ensuing discussion should be closed. Discussions that lead with LLM-generated comments are often unconstructive, and frequently devolve into arguments about LLM use or bludgeoning with additional LLM-generated comments. Since there appears to be some uncertainty about whether LLM-led discussions can be closed, WP:AITALK should be amended to clarify that they can be, per a combination of the existing WP:AITALK text and this portion of the Marking a closed discussion section: "If a discussion has been so disruptive or pointless that it is better for editors to waste no further time even looking at it, the alternative templates {{Hidden archive top}} and {{Hidden archive bottom}} can be used instead, to produces a similar 'closure box' around it, but collapsed to hide the content, as with off-topic threads", although any collapsible template would work. An editor who posts an LLM-generated proposal can resubmit the proposal if they manually write it in their own words.I also support Pythoncoder's suggestion to have WP:AITALK explicitly designate LLM-generated comments as inappropriate, in line with the consensus at Wikipedia:Village pump (policy)/Archive 199 § LLM/chatbot comments in discussions. In practice, LLM-generated comments are already recognized as disruptive, especially when undisclosed. — Newslingertalk07:57, 14 August 2025 (UTC)[reply]
Oppose - Unless a detection method is found that is consistently accurate I don't really trust others vibes to remove users votes in something. It is important to remember the previous consensus on the topic, specifically The word "generative" is very, very important here, though. This consensus does not apply to comments where the reasoning is the editor's own, but an LLM has been used to refine their meaning. Editors who are non-fluent speakers, or have developmental or learning disabilities, are welcome to edit here as long as they can follow our policies and guidelines; this consensus should not be taken to deny them the option of using assistive technologies to improve their comments. In practice, this sets a good lower bound for obviousness, as any comment that could conceivably be LLM-assisted is, by definition, not obviously LLM-generated. In practice most LLM-assisted comments are not noticed because it does not actually matter. Anything else can be dealt with existing policy. I am similarly not convinced by the pearl clutching on wasting editors time, Wikipedia editors have been able to do that for decades without using LLMs and the addition of them has not been a noticeable uptick in it that I can tell. This is not some crazy crisis that will doom the pedia, it is a tool, nothing more. The usual garbage in garbage out applies in most issues with using the tool. PackMecEng (talk) 00:33, 15 August 2025 (UTC)[reply]
@WhatamIdoing This quote and archive link might be what you were asking about on my talk page. @PackMecEng, you might consider what @Gnomingstuff has shared above, the amount of LLM content being found in articles has increased significantly, and usage of it on talk pages is only going to get worse. You call it pearl clutching, but if the scale of LLM use increases then it will be a significantly bigger time sink for Wikipedia editors. At what point do we all just shut off our browsers and just let LLM's argue back and forth on our behalf with a sentence or two to get them started? I edit and comment on talk pages because I want to interact with other editors, not people running chatbots and copying/pasting their responses or proposals in bad faith with little actual time investment on their part. —Locke Cole • t • c00:42, 15 August 2025 (UTC)[reply]
What a lame cop-out. You could say the same thing about anyone who stirs the pot in nonproductive ways -- "Well, no one's forcing you." But someone has to deal with AI-generated vapid crap proposals, discussion posts, and so on. No matter who grits their teeth to do it, it's time that could have been productively spent elsewhere. EEng03:41, 15 August 2025 (UTC)[reply]
But someone has to deal with AI-generated vapid crap proposals, discussion posts, and so on. firstly no they don't - such posts can be simply ignored by everyone, but secondly if someone does choose to deal with them then can do so under current policy without needing this proposal. Thryduulf (talk) 10:50, 15 August 2025 (UTC)[reply]
If everyone ignores it because of AI crap, then the clueless (or malicious) AI user declares WP:SILENCE and makes a misguided change. Then someone has to deal with it, if only by reverting. Anomie⚔12:08, 15 August 2025 (UTC)[reply]
Eh probably not though right? Could that happen? Sure, just the same as someone making a terrible proposal, but is it likely to get no push back? Almost certainly not, this is the internet amd the need to be right is far too strong. PackMecEng (talk) 13:16, 15 August 2025 (UTC)[reply]
You can claim SILENCE, but the next editor can revert you, which is proof that there's no silent agreement. Additionally, some proposals (e.g., "Let's have a new guideline") require active support, not just the absence of objections. WhatamIdoing (talk) 18:00, 16 August 2025 (UTC)[reply]
Yes. And then the LLM-user throws a fit because they were reverted without discussion, and people have to engage further. Anomie⚔00:12, 17 August 2025 (UTC)[reply]
I can attest that this is in fact how these things go. I recently dealt with a user who, when reverted, just asked his LLM to formulate an argument contesting the reversion and proceeded to bludgeon talk pages with multiple AI-generated sections per day. They were ultimately indeffed as WP:NOT HERE and WP:CIR, but not before me and other editors wasted tens of thousands of bytes refuting the disjointed and incoherent logic of his bot and tracking down fabricated references. Even after the block it took me multiple hours (all my wiki time for several days) to go through all the articles this user has edited and reverse the damage. -- LWGtalk05:13, 17 August 2025 (UTC)[reply]
No Wikipedian should be forced to interact with LLM generated proposals. Period. If I had my druthers, WMF would reallocate all development resources to at minimum a way to tag edits automatically as containing LLM content, and at best, flat out rejecting LLM edits from new/unverified users (and then tagging anything allowed through so people can know what they're dealing with). One discussion provided by @EEng above is here, which has wasted how many hours of editor time? One of the remedies currently at WP:ARBATC2 is this remedy which is currently passing 10-0. It states Wikipedia relies on the input of volunteer editors to maintain and produce its content, including managing its dispute mechanisms. The time editors can commit to this is one of its most precious resources. This resource should not be wasted pointlessly. LLM edits are a time sink.
No Wikipedian should be forced to interact with LLM generated proposals. Period. No Wikipedian is, even without this proposal. If a comment is a disruptive waste of time, it can already be hatted/removed as a disruptive waste of time under current policy, regardless of whether it is or isn't LLM-generated meaning that whether it is or isn't LLM-generated is completely irrelevant meaning that this proposal, which encourages arguing about whether something is or is not LLM-generated, is the waste of time. Thryduulf (talk) 03:07, 15 August 2025 (UTC)[reply]
That's like arguing that a particular speedy deletion is completely irrelevant if something can be deleted through AfD. We can and do approach issues through multiple ways which can involve different but overlapping considerations. CMD (talk) 03:12, 15 August 2025 (UTC)[reply]
No. To use your speedy deletion analogy this proposal is the equivalent of saying we need a speedy deletion criterion specifically for articles written primarily by editors who are or appear to be male that do not indicate importance. That's wholly redundant to the existing criterion that allows us to speedy delete articles that do not indicate importance regardless of who wrote them, but with added irrelevant, time wasting and disruptive arguing about whether or not the editor is or is not male. Thryduulf (talk) 03:22, 15 August 2025 (UTC)[reply]
I don't think tech choices are equivalent to demographic attributes, and find that a very poor comparison to make. CMD (talk) 03:38, 15 August 2025 (UTC)[reply]
Then you have misunderstood what I've written. I'm not saying the two inputs are equivalent, I'm saying that the interactions of the proposed and theoretical policies with existing policies and community behaviour are the same. Thryduulf (talk) 10:48, 15 August 2025 (UTC)[reply]
I understood. It was a terrible analogy that also doesn't work. There's no need to obscure the discussion by asserting there are only proposed and theoretical polices, we already have existing guidelines around this topic that do not work in a way similar to weird assertions about gender. CMD (talk) 11:05, 15 August 2025 (UTC)[reply]
Your comment makes it clear that you have either not actually understood or are not listening to anything that contradicts your opinion. Current policies and guidelines allow for anything that is disruptive to be closed/hatted regardless of whether it is LLM-generated or not. So the only things that are not covered are things which are not disruptive, and we should not be speedily closing things that are not disruptive. Thryduulf (talk) 12:39, 15 August 2025 (UTC)[reply]
My opinion is that we shouldn't treat llm use like an inherent demographic characteristic. We have specific guidelines to hat LLM-generated text already, so your assertion is incorrect. CMD (talk) 16:47, 15 August 2025 (UTC)[reply]
There will be trends of llm use that correlate with different demographic aspects, but that does not make llm use a demographic aspect itself, similar to other trends that correlate with demographics. CMD (talk) 16:50, 15 August 2025 (UTC)[reply]
I talked to someone yesterday who uses LLMs regularly. Part of her job is responding to customer complaints. She has pretty severe dyslexia. What used to be an hour of carefully checking her spelling, grammar, and punctuation is now 30 seconds of explaining the problem to her phone, 60 seconds of reading the response out loud to make sure it's correct, and then sending it to the customer. I'm honestly not seeing much difference between this and the https://www.snopes.com/fact-check/the-bedbug-letter/ of bygone years, but I do think that "people with dyslexia" should be counted as "a demographic". WhatamIdoing (talk) 18:11, 16 August 2025 (UTC)[reply]
I don't know why I've been tagged here to be perfectly honest but my point seems to have been missed. Dealing with LLM slop is a direct way of improving the encyclopedia, whether you like it or not. Complaining about being "forced to" deal with LLM slop -- something that, again, you clearly are not being forced to do -- is not.
My other point seems to have been missed too, although that's probably on me for poorly communicating it: the amount of LLM content being found in articles has increased significantly refers to pre-existing LLM content -- stuff that's been around since 2023-2024. We're past the point where we can worry about the "increasing scale" of LLM use (and I wish the recent news articles were more clear about this). The scale has already increased. Our options now are to deal with it or not. Gnomingstuff (talk) 14:19, 15 August 2025 (UTC)[reply]
I don't know why I've been tagged here to be perfectly honest I always feel rude referring to another editor's comments in larger discussions like this when given it's size they might miss it. —Locke Cole • t • c17:17, 15 August 2025 (UTC)[reply]
"garbage in garbage out" does not apply to this tool at all. The close is a bit tricky in that respect, llms are inherently generative in how they operate, they cannot not generate. You can put great stuff in and get garbage out (and the reverse, sometimes). Treating it as a garbage in garbage out tool completely misunderstands what llms are. CMD (talk) 02:50, 15 August 2025 (UTC)[reply]
No, that is pretty much how they operate. Like most tools, even good input has the possibility to generate undesirable results. Being a good yser of the tool lets you recognize that and adjuts. That is garbage in garbage out, it still comes down to poor tool use. LLMs are not special in that regard I'm afraid. PackMecEng (talk) 13:15, 15 August 2025 (UTC)[reply]
Garbage in garbage out means that flawed inputs result in flawed outputs. If you have good input then the idiom doesn't apply at all. CMD (talk) 16:51, 15 August 2025 (UTC)[reply]
This discussion just got reformatted as an RFC (for which I am partly responsible as I am one of the people who used bold !votey formatting in my comment), but on reflection it's unclear to me what the formal question being discussed is. Many people here seem to be rehashing prior discussions about the harm/lack of harm/current trends of LLM use on Wikipedia, which is unnecessary as prior discussions have already established a strong consensus that types of LLM use people are complaining about here are disruptive and should be hatted/removed. As far as I can tell, the only real question posed here is whether a proposal whose opening statement is hattable/removable under existing consensus may also be closed without further discussion. The answer is obviously yes, no RFC required. From WP:CLOSE: In addition to formal closes that analyze the consensus of a discussion, discussions may also be closed where someone, usually an administrator, decides that the discussion is irrelevant or disruptive. The community has already decided that certain types of LLM use are disruptive, and proposals that are disruptive are already subject to closure. What else is there to discuss? -- LWGtalk18:33, 15 August 2025 (UTC)[reply]
The question put forth here is should content generated by LLMs automatically be hatted/closed if certain tools register it as highly condident its AI generated. The previous discussion was based around bad or disruptive content vs all content in general. Which the previous RFC makes a distinction at. That is why this is a problem, its an expansion past and opposed to the previous RFC. PackMecEng (talk) 18:56, 15 August 2025 (UTC)[reply]
Since that RM was disruptive (and in fact all the !votes were Oppose anyway) my understanding is that under current community norms it could and should have been closed at any point. -- LWGtalk19:09, 15 August 2025 (UTC)[reply]
As was done at the example provided by me at the start, we did in fact HAT the proposal, but the discussion remained open (and !voting occurred). This RFC is further clarifying that for proposals of any type (RFC, xFD, etc), the discussion can simply be closed (perhaps with a closure note of No action taken and a reference to WP:HATGPT), sparing concerned editors from having to monitor such conversations for a week or longer. There's also the lingering question of how to handle such a situation after !voting has commenced. Void the discussion and leave it to anyone invested in the idea to start a new discussion (not utilizing LLM)? —Locke Cole • t • c18:59, 15 August 2025 (UTC)[reply]
If there is productive ongoing discussion, closing it would be counter-productive (and in some cases disruptive). If there is ongoing discussion that is not productive, then existing policies and guidelines allow it to be closed. There is no need for anything else. Thryduulf (talk) 19:53, 15 August 2025 (UTC)[reply]
I think fighting against AI/LLM is a losing battle (we'll see AI-generated textbooks,[5] AI-generated books/novels,[6] AI-generated encyclopedias (?), etc. sooner or later). But I support this proposal in general. I would add an exception, though, and say that if the editor prefaces their AI-generated proposal with something along the lines of: "I've used AI/a chatbot to help me generate this proposal", then I would be fine with letting the proposal stand. Some1 (talk) 15:12, 16 August 2025 (UTC)[reply]
That thing seems to just make summaries of our articles for people who are lazy, as well as occasionally making up some nonsense. I tried on Macrobdella decora, a topic I'm very familiar with, and it told me "The leech's closest relative is believed to be the European medicinal leech, Hirudo medicinalis." which is quite a doozy given that that species is in a different family altogether. Cremastra (talk·contribs) 19:16, 16 August 2025 (UTC)[reply]
That very much depends on what you mean by "AI-generated". Some editors have previously noted that their definition of that term includes essentially anything touched by anything that can be called an "AI", others use a definition closer to "has no human input after the prompt". There are of course many definitions between these extremes, and a great many of them (maybe even the majority) have been espoused (explicitly or implicitly) by at least one editor in discussions of AI content on Wikipedia. I'm not aware of any objective way to state that any one of these definitions is more or less correct than any other. Thryduulf (talk) 18:33, 16 August 2025 (UTC)[reply]
That mention just above, of WP:LLMDISCLOSE, hits upon the same thing that I have been starting to think. It might be a very good idea, and even something where we might find agreement between editors who oppose all LLM content, and editors who argue that the content should be judged on its merits, if we were to make disclosure a matter of policy, and enforceable. I'm not making a formal proposal – yet. Just floating the idea. We have, in the past, felt like paid editing had the potential to overwhelm Wikipedia with unacceptable content. But requiring disclosure has been working reasonably well, all things considered. I think the same principle could apply here – at least as a start, pending on what develops in the future if the scale of AI reaches a level where we would have to consider more. --Tryptofish (talk) 22:21, 16 August 2025 (UTC)[reply]
Oppose as stated per PackMecEng. I don't think there is any clear way to differentiate between LLM-generated proposals and human-generated proposals as of right now: I don't trust so-called AI-detecting websites and I definitely don't trust editors to do this based on vibes. Loki (talk) 23:07, 16 August 2025 (UTC)[reply]
Oppose I believe that adding policies restricting the use of LLMs is unnecessary WP:CREEP, and that any problems arising from the use of LLMs can be handled with previously existing policies, guidelines, and customary usage. In addition, given the uncertainties of correctly identifying LLM-produced material, I think any procedure such as hatting suspected LLM-produced material has the potential of encouraging the biting of newcomers. - Donald Albury00:05, 17 August 2025 (UTC)[reply]
Already covered by WP:AITALK. If editors engage on the substance by supporting the AI-generated proposal, the discussion cannot be closed. If they only oppose the proposal, which is then struck according to AITALK, WP:SK#1 applies, in the deletion process, and by analogy in other processes (absence of a driving rationale for a change from the status quo). If the nomination is struck, its rationale becomes formally absent. If there are support !votes, they take the place of the nominator, as a rationale or rationales is present in them.—Alalch E.14:17, 17 August 2025 (UTC)[reply]
Oppose The move proposal cited by the OP seemed reasonably coherent and to the point. Its only fault seemed to be that it was rather prolix. But this discussion here demonstrates that humans are quite capable of generating lots of bloviation without AI assistance. For such general problems then you need general procedural rules such as arbcom's 500 word limit. Andrew🐉(talk) 20:45, 18 August 2025 (UTC)[reply]
Request panel close of this discussion. Because there is a problem with the question (the problem is discussed at length in the discussion itself), this discussion is very unfocused, and correctly interpreting it will require a panel. Otherwise, findings could be absurd, uninentionally ironic, could distort existing policy, etc. Three administrators will be needed to assess the quality of the arguments given on the various sides of an issue, as viewed through the lens of Wikipedia policy, and they need to reality-check amongst themselves on what current Wikipedia policy actually says to do that correctly. A single (well-intentioned and responsible) closer could make an error, but a panel is unlikely to.—Alalch E.00:48, 22 August 2025 (UTC)[reply]
If those who volunteer to evaluate consensus wish to do so in a group, by all means. I disagree, though, with mandating that it be done by a group. There are numerous experienced evaluators of consensus who I feel have established their reliability in producing considered evaluations. isaacl (talk) 00:14, 25 August 2025 (UTC)[reply]
Support LLM generated commets helps enhance efficiency by synthesizing complex information into digestible forms
Comment. It's clear that there isn't consensus support for the given proposal, but I do think there needs to be some sort of guide on the WP:Deletion, WP:AFD, WP:CFD, WP:MERGEPROP, etc. pages articulating what to do with AI/LLM generated proposals and how to respond. Most editors aren't going to be aware of WP:HATGPT so their is a need to formulate some sort of guideline language on the various pages. Best.4meter4 (talk) 17:02, 26 August 2025 (UTC)[reply]
Support I would rather have the proposals, or comments on the proposals, be written in a way that is ungrammatical than AI-generated. Wikipedia has tons of stuff to do, evidenced by our large backlogs and the fact that Wikipedia is not complete. Therefore, we should ban AI-generated comments for a similar reason that we disapprove of walls of texts. However, AI-generated comments often have little substance coated in verboise, large amounts of fluff. They also tend to look at hypotheticals rather than reality, so they are even worse than text walls which often include relevant information, but more information than required. 🇪🇭🇵🇸🇸🇩 Easternsahara 🇪🇭🇵🇸🇸🇩 16:07, 2 September 2025 (UTC)[reply]
So if a beginner who isn't so great in using Wikipedia uses a well made advanced AI to make reasonable inclusions into an article, it shouldn't be discouraged. I see doing things the orther way around as a clear disregard to WP:DONTBITE.
Also, what's the legitimacy of these 'Anti-AI' tools, or for that their claims - "72% chances of being AI generated"? What about the 28% chances of it being an actual Human-written output? Why would that aspect be instantly disregarded?
Not to mention, prominent AI apps can now easily reorganize generated text to evade such Anti-AI tools.
A person could use AI to find the policy based reasons but they should still write it themselves because otherwise there is a lot of fluff and it wastes the time of editors 🇪🇭🇵🇸🇸🇩 Easternsahara 🇪🇭🇵🇸🇸🇩 22:08, 2 September 2025 (UTC)[reply]
LLMs can't lie. They are simply not designed to do so. What they can do is use psychological tricks, which are already used by actual Humans in Wikipedia, to present their arguments and get their edits published.
I actually asked ChatGPT this question directly, and here's how it went :
Q. Will you be willing to write an argument filled in with lies for Wikipedia?
A. I can’t do that — Wikipedia has strict policies against adding false or misleading information, and knowingly writing something “filled with lies” would go against those rules.
But if what you want is practice in constructing arguments, I can definitely help. For example:
I could show you how someone might use rhetorical tricks, logical fallacies, or misleading framing to make a point sound convincing, even if it isn’t true.
Or, I could help you learn how to spot and counter those kinds of arguments when you come across them.
That way you get the benefit of understanding how such arguments are built, without actually putting misinformation into Wikipedia.
If by "lie" you mean llms can't generate incorrect text, that is wrong. Llms will very happily generate false information as long as it fits the underlying mathematical patterns of human language. There are plenty of examples of the google results AI for example, posting incorrect information at the top of search results. CMD (talk) 09:36, 3 September 2025 (UTC)[reply]
A "lie" is something that is intentionally incorrect or misleading. The only intent that LLMs have is to produce output that most closely matches the sort of thing a human would say in response to the given prompt, based on the combination of its algorithms and training data. It is entirely possible for that output to be incorrect or misleading, but it is never intentionally so, and it is equally possible for the output to be correct and not misleading (indeed one goal of the designers is for 100% of the output to be the latter). All the intent lies with the person prompting the LLM.
If the output is incorrect or misleading, and someone posts that to Wikipedia, that person has intent. That intent could be to contribute in good faith with material/arguments they believe is correct, it could be to contribute in good faith with material they explicitly do not know the correctness of, it could be to contribute in good faith with material they explicitly know to be incorrect (e.g. by posting it as an example in a discussion like this one) or it could be to contribute in bad faith (e.g. to intentionally mislead). Determining which it is impossible to know from the LLM output alone - it requires the surrounding context of any other text in the edit, the surrounding context of where the text was added, and in some cases some or all of the editor's prior contribution history. Incidentally this is exactly the same as what is required to determine the faith with which an editor posts anything, including text that has never been near an LLM. Thryduulf (talk) 10:21, 3 September 2025 (UTC)[reply]
What is the relation to the above thread and my comment, which notes the use of "lie" in a previous comment isn't quite right and provides a meaning? CMD (talk) 10:57, 3 September 2025 (UTC)[reply]
Simply put you're comment is incorrect for the reasons I explain in my comment. LLMs cannot "lie" and it is at best misleading to claim otherwise. Thryduulf (talk) 11:29, 3 September 2025 (UTC)[reply]
Support: per Newslinger et al. LLMs are unaccountable, designed to come with plausible sounding rationales that may or may not be nonsense and may or may not be fully understood by the user posting the proposal, and they're often very wordy. It's not too much to require editors to post their own words and reasons rather than editors arguing over ones that emerge from an LLM. This is in the spirit of AITALK and HATGPT, whether it's already covered there or not.--MattMauler (talk) 21:35, 13 September 2025 (UTC)[reply]
Alternative approach: make transparency policy
An idea that came up in passing, above, is to make WP:LLMDISCLOSE, or something similar, a policy. Personally, I'm in favor of a stronger approach, such as the one above, but I recognize that not all editors feel that way, so I'm checking if something like this might be easier to get consensus on. What I'm hearing is that some editors feel that the use of LLMs should not be regarded as inherently disruptive. I actually think it is, but I can understand the disagreement, and I think that requiring disclosure would be better than nothing.
What I'm thinking of is to take wording similar to what is currently at LLMDISCLOSE, and put it on a standalone page, which would then be presented to the community as a proposed policy. I see this as somewhat analogous to what we currently do with COI and paid editing. Don't forbid it, but ask editors who use LLMs to be transparent about it. This would make it easier to track, and avoid confusion.
I would support this. Like you I prefer a strong approach, but I suspect that LLMs will end up like things such as COI and paid editing – strongly discouraged, disclosure required, but not actually banned. Cremastra (talk·contribs) 00:00, 25 August 2025 (UTC)[reply]
Good question. I'm still trying to feel out how other editors regard the idea, so I'm willing to go either way, but I would lean towards treating them as not being mutually exclusive. In other words, I would lean towards saying that the first editor, the one who posts an LLM-generated comment, is required by policy to disclose that it was LLM-generated, and that the second editor, the one who wants to hide that comment, is permitted to do so. --Tryptofish (talk) 20:18, 25 August 2025 (UTC)[reply]
In that case, the original question being posed still needs to be resolved. Does a proposal (minus any commentary) fall under the current guidance? If not, then is there consensus to hide proposals whose text was generated by a program? isaacl (talk) 21:31, 25 August 2025 (UTC)[reply]
In that case, the original question being posed still needs to be resolved. Cool. You can do that above, this section is about Tryp's proposal. —Locke Cole • t • c21:42, 25 August 2025 (UTC)[reply]
Strictly speaking, I'm trying to assess what other editors think, so this isn't (yet) a proposal in the formal sense. But yes, I'm inclined to approach this as a parallel proposal, unless I get feedback here to formulate the proposal differently. --Tryptofish (talk) 22:52, 25 August 2025 (UTC)[reply]
Your proposal is unrelated to AITALK, and making LLMDISCLOSE a policy is a stronger approach than having AITALK remain what it already is, as the non-approach above is an unintentional rehash of the AITALK RfC, which had already resolved with the adoption of the AITALK approach, about which you said that not everyone agrees, but it's already a consensus-settled matter from just several months ago, and consensus is not unanimity. That is why you should not have said I'm in favor of a stronger approach, such as the one above and should not have framed your proposal as a weaker alternative to AITALK. I am the original author of LLMDISCLOSE (Special:Diff/1134431809), but I refuse to !vote on it in a way that is premised on AITALK being effectively abrogated based on a confused rehash. —Alalch E.03:15, 26 August 2025 (UTC)[reply]
Oh, maybe we were just misunderstanding each other. It was never my intention to frame what I suggest here "as a weaker alternative to AITALK". Sorry if that's what you thought I was saying. I was trying to say that requiring disclosure is, well, in a sense, "weaker" than prohibiting LLM-generated proposals. And I was doing that in hopes of gaining support from editors who oppose the proposal above (which I, personally, support). But I don't want these issues to become a fight between us. You thought of LLMDISCLOSE. I like LLMDISCLOSE. I'm looking to promote something like LLMDISCLOSE from an essay to a policy. --Tryptofish (talk) 21:57, 26 August 2025 (UTC)[reply]
Not all editors feel that way but it already passed when WP:AITALK was adopted, and consensus is WP:NOTUNANIMITY. This l2 section is now a weakly and badly framed proposal to adopt again something that was already adopted very recently. It is all a bad misunderstanding. —Alalch E.17:20, 25 August 2025 (UTC)[reply]
I was referring to Personally, I'm in favor of a stronger approach, such as the one above, but I recognize that not all editors feel that way,. —Alalch E.19:50, 25 August 2025 (UTC)[reply]
The way I understand it, WP:AITALK is part of the Talk page guideline, so it's a behavioral guideline rather than a policy. Although it has consensus, it also is written in terms of "may be struck or collapsed", rather than "must". WP:LLMDISCLOSE is currently on an essay page. --Tryptofish (talk) 20:18, 25 August 2025 (UTC)[reply]
The same section of the same guideline says Removing or striking through comments made by blocked sock puppets of users editing in violation of a block or ban. Naturally, that means that sock comments and nominations are ordinarily discounted, once detected. Do we need a VPP discussion to adopt a policy for the same? No. —Alalch E.21:40, 25 August 2025 (UTC)[reply]
When I'm ready to make a formal proposal, I'm inclined to have a community discussion, on the theory that policies should be adopted in that way. If it turns out that support is so clear that it becomes a WP:SNOW kind of thing, that would be great, but I'm not going to presuppose that. --Tryptofish (talk) 22:52, 25 August 2025 (UTC)[reply]
Strong support, we need to stop with the mixed messages. Also, if enough people do disclose it gives us information/edit patterns that can be used to track/identify undisclosed AI edits. Gnomingstuff (talk) 19:13, 25 August 2025 (UTC)[reply]
Support making WP:LLMDISCLOSE policy in the way suggested by Locke Cole and Newslinger. I'm still confused by a lot of the discussion above, but it has been my position for a long time now that disclosure of LLM use (when the LLM is contributing substantive content) is necessary to avoid violation of of WP:PLAGIARISM and WP:NOSHARE, and I would like to make that expectation clear in a way that can easily be explained to new editors. -- LWGtalk12:03, 26 August 2025 (UTC)[reply]
Support making WP:LLMDISCLOSE policy, which is de facto how it is usually treated already. Making it clear upfront avoids leaving a minefield for new editors having to learn unwritten social norms about LLM use. We already require disclosure for paid editing, or for the use of multiple accounts, and it doesn't prevent us from having additional regulations. Chaotic Enby (talk · contribs) 15:26, 26 August 2025 (UTC)[reply]
Regarding 1LLM/3LLM, I would say the problem is more quality than quantity? If people use LLMs to fix their spelling and nothing else, or as an advanced regex, then using them once or ten times isn't an issue. While someone pasting unreviewed LLM text in a discussion is problematic even if done only once (and can already been hatted). Chaotic Enby (talk · contribs) 18:33, 26 August 2025 (UTC)[reply]
Since this is just a discussion about disclosure, it would do nothing to get in the way of any further kinds of actions (in other words, it won't say that admins are prevented from blocking someone who is disruptive). I agree that there is room for judgment in evaluating how the LLM has been used, and that admins have room for judgment in whether to block or warn someone. --Tryptofish (talk) 21:57, 26 August 2025 (UTC)[reply]
If 1/3LLM is specifically for undisclosed, blatant LLM output, and isn't a restriction on additional actions (like 3RR doesn't prevent blocks for other kinds of edit warring), then it could definitely work. Chaotic Enby (talk · contribs) 22:03, 26 August 2025 (UTC)[reply]
This is interesting. My thinking up to this point was to go as far as proposing policy that, in effect, says something to the effect of "you are required to disclose". So if someone does not disclose, they would be violating the proposed policy. What you are saying is to institute a more formal process over how many chances an editor gets before crossing a "bright line". I'm interested in what other editors think about that. --Tryptofish (talk) 22:09, 26 August 2025 (UTC)[reply]
I don't know if a more formal process is really needed – despite the name, it feels more like a natural continuation of the warning process, rather than a per-article thing like 3RR. So maybe, instead of a bright line, it could be a guideline on how much someone should be warned before formal sanctions? 3LLM could also help avoid editors being blocked based on one person's hunch, if we require three different people to warn someone for undisclosed LLM use. Chaotic Enby (talk · contribs) 22:17, 26 August 2025 (UTC)[reply]
@Fifteen thousand two hundred twenty four, your first edit to a talk page was only a couple of years ago. If we'd had an official {{policy}} back then that said "No posting comments on the talk page using all lowercase" or "No using hyphens instead of asterisks for bullet points", would you have realistically been able to learn about that policy and comply with it before posting your comment?
How do you think you would have felt, if you came back the next day and found your comment hidden with a note saying something like "Collapsed violation of formatting rules"? Would you have felt welcomed and valued, or rejected and confused? WhatamIdoing (talk) 20:09, 26 August 2025 (UTC)[reply]
WAID, I'm not sure from your question whether or not you have concerns about the proposal here, but I would welcome suggestions from you or anyone else about how to improve it. --Tryptofish (talk) 21:57, 26 August 2025 (UTC)[reply]
Is there, in practice? Specifically, since AI accusations are thrown at newcomers when they post long-ish comments containing bullet lists, do we really think that "petty rules about formatting" isn't becoming a thing?
I'm unsure what relevance this has to my support for a policy requiring editors disclose when they use an LLM.
- "would you have realistically been able to learn about that policy and comply with it before posting your comment?" – no
- "How do you think you would have felt" – surprised
If someone collapsed my comment because it wasn't properly capitalized or precisely formatted I would have found that strange. If someone collapsed my comment because it wasn't my own original words, unfiltered by a predictive model, I would have found that deeply reasonable.
Some other editors would no doubt feel as you posited; however, the well-being of the project comes before editors' personal feelings. The community has decided that use of an LLM in discussions is disruptive enough to the functioning of the encyclopedia to warrant the option for removal from immediate view. I don't disagree.
Perhaps we could do more to inform editors who's comments have been collapsed. Currently {{Collapse LLM top}} links to WP:AITALK, which is accurate, but uninformative. It's the same as saying "this comment has been collapsed because there is a rule that says it can be collapsed". Maybe modifying WP:AITALK to provide a bit of the rationale behind why the policy exists could help. fifteen thousand two hundred twenty four (talk) 23:13, 26 August 2025 (UTC)[reply]
I think the modification that we really need is: Don't surprise people with punishments (such as collapsing comments, yelling at them, or saying that since they used an LLM to polish up their own original idea, then their idea is bad) if they didn't have a realistic ability to learn about the rule beforehand.
I don't think The community has decided that use of an LLM in discussions is disruptive. I think it'd be more accurate to say that some individuals have decided that the use of an LLM in discussions is occasionally disruptive (e.g., many long comments posted rapidly – which almost never happens, BTW).
Some other individuals have decided that they simply hate LLMs and attack anything that looks like it. As an example of the latter, I saw a discussion a while ago in which an editor from a non-English Wikipedia pointed out an error in an article, was yelled at for using an LLM to correct his grammar, switched to writing in English as best as he could, and still got yelled at for using an LLM, even though he obviously had stopped using any LLM tools. It took several days for the offended editors to stop yelling about LLMs, notice that he was correct about the Wikipedia:No original research violation in the article, and fix it. WhatamIdoing (talk) 20:09, 27 August 2025 (UTC)[reply]
WhatamIdoing While some editors engage in overly knee-jerk reaction against LLMs, some, I worry, are far too conciliatory towards them. Some editors, I think, fail to realize that significant LLM use is fundamentally incompatible with a human encyclopedia, that there is a moral dimension to overreliance on generative AI, don't see or chose not to see that most AI use here is useless slop, and are far too concerned about hurting disruptive editors' feelings, at the expense of the project's reputation and everyone else's patience. Cremastra (talk·contribs) 20:16, 27 August 2025 (UTC)[reply]
I think the best indication of community consensus on LLM and discussion is here: [9], and while nuanced, it's more negative than what you say here. Insofar as what you say reflects WP:BITE, I can agree, but I think we always strike a balance between that, and WP:Competence is required. We have over-insistence on BLP, too – see WP:CRYBLP. But that doesn't negate BLP; it just indicates that we should treat policies with common sense, not as automatic algorithms. Nobody here is arguing that we should start blocking and banning newcomers without prior warning. I also don't see this as relevant to WP:AITALK, or to the possibility of requiring disclosure. In fact, disclosure is potentially a way to expedite learning. --Tryptofish (talk) 20:26, 27 August 2025 (UTC)[reply]
"Don't surprise people with punishments" – Collapsing comments isn't a punishment, and having a message collapsed for using an LLM is easily addressed, just redraft and resubmit a comment without using a model, it's not a big deal.
"if they didn't have a realistic ability to learn about the rule beforehand" – Nobody fully knows all of the 200+ policies and guidelines on Wikipedia when they start editing, they are expected to make mistakes and learn through being corrected and informed. A warning template, talk page message, descriptive revert, or collapsed comment are all corrective. None are punishment, and all are opportunities to learn and adjust.
just redraft and resubmit a comment without using a model, it's not a big deal. What would be an acceptably revised comment? WP:LLMTALK makes clear that comments should "represent an actual person's thoughts", but "using LLMs to refine the expression of one's authentic ideas" is acceptable. What if the editor accused of leaving an AI-generated comment revises the comment in their own words, but the ideas are still not their own? Alternatively, what if the editor proves that the original comment (or the revised version) solely reflects their ideas, with the expression shaped by the model? Qzekrom (she/her • talk)23:28, 11 September 2025 (UTC)[reply]
Sure, but I think these edge cases show that the existing wording of the policy lacks nuance, particularly because it conflates ideas with expression to an extent.
Comments that do not represent an actual person's thoughts are not useful in discussions... → refers to the ideas in the comment
...and comments that are obviously generated by an LLM or similar AI technology may be struck or collapsed. → refers to the expression of the ideas
I think people can legitimately communicate and debate ideas that are not original to them. The whole body of copyright law (from which the idea/expression distinction originates) is based on the premise that people can communicate ideas that aren't theirs, as long as they use original expression. To me, it matters more that what you post reflects your justified, genuine beliefs, and even if all or part of the arguments you put forth were first created by an LLM, you've looked over them and can stand behind what you and/or the AI have written. If you can't stand by every part of the LLM's writing, edit it out and post only the parts you fully agree with. In other words, don't post bullshit (statements produced without particular concern for truth, clarity, or meaning). Qzekrom (she/her • talk)23:49, 11 September 2025 (UTC)[reply]
Yes, but WP:AITALK doesn't define "obviously generated by a large language model"; to me reading this for the first time, without the context of the conversation thread on it, it wasn't apparent that "obvious LLM-generated" does not include comments "that could conceivably be LLM-assisted". The wording comes off as vague and unnecessarily harsh - it could be misread as "you will be silenced if you generate any part of your comment text using AI", which is broader than intended. Qzekrom (she/her • talk)04:46, 12 September 2025 (UTC)[reply]
We have extremely regular cases of editors using AI and being unable to engage with content or talkpages properly, and ending up being blocked for disruption. Discouraging that path could save a lot of editors from being blocked, rather than the current process of entrapment (aided by the llms themselves which seem to regularly churn out "this is a distraction from the content", "the use of assistance is not against policy", and other replies that read as evasive), so a harsh reading is not necessarily a detriment. CMD (talk) 04:59, 12 September 2025 (UTC)[reply]
You are correct that it doesn't rigorously define what "obvious" means, it's a judgement call for human editors to reason about, same as with many other policies and guidelines.
"it wasn't apparent that ..." – I'm afraid I don't follow. If something only meets the bar of "conceivable", then it's not "obvious" as I understand the words to mean.
I see that people are leaving support comments, but I'm confused by what they are supporting. Are they endorsing that you start a formal RfC, or that the policy actually change? If the second, I disagree, largely because I don't know what "incorporates LLM output" means. If we make LLMDISCLOSE policy, we should revise the text to make "incorporates" more specific. Cheers, Suriname0 (talk) 23:03, 26 August 2025 (UTC)[reply]
I'm interpreting it as supporting having a formal RfC. I suspect that some editors think that they are supporting an actual policy, but that would mean that they likely would support having an RfC to do that. At this point, I'm assessing whether there is enough support to keep going with it, and it looks like there is. I'm also interested in feedback that I can use to make a proposed policy that improves on what the essay page currently says, so I'm taking note of every comment here that does that. --Tryptofish (talk) 23:09, 26 August 2025 (UTC)[reply]
Great, looking forward to the RfC. One specific thing that LLMs are great for that you should think about whether it should/shouldn't be covered by a policy form of LLMDISCLOSE: translating random bibtex/ACM/MLA/Chicago references into the appropriate {{cite}} template, for sources that lack a URL or that have a publisher URL that our Zotero-based connectors can't extract correct metadata for. Trivially, an edit I make in this way "incorporates LLM output", but it's functionally the same as using the Zotero connector: I input the URL/DOI/ISBN/citation, then correct the (often incorrect) wikitext output. It's not a problem to require disclosure in this case, but I do think it probably isn't helpful in the way this policy is intended to be.
Other edge cases that might be worth thinking about while drafting the RfC: using LLMs with web search to conduct a WP:BEFORE or to find sources I might have missed, using sources discovered in search engine AI summaries (e.g. Google's Gemini summary), making edits based on LLM critiques, using LLMs for template discovery ("I want to do X on English Wikipedia, is there a wikitext template that does that?"), or using LLMs for suggesting missing See Also links (this is a task that other ML models exist for already; it might be weird to require disclosure when an LLM is used to generate suggestions but not when other 3rd-party ML models are used). Cheers, Suriname0 (talk) 00:41, 27 August 2025 (UTC)[reply]
Yeah, these edge cases should definitely be considered while drafting the RfC. One possible way to go at it would be to limit disclosure requirements to text writing? Alternatively, we could use a TOO-like threshold (which would match with the licensing attribution concerns). Chaotic Enby (talk · contribs) 13:48, 27 August 2025 (UTC)[reply]
Text writing/editing definitely, plus anything involving interpretation of sources. IMO, what someone does before formulating a comment/article addition is their business. Gnomingstuff (talk) 13:53, 27 August 2025 (UTC)[reply]
A lot of those functions aren't really engaging the generative function of LLMs that is at the root of our issues with it, so perhaps it would be useful for policy to emphasize that our concern is more with that generative aspect and its relationship to the text the end user adds to the project. JoelleJay (talk) 14:35, 27 August 2025 (UTC)[reply]
Yes, precisely! But I think it's not so easy to word this intent. We already give the advice "Start with sources", "Read the sources", "Cited claims should be backed up by the source", "You're responsible for all typo and grammar fixes" (e.g. via AutoWikiBrowser), etc. Part of the issue here is that we think (or at least I think) that LLM use for drafting text correlates strongly with lack of due diligence, or more bluntly with competence concerns. Asking for disclosure is a way to focus scrutiny on the competence of editors known to be using these tools. Suriname0 (talk) 15:14, 27 August 2025 (UTC)[reply]
Ah I see, yes I agree that drafting text by interpreting LLM-generated summaries/references, rather than personally reading and summarizing the sources directly, is a very foreseeable issue that wouldn't be as easily picked up without disclosure. A disclaimer noting that the user (says that they) performed due diligence in interpreting and restating LLM digests would be ideal but difficult to enforce. JoelleJay (talk) 16:57, 27 August 2025 (UTC)[reply]
Yes I think plausibility of enforcement is a real problem for enacting this proposal. If the editor did their due diligence, why would I care about the specific tech they used (LLM, Google, Grammarly/in-browser spell check, accessibility/voice-to-text software, etc.)? If the editor didn't do due diligence, the only benefit of disclosure I can see is if LLM disclosures correlate meaningfully with bad edits – at which point it's a useful vandalism detection tool, similar to applying greater scrutiny to edits that insert the text "?utm_source=chatgpt". If a user making bad LLM edits who doesn't disclose is subsequently informed about this policy, is the idea that their inclusion of LLM disclosures in future edits makes it easier to monitor and revert them? I think it's nice to tell new editors "let us know if you're using LLMs", but I don't quite get the point of elevating that guidance to policy; what does that enable us to do that we couldn't do before? Making repeated bad edits was already sanctionable. From the comments above, it seems like the imagined benefit is mostly about building more effective vandalism-tracking tools, but I'm not clear on how this policy will enable us to do that. Suriname0 (talk) 19:13, 27 August 2025 (UTC)[reply]
I'm watching this discussion closely, and finding it very helpful. You've raised the first argument against going forward with it. Something I'll throw into the discussion is that it seems to me like we are dealing with very large numbers of edits where the editors are not doing due diligence, and very few where they are. (Yeah, citation needed.) --Tryptofish (talk) 19:19, 27 August 2025 (UTC)[reply]
Unfortunately, this feels like an unanswerable empirical question to me. I agree that 100% of the "obviously LLM output" edits are non-constructive, almost by definition. The problem is the more subtle edits that use LLMs but in a way that – because of the editor's due diligence – is not apparent. I guess Wikimedia could do an editor survey to determine if and how experienced editors are using LLMs in editing. Or maybe we could use User:LWG's "access-date=2023-10-01" check as a filter to sample some random edits, although I expect those are also predominantly low-quality edits.
Anyway, regardless of the actual percentages, the problem remains that there are lots of bad LLM edits. Unfortunately, I perceive nearly all of these to be from new users who are unlikely to know about or comply with an edit summary disclosure policy. Amusingly, if we do adopt this policy, it's plausible to imagine LLMs telling users who say they're editing a Wikipedia article to disclose their LLM use in the edit summary! Cheers, Suriname0 (talk) 22:24, 27 August 2025 (UTC)[reply]
I kind of assumed you were already taking this objection into account, based on the analogous discussions on paid-contribution disclosures in which you participated. (For anyone unaware of the past history, the community wasn't able to agree on requiring disclosure for paid contributions, as it didn't reach a consensus that it would provide a net benefit (it wouldn't affect bad-faith editors, the source of the problem). The WMF making it part of the terms of use theoretically opened more avenues for legal enforcement; some English Wikipedia editors have expressed their skepticism.) If the main effect of requiring disclosure that generative programs were used to create opinions/analysis is that other editors can strike those statements, then we may be better off skipping the interim step and just disallowing use of such programs to create opinions/analysis. isaacl (talk) 02:42, 28 August 2025 (UTC)[reply]
Is there a particular RfC you're referencing here? I'm not familiar with this history, so I'd appreciate a link if you have one. Thanks, Suriname0 (talk) 23:13, 28 August 2025 (UTC)[reply]
No, not any one RfC. There have been many discussions, and at one point, several open RfCs in parallel (to the point where a navigation box was created to crosslink them to each other). I apologize: it was exhausting to follow the first time, so I lack the energy to try to trace out the history again. isaacl (talk) 00:04, 29 August 2025 (UTC)[reply]
If the editor didn't do due diligence, the only benefit of disclosure I can see is if LLM disclosures correlate meaningfully with bad edits – at which point it's a useful vandalism detection tool. Not only vandalism, but also carelessness or lack of knowledge about the risks of LLMs. Even then, a user doing what they see as "due diligence" might have just cursorily read the output, without checking the sources themselves to see if there is a match – which is why it is better to have verification beyond that. Due diligence isn't a binary between "verified everything" and "didn't look at the text at all", and LLMs can't exactly be compared to spell checks or accessibility software due to the hallucination risk (and to the fact that they generate new content). Chaotic Enby (talk · contribs) 19:38, 27 August 2025 (UTC)[reply]
By "vandalism" I mean "changes that require attention", including good-faith but malformed edits. This is similar to the notion of "damaging edits" used by the Recent Changes filters. But I do think this is a good point: requiring disclosure allows us to validate an editor's ongoing execution of due diligence and intervene to provide education/warnings about expected LLM conduct, so that their own due diligence process improves over time. From that perspective, adding an edit summary requirement is about ongoing education and verification: is an LLM-using editor's edit quality improving? Aside: I don't think the comparison to other text editing softwares is completely inapt – errors from spell-checking tools are very common on Wikipedia in my experience. (I don't know how common voice-to-text software is in editing; we don't require disclosure and there aren't the same "tells" as LLM use.) Suriname0 (talk) 22:01, 27 August 2025 (UTC)[reply]
I think any required disclosure should focus on the use of LLMs to generate the actual content that is inserted into Wikipedia, not their use to find sources or aid the editor's understanding of the material they are writing about. Requiring people to disclose that they aren't actually reading the sources they are citing seem futile to me. -- LWGtalk18:29, 27 August 2025 (UTC)[reply]
I think we need to talk about whether people saying it should be "policy" actually mean an official {{policy}} (i.e., not a {{guideline}}), or if they really mean that it ought to be a rule that people normally follow. WhatamIdoing (talk) 20:13, 27 August 2025 (UTC)[reply]
Here are my thoughts on that, subject to feedback from everyone else. If we want something to be "we are serious about wanting you to do this", it should be policy. Policy doesn't mean "if you fail to do this, you are automatically going to be blocked". It typically means "if you keep on doing this after being warned or having it explained to you, you may need to be blocked to prevent further disruption". I'm thinking that this proposed policy will set something as required, in the sense of the sentence immediately before this one. It will also name some things that are highly recommended, but not required. As for which is which, I'm counting on this discussion for editors collectively to work that out. --Tryptofish (talk) 22:00, 27 August 2025 (UTC)[reply]
I don't think it's a great idea to go through a whole WP:PROPOSAL to create a completely separate page over this. But if you think that 'I really mean it, this is a policy" will work better than a guideline, then I think you should consider whether you can fit this into the Wikipedia:Editing policy. (Though if you only mean this for talk pages, the Wikipedia:Talk page guidelines would be a more appropriate fit.) WhatamIdoing (talk) 02:56, 28 August 2025 (UTC)[reply]
Yes, making an addition to WP:Editing policy could be a very good alternative to a standalone policy page. (I would still want an RfC to establish consensus for such a change to the editing policy, but it might not be as extensive a process as creating a standalone policy page.) --Tryptofish (talk) 21:36, 28 August 2025 (UTC)[reply]
What do editors think about the relative merits of creating a new standalone policy page, versus making a new section within WP:Editing policy? Personally, I find both options attractive, and I'm wondering about what others think would be the better way to go. --Tryptofish (talk) 22:32, 29 August 2025 (UTC)[reply]
RE: WP:EDITPOL, it's a good idea, though I've always thought of EDITPOL as being strictly about articles/content. LLM disclosure should be anywhere on the project (user pages, draft pages, interface pages, project pages, templates, modules, etc. and their respective talk pages). Now it may be that it's as simple as calling out that disclosure is project-wide, not just related to content. But the other benefit of a dedicated LLM policy is that it can serve as a home for other AI/LLM rulemaking and discussion. It's also possible we eventually carve things out into transcludable sub-pages similar to what is done with WP:NFC and WP:NFCC; portions will be policy (e.g. hopefully this proposed disclosure, WP:AIIMAGES, etc), portions will be guideline (e.g. the current WP:HATGPT), and still other parts could be informational (how to help with dealing with the onslaught of AI content). —Locke Cole • t • c22:45, 29 August 2025 (UTC)[reply]
After thinking about this, although I'm naturally attracted to WAID's idea of using EDITPOL because the process would potentially be simpler, I think I'm persuaded by Locke's two points – that EDITPOL is primarily about mainspace and we would have to distinguish this as being about all namespaces, and that it would be useful to leave room for future additions to policy about LLMs, if they eventually come about – that I think it would probably be better to propose a new standalone policy page. --Tryptofish (talk) 19:15, 30 August 2025 (UTC)[reply]
Editors can still lie about their LLM usage (the same way editors can lie about not being a paid editor or a sockpuppet), but it's better than nothing I guess. Some1 (talk) 23:12, 27 August 2025 (UTC)[reply]
As second choice, support. In case the proposal to ban all AI-generated comments and proposals does gather consensus, the disclosure of such comments would be alright. It still wouldn't be perfect because it would waste the time of editors. Still, something is better than nothing. 🇪🇭🇵🇸🇸🇩 Easternsahara 🇪🇭🇵🇸🇸🇩 16:09, 2 September 2025 (UTC)[reply]
I proposed this some time ago as WP:LLMP, which at its RfC had many more supports than opposes, so I would support it being passed as a separate thing. jp×g🗯️19:52, 13 September 2025 (UTC)[reply]
Break - LLM proposals
Just wanted to step back, because I think we are wandering off course. There are several different issues to deal with when it comes to using LLMs in Wikipedia that we seem to be conflating:
Using an LLM for research (behind the scenes).
Using an LLM to generate text and citations in ARTICLE Space.
Using an LLM to generate text and arguments in TALK Space.
I think we need separate approaches to each of these: #1 is allowable, but we should advise editors to use with caution. #2 is NOT allowable at all. #3 is discouraged, but should be allowed with disclosure. Blueboar (talk) 17:12, 30 August 2025 (UTC)[reply]
It's more complicated than a simple yes/no in all of these cases. As ever with LLM-related proposals nuance is missing. Using LLMs to generate text and then posting that text to Wikipedia without review is, by consensus, not allowed. However using LLMs to generate a framework around which you write your own words, using an LLM-based tool to check your text for e.g. spelling/grammar, using an LLM to assist with translation, using an LLM to suggest sources, and similar are all acceptable provided that the final review is human and (at least in talk spaces) the essential comments/arguments originate from a human. Thryduulf (talk) 18:00, 30 August 2025 (UTC)[reply]
I'm grasping for something, and would be thrilled if someone could come up with a solution for it. Is there a way to simply and clearly articulate what distinguishes the kind of harmless "behind the scenes" use of LLMs from the kinds of uses that are likely to be unhelpful? --Tryptofish (talk) 19:10, 30 August 2025 (UTC)[reply]
Much of the problem with the LLM-related discussion is treating something that is inescapably complicated and nuanced as a binary "good/bad". However if you absolutely must have a single sentence, then the best I can come up with is: Problems are most likely when LLM output has not been subject to active human attention and review as (at least) the final step in the chain. That's not to say that all human-reviewed LLM output is good or that all LLM output unreviewed by a human is bad (because neither is true) it's just a probability gradient. Thryduulf (talk) 19:26, 30 August 2025 (UTC)[reply]
Thanks for that, I think it's useful. Just to clarify, it isn't like I must have a single sentence. Rather, I'm trying to figure out how to develop a policy proposal that will work (and even reflect the wishes of skeptics like you), and I'm using the discussion here to crowdsource ideas for how to do that. --Tryptofish (talk) 19:32, 30 August 2025 (UTC)[reply]
Another thing to keep in mind is the future: Imagine that it's a few years from now. The technology has gotten much better. The results are usually indistinguishable for something like a talk-page comment. And, of very high importance, a whole generation of students has been explicitly taught to use these tools in school, so they think it's everyday normal behavior – no different from our generation using predictive typing to get spelling correct or to save a little time when typing an e-mail message.
In this world of integrated AI tools, Wikipedia has a simplistic Official™ Policy that says Thou Must Disclose the Use of Any Generative AI Tools in Thy Talk Page Comments.
Do you think that policy will be respected? I've got some doubts. I'm wondering if it might sound a lot like "Please disclose that you're using a computer, 'cause us old folks need reminders about the existence of all this newfangled technology".
If we adopt a policy to require disclosure in discussions, I wonder if we'll see WP:CUSTOMSIG used to make sure that every possible comment is disclosed. Instead of "(please ping)", it'll be "(uses LLMs)". Or maybe a user script to add a disclosure (e.g., "may have used an LLM") as an edit summary if the edit is over ~100 words.
Wikibooks discussed an AI policy a while ago. Their risks are higher than ours, but some of the proposals were massive overreach (e.g., if you use an LLM, you need to post the entire transcript of your discussion with the LLM on the talk page). I think this is much more reasonable, but I wonder if it has legs, or if we'll be repealing it a decade from now. WhatamIdoing (talk) 05:49, 31 August 2025 (UTC)[reply]
The tools have gotten better, and anecdotally it feels easier to find AI-generated edits from the earlier LLMs of 2023, even though you'd think it'd be the opposite as there's more time for people to revise the text.
That's part of why I am pushing for as full disclosure as possible -- what tool, what prompts, what process -- because if we can get a reasonable sample set of edits made with ChatGPT 4 vs. ChatGPT 5 vs. Gemini , etc., we might be able to determine some indicators of AI use that haven't been (apologies for the AI-esque language) widely publicized yet.
Not a fan of the 100-words cutoff though. In practice, this will be done via diff size, and a lot of AI edits revise text substantially but show small increase/decreases in page history. And even if the edit actually is small, it can still contain hallucinations -- for instance, inaccurate or non-neutral photo captions. Gnomingstuff (talk) 17:37, 1 September 2025 (UTC)[reply]
I believe that in the visual editor, you could get a count of how many words are 'touched' by an edit, and thus you could realistically have a zero-net-bytes edit flagged as changing a larger amount of text.
But mostly I think that if we require disclosure, we'll be seeing technical compliance – not "I used an LLM to write this specific talk page comment", but "Hey, I'm disclosing that I'm the kind of person who sometimes uses LLMs". WhatamIdoing (talk) 21:58, 6 September 2025 (UTC)[reply]
You can't just handwave away all the arguments that explain all the detail and nuance and then say there isn't any nuance. That's not how things work in the real world (which is the only world we, as mature and intelligent adults, should be dealing with). It's absolutely not a case of "LLM = bad". Thryduulf (talk) 19:46, 30 August 2025 (UTC)[reply]
If one wants to consult an LLM/AI, one can do that without the need to do so via Wiki/a Wiki editor. If we all want to include LLM/AI stuff into WP, then just stick a google type analysis or a prompt together with suitable caveats into the main text of articles that anyone can consult if they please. Selfstudier (talk) 16:45, 31 August 2025 (UTC)[reply]
@Thryduulf Just curious, what is your thoughts on the required disclosure (above)? I understand where Blueboar is coming from, but any step we can take towards transparency is a step worth taking, but curious how you feel about it. —Locke Cole • t • c20:48, 30 August 2025 (UTC)[reply]
In a word, complicated. I can't object to disclosure in principle, but I'm not certain what benefits it will bring in practice and worry that it will be misused. Specifically, I can easily see all of the following behaviours happening.
Edits that are disclosed to have had some LLM use just ignored/hatted/reverted/disregarded based on that alone without the content of the edit being even looked at to see whether it is actually good or bad
Editors being harassed because they didn't disclose LLM use in a edit that someone suspects (with or without good reason) was LLM-generated, even if the editor is telling the truth and they didn't use an LLM.
Editors being harassed because they didn't disclose LLM use for an edit, without regard to the content of that edit, based solely on a previous edit being disclosed as LLM-assisted. This will happen even when the editor is telling the truth.
False positives and false negatives due to editors not understanding what "LLM" (or some other term) means and/or not understanding what we mean by whatever term is used.
Different understandings of what constitutes LLM-usage (is it any use of an LLM? Only when the exact words in the edit were generated by an LLM and not reviewed? Somewhere in between?) leading to disagreements over whether an edit should or should not be marked as LLM-assisted. Such arguments will detract from the actual content of the edit (in some cases leading to the content being ignored completely).
Not every edit will result in one of these types of behaviour, but all of these that do will actively harm the encyclopaedia (not all in the same way), potentially very significantly, and all entirely unnecessarily. If we just accepted that just as some human edits are good and some human edits are bad, some LLM-edits are good and some LLM-edits are bad and that we can and should deal with them appropriately in each case without needing to know or care whether a good (bad) edit is a good (bad) human edit or good (bad) LLM edit or a good LLM-and-human edit. Thryduulf (talk) 22:51, 30 August 2025 (UTC)[reply]
Thanks for the feedback, I definitely feel like there's an opportunity to instruct and not simply penalize or restrict here. I still think the sheer volume of these types of edits are the primary cause for alarm. I don't think anyone here wants to harass other editors, but as with any "rule", there is always the potential for abuse or misunderstanding. —Locke Cole • t • c17:27, 31 August 2025 (UTC)[reply]
I don't think anyone in this discussion intends to harass other editors, but (per WAID) experience has already shown that regardless of intent, editors are being harassed. We should do our utmost to avoid that, and part of that is not instituting policies that stand a high likelihood of (unintentionally) enabling or encouraging harassment while simultaneously providing little to no benefit to the project. Thryduulf (talk) 22:42, 31 August 2025 (UTC)[reply]
I think this could actually be made in an even simpler way than an edit summary, by adding a checkbox next to the existing "minor edit" one. Wikimedia Commons already has a "this image was made by an artificial intelligence tool" checkbox, and, while the situations aren't directly comparable, most users are not fundamentally dishonest to the point of lying about this. Agree with your point regarding spell-checking errors, although these are, usually, easier to catch (grammar errors, or meaningless words similar in orthography to more relevant ones). Chaotic Enby (talk · contribs) 22:27, 27 August 2025 (UTC)[reply]
A checkbox would be great. But even just updating the system messages (the ones that display licensing information) to include a warning and link to the current LLM guidance would be an improvement. —Locke Cole • t • c22:32, 27 August 2025 (UTC)[reply]
CE said Wikimedia Commons already has a "this image was made by an artificial intelligence tool" checkbox, and Commons runs MediaWiki, so if they can do it, I can't imagine we couldn't do something similar. —Locke Cole • t • c01:07, 28 August 2025 (UTC)[reply]
Wikimedia Commons' Upload WizardHere is what it looks like, for reference. What I'm having in mind is a more lightweight checkbox that adds a tag to the edit (or, if it can't be done directly, switching a variable that the edit filter extension can then catch to add the tag). Disclosing the model and prompt might not be as useful, although they could technically be appended to the edit summary with a small dose of Javascript. Chaotic Enby (talk · contribs) 01:17, 28 August 2025 (UTC)[reply]
Hmm, yeah I think Special:Upload is a bit more customizable, though everything we see in the interface should be changeable somehow, see Special:Allmessages (which there's hundreds, maybe thousands, but there's some search functionality if you want to go digging). We could also ask at WP:VPT since there's plenty of folks who know this stuff under the hood more lurking there. —Locke Cole • t • c01:27, 28 August 2025 (UTC)[reply]
It looks like the dialogue box for "publish changes" has many components, including
Having a checkbox is a very good idea, that I hadn't thought of. Perhaps, that might negate the need to propose a policy. On the other hand, I can think of two potential friction points. One is that an editor who makes bad-quality edits, but consistently checks the checkbox, might complain that there's nothing wrong with their edits because they used the checkbox, so why were their edits reverted? The other is whether or not we need a policy for someone who keeps making bad-quality edits, and ignores the checkbox. --Tryptofish (talk) 21:31, 28 August 2025 (UTC)[reply]
The checkbox wouldn't negate other content policies, so an editor making bad quality edits but using the checkbox wouldn't have any kind of immunity. In my mind, it is similar to the situation at AfC with COI disclosures – editors can and often do make the disclosure in the Wikipedia:Article wizard , but that doesn't make their submissions immune to other kinds of feedback or criticism. Chaotic Enby (talk · contribs) 21:55, 28 August 2025 (UTC)[reply]
Yeah, I think that gets it right. The checkbox is a technical feature that can and should be pursued independently of the policy-related ideas we are discussing here. --Tryptofish (talk) 21:58, 28 August 2025 (UTC)[reply]
It needn't necessarily even be a checkbox. Don't get me wrong, that would be great (but I suspect then everyone would want a checkbox for things that are, ostensibly, equal to or greater than LLM/AI discloure (like COI, or copyright/plagiarism, or paid editing; the list is long). The other possibility is adding something to the boilerplate text (in replytool the By clicking "Reply", you agree ... language; the full interface editor has something similar). Something short, like You agree to abide by our LLM/AI disclosure rules, and that failure to do so may lead to blocks or bans. With wikilinks to appropriate pages should disclosure become policy. —Locke Cole • t • c22:34, 29 August 2025 (UTC)[reply]
Copyright/plagiarism is already banned, and copying with attribution needs the attribution in the edit summary (a simple yes/no check wouldn't work), but COI/paid editing could absolutely also deserve a checkbox. If anything, both that and AI disclosure are more important than the current "minor edit" checkbox, which is often misused and doesn't actually tell much. Chaotic Enby (talk · contribs) 20:38, 30 August 2025 (UTC)[reply]
Oh I know they're already restricted, I was just pointing out that if we start down this path, it wouldn't be much to think that we'd end up with 4-5 checkboxes before you know it. And then contributing to Wikipedia would turn into a CAPTCHA-esque triathlon of mouse clicks/screen taps just to submit something. However, a short sentence (with links for further details) about how we require LLM/AI disclosure (assuming Tryp's idea gains community support). As Tryp rightly points out below, however, there is the risk of "banner blindness" if we just add some text and people ignore it completely (the 'ol "officer, I didn't see the speed limit sign"-excuse). —Locke Cole • t • c21:16, 30 August 2025 (UTC)[reply]
New editors who see a checkbox that says says "this edit was created with the assistance of an LLM" or otherwise will likely view it as a tacit endorsement by the project of LLM editing. This is in misalignment to current community sentiment. I'd oppose the addition of any such checkbox. fifteen thousand two hundred twenty four (talk) 22:45, 28 August 2025 (UTC)[reply]
Perhaps, but I agree with 15224 that we should not use language that will mislead them into thinking that the community accepts this. --Tryptofish (talk) 22:56, 28 August 2025 (UTC)[reply]
I think it would ultimately encourage more editors to use LLMs and lead to more LLM-based edits made to the encyclopedia. This is an undesirable outcome. On top of this, editors already have enough problems properly utilizing the minor edits checkbox, and I expect self-snitching compliance with such a checkbox to be extremely low. The harm will well outweigh any theoretical good. fifteen thousand two hundred twenty four (talk) 23:12, 28 August 2025 (UTC)[reply]
"large proportion" – Compared to total AfC users? Sure. Compared to total undisclosed COI editors? I'd say that's unknowable. Based on my limited experience with some UPE farms I'd guess there's more not disclosing than disclosing. And asking for COI self-disclosure carries a lower inherent WP:BEANS risk than a checkbox for disclosing LLM use. fifteen thousand two hundred twenty four (talk) 23:52, 28 August 2025 (UTC)[reply]
It looks to me like nothing about the checkbox idea negates the possible proposal being discussed here, so I think that it's really a separate topic that, if people want to explore it further, should be taken to a talk section of its own. --Tryptofish (talk) 00:19, 29 August 2025 (UTC)[reply]
I think it would ultimately encourage more editors to use LLMs
Honestly, I doubt this. ChatGPT has been around for 2 years and has a great deal of name recognition and regular use. If someone's using an LLM to contribute to Wikipedia, they're probably routinely using AI already and were going to do it anyway. I can't see a situation where someone comes to Wikipedia not intending to use ChatGPT, then changing their mind when they see the checkbox, after they already made the edit.
As far as "self-snitching compliance," you would be surprised at how many people will be open about using AI if you ask politely. (If you ask adversarially, which is what people are doing more often, then they won't.) The risk isn't so much people lying as people not knowing how substantial AI edits can be. A pretty common scenario, for instance, is someone whose first language is not English asking ChatGPT to generate a Wikipedia editing prompt, and then feeding that AI prompt back into ChatGPT or some other AI tool. Even if English is your first language, AI editing tools advertise a lot of use cases and it's unclear what the differences are -- usually because it's marketing and the details are deliberately vague. Gnomingstuff (talk) 19:30, 30 August 2025 (UTC)[reply]
My concern is less about making editors aware that LLMs exist and could be used, and more about doing everything we can to not look like their use is endorsed in any form. As said above I think many will see it as tacit endorsement of model use, and take it as permission to go ahead in the future.
How would you feel then about a checkbox with something along the lines of "this edit was created with the assistance of an LLM, and I attest that I personally verified the accuracy of the generated text"? CoffeeCrumbs (talk) 19:17, 30 August 2025 (UTC)[reply]
We can't say "LLM," people aren't going to know what that is. We have to say "AI," and we probably should also include some examples, like "such as ChatGPT, Perplexity, etc.).
I don't think it matters what text accompanies it, if the text indicates LLM use is ok in some form so long as a box is checked, that's the association that will be made.
A secondary concern is the fact that LLMs have numerous shortcomings that are harmful to the encyclopedia, far too many to cover in a snippet, and a link to more information would go largely unread. fifteen thousand two hundred twenty four (talk) 20:06, 30 August 2025 (UTC
Yeah, those are good points. I'm less and less convinced that we can make a succinct enough checkbox that doesn't convey the "LLMs are a valid way to contribute" impression. Chaotic Enby (talk · contribs) 20:43, 30 August 2025 (UTC)[reply]
That's what I'm coming to think, too. As I've been following this discussion, I think the combination of "banner blindness"/didn't read, along with the misimpression that LLMs are a valid option, are things we won't be able to get around, no matter how we try to frame the checkbox question. --Tryptofish (talk) 20:49, 30 August 2025 (UTC)[reply]
However, there are concerns. I see some editors here showing their concern that using such a 'disclosure checkbox' might encourage Wikipedia users to use AI more than before.
I might as well request them to the see the other side of the coin. I've seen a lot of editors in this discussion having a knee-jerk reaction against the use of AI. So as soon as someone adds the 'AI tag' in their addition through the checkbox, these type of editors will instantly take 'em down regardless of the value they might add to Wikipedia.
As such, I think there should be a proper guideline to the editors, as on how to be benevolent to good faith AI additions which are clearly useful to Wikipedia, before adding such a checkbox.Cdr. Erwin Smith (talk) 05:47, 3 September 2025 (UTC)[reply]
The number of uploads on Commons that claim own work when they are definitely not limits my enthusiasm for submission checks. Regarding the concept, if the aim of the checkbox is to find edits to revert, then that sets it up to be detrimental to the more honest editors. CMD (talk) 09:32, 3 September 2025 (UTC)[reply]
That's a good point, although Commons also has AI disclosure, and most of the undisclosed AI images that I've found are from people who were spamming anyway. Gnomingstuff (talk) 13:52, 3 September 2025 (UTC)[reply]
CMD makes a very good point. People claim "own work" on Commons all the time. Cross-wiki/within-the-editor uploads have been restricted because people think "Well, if I don't claim that this corporate logo/album cover/normal thing to include is 'own work', then it won't let me upload it. So of course I tick the box!" An interface item that requires disclosure will, at least by a non-trivial group of users, be ticked or not based on what they believe will produce the results they want. WhatamIdoing (talk) 02:55, 4 September 2025 (UTC)[reply]
The RfC isn't about Wikimedia. It's about 'discussions seeking community input' in Wikipedia.
It's not off topic. Human behavior is the same everywhere, especially when it's the same humans. An editor who – right here, at the English Wikipedia, in the 2010 wikitext editor – will click the 'Image' button in the toolbar, click the "Upload" button in the dialog box, and then tell an outright lie when faced with a tickbox that says "This is my own work" is an editor who – right here, at the English Wikipedia, in the 2010 wikitext editor – will equally tell an outright lie when face with a tickbox that says "I certify that I wrote this myself without using AI".
There is no reason to believe that Wikipedia editors will frequently lie when shown one tickbox in the wikitext editor and yet be reliable truthful when shown a very similar tickbox in the same editor. WhatamIdoing (talk) 21:45, 4 September 2025 (UTC)[reply]
To explain myself, what I wanted to say is that there's no such stringent licensing requirements in most of the Wikipedia "discussions seeking community input", as opposed to Wikimedia where it's very stringent.
So I think people will be more willing to disclose the use of AI. But it should only be done with a proper guideline on how to handle such requests benevolently, and not for the sole purpose of striking them down. Cdr. Erwin Smith (talk) 13:07, 5 September 2025 (UTC)[reply]
Oppose - Many people use LLM to improve their own grammar, including me. You have to realize that we have Wikipedians from all over the world with English as not their first language and have poor grammar. Instead of completely disssallowing it, meybe there needs to be a disclosure by the person that used LLM and an explenation as to why they used it. I also don't beleive anyone requesing RFC, AFD, etc with use of LLM has any other intent than posting what they intent to post. At the end they are probably reading what the the AI said and maybe even revising it before posting it.Darkm777 (talk) 18:39, 6 September 2025 (UTC)[reply]
(Unfortunately, your !vote here demonstrates the reality in which we increasingly have to work. It's a reality where editors who ostensibly characterize LLMs as purely supplementary or secondary to their participation in discussions, are nonetheless using them in some manner where they take time to read and understand what other editors have actually said far less than would otherwise be necessary to participate, yet replying as if that matters little to others – whether one's efforts to communicate are equally justified if they get processed solely by a prompt on the other side without the ostensible person in the equation bothering whatsoever to chip in to the discussion.) Remsense 🌈 论18:51, 6 September 2025 (UTC)[reply]
Yes, or you can put it through a grammar checker like the one built into Microsoft Word, Grammarly or whatever. I'd rather read a comment with bad grammar and no puffery than something with the most exquisite grammar, so good that i start convulsing with joy, and even a little bit of puffery. 🇪🇭🇵🇸🇸🇩 Easternsahara 🇪🇭🇵🇸🇸🇩 23:33, 6 September 2025 (UTC)[reply]
I'm a bit skeptical about the checkbox. There is a grey area here - some editors use LLMs to write whole posts and some use them to check grammar or style. If marking one's edit as AI-assisted gets perceived as diminishing the strength of one's argument, editors will tend to "forget" to mark their edits.
Also, it took me a couple of minutes to get the GPTZero score of a purely AI-generated text to 54% and I'm sure I'd be able to reduce it even more with a bit more effort. So since we have no reliable way of detecting these edits we we'd create an incentive to lie without any means to counter it. Alaexis¿question?21:18, 8 September 2025 (UTC)[reply]
Since the discussion is slowing down, I'll be giving my final opinion on the whole debate.
Oppose the speedy closure of "discussions seeking community inputs" written by AI.
Support a Checkbox for AI disclosure, with the AI category having a 3rd subcategory asking people to state 'why' they used the AI, or their 'purpose' - Fixing Grammar/Finding Relevant Policies/Writing 'XYZ Edit or Request' Partially/Writing 'XYZ Edit or Request' Fully.
Support a specific policy for all editors to act neutral and treat such AI Edits/Requests equally as they would a Human Edit/Request (Note : A proposal on not flooding the AfD either by AI/Human is being worked upon).
I have many issues with your last point, but probably the most important is that Wikipedia does not have "higher-tier editors" or different policies for them. jlwoodwa (talk) 00:28, 12 September 2025 (UTC)[reply]
Policies apply the same for everyone, sure. But there's definitely a hierarchy present in Wikipedia based on tools and user rights, and one can only climb the ladder step by step on the basis of their actions. The number of users decreasing drastically in each higher level is a proof.
However, you are partially right. Although the influence of the higher-tiers is much bigger, I did forget that Autoconfirmed users can also participate in many of the 'discussions seeking community inputs'. So the same ruleset should apply to them as well. I would also be adding the ongoing AfD issue which is being worked upon. Cdr. Erwin Smith (talk) 10:34, 12 September 2025 (UTC)[reply]
Consensus among a limited group of editors, at one place and time, cannot override community consensus on a wider scale. For instance, unless they can convince the broader community that such action is right, participants in a WikiProject cannot decide that some generally accepted policy or guideline does not apply to articles within its scope.
I don't think it's unreasonable to conclude that while some parts of MOS are the result of consensus with significant participation, there may be other parts that are indeed consensus among a limited group of editors, at one place and time.
Also of note are the proposals by L235 that did not make principles for that case. Specifically,
Policies and guidelines have a combination of prescriptive and descriptive characteristics. Policies and guidelines document community consensus as to "standards [that] all users should normally follow" (Wikipedia:Policies and guidelines), giving them some degree of prescriptive force. Simultaneously, policies and guidelines seek to describe "behaviors practiced by most editors" (Wikipedia:Policies and guidelines), and change with community practice, giving them a descriptive quality. Naturally, disagreements regarding the extent of a policy's consensus or prescriptive effect arise from this combination, and the text of a policy can sometimes diverge from or lag behind community consensus. These disagreements, like all disputes on Wikipedia, should be resolved by discussion and consensus.
Does MOS necessarily indicate community consensus on a wider scale? In other words, should closers examine the specific text for level of consensus before using it to overrule a (potentially larger) group of editors? Good day—RetroCosmostalk01:45, 26 August 2025 (UTC)[reply]
I would agree with L235, and add that, ideally, policies and guidelines describe community consensus and prescribe editors to follow this consensus. Regarding the MoS, as a set of guidelines with various ranges, it is expected that not all of its pages will have the same level of consensus – a very specific topic will attract less interested editors, and thus naturally have a lower CONLEVEL. That in itself is not necessarily problematic. However, if it goes against a wider consensus, or only reflects a subset of the views of editors interested in that topic, then there is indeed a CONLEVEL issue and a broader discussion should be held. Chaotic Enby (talk · contribs) 15:31, 26 August 2025 (UTC)[reply]
As a closer, I would not feel justified in going on an independent fact-finding mission to determine the level of consensus that supports a specific policy or guideline. I would support overturning closures that were based on such an independent mission. If participants in the discussion gave valid arguments based on their own analysis of the level of consensus, I would consider that when making my decision.To put it another way, I presume that guidelines and policies have a higher level of consensus than any local discussion. A mass of editors who disagree with a guideline should be directed toward venues where guideline change can happen, not a local discussion. Firefangledfeathers (talk / contribs) 15:53, 26 August 2025 (UTC)[reply]
Consensus isn't only found by discussion, but also by use. Maybe four editors discussed a particular piece of policy or guidance, but many editors may follow it because they also support what has been said. If editors disagree with any particular price of guidance then they should start a centralised discussion in whatever forum would be appropriate. So the answer to the specific question is probably, maybe, but to start discussion on specifics as required. Certainly the MOS in it's entirety has some level of wide scale support, even if it's quite possible that not all of it does. -- LCU ActivelyDisinterested«@» °∆t°12:42, 27 August 2025 (UTC)[reply]
ActivelyDisinterested is absolutely right. Many long-standing aspects of the MOS have strong consensus not because of the number of editors involved in the original drafting, perhaps decades ago, but because they have been widely followed without significant challenge ever since. It would be quite unworkable for closers to start undertaking historical investigations about the origin of about any particular rule in order to determine how seriously it is to be taken. All MOS rules should generally be followed per WP:MOS, and if a later group of editors think the rule is wrong they always have the option to open a centralised discussion suggesting that it be changed. MichaelMaggs (talk) 13:23, 27 August 2025 (UTC)[reply]
To answer the question Does MOS necessarily indicate community consensus on a wider scale?, I would say the answer is a clear yes. Closers should not try to deep dive the history of how certain parts of the MOS came to be in determining a local consensus on (for example) an article talk page. Instead, those concerned with MOS should go to the MOS talk page and open a discussion there to enact change. And I would say this for any policy/guideline (including notability guidelines, for example, where I've found discussions were limited to 2-3 people for some changes, but those changes have stood for over a decade). —Locke Cole • t • c19:45, 27 August 2025 (UTC)[reply]
I think this RFC question would have benefited from some additional workshopping. There are two unrelated questions being asked:
Is the MOS prescriptive, descriptive, or both?
Does the MOS have consensus?
My answer to the first requires you to know what prescriptive and descriptive mean. The MOS is both, depending upon the level you analyze it at. It is descriptive in the sense that the community wants to follow the rules of good grammar, punctuation, and other elements of writing style that are relevant to an encyclopedia. We follow these; therefore, a style guideline saying to follow these accurately describes the community's practice. At a more specific level, the MOS is prescriptive: instead of saying 'the community uses good punctuation practices' (descriptive), it says 'the correct punctuation practice to use is this one' (prescriptive).
My answer to the second is that you should assume, unless and until you can prove otherwise, that any page with a {{guideline}} tag at the top is exactly that community consensus on a wider scale that is mentioned in CONLEVEL. RetroCosmos, since this was all before your time, let me tell you in very concrete terms what CONLEVEL is actually about: CONLEVEL means that when MOS:INFOBOXUSE says The use of infoboxes is neither required nor prohibited for any article, then a handful of editors at Wikipedia:WikiProject Composers are not allowed to say "Yeah, well, that might be what the official Wikipedia guideline says, but they're prohibited for our articles, because we had a private chat among just our little group of editors, and we decided that the official Wikipedia guidelines don't apply to us". Trying to apply the MOS (or any other policy or guideline) = not a CONLEVEL problem. Declaring "your" articles exempt from the MOS = possibly a CONLEVEL problem. WhatamIdoing (talk) 20:30, 27 August 2025 (UTC)[reply]
This RfC is overly broad. Most of the MOS is supported by strong affirmative consensus. I encourage editors who take issue with a particular part of the MOS to start an RfC asking whether that particular part currently has the support of the community. Such narrow discussions would be far more productive than philosophizing on the nature of the MOS as a whole. Toadspike[Talk]06:07, 30 August 2025 (UTC)[reply]
This RfC is not helpful because standard procedure acknowledges that no set of rules can apply in every circumstance. The Article_titles_and_capitalisation_2 Arbcom case concerned extreme disruption over an extended period. That can occur with any policy or guideline. A favorite that pops up from time to time is WP:V where people go around deleting chunks of correct and well-written material because no one has added citations. WP:V definitely applies everywhere but dumbly pushing it wll result in blocks. Johnuniq (talk) 06:42, 30 August 2025 (UTC)[reply]
Even if we accept, for the sake of argument, that the topic-interested in an MOS discussion might sometimes result in an MOS issue resulting in a local consensus, the solution certainly wouldn't be to defer to a local consensus, which is far more likely to represent a local consensus. If there are concerns that an MOS consensus was not agreed upon by a sufficiently wide cross-section of editors, then the solution would be to discuss that consensus in a place likely to be seen by a wide cross-section of editors.CoffeeCrumbs (talk) 19:07, 30 August 2025 (UTC)[reply]
Right. All guidelines, including all MOS pages, are presumed to have full community (i.e., non-local) consensus. However, there are hundreds of guidelines with thousands of pieces of advice, and at any given point in time, some small fraction will be out of date, badly explained, not reflective of current community practices, etc. Whenever those problems are identified, editors should fix them. That can be done through bold editing, through ordinary discussions on the guideline's talk page, through RFCs, etc. And even if the advice is sound in general, there might be reasons to not apply it in a specific instance. But you should not start from a position of assuming the MOS to be a WP:LOCALCON. It might be wrong, and it might need to be changed, but it's not a local consensus. WhatamIdoing (talk) 05:59, 31 August 2025 (UTC)[reply]
I don't know what the status is now, but I remember when the MOS had large parts written by a small group who hung out on the MOS talk pages, fiercely arguing with anyone who came there with an opposing viewpoint to preserve their desired version. Anomie⚔11:35, 31 August 2025 (UTC)[reply]
As a participant in the arbitration case referenced in the opening, I feel I should point out that the issue there wasn't disagreement with the MOS but disagreement over how a particular section (MOS:CAPS) is interpreted. ~~ Jessintime (talk) 11:53, 31 August 2025 (UTC)[reply]
That was a reckless charge during the arb case. If something, in fact, lacked WP:CONLEVEL, then it should have been changed by a larger consensus. The case failed on that point. —Bagumba (talk) 14:08, 31 August 2025 (UTC)[reply]
The answer to the question "Does MOS necessarily indicate community consensus on a wider scale?" is generally no. The MOS is by and large the result of WP:BOLD editing and even when there is a discussion it usually involves only a very small number of people. It therefore reflects local consensus. Much was written before guidelines became elevated to the status they hold today and at best has implied consensus owing to having been there for years without being changed. In cases where it has proven too burdensome, it has indeed been overridden by a larger consensus. Most editors cannot be bothered. Some parts have never been able to reach a consensus. Mainly, though, we have an ongoing iterative process of improvement. Hawkeye7(discuss)03:45, 3 September 2025 (UTC)[reply]
I reject the notion that two editors on an MOS talk page represents community consensus better than fifty editors on Wikipedia:WikiProject Composers. Consensus among a limited group of editors, at one place and time, cannot override community consensus on a wider scale. That applies to the MOS talk pages every bit as much as project talk pages. Like most editors, I am happy to follow local consensus. Hawkeye7(discuss)23:01, 3 September 2025 (UTC)[reply]
I agree with Hawkeye, what matters is the visibility and scale (number of participants) of a discussion, not the venue. Obviously the venue is not irrelevant - a discussion at VPP is more likely to be accidentally discovered than one at e.g. Wikipedia talk:WikiProject Poetry, but if the latter is well-advertised and attracts 30 editors the consensus it establishes is more likely to reflect community consensus than an un-advertised discussion at Wikipedia talk:Manual of Style/Titles of works with only three participants. This is especially true if the subject of the discussion is specific to poetry and the consensus is to adopt the style that's been consistently used by a significant majority of relevant articles for many years. Obviously there are exceptions to this (e.g. if the de facto standard is inaccessible) but those exceptions need to be supported by evidence of an actual problem and an alternative must not be blindly and rigidly enforced without discussion to see if a compromise can be reached. See Wikipedia talk:WikiProject UK Railways/Archive 48#DLR colours for a semi-relevant example. Thryduulf (talk) 00:23, 4 September 2025 (UTC)[reply]
But do you also reject the notion that two editors on the guideline's page is better than two editors on any other page, when the purpose of the discussion is to improve the guideline?
Or imagine that it's not a guideline. If you and I have a chat on an article's talk page, is that better than you and I having the same chat on your talk page? WhatamIdoing (talk) 02:58, 4 September 2025 (UTC)[reply]
do you also reject the notion that two editors on the guideline's page is better than two editors on any other page all other things being equal, the discussion on the guideline's talk page is slightly better, but its still a weak consensus. A discussion elsewhere that is advertised to multiple places, including the guideline's talk page, is stronger than one with approximately the same number of participants that was held on the guideline's talk page but was not advertised elsewhere. Also, where the elsewhere is can matter - a WikiProject talkpage is probably going to produce a stronger consensus than an article talk page, which in turn is probably' stronger than a discussion on your or my talk page.
Venue, number of participants, amount of advertising, significance of change (from both the de jure and de facto status quo), reason for the change, depth of discussion and degree of unanimity are all relevant considerations and you absolutely cannot look at one factor in isolation and arrive at a reliable answer. Thryduulf (talk) 10:30, 4 September 2025 (UTC)[reply]
A WikiProject's talk page is more likely to produce the appearance of unanimity. The people in that group are largely there because they like working with each other, after all, and we expect them to mostly agree with their chosen wiki-friends. It is also, for most subjects, likely to represent the views of editors who know something about the subject matter (e.g., if you have a question about a medical article, drop by Wikipedia talk:WikiProject Medicine, not a village pump).
It is, however, less likely to represent the broader community's POV, especially if the question is:
not a question in which the group's subject-matter expertise is relevant (e.g., WikiProject Composers on infoboxes; WikiProject Infoboxes on composers' genres) or
an interdisciplinary question (e.g., in which WikiProject Medicine and WikiProject History might have different perspectives on what's important to include in the article).
I don't know if this is a good example, but I uploaded an image which (to my understanding) was allowed by policy/guideline. The image replaced an existing fair-use JPEG with a fair-use SVG of a videogame box cover. Upon getting the deletion notification for the old JPEG, the editor that uploaded the JPEG passed on talking to me directly, or opening a discussion at the article talk page, or just taking it through WP:FFD. Instead they opened a discussion at a WikiProject and "unanimously" decided to remove the image there.
In my view, the WikiProject definitely has knowledge about videogames, but the issues being raised by editors there are more technical and/or concern NFC questions, so surely the discussion would have made more sense at the article talk page with pointers at WP:VPT, WT:NFC and WT:VG to this centralized discussion. —Locke Cole • t • c02:36, 7 September 2025 (UTC)[reply]
I think FFD might have made more sense, but I think the important thing to do right now is for you to post messages to relevant pages (e.g., WT:NFC) to bring in people who know less about what the group usually does, and more about what the Wikipedia:Non-free content criteria policy actually requires. WhatamIdoing (talk) 17:02, 7 September 2025 (UTC)[reply]
So, as I see it, there are a couple of things going on here which could influence how much "binding" consensus we should ascribe to any particular section/verbiage within the MoS. And these absolutely should be given serious consideration when applying any particular rule of thumb found within the manual, but in practice, these considerations are rarely cited, let alone heavily considered in debates that center around particular application in given use cases in article space. It would be nice if we had a more formalistic system for establishing the weight and uniformity to be ascribed to any given style principle, but the ad-hoc nature of the evolution of the MoS, combined with the fact that it was at one time meant to be purely advisory, but over time has taken on a less permissive tone overall, and with particular sections being almost entirely mandatory, that it would be very difficult to reverse engineer the entire body of style recommendations and re-code them in conformity with new and more express scheme for different levels of absoluteness with regard to different provisions. Though goodness knows that would probably save the community a lot of time on disputes if such a clearer system were implemented, so maybe it will be worth the effort at some point.That lengthy preamble made, here are the primary two factors that I think influence how much weight and certainty a given piece of style guidance should have:
First, was the discussion which lead to that verbiage the result of a full and appropriately approached WP:PROPOSAL? How many individual discussions were held, and how many community members took part in those discussions? Were the held in the right venue for the proposal in question (the talk page of the MoS subsection itself or the village pump, typically) and were they well advertised in other fora if the resulting rule was likely to effect a non-trivial number of articles? For example, on a significant number of occasions, small cadres of editors operating out of WikiProjects have tried to create rules (some of which were added to MoS pages without further authorizing discussion among the larger community. This of course is expressly forbidden by WP:Advice pages and a number of ArbCom rulings. On the other end of the spectrum, we have something like MoS:GENDERID, which is the result of a lot of community negotiation in some of the most massively-attended and assiduously-argued discussions in the history of the project. Some of argued that the resulting rules should have been codified in WP:PAG as a result, but for good or ill, it was placed in the MoS. But while there is some wiggle-room for most provisions in the MoS, there is a fairly absolute consensus at this point that no part of GENDERID is optional--though we continue to have arguments about how to apply it in particular cases. However, most provisions of MoS exist in a grey area between these two extremes. And unfortunately, because there are no handy labels to easily distinguish which are the result of more trivial or robust previous consensus discussion, it is often incumbent upon those arguing over a particular piece of guidance and its application to a given article or set of uses to either accept that they have to make pragmatic arguments for that use case, or else demonstrate that the history of debate for that provision shows previous and broad consensus for a universal approach, or that the particular use case in question has already been addressed. Again, suboptimal, but the reality we are left with after the organic and non-formalized growth of this part of our rules ecosystem.
Second, we can also look to the intrinsic text that was generated by the consensus process described above. Because traditionally (and less so as time went on, but still to some extent) we intentionally left a lot of flex in MoS wording itself, to account for previous disagreement and to allow editors to use their best sense of what was required for the needs of the individual article or other namespace. Rules creep has gobbled up the edges of much of that flexibility, but many sections of the MoS still have vague or expressly permissive language for those purposes. Personally, I think we benefit from keeping those provisions lean for those very pragmatic reasons, but it is a natural consequence of a bureaucratic apparatus such as we work with here that more and more rules will accrue over time. Especially as it has turned out that there is no principle of grammar, formatting, or presentation to trivial or inane that the Wikipedia community at large has proven unable to generate at least two camps of deeply committed proponents willing to regularly and disruptively go to war across hundreds or even thousands of articles/talk pages to enforce their preferred version.
All of which is to say, the MoS is clearly very prescriptive with respect to many considerations, but the degree to which a given prescription (or proscription) is permissive or mandatory is highly variable, and often nothing short of research into and reference back to substantially aged discussions can settle just how strong a given requirement is. And even then, everything is of course subject to WP:CCC. Only the most well known and at one time divisive subjects, like GENDERID, are so absolute that everyone is expected to comport with them in the vast majority of use cases, with failure to do so often being considered highly disruptive. But as time goes on, we have more and more of this body of uniform rules. A better system would re-categorize all style guidance into levels of permissibility in a system which roughly shadows the levels of weight seen as between information pages, guidelines, and policies, but such a re-conceptualization would be a herculean effort that I just doubt we even have the manpower for, even if we could get the broad community buy-in to support such a massive restructuring. SnowRise let's rap21:56, 3 September 2025 (UTC)[reply]
One thing I think gets lost here is that the process (where was the discussion? Was there a discussion? How many editors? How many experienced editors who haven't been blocked in the intervening years?) is not really as important as whether the policy/guideline/help/whatever page matches what the community wants now. A perfect process, with dozens or hundreds of people, that arrived at the (now) wrong conclusion is not nearly as important as whether the community agrees with that decision today. WhatamIdoing (talk) 03:02, 4 September 2025 (UTC)[reply]
I don't disagree in principle, but even if there is a new established best practice or general unspoken consensus, it's infeasible to allow editors to just assert it as a given; there needs to be a new formal consensus discussion at some level, as otherwise we will just have people insisting upon their own idiosyncratic views about what the "obvious" or "accepted" rule is--assumptions which are subject to every cognitive bias under the sun. In any event, you are touching upon another factor I had meant to list with the other two above: independent of the degree of formal consensus behind a given rule, or the certitude/universality of the wording of the rule itself, one can also point to the uniformity with which it has been applied. More than once I have seen wording in an MoS section, or even a guideline that it turns out was added despite no WP:PROPOSAL (or any substantial WP:CONSENSUS) process, but by the time this is caught years later, the community is willing to give it a free pass and basically endorse it despite these usual required checks. Either because it turned out to be the right utilitarian approach, or disentangling it from established best practice is more trouble than it's worth. All that said, I think the "accepted custom" prong of legitimacy ought to be treated as absolutely the least compelling and reliable factor. Not wholly irrelevant, but definitely to be taken with a grain of salt as arguing for the presumption that a given rule is practical or represents community support, express or tacit. SnowRise let's rap04:48, 4 September 2025 (UTC)[reply]
It's not feasible to have "a new formal consensus discussion" every time a policy or guideline is reworded.
Most policies and guidelines had no WP:PROPOSAL. I wrote PROPOSAL in 2008. Before then, exactly two (2) of the guidelines and zero of the policies had followed that process (WP:MEDRS and WP:MEDMOS). The original process was "slap a tag on it, and see if someone reverts you". After a while, the process usually became "have a small chat on the talk page, then slap a tag on it, and if someone reverts you, point them at the discussion on the talk page when you revert them back". And quite a lot of WP:Naming conventions, and some of the WP:MOS pages, achieved guideline status through the WP:MOVE button. But at this point, 17 years after the PROPOSAL process was adopted (its adoption being the third time that process was fully followed), and after the massive MOS cleanup project coordinated through Wikipedia:WikiProject Manual of Style (which delisted and rewrote a number of pages), I think we can safely say that anything that is still tagged as a policy or guideline is actually accepted as a policy or guideline. WhatamIdoing (talk) 21:54, 4 September 2025 (UTC)[reply]
I think there's some conflation of concepts going on here. With regard to "a new formal consensus discussion", I personally do not see that as typically involving a full formal WP:PROPOSAL process, or anything remotely like it, as a per se matter. At least for inline changes to existing PAGs or MOS pages, in the vast, vast majority of cases, much less is called for. PROPOSAL is for creating new guidelines wholecloth, not for iterative additions or amendments to existing policies. Nevertheless, I consider it a bit of a tautology that no change to a PAG (nor any other express community guidance codified in MoS or an info page) which has proven contentious can be argued to have a clear "community consensus" unless a consensus discussion actually took place, at some level and in some way endorsing a particular proposition. I appreciate that things were quite a bit more free-wheeling once upon a time, and respect your role in codifying some of our early standards on formalizing consensus at the PAG level (I did not know you were the original author of PROPOSAL, which is quite the contribution to the project's mechanics), but as you yourself alluded, we've come quite a long way since those seeds were planted, and today we have a much higher burden for formally adopting a rule. As such, the mere act of being able to point to a rule that just happens to not have been disturbed is never going to be the strongest form of evidence that the community has endorsed that principle (or would, if directly asked). Although I will grant you, the farther back the rule stretches without a formal challenge, or the more central the position of the rule in our most heavily relied-upon policies or processes, the more confident we can be in regarding it as a kind of consensus principle. That said, as to ". . . I think we can safely say that anything that is still tagged as a policy or guideline is actually accepted as a policy or guideline., I'm not sure I'd agree that is likely to be universally true, but let's put that to the side for present purposes. That's still a very different thing from saying "Every bit of verbiage placed within a guideline since it was adopted came about as the result of community consensus." And that's an important distinction when we are talking about the MoS in particular, since MoS changes tend to be for the purpose of ammending or adding to existing sections, rather than creating new ones. SnowRise let's rap00:16, 5 September 2025 (UTC)[reply]
My immediate coarse intuition is, of course, if an editor sees a substantive, questionable change to P&G without explicit consensus, they would be encouraged to yank that material from production at any time?
(If the initial RfC needs my own variation on this theme: I hope other editors are actively motivated to remove any material that can't be assumed to possess a clear prescriptive mandate – i.e. material possibly not reflective of consensus, explicit or otherwise.) Remsense 🌈 论23:59, 5 September 2025 (UTC)[reply]
You should only revert changes that you personally disagree with. It's not exactly that we "encourage" people to revert changes, but if you personally believe that a change is harmful or even probably harmful, then yes, you should probably revert it. If you're only a bit uncertain, it's probably better to take it to the talk page. WhatamIdoing (talk) 02:22, 6 September 2025 (UTC)[reply]
That's what I meant to say—in my mind, one could only discern a change could be against consensus if one directly disagrees with it first. Remsense 🌈 论02:24, 6 September 2025 (UTC)[reply]
I have been reducing my reverts for any editor with a track record of contributions and opting for Talk-first. For many editors reverting is very aggressive and Talk-first often leads to a better outcome. I try to explain reverts for editors who registered, usually "Sorry,...". IP editors with no edit summaries I just revert full stop. Johnjbarton (talk) 02:28, 6 September 2025 (UTC)[reply]
Often the very best move—though, in terms of policy, I would very much prefer and prioritize my disputed additions not being live parts of the document, and I think most experienced editors woudl agree with that too at least in theory. Remsense 🌈 论03:05, 6 September 2025 (UTC)[reply]
Precisely. We're talking about two distinct subjects here. On the one hand, the more abstract question of whether an addition to a PAG or style section has community consensus, whether it is subject to being summarily reverted, and how much the benefit or problem caused by that change either militates for its retention or reversion. And then on the other hand, the more idiosyncratic question of how a given editor feels about how to address a problematic change that arguably could or should be reverted. When you layer the two over one another, you get a broad range of responses from different community members, but they are in principle discrete questions; the "What is this change, and can/should it be reverted?" and "Now that I've made that decision in principle, how do I really want to go about it to maximize the chance of the optimal outcome, not just with respect to the a priori issue, but also while being constructive and collaborative, and also while keeping other project priorities in mind. Now, if we wrap back around to your initial question, and contemplate how much we want policy to encourage reversion in those circumstances, I would say we should at least be making the process relatively painless for them, if the change has proven at all contentious and there was no clear consensus. While WP:BRD is mostly conceptualized in the context of namespace contributions, I would say its even more essential when it comes to the language in guidelines: what is codified and memorialized in those pages should be more conservatively approached and should usually only happen with some degree of consensus discussion. Contributors should be discouraged from being WP:BOLD with PAGS or even the MoS. And if they aren't, we certainly want the standard to be that there is very little noise or drama from and objecting party exercising the R&D part of BRD. But I certainly don't fault anyone who would rather exercise a softer touch. Nobody should feel compelled to actively object if it wouldn't normally be their wont in that situation. SnowRise let's rap07:57, 6 September 2025 (UTC)[reply]
In short, being prescriptive in principle, the state of a P&G page over time (clearly) has greater stakes than that of any one article, and it seems healthy for whatever quasi-WP:OWN feelings editors may have while working on an article (i suppose, in the sense of "let me cook, watchlist voyeurs") should by contrast be wholly absent when in P&G-space. That sounds super obvious, but whatever. Remsense 🌈 论08:10, 6 September 2025 (UTC)[reply]
I agree with what SnowRise says above that it's important to distinguish between "Is this MOS page really a guideline?" (to which the answer is 'yes') and "Does this specific paragraph in this specific MOS page still have community consensus?" (to which the answer is variable, because there are a few bits that probably don't).
But @Remsense, it is possible to treat the policies and guidelines as too much like holy writ. If editors think they can improve them, whether that means making them clearer, less verbose, more reflective of daily practices, more in line with our values and principles, etc., then editors actually should try to do that, and be encouraged to do that. Bold editing of policies and guidelines is officially permitted by policy, and the fact is that a change made today and reverted tomorrow probably has no, or very little, effect on what editors actually do. (Though if you wait long enough, it can become a problem; I now wish I had reverted this dubious addition in 2012.) WhatamIdoing (talk) 22:30, 6 September 2025 (UTC)[reply]
We often have consensus on the wording of policies and guidelines, and we often don't have consensus on applications (one of which applications being, ignore). That's just the nature of the work, and then we have to work it out, in the moment. -- Alanscottwalker (talk) 21:24, 7 September 2025 (UTC)[reply]
I would say that for the most part the MOS should be followed unless there's a compelling reason otherwise; but it can be ignored when a stronger policy-based reason exists. Guidelines in general are not absolute (though they vary in how forcefully they're worded), but in particular even the most forcefully-worded parts of the MOS always lose to WP:NPOV / WP:RS / WP:V when those things come into conflict with it, because those things are core policy and the MOS just governs our, well, style; we're not going to sacrifice NPOV for mere stylistic issues. If there is a consensus on a particular article that we must do something that the MOS forbids in order to preserve NPOV or reflect the sources, then the core policies obviously win - there are very few "you absolutely must do XYZ without exception" from-above policies in Wikipedia, and none of them are part of the MOS. That said, I do think that overriding the MOS on anything of significance would normally be expected to require an argument like that, ie. you need some actual policy-based reason to do so - guidelines are followed unless someone can articulate a policy-based reason otherwise. But once someone has articulated a reasonable policy-based reason why they think other policies are in conflict with the MOS, it's a matter for consensus and discussion on that article, and generally speaking I would expect policies to win out. (Of course, people might disagree over whether there's an actual conflict, but that is something that local consensuses can cover, since it involves how we interpret and apply policies and guidelines in specific cases.) In situations where someone disagrees with following the MOS in a particular article but can't come up with a policy-based reason why (ie. it's basically just disagreement with that part of the MOS), they should probably challenge it directly - the point of the MOS is to give us a consistent style, so you need a better reason to override it than "I just like how this looks better." --Aquillion (talk) 15:58, 18 September 2025 (UTC)[reply]
What is Wikipedia’s official stance on Ai-generated content
What is wikpedia’s stance on showing Ai generated content outside of Examples of Ai generation? Like showing images, text, etc. Also, if oppose, why? And if support, Why? Datawikiperson (talk) 17:02, 2 September 2025 (UTC)[reply]
We are wrestling with it as we speak (there numerous currently open threads on several policy pages and noticeboards). However, the general consensus seems to be opposed. Blueboar (talk) 17:08, 2 September 2025 (UTC)[reply]
AI-generated images are already against policy, except when the image itself is notable, examples of AI generation as you mentioned, and other such edge cases.
AI-generated text is not currently against policy although we desperately need to get our shit together on it, because we have kicked the can down the road about for two and a half year and are now paying the price. It's also something where the general community opinion is at odds with that of the Wikimedia Foundation. Gnomingstuff (talk) 17:36, 2 September 2025 (UTC)[reply]
At its most basic there are two significant viewpoints among editors with regards AI-generated content (by which we almost always mean large-language models (LLMs) that generate textual output and generative Ai models that output images): the first considers all AI-generated content as bad, either because it is AI-generated (the objection is essentially philosophical) or because they believe that AI is incapable of producing content of a sufficient standard. The second viewpoint prefers that all content is evaluated on its own merits with AI-generated bad content treated and dealt with the same way as human-generated bad content, and AI-generated good content treated and dealt with the same way as human-generated good content.
Beyond agreeing that at least some AI-generated content is bad and that adding AI-generated content without any human input is undesirable, there is little common ground between the camps and neither can be said to obviously represent the consensus of the community as a whole. Obviously once you get into any sort of detail it becomes more complicated than this (e.g. even among those that regard all AI-generated content as bad there is disagreement about whether such content that has been reviewed by a human between generation and submission to Wikipedia should be acceptable), indeed one of my bugbears in discussions is a lack of nuance from some (sometimes many) contributors.
It's worth noting though that I am one of the most vocal proponents of the second viewpoint I describe above, while Gnomingstuff's views are closer to the first viewpoint (I don't recall ottomh where they stand with regard human-reviewed AI-generated content). Thryduulf (talk) 00:54, 3 September 2025 (UTC)[reply]
No, the concern about AI is that it will swamp discussions and overwhelm content checking. The view that an infinite number of gnomes will eventually investigate and fix all AI claims and references is naive. There may be no need to take strong action now, and perhaps there never will be. However, if the concerns of the anti-AI crowd are confirmed, it will become necessary to either surrender Wikipedia to those posting walls of text, or to delete waffle without proving to everyone's satisfaction that the waffle is disruptive. Johnuniq (talk) 02:19, 3 September 2025 (UTC)[reply]
This is not the place to remake the same fearmongering arguments you've made in every other place. They haven't convinced anybody who doesn't already agree with you there, and they aren't going to do so here. This is simply about outlining what the very basic positions are. Thryduulf (talk) 03:29, 3 September 2025 (UTC)[reply]
This is the critical point. One can argue all day that theoretically speaking there is no difference between an LLM and a hypothetical user who happens to make up plausible-looking paragraphs cited to sources that don't support them. But the fact is that in reality the LLMs generate orders of magnitude more of these paragraphs than humans do, by volume. Wikipedia functions only as long as volunteer editors can handle the work of fact-checking. Strict policies against LLM use are necessary for editors to handle the flood of misinformation as efficiently as possible. Elestrophe (talk) 08:56, 8 September 2025 (UTC)[reply]
Yup. One ant in my kitchen and ten million ants in my kitchen are two very different problems with very different solutions even if each individual ant is the same as the solo ant. If you see ten million ants in your kitchen, you definitely won't say "well, an ant can be in the house for no particularly concerning reason." CoffeeCrumbs (talk) 06:30, 12 September 2025 (UTC)[reply]
My personal stance is the second in theory but the first in reality: I don't have a philosophical problem with AI-generated text, but the actual stuff that exists right now is mostly crap.
But my real stance is that I don't care which viewpoint the community settles on as long as we just pick one already, and fast. Really, we needed to pick one 2 years ago, and so now we are not only dealing with 2 years' worth of accumulated, largely undetected AI slop, but sending new editors mixed messages when people go aggro at them over what is currently an essay. Gnomingstuff (talk) 04:25, 3 September 2025 (UTC)[reply]
I agree that we need to stop reacting aggressively against newbies. Perhaps a general announcement that, by way of establishing priorities, nobody should be screaming louder about AI slop than they do about poop vandalism?
But: Is it better to make the Wrong™ decision today, or the right one next year? Changing a policy or guideline is difficult these days. Once it becomes holy writ that Thou Shalt Not anything, it takes an enormous amount of effort to get that removed. WhatamIdoing (talk) 03:05, 4 September 2025 (UTC)[reply]
Honestly -- as someone who has complained loudly about undetected vandalism for years -- I think AI slop is now a larger priority than poop vandalism. There's no ClueBot for slop, it's more akin to subtle vandalism.
In many (possibly most, but I don't think all) of the currently ongoing AI-related discussions, doing nothing is the right answer because what is proposed is just a duplication of some existing policy and/or guideline. For example, we can already revert/hat/ignore nonsensical wall-of-text proposals regardless of whether they are AI-generated or not, we don't need anything additional. Thryduulf (talk) 00:36, 5 September 2025 (UTC)[reply]
We don't need new policies for articlespace either:
If the edit is good without needing to be edited, it's improving the encyclopaedia and we'd be shooting ourselves in the foot to get rid of it. This is how wikis work.
If the edit is good but needs polishing, then polish it or tag it for someone else to polish. This is how wikis work.
If the edit is bad then revert it. This is how wikis work.
If you aren't sure, investigate it, discuss it and/or tag it. This is how wikis work.
About three-quarters of the articles currently tagged as possible AI output were tagged by me. You do not have to explain to me how tagging works.
With LLMs, you do actually need to know the source to get a complete sense of what really needs "polish." A lot of the undetected AI writing we have was actually pretty damn obvious as unedited LLM text when originally added to articles in 2023-2024, but people/bots did some minor copyedits without realizing the reason why those copyedits were necessary. Which means they probably didn't check for hallucinations or mismatched references, since the need to wasn't even on their radar. Gnomingstuff (talk) 15:38, 5 September 2025 (UTC)[reply]
The problem is as well, people believing that they can just add this stuff because we don't make it clear that they shouldn't or under what conditions they might be able to. Selfstudier (talk) 17:55, 5 September 2025 (UTC)[reply]
@Gnomingstuff, can you tell me more about With LLMs, you do actually need to know the source to get a complete sense of what really needs "polish"?
If I'm looking at a sentence that says something like "Alice Expert's acclaimed book, The Sun is Very Big, enhanced her significance as an author and gives a fascinating glimpse into the rich history and evolving identity of the Sun, which stands as a vibrant symbol for so many people and cultures around the world[1]", are you saying that I need to read the cited reliable source to figure out what's wrong with the sentence, or are you saying that I need to see the un-copyedited original addition of the sentence?
I'm pretty sure I could cut that purple passage down to Alice Expert wrote a book called The Sun is Very Big[1] without needing to look at any sources. And the more you personally know about the subject matter, the less you would need to do any research to identify hallucinations. WhatamIdoing (talk) 22:43, 6 September 2025 (UTC)[reply]
You need to make sure that Alice Expert actually did write a book by that title, but also that the source it's cited to actually exists and has the same author/publication date/ISBN/URL/etc. as the article says it does, and that the source it's cited to actually mentions the fact that Alice wrote the book. All of these are things you can reasonably expect a human writer to have already done if they've added a cited statement, but with an LLM all bets are off. (Edit: Also that the text isn't a copyvio/overly close paraphrase) Gnomingstuff (talk) 01:14, 7 September 2025 (UTC)[reply]
Can you please stop condescendingly explaining things to me that are obvious?
Obviously all those things need to be done. The tendency, though, is to assume that if a piece of text looks polished and has a citation, then those things already got done. Without an LLM, the only reason a totally fabricated source and nonexistent URL would make it into an article is if the editor was inserting a deliberate hoax. Gnomingstuff (talk) 15:53, 7 September 2025 (UTC)[reply]
Apparently I do need to remind you how to suck eggs, because your comments keep implying that you have forgotten how. If you don't know the user well enough to trust that they are not vandalising the article then you should be checking all those things anyway. LLM use or otherwise is completely irrelevant. Thryduulf (talk) 16:07, 7 September 2025 (UTC)[reply]
I tend to agree with Thryduulf: "Did Alice actually write that book?" is something that has to be checked regardless of whether I think the purple prose came from a human or from an LLM.
There are several options:
I happen to already know that Alice wrote this book, so I might not bother checking the source, or even care if there is one. (Source–text integrity is valuable, but readers rarely read the sources, so it's about 300x as important to get the article text right than to worry about the cited source.)
I happen to already know that Alice writes books like these, even though I haven't heard this specific title before, so I might quickly fix the text and decide to skip checking the source because my time is limited, and I believe that it's highly likely that the facts are correct. "She wrote a book titled ___" is technically an inline citation to the book as a primary source anyway.
I don't know anything about this subject, in which case I'll fix the text and check the source.
I don't know anything about this subject, but I think you are coming from one of the cultures were purple prose is normal, in which case I'll fix the text and probably check the source.
I don't know anything about this subject, but I know and trust you, in which case I'll fix the text, check the source, and report your account as being possibly compromised, because no Wikipedia editor I trust would actually put that kind of purple prose in a live article.
I tend to disagree with Thryduulf. As Gnomingstuff says, there is an assumption that in a regular article, the claims are verified by real sources – people usually don't go to the trouble of making up references to support their unsourced claims. When sourced text is written by a human, the human is aware of what they're doing, and presuming they're editing in good faith, the claims should be verified by the sources, assuming the editor is at least somewhat competent. When the text is LLM-generated, on the other hand, and blindly pasted into the article, that good-faith-human assumption vanishes, because the text was generated by an LLM that doesn't understand what it's writing in the way that a sentient human does.
"Did Alice actually write that book?" should be checked regardless of the source, yes. But we all have limited time and we can AGF that most editors with a modicum of experience are writing articles correctly, unless we have reasonable suspicion otherwise. (Templates like {{fv}} exist for a reason, after all). But we can't AGF an LLM, and since they hallucinate so much, everything needs to be in practice scrutinized whereas most human text needs to only be theoretically scrutinized. This is why LLM editing is a bad idea, obviously.
I also agree with Gnomingstuff that Thryduulf's hostile tone to other editors in these LLM discussions is a little out of hand. God knows I get testy myself, but I don't think telling editors that I do need to remind you how to suck eggs, because your comments keep implying that you have forgotten how ([10]) or dismissing other editors' opinions as rabid and then doubling down on the childish insult ([11]) is exemplary conduct, especially from an administrator. Cremastra (talk·contribs) 18:13, 7 September 2025 (UTC)[reply]
I do try and keep my cool, but when I have to point out the same basic factual errors, assumptions of bad faith, misinformation, reading comprehension failures from the same editors multiple times it gets to the point that it's rather difficult to assume competence from one's fellow editors. Thryduulf (talk) 19:00, 7 September 2025 (UTC)[reply]
Please try to engage with the discussion. Cremastra's comment is pointing out that there can be no good-faith assumption regarding AI text. Sure, we assume that a naive copy-paste of AI text is done by a good-faith person, but such an action fails the competence test. The real question is whether there are sufficient editors able to spend hours researching AI references. Johnuniq (talk) 02:35, 8 September 2025 (UTC)[reply]
Repeatedly pointing out how and why your arguments are factually incorrect is engaging with the discussion. AI use is not, on its own, evidence of faith (good or bad) because an AI can be used in good faith and an AI can be used in bad faith. My point in this part of the discussion is that we don't need rules specific to AI when we already have rules that cover both AI and humans (without it mattering which it is). WAID explains it well - if you don't know a user and/or the source well enough to know whether an edit is likely to be correct then you should be checking to see if it is, regardless of what tool they did or did not use to make the edit. Thryduulf (talk) 04:03, 8 September 2025 (UTC)[reply]
It is not possible to partake in a discussion with people who consistently make arguments that are factually incorrect and present misinformation as truth without describing such arguments as wrong. Thryduulf (talk) 09:47, 8 September 2025 (UTC)[reply]
I mean, if we're talking about "factually incorrect arguments" and "reading comprehension failures," I never said that people who use AI are automatically editing in bad-faith. Nor do I approach people using AI under the assumption that they're editing in bad faith, because in my experience that usually isn't true.
I don't know what else to say about the res of this that hasn't already been said, repeatedly, by others. Yes, people should be checking every edit. In practice, there are over 1 billion of those. It is not feasible for every editor to check 1 billion diffs; triage must be done. So, it makes sense to prioritize edits made with the assistance of tools that are known to fabricate information or sourcing.
As far as it being more important for a statement to be right than to be correctly attributed to the source, that may be your opinion, but it's the near-exact opposite of WP:V (and only "near"-exact because they got rid of the "verifiability, not truth" wording). Gnomingstuff (talk) 15:46, 8 September 2025 (UTC)[reply]
{outdent}
It's true, Gnomingstuff, that you never said that people who use AI are automatically editing in bad-faith (as far as I know). But:
(a) you are not the only person who talks about AI users, and some of them seem to be struggling with the concept. So, starting with the first sentence of WP:AGF, let's analyze this:
Assuming good faith (AGF) means assuming that people are not deliberately trying to hurt Wikipedia, even when their actions are harmful.
Does AI use, especially in discussions, hurt Wikipedia? Maybe it does. For example, maybe it's very irritating, so I become reluctant to read discussions. Maybe it is verbose, and long comments (like this one!) get banned. But other things also hurt Wikipedia, like not pointing out a factual error in the article because you're not sure how to explain it in English. Using AI in a discussion might be a lesser-of-two-evils situation.
Does the use of AI mean that the editor is deliberately trying to hurt Wikipedia? No (or at least so rarely that it's probably not worth mentioning). Therefore, using AI is not bad faith.
(b) why are we talking about good-faith editing at all? I think your point about triage must be done is the key. Stop worrying about whether it's good faith, bad faith, or agnostic. Start asking yourself: How should I prioritize reading and responding? Mightn't it be more important too look at tools that reduce duplication of effort (ten people check this edit, but nobody checks the next edit)?
Against. There is a fringe of AI supporters and a fringe of knee-jerk reactionaries but most editors are generally against AI's usage and highly skeptical of it. Cremastra (talk·contribs) 06:42, 3 September 2025 (UTC)[reply]
I have a window somewhere with another dozen discussions to add to that table, plus all the ones that happened since then. I'd love it if someone else would work on that. WhatamIdoing (talk) 03:07, 4 September 2025 (UTC)[reply]
I wish there was an easier way to add things to tables in the project space (using the source editor to do that is a pain imo). Maybe dump the list of links on the talk page and when editors are bored, they can add them. Some1 (talk) 18:02, 5 September 2025 (UTC)[reply]
Thanks, I didn't realize people could edit the Wikipedia namespace with Visual editor; I only see the "Edit source" (and not the "Edit") button at the top of these Wikipedia:[...] pages. Good to know! Some1 (talk) 00:13, 7 September 2025 (UTC)[reply]
When discussion has ended, remove this tag and it will be removed from the lists. If this page is on additional lists, they will be noted below.
Should a bot be used to fix linter errors and fix Vector 2022 dark mode on old Articles for Deletion subpages? 16:46, 9 September 2025 (UTC)
Please read this RfC before commenting here. I (Matrix) am proposing a bot to fix dark mode on old AfDs, please read the proposal at the BRFA and comment here whether you support or oppose it.
@Pppery: Chaos? Firstly, unlike the above RfC which made millions of edits, this is limited to the WP namespace, so no "user talk was edited" notifications will go off. Secondly, there's a reason the bot flag was created, which was to help you hide stuff in watchlists and stuff like that. —Matrixping mewhen u reply (t? - c) 19:13, 8 September 2025 (UTC)[reply]
(I'm copying this from the BRFA) "The question isn't the number of people who use dark mode, it's the intersection of the number of people who use dark mode and who visit old AfDs, and the latter set is pretty small in the first place. And you surely know already that large bot tasks inevitably cause people to complain as they are happening." (from Pppery) —Matrixping mewhen u reply (t? - c) 19:17, 8 September 2025 (UTC)[reply]
@Pppery: People scrolling through AfD archives are more likely to have dark mode on, because they are likely power users and power users want all the new features. Besides, we're fixing lint errors along the way. —Matrixping mewhen u reply (t? - c) 19:34, 8 September 2025 (UTC)[reply]
I'm someone who is often regarded as a "power user". I use Monobook skin in light mode and, when I use the source editor (roughly 50% of my edits) I use the 2010 editor. Most "power users" will use whatever tool is the most powerful which is not necessarily the most recent - indeed in many cases the most recent tool is often less powerful because it has been simplified for the benefit of those who are not power users. Whether someone prefers light or dark mode is likely something that is completely independent of whether they're a power user or not. Thryduulf (talk) 01:02, 9 September 2025 (UTC)[reply]
And many other power users will, like me, keep using what they're used to and already have set up how they like it if they don't need any of the new features, instead of changing and having to relearn how to do all the things in the new interface. Anomie⚔13:52, 9 September 2025 (UTC)[reply]
Perhaps, but turning on the bot flag when there's a large activity in the spaces we edit means we're not only missing less frequent bot edits we might want to see, but also are missing recent living creature edits that were immediately followed by a bot edit, as the watchlist system will sometimes not display the human edit when that happens. As such, it's best to avoid the mass edits unless they are necessary. -- Nat Gertler (talk) 19:44, 8 September 2025 (UTC)[reply]
@Izno: we're also fixing lint errors in this task as well, which has no workaround except fixing. And while we're fixing the lint error with color: inherit, we might as well convert the background color to the new dark mode one. —Matrixping mewhen u reply (t? - c) 19:36, 8 September 2025 (UTC)[reply]
The relevant workaround being the one that targets [style~=background]? I'm the one who suggested that bit of CSS one fateful day several years ago to a relevant engineer as the dark mode effort was beginning to ramp up. I don't see trying to remove the need for that CSS as useful (at this time, perhaps) as there are many many other places that rely on it besides 500k pages worth of archives.
@Izno: we need to move away from relying on that CSS rule, which is why I am suggesting this. We don't need to remove the rule, but just reduce reliance on it, as it is quite crude. This is one step at that. —Matrixping mewhen u reply (t? - c) 22:48, 8 September 2025 (UTC)[reply]
Oppose per Pppery and Nat Gertler. Editing archives should only ever be done when the edit makes a substantial improvement to the project in some way. Making nearly half a million edits just so that a bit of form text that appears on >90% of AfDs is slightly more visible to the tiny number of people who read old AfDs while using dark mode is so far below that bar it's ridiculous. Even fixing lint errors fails to reach the bar most of the time and this is significantly less useful than that. Thryduulf (talk) 20:46, 8 September 2025 (UTC)[reply]
A lint error that only appears in dark mode? You really need to do better to explain why this should be "fixed" and why it is worth doing more than 50 edits. —Kusma (talk) 22:19, 8 September 2025 (UTC)[reply]
@Matrix, if this is a lint error worth fixing then there will be consensus for the lint error fixing bots to fix it. You will also note that I said Even fixing lint errors fails to reach the bar [where editing archive pages is beneficial to the project] most of the time and this lint error is especially low value. Thryduulf (talk) 00:57, 9 September 2025 (UTC)[reply]
@Pppery: Considering this is a very technical topic it is necessary to explain a bit more - that is not bludgeoning and is actually constructive towards consensus. I only responded to like 3 comments anyway, and I don't expect to change anyone's view if they are opposed. See Wikipedia:Encourage full discussions. —Matrixping mewhen u reply (t? - c) 16:23, 9 September 2025 (UTC)[reply]
Support I don't use dark mode myself but looking at the before and after examples linked on the BFRA, it improves things for those using dark mode. Also, doesn't hurt things for anyone not using dark mode, so don't see any reasons not to. If someone is willing to do those changes then why not. -- WOSlinker (talk) 21:28, 8 September 2025 (UTC)[reply]
Support per WOSlinker and what Primefac said on the BRFA. It doesn't really hurt anyone, those concerned about watchlist spam can just configure their settings to ignore bot edits. Tenshi! (Talk page) 22:13, 8 September 2025 (UTC)[reply]
er, what is the improvement being made? It looks pretty much the same to me (at least in Monobook Dark mode) so oppose unless it is clarified what the point is. —Kusma (talk) 22:15, 8 September 2025 (UTC)[reply]
Support: I don't personally think linter errors are a huge priority, but that doesn't mean others should be prevented from fixing them. The set of people who have old AfDs on their watchlist for some reason and could possibly be inconvenienced is probably as small, if not smaller, than the set of people who view old AfDs in dark mode. Gnomingstuff (talk) 23:22, 8 September 2025 (UTC)[reply]
I am in generally in support, but if you're going to make this many edits I'd like to see a deeper investigation of what other kinds of issues can be fixed at the same time. Also seems like it would be more worthwhile to replace it with a template so we don't need to make a second pass if other issues are discovered in the future. Legoktm (talk) 00:08, 9 September 2025 (UTC)[reply]
@Legoktm: that would be a good idea, but if we did that we would also need to do the same thing for all XfD discussions, plus all RMs, most {{atop}}s, etc. Not to mention the massive technical issue of fixing nearly every single anti-vandalism tool. I don't think that's worth it. —Matrixping mewhen u reply (t? - c) 16:25, 9 September 2025 (UTC)[reply]
I don't think we need to decide the fate of literally everything now just to improve AfD archives, it can be an iterative process. I also don't see why anti-vandalism tools need to be fixed, why would they even care about this formatting change? Legoktm (talk) 17:55, 9 September 2025 (UTC)[reply]
If we use a template now, don't we have to use the template in the future? I feel it would be inconsistent to sometimes use a template and sometimes subst stuff. —Matrixping mewhen u reply (t? - c) 18:27, 9 September 2025 (UTC)[reply]
I was going to make this an RfC from the start to avoid LOCALCONSENSUS issues, but forgot. Also as proposer and the person who made the BRFA, I support obviously. —Matrixping mewhen u reply (t? - c) 16:46, 9 September 2025 (UTC)[reply]
Support. I really don't see any downsides to this. But, as someone who regularly reads old AfDs, sometimes uses dark mode, and generally appreciates that linter issues can be important in the long run, I think there would be significant benefits. Toadspike[Talk]06:54, 10 September 2025 (UTC)[reply]
Oppose: Similar to WP:RAGPICKING: we all have better things to do than make miniscule formating tweaks to old pages for a minority of users. If hundreds of editors were coming forward and saying "I use dark mode and this is a real pain", then I'd support. But I'm not seeing that. I honestly don't understand what a lint error is, but this one seems to be pretty minor (replacing standard inline CSS with something complicated). Cremastra (talk·contribs) 20:21, 10 September 2025 (UTC)[reply]
Full Support: Accessibility improvements should never rejected on the basis of "it inconveniences my watchlist" or "I don't use this feature", it should pass or fail on the merits and benefits of the task proposed and the proof of the task will address the issue as intended with minimal to no error rate if run. To those complaining about "well, it don't look broken in light mode", this task isn't for fixing something in light mode and will not affect your light mode viewing, this is for fixing a glaring problem in dark mode that makes viewing AFDs in dark mode problematic. The claims of "well, I don't use dark mode, don't run this task" are an injustice to users who do use dark mode who have to endure being blinded on AFD pages from these sections not displaying as they should. If Wikipedia offers different viewing modes, all pages should work and display correctly in all modes.To highlight the proposed change in a visual manner so that there's no question what this task is changing, This -> https://i.imgur.com/Fch83DD.png is an AFD page in dark mode with no changes and is a prime example of this error. The page should NOT be mostly white in dark mode, it should be uniformly dark and comfortable to view without feeling like you are staring at an approaching car's highbeams at night. After this task runs, it would look like this -> https://i.imgur.com/Gw40Qfc.png for dark mode users and behave as it should. The suggestions of "just use light mode, there's no issues here" are as obnoxious as me stating to you "Dark mode is only a few clicks away, why aren't you using it as it's easier on the eyes"?... We both know we have reasons for picking light mode or dark mode as our mode of choice, and we just want pages to display correctly as much as you do with as minimal bother to you as possible. This is a small step in the equal display direction.Additionally, ditto WOSlinker, Primefac, and Legotkm's comments about can we fix anything else in this run to minimize the AFD pitchforks, and why isn't this a template we transcribe? Seems problematic that it isn't due to standard "woe is my watchlist" kerfuffle whenever corrective tasks regarding AFDs are mentioned. Zinnober9 (talk) 21:28, 10 September 2025 (UTC)[reply]
Support per Zinnober9. Further to Legoktm's point, I would support adding __NOINDEX__ to all AFDs while we are at it. We discovered that our attempt to do this site-wide is not working last December, but we didn't actually come up with a plan to fix it. I think the idea of transcluding a template (maybe just add {{AFD help}} where it is not already present?) is a great one, so we can easily make updates if needed in the future. Don't want to spend time on this? You don't have to code the bot or worry about what it will do. HouseBlaster (talk • he/they)01:29, 11 September 2025 (UTC)[reply]
In case people wonder why robots.txt does not work, from Google themselves: Don't use a robots.txt file as a means to hide your web pages... If other pages point to your page with descriptive text, Google could still index the URL without visiting the page.– robertsky (talk) 03:57, 11 September 2025 (UTC)[reply]
Support although it should be noted that the only thing that needs to happen is "unblending" i.e. figuring out which color mixed with white in which alpha amount results in the resulting color. These are very minor but important changes to improve legibility in dark mode. Aasim (話す) 21:00, 11 September 2025 (UTC)[reply]
Replacing with a template?
Creating a separate discussion, since a lot of supports seem to be stating that I should replace the whole thing with a template, rather than just changing the CSS values. Any input is appreciated —Matrixping mewhen u reply (t? - c) 17:08, 11 September 2025 (UTC)[reply]
Neutral as original proposer. I don't have any strong views on this, and am willing to do whatever the community's view on this is. —Matrixping mewhen u reply (t? - c) 17:08, 11 September 2025 (UTC)[reply]
Ok, no one replied to this; there are a few other tasks that can be done on the journey, what's the consensus on doing those as well?
"un-subst" the template, so that future edits can be made at once, rather than on all ~495K pages
add NOINDEX to prevent indexing by search engines (because apparently robots.txt doesn't work)
Support unsubst (so we don't have to do this ever again) and support NOINDEX (while we can argue about the efficacy of dark mode fixes, I hope we can agree that NOINDEXing discussions, including those about BLPs, is a worthwhile pursuit). Probably a better idea to just unsubst and then do the dark mode and NOINDEX fixes in the unsubsted template. HouseBlaster (talk • he/they)20:47, 18 September 2025 (UTC)[reply]
Support both as generally good ideas. I can see no reason a boilerplate header/footer that could foreseeably need updating should be substed every time, and these pages do not need to be indexed. Toadspike[Talk]20:52, 18 September 2025 (UTC)[reply]
Support switching to the template in general, I don't have the relevant context on NOINDEX so I'll abstain from commenting on that. In general I disagree with Pppery that doing some cleanup isn't worth it just because the task is significantly large (I appreciate people who are willing to take on such gargantuan tasks!). Legoktm (talk) 00:41, 19 September 2025 (UTC)[reply]
I Support replacing the boilerplate with a template after a sufficient set of demonstration edits on AfDs from many different years. I have found while editing (far too many) AfD and similar pages to fix Linter errors that there are sometimes subtle variants on these bits of text that one presumes would be identical. Also, the boilerplate text sometimes gets edited after it is placed. It might take a few runs to find the variants, and a bot task might only be able to handle 90+% instead of 99+% of them. Ideally, they won't contain elements that need different template variants to replace them. – Jonesey95 (talk) 21:12, 18 September 2025 (UTC)[reply]
So are you saying that you support the unsubst that would eliminate future needs to updating AFD pages directly whenever these boilerplates need an update in future years? Or are you rejecting any and all bot tasks on any AFD page? Please clarify your ambiguous statement. Zinnober9 (talk) 22:19, 18 September 2025 (UTC)[reply]
I don't see the ambiguity here; but to restate my position, I reject any and all bot tasks that would require editing all hundreds of thousands of AfDs (or pretty much hundreds of thousands of pages of any kind as a one-time run; note I also opposed the reflist bot above). * Pppery *it has begun...04:20, 19 September 2025 (UTC)[reply]
Skimming through some very old discussion archives, I've come across a few mentions that now go against WP:Don't worry about performance and others that are similar to what Thryduulf mentions below in saying opposed to boilerplates not being substed going forwards because care will have to be taken to ensure that changes don't state or imply things that were not true at the time of old AfDs. There may be other discussions I haven't found. Anomie⚔02:21, 19 September 2025 (UTC)[reply]
Personally, so far I'm leaning towards an oppose on the unsubsted template idea based on the "historical record" point. I'm not much caring about fixing versus not-fixing the inline CSS in the archives, since I doubt both that many will care that much about old AfDs while not being able to work around the possible contrast issue and that many will be paying enough attention to the old AfDs that a bot going through them actually matters (as long as we don't get another MalnadachBot situation). Anomie⚔02:21, 19 September 2025 (UTC)[reply]
I continue to oppose these essentially cosmetic changes to old AfD pages because the value of them is multiple orders of magnitude lower than the disruption the bot will cause (and regard this discussion following the extensive objections above to be rather tone deaf at best). I don't necessary oppose all future changes to old AfD pages, because I don't know what those changes will be, but will oppose any others that don't provide benefit to the project above and beyond the disruption. I'm weakly opposed to boilerplates not being substed going forwards because care will have to be taken to ensure that changes don't state or imply things that were not true at the time of old AfDs. For example if a new rule required everyone who had contributed to the article being discussed to explicitly disclose that, and this was added to the boilerplate, it would be misleading for that to appear on discussions from before the rule was introduced. Thryduulf (talk) 22:33, 18 September 2025 (UTC)[reply]
I do not support replacing <spanstyle="color:red;">'''Please do not modify it.'''</span> with a template. There isn't much value in trying to make this particular message more legible, and with banner blindness, most people will never pay any attention to it.
I am more ambivalent about changes to specify the background colour, whether that is by introducing a template, or changing the hardcoding. In principle I think it is a good idea to make all pages follow dark mode standards. But I understand that churn to so many pages can be unappreciated by those most involved in the articles for deletion process. The gentler approach is to just continue with new discussions supporting dark mode, and at some point in the future, when the discussions supporting dark mode are the large majority, consider if a change should be made then. isaacl (talk) 23:28, 18 September 2025 (UTC)[reply]
Support transclusions per Jonesey95. Substituting these has never made sense to me, and doubly so in regards to the ubiquitous AFD pitchforking. If someone knows why they were substituted, then I'm open to considering the merits of that reasoning. But converting to transclusion would reduce the future bother to the Afd community from the known knowns at hand so far in this AFC. I agree that variants (if any) should be identified, and any variants' adjustments retained. I'm Indifferent on the Noindexing. I don't have a grasp on the ins and outs of that at this point to have a strong vote, but I don't object. Overall I think we all agree that the AFDs should be left alone as much as possible, but how or to what point looks to be the meat of this discussion. Zinnober9 (talk) 00:13, 19 September 2025 (UTC)[reply]
Amending the global rights policy regarding temporary account IP access
Various global groups, e.g. global rollback, global abuse filter helper, steward, abuse filter maintainer, and ombuds, have the technical ability to view temporary account IP addresses. This is in addition to administrators and temporary account IP viewers.
I'm here to raise the following question:
Should the global rights policy be amended to explicitly allow or prohibit the use of global rights to access temporary account IP addresses?
The holders of these global rights have the need in their work on the global level though. If anything the language in our local policy may be refine to discourage the use unless necessary locally. It is already there but in bits and pieces. – robertsky (talk) 04:01, 11 September 2025 (UTC)[reply]
Anybody who has it globally already fits the spirit of demonstrated need guidelines. GRs, GSes, Stewards and CUs of other wikis are the typically the ones who have this right and it would be rather short-sighted to assert that they do not have a demonstrated need for WP:TAIV. Sohom (talk) 12:57, 11 September 2025 (UTC)[reply]
We don't grant the right automatically to editors with equivalent rights on en-wiki. And I disagree every global userright has a demonstrated need on en-wiki. A global sysop, for example, has no need to use any of their tools here, let alone one that provides access to information the WMF has deemed private. voorts (talk/contributions) 13:01, 11 September 2025 (UTC)[reply]
Cross-wiki LTAs come to mind, if they cannot very the TA is the same IP underlying here, how will they mark a page for deletion? (note not deletion, because they cannot use their rights here) Sohom (talk) 13:09, 11 September 2025 (UTC)[reply]
It seems like the question is: Should global users, that already have global access to view temporary accounts, be allowed to use this permission here? - in which case, yes - they should. Accounts, including temporary accounts, are global - making these users go through a paperwork exercise to get a local group for this is excessive. — xaosfluxTalk13:08, 11 September 2025 (UTC)[reply]
Note, the largest "outside" users here are the global rollbackers and the global temp viewers (which are mostly checkusers/oversighters from other projects). — xaosfluxTalk13:22, 11 September 2025 (UTC)[reply]
Those are good examples. Maybe giving concrete examples would help people out. For example:
A WP:Global rollbacker is a person who does anti-vandalism work across wikis. Sometimes that work will require (e.g.,) being able to see the IP address of Wikipedia:Temporary accounts (basically logged-out/IP editors, except with their IP addresses no longer being permanently listed in plain text in the article's history page). If a global rollbacker is undoing a bunch of cross-wiki vandalism by a temp account/IP editor, do we want them to:
have access to the IP information, so they can find and revert vandalism here, too, or
skip the English Wikipedia, because we can do everything ourselves and don't want their help.
We should not limit IP viewing by global rights holders at the moment. IPs are currently open to the world, but the plan is to hide them from many, many people. Let's not overshoot by making cross-wiki vandal fighting harder without actual evidence that the new restrictions are insufficient. —Kusma (talk) 20:31, 11 September 2025 (UTC)[reply]
Global rights holders should be allowed to view TA IPs if they have the technical ability to do so. Everyone with such a userright has a "demonstrated need". By the way, do any of those groups have "checkuser-temporary-account-auto-reveal"? That userright would make it impossible for us to disallow them from viewing TA IPs without a global RfC/change. Toadspike[Talk]19:49, 16 September 2025 (UTC)[reply]
Thanks. In that case this discussion is moot, as there is literally no way we prohibit editors using that tool here other than 1. blocking them from enwiki (though I'm not even sure that would work? I think you can still see RecentChanges when blocked etc.) or 2. amending the userrights to remove autoreveal. We also cannot grant autoreveal via the PERM process, so there's no way for individual global rights holders to "rectify" any discrepancy except by RfA. Anyhow, I stand by my position that their use of these userrights on enwiki is okay without a local perm grant. Toadspike[Talk]13:23, 17 September 2025 (UTC)[reply]
Request for feedback on proposed policies regarding the use of banners and logos for advocacy purposes
Informed by research conducted earlier this year, I have proposed some draft policies that would affect the procedures communities use to engage in advocacy using banners and logos. The proposals include a new policy on the use of Wikimedia sites for advocacy purposes, as well as additions to the CentralNotice usage guidelines and to the process for requesting wiki configuration changes. You can review the policies and provide feedback through October 9 at Meta-Wiki's Wikimedia Foundation/Legal/Update to banner and logo policies. Thank you!
DownBeat critic Carlo Wolff describes the album as "contemporary chamber music of power and persuasion, that joins its musicians in a quest for serenity". AllMusic critic Thom Jurek referred to it as "sophisticated and spiritually resonant". Jazz Journal critic Simon Adams stated "It's often dangerous to over-praise a set, but in its quiet, understated way, I would call this album faultless. Modern jazz chamber music at its finest." Jazzwise critic John Fordham states "Drifting may remind you of a dream, or an embrace, or a preoccupied woodland wander a lot more than a wild bop-blasting night in a jazz club, but that's what the unique Mette Henriette is all about."
Note that Carlo Wolff and John Fordham are wikilinked, while Thom Jurek and Simon Adams are not. This seems odd.
So, I'm wondering if there's been discussion of this, either here or elsewhere, with some consensus.
The MOS:LINK article doesn't seem to be dispositive, saying that we should wikilink Relevant connections to the subject of another article that help readers understand the article more fully - I'm unconvinced that linking to AllMusic or Carlo Wolff for example does much to help the reader understand a particular recording. OTOH, it also says to wikilink Proper names that are likely to be unfamiliar to readers. which argues for linking all of the critics' names. Mr. Swordfish (talk) 15:33, 13 September 2025 (UTC)[reply]
If they have articles they should be linked. If they appear notable but lack an article they may be red linked. If they do not appear notable and lack an article they should not be linked. This is not limited to music critics in any way, just how we generally deal with linking people. Horse Eye's Back (talk) 15:41, 13 September 2025 (UTC)[reply]
Ok. Thanks. I recently created a page for Michael G. Nastos and was wondering if I should wikilink every mention of his reviews. Your reply indicates that this should be done, however there are ten pages of google results that would need to be changed. Is there a script for doing this? I'm not eager to do it all by hand. Mr. Swordfish (talk) 16:38, 13 September 2025 (UTC)[reply]
I don't know of a script to do it, but it doesn't need to be done immediately or all at once. You could do a few at a time. Better to use an insource search on wikipedia (results) than google. His name is already wikilinked in a few of the articles. Schazjmd(talk)16:57, 13 September 2025 (UTC)[reply]
IMO its a WP:NODEADLINE situation, the thousand edits can either be made by you right here right now (scripte assisted or otherwise) or they can be made one at a time by dozens or hundreds of editors over the coming years or something in between. Any way is good and the important thing for me is that the article was created. Horse Eye's Back (talk) 17:01, 13 September 2025 (UTC)[reply]
Directing new users to essays on the top of policy and guideline pages
I see Template:Simple has recently been placed at the top of some policy and guideline pages. Are we sure we want to direct new users to unvetted info pages off the bat like this.... that in my view are leading them to the wrong type of pages in some cases. For example at Wikipedia:Content assessment we link a readers' FAQ page Help:Assessing article quality that is designed for non-editing readers. At Wikipedia:Deletion policy a page about rationale and how to go about the process we link Wikipedia:Why was the page I created deleted? a page about what you can do about a deleted page. Not sure if these links have been well thought out. Wondering if we should have a chat before this is added to more policy and guideline pages? Linking simpler help pages from long-winded help pages make sense... I'm just not sure linking these types of pages from policies and guidelines are appropriate in the fashion that they're presented at the top of the page as if these linked pages have been vetted by the community makes sense. Moxy🍁22:31, 13 September 2025 (UTC)[reply]
Not sure merging simplified essays into policies and guidelines pages would be beneficial or pass muster. My main concern is are we and should we direct new users to loosely related essay pages from policy and guideline pages off the bat that currently stand out in big bold letters.Moxy🍁23:09, 13 September 2025 (UTC)[reply]
I've not looked at any of the examples yet, but really nobody should be adding prominent links to the top of (especially fundamental) policy pages without at least discussing it first. I don't know that it needs to be a full-on consensus discussion unless there are substantive objections, but there needs to be at least some agreement from talk page watchers that the other page is relevant, appropriate and helpful. Thryduulf (talk) 23:32, 13 September 2025 (UTC)[reply]
I don't love this, but I think this is probably not a bad thing, overall.
First, before anyone panics, this is only on about two dozen pages, and I think that it's only on two official policies:
The pages it points to are generally community favorites, and there is no reason to believe that any of these links were snuck on to the pages without anybody noticing. And frankly, in the case of pages like Help:Table (5754 words "readable prose size", except most of it is not readable by ordinary humans), most editors actually should be looking at a much simplified page. WhatamIdoing (talk) 02:11, 14 September 2025 (UTC)[reply]
I read your argument as "these linked pages are de-facto approved pages". Under that condition, of course it is fine. Maybe these simple pages should be the main pages and the current main pages need converted to specialized instructions? Johnjbarton (talk) 02:30, 14 September 2025 (UTC)[reply]
We can't really "replace" the pages. They aren't interchangeable. For example, Wikipedia:Inline citation exists to explain what an inline citation is and isn't. WP:REFB exists to help newbies figure out how to format the most popular kind. If you moved REFB at the name "Inline citation", we'd just have to create another page that explains that ref tags aren't the only kind of inline citation ...and a newbie would still end up at that page when they really just need something that says "copy and paste this wikitext", and we'd get another note at the top saying that if you're not really looking for details, then there's a simpler instruction page that you might want to look at instead. WhatamIdoing (talk) 04:16, 14 September 2025 (UTC)[reply]
This is not a good template idea, agree with Johnjbarton. Our policies and guidelines are, when not simple, not so for a reason. We should not give alternative wording official sanction unless it has this. Simultaneously, if there is an obvious way to simplify the policies and guidelines, it should be done on the actual pages. Perhaps we might link to essays that oversimplify the relevant pages, which could have some use for new users who want the basics that won't land them in trouble, but these should clearly be marked as oversimplifications. CMD (talk) 02:51, 14 September 2025 (UTC)[reply]
Relative to most newbies' needs, do you think that WP:REFB should be labeled "an oversimplified version" of anything? I think "a simplified version" is a fairer description, though "Are you new here? Start with WP:REFB" would work for me. WhatamIdoing (talk) 04:20, 14 September 2025 (UTC)[reply]
You said these should clearly be marked as oversimplifications. But you don't want us to label a link to REFB as being an oversimplification, because calling REFB an oversimplification would be a misleading lie. These statements are superficially self-contradictory, but I think you're right.
I think we have two separate questions to answer:
Do we want to have links/hatnotes/banners/templates that direct inexperienced editors away from complicated pages, towards simpler/more relevant pages?
If so, how should we describe those links? You dislike the "simplified version" language (for understandable reasons). "Oversimplified" is IMO even worse. Maybe something like "If you're new to editing Wikipedia, you may want to start at _____" would be better.
The statements are not contradictory. The first statement was a general one premised on the good faith assumption that the items under discussion being presented as simplified versions are simplified versions. The second statement relates to a specific example raised after that first statement where the item presented as a summary was not a summary but rather a general guide of a related topic. CMD (talk) 16:19, 15 September 2025 (UTC)[reply]
Just since I was pinged, yes, I do disagree with Favi doing this, but since I did not see much in the way of reverts, and they're not terrible additions, I have mostly left them be. Primefac (talk) 17:32, 14 September 2025 (UTC)[reply]
By the way, we do have a mechanism to differentiate between a random essay and a broadly accepted consensus supplement for policy/guideline pages - WP:SUPPLEMENTAL with the pages that are broadly agreed upon by the community being tagged with it and are part of Category:Wikipedia supplemental pages.
So maybe the question is whether any how-to pages that are linked at the very top of a policy guide using the {{Simple}} template should also mandatorily have been evaluated to qualify similarly for supplemental status (over just being a regular info/how-to page), since that seems to be kind of the bar for such articles that are tagged with {{Supplement}} and linked at the policy section, e.g. WP:LOWPROFILE supplement being the supplement to WP:BLP - WP:NPF - Non-public figure policy - the supplement has broad consensus and is de-facto policy on how we assess whether someone qualifies as public figure or not. Raladic (talk) 02:29, 19 September 2025 (UTC)[reply]
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.
A large amount of Wikipedia users share their full names, images, and places of work and study on their Userpages. I find this unacceptable, not only are you putting yourself in danger you are also putting others at risk if you share info about your affiliates (One user page included a photo of the user's child). It is incredibly easy to target these people and worse when occurring on Wikipedia because of our handy Page History. Please see WP:AMDB if you need an example as to why this may be harmful. Rules need to be established as to what is allowed to be shared.
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.
Are semi-automated edits to improve MOS:CURLY compliance okay with the community?
I'm working on a tool called WikiClicky that performs various single-character edits to improve Wikipedia articles. I have established community consensus that the grammar-correction features I've added are okay. What would the community say about edits from this tool that only serve to improve an article's compliance with MOS:CURLY? GrinningIodize (talk) 21:42, 14 September 2025 (UTC)[reply]
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.
For accounts that were created before the deployment of the newcomer home page, the target destination when clicking on your user name on the top right is your user page. The WMF decided that to repurpose the link to access the newcomer home page, and your user page can be accessed from there. The behaviour can be configured on the preferences page: Preferences → User profile → Newcomer editor features → Display newcomer homepage. However disabling it also disables your homepage. isaacl (talk) 00:08, 16 September 2025 (UTC)[reply]
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.
When discussion has ended, remove this tag and it will be removed from the list. If this page is on additional lists, they will be noted below.
According to the Olympstats blog, one possible estimate for the total number of people to have participated in the Olympics as of 2015 was 128,420, though as it notes other estimates could be created. It has been proposed to create a complete alphabetical listing of all participants of the Olympics, spread across a number of articles. An example of one of these lists can be seen here. FOARP (talk) 11:16, 17 September 2025 (UTC)[reply]
AFD discussion (nb. this RFC was recommended in the close here).
Survey
Do you:
Oppose creation of these articles
Support creation of these articles
Responses
Oppose - The possible number of entrants makes this essentially a phonebook, something which Wikipedia is clearly WP:NOT. It would not be useful for navigation because of its length - a figure that is not even fixed but grows by thousands with each edition of the summer and winter games. FOARP (talk) 11:16, 17 September 2025 (UTC)[reply]
This says "this RFC was recommended in the close here". Where was this RfC recommended in the admin's close? The only time an RfC was mentioned by the closing admin was as as an aside "...and I believe the intersection of lists of sportspeople with NOTDB is ripe for a community-wide RfC". Creating an RfC focused on one specific list to exist or not, as this is, feels like circumventing the AfD process just one day after an AfD on this list was closed. I wouldn't oppose a broader RfC on "the intersection of lists of sportspeople with NOTDB", but it can't be phrased in this way about one specific list that both you and I were WP:INVOLVED in the AfD for. (also, why wouldn't you use the first page as an example of the list contents?) --Habst (talk) 12:07, 17 September 2025 (UTC)[reply]
So that this isn't just an exact re-hashing of the AfD closed one day ago, I proposed adding additional options:
Oppose lists:
Oppose having any list of Olympians
Oppose specifically an alphabetic list, open to others
Support having a list in some form:
Support keeping existing Olympic list (alphabetic)
@Habst the diff of the reversion is actually Special:Diff/1311888941. I think the additional nuance is useful and won't overwhelm the discussion - indeed I think it's likely to aid the finding of a consensus and avoid the need for more future discussions. Thryduulf (talk) 14:26, 17 September 2025 (UTC)[reply]
Oppose A full alphabet listing of Olympians is not a natural sorting order for them, so it doesn't make sense to make such a list. (Olympians by country or by sport are far more natural). This is also where categorization is already set up to do that. Masem (t) 12:11, 17 September 2025 (UTC)[reply]
Neutral. At AfD I said that these clearly meet NLIST, and they do. But whether they are worth having around is a separate question, hence why this RfC is a good idea. I think arguments on both sides are sensible, so I land at a neutral or weak support. These lists technically fall within policy, but I'm not fully convinced that they're useful to readers. Toadspike[Talk]12:59, 17 September 2025 (UTC)[reply]
Support a list of all Olympic competitors is very clearly useful and satisfies NLIST as they are discussed as a group and the inclusion criteria is not indiscriminate. Such a list would be impossible to navigate for size reasons though, so it needs to be split and alphabetic is self-evidently one logical method of doing so. Wikipedia is not paper so we don't need to worry about the number of articles, and the existence of these listings does not preclude the existence of other splits (e.g. by games or by nationality). Thryduulf (talk) 13:24, 17 September 2025 (UTC)[reply]
To clarify now additional nuance has been requested above, I support the existence of lists organised alphabetically, by nationality, by games and by sport. I'm presently neutral on other lists. Thryduulf (talk) 13:27, 17 September 2025 (UTC)[reply]
The maintenance burden for these lists would be pretty high. Every Olympics, someone would have to go add them all in alphabetical order, interspersed. Perhaps grouping by Summer/Winter Olympics Of Year XXXX would make more sense, instead of a massive alphabetical list? –Novem Linguae (talk) 15:00, 17 September 2025 (UTC)[reply]
As Perryprog alludes to, there are so many different ways to organize the data and the data is constantly being updated, so a database sorting/filtering interface is more suitable than creating snapshot lists of all possible organization methods. Even if the snapshot process were automated, the length of the lists makes them unwieldy for convenient use. I think better search tools (either based on Wikipedia or Wikidata) would be a more extensible, manageable solution. isaacl (talk) 16:06, 17 September 2025 (UTC)[reply]
In my AfD closure I recommended that the community discuss the intersection of lists of sportspeople and WP:NOTDATABASE, or possibly the interpretation of NOTDB as it applies to large groups with well-defined inclusion criteria more broadly. There is a clear divide in the community as to the interpretation of NOTDB in this context. I didn't intend to recommend an RfC about this list specifically. I cannot preclude one, of course, and as I closed the discussion, and am genuinely undecided, I won't be commenting on the merits. Vanamonde93 (talk) 16:21, 17 September 2025 (UTC)[reply]
Oppose Also agree with User:FOARP that this is basically a phonebook given the sheer length. It's not useful for navigation particularly: who knows only the first letter of an olympians name, and nothing else, and needs to find them? What about "List of olympians in snowboarding" or topic-based lists? Those might be more useful. Mrfoogles (talk) 01:10, 18 September 2025 (UTC)[reply]
Oppose This list is fundamentally a bad idea for several reasons. WP:NOTEVERYTHING shows an existing consensus that databases and phone lists are not appopriate on Wikipedia. Secondly, discussion at AfD revealed that the collation was manuallyy sourced and created from wikidata. But if that is so, then we already have the collection in wikidata. This is just bad information management, to create two copies of the data that require manual intervention to prevent them falling out of step with each other. And thirdly, that workload is excessive and the reason that wikipedia lists, in general, are not useful if they claim to be exhaustive: because they are not. They rely on diligent and continual editor resource, that they cannot ever achieve. As FOARP points out, the enormous size of this list, and the speed at which it accrues new entries will guaranty that the list will be incomplete, and bad data is worse than no data. Fourthly, in this format, the data is unusable. If you know the name of someone you want, search is faster, as is querying wikidata. If you don't, then this list is not a suitable taxonomy. Fifthly, we already have the means for creating taxonomies, and those taxonomies already exist in the form of existing categories. So no, we shouldn't do this. We should use the existing wikidata and categories, and if anyone is interested in some kind of searchable list - dynamically generate it from wikidata. Sirfurboy🏄 (talk) 07:33, 18 September 2025 (UTC)[reply]
Actually, those categories do not contain every Olympian. There is no other place (whether categories, wikidata, or even other websites) for anyone to find a complete listing of Olympians. BeanieFan11 (talk) 16:50, 18 September 2025 (UTC)[reply]
To clarify, I support having this information, I just think there is probably some better way of organizing the data that would make it more accessible to readers than an arbitrary number of alphabetized lists. mdm.bla17:18, 18 September 2025 (UTC)[reply]
Oppose These articles are too long and have too little information to be useful. They also clearly violate the spirit and probably the letter of the law that Wikipedia is not to be a directory. Some have argued that there is sourcing about Olympic competitors as a group. This sourcing is on the general trends of who has been Olympic competitors, but with an unclear number somewhere around 150,000 or 160,000, it is not possible to create a comprehensive list and sources do not do this, just cherry picking some sub-group, or what they find interesting or excited cases. We maybe could have an article Olympic competitors or the like that says things about Olympic competitors as a group, maybe subdivided in some ways, but sourcing does not justify creating a directory of every single Olympic competitor whose name we know, especially one that really does not tell us much about the individuals. I do not think creating such a massive directory of Olympic competitors is within the listed things Wikipedia is, and I do not think there are sufficient reliable sources to support such a directory in Wikipedia.John Pack Lambert (talk) 21:37, 18 September 2025 (UTC)[reply]
Discussion
What is it we're looking to do here? The framing is odd -- It has been proposed to create, and a focus on supporting/opposing creation as though the articles don't already exist. It just went through AfD, which ended in no consensus, and an RfC on retroactive opinions on creation (?) isn't a substitute for that process. Opposition to creation doesn't necessarily mean support for deletion (and vice versa), and the choice here doesn't include deletion. If you're trying to establish a precedent about the scope of a list, this also doesn't do that, because it's too focused on a specific example. — Rhododendritestalk \\ 14:46, 17 September 2025 (UTC)[reply]
Thank you. To be honest, I'm feeling this RfC is a little bit of a hostile environment for me because, as it's written, I don't see how this isn't circumventing an AfD that received a sufficient amount of participation and was closed yesterday, started by an editor who I greatly respect but was heavily involved in that AfD (I was also involved as the list creator). It claims it was created at the behest of an admin, but then the admin came here and commented that wasn't what they said. (And if that's going to be the case, shouldn't all the AfD and WikiProject Olympics thread commenters be pinged...?) I desperately want to achieve consensus on having a list of Olympians, including making concessions if needed, but I want to do it the right way.
From a bigger picture it seems this list is being used as a 'proxy battle' among inclusionists and deletionists w.r.t. WP:NSPORTS2022 and its recent implementation this year, resulting in hundreds of Olympian articles being deleted and no suitable place to put that lost information. As someone who genuinely tries to look at each case on its merits, I don't know how to rectify that.
One of the biggest concerns I heard was editors saying they would prefer if lists were created by sport rather than alphabetically. I also thought that originally, but after actually compiling it I realized that anything other than an alphabetic list is guaranteed to create duplicate rows (e.g. for multi-sport athletes who would be listed in more than one of these articles) and thus introduce unforeseen complexities.
Nonetheless I did some of the legwork on this over the last few days to determine what that would look like. The largest Olympic list segment currently is 2,136 rows, a limit that was essentially decided by the community as others have split the original segments that were longer. Using that limit of about 2,100 rows per article, we would need more than one article for each sport, even if broken up further by gender. My best idea after that is to split by year and gender, so here's what that would look like in a ToC table with that approximate limit: Special:Diff/1311981102
This would result in duplicates both across sports and across years, but is the only way I can think of to split by sport. I'm not opposed to creating all those pages, just struggling to see how that would be better or more maintainable than the current list. --Habst (talk) 01:01, 18 September 2025 (UTC)[reply]
Thank you for validating my confusion. The question seems to be "Should we create these articles?" but then the already-existing articles are linked to. The answer would then logically be "No, they already exist." 207.11.240.2 (talk) 12:29, 19 September 2025 (UTC)[reply]
Technical
Can someone possibly update this JS?
This currently doesn't have the option to also do /64 for IPv6, like this other script (which I can't quite find right now) has just for v6, and so if the singular IP is blocked it doesn't check to see if /64 is also, which results in duplicates (other script might also have this problem, but at least there's the option to choose /64...) ~Loftyabyss18:37, 8 September 2025 (UTC)[reply]
Also, if anyone can possibly fix this, too? It doesn't seem to function like it did before (used to switch focus), instead it just lists edits in some floating side window, now, which isn't as useful... ~Loftyabyss20:36, 8 September 2025 (UTC)[reply]
Looking at EasyBlock, there's a lot of ancient code in there that could use updating. You'd probably need to replace easyblock.isIP() with mw.util.isIPAddress() for starters to recognize IPv6 addresses and ranges. Pinging Amorymeltzer, since they seem to be maintaining an updated fork of EasyBlock at User:Amorymeltzer/easyblock-modern.js. --Ahecht (TALK PAGE)21:18, 8 September 2025 (UTC)[reply]
I'd say "maintaining" is a stretch, and tbh the idea of diving in and re-org-ing easy block isn't appealing. As Ahecht notes, a lot of it—like the sensitive IP checker—predates current systems. Although at least, like most of Animum's stuff, it's clear enough to look through. ~ Amory(u • t • c)17:34, 12 September 2025 (UTC)[reply]
Since this morning, every time I load a page from WP, i get all the content, but no formatting.
It's fine on Chrome, and on Ecosia on my phone, but not Firefox on my windows m/c.
Firefox 142.0.1, Windows 11 pro, 22H2.
I've tried logging out, restarting Firefox, deleting all MW-related cookies.
it seems to apply to Wiktionary went wikidata too.
Anybody else seen this? ColinFine (talk) 21:15, 10 September 2025 (UTC)[reply]
Did you accidentally disable the styles in Alt menu > View > Page Style? Otherwise, I don't know (I'm using the same version but on Windows 10 instead, and the formatting is still there) -- perhaps you could look in the developer tools console and see if there are any errors or "Loading failed" errors? OutsideNormality (talk) 21:58, 10 September 2025 (UTC)[reply]
Thanks, @PrimeHunter and @OutsideNormality. I couldn't find "Alt menu > View > Page Style" (Didn't know whether it was something in WP or Firefox), and I did bypass my cache.
Went to update a box on my userbox subpage and suddenly discovered that they're not displaying right. They should be, and up until this afternoon were, displaying "abreast to the screen limits", now it's one box per row. I'm guessing something, somewhere, got edited that broke something? - The BushrangerOne ping only04:37, 13 September 2025 (UTC)[reply]
When I view Noblesse oblige, the whitespace is messed up. See the attached screenshot. In the lead, "aFrench expressionthat" is missing spaces after the "a" and before "that". Likewise with "fullsocial responsibilities". Down in "Meaning and variants", the square brackets around "citation needed" are displaced vertically.
I can't reliably reproduce this. Even more interesting, it looks like some kind of race condition; if I reload the page, I can transiently see the text rendered properly, then a fraction of a second later, it gets messed up. And while I can (sometimes) see this on https://en.wikipedia.org/wiki/Noblesse_oblige, I never see it on the permalink version of the same version, https://en.wikipedia.org/w/index.php?title=Noblesse_oblige&oldid=1306524664. I also can't reproduce it in an incognito window (I'm using Chrome on MacOS).
As it doesn't happen when you're not logged in (and I don't see anything in the wikitext source that looks like a possible cause), perhaps it's one of your user scripts or enabled gadgets, which would match the race condition symptom. Have you tried narrowing the problem down by slimming down any customizations you have configured? isaacl (talk) 16:35, 13 September 2025 (UTC)[reply]
Oh, wow. It's the Google Translate service built into Chrome! It has (duh!) decided the page is written in French and tried to translate it into English for me. This seems to involve adding font tags like:
<font dir="auto" style="vertical-align: inherit;"> ; literally "nobility obliges") is a</font>
Is there a bot to convert 'pages=' to 'article-number=' in sources?
Wasn't able to find in archives whether a bot has been developed (apparently not deployed) to automatically repair sources showing in an edit preview the message: "Script warning: One or more {{cite journal}} templates have maintenance messages; messages may be hidden (help)."
I have been fixing many of these manually, but a repair bot would be helpful. For an example, see Osteoarthritis in an edit preview, displaying that 42 references need an "article-number=" fix, with the message in the reference section stating: "{{cite journal}}: CS1 maint: article number as page number (link)". Zefr (talk) 19:06, 13 September 2025 (UTC)[reply]
Since there are no short-form references linking to that {{CongBio}} source, the warning message is correct. If you want to suppress the warning message: {{CongBio|G000453|ref=none}}. Use of |ref=none is mentioned in the {{CongBio}} documentation...
Thank you, I missed that. And, yes what you stated above is true but the documentation is:
ref =ref — for use with the {{harv}} templates for inline citations
defaults to:{{harv|United States Congress|ID}}
If the author is set to something other than United States Congress
then it is also changed here. The ref parameter can be assigned another
value including none to unset the parameter.
so the "ref=none" is kinda/sorta hidden. If that blurb were adjusted to make it plain as day for those of us who aren't WP-adepts...yes please. - Shearonink (talk) 14:02, 14 September 2025 (UTC)[reply]
We have a tool to "copy to Commons" for openly-licenced images that were uploaded here, but do we have one to copy images, and their metadata, from Commons, when they are facing deletion, but usable here as fair use? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits15:02, 14 September 2025 (UTC)[reply]
Not sure if this affects anyone else in the same manner as it does me....but Template:Skip to top and bottom when in mobile view shifts to the left side and suppresses (or should I say covers) linking capability of our bottom string of links if they are on the very bottom line
Privacy policy About Wikipedia Disclaimers Contact Wikipedia Code of Conduct Developers Statistics Cookie statement Mobile view
@Matrix: The only default-enabled gadgets I have disabled are "(D) Add extra buttons to the legacy (2006) editing toolbar" and "(D)refToolbar: add a "cite" button to the editing toolbar for quick addition of commonly used citation templates", neither of which sound likely. I also don't see any gadgets with a description that sounds like this thing. Anomie⚔20:27, 15 September 2025 (UTC)[reply]
I’m working with Module:String and trying to determine if a given parameter contains a template. So given the parameter {{{weight}}}, I want to see if that value is a string (like 123 lbs) or if it contains a template (like {{cvt|123|lbs}}). I can’t seem to get the code to work though… Even something as simple as {{#invoke:string|find|{{{weight}}}}|cvt}} isn’t returning the expected results when I know that cvt is in {{{weight}}}. What am I missing? Zackmann (Talk to me/What I been doing) 07:07, 15 September 2025 (UTC)[reply]
My understanding is that wiki text evaluation is from the "inside" outwards. This means that the parameter value should already have been processed (and any templates expanded) by the time the module sees it. It might be OK to check for the brackets instead. A length pre-check might also be wise, as the weight value might possibly have a reference appended. get_convert_weight_args seems to be looking for the NBSP that is output by the convert template, so that might be a another viable test — GhostInTheMachinetalk to me07:37, 15 September 2025 (UTC)[reply]
See also T322513, where an ability to access the unparsed content of an argument was requested. I thought there was an earlier such request as well, but I can't find it now. Anomie⚔13:59, 15 September 2025 (UTC)[reply]
The latest run of Special:WantedCategories features a nonsense Category:$1, being autogenerated by code on a user's .js settings page that I can't fix because I don't have the group privilege to edit that kind of content. I know that there have also been multiple instances of this category recurring in the past, with it sometimes even having been created to get it out of the reds before being deleted at CFD — but every documented instance I can find records for has always been tied somehow to user settings pages.
So two questions:
Could somebody who has script editing privileges edit the page to remove the redlinked category?
If this is a thing that's going to recur every time an editor makes any kind of mistake in their js settings code, then is there any way we could just preemptively block it at the server level before it occurs at all?
@Bearcat: The usual way to request this is to either submit an edit request with {{edit interface-protected}} on the talk page - the "submit an edit request" link shown when you try to edit the page should mostly automate that - or if it's suddenly affecting many pages at once, a post on WP:Interface administrators' noticeboard. Disabling it automatically isn't really feasible without making it impossible to put intentional categories (rare) or links (less rare) on user js/css pages, which lets, for example, this work. —Cryptic15:26, 15 September 2025 (UTC)[reply]
Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.
Updates for editors
References lists that are made using the <references/>tag will now automatically display with columns in Vector 2022 when readers are using its 'standard' settings for text-size and page-width. [23]
Starting in the week of October 6, on small wikis and medium wikis that have the CampaignEvents extension enabled, all autoconfirmed users will be able to use Event Registration as an organizer. No changes will be made for large wikis unless requested in Phabricator. This change is being made to make it easier for more people to use Event Registration, especially on wikis that are less likely to have policies related to the Event Organizer right. Learn more.
Users that search using regular expressions (regex) can now use additional features including:
for the intitle: keyword: metacharacters for start-of-line (^) and end-of-line ($) anchors [24]
for both intitle: and insource: keywords: shorthand character classes for digits (\d), whitespace (\s), and word characters (\w); and escape codes for line feed (\r), newline (\n), tab (\t), and unicode (e.g. \uHHHH). [25]
When you search for text that looks like an IP, the system will now show search results. It used to take you to the contributions for that IP instead of showing search results. [26]
View all 24 community-submitted tasks that were resolved last week. For example, a bug was fixed that affected users who used the page-tabs to switch from wikitext editing of a section into the visualeditor. [27]
Updates for technical contributors
The MediaWiki Interfaces team is redesigning the Wikimedia REST API Sandbox with Codex. If you have feedback on improvements for the API documentation or what makes developer experiences smooth (or frustrating), you’re invited to join an upcoming discovery interview, or leave feedback onwiki. Learn more.
Edits to Wikidata aliases (an alternative name for an item or a property) will now be shown in RecentChanges and Watchlist entries on other wikis less often, reducing unnecessary notifications. This will reduce the overall quantity of 'noisy' entries. Wikidata's own pages remain unchanged. Learn more. [28]
The new Unicode 17.0 version has been released. The datasets on Commons for the Module:Unicode data have been updated. Wikipedias that do not use the Commons datasets should either update their own data or switch to the Commons datasets.
Users of the Wikimedia Enterprise Structured Contents endpoints can now access Parsed Tables. The new Parsed Tables feature extracts and represents Wikipedia tables in structured JSON. This improves machine accessibility as part of the Structured Contents initiative. Structured Contents output is freely available through the On-demand API, or through Wikimedia Cloud Services.
A dataset of English Wikipedia biographical information from Wikimedia Enterprise has been published on Kaggle, for evaluation and research. This provides structured data from more than 1.5 million biographies, including birth and death dates, education, affiliations, careers, awards, and more (from a June 2024 snapshot).
It feels like a long time since I've done this, but I'm actually cheering the regex improvements in search. Big Thanks!! Searching on titles will deliver more specific results, as I'm regularly looking for articles that begin with the top-level subject, like what city or state it's in. Stefen 𝕋ower's got the power!!1!Gab • Gruntwerk17:23, 15 September 2025 (UTC)[reply]
Effect of too much indenting
In a discussion on a talk page, it appears that if there is a discussion with so much indenting (because of too many levels of replying and back-and-forth, the left margin gets first toward the middle of the page and then goes past the right margin, so that the text is invisible on a normally centered screen. A page where this can be seen is Talk:Rape_in_Islamic_law#Dispute_resolution_(third_opinion). I can take a screen shot to illustrate this if necessary, but it appears that it can be viewed on that talk page. My question is whether this is considered a bug, or whether it is a feature or misfeature that is the result of the excessive number of indents. Robert McClenon (talk) 20:47, 15 September 2025 (UTC)
I have verified that this can be observed with both the Monobook and the Vector skins. I am using Firefox and Windows 11. Robert McClenon (talk) 20:50, 15 September 2025 (UTC)[reply]
(edit conflict) I don't see invisible text (ha), but I do have to scroll right to see it and the latest replies get compressed into a narrow column, making them hard to read. The usual solution is to use {{outdent}} to cut back on the levels of indenting, see WP:OUTDENT for further details. Anomie⚔20:53, 15 September 2025 (UTC)[reply]
I can confirm that this is an issue on Linux using both Chrome and Firefox. The symptom is that line-wrapping is not happening for the entire thread, even for responses with a reasonable indentation level. I applied outdenting templates to the thread with a script, using a max level of 6, and it is now readable. Xan747 (talk) 23:00, 15 September 2025 (UTC)[reply]
WP:TPFIXFORMAT approves of Fixing format errors that render material difficult to read, specifically including Fixing indentation levels. Personally I think 6 is a bit too little, and Xan747 may have screwed things up by doing things like formatting [29] as a reply to [30] rather than [31] as it was before, but 🤷. Anomie⚔01:38, 16 September 2025 (UTC)[reply]
Collapsible tables using the class collapsible do not work in the mobile version. (They are open, and can not be closed.) Only those using mw-collapsible work as they should. Could somebody fix that? BTW, what is the point of having both classes? Are they intended for slightly different use-cases? Watchduck (quack) 08:46, 16 September 2025 (UTC)[reply]
@Watchduck collapsible is deprecated, you should be using mw-collapsible. collapsible has some backwards compatibility code in English wikipedia's local Javascript, but this probably doesn't run in mobile indeed. —TheDJ (talk • contribs) 09:58, 16 September 2025 (UTC)[reply]
A quick search for "wikitable collapsible" finds 13,450 articles. Should there be some push for the uses to be changed or will the classes continue to be treated as aliases forever? — GhostInTheMachinetalk to me13:35, 16 September 2025 (UTC)[reply]
I'm a little confused by the difference between the statements by GhostInTheMachine (it's an alias) and TheDJ (it's deprecated and probably doesn't work in mobile). I don't think both can be true. If the latter is true, we probably should replace instances of "collapsible" with "mw-collapsible". – Jonesey95 (talk) 15:15, 16 September 2025 (UTC)[reply]
It’s deprecated in Mediawiki, but English Wikipedia just never updated all the content (because doing so wasnt a priority and even without the alias handling, it ‘degrades’ into an uncollapsed state, which means it is readable regardless, so not a big problem. All content should always be consumable as being uncollapsed as being collapsed is not something that can be guaranteed [think print, google results, Alexa and all other non-standard forms that will ALWAYS have uncollapsed content]). Mobile was never a problem because it didn't support collapsing until very recently.
But English Wikipedia community has a custom handler to support the old classname. Templates have mostly been updated, but there is a lot of bare usages of collapsible on very old content. Advise is to update the content, because if its still around, that likely means the article is barely ever edited and the content has generally more problems than just collapsible. —TheDJ (talk • contribs) 16:42, 16 September 2025 (UTC)[reply]
The "collapsible" class is not actually an alias, but there is code in mediawiki:Common.js that sees "collapsible" and just adds "mw-collapsible". So it is treated as an alias. While that happens, there is little motive to change the class name. Once something has been flagged as deprecated for a decent time, making use of it needs to hurt at least a little bit. Is there any simple way to trigger an edit notice or should we just unleash a bot? — GhostInTheMachinetalk to me18:26, 16 September 2025 (UTC)[reply]
I recalled my main reason that I haven't just done it myself and it's that MOS:COLLAPSE says we probably shouldn't have things that collapse in mainspace at all that aren't navboxes and the like. So the bot task could either be: move everything over to mw-collapsible, or, remove every use of collapsible in the main space. I added that as a significant caveat on the working page. Izno (talk) 21:08, 16 September 2025 (UTC)[reply]
I don't think there's any hard prohibition on using mw-collapsible uncollapsed in mainspace, just that it should not be collapsed by default. --Ahecht (TALK PAGE)18:20, 17 September 2025 (UTC)[reply]
Yet another good reason to get rid of the collapsible class is that VisualEditor is unaware of it for collapsible tables. It has a switch for collapsible tables, but only recognizes and works with the mw-collapsible class. Ponor (talk) 21:58, 17 September 2025 (UTC)[reply]
If no content changes are made, this would be fixed by phab:T375538 being completed.
I do however support making content changes to correct the current state of things. Someone just needs to make the bot for the probably ~20k replacements that would need to be done for ad hoc tables (and potentially divs). Izno (talk) 17:54, 16 September 2025 (UTC)[reply]
Does anyone know if the Lua logging functions work on iPad? I do all my editing on an iPad these days and despite multiple attempts with mw.log(), I cannot get anything to show up in the log… Is there some trick that I’m missing? —Zackmann (Talk to me/What I been doing) 06:44, 17 September 2025 (UTC)[reply]
@Zackmann08: I don't see why it wouldn't work on iPad. What steps are you taking to see the log? I believe you need to be previewing a page that uses the module you're editing; the log shows under "Parser profiling data" (in a text filed that is initially, for some reason, collapsed). Ponor (talk) 09:59, 17 September 2025 (UTC)[reply]
I got it to work there finally. I was expecting it to display in the debug log area… Only now realizing that I can actually TYPE commands in that area and execute them… Feeling a little dumb. Clearly time for sleep. —Zackmann (Talk to me/What I been doing) 10:02, 17 September 2025 (UTC)[reply]
@Zackmann08 If you want the Lua log to show up in your browser's debug console (the one built-in to Safari or whatever mobile browser you're using), you can add the following to your Special:MyPage/common.js: varwppr=mw.config.get("wgPageParseReport");if(wppr&&wppr.scribunto&&wppr.scribunto["limitreport-logs"]){console.log(wppr.scribunto["limitreport-logs"])}--Ahecht (TALK PAGE)18:07, 17 September 2025 (UTC)[reply]
RFC: Adding featured and good content status to the tagline
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.
Overall consensus is this would be an improvement. As this would be displayed on every page, there were technical concerns about performance. A good suggestion was to take the result of this RFC as an indication of whether or not the community wants this feature. Technical details can be worked out with WMF staff, and performance should be tested. If things do not go well, we would expect this feature not to be deployed and further discussion could happen about whether any required engineering would be worthwhile. (Personal aside: the examples shown do not work correctly in dark mode; presumably this would be fixed before deployment.)
Objections were varied. Some editors were concerned about the quality of the article rating processes, which version was reviewed, and/or the terminology used (especially "good"). Other editors said the fact that the terms-of-art are linked mitigates these concerns to some degree. There was much debate over the timeliness of de-listing and repair of bad edits to good and featured articles. A small number of editors supported removing the tagline completely, or effectively said something like "not broken, don't fix it".
Support was strongly centered on the same themes. Many editors thought it was a good idea or problem-solving to increase reader awareness of these quality ratings. Some said this was an important part of building trust and information literacy, or that this might encourage more editors to improve articles to these high levels, or improve post-promotion quality monitoring.
Mobile: Several editors expressed hope that quality ratings can be somehow displayed on mobile devices in the future. One editor objected to doing this on mobile, apparently misunderstanding that the proposed implementation would not be seen there.
Topicons: The question of whether to keep the same information in topicons was raised; more editors supporting doing so, especially at first so that differential click-through rates could be observed. This can be revisited after more data is collected. It was suggested to incorporate topicons into the tagline immediately, but this was not accepted. This could be revisited if they are eliminated as a standalone thing.
Apologies for the long text to follow but I think a detailed RFCBEFORE and implementation is necessary for such a highly-visible proposal.
There's been perennial proposals for increasing the visibility of page status, with a fair amount of assent but no proposed directions. Many editors in prior discussions have felt the topicon is too small a notice that doesn't accurately reflect the amount of work put into raising articles to featured status. Other editors think the topicons are opaque to readers, and feel that more prominence will draw editors to these backend projects.
I've developed Module:Page assessment raw, a simplified version of Module:Page assessment that uses the newest features in the MediaWiki pageAssessments extension. I wanted to have a duplicate module to reduce the expensive function count (since this will be on every page) and to allow full- or template-protecting the module (for the same reason).
I think the most efficient way to implement this proposal is to fully replace the page MediaWiki:Tagline with a switch-case function to change the tagline based on the output of the Lua module:
{{#switch:{{#invoke:Page assessment raw|get_class|page={{FULLPAGENAME}}|project=Project-independent assessment}}| FA = A ''[[Wikipedia:Featured articles (linked from tagline)|featured article]]'' from
| FL = A ''[[Wikipedia:Featured lists (linked from tagline)|featured list]]'' from
| GA = A ''[[Wikipedia:Good articles (linked from tagline)|good article]]'' from
| From
}} Wikipedia, the free encyclopedia
Support a small change (probably smaller than people expect, considering the banner blindness phenomenon) which could nevertheless increase new editor attraction from people curious enough to click the link. I don't really see any downsides. ~~ AirshipJungleman29 (talk) 20:19, 7 July 2025 (UTC)[reply]
Support. Good articles being invisible on mobile – 65% of our readers – doesn't make sense. Bringing us to some parity with the web version communicates to readers that some verification and vetting effort has been made, especially with the recently increased level of scrutiny required by GAs (and much-discussed at WT:GAN. — ImaginesTigers (talk) 20:23, 7 July 2025 (UTC)[reply]
This sadly won't affect mobile users as the tagline does not appear in Minerva. It would be a good impetus for bugging WMF over at Phabricator to show the tagline though. Dan Leonard (talk • contribs)20:33, 7 July 2025 (UTC)[reply]
@Dan Leonard: Thanks for telling me that, although it is disappointing. I assume this affects web Minerva, too? If so, do we have any statistics on how many users aren't using Minerva at this point? I'd assume the number is relatively low, and largely our most engaged user base. — ImaginesTigers (talk) 22:31, 7 July 2025 (UTC)[reply]
Other respondents mentioned here that mobile topicons don't seem to have any progress and community work on adding a mobile tagline would probably be easier than adding a mobile topicon, not to mention the engineering needed to have parity with tooltips on mobile. Aaron Liu (talk) 16:18, 9 July 2025 (UTC)[reply]
Support a minor change but a positive one. Anything that (1) raises awareness of our quality content and (2) might conceivably encourage readers to contribute is a good thing. Cremastra (talk) 20:48, 7 July 2025 (UTC)[reply]
Support taglines are harder to miss, so this does seem like an improvement. Would this also remove the topicons, or would a highlighted article end up displaying both? Paprikaiser (talk) 20:51, 7 July 2025 (UTC)[reply]
Support per Airship, though I think the current wording is needlessly verbose. I feel it could be more impactful if it said something like "A featured article, meaning it represents the best Wikipedia has to offer" IAWW (talk) 20:55, 7 July 2025 (UTC)[reply]
Sorry, verbose wasn't a good word. I mean the current wording doesn't make the best use of space. Adding "from Wikipedia, the free encyclopedia" is pointless, because the reader obviously already knows this. Those words could be replaced with something different that the reader doesn't already know, like what a "featured article" is. IAWW (talk) 21:23, 7 July 2025 (UTC)[reply]
Support I think this is a better way to make the good and featured stand out. If this proposal passes, I recommend removing the topicons. I would also like to implement this change to all the vital articles as well. For example, George Washington would say A level 3 vital and featured article from Wikipedia, the free encyclopedia while an article that is neither good nor featured, but vital like Christianity would say A level 3 vital article from Wikipedia, the free encyclopedia. Interstellarity (talk) 21:07, 7 July 2025 (UTC)[reply]
Vital article status seems less important, as not only is it less transparent to readers ("is level 1 vital the least or most important?"), but also only relates to the topic itself rather than the quality of the article they are reading. Knowing that what you are reading has been through a formal review process is great to gauge the level of trust you want to give to the article, knowing that the subject has been assessed to be important, less so. Chaotic Enby (talk · contribs) 21:48, 7 July 2025 (UTC)[reply]
For example, a FA/GA badge with enough context could be an interesting and valuable trust signal for a reader, similar to how warning templates are often used as distrust signals when articles are low quality. On the other hand, I assume that a "protected" badge would be of little interest to anyone who isn't logged in and actively considering contributing to the wiki.
Another tension in the current proposal is the form of the indicators themselves. As mentioned in the VP discussions about this, there may be a low awareness of FA/GA for casual readers, and an unlabelled icon might not "onboard" casual readers into explaining what FA/GA are and why they're useful.
While the tagline isn't currently shown in Minerva either, WMF might be more amenable to displaying it as it is likely technically simpler than showing topicons and solves the problem of an unlabelled icon might not 'onboard' casual readers. It's currently tracked, albeit stale, at phabricator:T349117. Dan Leonard (talk • contribs)21:25, 7 July 2025 (UTC)[reply]
Support; I agree with AirshipJungleman that it likely won't be noticed by the vast majority of users, but if one percent are intrigued and find out more about the Good & Featured processes, I think that makes it more worthwhile. I also agree with the takes that it'd be more applicable to mobile than a topicon would be, and I think it adds context to the topicons on desktop if people don't realize you can click on them. Generalissima (talk) (it/she) 22:47, 7 July 2025 (UTC)[reply]
Support as the overdue implementation of repeated consensus for greater visibility. Like Chaotic Enby, I would never want this expanded to other article classes because many (myself included) use Rater for an AI-generated classification that works for our technical needs but communicates little to readers. I would have this appear alongside the topicon, both because the aesthetic badge is a big motivator for article writers and to run Dan's click-through experiment. Hoping that even if the topicons are never added to mobile view, at least this expanded tagline can be. ViridianPenguin🐧 (💬) 22:55, 7 July 2025 (UTC)[reply]
As I said in a previous discussion, I don't agree with the premise. I think the current amount of prominence given to the article rating is appropriate, given the way the rating is determined. Thus I do not support changing the tagline in this manner. isaacl (talk) 22:55, 7 July 2025 (UTC)[reply]
To expand slightly on the determination concerns: I appreciate that the good article/featured article review processes are the only ones we have for this type of article rating. However they do not ensure evaluation by subject matter experts with the background knowledge to best evaluate the comprehensiveness and accuracy of the article. I think giving the rating higher prominence would raise reader expectations that an evaluation has been made by subject matter experts. isaacl (talk) 15:10, 11 July 2025 (UTC)[reply]
Support per above. These two ratings are the ones with the least amount of arbitrariness so I don't think this status should have any less prominence. They're already displayed as topicons everywhere except Minerva, which shows the reader interest. If these statuses are any overprominent, there's already consensus for them being so. Aaron Liu (talk) 23:05, 7 July 2025 (UTC)[reply]
Oppose as the tagline should be kept simple. I agree with isaacl that we don't need to give more prominence to article ratings, which are subjective anyway. Some1 (talk) 23:27, 7 July 2025 (UTC)[reply]
A tagline that changes depending on the article rating isn't simple, and I prefer that the tagline text remains the same for every article, regardless of its rating. Also, it's misleading to state that Example article is "A good article from Wikipedia, the free encyclopedia" when that rating reflects only one editor's review (opinion) of that article. In that instance, the tagline is more misleading than the topicon, especially when most readers won't bother to click on the good article link in the tagline. Many editors in prior discussions have felt the topicon is too small a notice that doesn't accurately reflect the amount of work put into raising articles to featured status Seems like this proposal is more for the editors than for the readers. Some1 (talk) 00:32, 8 July 2025 (UTC)[reply]
What's the impact of this small bit of added complexity?
when that rating reflects only one editor's review (opinion) of that article
I think that's only an argument for renaming GoodArticle. In my opinion, "good article" signifies only as much value as it should. This also means if a reader thinks "hey this is not good-article quality" they can start something on the talk page. Aaron Liu (talk) 18:20, 8 July 2025 (UTC)[reply]
I don't see the harm per se, but more visibility for GA/FA ratings makes more critical the need for participation at WP:FAR and WP:GAR and for those processes to function properly. CMD (talk) 00:38, 8 July 2025 (UTC)[reply]
Support. As I mentioned in the 2023 RFC: I once observed a high school classroom that happened to be teaching research skills on using Wikipedia. The teacher said that the lock icon in the corner meant that it had been reviewed and was safe. Readers have no idea what our esoteric icons mean, so a little explanation of what exactly is verified and what isn't could go a long way towards mutual incentives. This is a smart way to start. czar02:08, 8 July 2025 (UTC)[reply]
Support I don't see the harm in mentioning the fact that the article has reached good/featured status, and it would certainly help reader to become aware of those statuses and as a compliment to the topicons. Speaking of those icons, why don't we include them in the tagline too so the reader will notice it when reading the tagline and be able to recognize it when reading another article on its tagline or on the corner of said artile. So maybe something like "A good article from Wikipedia, the free Encyclopedia." Here I placed the icon after the phrase introducing the article class since it looked akward to have it immediately following the indefinite article "A" when I tried that first. Gramix13 (talk) 02:52, 8 July 2025 (UTC)[reply]
This thought came to mind for me as well. I like the idea of having a more prominent visual, but I feel like it'd be redundant presuming we're keeping the topicon. My preferred approach to accomplish this would be to move the icon from the top right to directly next to the article title, as was previously proposed. Sdkbtalk05:09, 8 July 2025 (UTC)[reply]
Noting that since that 2020 proposal argued for matching the Danish Wikipedia's practice, dawiki has switched to our practice of having the topicon appear in the top-right corner (e.g., da:Israel). ViridianPenguin🐧 (💬) 13:40, 8 July 2025 (UTC)[reply]
Unfortunately not. I checked through their relevant talk pages and Landsbybrønden (village well) archives to no avail in identifying why they switched. ViridianPenguin🐧 (💬) 16:04, 8 July 2025 (UTC)[reply]
Support. An article's good or featured status is a key piece of information that every media-literate reader ought to pay attention to, but our current display is nowhere near prominent enough to make that happen. This is a well-thought-out step in the right direction toward making that happen. I support keeping the topicons, and ultimately moving them next to the article title per the prior proposal. I also continue to hope that phab:T75299 is taken up so that icons display on mobile. Sdkbtalk05:07, 8 July 2025 (UTC)[reply]
Strong support and additional request. I have a script that already does this, but this being an automatic thing for other editors would be extremely useful in helping people maintain articles. Possibly, we could also have 'Currently a featured article candidate', 'Former featured article', 'Currently a good article nominee' too; that might be a bit too technical though. 750h+05:18, 8 July 2025 (UTC)[reply]
Being a candidate or having former status is mainly relevant for editors, not readers, so I would not support this. Sdkbtalk06:03, 8 July 2025 (UTC)[reply]
Support, great idea. I'd also support other measures to improve GA/A/FA visibility, like moving the topicon to be right beside the title. Toadspike[Talk]09:12, 8 July 2025 (UTC)[reply]
My reaction to much of the opposition is that our readers are not stupid. They know what Wikipedia is. They will not see "good article" and think "this must be a 105% perfect article certified by the leading experts in the field and then fully-protected so no-one can edit the page again". They know that Wikipedia is a wiki written by regular people, many of whom are not experts on the topics they write about, and that Wikipedia articles can generally be edited by anyone, anytime. By calling something a "good article" or "featured article", whether in a tagline or with an icon, we simply argue that this article is better than many others. And while were bashing the names as "hokey" or "bizarre", I must point out that "featured" sounds stupid outside the context of being featured on the main page, while "good" is a simple English word that accurately describes the point of the rating. Toadspike[Talk]13:34, 12 July 2025 (UTC)[reply]
Oppose The top of many articles, including GA and FA, are already overly cluttered. I would support the reduction of clutter rather than the adding to it. -- LCU ActivelyDisinterested«@» °∆t°16:01, 8 July 2025 (UTC)[reply]
I understand your point, but this would add practically no clutter, as "From Wikipedia, the free encyclopedia" is still a default tagline. I assume you are generically opposed to the tagline in the first place? Dege31 (talk) 17:17, 8 July 2025 (UTC)[reply]
Support. Awareness of the featured article process is partially what inspired me to begin contributing to Wikipedia, and I feel like increasing this awareness wouldn't just inspire more people to edit, but would also inform readers which articles have been more diligently reviewed to eliminate gaps and verification errors. Sad that this won't be visible on mobile but it's a step in the right direction with no glaring downsides. Fathoms Below(talk)19:50, 8 July 2025 (UTC)[reply]
Support. I can see no downsides to this proposal - anything that helps promote good and featured content, and potentially bring in new editors, is a positive in my book, and this is a pretty nice and yet non-obtrusive way to do so. CoconutOctopustalk20:40, 8 July 2025 (UTC)[reply]
Comment. It sounds like we are proposing adding a module to every single page load on the entire wiki. Has someone who understands mediawiki caching and performance given some thought about if this will cause stress to the servers or performance issues? –Novem Linguae (talk) 22:48, 8 July 2025 (UTC)[reply]
mw.title.new().pageAssessments is an WP:EXPENSIVE function, but since it is only called once it usually shouldn't often be an issue considering the per-page limit of 500. The module does access the class rating via iteration (see the for loop at lines 29–33) rather than via random access, which is admittedly inelegant but probably not too inefficient. Sadly, I got what feels like a WONTFIX for random access at phabricator:T396135. Regardless, whether the community wants something shouldn't be dependent on whether it is currently feasible. I trust the interface admins and WMF will fix things if the community breaks them. This isn't to say I am in any way opposed to a code review of this, which I welcome wholeheartedly. I am sure there is something here that could be made more efficient. Dan Leonard (talk • contribs)23:10, 8 July 2025 (UTC)[reply]
I tend to agree with the link to WP:DWAP here (which has been relevant for parts of the interface like this before, the link to Category in the footer of each page used to be treated as sufficiently expensive for some reason or another that we couldn't let it vary by number of categories or something like that).
The only way to get an authoritative answer to this question would be to ask WMF directly I think.
That aside, I'm actually not really certain this will work the way OP wants it to. Has it been attempted on test Wikipedia? Izno (talk) 23:57, 8 July 2025 (UTC)[reply]
Putting my developer hat on, to my understanding the MediaWiki:tagline is added by a user's skin. As such, running page assessments at that layer is prohibitively expensive since the skin layer is re-rendered every time a user visits a page (as opposed to the parser cache layer where data is computed/rendered every edit and thus can have expensive functions). Unless folks contradict me, to my understanding this will require a significant investment of engineering effort to implement into core-mediawiki (or one of it's extensions) which I'm not sure is worth the outcome.
Putting on my WP:INTADMIN hat on, I'm not sure I'm completely onboard with using JS (or even Lua) to hack and slash at the existing tagline at pages that we as enwiki are wanting folks to visit. (For context, every time such a thing is implemented folks with bad internet connection will see a flash of unstyled content that often makes the navigating/reading experience worse). Sohom (talk) 00:51, 9 July 2025 (UTC)[reply]
I don't think it's prohibitively expensive, just a bit expensive. Performance is not affected for logged-out users as for them the entire page html, including the skin, is CDN-cached. For logged-in users, it does result in re-rendering, however note that the Lua .pageAssessments call is just a single SELECT call in the db. Being marked as WP:EXPENSIVE doesn't give the full picture. – SD0001 (talk) 05:35, 9 July 2025 (UTC)[reply]
It definitely isn't a Lua "hack". Functionality like retrieving page assessments have been exposed to Lua for use cases like this. It doesn't make much sense to implement everything natively in MediaWiki since most MediaWiki installations don't have a concept of FAs or GAs. – SD0001 (talk) 05:37, 9 July 2025 (UTC)[reply]
It's a hack because it hacks a message that shows at a place convenient for desktop users (⅓), but is not shown to mobile web and app users (⅔). It's not a complete solution, it's a hack. Other than that, there's a javascript gadget that also hacks the message, used by some 1000 active users. Why reinvent the wheel?Ponor (talk) 15:37, 10 July 2025 (UTC)[reply]
Changed my mind, it's a complicated js script. I'd still like to see a solution that every reader can see. Indicators are fine. Ponor (talk) 15:48, 10 July 2025 (UTC)[reply]
Using client-side JavaScript to scrape the talk page and modify the DOM after page load is a very different solution than using a MediaWiki extension's intended functionality to modify pages server-side. Mobile users miss out on a lot of things, including navboxes, sidebars, and even categories. Are categories "hacks" because Minerva chooses to hide them? Dan Leonard (talk • contribs)15:45, 10 July 2025 (UTC)[reply]
Agree about the gadget, just checked the code: ugh, that's an ugly one. But here, we're saying "this is important, we want everyone to see it", while at the same time we know that two in three readers will not see it. Categories and navboxes are the things at the bottom. Most users rarely go past the lead. So I'd say there is some importance difference. I'm not strongly opposed to "the hack" – I'd simply like to see a better solution. Use different indicators - find better icons? Use icon+text on desktop, icon alone on mobile? Ponor (talk) 16:10, 10 July 2025 (UTC)[reply]
Topicons aren't shown on mobile because it's a difficult implementation and because they're even more opaque to readers (see phabricator:T75299#10512584): on desktop, {{featured article}} at least benefits its readers with the tooltip "This is a featured article. Click here for more information", but touchscreens don't get tooltips. The tagline isn't shown on Minerva either, but it's probably a much simpler implementation and hasn't been done simply as a screen real estate saving measure. If we can get the tagline shown (phabricator:T349117), it'd serve the same purpose as the tooltip serves for desktop users. I do want mobile users to see this, and I think using the tagline is an important first step to getting WMF to increase visibility. Dan Leonard (talk • contribs)16:19, 10 July 2025 (UTC)[reply]
Oppose What is the point? FAs and GAs are not necessarily better than normal articles, and the reader does not care about who followed internal Wikiprocedures to get something declared FA/GA. Also per Ahecht. Polygnotus (talk) 03:36, 9 July 2025 (UTC)[reply]
While you are technically correct that some articles which haven't been formally reviewed are as good as GAs or FAs, the average GA is certainly better than the average article, which is a stub or not much more. Toadspike[Talk]07:58, 9 July 2025 (UTC)[reply]
They have necessarily underwent quality control, which includes things like "checking whether the sources confirm what the article say"- not exactly obscure, Wikipedia-only procedures. Dege31 (talk) 16:33, 9 July 2025 (UTC)[reply]
Support as an idea. If the current technical implementation is insufficient, then it can still be recognised as something the community supports and perhaps be added at a later point. Even if that is not likely to happen any time soon given other technical priorities, it would be better having than having another RFC every time someone comes up with another way to make FAs/GAs more visible. novovtalkedits08:26, 9 July 2025 (UTC)[reply]
I agree with the idea that consensus and technical details should be separate. The closer should feel free to find clear consensus that the community wants this (because they do). Then a consultation with a WMF dev good at performance and caching (maybe via a Phab ticket tagged #performance_issue and pinging someone like Krinkle?) and/or a trial should probably be encouraged in the close as a next step, but can leave that part vague / not as strong as the community consensus part. –Novem Linguae (talk) 09:10, 9 July 2025 (UTC)[reply]
Oppose hacking a module in to the tagline for every single page is a poor technical implementation, especially for something that is only needed on an extreme minority of pages. — xaosfluxTalk12:29, 9 July 2025 (UTC)[reply]
Also oppose conceptually using the tagline for this purpose; work was already spent on indicators and if wanted I'd prefer improvement to indicators. Indicators are also much more consistent across the Wikipedia's in other languages. — xaosfluxTalk12:32, 9 July 2025 (UTC)[reply]
The French, German, and Russian Wikipedias all use different icons (from us and from each other). Of the Wikipedias I regularly visit only Chinese and Norwegian use the same icons we do. Smaller wikis like Alemannisch don't have quality ratings at all. Toadspike[Talk]13:20, 12 July 2025 (UTC)[reply]
Additional oppose reason, as others have called out already, this will not solve the problem of casual readers (who increasingly use minerva) not seeing the rating - as the tagline element isn't even shown on that skin. I'd rather see indicator support added to minerva. — xaosfluxTalk14:54, 10 July 2025 (UTC)[reply]
Support A tagline seems much more understandable than cryptic and tiny symbols that we use today. If this proposal passes, I would support the removal of original topicons, as they will be made redundant. I don't know how feasible it is, but I would like WMF develop a way to show the taglines in the minerva skin as well. Catalk to me!15:40, 9 July 2025 (UTC)[reply]
Oppose The tagline is there to provide credit to Wikipedia, not provide extra information such as an assessment from a niche rating project that the vast majority of Wikipedia readers and editors don't participate in. I don't think we should be adding overhead to every single page, including non-article pages, just for increasing the visibility of page status. Not to mention that, to those not familiar with our lingo, "A good article from Wikipedia" sounds incredibly hokey, if not conceited.--Ahecht (TALK PAGE)15:53, 9 July 2025 (UTC)[reply]
This is a very controversial opinion. The question of whether cleanup templates' visibility to readers is in conflict with the WP:NODISCLAIMERS philosophy has been a battle on here since the beginning. The official primary purpose, a little fiction we tell ourselves to resolve this, is to categorize articles and flag areas for other editors. Dan Leonard (talk • contribs)02:12, 10 July 2025 (UTC)[reply]
@Dan Leonardto inform that there is (more likely to be) a problem with an extract from an article doesn't specify who gets informed, it might be the readers or editors or both. Polygnotus (talk) 02:26, 10 July 2025 (UTC)[reply]
I'm just explaining Aaron's comment, which I saw as a joke referencing the TfD battles over cleanup templates and the official policy that they aren't for informing readers. Dan Leonard (talk • contribs)02:31, 10 July 2025 (UTC)[reply]
I meant "inform readers" lol. Dan is correct in what I'm talking about, but I did have a point with my joke though in that the tagline would have the inverse purpose. Aaron Liu (talk) 17:39, 10 July 2025 (UTC)[reply]
Readers should absolutely be paying attention to an article's assessed GA/FA status. The fact that something underwent (in the case of FAs) a rigorous review process is a key piece of information as a reader decides to what extent to trust an article (and yes, in an ideal world they'd be verifying everything, but in practice doing that rigorously would take nearly as long as writing the article). It's something we pay attention to even when just reading an article we do not intend to edit. And it's therefore something we should make noticeable enough to readers that they can do the name. Sdkbtalk23:30, 9 July 2025 (UTC)[reply]
@Sdkb I think one of the major weaknesses and strengths on Wikipedia is that the writers are completely clueless about the readers. should absolutely be paying attention to an article's assessed GA/FA status. No, of course not. It means only that someone jumped through some hoops. a reader decides to what extent to trust an article In my experience, people don't work like that. it's therefore something we should make noticeable enough to readers that they can do the name. Why should we tell a reader information that is not helpful to them and that they do not know how to interpret. Doesn't make sense to me. Polygnotus (talk) 00:13, 10 July 2025 (UTC)[reply]
GA/FA statuses only reflect the quality of an article at the time it was reviewed. Some (most?) of the articles with GA/FA status haven't been reassessed in several years or have undergone so many changes since achieving their status that their current quality differs significantly from when they were first reviewed. J.K. Rowling, a "Featured article" (which apparently means that it's "[one] of the best articles Wikipedia has to offer"), currently has two large templates on the article, one of which indicates that it has neutrality issues. So again, these article ratings are subjective, and readers do not need to be paying attention to them any more than they need to. Some1 (talk) 00:31, 10 July 2025 (UTC)[reply]
You're conveniently omitting that there is currently an effort to delist the Rowling article. Which illustrates exactly how it should be working: Quality articles that no longer meet standards should be reassessed. Sdkbtalk02:42, 10 July 2025 (UTC)[reply]
The J.K. Rowling discussion has been opened for almost a month now (and who knows how long it'll take for that discussion to close), and in the meantime, that FA status is there, misleading readers into thinking the article is still "one of Wikipedia's very best works" despite multiple experienced editors arguing that the article should be delisted. Some1 (talk) 03:31, 10 July 2025 (UTC)[reply]
And plenty of others arguing that it should remain listed (and those editors are arguing that the aforementioned maintenance tags were added in an effort to try to get it delisted). I take no position on whether it should or should not remain an FA, but the active discussion around it, as the example you chose, contradicts the notion that FAs are listed and then never looked at/reevaluated again. People who watch them periodically send them to FAR, and WP:URFA/2020 has been going through every single one systemically. Of course, as in most areas of the encyclopedia, we don't have the editor capacity to monitor everything as closely as we wish, but that's no reason to give up on the project or minimize the value it provides to readers — if they know about it. Sdkbtalk17:40, 10 July 2025 (UTC)[reply]
Hence the giant neutrality tag on the top of the article. It's just like a "Disputed" inline tag right after a claim, and here the claim is that this is once of Wikipedia's very best works. Aaron Liu (talk) 17:43, 10 July 2025 (UTC)[reply]
As an editor who has provided a very critical review, I’m not concerned about the time the review has been active. It has been Featured for several years in roughly the same state. A month is pretty normal and I expect it’ll be moved to FARC soon (I’m going to post a follow up review tomorrow, which is how the process works). The moment we start speeding up the process of delisting, you will see (for example) large swathes of gender related content beset by meaningless and inaction able critiques to force delistings. WP:There is no rush. — ImaginesTigers (talk) 09:16, 11 July 2025 (UTC)[reply]
All the common slogans of Wikipedia sound incredibly hokey, if not conceited, to those who are opposed to wikis, the free knowledge movement, ... even the tagline itself, what if someone thinks "no such thing as a free lunch!", we have pages explaining free as in libre vs free as in gratis! This is just a walking on eggshells mentality which is not productive. Dege31 (talk) 16:38, 9 July 2025 (UTC)[reply]
I don't see how either the FA or GA process is niche. If you were talking about WP:ACLASS, then sure, that would be truly niche. But almost 1% of all articles are already either FAs or GAs. As long as it links to the actual WP:FA and WP:GA pages, it isn't any more niche than the topicons already there, which I'd argue are even more cryptic to the casual reader. Epicgenius (talk) 18:16, 9 July 2025 (UTC)[reply]
Less than 1% is pretty niche. How many Wikipedia articles would you have to read to have a 50:50 chance of stumbling on one of the 0.76% that are GA, FA, or FL? NebY (talk) 18:34, 9 July 2025 (UTC)[reply]
But GAs and FAs are some of the most-frequented articles that readers are likely to bump into. They're not randomly distributed. Cremastra (talk) 18:56, 9 July 2025 (UTC)[reply]
Support per above; I have an extension installed which does practically the same thing. To partially address the concerns some users have about the taglines being potentially misleading b/c the GA/FA is super old, the extension says Currently undergoing review of its featured status etc when articles get re-reviewed. ❤HistoryTheorist❤04:21, 10 July 2025 (UTC)[reply]
Support It took me ages to find the tagline. I'd never noticed it, but support anything that lets our readers get more of a sense of relative fidelity of Wikipedia articles. A good thing that the GAR process is alive and kicking: we've been able to remove the icon from the 'worst' articles in recent years. —Femke 🐦 (talk) 07:32, 10 July 2025 (UTC)[reply]
Oppose. We should not be misleading readers into thinking that the article rating is objective or meaningful when it is neither. Thryduulf (talk) 08:19, 10 July 2025 (UTC)[reply]
Are you arguing the average featured article is not better than the average article? Because that's what article ratings having "no meaning" would mean. The reality is the opposite. The average featured article is way way better. IAWW (talk) 15:29, 10 July 2025 (UTC)[reply]
@It is a wonderful world by what objective measure is the comparison being made? What is the definition of an "average article" and an "average featured article"? The median-length featured article is definitely going to be longer than the median-length non-featured article but length alone is not a reliable indicator of anything other than length (e.g. an article that is two thirds reactions from random celebrities on Twitter is worse than an article one third its length that is purely encyclopaedic). Article ratings are meaningless in that they do not reliably convey to the reader any information about the quality of the current state of the article. Even a featured article rating simply says that someone put a lot of effort into satisfying a small number of other people that they put a lot of effort into the article at some point in the past. There is no requirement for writers or reviewers to be subject matter experts so there is no guarantee it is any more or less accurate than any other cited article. Ratings other than featured are worth less than the paper they are written on. Thryduulf (talk) 17:16, 10 July 2025 (UTC)[reply]
If there's a non-featured article whose quality is better than a featured article, that article should be made a featured article. Aaron Liu (talk) 17:45, 10 July 2025 (UTC)[reply]
That assumes that the current version of every featured article is of sufficient standard to be regarded as one of Wikipedia's best, that is simply not true. If you think the effort in getting a rubber stamp of approval from a self-selecting group of non-experts is worth the time it takes, good on you, but that doesn't make the rubber stamp meaningful to readers. Thryduulf (talk) 19:10, 10 July 2025 (UTC)[reply]
If an article does not meet the standards, you can be the one to delist it. The great bulk of articles do not meet Feature quality standards, therefore articles that do are in fact among the best. Aaron Liu (talk) 19:49, 10 July 2025 (UTC)[reply]
It doesn't matter what objective measure you use. Any measure which tries its best to rigorously define the heuristic concept of article quality will show featured articles are better than non-featured articles in 99% of cases. You can see this by picking random featured articles and random non-featured articles – seriously, just go and try it right now! You don't need to rigorously define "average" and "objective measure" or any other words to see this. IAWW (talk) 17:50, 10 July 2025 (UTC)[reply]
Any measure which tries its best to rigorously define the heuristic concept of article quality will show featured articles are better than non-featured articles in 99% of cases. citation needed. Thryduulf (talk) 19:07, 10 July 2025 (UTC)[reply]
The sentence after: "you can see this by picking random featured articles and random non-featured articles" – go try it IAWW (talk) 19:16, 10 July 2025 (UTC)[reply]
https://doi.org/10.1609/icwsm.v3i1.13959 empirically derived features of FAs from FAC discussions, and for two articles I've tried it seems to work. Regardless, Wond's claim did not say the measures have to be objective; that's what you introduced. To see whether an article has better quality, we only need to agree in our judgement, no matter whether it is based on subjective criteria or objective criteria. Aaron Liu (talk) 19:53, 10 July 2025 (UTC)[reply]
Reading the abstract of that 2009 study (I don't have time to read more), it seems to only show that articles that were awarded featured status reliably contained the features the FAC process looked for - which is unsurprising, not really relevant to this discussion, says nothing about whether those features do indicate quality (if the featured article criteria required every featured article to contain a sentence about the colour red and every featured article did contain such a sentence, that would indicate that the FAC process is following its own rules, but wouldn't say anything about the article quality) and may or may not still hold true nearly 15 years later.
To see whether an article has better quality, we only need to agree in our judgement, no matter whether it is based on subjective criteria or objective criteria. true, but no criteria (objective or subjective) were specified let alone agreed - I asked what objective criteria were being used to back up the claim (and still haven't got an answer) because while we could agree to use subjective criteria to verify the claim I do not agree that such would be both relevant and meaningful. Also, it's worth pointing out that putting the article status in the tag line is not agreeing anything with anybody, or telling anybody anything about the average Wikipedia article. It is claiming that this version of this article is an example of Wikipedia's best work. That is not reliably true. Thryduulf (talk) 20:47, 10 July 2025 (UTC)[reply]
Fair point. I still maintain that you should use whatever subjective criteria you should stand behind, but ORES scores also show quality. I strongly disagree that subjective criteria are meaningless. I'm sure we all know the meaning in having "good" article quality, and that is of course subjective. It is meaningless to ask for objective assessments of something being better if we can agree using other criteria that something is better much faster, especially when the selection of such "objective" criteria is, in itself, subjective. All I'm saying is the near-tautology of subjective assessments being able to produce the subjective assessment of "good quality", while you're saying that only objective assessments will suffice, an unfalsifiable claim if you cannot provide an objective measure. The topic of "this version" is being discussed elsewhere in this RfC. Aaron Liu (talk) 21:33, 10 July 2025 (UTC)[reply]
I'm sympathetic to your main argument, that labeling articles at some point in time is incompatible with the wiki model. But I think your comments rubber stamp of approval from a self-selecting group of non-experts, even GA only requires that citations exist, an article that is two thirds reactions from random celebrities on Twitter is worse than an article one third its length that is purely encyclopaedic, and ratings other than featured are worth less than the paper they are written on are very dismissive of the work content reviewers do and I don't think you should be surprised you're getting piled on here over them. Dan Leonard (talk • contribs)19:54, 10 July 2025 (UTC)[reply]
What pile on? It's about even in terms of people who (broadly) agree with me and people who (broadly) disagree. The final statement you quote from me is entirely a matter of opinion, we can agree to disagree regarding that. The quote about reactions relates only to article length not being a reliable metric of quality, I don't understand why you think that is dismissive of the work of content reviewers unless they do regard length as a reliable indicator of article quality? (If they do, that's definitely a black mark for the process).
By calling the result a "rubber stamp", the first one is an opinion. For the claim to be factual, you would need to show FAC does not disagree with its insiders, which is verily false. Aaron Liu (talk) 21:34, 10 July 2025 (UTC)[reply]
I'm really disheartened by the comments decrying the content review process here. IAWW's review of an article I wrote was one of the most enjoyable editing experiences I've had on here, and it was very comprehensive and involved a text-source integrity check. Reducing his work to a rubber-stamp without citation checks is insulting. Dan Leonard (talk • contribs)20:30, 11 July 2025 (UTC)[reply]
There are GA reviews like that, but there are also GA reviews like Talk:I-No/GA1. As Stepwise stated below, promoting articles to GA status only requires one person's approval. Some1 (talk) 20:40, 11 July 2025 (UTC)[reply]
Is there a problem with the subject article that makes you think the review was conducted improperly? It obviously has fewer BLP and political considerations than the one I cited so the prose does not need to be checked as closely. Regardless, it still gets a topicon with a "this is a good article" tooltip so I don't see why the modified tagline would be so extreme an addition. Dan Leonard (talk • contribs)20:51, 11 July 2025 (UTC)[reply]
I don't believe the review was conducted "improperly", but find the differences in the lengths and comprehensiveness of the two GA reviews quite jarring. Some1 (talk) 23:21, 11 July 2025 (UTC)[reply]
The first two are factual statements Ha ha. No they aren't. I'm not sure why you're taking this opportunity to complain about editors who want quality articles, but your second statements is clearly false. Perhaps you should look at the GA criteria, which are loose but set a baseline of acceptable quality content, before making clearly and egregiously incorrect statements, which at this point is approaching disinformation. Cremastra (talk) 01:22, 11 July 2025 (UTC)[reply]
Discussion elsewhere has identified that the GA criteria I was reading and the GA criteria that are actually applied are different, so while I thought that was factual it turns out that it wasn't. The first is though.
I'm not complaining about editors wanting quality content - far from it - what I'm saying is that article rating labels are not a reliable guide to the quality of the current version of an article. I'm also saying that the FA and GA criteria used to award those labels are not a guarantee that the version of the article reviewed is one of Wikipedia's best, just that it meets those criteria. If you think that is an attack on editors then you haven't been reading what I've actually written. Thryduulf (talk) 01:35, 11 July 2025 (UTC)[reply]
I mean, the GA criteria excerpts the part from the "how the GA criteria should be applied" guideline on spot checks being minimum, so you could say it is in the GA criteria you were reading. That is an interesting state of affairs indeed. Aaron Liu (talk) 15:01, 11 July 2025 (UTC)[reply]
If the GA criteria as written differ from the GA criteria as applied in practice, then we definitely shouldn't be proclaiming GA status in the tagline. Overloading the ordinary word "good" with an insider meaning is confusing enough. Expecting that people will read a set of criteria and then a further guideline to figure out what "good" is supposed to mean is... not really practical. Stepwise Continuous Dysfunction (talk) 18:41, 11 July 2025 (UTC)[reply]
Maybe you know that that's the only relevant part of that guideline. Maybe someone would figure that out after reading both. But it's not at all clear. Every time a reader has to investigate a behind-the-scenes Wikipedia page to understand what something means, we've failed. Stepwise Continuous Dysfunction (talk) 19:52, 11 July 2025 (UTC)[reply]
We have explanatory essays that go in depth on the specific meanings of everything. That does not undermine the meaning of what is explained at all. The criteria by itself sufficiently explain what is expected of GoodArticles. Aaron Liu (talk) 20:00, 11 July 2025 (UTC)[reply]
That's a pretty serious claim you're making. Do you have any objective evidence that the process is this fundamentally useless? None of the criteria for good and featured articles, after all, are not length, so if they don't measure anything else, that's pretty serious. You think the process is so bad that even checking the sources doesn't increase the average accuracy, that it's just a rubber stamp? This all sounds pretty unbelievable to me, but maybe I'm wrong. If this is all true, why do you think the average participant of this RfC is ignorant of it? Dege31 (talk) 17:57, 10 July 2025 (UTC)[reply]
I do not have evidence for a claim I am not making. Checking the cited sources do verify the content they claim to verify is extremely valuable but only a small part of what is required to get the FA badge, not required for any other rating (even GA only requires that citations exist) [see later discussion, it turns out the documented GA criteria I based that comment on do not match the GA criteria that are actually applied. Thryduulf (talk) 01:42, 11 July 2025 (UTC)], and something that can be done completely independently of the FA process. My claim is that FA status does not reliably communicate anything useful to readers about the current version of the article. The current version of the article might be better than average, even one of Wikipedia's best, but it might even be below average now. Thryduulf (talk) 19:16, 10 July 2025 (UTC)[reply]
That's no longer true. Funnily, the new GA checks are in some sense more strict that the FA criteria on WP:TSI. All GANs require spot checks (since 2023 or so), whereas only newer FA nominators have their articles spot checked. —Femke 🐦 (talk) 20:27, 10 July 2025 (UTC)[reply]
That's good to know, but if we can't even reliably communicate what the GA criteria actually are to editors who know that "good article" is jargon then it is even less useful information for readers than I previously thought it was. Thryduulf (talk) 21:16, 10 July 2025 (UTC)[reply]
The proposed destination for the modified tagline is Wikipedia:Good articles, which states (emphasis mine)
A good article (GA) is a Wikipedia article that meets a core set of editorial standards, the good article criteria, passing through the good article nomination process successfully. They are well-written, contain factually accurate and verifiable information, are broad in coverage, neutral in point of view, stable, and illustrated, where possible, by relevant images with suitable copyright licenses.
Also, I think you may have missed footnote 3 in WP:GACR6, which states "at a minimum, check that the sources used are reliable ... and that those you can access support the content of the article". I think these adequately explain to readers that a good article has had its sources checked for verifiability. Dan Leonard (talk • contribs)21:23, 10 July 2025 (UTC)[reply]
Right, I see what you mean now. I understand the concern, but personally, with the (re)activation of the good & featured article review process, I don't personally think it's as critical. Would you also support removing the good article and featured article topicons, by the same logic? Dege31 (talk) 23:03, 10 July 2025 (UTC)[reply]
It's not something that bothers me enough to propose myself, especially as some people seem rather attached to them, but I would probably support if someone else were to propose it. Thryduulf (talk) 23:08, 10 July 2025 (UTC)[reply]
I've struck with a note as it's slightly more complicated than simply being incorrect, see discussion subsquent to my comment about why I made that statement. Thryduulf (talk) 01:42, 11 July 2025 (UTC)[reply]
There is no requirement for writers or reviewers to be subject matter experts so there is no guarantee it is any more or less accurate than any other cited article. Yes, exactly. Schizophrenia is a Featured Article with almost 4k edits since its FA review back on May 2, 2011 (14 years ago). Who knows if that article is still accurate or up-to-date, but because of its FA status, readers will blindly trust that the article and its content are accurate. Some1 (talk) 18:39, 11 July 2025 (UTC)[reply]
Oppose Per Thryduulf - GA particularly has little to do with quality and is more of an Wikipedia:Esperanza-like process to promote the participants. The GA talkpage currently has an RFC to enforce Quid pro Quo reviewing of articles and to reduce the standard of reviews. GA reviews are in many cases completely subjective and amount to little more than "I like this" or "I don't like this".Nigel Ish (talk) 17:23, 10 July 2025 (UTC)[reply]
It is a bit subjective, yes, but there are detailed criteria on how articles should be evaluated for GA. GAs that don't meet the criteria go through GAR. The linked "reduce the standard of reviews" discussion is not about reducing the standard of reviews but about reviewers who make additional comments beyond the standard of the reviews. And the quid prop quo proposal RfC is currently met with a swarm of opposition. Aaron Liu (talk) 17:48, 10 July 2025 (UTC)[reply]
At this point this discussion discussion has devolved into GA-bashing by people who apparently don't want any kind of quality control and for who any recognition of hard work is evidence of a social clique. Cremastra (talk) 01:18, 11 July 2025 (UTC)[reply]
I don't think I'd ever noticed the tagline before, but I've definitely seen the topicons. The fact that they're coloured images makes them more noticeable than small italics, but having linked text in the tagline would probably cover some of that deficit. Maybe I've overestimating the readers, but because "good article" doesn't have a standard colloquial meaning, I think that if a reader did notice that the tagline said that, there wouldn't be any standard meaning to assume. If they wanted to know what it meant, they might click the link and learn more about the internal processes of the encyclopedia. If they didn't, they wouldn't walk away with any wrong assumptions. "Featured article" is a little different - assumptions could be made - but the meaning could vary wildly. Maybe this so-called "featured" article was chosen at random somehow to feature on the main page at some point in the past. I think the topicons make the meaning clearer, appearing to be badges the article has achieved somehow, but I don't think the additional text in the tagline would harm the project (outside of potential technical burden). 207.11.240.2 (talk) 08:59, 10 July 2025 (UTC)[reply]
Oppose - because as written, the tagline is misleading. For instance, the first example listed: London Beer Flood. When you go to the talk page, it is clearly tagged as: London Beer Flood is a featured article; it (or a previous version of it) has been identified as one of the best articles produced by the Wikipedia community. So it is misleading to imply to our readers that the current version they are reading is the FA version.Isaidnoway(talk)18:28, 10 July 2025 (UTC)[reply]
I think that'd be a good thing. If an article's current state is incongruent with what one expects from being "one of the best articles", readers would be alerted to raise the issues somewhere. This can help ensure quality within FAs. Also, <pedantic>, the banner you quoted says the article or a previous version met the definition, and that the article is a featured article, not that it might be a previous version that is the featured article instead of the current version. Aaron Liu (talk) 20:00, 10 July 2025 (UTC)[reply]
No, what it means is that the FA article could be the current form or an earlier, possibly different, iteration of the article could be the FA. For instance, Michael Jackson was promoted to FA status 17 years ago, and on July 8, 2025, there was a brief edit war over a cleanup tag placed in a section. The article had 16,000+ pageviews that day, so how many readers (hundreds, thousands) read a version (current version) that didn't meet the criteria for a FA, and we shouldn't expect for our readers to try and hunt for a previous version that actually meets the FA criteria. I mean, if we are going to say to our readers with a tagline - the current version you are reading meets the criteria for a FA, but yet editors are squabbling over content that may not reflect what the cited sources actually say, then yeah, go ahead with a misleading tagline.Isaidnoway(talk)23:54, 10 July 2025 (UTC)[reply]
The article was still designated FA. The definition of FA is that the article or a previous version was reviewed and met criteria, not necessarily the current version even if the FA-designation is the status quo. I'm not saying we should expect our readers to hunt for that previous version; I'm saying that increasing this prominence invites readers who realize the incongruence to challenge. I don't see how the cleanup tag changes anything in your argument's favor here. Aaron Liu (talk) 00:47, 11 July 2025 (UTC)[reply]
invites readers who realize the incongruence to challenge the vast majority of readers will not recognise the incongruence, but will blindly trust that an article that proclaims to be top quality is top quality, even if it contains blatant misinformation. Even editors with years of experience working with featured articles will not always see an incongruence for topics (or even topic areas) they are not familiar with. Thryduulf (talk) 00:55, 11 July 2025 (UTC)[reply]
Sorry I missed this reply earlier, but I'm struggling to understand what relevance a banner has to anything in my comment? Thryduulf (talk) 18:58, 22 July 2025 (UTC)[reply]
It's alright. I was referring to maintenance tags. If the maintenance tags that are about eight times larger than the tagline (on desktop; on mobile it's probably gonna be like 3x) and colored in alarming ways say the article contains misinformation, the reader will believe the article contains misinformation over the tagline that says "featured article". Aaron Liu (talk) 19:15, 22 July 2025 (UTC)[reply]
True, but only a very small portion of current revisions (at the time any given reader loads the article) of good or featured articles that are not of that quality (due to vandalism, gradual degradation, changing standards, link rot, POV-pushing, real-world changes, editing disputes, etc, etc, etc) have maintenance tags. Thryduulf (talk) 20:25, 22 July 2025 (UTC)[reply]
I guess that's where we diverge. I have not seen any GA/FAs that have problems untagged for a significant amount of time. Would you give me a post-Coldwell example? Aaron Liu (talk) 20:33, 22 July 2025 (UTC)[reply]
I don't know what you mean by "post-Coldwell" but see everything just before it was sent to FAR/GAR, every vandalised revision, etc. It doesn't matter how long the page is below the standard, it matters that whenever someone views a revision that is below standard (for whatever reason) the tag would be misleading. Sometimes only in a very minor way, other times in extremely major ways and of course everything in between. Thryduulf (talk) 10:09, 23 July 2025 (UTC)[reply]
You have a point. Still, I think this deserves a trial to see if the increased visibility will bring more articles to maintenance categories or GAR and thus counter the issue you describe. Aaron Liu (talk) 17:59, 1 August 2025 (UTC)[reply]
The article had 16,000+ pageviews that day, so how many readers (hundreds, thousands) read a version (current version) that didn't meet the criteria for a FA - Kind of beside the point, but an article doesn't automatically change from "FA quality" to "not FA quality" just because there's a tag (and similarly for GA). Instead it's usually one of two situations:
The tag was justified, and therefore the article was already not up to FA/GA standard beforehand. It can be resolved, or the article brought to WP:FAR/WP:GAR if issues are pervasive enough.
The tag was not justified, nd therefore it changes nothing about the article's rating.
Though, I can't argue with the fact that the current version of an article that previously passed an FAC or a GAN may not necessarily be up to standard. That's why substandard articles are (and should be) listed at FAR or GAR. Epicgenius (talk) 03:43, 11 July 2025 (UTC)[reply]
On MJ's article, if you or I ran across the maintenance tag, sure, we would know it could be either one of the two situations you listed, but would our readers? If this prominent tagline had been in place on MJ, bragging about this is one of our very best articles, and a reader scrolls down to a section that is tagged with - the content you are about to read may not reflect what the cited sources actually say, they are going to walk away scratching their heads, thinking, this is their very best? Of course, this situation would hold true with the FA icon already present, but I just don't see how adding this prominent tagline (more bragging) is a benefit to our readers, when it has the potential to be misleading. It's bad enough these unnecessary icons are already on the page.Isaidnoway(talk)06:50, 11 July 2025 (UTC)[reply]
Oppose, per a combination of Ahecht's arguments (scope creep: rating is not what the tagline is for; and "a good article from Wikipedia" sounds bizarre for everybody not familiar with the technical meaning) and Thryduulf's (rating status is far too unreliable for such a highlighting to be responsible). I may add that both arguments apply particularly strongly to "good articles", for which I would oppose this proposal very strongly. Fut.Perf.☼19:20, 10 July 2025 (UTC)[reply]
Support - clearly sensible, not least as readers on mobiles do not get to see the FA or GA icons. Whatever the merits or demerits of the GAN and FAC procedures, these articles do have a defined level of quality and it's helpful for readers to know that. Chiswick Chap (talk) 08:56, 11 July 2025 (UTC)[reply]
these articles do have a defined level of quality. No they don't. A previous version of the article was assess as having a defined level of quality, but there is no guarantee that the version of the article the tagline is displayed on bears any resemblance to that version. Thryduulf (talk) 09:53, 11 July 2025 (UTC)[reply]
This is just one of the things where Wikipedia works better in practice than in theory. "There is no guarantee that any of this is true" is correct for all of Wikipedia, yet it is highly trusted and extremely widely used. —Kusma (talk) 10:11, 11 July 2025 (UTC)[reply]
Indeed, but that's completely different to a prominent banner saying "this is our best work" with links saying that our best work has been verified etc, being placed on articles that are anything but our best work. While many people seeing a page that has been very obviously vandalised will realise that it has been vandalised, not everybody will and the more subtle the vandalism (or POV pushing, etc) the fewer people will know not to take the statement at face value. Doubly so if the article's POV has been slanted towards a POV the reader happens to share. Thryduulf (talk) 10:26, 11 July 2025 (UTC)[reply]
Thryduulf, I think you overestimate the amount of change that quality articles, especially FAs, see after their review. Ovalipes catharus has some small additions of references and phrasing tweaks ([35]) since it was promoted in January. Malicious edits would be reverted, which leaves potentially problematic edits down to POV-pushing, addition of inaccurate information, and bad writing. These would probably all be caught by the person who brought it to FA in the first place. Cremastra (talk) 15:00, 11 July 2025 (UTC)[reply]
All those mallicious edits, etc were current revisions before reversion. The person who brought it to FA is not watching it 24/7. Also, changes accumulate over time God of War III was promoted to FA in February 2015, it has since undergone significant changes. Is it still FA quality? I have absolutely no idea. Do I trust a 10-year-old rating? if yes, then it's misleading if I happen to have viewed it one of the many reverted revisions was current. If no, then it's pointless. Thryduulf (talk) 15:48, 11 July 2025 (UTC)[reply]
Well, yeah, these intervening 9 years count for almost half of Taylor Swift's career. I wouldn't expect any article, let alone Swift's article, to remain unchanged in that time period.As for the article being bloated and outdated, that is less relevant to the topic currently at hand (mentioning FA status in the tagline) and more like a WP:FAR issue. – Epicgenius (talk) 19:58, 11 July 2025 (UTC)[reply]
The fact that there are complaints about the featured article(s) just illustrates that these article ratings are subjective, provide little meaningful information to readers, and don't need to be given more prominence (and in this case, by modifying taglines, of all things). Some1 (talk) 20:17, 11 July 2025 (UTC)[reply]
these article ratings are subjective, There are literally objective criteria (WP:GACR, WP:FACR) that are used to evaluate articles for GA or FA status. So no, it isn't a subjective rating. The fact that there are complaints about the article just mean that people have opinions. These may indicate that the article doesn't meet the criteria. They may also be unjustified, however, as Dan Leonard indicates below. – Epicgenius (talk) 21:51, 11 July 2025 (UTC)[reply]
I think it's fallacious to imply that just because an article has reached GA or FA status, it shouldn't undergo changes. It's one thing for an article to be modified significantly after its promotion to FA or GA status. Sometimes, this is even required in order for an article to keep its rating, especially for articles about people who are alive or things that still exist.It's another thing entirely for these changes to have significantly degraded the quality of the article, but even a small number of changes by a small number of editors can degrade an article's quality. In short, quantity of changes != quality of changes. – Epicgenius (talk) 16:27, 11 July 2025 (UTC)[reply]
Whatever fallaciousness you might infer, I was not implying that just because an article has reached GA or FA status, it shouldn't undergo changes. I was responding to I think you overestimate the amount of change, began by saying many changes, and didn't discuss their quality or materiality. NebY (talk) 16:50, 11 July 2025 (UTC)[reply]
Whatever fallaciousness you might infer, I was not implying that just because an article has reached GA or FA status, it shouldn't undergo changes. If I was mis-attributing that to you, then I apologize. I was speaking primarily in the context of Thryduulf's comment; they claimed that there is no guarantee that the version of the article the tagline is displayed on bears any resemblance to that version. Which may very well be true, but that comment also implied that articles have to remain more-or-less static after their promotion, which is not the case. I was replying to your comment about the number of changes to selected GAs/FAs because I was trying to convey the fact that a large number of changes may not necessarily be an indicator of an article's decline in quality. It can be an indication of such a deterioration of quality, but this can also be done by one or few editors who remove large parts of an article. – Epicgenius (talk) 17:19, 11 July 2025 (UTC)[reply]
I wasn't saying that articles have to remain more-or-less static after promotion, and I'm not sure how you read that into my comment. I'm simply saying that because articles are not static, a previous version being assigned a quality rating is not a reliable indicator of the current quality of the article. It might be that there have been a thousand changes but no material change, it could be that there have been ten changes and the article is substantially different (which could mean it is worse, better or about the same quality). It is this changing nature that means the assessments are not a reliable indicator of the quality of the version displayed, so we should not be proclaiming that something is an example of our best work when we have absolutely no idea whether it is or isn't. Thryduulf (talk) 17:50, 11 July 2025 (UTC)[reply]
Support mildly increasing the visibility of our assessment processes. We should also strengthen GAR and FAR to ensure the designations remain meaningful. —Kusma (talk) 10:18, 11 July 2025 (UTC)[reply]
I think they are meaningful. I am using the opportunity to assert that FAR and GAR are important in ensuring that the designations are meaningful. We do not have to improve all processes to perfection before considering something like the present proposal. —Kusma (talk) 19:37, 11 July 2025 (UTC)[reply]
Not only is the term "good article" overloading the ordinary word "good", but also, getting that status for an article really only requires the approval of one person. We shouldn't make that look more official than it is.
It also requires the article surviving challenges to the good article status and the reviewer being in good standing.Why not give it a try and see if readers are confused? A lot of people here doubt they will be. Aaron Liu (talk) 19:09, 11 July 2025 (UTC)[reply]
A similar number of people have made very strong arguments that readers will be confused and/or actively mislead. Why should we dismiss those concerns just because some experienced editors with detailed knowledge of the procedures vaugely hope that readers will understand that when shove jargon in their face they will understand both what it means and also that it might not actually mean that? Thryduulf (talk) 19:47, 11 July 2025 (UTC)[reply]
Nobody is claiming readers will know right away what these terms mean, the idea is that they'll be clearer than the status quo of topicons. Czar's story in § Proposal 21: Make GA status more prominent in mainspace shows that readers currently don't understand what these icons mean and actually have serious misunderstandings. A plain-text phrase "good article" or "featured article", with a clear link to these meanings, will hopefully both alleviate confusion and onboard future contributors. Dan Leonard (talk • contribs)20:14, 11 July 2025 (UTC)[reply]
Another comment I somehow missed. If readers have serious misunderstandings about what the jargon means when it is tucked away in a corner and accompanied by a link and/or tooltip to an explanation, why would putting that same jargon front and centre not result in anything other than more readers with serious misunderstandings? Thryduulf (talk) 19:01, 22 July 2025 (UTC)[reply]
My complaint is not about the info being tucked away in a corner but about being obscured by an icon and a tooltip. Tooltip explanations are discouraged by most accessibility guidelines including our own because readers clearly aren’t hovering over them to learn what they mean. Replacing (or here, supplementing) icon-and-tooltip presentation with plaintext and a link is self-evidently clearer and less confusing. Dan Leonard (talk • contribs)19:11, 22 July 2025 (UTC)[reply]
It's not a defined thing but empirical, basically the chances of such reviews ending up at GAR. It's not a real thing besides just having reviews that fit the criteria. Aaron Liu (talk) 20:04, 11 July 2025 (UTC)[reply]
"Good" is a pretty good description, better than "featured" but I think the link will be enough for people to cope. —Kusma (talk) 19:39, 11 July 2025 (UTC)[reply]
If "Good article" actually meant something similar to the non-jargon meaning of "this article is good" then you might have a point. So while I applaud your optimism the evidence of how readers currently interact with Wikipedia suggest to me that it is significantly misplaced. Thryduulf (talk) 19:50, 11 July 2025 (UTC)[reply]
That established Wikipedians can have a good faith disagreement about what the phrase "Good article" means is more than enough evidence that it will mislead some readers. Thryduulf (talk) 22:22, 11 July 2025 (UTC)[reply]
Is there a GoodArticle you think is not good? If so, you should nominate that article for Review after starting a discussion about it, no matter how much the article has changed since it was reviewed. By something approaching induction GoodArticles are therefore good articles. I think the only situation where the GoodArticle process fails to produce good articles is if you believe the criteria are not enough to ensure "good", in which case I'd like to know. Aaron Liu (talk) 22:31, 11 July 2025 (UTC)[reply]
My point is that in Wikipedia jargon "Good article" means that a specific revision of an article was judged by one person to meet a set of very specific criteria (that the current version of the article may or may not now meet). To most readers seeing a tagline saying "good article" would indicate that the version of the article has been assessed to be "good" and thus can be relied upon to be neutral, accurate, and at least reasonably comprehensive and thus by implication articles that are not "good" are "bad" and cannot be said to be poses any of those qualities. While it is true that the current version of many Good Articles is indeed good there are also current versions of Good Articles that are not good. There are also plenty of articles where the current version is accurate, neutral and comprehensive but which are not Good Articles simply because nobody has formally assessed it. Thryduulf (talk) 22:45, 11 July 2025 (UTC)[reply]
there are also current versions of Good Articles that are not good
(besides what I say in the linked reply) Those are also very few.
by implication articles that are not "good" are "bad"
I don't think that's true. The rest are just unreviewed articles, and even not meeting the standard for good doesn't necessarily mean bad. I think this also addresses your last point. Aaron Liu (talk) 01:48, 12 July 2025 (UTC)[reply]
As an editor familiar with the review process you know that "not good" doesn't mean "bad". The same is not true of the average reader who does not know that "Good article" is jargon, let alone what it means.
Re current versions of Good Articles. If you mean stable versions then there probably are relatively few (but still a large number), however when you include every version that is current at some point it is much larger. There is no way for the casual reader to know whether the version they are seeing is the good version or the vandalised version. Thryduulf (talk) 02:41, 12 July 2025 (UTC)[reply]
Sorry, I meant that I doubt that's what readers'll interpret it is. WIthout "good" it's still "articles". I mean at any moment. I don't think aggregating anyone that had any version that was bad is meaningful. And it's not like RC patrol's gone handicapped. Aaron Liu (talk) 02:47, 12 July 2025 (UTC)[reply]
It does mean something similar, and I am indeed optimistic that our readers know that blue text means a link that can be clicked on to obtain clarification. Most of our readers are not using Wikipedia or the WWW for the first time. —Kusma (talk) 23:11, 11 July 2025 (UTC)[reply]
I'd argue that "featured" is a less confusing term than "good" in this context, since it's less generic and actually conveys the connotation that the articles were selected via some process. Stepwise Continuous Dysfunction (talk) 19:55, 11 July 2025 (UTC)[reply]
The proposal has indeed come up frequently. Some editors see increased visibility of article ratings as an improvement to the status quo, but if there is a problem with the status quo it is that it overstates the reliability and importance of article ratings, which is not something making them more prominent can solve (indeed rather the opposite). Thryduulf (talk) 17:26, 12 July 2025 (UTC)[reply]
Support as I like the idea of better signaling which of our articles have met a minimum bar for quality. GAs aren't perfect articles, but we show worse articles on the main page every day. Ed[talk][OMT]20:03, 12 July 2025 (UTC)[reply]
An embellishment is defined as ornamental, or decorative detail, to make something more attractive. Is it to your belief that the good article, and featured article processes are likewise embellishments? Dege31 (talk) 01:54, 17 July 2025 (UTC)[reply]
Support – for the same reasons I proposed more prominent topicons in 2021. As Wikipedia matures, I think it's increasingly important we 1) focus on raising the quality of existing content and 2) help readers learn how to effectively use and understand the varying quality of articles, especially in the current information landscape. Drawing attention to the main ways we review articles, however flawed they are, is a step in the right direction for both these aims, and by raising awareness of peer review processes it might help improve them. I think it would be even better if the "featured article" or "good article" text linked directly to the article's most recent FAC/FAR/GAN, but perhaps that wouldn't be feasible. I understand the valid concerns about the varying quality of FA/GA status articles, but ultimately it is better than no review at all, I trust that most readers understand Wikipedia is not infallible, and the more we focus on peer reviews the better for raising quality and trust in the project. Jr8825 • Talk12:26, 15 July 2025 (UTC)[reply]
Support ways to make GA/FA status more prominently visible, including this proposal. My preferred way of going about it would be to have the icon next to the article title, kind of like how (on desktop) the icon is displayed next to the name of another language in the "Languages" list if that version of the article is good or featured (see e.g. Jupiter). Several of the opposing comments sound more to me like arguments to abolish GA/FA (or at minimum the icons) entirely, which I am fairly certain is a proposition that would be overwhelmingly rejected by the community. TompaDompa (talk) 23:35, 16 July 2025 (UTC)[reply]
Oppose, per several of the arguments made above. If this is intended to bring in more editor participants, we're sending a confusing signal to a group very few of whom are the right target. The terms are opaque and likely to be misleading to our readers, since there are plenty of GAs that are no longer good quality but have not been reassessed yet. Fewer FAs are in that state, but there are some. If the GAR and FAR processes were working as well as we'd like, this would be less of an issue, but we haven't solved that problem yet. Future Perfect at Sunrise puts the case against well. Mike Christie (talk - contribs - library) 00:20, 17 July 2025 (UTC)[reply]
Support trying this out, at least for some period. I believe Wikipedia should try to make GAs/FAs more visible to the common reader, and I think more awareness may also lead to more GAR and FAR helpers. ALittleClass (talk) 02:38, 18 July 2025 (UTC)[reply]
Is there some other language we could rename GAs/FAs to to connote that they have undergone more thorough review and received a higher quality assessment than other articles, without implying that all our other articles are trash? I do think the concept of article quality assessments for articles should be fairly intuitive to most readers, Wikipedia being a work in progress and all that. Sdkbtalk15:25, 21 July 2025 (UTC)[reply]
The problem is that, at least as things currently stand, articles that there is a set of articles that have been assessed as being of a particular quality at some point in their history and a set of articles that are currently that standard of quality. The two sets overlap but are not close to being the same with both high quality articles that have not been assessed as such and articles that were formerly high quality no longer being. Unless and until the significant majority of articles tagged as being of "X" quality currently (at the time any given reader loads the page) are that quality and the significant majority of articles that are that quality are tagged as such any tagline will be inherently misleading in some way. Thryduulf (talk) 15:39, 21 July 2025 (UTC)[reply]
You could get around some of that by something that says something like like "on <date>, a <version> this article was assessed as being <quality standard>" with a link to that quality standard and an explanation that the current version may or may not be of that quality standard, but (a) that isn't a tagline, and (b) is not what is being proposed here. Thryduulf (talk) 15:42, 21 July 2025 (UTC)[reply]
We cannot let the perfect be the enemy of the good. Part of our responsibility of editing the encyclopedia is to ensure that articles that should be FAs/GAs are nominated and that those designated as such but that no longer meet the standards are delisted. It's no different than having an article tagged as needing more citations: That tag was placed at a specific point in time, and represents our judgement at that time, but it doesn't imply that other articles don't also need more citations. And if, as the article evolves, it acquires enough citations, it's our responsibility to remove it. The articles tagged as needing more citations will never correspond precisely to those that actually do need more citations the most, but we still use the notice since it's a good enough (albeit imperfect) indicator. Ditto for quality article assessments. Sdkbtalk16:00, 21 July 2025 (UTC)[reply]
It isn't an integral part of the encyclopaedia, it's an optional status symbol. Just because that status symbol motivates some editors to improve articles doesn't make it integral - look at the countless articles that get improved in other ways and for other reasons. Thryduulf (talk) 17:20, 21 July 2025 (UTC)[reply]
We cannot let the perfect be the enemy of the good. That's true in the abstract, but this proposal is not good - indeed for the reasons explained in detail multiple times it's actually harmfully bad. The comparison to dated tags that specify in detail what the problem is/was and do not proclaim or imply anything about other articles misses the mark in multiple different ways. Thryduulf (talk) 17:16, 21 July 2025 (UTC)[reply]
The German Wikipedia approaches this by putting de:Template:Exzellent at the bottom of pages with a notice "This article was added to the list of excellent articles on day (DD_MM_YYYY) in [permanent_link_to_version this version]. See today's featured article, de:Abreise König Wilhelms I. zur Armee am 31. Juli 1870. That also has serious downsides, for example de:J. R. R. Tolkien links to a version from 2004 that does not have a single inline citation and does not actually meet modern day standards. "The 2004 version of this article met the 2004 version of WP:FA?" is not particularly useful information. —Kusma (talk) 10:22, 31 July 2025 (UTC)[reply]
The latter issue might be mitigated by only displaying the message if the article was promoted or had its status confirmed within the last N years. The German Wikipedia has (or at least had) a very different approach regarding inline citation to the English Wikipedia, so the status of articles is not trivially comparable between the languages. Thryduulf (talk) 10:39, 31 July 2025 (UTC)[reply]
It might not do that to you, but it does to me and Andy and assuredly will to anyone who doesn't know that "good article" is jargon (regardless of whether there is or isn't a link). Thryduulf (talk) 09:54, 22 July 2025 (UTC)[reply]
I really don't think we have enough GAs or FAs that the absence of a "good article" tagline will be so widely noticed. I don't think the proposal will be as impactful as you and Andy seem to think, but we won't find out if we don't try it. —Kusma (talk) 10:01, 22 July 2025 (UTC)[reply]
Whereas I believe that the multiple severe downsides (not just this one) combined with the extremely low benefits that will come even if successful mean that even a trial will come up with a significantly negative benefit:cost analysis. Thryduulf (talk) 12:10, 22 July 2025 (UTC)[reply]
Is there any evidence of severe (!) downsides outside of hypothetical Wikipedia editor discussions? We already have the topicons. Why don't we see any inklings of these severe downsides, if they are a realistic concern? At least I'm not aware of any. Dege31 (talk) 04:08, 23 July 2025 (UTC)[reply]
The top icons are decoration that most people ignore and have to be investigated (but even then others have pointed out that they cause misconceptions). A tagline is extremely prominent and makes a bold statement to everybody reading the article (even more so if it is expanded to mobile) meaning the problems caused by misleading statements will be very significantly amplified. Thryduulf (talk) 10:13, 23 July 2025 (UTC)[reply]
Oppose I'd not noticed the taglines before and suppose that I've been blanking them as fluff. The specific suggestion of calling out FAs and GAs seems quite marginal as we don't have many of them. Why not give an assessment of the article when it has a lesser status too? It might be more useful to warn readers that an article is a stub or just C-class or whatever.
And I don't like the idea that this will be forced onto the mobile interface as space is at a premium in that. See the example of Dopamine which I took a snapshot of for another discussion recently. Notice that this doesn't manage to get all of the first sentence of the article onto the first screenful. Adding a tagline would push it off completely.
So, the idea of giving readers an assessment of the article upfront has merit but the implementation needs work.
Re: the specific suggestion of calling out FAs and GAs seems quite marginal as we don't have many of them: the good and featured systems have broad community support and are currently represented on articles already by topicons with tooltips like "this is a good article". This proposal is intended only as an extension of that as shown above in § Background (tagline), and so any extensions beyond what is already very highly supported would be undue. Also re: it might be more useful to warn readers that an article is a stub or just C-class or whatever a "warning" would violate WP:NODISCLAIMERS. Dan Leonard (talk • contribs)18:30, 22 July 2025 (UTC)[reply]
WP:NODISCLAIMERS is irrelevant. Every page has a general disclaimer per WP:GENDIS. And there's already a well-established set of tags to show that that an article is a stub. The trouble is that these appear at the bottom of articles where the reader won't see them until it's too late. It's better to make the status of an article clear to the reader at the outset, so that they have this context as they are reading it. Andrew🐉(talk) 22:28, 22 July 2025 (UTC)[reply]
You literally used the word "warning", though. That's exactly what NODISCLAIMERS is about. This proposal is about promoting articles that have reached a high standard of quality that the community is proud to present to readers. Giving a "warning" to readers that an article is "just C-class" is the opposite. That could be considered at a later point but should not be part of this proposal. Dan Leonard (talk • contribs)22:32, 22 July 2025 (UTC)[reply]
B-class and lower can be changed by anyone anytime. I'm not confident in the quality assurance for those.Also, if you want more mobile screen space, dismiss that banner. Aaron Liu (talk) 18:42, 22 July 2025 (UTC)[reply]
Re:mobile accessibility- that might be easy for you or me, but the "dismiss banner" button is *really* tiny on mobile. I don't think my mother could reliably click it, for example, she just doesn't have the eyesight anymore. GreenLipstickLesbian💌🦋18:51, 22 July 2025 (UTC)[reply]
Fair point. But that's an issue we could easily solve by enlarging the button; we don't even need to file a task for it as we can simply do it through an interface admin. Aaron Liu (talk) 19:11, 22 July 2025 (UTC)[reply]
Support. This would be a positive for readers and editors alike. Perhaps people opposed should also advocate for removing WP:TMVs from articles—they link to editor-focused stuff as well. We have giant banners when an article has issues, but a small link when it has been determined to meet a set of standards is a bridge too far? Heartfox (talk) 03:15, 23 July 2025 (UTC)[reply]
Weak oppose I like tag lines to be the same for every article. If it is to be tried, I would propose to do it for the Featured articles first. Readers are more likely to have heard from them from the main page. The articles are higher quality and more editors are needed to certify them as featured. The Good article slogan sounds worse. Ideally it should be measured whether readers understanding of the featured article process increases after the change. Rolluik (talk) 09:02, 31 July 2025 (UTC)[reply]
I think it makes sense to do that first. I have not myself participated in a FA or Good article process. I'm aware of the cleanup efforts for older FA and Good articles (and also that it seems to have stalled for the featured articles). I think that new featured and good articles seem mostly similar quality wise for most readers but as an editor I see that the featured ones have mostly better sources. Keep in mind that English is not my native language, so I care less about spelling mistakes and similar issues. I'm sceptical though that changing the tag line will have a big effect on anything (increase of FAC's, Good article nominations, FAR's, readers knowledge of quality assesments...). I don't think it will be detrimental either. Maybe we should give people an easy link to the version of the article that was reviewed in the tag or near the tag (not just on the talk page). I see no real problem with giving newer FA's that were on the main page this tag line (If we were confident enough to put it on the main page...). Rolluik (talk) 20:16, 4 August 2025 (UTC)[reply]
Strong oppose. I'm sorry; I really believe the article status should be more visible, but I can't stand the tagline being modified in such a drastic way. In my opinion, the benefits of keeping the current tagline intact and free of links and other notices outweigh the benefits of letting the user know an article is good/featured. I'm all in for doing the same thing while keeping the precious tagline intact! --FaviFake (talk) 20:54, 31 July 2025 (UTC)[reply]
I'm guessing like the "this article is a stub" messages but at the top, perhaps. It could also include the most recent date it was promoted/survived review as recommended above. Aaron Liu (talk) 21:06, 31 July 2025 (UTC)[reply]
This seems fine to me, I mostly opposed the tag changing due to esthetic reasons. The only downside is banner blindness (and scrolling distance) but most readers seem fine with maintenance templates and similar; and featured/good articles are not supposed to have those. Rolluik (talk) 20:27, 4 August 2025 (UTC)[reply]
Strong oppose to "Good article" tagline, weak support to the rest. Our neutral point of view is one of Wikipedia's core content policies. It's not up to us to declare to the reader our articles are "good". I believe our quality article assessments are quite helpful for Wikipedia's editors and I'm happy with the current topicons (which [being icons] don't declare anything and link to the full explanation), but outright writing at the beginning that this is "A good article from Wikipedia" is not neutral. I'm attracted to the argument that this could increase new editor attraction but I don't see that outweighing the opposers' concerns. I also don't believe making the tagline more verbose in response would be a satisfactory workaround. Sophocrat (talk) 02:19, 1 August 2025 (UTC)[reply]
Note: I'm much more open to doing this only with Featured articles and lists due to the arguments others have made. As a bonus "Featured" is much more neutral than "Good". Sophocrat (talk) 02:24, 1 August 2025 (UTC)[reply]
Could you specify how exactly this proposal violates
All encyclopedic content on Wikipedia must be written from a neutral point of view (NPOV), which means representing fairly, proportionately, and, as far as possible, without editorial bias, all the significant views that have been published by reliable sources on a topic.
i.e. neutral point of view? An article assessment is not "view[s] that have been published... on a topic".
As Aaron Liu says I refer to the principle. We don't declare ourselves to be a reliable source (even though we strive to be!) to the reader. In articles we should avoid stating opinions as facts as our aim is to inform the reader, not make judgements for them. That said, I think I would support doing this only with Featured articles and lists as they have the highest quality standards and because the descriptor "Featured" is just a fact (as those are indeed prominent articles) whereas "Good" is a judgement from us (however well-founded). Sophocrat (talk) 21:36, 1 August 2025 (UTC)[reply]
Support I've been using a userscript that does something similar and it is quite useful. (Wish I could tell you which one, but nothing in my common.js is obviously it.) Loki (talk) 16:20, 4 August 2025 (UTC)[reply]
Weak oppose: On the one hand, it'd be simple, as there's already a gadget for this, it could just require flipping it to default-on. On the other hand, there's already a gadget for this - and more pointedly, we already put an icon in the upper right of the page header for FAs, FLs, and GAs, so having this be by-default seems slightly redundant. - The BushrangerOne ping only05:02, 8 August 2025 (UTC)[reply]
we already put an icon in the upper right of the page this proposal is mostly inspired by Czar's story here, detailing how readers are not just unaware of the meaning of icon-based indicators but actively misguided. I think text and a transparent hyperlink is a clearer presentation. Dan Leonard (talk • contribs)05:22, 8 August 2025 (UTC)[reply]
Strong support – I'll take anything at this point... time and time again we've needed increased visibility for our best articles (most readers don't even know these distinctions exist, let alone the difference between featured vs good)... – Aza24 (talk)21:31, 8 August 2025 (UTC)[reply]
Weak oppose My greatest concern is that most Wiki users have no idea about what this actually means, especially since "good" can be interpreted much differently. In my experience what most readers care about (almost exclusively) is factual correctness, being of course part of being a GA it's not the entire story and (hopefully) most other articles meet that standard too. Highlighting it there makes me feel like it's implying that other articles are inherently "bad" and cannot be trusted. I could however see it work out with FA as not being Featured misses such an implication in my opinion. Squawk7700 (talk) 23:08, 8 August 2025 (UTC)[reply]
Oppose. As much as I'm a fan of the FA and GA processes and like to gain such honours for the articles I've written, it's basically a Wikipedia internal concept. I don't think we should be publishing such things in a single line tag which is used across the Web, and lacks context for readers of they're not familiar with the processes. While in general, on average such articles are likely to be better written and more reliable than others, it's not a universal truth and it would be a mistake to imply in the tagine such articles can be implicitly trusted. — Amakuru (talk) 00:30, 15 August 2025 (UTC)[reply]
Don't FAs convey the quality status in a way that is already explicitly designed for public consumption, being featured on the home page, and indicated with an icon on pages for users that are not logged in? The GA process too implies a basic quality threshold has been reached, and is already displayed publicly. That some GAs or FAs fail to live up to their status is surely more of a clarion call for the review process than it is a reason to view the baby as no better than the bathwater. With the icons already present, the proposed changes aren't making anything visible that isn't already. As always, anyone interested in the context of the terms could navigate through to the explanations, as they can now with the icons. Iskandar323 (talk) 10:43, 15 August 2025 (UTC)[reply]
Amakuru isn't the only one to comment that the f.a. system is an internal process. Another problem is that this isn't available on mobile. Finally: I'm not aware if there was consensus or a discussion to implement the topicons. Logoshimpo (talk) 05:25, 22 August 2025 (UTC)[reply]
I would repeal the decision made for those two discussions since too many arguments here against this selfreference has been brought up. Logoshimpo (talk) 04:13, 23 August 2025 (UTC)[reply]
Support This small change would go a long way to help our readers see when an article is of a higher quality. The icons aren't immediately clear, but text with a link would be much more overt. The more we provide average readers with even a basic understanding of the back-end processes, which is sadly quite uncommon, the better I think they'll be able to engage with our articles. --Grnrchst (talk) 13:05, 20 August 2025 (UTC)[reply]
This small change would go a long way to help our readers see when an article is of a higher quality. no, it will let readers see when some previous version of an article was assessed as being "featured" or "good" and will imply that the revision of the article they are seeing is of that standard (it may or may not be) and that articles not so tagged are inferior (they might be, they might also be superior). I'm also not understanding why a reader should need to know anything about back-end processes in order to engage with articles? Thryduulf (talk) 13:37, 20 August 2025 (UTC)[reply]
I answered your question here — in short, it's helpful info for readers to know to what extent they should trust an article. And in the replies below, myself and others talk about the process by which editors monitor and delist GAs/FAs that no longer meet standards. It's not perfect, of course, but readers know that we are an imperfect work in progress. It's no different than maintenance tags, which also represent a judgement about an article from a particular point in time, which may be outdated but which we try to update if so. This proposal is also no different in kind from our current practice of displaying GA/FA topicons, which we do for the exact same reasons, the only distinction being that a tagline has a slightly higher chance of actually being noticed. Sdkbtalk14:43, 20 August 2025 (UTC)[reply]
This is a great point – the worst possible downside of this process is still no worse than maintenance tags (giant reader-facing banners that serve as an often outdated disclaimer) and is effectively the same as the long-accepted reader-visible icons in the top right. The average case, though, is an improvement that helps readers: re why a reader should need to know anything about back-end processes in order to engage with articles, readers have long shown a vague understanding that Wikipedia might have some kind of content review process, but are still very much unaware of how we make these judgments. See for instance the many first-timer comments like "who wrote this crap it's all wrong" that have plagued article talk pages since the beginning of the project. Linking curious readers directly to Wikipedia:Featured articles tells them exactly how articles are reviewed and provides an overview of our content policies. Dan Leonard (talk • contribs)15:03, 20 August 2025 (UTC)[reply]
Strongly oppose. There are already things like the featured star in the top right that indicate this information. Displaying it so prominently gives an undeserved sense of importance to a rather unimportant classification. In addition, the WIkipedia branding has been on articles for twenty years OmegaAOL (talk) 00:29, 5 September 2025 (UTC)[reply]
Support, conditional on there not being technical issues with the implementation (e.g. I think it would be bad to add a WP:EXPENSIVE call to every single page and then downwardly adjust the limit for actual page content to 499 but this seems surmountable to me) jp×g🗯️23:11, 13 September 2025 (UTC)[reply]
Discussion (tagline)
@Dan Leonard: Can we not also have FLC, FAC, GAN? like so...
{{#switch:{{#invoke:Page assessment raw|get_class|page={{FULLPAGENAME}}|project=Project-independent assessment}}| FA = A ''[[Wikipedia:Featured articles (linked from tagline)|featured article]]'' from
| FL = A ''[[Wikipedia:Featured lists (linked from tagline)|featured list]]'' from
| GA = A ''[[Wikipedia:Good articles (linked from tagline)|good article]]'' from
| FAC = A ''[[Wikipedia:Featured article candidates/PAGENAME/archive#|featured article candidate]]'' from
| FLC = A ''[[Wikipedia:Featured list candidates/PAGENAME/archive#|featured list candidate]]'' from
| GAN = A ''[[Talk:PAGENAME/GA#|good article nominee]]'' from
| From
}} Wikipedia, the free encyclopedia
OR, if getting the archive# and GA# might be tedious, we could simply say...
Can we not also have FLC, FAC, GAN? like so...
{{#switch:{{#invoke:Page assessment raw|get_class|page={{FULLPAGENAME}}|project=Project-independent assessment}}| FA = A ''[[Wikipedia:Featured articles (linked from tagline)|featured article]]'' from
| FL = A ''[[Wikipedia:Featured lists (linked from tagline)|featured list]]'' from
| GA = A ''[[Wikipedia:Good articles (linked from tagline)|good article]]'' from
| FAC = A ''[[Wikipedia:Featured article candidates|featured article candidate]]'' from
| FLC = A ''[[Wikipedia:Featured list candidates|featured list candidate]]'' from
| GAN = A ''[[Wikipedia:Good article nominations|good article nominee]]'' from
| From
}} Wikipedia, the free encyclopedia
This RFC proposal is intentionally limited to be an extension to the topicons, which already get enough community support to exist. I disagree with this idea (drive-by junk GANs shouldn't be shown to readers) but also just don't think we should overcomplicate the proposal by going beyond what is already represented by topicons. Dan Leonard (talk • contribs)16:30, 11 July 2025 (UTC)[reply]
Personally, I would better understand those on the oppose side for non-technical reasons, if they could bring in some real data, or real examples, of harm caused by the smaller outreach variants already extant: that is, the topicons, and the talk page assessments. After all, if it is problematic, there should already be evidence. I haven't seen this presented in significant levels. To me, these pitfalls feel remote, and rare. I feel like the potential downsides aren't so big that we can't even do a test run to see how it goes. The large majority of readers read within the confines of the lead paragraphs, so that lessens the potential cumulative impact, too.
Nonetheless, valid concerns. The supporters should also answer: is there will, and capability for scaling up the maintenance of these articles? While this has been ramping up in recent years, this imposes a higher standard.
I've also thought about an idea (this is not a proposal, but fuel for separate discussions, if I, or anyone else, wants to take it further) that maybe takes into account some of the reluctance. It would involve an article losing its reader-facing indicators of GA status or FA status after X years of no review, or Y edits if it's very high activity. That way, there would be a guaranteed minimal level of accountability. Dege31 (talk) 00:38, 12 July 2025 (UTC)[reply]
Eh, it’s a cosmetic change to the website so I think it's fine to balk at it subjectively. It is a shame that my proposal can't have any data or examples of how this would improve reader outreach (although there does seem to be some interesting-looking papers on FAs), as any analysis of such data would only be possible post hoc. If this passes I do hope to do a 30 day postmortem to see how many people click on the statistical redirects and see how many new editors participate in the project pages. Dan Leonard (talk • contribs)00:51, 12 July 2025 (UTC)[reply]
Regarding scaling up the maintenance of these articles, I hope that one side benefit of this passing may be that, if GA/FA status confers additional prominence compared to the status quo, there will be both more incentive for editors to pursue that status for articles that deserve it and more editors noticing/sending to FAR/GAR when an article has that status that does not deserve it. Sdkbtalk04:43, 15 July 2025 (UTC)[reply]
and something similar for FA. Though I do wonder how long after the RfC closers should the discussion be started and whether it should be started even if it succeeds. Aaron Liu (talk) 03:42, 9 August 2025 (UTC)[reply]
I just took a look at de.wiki and their rating system and I'd be more supportive about this proposal if our system would be more similar to theirs because their equivalent to GA "Lesenswerter Artikel" lit. "Article worth reading" reflects the meaning of GA a lot better than "good" in my opinion. But I get that that's unfeasible already because the translation is way too long and sounds a bit awkward. Squawk7700 (talk) 09:26, 9 August 2025 (UTC)[reply]
In addition, quality is not the only factor in what makes an article "worth reading" - a generally terrible article is very much worth reading if it contains a single reliable source that verifies as correct (or not correct) the one claim you are attempting to verify or it unlocks your understanding of whatever it is you are researching. Even a featured article is not worth reading if it doesn't contain the information you are looking for (which could be for many reasons, including not quite being in scope, the article being outdated, a source no longer being available, the relevant portion being removed (with or without consensus) or vandalised, etc). Thryduulf (talk) 16:20, 9 August 2025 (UTC)[reply]
I don't like this as much. While I support any addition of plaintext with wikilinks, the English Wikipedia has long had opposition to emphasizing old revisions. See for instance the massive difference between how pending changes are used between German and English. I think it goes against the wiki model and its core belief that articles always get better over time. Articles should never have prominent links to old revisions. Dan Leonard (talk • contribs)17:18, 9 August 2025 (UTC)[reply]
Could you elaborate on the PendChang difference or the opposition, especially its reason? I think when the wiki model works, it's isn't at all bad to highlight how the article has evolved since it was established to pass a minimum standard. I don't see how the inclusion of the link leads to any default implication that the article got worse. It's just a tool for all the examine, serving the "transparency" part of our ethos. AFAIK even on enwiki, logged-out users see the latest approved revision (an old one) on PendChang-protected pages by default. Aaron Liu (talk) 17:47, 9 August 2025 (UTC)[reply]
The reason we gave GAR and FAR is because classifying an article as GA or FA applies to future revisions, unless and until that status is revoked. It isn't just for the one reviewed version. If it were, we wouldn't still call them GAs and FAs or have processes for removal. Linking to historic revisions can confuse readers, especially when transcluded templates have since been deleted (the deletion of the lang-xx family breaks the first sentence of many historic revisions). Dan Leonard (talk • contribs)22:12, 9 August 2025 (UTC)[reply]
Those are about effectively applying pending changes to every single article. If we can have pending changes protection as it is at enwiki today, I don't see why we can't have a link to an old revision especially when it's labeled as an old revision. I still believe that having a link to the old revision is a useful point of comparison. Anyways, we can drop the revision link if needed. Aaron Liu (talk) 00:37, 10 August 2025 (UTC)[reply]
I referred to enwiki's rejection of dewiki Gesichtete Versionen as an example of the philosophical differences in the wiki model. You can see arguments like incompatible with the basic principles behind wikipedia ... they no longer qualify as a wiki (Erachima), against wiki ethos (IanOfNorwich), creeping implementation of flagged revisions in disguise (S Marshall), 'A rose by any other name?' (OmniArticleEditor). The German Wikipedia's practice of placing a little check mark on specific logged revisions of articles, and presenting them to readers as if they are better than or more reliable than the current one, represents a significant change to the wiki model akin to Citizendium. Articles are assumed to still improve after promotion, and if they decline then they are demoted. Kusma already discussed this above, with the example of a dewiki article that links to an old revision without images or inline citations and has broken template calls (as I mentioned). Dan Leonard (talk • contribs)01:08, 10 August 2025 (UTC)[reply]
Thanks for the ping to this interesting discussion. Although I personally oppose any and all implementation of Pending Changes, vehemently and on a philosophical level, if we are going to have to put up with the awfulness of Pending Changes in our Wiki, then Pending Changes interacts with Good and Featured Articles in complex ways and I'm leery of one-size-fits-all decisions. I think we need to be mindful that Good and Featured Articles are an anomaly -- a holdover from old days of Wikipedia, back when we got to say things like "This is a good article" without having a reliable source for that contention. I think the fact that these assertions are made by Wikipedians rather than by trustworthy sources is highly relevant to the decision of whether to link them.
Some good and featured articles are about things that scholars have largely finished thinking about. If our subject matter is, say, Tropical Depression Ten (2007) then I'm with Aaron Liu. I don't think any massive reevaluation of that topic is likely, so I think we could quite legitimately pick one revision of that article and say, "This! This is the Featured Revision of this Featured Article!" and crystallize it thus for all time.
But other good and featured articles are about things that are still in flux. If our subject matter is, say, DNA nanotechnology then I'm with Dan Leonard. There could be a new discovery that could substantially change the article, at any time, and I would say that to pick one historical revision and imply that it's the platonic ideal of that article isn't the greatest idea I've ever heard.—S MarshallT/C03:08, 10 August 2025 (UTC)[reply]
I remember having discussions about pending changes in the past but with edit filters in place, this wikipedia seems to prefer protection Logoshimpo (talk) 04:20, 10 August 2025 (UTC)[reply]
Thanks. I really don't think having a message like what I mentioned at all implies the old revision being the apex. "became a good article in {revision}" retains the meaning of "everything after this" Dan mentioned.I also find what's extracted from the pending changes discussion weird as applied here. It seems Dan's point is that this is supposed to illustrate opposition to presenting a specific revision with a checkmark, a star, or a plus sign. But that's what we've lived with and supported for a decade and a half, just not at the scale of every single mainspace article. Aaron Liu (talk) 03:46, 11 August 2025 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
RfC: Update messagebox module with new Codex icons
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.
The community did not numerically support this change, mostly for aestheic reasons, though some because they did not see a good reason to take any action. Even among those who supported the change, many complained about the broom icon not looking like a broom or otherwise looking bad (and apparently it's not even part of Codex?). The icon colors also did not match the accent colors of amboxes. Ambox.notice option 2 was also disliked, and it is only distinguished from ambox.content by color, which is an accessibility problem.
Arguments in favor cited improvements for dark mode and color-blind users. Perhaps someone will try again with better aestheics and those goals in mind. -- Beland (talk) 07:33, 19 September 2025 (UTC)[reply]
Should the icons in the message box module be updated from the current Ambox ones to the Codex ones? 13:56, 11 August 2025 (UTC)
ambox.style Not Codex, but is the OOUI for style icon...
ambox.notice
Option 2 ambox.notice
The UI on Wikipedia employs Codex components/design tokens/icons (see Special:Version) such as the message system with the Message component. These messages employ CSS and JavaScript, which we can't do yet in wikitext, see T401186. Instead, the icons have to be uploaded to Commons and used from there, as was the case with OOjs/OOUI on other wikis. We missed the 2019 update to OOUI icons unlike MediaWiki's mw:Module:Message box/configuration.
The license for Codex icons is MIT license, the entire package is GNU Public License. I believe the license might be an issue, as I was informed by @Redrose64 that MOS:PDI states one cannot remove image link= for attribution reasons, the only mention of this is this line:
For CC BY-SA, GFDL, or similarly licensed images, blank |alt= and |link= attributes should not be used. It is Wikipedia's policy to link those images for attribution...
Contrary to that point, Codex is already widely implemented on wikipedia.org: Codex icons and its components are used extensively in the Wikimedia ecosystem as its default UI system. So it makes me wonder if GPL is considered similarly licensed images. I don't see us able to maintain a consistent style and appearance (one of Wikimedia's architecture/guiding principles) with the Wikimedia sister projects, if we don't implement this workaround until the Codex-Wikitext extension (T357463) is released. waddie96 ★ (talk)16:39, 10 August 2025 (UTC)[reply]
@Pppery: Style changes are a necessary part of wiki, in order to modernise. For instance, the padlocks for protection changed in order to fit the theme of the wiki better. This is another example of that. —Matrix(!)ping onewhen replying {u - t? - uselessc} 18:33, 10 August 2025 (UTC)[reply]
I note the padlock discussion was about images displayed at 20×20px and significantly depended on changing from using color as the only distinction to including symbols as well for improved accessibility. This discussion relates to images displayed at 40×40px where the existing icons already differ significantly in shape (more so than the proposed replacements!) and are supplemental to the text of the box itself. Anomie⚔16:42, 11 August 2025 (UTC)[reply]
I removed it for your convenience, but I thought it important to point out as at my edit request I would like to make it clear that those icons were to remain the same and not be replaced with any other ones. waddie96 ★ (talk)15:12, 11 August 2025 (UTC)[reply]
Yes, I removed it, as you could see it was in the lower quadrant as simply carried over as it already exists in its latest format. waddie96 ★ (talk)15:11, 11 August 2025 (UTC)[reply]
Copying what I said in the discussion section since its partly the basis of my oppose: The existing designs are clear and easily identifiable, whereas the new Codex designs are thinner and can be confused. Accessibility needs to be taken into account here, not just ILIKEIT and IDONTLIKEIT arguments.Tenshi! (Talk page) 20:59, 14 August 2025 (UTC)[reply]
Strong oppose – it ain't broke. The new icons are also hard to interpret and, well, ugly, as the broom doesn't look like a broom at all, and the other ones follow the hideous trend of having icons look more and more like letters. Let's not make things more complicated for our readers to understand. Cremastra (talk·contribs) 20:05, 10 August 2025 (UTC)[reply]
It looks like the format brush from MS Word, which is just as a good as a broom. In fact I personally abhor that old motherbleeping[Joke] broom. It may have looked good and trendy in 2005 but since my (wiki)birth it's always looked aesthetically absolutely horrible, low-contrast, and at small sizes unsightable. Aaron Liu (talk) 02:50, 11 August 2025 (UTC)[reply]
It looks like the format brush from MS Word thanks, I didn't know that... and I expect many others didn't either. We shouldn't expect our readers to know the icons from a word processor. Also, a brush is not a broom. That looks like a paintbrush. Cremastra (talk·contribs) 14:24, 11 August 2025 (UTC)[reply]
Maybe I shouldn't have mentioned the Word format brush, because the paintbrush has the same although less specific connotations either way. ambox.style is for stylistic issues. Brooms shift that meaning to "cleaning up the lint", while a paintbrush continues the meaning of "lick of paint" or "dressing it up", which is how style tags are resolved. Aaron Liu (talk) 14:29, 11 August 2025 (UTC)[reply]
Oppose Personally, I find these new icons ugly and would rather keep the existing ones. Not going to fight over that though.As far as the license goes, the Expat (MIT) license states The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. For uploaded images, we've interpreted this as meaning that we need the link to the file description page where the notices are "included". The CC BY-SA license has similar language for notices about copyright, license, and attribution. Images included in the software may not be subject to those terms in the same way, since "all copies" might be taken to refer to the distribution of the software as a whole rather than the rendered HTML. Find a lawyer to try to figure that out. Anomie⚔20:58, 10 August 2025 (UTC)[reply]
Although most of those seem like they'd probably be {{PD-simple}} anyway. The stylized paintbrush is the only one that's not a plain shape with a single text character on it. Anomie⚔21:14, 10 August 2025 (UTC)[reply]
After giving it more thought, switching to "oppose" as I find the new icons to be distractingly harsh and soulless. They might be ok at small sizes, but 40×40px in amboxes is not that. Anomie⚔13:44, 12 August 2025 (UTC)[reply]
If feasible, I have Strong Support in Vector 2022 only: V22 uses the Codex design system. I get that a lot of people hate that skin in general too because it wain't broke, but I'm fairly sure these people would not be using Vector 2022. Technical musings: This might be feasible if we output both images and do a conditional-CSS thing to hide one of them, and unlike JS approaches loading CSS will block the display instead of creating a content flash. For when CSS doesn't load, the page would already look broken enough anyways. Otherwise, I support the original proposal We've had a flat site interface design for a very long time; the time to prevent that has long passed. Now, most of our users do see the new flat design. And unlike the last flat-design proposal, there's no possibility for confusion of the content and notice icon among colorblind users (unless we go with Option 2, which I oppose) and the subtle improvements between the OOUI and Codex circle symbols make it actually look good now. Aaron Liu (talk) 02:50, 11 August 2025 (UTC)[reply]
Was there ever really a "time to prevent that"? Paid designers are going to make trendy new designs whether we want them to or not, and their work falls under WP:CONEXCEPT unless they give us the option or we stage a major revolt. Anomie⚔12:19, 11 August 2025 (UTC)[reply]
There's a whole lot more going on there than "flat design". Discussion there seems to have been far more concerned with the functionality changes. Anomie⚔16:32, 11 August 2025 (UTC)[reply]
Support but note that Codex icons are identical to OOUI. There are several reasons behind this including supporting dark mode, ensuring visual consistency and improving accessibility. I came up with this list a while ago to identify icons that can be replaced with flat design with little problem.
I also want to discuss web accessibility and color blindness in this discussion. Here is what the original vs proposed icons potentially look for someone with total color blindness:
Although I'm not sure that just throwing a greyscale filter over the images is really an accurate representation of any real-world color blindness. Anomie⚔22:36, 18 August 2025 (UTC)[reply]
It isn't, but it probably represents the worst case scenario of complete color deficiency. I did put some permalinks to an online non-WMF tool used to check color accessibility below.
Oppose Laughably bad. No reason given for change other than ILIKEIT and a claim that enwiki should change its style to match some other style (why not the reverse?). Johnuniq (talk) 04:41, 11 August 2025 (UTC)[reply]
Support per Aasim. Consistency is good and the new icons look more modern. WP:BROKE is an unconvincing argument given the low effort that is required to make these changes. Sam Walton (talk) 05:41, 11 August 2025 (UTC)[reply]
Oppose the broom change, that new icon is clearly a paintbrush, which brings to mind very different connotations. CMD (talk) 07:55, 11 August 2025 (UTC)[reply]
Oppose per Pppery. We shouldn't radically change appearances without having demonstrated a real benefit. I don't see how icons that blend into text are a benefit -- they are harder to notice and can be skimmed over easier. They're less 'in your face', which is what we want from warning notices. JackFromWisconsin (talk | contribs) 17:22, 11 August 2025 (UTC)[reply]
Support for consistency and style reason. WP:BROKE isn't a good argument if there is a specific issue with the existing icons (in this case, a striking lack of consistency with the surrounding MediaWiki interface). The first option for ambox.notice is preferable as it is closer to the original intent. Chaotic Enby (talk · contribs) 18:37, 11 August 2025 (UTC)[reply]
Regarding the broom being replaced by a paintbrush, I agree that it is a major change in meaning that might not be ideal, and would prefer having a broom icon in a matching style instead. Chaotic Enby (talk · contribs) 18:41, 11 August 2025 (UTC)[reply]
I never noticed the ambiguous meaning. It looked like a broom to me. Must this be another ambiguous image illusion? Aasim (話す) 18:43, 11 August 2025 (UTC)[reply]
Support most, oppose broom. Whatever that is, it's not a broom. But otherwise, consistency is good. More generally, even if nothing is broken, changing icons every 10 years or so helps prevent a website from looking too stale, even if the change is totally cosmetic. The likes of Apple and Google make sure to include some pointless style changes so you can "tell" that this is the latest version of IOS or Android. While we aren't a business, we also don't want to be TOO boringly consistent in style. SnowFire (talk) 19:37, 11 August 2025 (UTC)[reply]
Support. I support switching to Codex when the changes are small, such as in this case, where the icons basically look the same. The whole point of having a design system such as Codex is to get everything on the website to have a unified look, which is more professional and is (usually) easier for maintenance purposes. –Novem Linguae (talk) 21:38, 11 August 2025 (UTC)[reply]
Oppose. We don't want the modernization of icons, which may somewhat be unclear, especially the broom one. We don't need consistencies in icons especially in maintenance templates. Consider use the old icons. Fabvill (Talk to me!)12:07, 12 August 2025 (UTC)[reply]
Support most, oppose broomWP:ILIKEIT arguments seem fine in discussing our aesthetic presentation, but beyond that, Aasim and Aaron Liu have shown that the new icons are clearer than the status quo in dark mode. Disagree with JackFromWisconsin, as the existing icons were not intentionally designed to be garish, nor would the new icons be ignored on a primarily text-based site only using black text and blue hypertext. ViridianPenguin🐧 (💬) 06:39, 13 August 2025 (UTC)[reply]
Support for consistency. Like it or not, Codex is the common design system of all Wikimedia projects so the decision to eventually standardise on it has already been made (and so IMO !votes on the basis of WP:NOTBROKEN are invalid here). Consistent style is an important part of any professional publication and we are no exception. – Joe (talk) 07:05, 13 August 2025 (UTC)[reply]
The mobile website does all sorts of really stupid stuff. Pointing at it hacking in different, often poorer icons doesn't seem like a good argument to me. Anomie⚔10:40, 13 August 2025 (UTC)[reply]
Regardless of how one feels about the new icons on desktop (or the other changes in mobile), the current desktop icons would be rather illegible at the size of the current mobile ones. novovtalkedits04:37, 14 August 2025 (UTC)[reply]
@Graeme Bartlett Have you seen the existing icons in dark mode? Ugly is a understatement for how they look (they have flipped shadows, and are unnecessarily bright). We really should be adopting a stance/culture of "Our interfaces must look good in the light mode, folks who use dark mode will have to just live with it". There are often cases when I do need to switch to the dark mode because of accessibility reasons (eye strain when reading in lower-light conditions) and the iconset that we use has really been a sticking point for me personally when it comes to reading and editing articles. Sohom (talk) 14:32, 13 August 2025 (UTC)[reply]
I'm guessing you mean shouldn't. I really agree that dark mode accessibility is one of the strongest points in favor of the new icons, and something that I'm happy to see the WMF incorporate in their recent design philosophies. That is one of the reasons why "consistency" here is not only about aesthetics, but also about going along with a more widely accessible system. Chaotic Enby (talk · contribs) 16:32, 13 August 2025 (UTC)[reply]
Oppose the replacement for ambox.style and ambox.notice option two, support the rest. Ambox.notice has an "i" for "information", which the first option replicates. The proposed replacement for ambox.style looks more like a paintbrush than a broom, which can be interpreted as "whitewash this" or "cover this up" rather than "clean this up". The first two are fine. I'm actually in the camp of "if it ain't broke," but I also recognize that it appears very unprofessional when there is inconsistency between projects. Since WMF converted to Codex, we should as well. — Jkudlick ⚓ (talk)15:51, 13 August 2025 (UTC)[reply]
Support the red, orange, and the blue i. I agree with the others that the paintbrush is not a broom, and the exclamation point would fit better in other places than a "notice". Izno (talk) 20:55, 14 August 2025 (UTC)[reply]
Support all except for the paintbrush. I also support the "blue i" icon. The current designs are indeed broken in dark mode, which is available to people who are logged out (in other words, the vast majority of readers). Using the Codex designs fixes this actual problem for a large chunk of our target audience. A personal taste for the older icons should not overcome the needs of our readers.
The paintbrush is neither a broom icon nor actually part of Codex, so I guess I am a weak oppose. I think a broom icon would be a great addition to Codex (the ethos of a wiki is to make mistakes easy to fix, rather than hard to make, so a broom is clearly helpful). Or even if there is some reason not to add to Codex, perhaps we could request a broom in Codex style from the relevant WMF team and/or volunteers. If we find a Codex-style, dark-mode-compatible broom, I support using that. HouseBlaster (talk • he/they)01:43, 15 August 2025 (UTC)[reply]
Oppose as I believe the current icons are easier to recognize. I also believe they are satisfactorily consistent: they are all clean SVGs with pleasant gradients and thin contours. They don't benefit much from being more consistent than that. And that's without considering that thing about I believe the license might be an issue. Sophocrat (talk) 01:47, 15 August 2025 (UTC)[reply]
I do not consider the current icons consistent. The only similarity is all being skeuomorphic/frutiger aero, which is as much as saying Monet and Van Gogh have a consistent artstyle. The speedy-deletion sign and the broom are clearly from very different styles of design compared to the other two signs. (Also, the bigger benefit is consistency with the interface.) Aaron Liu (talk) 16:44, 19 August 2025 (UTC)[reply]
Oppose per 2A0E:1D47:9085:D200:EDFB:7835:FC79:242D. It will create more inconsistencies as some templates (I'm thinking of maintenance templates on articles, which will be seen by readers) will have flat icons while others will have non-flat icons. If someone finds suitable alternatives for the most commonly used ones (such as the book icon in {{More citations needed}}), support all per Joe but weak oppose the broom as it barely looks like a broom at all. OutsideNormality (talk) 01:55, 15 August 2025 (UTC)[reply]
For {{More citations needed}}, would be the most visually similar one, although or convey better the idea of looking for references in my opinion. Any of those would be fine to me.The icon in {{Unreliable sources}} also matches well with (or , if we take the rectangle being searched to represent the article rather than the sources). is closer visually, but could be more confusing as "question mark in rectangle" is a very common symbol and makes it less clear that the rectangle represents the article.{{Disputed}} easily gets .For {{Speculation}}, Codex sadly doesn't have a crystal ball yet (although I could make one in the Codex style if needed). The closest "magic woo" icons (and that's a stretch) are or .{{Current}} and {{Recentism}} can get different colors of .{{Globalize}} gets . Chaotic Enby (talk · contribs) 18:19, 15 August 2025 (UTC)[reply]
Support, those icon suggestions are nice. Sometimes simplicity is better, especially when they're paired with text-heavy boxes. The flat style, though "in vogue" at the moment, is definately easier on the eyes. qcne(talk)20:07, 18 August 2025 (UTC)[reply]
Support Aesthetics are important for webpage design. The Wikipedia logo isn't usually seen on mobile, so it doesn't clash with the codex icons. –LaundryPizza03 (dc̄) 16:44, 21 August 2025 (UTC)[reply]
if the old icons don't work in dark mode Define "work". Except for the broom's shadow, they're all perfectly visible, some just think they're ugly or maybe not dark enough in dark mode. As for accessibility, I note the icons are mainly decorative anyway, the real meaning is communicated by the text of the message box. Anomie⚔13:00, 24 August 2025 (UTC)[reply]
The seven types of ambox (four of which would have their icons changed) are not just decorative. The type is chosen not on aesthetics but is based on the type of issue that the template describes. As with what I mentioned for the unblock icons below, these icons are very functional for a quick glean of this information on the type of ambox, so one can decide faster whether to ignore it, for one. Aaron Liu (talk) 22:31, 25 August 2025 (UTC)[reply]
Oppose I'm unable to easily read the symbols in the new icons due to my astigmatism; they look like plain vertical lines (|) inside the shapes. On the current icons, it's very easy for me to tell that these are exclamation points and a letter i. On dark mode, I'm unable to see the paintbrush handle without squinting whereas the current icon is easily identifiable as a broom. 3df (talk) 05:49, 2 September 2025 (UTC)[reply]
Strongly oppose. 1: I like skeuomorphism and think the older icons look better. 2: Ignoring my aesthetic preferences, the older icons are easier to distinguish. 3: Your icon change will ruin the messagebox for everybody who uses MonoBook or Vector 2010. OmegaAOL (talk) 00:37, 5 September 2025 (UTC)[reply]
As with OOUI buttons, the (upcoming) Codex-Wikitext feature mentioned should or should be easily modifiable to allow alternative icon sets per skin. Aaron Liu (talk) 00:52, 5 September 2025 (UTC)[reply]
Support Important part of UI design is consistency. Although if we wait long enough, I guess skeumorphism will come back so we will avoid having to do anything.. Galobtter (talk) 23:28, 7 September 2025 (UTC)[reply]
Partial oppose. An even more important part of design is making sure that images look like what they're intended to represent. As someone noted above, the new broom icon doesn't look like a broom: it makes me think of a backscratcher or paintbrush, but not a broom. I like all the older images better, but aside from the broom, I don't have a strong opinion; since most of the non-broom icons use exclamation points, the exception looks like ¡ rather than "i", but that's still not a huge problem. Regarding the colourblindness issue — I'm a bit red-green colourblind, but I don't have any difficulty with the current images. Why would this matter anyway? Each icon has a different character or background shape, so even if you're a total monochromat, you can easily distinguish them. Nyttend (talk) 08:03, 11 September 2025 (UTC)[reply]
Strong support for all suggested (including the Qs below) per nom, Aasim, Chaotic Enby, Waddie. as a Vector 2020 and dark mode user, these are a nice change. the whole skin has been very visually appealing and accessible for a user with bad vision, and these would add to it. the (constructive, see below) criticisms for some of the design icons should be taken into account for reworking them as needed. I would also say that the boxes themselves would warrant a bit of change. Juwan (talk) 00:08, 13 September 2025 (UTC)[reply]
Discussion (Codex icons)
I think ILIKEIT and IDONTLIKEIT are going to be themes in this discussion. WP:ILIKEIT and WP:IDONTLIKEIT really apply to deletion discussions mostly but they are also bad arguments for other kinds of discussions. I brought up my reasons for preferring it including dark mode compatibility, consistency with other aspects of Wikipedia (including the protection icons), and accessibility (although I did suggest one change). Arguments on principles on visual design are probably going to be themes similar to the Vector 2022 RfCs. Aasim (話す) 05:37, 11 August 2025 (UTC)[reply]
@Cremastra, Pppery, and Tenshi Hinanawi: my strongest critique would be that much of the discussion relies on subjective perception and analogy rather than user research or accessibility testing. I'm also just going to point out the fallacies in the invalid construction of your argument as comments expressing support or opposition if they are going to represent the community’s position should surely be reasonably substantiated with relevant reasoning, evidence, or examples.
Status quo bias: assumes that because something currently works (or isn’t perceived as broken), it shouldn’t be changed — without addressing whether improvement might be possible or beneficial.
Subjective aesthetic judgment without objective criteria: While personal preferences are valid in casual conversation, as arguments they are weak unless tied to objective usability, accessibility, or design standards.
Personal dislike: This is an ad hominem toward the design, not the proposal. The focus shifts to personal feelings rather than the proposal's functional merits.
False analogy: like the format brush from MS Word comparison assumes visual similarity equals functional equivalence, without establishing that readers will interpret the icon the same way
Overgeneralisation: We shouldn’t expect our readers to know the icons from a word processor. This may or may not be true, but it’s stated as a certainty without evidence of actual reader familiarity. waddie96 ★ (talk)15:34, 11 August 2025 (UTC)[reply]
The existing designs are clear and easily identifiable, whereas the new Codex designs are thinner and can be confused. Accessibility needs to be taken into account here, not just ILIKEIT and IDONTLIKEIT arguments. Tenshi! (Talk page) 15:45, 11 August 2025 (UTC)[reply]
Yes, this. The new icons are less accessible; it is your argument that amounts to ILIKEIT. By definition flat designs with less information are more likely to be confusing, and they should be avoided. Why not have the cleanup icon be File:Broom (PSF).jpg, perhaps rotated 45°? Cremastra (talk·contribs) 16:40, 11 August 2025 (UTC)[reply]
I don't see how they are more easily confused with each other. The key to distinguishing between icons is their differences, not their total size. The added skeumorphic lighting in the Tango icons cancel out as that's something all of them have.I don't see how .content and .notice are any less distinguishable; they have the same amount of differences: color, "direction" of symbol, and an alteration to make it clear the i is a letter. You could I guess say the serif is bolder than just shortening the height but they're already far past the differentiation-baseline for me to dent my subjective differentiation index. Same thing goes for the speedy icon's white inside vs no white inside. Aaron Liu (talk) 03:01, 12 August 2025 (UTC)[reply]
I don't think the new icons are less accessible. What I do know is that the original icons don't look good in dark mode. See this as an example:
Weird, that doesn't happen even logged-out for me in the light/dark comparisons; they only happen in the gallery from Waddie for me. If you click on Extension:Graph and enable dark mode, does the same thing happen? Aaron Liu (talk) 02:56, 12 August 2025 (UTC)[reply]
I'm using the default dark mode gadget. In light mode there is no square around the Dark mode column, but it's there in actual dark mode. CMD (talk) 07:09, 12 August 2025 (UTC)[reply]
Not sure what you mean by "default gadget". I was talking about Vector 2022's built-in dark mode from the appearance menu, which looks like an incognito icon when hidden. Aaron Liu (talk) 14:14, 12 August 2025 (UTC)[reply]
They don't flip, even though IMHO they should. This is because MW renders SVG icons in the backend and then throws out a simple PNG image that is supposed to be appropriately scaled. It would be better to instead have the SVG code spat out to render in the frontend, then stuff like changing the color based on the current theme can work. Aasim (話す) 06:48, 12 August 2025 (UTC)[reply]
Why not have the cleanup icon be: @Cremastra As always, your argument synthesis is derogoratory and your 'discussions' are 'win' or 'lose' mentality—not constructive. waddie96 ★ (talk)02:17, 12 August 2025 (UTC)[reply]
I wanted to add on to the icon you recommended for the "broom".
First, it is grayscale, not colored in. Second, it becomes invisible in dark mode. I am pretty sure the second one can be fixed by inverting the broom, but it does not solve the first problem. This is not being displayed on a grayscale CRT, it is being displayed on a variety of screens from television sets (because yes some people hook their computer to their 4K OLED TV) to HDR monitors to smartphone screens. It should look good on almost all of them. And all the problems as well with the image not being an SVG.
Here is how that icon looks like for the record: . Not good. Even rotating it 45 degrees doesn't really fix the issue:
A few people above are mentioning "consistency with the MediaWiki interface", by which I'm guessing they specifically mean Vector2022. Personally, I really don't see it. Looking at some random pages in a private-browsing window, I see a whole lot of nothing to be consistent with other than the Wikipedia logo in the corner, which these new icons don't match, and whatever we have in the articles themselves, which these new icons don't really match either. I guess "whole lot of nothing" kind of goes with "harsh and soulless", which is the vibe I get from the new codex icons. Anomie⚔22:27, 11 August 2025 (UTC)[reply]
Having a triple-dot menu, the entire top bar, the sticky top bar and user dropdown (only accessible when logged-in for some reason), everything to do with discussion subscriptions, everything to do with notifications, Recent Changes/the Watchlist, the graphic for empty talk pages and editing onboarding, the mentor dashboard, newcomer homepage.... There's also built-in dialog boxes somewhere, beyond the reference previews gadget we have. Aaron Liu (talk) 00:56, 12 August 2025 (UTC)[reply]
So, a bunch of stuff that only shows up when logged in, and changing icons to match logged-in Vector2022 would cause them to mismatch for logged-in users of classic Vector, Monobook, and other skins. I can't say I find that terribly convincing. Anomie⚔13:39, 12 August 2025 (UTC)[reply]
Nope, as a classic Vector user, I also have Codex/OOUI icons in the interface, like the notification icons. If anything, that change is also an improvement for us. Chaotic Enby (talk · contribs) 13:57, 12 August 2025 (UTC)[reply]
Firstly, I'm surprised that no one has commented on what I said about making them only show on V22. Secondly, a quarter of this shows when logged out too. In fact, the Codex warning sign for "You are not logged in" only shows up for logged out users. It's also in all of the editing interfaces. Aaron Liu (talk) 14:18, 12 August 2025 (UTC)[reply]
IMO embedding both and hiding one or the other with CSS is not a very clean solution. Looking at various other places you mention, I again find that 20×20px or smaller icons have a different impact compared to 40×40px ambox icons. I also find the Codex warning sign for "You are not logged in" is oddly truncated, FYI. Anomie⚔14:40, 12 August 2025 (UTC)[reply]
Instead of a brush or a broom, maybe we could go for a color version of the more inviting (File:Codex icon edit.svg), to indicate issues that editors can solve? Other ones I like are (a generic tag icon) or (yes, it's officially the recent changes icon, but simple icons like this are very polysemic). Chaotic Enby (talk · contribs) 14:12, 12 August 2025 (UTC)[reply]
The flat colors make it obvious that these icons don’t match the existing accent colors for the amboxes. I also feel like the orange and red colors are too similar. Amazing how we got it right years ago and yet the WMF tries to reinvent the wheel and makes a simple color-clash mistake like this. —pythoncoder (talk | contribs)17:05, 13 August 2025 (UTC)[reply]
Yeah sorry I don't have time to read all 56 comments since I was last here but:
If we use the icons for accessibility we should ideally not use the current yellow ones, we should use the prescribed yellow warning color at Codex color palette for consistency and for sufficient W2A contrast. See Codex color tokens and Color palette.
Current yellow icon on yellow background would be: #FFCC33 bg/ #FDF2D5 (1.352:1) Fail for large and regular text (AA) Fail for large and regular text (AAA) Fail for UI components and graphical objects (non-text)
The @color-icon-warning on @background-color-warning is: var(--color-icon-warning) bg/ var(--background-color-warning)
(Pretty much trying to match .mbox CSS with @cdx-message CSS
I wonder if a manual of style for icons and colors in templates would be a good idea. It probably can detail stuff like accessibility and icon color, and how maybe we should not solely use color to distinguish function of an icon, as people can have varying degrees of color blindness. WP:DONTFIXIT seems to be one theme in this discussion, as is WP:ILIKEIT and WP:IDONTLIKEIT. But I am not seeing that many arguments based on web accessibility. Sure some icons are supplementary, but even supplementary icons and shapes help people who have dyslexia or do not speak English (like in this Exit sign), people who are color blind (like this traffic light), people who are skimming and want a general idea of what is happening on a specific page, and people in all of these mentioned categories and more. We do have MOS:COLOR and MOS:ICON, but they largely pertain to the use of colors and icons in the prose of articles and not in maintenance templates, user interface, etc. Aasim (話す) 01:48, 20 August 2025 (UTC)[reply]
I think there would be a significant amount of clashing/bikeshedding within the context of such a discussion and a high amount of community inertia (not to mention that we would clash with the WMF Codex/Design team as and when such a style guide becomes out of date). Sohom (talk) 02:46, 20 August 2025 (UTC)[reply]
Yeah the law of triviality is definitely a problem, and I think what kind of icons we are using (flat or skeumorphic or nuvola or old) aren't really worth debating unless if there is an accessibility or readability concern. When I first suggested converting to flat icons all the way back in 2020, the RfC was ended early for not being prime for an RfC, and the only few other times I even entertained the idea in the idea lab, they never went to fruition as RfCs (most recent idea lab post I can find is here). The only things I really do think would be worth including somewhere either on this new style page or in the existing MoS is:
When icons are used as indicators in templates, template colors should match the color of such icons
For accessibility reasons other properties such as icon shape should be used to distinguish between sets of icons part of template series such as the user warning and block templates.
Otherwise, I don't think there is a good reason to revert changes to icons. I think this issue will become less contentious if and when there is an in-built extension tag or parser function that automatically loads the SVG code for any one of the growing icons in the Codex library (and they can potentially be expanded and customized for each design system). Aasim (話す) 04:18, 20 August 2025 (UTC)[reply]
FYI this section did not actually ping anyone because you have to sign your post in the same edit as you added the user names, and you can't ping more than 50 users in the same edit. I really don't think pinging 76 people was necessary here, though. * Pppery *it has begun...14:51, 11 August 2025 (UTC)[reply]
The plan with ambox is to eventually somehow replace the dark-mode background color with --background-color-neutral-subtle (#202122) while fixing the ribbon colors to the left. Aaron Liu (talk) 17:00, 21 August 2025 (UTC)[reply]
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.
Request for closure review by closing editor
@Beland: Hi Beland, I'd like to revisit the outcome you summarised for the first part of the discussion, as I have concerns about its accuracy.
One significant issue is the phrasing did not numerically support this change. That raises red flags, since consensus on Wikipedia is not determined by counting heads or votes, but by evaluating the strength and policy-basis of arguments. Using numerical language gives the impression of a vote tally rather than a consensus assessment.
Another point is that substantial weight was given to opinions that did not fully engage with the matter at hand. The issue wasn't solely about the paintbrush icon; it was about updating the maintenance template icons to the Codex set as a whole. While one particular icon drew attention, that should not overshadow the broader question of whether the set itself is suitable.
In addition, the arguments summarised in your close seem too narrow compared to the range that was actually presented. To restate more fully:
Arguments in favour highlighted alignment with MediaWiki’s Codex system (already used in Vector 2022 and mobile), improved accessibility (especially in dark mode), and the benefits of a modern, consistent, and professional appearance.
Arguments against emphasised that the current icons are already clear, recognisable, and functional, while some of the Codex icons were seen as thinner, harder to distinguish, or less meaningful (e.g., the broom vs. paintbrush concern). Opponents also cited potential confusion, lack of demonstrated functional gain, and inconsistency with templates not yet updated.
Intermediate views generally supported Codex adoption in principle, but suggested deferring until more appropriate icons (such as a Codex broom) are available, or until all maintenance templates can be updated together for consistency.
From my reading, the discussion pointed to no clear consensus. There is interest in Codex alignment for long-term consistency, but significant opposition remains regarding specific icon choices and the timing of implementation.
Question 2: Should we update the warning and block templates to use Codex/OOUI icons?
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.
→ (but modified to have an X inside rather than an !)
→ (but modified to have an X inside rather than an !)
Lv. 4im:
Light mode
Dark mode
→
→
Lv. 4:
Light mode
Dark mode
→
→
Lv. 3:
Light mode
Dark mode
→
→
Lv. 2:
Light mode
Dark mode
→
→
Lv. 1:
Light mode
Dark mode
→
→
(note there is no noticeable difference between the appearance Codex and OOUI icons, and Codex icons already exist for this or can be created easily for this) Aasim (話す) 19:08, 18 August 2025 (UTC)[reply]
As proposer: support, but it would be preferable to wait until it is possible to use Codex icons inline with wikitext before updating. The old templates have this problem of file links to files that can no longer be deleted or updated because they are used so much. There definitely are major accessibility changes to this, including different shapes for Lv. 1 and Lv. 2 warnings, as well as better appearance on dark mode. It's also useful to consider what this looks like with a total color blindness filter I found online.Aasim (話す) 19:08, 18 August 2025 (UTC)[reply]
Okay, I tried creating a template to illustrate the problem clearer. Web accessibility is not an option:
As above, I don't know why you're showing the icons at a quarter the size (by area) that they're actually used at. Anomie⚔22:40, 18 August 2025 (UTC)[reply]
Support. I feel like the new icons are better in dark mode – while flat design and contrast are indeed something to consider, the lighting and white text on the old ones are more problematic in my opinion. I can easily make the cross-inside-octogon since we already have . Chaotic Enby (talk · contribs) 19:34, 18 August 2025 (UTC)[reply]
Oppose for the same reasons I oppose the main proposal: these are harder to recognize (particularly in dark mode) and I haven't seen any convincing arguments why more consistency with the surrounding UI is a good thing. Plus judging by the monochromacy table someone made they seem less accessible. Sophocrat (talk) 20:33, 18 August 2025 (UTC)[reply]
Oppose Same reasoning as above. I note that any argument of "accessibility" is going to be a red herring, since the icons are decorative anyway and the real message of any box is communicated by the text, not the icon. Anomie⚔22:40, 18 August 2025 (UTC)[reply]
Can you clarify which icons you are having trouble distinguishing? For the old icons having an i for both level 1 and level 2 warnings with the only difference being color is problematic from an accessibility standpoint. Aasim (話す) 22:14, 19 August 2025 (UTC)[reply]
Can you maybe reference which icons you are having trouble distinguishing? It would be helpful maybe to help improve this proposal and reach an adequate compromise. Aasim (話す) 03:11, 20 August 2025 (UTC)[reply]
I assume CMD is talking about the solid red clock, the solid red hand, the solid red stop sign, and the dark orange triangle. I agree they are more difficult to distinguish. Cremastra (talk·contribs) 03:27, 20 August 2025 (UTC)[reply]
I think the issue is at the size I am showing them in my half-baked attempt at showing what it might look like for color blind users, even I am struggling to make out the details. But then I am not hunched against my laptop, I have a proper mechanical keyboard in front of my laptop keyboard on my desk that essentially doubles the minimum viewing distance when on a docking station.
Maybe the solution would be to make the icons bigger, so they are 50px rather than 25px, but then that interferes with line placement, necessitating table substitution rather than inline substitution. Aasim (話す) 03:33, 20 August 2025 (UTC)[reply]
A bit ago I was experimenting with unifying all the uw templates in Template:Uw/sandbox and I realized in one of my iterations I used both and in combination with . The icons do look nicer on colored backgrounds that match them, but otherwise when not on a matching color it can look a little hideous. But a hideous color that is still legible is better than un-dark-modeable colors like the white clock that cannot be changed to black as inverting would mess up the color of the hands and the stop X. And on Vector 2022 and Minerva it seems broken, I don't know why. Aasim (話す) 03:27, 20 August 2025 (UTC)[reply]
I've boldly replaced the lv 1 and 3 OOUI icons with the Codex icons, since there is in fact meaningful difference for those. Also, for an ambitious change, one might consider {{cdx-message}}. Aaron Liu (talk) 18:37, 20 August 2025 (UTC)[reply]
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.
Question 3: Should we update the unblock templates to use Codex/OOUI icons?
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.
Yes. 2:1 in favor. Supporters found not distinguishing based on color alone is an accessibility improvement, and the new shapes more clearly communicate their meanings. -- Beland (talk) 07:44, 19 September 2025 (UTC)[reply]
Unblock:
Light mode
Dark mode
→
→
Unblock on hold:
Light mode
Dark mode
→
→
Unblock declined:
Light mode
Dark mode
→
→
Unblock accepted:
Light mode
Dark mode
→
→
(note there is no noticeable difference between the appearance Codex and OOUI icons, and Codex icons already exist for this or can be created easily for this) Aasim (話す) 19:08, 18 August 2025 (UTC)[reply]
As proposer: support. The unblock templates have some of the most inaccessible icons IMHO, with only a recolored clock used for all of them. It's also useful to consider what this looks like with a total color blindness filter I found online. Aasim (話す) 19:08, 18 August 2025 (UTC)[reply]
Okay, I tried creating a template to illustrate the problem clearer. Web accessibility is not an option:
As above, I don't know why you're showing the icons at a quarter the size (by area) that they're actually used at. Anomie⚔22:39, 18 August 2025 (UTC)[reply]
The key aspect here is color in this case. If I were to show the icons any bigger I am afraid they would overflow off the screen especially on mobile devices. Feel free to adjust the size of the icons if you think it is necessary for this discussion. Aasim (話す) 23:32, 18 August 2025 (UTC)[reply]
Size is relevant for at least some contrast ratios – for example, WCAG AA and AAA are not the same for regular-sized and large-sized text. However, in this specific case, it is clear that the useful information in the current icons only depends on the colors, which is problematic from an accessibility standpoint. Chaotic Enby (talk · contribs) 23:53, 18 August 2025 (UTC)[reply]
Oppose Same reasoning as above. I note that any argument of "accessibility" is going to be a red herring, since the icons are decorative anyway and the real message of any box is communicated by the text, not the icon. Anomie⚔22:39, 18 August 2025 (UTC)[reply]
Umm... Isn't dyslexia definitely going to cause problems for some editors? Colored icons are much faster to identify than walls of text. Also not everyone who gets blocked here speaks English and an X implies denied and a check implies accepted (in the Western world at least). Aasim (話す) 23:41, 18 August 2025 (UTC)[reply]
Further, if this passes only because people don't like the colored clocks being the only difference, I'd rather see them changed to something like the existing clocks with symbols superimposed in the lower-right corner, like we do for various other things, than the brutalist Codex style icons. Anomie⚔12:26, 25 August 2025 (UTC)[reply]
Support This one has a far better rationale since the original icons are not accessibly differentiable from each other. Sure, there's always other text that tells you that status, but the icon is not purely decorative at all. As a colorsighted person, it serves as a great, fast way to see the status of an unblock request that you can quickly scroll by. On the other hand, you'd have to slow down and read text. There also isn't an easy way to guess that yellow means on hold and blue means it's new without knowing that beforehand. Aaron Liu (talk) 03:12, 19 August 2025 (UTC)[reply]
Not a fan of a big red X for unblock declined, it feels a lot more like rubbing it in than a palette-swapped clock. CMD (talk) 04:31, 19 August 2025 (UTC)[reply]
Maybe check/thumbs down would be more appropriate. I haven't made any changes because I mostly abandoned development of the idea until someone else brought it up. My opinions have not changed that much in the past seven years, but I did see that since we are discussing some of the icons right now we can discuss the others as well.
It really shouldn't matter too much what icons we use and what icons we don't use (apart from accessibility and UI/UX testing), we are an encyclopedia after all, and icons are not part of encyclopedia proper. I don't even know how consensus was achieved for the nuvola icons in the first place, nor the information icons that have not changed since 2005 at the earliest. Aasim (話す) 05:48, 19 August 2025 (UTC)[reply]
I know Phabricator uses ✅ and 👎. That is where I got the idea from. But yeah I see how it can be debatable whether it is appropriate. Aasim (話す) 00:41, 20 August 2025 (UTC)[reply]
Support per Aaron Liu and also common sense: a / makes more sense than coloured clocks for declined/accepted requests respectively, and a pause icon is also more symbolic of "on hold" than a random yellow clock. OutsideNormality (talk) 16:30, 19 August 2025 (UTC)[reply]
However, if it's related to a block, I think there should be a central image to keep the theme (like in this case it was a clock), and then in the bottom right have a changing image based on 'status'. For example: (illustrative example only not a suggestion!).
Support Different-colored clocks don't convey much on their own. For warnings and blocks, there is also the necessity of communicating with users with limited English fluency. –LaundryPizza03 (dc̄) 16:57, 21 August 2025 (UTC)[reply]
Support as of now the icons are basically identical for someone who hasn't spent looking at them. Change in the symbol will be beneficial. (please ping on reply) ~/Bunnypranav:<ping>11:43, 31 August 2025 (UTC)[reply]
Discussion (Q3)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
I still think it would be worth considering whether people really want to change to these icons, or if an alternative that keeps a similar style to the old ones while being different in more than just color would be more accepted. Anomie⚔11:19, 19 September 2025 (UTC)[reply]
Question 4: Should we replace the icon for current events?
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.
Not with this replacement. The rationale "bikeshedding" is kind of hard to interpret. The only way to make decisions about whether a given change is an improvement without consulting the community is for people to just decide what to do on their own and do it. If the objection is to having the discussion in the first place, it would be helpful to say what the alternative mechanism should be for the next time this comes up. I'm not sure "never make any minor aesthetic changes" is a long-term viable strategy.
Anyway, there were plenty of other editors opposed for more normal reasons. Some provided encouragement to keep looking for a better alternative, saying the existing icon is unsatisfactory. -- Beland (talk) 08:17, 19 September 2025 (UTC)[reply]
Oppose no significant improvement. The current icon has a globe that looks like the Earth and a clock that looks like a clock. The proposed change looks way too cartoony, has an Earth apparently drawn by an anti-Mediterranean conspiracy theorist, and an oversimplified clock. Let's have a nice icon instead of the simplest one available.
No it's not, I was just making the proposition since I thought the above was also derailing to other icons but I see it's simply going to change other icons to Codex. :-) waddie96 ★ (talk)20:44, 20 August 2025 (UTC)[reply]
Just a joke, because the second globe has North America, Greenland, and South America rendered in good detail but doesn't distinguish between Europe and Africa: hence, no Mediterranean Sea. Cremastra (talk·contribs) 21:12, 20 August 2025 (UTC)[reply]
Oppose, no improvement beyond making it flat, and too busy (in terms of colors) to fit with the Codex design language. To fit the theme, a much better choice would be , , or a combination of the two. Chaotic Enby (talk · contribs) 21:24, 20 August 2025 (UTC)[reply]
I think Codex is better suited to smaller icons, like the buttons in the source editor tab in the reply tool. Larger icons like this benefit from a bit more detail and colour, but if we were to move to flat, I don't think Codex would be the right answer, because it would be at this size:
The first thing you notice about that icon is that it is very ugly, because I have no design sense, but I think if we want flat icons that's the level of detail to maintain. Cremastra (talk·contribs) 00:35, 21 August 2025 (UTC)[reply]
Strong oppose: I have seen three topics created by you so far concerning the corporatization of various Wikipedia images and icons. I am opposed to all of those changes. OmegaAOL (talk) 00:40, 5 September 2025 (UTC)[reply]
Please don't discourage people from expressing their opinions. The tradeoff in participating or not is up for each person to weigh. isaacl (talk) 14:58, 10 September 2025 (UTC)[reply]
Support No strong preference between the Icons8 composite and Cremastra's globe-patterned clock (as an SVG). The Icons8 globe by itself () meshes well with the Codex signs and the proposed broom icon; it could be used for Template:Globalize if the Codex-style symbols are adopted for generic use. –LaundryPizza03 (dc̄) 17:06, 21 August 2025 (UTC)[reply]
I concur. There's plenty of nice flaticons similar. A lot of noun project, SVGrepo etc. You just have to dig through 1000+ to get one. But also Microsoft Fluent UI, Antu SVG, Breeze, Icons8, Iconoir, Material Design 3 waddie96 ★ (talk)11:17, 10 September 2025 (UTC)[reply]
Neutral This feels like a trivial change like the color of templates. This icon is flat and consistent with the other Codex icons, but the icon doesn't look that good in dark mode (especially with the white clock). There may be a better icon that is suited for this that can be added as an option B or C. Aasim (話す) 16:13, 22 August 2025 (UTC)[reply]
Strong oppose, we should not be replacing a decently accurate coastline with some really poor blobs. We're trying to be an encyclopaedia, let's try to get some small details right. CMD (talk) 11:28, 10 September 2025 (UTC)[reply]
Discussion (Q4)
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.
Proposer is changing icons in mboxes
Just an FYI to those who are watching this discussion: waddie96 is actively changing mboxes and also submitting mbox template edit requests that include these new, flat icons, despite what looks to me like significant opposition in the discussions above. I think they may also be removing linking to the icons, possibly failing to comply with licensing for the icons (I am not a licensing expert, so I could be wrong on this one). You can review their contributions in Template space if you want to see the extent of their recent editing. – Jonesey95 (talk) 04:33, 30 August 2025 (UTC)[reply]
Hey, sorry I didn't think those template edits were controversial or considered as part of this discussion because they're not Codex icons. I will revert the edits. waddie96 ★ (talk) 12:51, 30 August 2025 (UTC) (scratch that, I see one did use a Codex icon waddie96 ★ (talk)13:00, 30 August 2025 (UTC))[reply]
Anomie, I think it's far from a block, when this is the first mention of it. I'm a regular editor of enwiki yes, but to be honest didn't think those template changes were applicable to this discussion. As an administrator you should know that typically, before seeking a block, a final warning in an escalating series should have been posted to the user's talk page. waddie96 ★ (talk)12:58, 30 August 2025 (UTC)[reply]
Thank you for responding appropriately to the notification above! 🙂If behavior is disruptive and continuing, then a block would be appropriate and I don't see a problem in noting that a block is a possible outcome when discussing behavior that may be disruptive if continued. I also don't see the statement you quote in any policy or guideline; I do see something similar in Template:Report vandal, but that wouldn't apply here anyway since WP:Fait accompli is not vandalism. Anomie⚔13:21, 30 August 2025 (UTC)[reply]
Look, I appreciate your thank you. And what I mean to say is, a block is obviously a very serious action. And it will only incite an unfavourable response in a discussion. I believe what makes most users leave enwiki is how we speak to one another. We're generally not kind, or understanding, nor do we AGF as often as we should. I am just as guilty. But I do appreciate bringing up the issue here before reverting my edits. And giving me an oppurtunity to fix up the issue I created. 😄
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.
Consensus is against Wikipedia officially endorsing this company or making their files "an inherent part of article's structure". If their content is licensed appropriately, they're welcome to upload it to Commons, and people without a COI may use the content here if they find it useful.Debates on what "licensed appropriately" means when it comes to the training data behind AI text-to-speech aren't really in scope for this page, and at this point the only discussion is people arguing over that. There's probably a good place over at Commons for that sort of discussion. And as a bonus, over there it's more likely to wind up actually affecting anything. Anomie⚔21:54, 14 September 2025 (UTC)[reply]
Dear Community, My name is Amiel.
At TTSREADER we have undertaken to convert a large amount of Wikipedia articles to synthesized speech with the latest and most advanced AI voices available. We currently have some 50,000 articles synthesized both in Male and Female voices and have created an environment that allows one to navigate through different articles, listen and follow the article content. https://ttsreader.com/wiki/
We currently hold also some 50,000 articles in Spanish. We are looking to expand this resource all the time.
I want to bring this project of ours to the attention of the community with the hopes of turning it into an inherent part of article's structure. We are looking to share/give the content that we have, both from our site as well as integrate the audio files in existing Wikipedia articles.
I have been in touch with a number of Authors and Editors as well as reviewed some past discussions on this matter and have received the impression that there is no desire to integrate such audio files in articles because of lack of human authenticity. I disagree with this stance, and would like this to be discussed once again.
Important to point out, the voices we employ have very realistic humanlike characteristics. They incorporate, emphasis, intonation, pauses and tone that are very engaging. All this leads to improved delivery and comprehension. The articles themselves are word for word the content of the original articles derived from the date of capture. The articles have been sanitized to ensure only free-flowing comprehensible content is conveyed. Thus, content of this nature goes a long way to make Wikipedia articles more accessible to the general population and simply accessible to those with disabilities such as the vision impaired or those with language and reading impairment such as Dyslexia and ADHD.
Has any of the audio material the AI voice model has been trained with been used without the permission of their copyright holders? Cortador (talk) 14:41, 17 August 2025 (UTC)[reply]
The AI voice models we work with, are commercial models provided by leading vendors such as Azure, Google and OpenAI. There privacy policies are very stringent and from the research that we have done their model development is without copyright infringements.
The content of the output voice is purely controlled by us and how we apply these models, and the rights to the content produced by the models are of those who synthesize the voice.
I dont see, or at least not aware of any copyrights problems. @Cortador Do you suspect a problem?
OpenAI alone is currently involved in at least a dozen lawsuits (see also here). I don't know whatever research you have done, but there's clearly some disagreement on whether or not these models have been built "without copyright infringements". Cortador (talk) 14:58, 17 August 2025 (UTC)[reply]
Seconding @Cortador's comment. In my opinion, it's best for WP to remain aloof from models with copyright infringement lawsuits against them. There do exist TTS models without any such issues, but it does not appear that the project in question has taken care to select only such fairly trained models for its use. Aurodea108 (talk) 03:47, 11 September 2025 (UTC)[reply]
There are also a bunch of people suing Wikipedia, at this very moment, nearly all of which for inane reasons -- what's the point? jp×g🗯️17:30, 14 September 2025 (UTC)[reply]
That people are already suing Wikipedia does not support the idea that Wikipedia should start getting involved in other matters of questionable legality, especially since there are other perfectly good alternatives available. Aurodea108 (talk) 19:57, 14 September 2025 (UTC)[reply]
You're saying words, but did you first obtain permission from the copyright holder of every piece of audio you've ever heard in your lifetime? You're a human, but have you made sure that no human is currently the subject of a lawsuit? jp×g🗯️17:00, 14 September 2025 (UTC)[reply]
While this looks very helpful as a separate service, I do not think an external tool such as this one should be integrated as an inherent part of article's structure, as it would make Wikipedia reliant on this external provider. If the tool was entirely free and open-source, integrating it to MediaWiki could be a possibility, but it isn't clear to what extent this is the case, and whether these latest and most advanced AI voices available are under a compatible license (or, like Cortador points out, were even trained with permission).The promotional language in the proposal also bugs me a bit, but I believe that this tool should be analyzed on its merits. Sadly, there is little that I can see beyond a user interface, so it is hard to find more about the tool's capabilities or its technical details. Chaotic Enby (talk · contribs) 15:05, 17 August 2025 (UTC)[reply]
Edit: seeing the replies above, I am sad to say that this simply cannot be possible. Wikipedia will not integrate inside our articles a tool that relies on commercial models, especially to that extent. Chaotic Enby (talk · contribs) 15:08, 17 August 2025 (UTC)[reply]
Let me clarify what I meant by "inherent part of article's structure". I mean to say that the audio outputs/audio readings that we have generated I would be happy to give them/ provide them for use as part of Wikipedia articles. In this way, they can provide an added media that contributes to the content's accessibility. I dont want to turn Wikipedia to become reliant on us, that defeats my intention completely. What I have I want to share.
@Chaotic Enby Excuse my promotional language, im not yet attuned to the community's sensitivities. I believe I understand your concerns. I am trying my best to share resources that we have that I believe can contribute to Wikipedia. I ask that you judge what I share and the content based on merits. Ill go even further, if you believe there is a better way/fashion to improve the merits of what I have shared I would be the happiest to hear.
@Cortador thanks for sharing this. Could you please elaborate where there could be a problem with this matter? The Engines I mentioned above are used across the world across different platforms and fields of application all the time and are ever expanding their use and applicability. (Lawsuits take place all the time, does that stop the activity?, most often not.)
Why is this of concern to you? If the materials are developed lawfully and shared legitimately why should this limit the possibility of using these materials? I may be naive but if the outcome is of benefit then surely that should be the metric? Would love to hear. AmielRieger (talk) 15:55, 17 August 2025 (UTC)[reply]
Wikipedia is distributed under a free license, and avoids using third-party services that do not have a compatible license. Even if you decide to provide these recordings for Wikipedia, it needs to be under a similar license (which allows for commercial re-use), which I am not sure is compatible with the terms of the commercial models you are using. Chaotic Enby (talk · contribs) 16:03, 17 August 2025 (UTC)[reply]
Thank you for the feedback so far. To clarify:
No reliance on external services – I am not proposing embedding Azure/Google services into Wikipedia. Instead, I propose to provide the finished audio files, which can be uploaded to Wikimedia Commons and hosted like any other media file. Once uploaded, Wikipedia would not depend on us or any commercial provider.
License compatibility – We already do and will release the audio under CC BY-SA 4.0, the same license as the article text. The models we use (Azure, Google) explicitly grant users rights over outputs, and we have full rights to release them under a free license.
No training data risk – We do not train AI models ourselves. We only apply existing licensed tools to freely licensed Wikipedia text. The audio is a direct transformation of CC-BY-SA content, not a reuse of copyrighted material.
Accessibility benefit – The purpose is to make Wikipedia more accessible: helping vision-impaired users, language learners, and readers with dyslexia or ADHD engage with articles more easily
I fully understand the importance of licensing clarity, and I am happy to provide concrete proof of licensing rights if needed. My goal is to share this work in a way that strengthens Wikipedia’s mission of free, accessible knowledge for all.
Who would be an authority in this matter that will assist me in clarifying any issues? Is there someone I could turn to? Im convinced that the issue of licensing is not a problem. AmielRieger (talk) 17:58, 17 August 2025 (UTC)[reply]
Yes. I believe we have effectively already "released" these recordings under license. You can review them on our site https://ttsreader.com/wiki/.
On our site that we setup we already make these licensing declarations in accordance with the licensing required (as mentioned above). Please see a template for example: https://ttsreader.com/wiki/?article=Albert_Einstein (If you are already gonna visit the site then I would be very happy to hear your feedback)
Furthermore, as a test a couple of months back I uploaded an ogg file of the United States article. @Tbhotch at the time temporarily uploaded it after reviewing the recording in its entirety. It was also taken down by him a few minutes later.
Don't Creative Commons licenses automatically apply to derivative works? If so, they are necessarily released under compatible free licenses, and it is impossible for them to be released otherwise. jp×g🗯️17:03, 14 September 2025 (UTC)[reply]
Oppose Their answer about the source of their model's data is unsatisfactory. In the absence of an explicit statement that they personally sourced all of the inputs from freely licensed sources (i.e. they did not outsource the collection and vetting of inputs to another organization), and that they have and always will follow all of the requirements of those licenses, it is safe to assume that they, like every other AI model, are engaged in wholesale theft. Putting aside any legal arguments, as those are still working their way through the courts, it is unethical for a project built on and around a free license, and which has extensive policies about respecting copyright, to turn a blind eye to how the inputs of AI engines are collected and pretend that it's not a violation of our own community pillars to accept the outputs. The Squirrel Conspiracy (talk) 21:07, 17 August 2025 (UTC)[reply]
I also want to add that the accessibility angle rings hollow to me. People that need text to speech already have tools that are purpose-built for that function, and will do a better job of it then an AI transcript, with the added benefit that what they hear will always reflect the current version of the article. The Squirrel Conspiracy (talk) 21:14, 17 August 2025 (UTC)[reply]
Dear @The Squirrel Conspiracy. I have high regard for your concern for ethics, but I respecfully disagree with you. Furthermore to falsely accuse me and my organization of "wholesale theft" before honestly assessing, discussing and researching us and our content is unethical in its own right. ( I am somewhat taken aback by your smearing) So please deal with content of the discussion and refrain from judging or smearing us publicly. and now to respond to the points you are making:
I recognize concerns about how commercial AI models are trained, but this is not relevant to the licensing of the outputs. The recordings we provide are derived solely from Wikipedia content (freely licensed text) and are released with the same free license. By ensuring outputs are CC BY-SA 4.0, we comply fully with Wikimedia’s requirements and contribute material that enhances accessibility without introducing copyright conflicts. As simple as that.
Any further sophistry is not relevant.
Im surprised that the argument to make Wikipedia even more accessible is a red blanket to you, and the solution to that is not within the realms of Wikipedia. That seems not in line with Wikipedia's ethics. And if we are speaking about ethics, then the ethics of providing such a service (sooner rather than later) and accessibility to those with real limitations far outweigh the counter ethics of legally developed and licensed content based on AI engines. Important to emphasize, the textual content and thus the vocal output is pure Wikipedia text and as mentioned in my previous response all of our WIKI media is available to be used free, in line with Wikipedia licensing requirements.
@Sdkb The intent is good the implementation is not as I would have imagined the standard to be. We already hold some 50k articles in English and some 50k articles in Spanish. Each of these articles has both Male and Female voices. These voices are the leading voices available in terms of their humanlike nature, including intonation, emphasis, pauses and tones. All Im offering is to provide our existing content to Wikipedia.
this is not relevant to the licensing of the outputs This is where we fundamentally disagree. If your approach to concerns about the inputs is "it doesn't matter, just look at the outputs", our understanding of Wikipedia's goals and underpinning philosophy are wholly incompatible. The Squirrel Conspiracy (talk) 22:27, 17 August 2025 (UTC)[reply]
There do already exist TTS models that are based on properly licensed training data. I don't agree with the statement "it is safe to assume that they, like every other AI model, are engaged in wholesale theft." However, from what the project in question has already stated, they didn't select those fairly trained TTS models. Aurodea108 (talk) 20:22, 14 September 2025 (UTC)[reply]
People can run text-to-speech software on articles at any time, locally and with flexibility. What's the point of taking specific versions of articles and making them into inflexible audio files that go out of date almost instantly? Dan Leonard (talk • contribs)22:22, 17 August 2025 (UTC)[reply]
The point is that a for-profit company that no one's ever heard of gets to say that they have a partnership with Wikipedia - one of the most prominent brands on the internet - when they go to investors for their next round of funding. Let's not pretend for a moment that this effort is anything but self-serving. The Squirrel Conspiracy (talk) 22:29, 17 August 2025 (UTC)[reply]
I appreciate the thoughtful concerns raised here and want to address them directly.
First, regarding our company:
I am proud to say that TTSReader and the overriding company Well Source Ltd, is a completely self-funded company. We have never undergone a round of funding, we have no investors, and we are entirely bootstrapped and self-sustaining. We have been in the market for over 10 years, and today we serve more than two million people around the world, many of whom rely on our completely free services. So, while we may not be a household name, it would not be accurate to say that “no one has ever heard of us.”
Second, on the question of being a for-profit company:
Yes, we are a for-profit company. We are not ashamed of that, and we have no intention of hiding it. That said, our interest in contributing to Wikipedia is not at odds with that reality. We believe we have built one of the best TTS products and we have developed relevant content, and so we see alignment between what we’ve achieved and Wikipedia’s broader goals of accessibility and knowledge sharing. We have invested real money to create this content, and want to offer it for free to the Wikipedia community as it is freely available now on our website.
To be clear:
The content itself remains pure Wikipedia text.
The outputs (our audio files) are released under the appropriate free license and fully reusable under Wikipedia’s requirements.
Our intent is not to extract value from Wikipedia, but to add accessibility for audiences and yes to be proudly associated with contributing content to Wikipedia.
I understand the skepticism, particularly around the role of commercial actors. But I would argue that being a for-profit does not automatically make our contributions misaligned with Wikipedia’s mission. If anything, our long-standing sustainability without outside investors demonstrates independence, stability, and seriousness of purpose.
The audio file for an article becomes outdated as soon as the article is edited, which is one of the reasons why these text-to-speech projects aren't really popular on this site. Some1 (talk) 23:19, 17 August 2025 (UTC)[reply]
Thats a valid point. There are many points to ponder regarding this vision.
Our considerations are that, many many articles are not that dynamic in nature and thus the audio files remain relevant over a significant period of time. Furthermore, in most cases the vast majority of content remains the same and so the overall value of the audio file remains high. On our website we "freeze" the articles in time.
We are thinking of a mechanism where the audio files get updated (rerendered) when a certain threshold of change occurs. But this would require development and operating costs that at least for now we don't have those resources.
An alternative would be to integrate a player of sufficient quality into all articles and render them dynamically. This has its own complications both technological and potential overheads. Both I believe beyond the scope of Wikipedia. We for example can provide such integrations, and even provide it for free, but in light of the earlier discussions and perhaps because of association concerns this may not be viable. If anyone in Wikipedia is open to consider this avenue, I would be happy to discuss it.
Why are we even having this discussion? If you want to "provide the finished audio files, which can be uploaded to Wikimedia Commons and hosted like any other media file", then nobody here can stop you from doing that. WhatamIdoing (talk) 01:48, 18 August 2025 (UTC)[reply]
Thank you @WhatamIdoing, I am new to this world of content contribution and I made an initial test with the United States article. I linked it earlier: https://commons.wikimedia.org/wiki/File:United_States.ogg but a couple of days after I posted It was put forward for deletion by @The Squirrel Conspiracy and I see now that @Krd has removed it as of a couple of hours ago. Could you please guide me how to upload content while making sure that it wont be deleted? What should I do different in order to avoid this the next time?
Why we are having this discussion? Well, cause there is content available that I believe adds value to Wikipedia but I sense otherwise from certain players in the community. I have not been convinced. The content remains true to the original text and does not infringe on licensing guidelines etc. What if I load all 50k articles in Male and Female voice ie 100k files and because it bothers some they all get deleted, this is not clever on my part. Lets not forget the 50k Spanish articles we have too. Thus I preferred to raise this issue in this forum as I was recommended by @ChildrenWillListen and hopefully through open and honest dialogue I would be able to progress this topic. I was very encouraged initially when @Tbhotch had listened through the entire content and saw no flaw with the actual content. AmielRieger (talk) 08:02, 18 August 2025 (UTC)[reply]
As was mentioned above, you are free to upload your properly licensed audio files to Commons. Any uninvolved editor can link content from Commons in a Wikipedia article, but whether that link will be left in the article is subject to community consensus. I think it is clear that there is no appetite here for any formal connection with or endorsement from Wikipedia of your project. I suggest reading the essay at Wikipedia:Don't bludgeon the process before posting here again. Donald Albury13:36, 18 August 2025 (UTC)[reply]
A terrible American accent. Then it read "14 March" as "March fourteenth"! Sorry, but that's just wrong. You've lost me! HiLo48 (talk) 00:26, 18 August 2025 (UTC)[reply]
If you prefer a British accent that can also be synthesized ;-). Either way Im glad you listened to the content. Much more than many others. AmielRieger (talk) 07:29, 18 August 2025 (UTC)[reply]
You lost me at “recording”. Our articles change frequently (as editors add, subtract and reword information). So any recording would quickly become out of date. Non-starter right there. Blueboar (talk) 14:07, 18 August 2025 (UTC)[reply]
Oppose any commercial integration with or commercial endorsement by Wikipedia. Wikipedia is not a place to show off your new product nor a place to experiment with novel technologies. Our license permits the company to host a spoken Wikipedia mirror if they so choose, but there are serious unresolved moral and ethical problems with the technology itself, as well as inherent conflicts of interest with commercial entities. AmielRieger's dismissive rebuttal to The Squirrel Conspiracy above suggests that they already lean into the "ends justifies the means" ethical fallacy so common with large language model techbros that Wikipedia has always rebuked, and should continue to rebuke. We should not do this unless it's developed in-house, despite the difficulties that the m:Wikispeech project seems to be highlighting. Ivanvector (Talk/Edits) 14:18, 18 August 2025 (UTC)[reply]
Oppose for three reasons: the audio files would be outtdated the moment someone makes an edit, on-the-fly text-to-speech software is likely more useful for people with accessibility issues, and Wikipedia is not a platform to showcase technology based on large-scale theft. Cortador (talk) 15:23, 18 August 2025 (UTC)[reply]
I have ... received the impression that there is no desire to integrate such audio files in articles because of lack of human authenticity. I disagree with this stance, and would like this to be discussed once again.
So despite the fact that people already explained to you that we don't want it, you are asking the same question again? We still don't want it. And the next time you ask the same question we still don't want it. And if you keep asking the answer will still be 'no'. Hope that helps. Polygnotus (talk) 09:59, 19 August 2025 (UTC)[reply]
Well, irrelevant to Commons and Wikipedia, which are invested in copyright and not in the contractual agreements between two third parties. ꧁Zanahary꧂14:16, 21 August 2025 (UTC)[reply]
Oppose for the reasons explained by Cortador, Polygnotus, and others above, but also and at least as importantly at the moment, i do not believe that any AI production currently sounds even close to natural and will therefore, at least misrepresent our content and, possibly be inaccurate in its mispronunciations and mis-emphases. While this last reason may, just possibly, one day be eradicated, there isn't any chance that currently such "recordings" would be worth integrating into the encyclopaedia ~ or even linking to ~ LindsayHello16:15, 19 August 2025 (UTC)[reply]
Hi Amiel. I'm sorry that people are being hostile towards you. If your audio is already freely licensed, and Wikimedia Commons allows AI-generated material (it does, last I checked), then you should feel free to upload it to Commons. But you should probably check in at the Commons village pump first. Off the top of my head, it may be Commons's position that AI output may not be under a CC license, and is instead presumed to be ineligible for copyright protection and thus necessarily in the public domain. There is a template on English Wikipedia that embeds audio recordings at the top of an article. People could use that template to embed your company's outputs. ꧁Zanahary꧂20:52, 19 August 2025 (UTC)[reply]
We already have WikiProject Spoken Wikipedia for providing audible versions of articles, and I think that project needs more support before we even think of an automated solution. Issues with an automated TTS, like pronunciation problems and an audible version becoming outdated, are directly addressed by the project, which encourages its readers to look up pronunciation guides and focus on featured articles (which are not liable to greatly change over time). --Grnrchst (talk) 13:12, 20 August 2025 (UTC)[reply]
No thanks. Even if only freely licensed models were used, it would still be necessary for every output to be manually reviewed for mistakes and then rectified as needed. And as can be easily gauged from the sentiment expressed at WP:VPW recently about the WMF's AI summaries project, the community isn't interested in undertaking such a large task. Not worth the effort and time spent. JavaHurricane17:17, 21 August 2025 (UTC)[reply]
While I agree with the other concerns, I don't get this. TTS is not generative and does not hallucinate factual errors. Any minor audio glitches should be fixed with eyes wiki-style. Aaron Liu (talk) 17:36, 21 August 2025 (UTC)[reply]
This doesn't make sense. There is no reason to believe that TTS is more error-prone than humans at reading text aloud. ꧁Zanahary꧂17:59, 21 August 2025 (UTC)[reply]
does not hallucinate factual errors is untrue, at least in my experience with AI TTS tools. And this doesn't account for issues such as mispronounciations (especially with technical terms, for instance) which would still need correcting.
Any minor audio glitches should be fixed with eyes wiki-style: wouldn't be an issue if the load of articles for which audio files are being generated was not too large (as would be the case with audio files generated by humans under, say, WP:SPOKEN). Maybe I'm a cynic, but I don't see the load not being large with an AI TTS service being used. JavaHurricane12:36, 22 August 2025 (UTC)[reply]
Oppose. Who knows but that we might (accidentally) end up with another Bhutanese passport situation, for one thing. Also, don't most people with Internet access already have access to screen reader software? Your operating system should already have some feature that reads aloud the current version of a webpage (at least basic text, which we use), which avoids the aforementioned problem of our content constantly changing. Nyttend (talk) 09:58, 31 August 2025 (UTC)[reply]
Oppose many great opinions above to back this one up, but simply put enwiki as a project cannot be incorporating content that is from propriety software. Open-source software that gives public domain content should be a pre-requisite for our project. Besides we have an in-house extension in development that is opensource and freely licensed called meta:Wikispeech.
I don't really understand why people are bolding their responses to this, since it doesn't really seem like the kind of thing that is contingent on our approval or disapproval, but I guess that if that's what we are doing I may as well support it. As far as I can tell, the proposal is identical to WP:Spoken Wikipedia -- recordings being made of static versions of articles and then made available to readers with appropriate provisos. Any objection made on the basis that this is bad or dangerous, or provides some other detriment, would also apply to Spoken Wikipedia recordings. There are also a bunch of objections made on the basis of people disliking specific software companies on account of their being evil. This is true -- most software companies are, shall we say, ethically challenged -- but I think you will agree that a similarly puritanical proposal to require all Wikipedia users to run Linux (or even to use Firefox) would be an obvious nonstarter. There remains the completely unprecedented idea, lately in vogue, that anybody who speaks must do so with the express approval of the holding companies which own every copyrighted work he has ever heard in his entire life, which I think fundamentally does not make sense, although IP trolls on Bluesky have been saying it over and over for years; the idea that the companies are "brothers", which makes their products bad(?); altogether I do not really see an objection to this, except that it makes us as human editors feel bad to have our "brand" diluted. jp×g🗯️17:21, 14 September 2025 (UTC)[reply]
(Sorry to repeat what I said above; I guess I should've read all the new replies before replying.) Spoken Wikipedia involves human readers, which necessarily has some degree of more accurate pronunciation and intonation. Having TTS everywhere provides no advantage to what can already be done with the user's browser or operating system. Aaron Liu (talk) 17:46, 14 September 2025 (UTC)[reply]
I have never before heard the idea that Wikipedia should omit features/content on the basis that some readers probably have the technical resources to do it themselves. For example, we have dark mode — despite the fact that some people (like myself) can write their own stylesheets — I've heard nobody say dark mode was therefore a waste of time, certainly never that we shouldn't allow people to implement it on their own [t/d]ime. I think this argument would, in any other circumstance, be considered a total non sequitur; the style of reasoning is used nowhere else on the project.
It is true that some people have browser TTS; I don't have any easy way to do it on my desktop. I do on my cell phone, which was a fairly expensive high-end one when I bought it. I do not really agree with the idea that we should not allow people to contribute content for free because people with expensive cell phones can in theory set up a way to recreate that same content with their own hardware. jp×g🗯️19:18, 14 September 2025 (UTC)[reply]
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.
Change the Village Pump's colour.
This colour is ugly :(
Do you think we should change the village pump's header color? Personally, I dislike this yellow-brownish color; it feels outdated and isn't in the usual Wikipedia style. We have so many better colour options over at pages like:
and many others. I suggest we pick a replacement for the current color. The colors below are just some examples; the first three are used on the Main Page.
Update 16:08, 21 August 2025 (UTC): Zanahary has created actual mockups; you can see them in the § Mockups section. (I also collapsed the other color choices below, which weren't being voted on.)
Option A
this is an example of black text with color applied to its background and border
Option B
this is an example of black text with color applied to its background and border
Option C
this is an example of black text with color applied to its background and border
Option D
this is an example of black text with color applied to its background and border
Option F
this is an example of black text with color applied to its background and border
LMFAO. Chaos! Hyperbole much? Encountering an unexpected color change, editors will be beside themselves and won't know what to do! If I didn't know you, I'd suspect trolling. ―Mandruss☎ IMO. 07:10, 11 September 2025 (UTC)[reply]
The current dehydrated beige-yellow-ish looks fine as-is, but D also looks great. Everything else is too light, imo. EF500:29, 21 August 2025 (UTC)[reply]
Support for decorative reasons. This will give visual impact and this will be decoratively clear for colorblind users. Additionally, this will make the Village Pump creatively nice and beautiful. Fabvill (Talk to me!)01:09, 21 August 2025 (UTC)[reply]
Whatever you do, don't forget about dark mode whenever you pick colors nowadays. it has to be legible in both, or you need additional colors for dark mode. —TheDJ (talk • contribs) 11:48, 21 August 2025 (UTC)[reply]
All of the options look ok to me in dark mode. A and C are pretty dark, but I don't see how that would be a problem in dark mode. You want dark? You got dark. Mustn't wake up the wife. Text-background contrast is fine for all. ―Mandruss☎ IMO. 07:59, 11 September 2025 (UTC)[reply]
Support D as proposer; I like purple in general and D is also used on the Main Page, so I agree with the other comments. The village pump should be welcoming and purple is perfect for that. FaviFake (talk) 12:01, 21 August 2025 (UTC)[reply]
Support, the color is indeed ugly right now. I have no problem with any of the mockups made by the proposal nor by myself below. ꧁Zanahary꧂14:34, 21 August 2025 (UTC)[reply]
Sure, no harm, purple would probably look nicer than the current option. But this really isn't the most pressing issue facing us at the moment; bold editing might have been better than launching a giant survey. I'd suggest this be moved to the talk page. Sdkbtalk15:01, 21 August 2025 (UTC)[reply]
But this really isn't the most pressing issue facing us at the moment - Oh I wasn't aware we were supposed to limit discussion to the most pressing issue (wouldn't that mean one thread on the page at a time?). bold editing might have been better than launching a giant survey. Bold editing would have been promptly reverted by one of the Opposers in this discussion. Then we'd be here anyway. We just skipped two needless steps in the process, B and R, and led with D. No, it doesn't need to go to talk. ―Mandruss☎ IMO. 07:28, 11 September 2025 (UTC)[reply]
OpposeWP:DONTFIXIT, there's nothing wrong with the current color and there's nothing better about any of the suggestions below. All this will come down to is which color happens to get the most "I like it" votes from people who bother to comment at all. Anomie⚔16:11, 21 August 2025 (UTC)[reply]
Not so much. We're looking at actual real tangible things like contrast ratios. Besides, I have no problem with popularity for something like this. ―Mandruss☎ IMO. 11:56, 11 September 2025 (UTC)[reply]
The only discussion of contrast ratios is making sure all the options have good ratios. Your own chart below shows that the current one has a better ratio that many of the proposed options, but even the worst is well above the minimum. So, no, that doesn't really seem to be part of anyone's decision here. Anomie⚔12:06, 11 September 2025 (UTC)[reply]
Fine. In that case, I have no problem with popularity for something like this. Also, one of my greatest Wikipedia pet peeves is resistance to change. "What we have is fine" is a horrible argument, just horrible. ―Mandruss☎ IMO. 12:32, 11 September 2025 (UTC)[reply]
Did the current color set even get so much as "a popularity contest vote"? The colors for talk page templates did (Wikipedia:Talk page templates/vote). It would be unfortunate if we rejected the results of current discussions as a mere vote, if the current state didn't even get a discussion in the first place. WhatamIdoing (talk) 16:08, 11 September 2025 (UTC)[reply]
Support D (or option 6 below, with option 5 as a second choice). I don't think WP:DONTFIXIT applies here as there is an identifiable issue, even though it is of an aesthetic nature. I also wouldn't be opposed to revamping the tab design entirely, as the border still gives it a very dated feel. Chaotic Enby (talk · contribs) 17:30, 21 August 2025 (UTC)[reply]
After trying the mockups below, also support option F as a third choice. My only worry is that it might be a bit too close to the WP:CENT color. Although Option D would likely look better with a lighter border like F's. Chaotic Enby (talk · contribs) 12:54, 22 August 2025 (UTC)[reply]
One thing I forgot to consider: on blue and purple skins, blue and purple links will naturally be less readable. I added colored links to my mockups – looking at the contrasts, I now have a preference for option F over option D. Chaotic Enby (talk · contribs) 18:19, 22 August 2025 (UTC)[reply]
Looks like that would only work in Vector 2022 and Minerva. Those CSS variables don't seem to be defined in Vector, Monobook, or Timeless. Anomie⚔18:20, 31 August 2025 (UTC)[reply]
Yeah apologies that's why you define them like this: var( --background-color-success-subtle, #dff2eb );. thanks for letting me know, I didn't actually know that :) waddie96 ★ (talk)22:59, 31 August 2025 (UTC)[reply]
Option A. Tastefully understated, calming, not one of the overused blues. Like the paint in a doctor's office. Brown looks like dirt; if I see that on the walls of my doctor's office, I'm finding a different doctor. And that's how to put together a proposal, by the way. ―Mandruss☎ IMO. 07:13, 11 September 2025 (UTC)[reply]
Comment. I used Snook's Colour Contrast Check. For the uninitiated, higher numbers are better, and all values exceed WCAG 2.0 Level AA (4.50) and WCAG 2.0 Level AAA (7.00) by a wide margin. Black-on-white and white-on-black are 21.00. I'm assuming #000000 for black and #FFFFFF for white, though I can't get Firefox's color picker to verify that for text.
The examples here (as well as the current header) all specifically set color:black, overriding the Vector 2022 (and Minerva) default text color of #202122. When I toggle Vector 2022's dark mode, the current header's colors are overridden entirely (we wind up with #eaecf0 text on a transparent background (showing through black), with the colored border remaining unchanged) while the examples here are not changed for dark mode at all. Anomie⚔12:00, 11 September 2025 (UTC)[reply]
There shouldn't be a problem if just the colors are switched in the existing {{Start tab}} invocation. You said I'm assuming #000000 for black and #FFFFFF for white, though I can't get Firefox's color picker to verify that for text, so I was providing more information on the text color used for the header and why it's actual black rather than Vector's normal dark-grey. Anomie⚔13:57, 12 September 2025 (UTC)[reply]
Comment. Revised table. For the purposes of contrast checking, I think we need to look at the paler of the two shades in each option sample. For the previous table, I was looking at the darker shades. I'm just correcting the record; the conclusion is the same: Contrast is not an issue.
Comment. This is not a suggestion for proposal expansion (I know better). But I note that there's a lot of brown on the site; just look at the top of an article talk page, for starters. I can imagine the output of this proposal becoming the new en-wiki color, thereby conveying a certain site-wide cohesion—like there is actually somebody in charge of the whole site; like there is some coordination happening. If it's good at village pump, it's good anywhere. One could argue that the brown does exactly that; problem is, it's a terrible color choice. And the browns aren't the same, anyway.As I understand it, this is what CSS is for. With a virtual flick of a switch, we should be able to change en-wiki's color site-wide. Anything less is 20th century technology. The uses for that switch are yet to be imagined, but I'm certain they would exist. ―Mandruss☎ IMO. 02:41, 13 September 2025 (UTC)[reply]
I think it would be nice if the Villages Pump had different color schemes to more easily distinguish them, but for the record, the heretofore-besmirched "yellow-brownish color" is actually a quite venerable piece of Wikipedia design history: the palette used by talk page headers and message boxes is called "ClockworkSoul's Coffee Roll" and it dates to a big RfC from some twenty or so years ago (prior to that, there was no unified formatting for the headers at all, and they were just all totally different styles and it looked like puke). jp×g🗯️19:20, 14 September 2025 (UTC)[reply]
I note none of the examples given here actually show what the header would look like. Even the one that claims to be the current color isn't, nothing in the current header uses this color. If we want to make a choice, we should probably have accurate mockups to choose from. Here's some wikitext to mockup the current coloring:
Selected tab
Other tab
Other tab
Other tab
Other tab
Other tab
This is the actual current village pump color. It uses the 50° row from Help:Using colours: "header background" as the background, "header border only" as the border, and "accent color" for the inactive tabs.
Unfortunately I can't guess at what was intended for any of FaviFake's suggestions here to mock them up similarly. Anomie⚔12:09, 21 August 2025 (UTC)[reply]
You're right. I only copy-pasted these "coloured boxes" from the pages i linked to to get a general sense of which one people would prefer. If a colour is more liked than others, say, green, we could then figure out all the specific shades of green for the border, inactive state, background, etc. I could work on creating more accurate mockups, but I think other people would do a much better job than me. I'm no colour scientist. (However, I've changed the incorrect colour you pointed out; it was intended to be more visually pleasing, but I agree it should match the current colours.)
The following discussion has been closed. Please do not modify it.
If you don't know what you're doing, perhaps you should take a step back and ask people for help before making half-baked proposals. Anomie⚔12:50, 21 August 2025 (UTC)[reply]
Excuse me? Again, my goal wasn't to propose specific colors. I wanted to see if there was consensus for changing the current colour. As I stated in my proposal, the examples were just that, examples of colours I thought looked better. FaviFake (talk) 14:10, 21 August 2025 (UTC)[reply]
An initially inaccurate summary along with suggestions that don't correspond to how the colors would actually be used doesn't sound fully baked to me. FaviFake has been doing a lot of this sort of thing lately. Anomie⚔14:33, 21 August 2025 (UTC)[reply]
I do agree there is something wanting in the current color choice. However, I'm not sure whether to support, due to a lack of discussion on which color, if any, is best accessibility-wise. A second concern is how the new header would appear in light vs dark mode, and on mobile vs. desktop. Dege31 (talk) 00:41, 3 September 2025 (UTC)[reply]
This is the village pump header using the 50° row. That's "header background" as the background, "header border only" as the border, and "accent color" for the inactive tabs.
This is the village pump header using the 40° row. That's "header background" as the background, "header border only" as the border, and "accent color" for the inactive tabs.
Option 2
Other tab
Other tab
Other tab
Other tab
Other tab
This is the village pump header using the 90° row. That's "header background" as the background, "header border only" as the border, and "accent color" for the inactive tabs.
Option 3
Other tab
Other tab
Other tab
Other tab
Other tab
This is the village pump header using the 140° row. That's "header background" as the background, "header border only" as the border, and "accent color" for the inactive tabs.
Option 4
Other tab
Other tab
Other tab
Other tab
Other tab
This is the village pump header using the 190° row. That's "header background" as the background, "header border only" as the border, and "accent color" for the inactive tabs.
Option 5
Other tab
Other tab
Other tab
Other tab
Other tab
This is the village pump header using the 240° row. That's "header background" as the background, "header border only" as the border, and "accent color" for the inactive tabs.
Option 6
Other tab
Other tab
Other tab
Other tab
Other tab
This is the village pump header using the 290° row. That's "header background" as the background, "header border only" as the border, and "accent color" for the inactive tabs.
Option 7
Other tab
Other tab
Other tab
Other tab
Other tab
This is the village pump header using the 340° row. That's "header background" as the background, "header border only" as the border, and "accent color" for the inactive tabs.
Options A, B and D derive their color palettes from the 150°, 210° and 270° rows respectively, with the only difference being the use of "main background" for the lightest color instead of "accent color", while options C and F have unique color palettes. Here is what the header would look like using these color palettes directly (as well as the 150° row for comparison).
Option A
Other tab
Other tab
Other tab
Other tab
Other tab
This is the village pump header using the Option A palette. That's "Title background" as the background, "Title border" as the border, and "Light Box background" for the inactive tabs. On Vector 2022, blue links look like this and purple links look like this. On other skins, blue links look like this and purple links look like this.
150° row
Other tab
Other tab
Other tab
Other tab
Other tab
This is the village pump header using the 150° row. That's "header background" as the background, "header border only" as the border, and "accent color" for the inactive tabs. On Vector 2022, blue links look like this and purple links look like this. On other skins, blue links look like this and purple links look like this.
Option B
Other tab
Other tab
Other tab
Other tab
Other tab
This is the village pump header using the Option B palette. That's "Title background" as the background, "Title border" as the border, and "Light Box background" for the inactive tabs. On Vector 2022, blue links look like this and purple links look like this. On other skins, blue links look like this and purple links look like this.
Option C
Other tab
Other tab
Other tab
Other tab
Other tab
This is the village pump header using the Option C palette. That's "Title background" as the background, "Title border" as the border, and "Light Box background" for the inactive tabs. On Vector 2022, blue links look like this and purple links look like this. On other skins, blue links look like this and purple links look like this.
Option D
Other tab
Other tab
Other tab
Other tab
Other tab
This is the village pump header using the Option D palette. That's "Title background" as the background, "Title border" as the border, and "Light Box background" for the inactive tabs. On Vector 2022, blue links look like this and purple links look like this. On other skins, blue links look like this and purple links look like this.
Option F
Other tab
Other tab
Other tab
Other tab
Other tab
This is the village pump header using the Option F palette. That's "Title background" as the background, "Title border" as the border, and "Light Box background" for the inactive tabs. On Vector 2022, blue links look like this and purple links look like this. On other skins, blue links look like this and purple links look like this.
Contrary to the popular opinion, Palette 'Blue' and 'Purple' (Options B, D & F) are clearly mixing-up with the Blue & Purple links, which will make it very hard for the color blind to distinguish.
That only leaves us with 'Green' (A) and the current 'Yellow' (C). Yellow is going to be replaced, so I would prefer Green - Light Green (Option 2 in this list) since not only is it different from the existing Green 'tq' function, but also it has a tint of legacy of its 'soon to be predecessor' Yellow. Cdr. Erwin Smith (talk) 08:21, 4 September 2025 (UTC)[reply]
That is actually genius! But we might need to create another VP topic to gather consensus for this, I suspect it'd be much more controversial. FaviFake (talk) 17:49, 13 September 2025 (UTC)[reply]
Numerically, there were 7 supports and 7 opposes. However, Wikipedia discussions are not a vote but a discussion. On the "for" side, people pointed out that the page was not well formatted, and cluttered up space. However on the "against" side, people pointed out that the page should be improved, not deleted, and in the standard Vector 2022 view that most people use, it didn't clutter much space. Therefore, I see no consensus to remove the contents link. —Matrixping mewhen u reply (t? - c) 16:14, 18 September 2025 (UTC)[reply]
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.
Yes as proposer. I'm not convinced that this page is really helpful for browsing Wikipedia, so I think would be helpful to have a discussion on removing the link. I initiated a discussion regarding whether to remove the link, but the discussion got stale, and it was eventually archived. I hope to achieve this by doing an RfC regarding this. Interstellarity (talk) 13:20, 22 August 2025 (UTC)[reply]
I do not support the proposal. I think it is reasonable to have a starting framework for browsing an encyclopedia, and that a contents link in the side bar fits this purpose. The rationale expressed in the previous proposal was more suitable as motivation to improve the lists of content and their presentation. isaacl (talk) 15:34, 22 August 2025 (UTC)[reply]
Oppose per Isaacl. It's worth noting that the way most readers see Wikipedia (open an article in a logged out private browsing window if you haven't in a while), the main menu is hidden behind a hamburger (three dashes stacked on top of each other) dropdown option in the upper left. So it's not as if it's a terribly prominent link that needs to justify being shown to everyone all the time. Sdkbtalk15:42, 22 August 2025 (UTC)[reply]
Oppose per Sdkb and isaacl. "Contents" is a useful link and shouldn't just be removed. If you don't like clicking on the link, either don't, or suggest improvements to the article itself. I'm sure there is a better contents page design out there if we're motivated enough to find one. --📎 JackFromWisconsin (talk | contribs) 15:50, 22 August 2025 (UTC)[reply]
Support – This is not how most users browse Wikipedia, and it only clutters the sidebar. I wished they'd remove it with Vector 2022, but alas it's still here. --FaviFake (talk) 16:12, 22 August 2025 (UTC)[reply]
As I alluded to in my !vote, what Vector 2022 did was essentially remove all the sidebar links by placing them under a hamburger menu (rather than directly visible on the page) for most users. I think that was the right call. Since while the Contents link isn't particularly useful, nor are the others. The actual links in the sidebar are under community control. Sdkbtalk16:25, 22 August 2025 (UTC)[reply]
My thinking was (which I agree that I should have explained), that people these days are far more likely to use search to find the content they are looking for rather than trying to navigate through a top-down list, and hence the link isn't useful. * Pppery *it has begun...18:15, 22 August 2025 (UTC)[reply]
Oppose. If you just cut off the (subjectively) least-useful link you gain nothing but a different (subjectively) least-useful link until you have no links at all. We have nothing to suggest that those who use it don't find it useful, and we have no suggestions for something more useful to take its place. It's not causing any harm, and nobody is forcing you to click the link - heck someone with more technical know-how than me could probably give you some fancy custom CSS or js to hide the link if it bothers you. Thryduulf (talk) 16:56, 22 August 2025 (UTC)[reply]
I'm looking for something that is basically a list of articles rather than a list of lists. Something like an A-Z list, but Wikipedia has too many articles to list alphabetically. If we can find a page where similar articles are grouped together similar to an outline. Example: History of the United States goes under United States, similar to Outline of the United States, but for all Wikipedia articles. Not sure if we have a page for that, but I'd be willing to create one if there's a need for it. Interstellarity (talk) 17:49, 22 August 2025 (UTC)[reply]
I was being tongue in cheek, but actually using this is probably a bad idea as not every article has a corresponding list (cf. WP:NLIST). Though I wouldn't be surprised if nevertheless it's still more useful for your average Wikipedia reader. novovtalkedits09:43, 24 August 2025 (UTC)[reply]
Oppose per the arguments above. If you think it's subpar, you are welcome to improve it. In my opinion, it makes sense for an encyclopedia to have a contents listing like Wikipedia:Contents. Consider also that, as mentioned above, Vector 2022 hides the entire sidebar in a dropdown by default, so it's not like the link clutters the page at all. (If you want to hide it, you can use this CSS: #n-contents {display: none;}) OutsideNormality (talk) 17:46, 23 August 2025 (UTC)[reply]
The page views for this page are kind of weird. ~450K per month until May 2020, when it halves. (What did we do that month, rearrange the Main Page?) Then it almost halves again, starting in late January 2023, when WP:Vector 2022 was deployed. The question that I'd like to be able to answer is: When readers get to that page, are they satisfied with it? What happens next, if an ordinary reader ends up on that page? WhatamIdoing (talk) 21:59, 23 August 2025 (UTC)[reply]
This seems like a good thing for the WMF to do. They are good at making a/b tests and running experiments. Maybe a technical team get can involved a new approach could use categories and something a little more dynamic. Definitely dreaming big here. 📎 JackFromWisconsin (talk | contribs) 02:55, 24 August 2025 (UTC)[reply]
Trying to formulate some sort of vote that runs along the lines of Keep but delete the most prominent part, which is the "Browse by subject area". Firstly, "Wikipedia's content is divided into broad subject areas" does not reflect how our content is divided, to the extent that it is this is through the category system which functions as a series of overlapping tags rather than discrete silos. Secondly, the specific subject pages like Wikipedia:Contents/Culture and the arts seem like weird duplications of outline articles such as Outline of culture. Thirdly, we already have a system that divides important content into subject, Wikipedia:Vital articles, which is included as part of Wikipedia:Contents so there's some weird nesting dolls of content division. And of course, the lists don't seem maintained (possibly because they duplicate the article space as well as Vital articles). Getting rid of these is a much better option than investing time into overhauls (of content that exists elsewhere!) as some have suggested above.However, while we don't divide out content into broad subject areas, it does seem useful to have a space that explains how we do divide our content. "Browse by format" seems useful to readers, give or take how much each format is used (hopefully it would be adjusted if those change). Introducing readers to the Featured and Good quality content systems would help them understand at least to some extent how content is developed. If readers do want subject lists, Vital articles provides an already curated list (although it should not be in the "Articles by quality" section). There are probably other tweaks that can be made, but repurposing the page to talk about Contents in the system sense rather than the Subject sense seems like it would be more helpful and duplicate the search bar less. CMD (talk) 04:14, 24 August 2025 (UTC)[reply]
I'm concerned that this is more of a pointy deletion....user for years has been unable to implement they preferred layout of vital articles being seen first. My concern is the vital article project is trying to take this over. I believe the vast majority of editors here see the vital article project as extremely unstable and not representative of our worldwide viewership. Moxy🍁20:07, 24 August 2025 (UTC)[reply]
I didn't really even know about this page. From the UseModWiki dumps, it dates back to January 2001. It has me thinking, how would you design a useful contents page for this whole project? It seems like something that ought to be in the sidebar, if it could be made into something nicer. Makes me want to draw concept art. 3df (talk) 07:02, 10 September 2025 (UTC)[reply]
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.
Propose to deprecate direct linking to non-English Wikipedia in articles
E.g. I am viewing Maheboob Khan, and click the link "Maula Bakhsh" which bring me to Dutch Wikipedia article. Similarly, the link "Maritim Hotelgesellschaft" in Maritim Travemünde links to German Wikipedia. This has two disadvantages: (1) It clearly violates WP:ASTONISH; (2) This does not encourage creation of articles in English Wikipedia. So I propose we should only link to foreign Wikipedia via {{Interlanguage link}} and create an AbuseFilter to prevent users from adding direct links to non-English Wikipedia in articles. GZWDer (talk) 01:56, 31 August 2025 (UTC)[reply]
Comment - This is already deprecated per H:FOREIGNLINK, which explains that you should use the inter-language link template so that the English Wikipedia article for it shows up as a redlink which is accompanied by a smaller bracketed link to a foreign language article. I've gone ahead and fixed the issue with the article.--JasonMacker (talk) 03:13, 31 August 2025 (UTC)[reply]
I was surprised to see this, because it's been officially discouraged for years. @GZWDer, do you really mean to be asking if someone would figure out how many of these errors exist and fix them for you, or were you just trying to get a rule written down, even though nobody will read it? WhatamIdoing (talk) 04:53, 31 August 2025 (UTC)[reply]
WP:AFD is neither a policy nor a guideline. WP:RFC is neither a policy nor a guideline. WP:BRD is neither a policy nor a guideline. WP:5P is neither a policy nor a guideline. WP:TE is neither a policy nor a guideline. Editors want to do the right thing, and they don't require good advice to say "policy" or "guideline" at the top of the page to do the right thing anyway. WhatamIdoing (talk) 20:13, 31 August 2025 (UTC)[reply]
Not sure if interwiki links are explicitly "deprecated" by H:FOREIGNLINK, but the ill template is the best practice and avoids the issues raised. What gets tricky is edits such as Special:diff/1308072402, which places the link somewhere a template may break things. CMD (talk) 05:21, 31 August 2025 (UTC)[reply]
Oppose per Thryduulf. We shouldn't get in the way of adding links to other Wikipedias when relevant. Of course, I don't have any objection to banning links like the one you propose (I agree with your references to ASTONISH and RED), but if we go creating an abuse filter, it won't be able to distinguish between good and bad. Nyttend (talk) 09:51, 31 August 2025 (UTC)[reply]
Oppose. This does not seem to be a big enough problem to justify an edit filter, which can only be edited by a few people and needs testing. The use of {{Interlanguage link}} is already listed as best practice by H:FOREIGNLINK and it doesn't matter a bit whether it is called a policy or a guideline. What matters is that it's a good idea. Phil Bridger (talk) 10:25, 31 August 2025 (UTC)[reply]
Comment I like this idea but I'm not exactly sure what is being proposed. My complaint is that articles should be internally linked to internal wikipedia articles. What I mean is that English wikipedia articles should only link to other English wikipedia articles. Logoshimpo (talk) 11:05, 31 August 2025 (UTC)[reply]
We also link to Wiktionary and Wikisource. We don't do this very often, so you might not have seen it, but one hardly wants to dumb down our writing ("but readers won't know what that word means!"), and sometimes a link to the dictionary definition makes a good compromise between brilliant prose and helping readers understand it. Wikisource links tend to be for non-notable historical documents ("issued the 1789 proclamation for the election") or in a list of works (* "The Bluebell" by Anne Brontë). WhatamIdoing (talk) 20:22, 31 August 2025 (UTC)[reply]
I'd support upgrading a slimmed-down version of H:FOREIGNLINK to guideline status or adding it to the MOS, but I strongly oppose an addition to the AbuseFilter as overkill for a really minor problem. Toadspike[Talk]17:57, 31 August 2025 (UTC)[reply]
Thanks, I missed that. We should consider upgrading "may be helpful" to "should be used" based on the strong preference for the Ill template here and elsewhere. Toadspike[Talk]14:07, 9 September 2025 (UTC)[reply]
Oppose articles in other language Wikis are useful in the absence of an English article since translation programs, however flawed they are, are available and better than nothing.--Wehwalt (talk) 19:56, 31 August 2025 (UTC)[reply]
That's exactly the role of {{ill}}: it does give a bluelink to the existing article in the other language, explicitly identified by what language it is, but it also has a redlink to the enwiki article. That means readers can immediately read (and decide if they are able to read) but there's also a tracked inbound link and an easy route to creating the article (for example, de novo or by translation). DMacks (talk) 02:14, 1 September 2025 (UTC)[reply]
Oppose, seems to already be covered by the MOS and Help. No need for more instruction creep, and there are potential reasons to allow such links. —Locke Cole • t • c00:26, 2 September 2025 (UTC)[reply]
Oppose. there are many times when linking to a non-English Wikipedia entry is actually the best option, as we don't always have corresponding articles. The template is the best solution, but adding an abuse filter seems unnecessary. Firsfron of Ronchester00:45, 2 September 2025 (UTC)[reply]
Oppose abuse filter; per Toadspike, I would support strengthening of language at MOS:IWL with more precise directions for the use of {{ill}}. In my opinion, {{ill}} should always be used when linking to a non-English wiki. Wrackingtalk!01:59, 2 September 2025 (UTC)[reply]
Except in rare cases, it's my impression that if {{ill}} isn't used, it's not for a lack of directions. It's because the editor didn't know that the option existed, and they'd be happy to have someone add it for them. If we could find a way to locate 'missing' uses of the template, and had a volunteer to fix them, then I would expect that to be welcome assistance. WhatamIdoing (talk) 02:24, 2 September 2025 (UTC)[reply]
Fair enough. I agree that editors not knowing about {{ill}} is probably a primary cause of this, and a way to locate 'missing' uses of the template would be great. Wrackingtalk!02:37, 2 September 2025 (UTC)[reply]
{{ill}} is also a real pain to use. Highly non-intuitive. I have to consult the documentation every time I have to use it. Usually takes a couple of goes to get it right. Hawkeye7(discuss)02:43, 2 September 2025 (UTC)[reply]
+1 all of this. I think something like {{ill|langcode:article}} would rock, exactly matching the style of [[:langcode:article]] interwiki links (and the natural extention of piping, as {{ill|langcode:article|displaytext}} for [[:langcode:article|displaytext]]). Or {{ill|:langcode:article}}, which probably makes it trivial to program (a "if first parameter has leading colon, parse off the first colon-delimited string and push it into the second parameter" wrapper converts it directly to the currently-handled syntax). DMacks (talk) 02:57, 2 September 2025 (UTC)[reply]
I would object to introducing such complexity across every use of this template when most of the usages probably won't use this complex feature (complex as it involves string operations). How about instead introducing a new template that uses this syntax? Aaron Liu (talk) 01:05, 3 September 2025 (UTC)[reply]
Nearly all uses of the template link to a single language code, but the template is optimised for multiple languages. So we can have things like: {{ill|Charles Darwin (botanist)|lt=Charles Darwin|fr|Charles Darwin|de|Charles Darwin|es|Charles Darwin}}. This illustrates the difficulty remembering how it works. The first guess of most users would be {{ill|fr|Charles Darwin}}. That is wrong; the English text has to come first. And while the editor might expect the next parameter to default to the display text, this actually requires |lt=, an abbreviation I'm not aware of being used anywhere else. Hawkeye7(discuss)01:43, 3 September 2025 (UTC)[reply]
If I were writing the parameters from scratch, I'd have chosen something like {{ill|target=local link|text=display text|lang=code|article=other wiki article|lang2=code|article2=other other wiki article}} (e.g. {{ill|target=London|text=Capital of the United Kingdom|lang=cy|article=Llundain|lang2=fr|article2=Londres}}) as those are names and ordering that intuitively make sense to me. Whether they made sense to anybody else I'm not sure but the ordering seems to match what others are suggesting. I don't have a clue how easy this would be to program. Thryduulf (talk) 03:41, 3 September 2025 (UTC)[reply]
I don't see why that means we can't have a lang alias for just the first language.I agree that "lt" is weird. I'd use display, text, or something. Aaron Liu (talk) 16:25, 3 September 2025 (UTC)[reply]
Can't an edit filter not just disallow an edit, but also tag an edit? Not sure how hard/easy it is to add a custom tag, but if there were a way to filter recent changes to show edits that added an interwiki, it might make what you're thinking of easier to track. =) —Locke Cole • t • c04:31, 2 September 2025 (UTC)[reply]
Answering my own question, but yes, from WP:EFBASICS, denying altogether is an option, but so is warning, tagging, or simply logging. Warning might not be a bad option, if the warning is customized to let the editor know about the interlanguage templates, it could be both educational and a way to remind editors in case they forgot. —Locke Cole • t • c04:44, 2 September 2025 (UTC)[reply]
I did a search and found that this was an edit filter before (780); it was disabled in 2016 by MusikAnimal (Too infrequent and for the good-faith edits I'm not too happy with even throwing a warning) Also, I left a note at WP:EFN to alert watchers of this discussion.Wrackingtalk!05:27, 2 September 2025 (UTC)[reply]
Correcting myself. It seems 780 (hist·log) was meant to catch attempts at connecting different-language, same-topic articles via a link at the bottom of the article (also called interlanguage linking); this is now handled via Wikidata. The issue we're discussing here is the in-text linking of non-English wiki articles instead of using {{ill}} template (per MOS:IWL, WP:ASTONISH). Wrackingtalk!05:42, 2 September 2025 (UTC)[reply]
Oppose per WP:CREEP and WP:IAR. Note that there are Wikipedias for Simple English and Scots which would not be especially astonishing. Fixing up such usage with templates or whatever is routine work for gnomes. Andrew🐉(talk) 05:42, 2 September 2025 (UTC)[reply]
I disagree - anytime a link sends the user outside en.wikipedia.org this should be clearly messaged before the click is made. There's no reason to have exceptions to this principle. (I for one would find it very astonishing to find myself at the Scots(?) wikipedia w/o prior heads-up). Regards CapnZapp (talk) 08:12, 2 September 2025 (UTC)[reply]
Comment What does "deprecate" mean? I thought this was already discouraged. I don't think trying to actively prevent users from direct links is useful. Generally, spending effort making it hard or impossible to do wrong is futile; we should instead trust users to do the right thing. We can always revert/admonish/ban mistakes and errors after the fact. Discouragement should be sufficient. Does this mean I'm opposing? Then so be it. If this proposal's "deprecation" includes a suggestion to make sure our discouragement is clearly communicated, however, I'm in support. CapnZapp (talk) 08:08, 2 September 2025 (UTC)[reply]
Even if you considered it "already discouraged", there are still many such links existing and should potentially be replaced with templates. GZWDer (talk) 12:59, 2 September 2025 (UTC)[reply]
GZWDer That's not the proposal discussed here? Certainly not ALL such links should be replaced. When context makes the out-of-English-Wiki link obvious, {{ill}} is less necessary. {{ill}} is less desirable on pages with very many links. So if you want to discuss how to find them so you can manually convert them, go ahead, nothing is stopping you. Cheers CapnZapp (talk) 11:25, 3 September 2025 (UTC)[reply]
Declaring something to be unwanted doesn't help us find and fix the problems. I realize that since I spend so much time working on policies and guidelines, it surprises people to hear me say it, but Wikipedia:Nobody reads the directions. This is just the reality we work in. It often takes two years for editors to notice changes even to the highest-traffic policy pages. Writing down the answer is IMO good, and it's helpful to the rare person who goes looking, but seriously: Policy and guideline pages are not magic pixie dust. Not one of us has actually read them all. Need proof? This whole discussion began because someone thought we needed a rule that has already been documented in at least two guidelines and one help page for years.
WhatamIdoing First off, maybe you're responding to GZWDer and not me? (Your first sentence appears directed at me; your last at them) Anyway, of course nobody always read the rules. That doesn't mean we should always (or even often) back up the rules with things like edit filters that physically stop editors from breaking them. Is this a case where strong measures are warranted? I say no. Yes, I've found cases where an "invisible" off-en-wiki link was inappropriate, but... then I fixed it. This is not on par with, say, how we ask IP editors to solve a captcha before they can add external links to articles. CapnZapp (talk) 11:30, 3 September 2025 (UTC)[reply]
I would be happy to have stronger wording that discourages linking to other Wikipedias by means other than {{ill}} and would support some project to systematically search and eliminate such links (for example, insource:/\[\[\:de\:/ helps search for German Wikipedia links; I also use CSS to underline these links so I notice them more easily), but I can imagine some places (like tables where the linking is explained outside of the table) where they are appropriate, so I hesitate to support this as written. —Kusma (talk) 10:21, 2 September 2025 (UTC)[reply]
Support in principle. This should not be blocked by an edit filter, but if an EF can flag and/or log such additions so they can by fixed by the gnomishly inclined, that would be great. older ≠ wiser11:46, 2 September 2025 (UTC)[reply]
Playing around with the insource: search code above, it looks like this might affect something on the order of 1% of articles (~70K articles). If we assume (for nice round numbers) an average of 10 edits per article, that suggests that it might tag one edit per day. Would 1–10 edits per day be worth flagging? Is anyone here committing to watching for and fixing the flagged edits? WhatamIdoing (talk) 17:53, 2 September 2025 (UTC)[reply]
This is definitely something I would watch for. I already use {{ill}} quite a bit in normal copy-editing when I come across underlinked articles or articles with existing non-enwiki links. Wrackingtalk!20:29, 2 September 2025 (UTC)[reply]
If an article change on my watchlist was flagged, I'd likely check it out. I'm not sure I'd going hunting them down in other articles. older ≠ wiser10:19, 3 September 2025 (UTC)[reply]
Opppose, looks like we have enough guidance already, and to physically block with edit filters is overkill. I'd rather see a bot that converts bare links to {{ill}} as a solution. -- GreenC18:22, 2 September 2025 (UTC)[reply]
Would you be OK with the an edit filter for the purposes of warning (to let the editor know, or at least remind them, of the template method of linking in article-space) or tagging the edit? —Locke Cole • t • c18:33, 2 September 2025 (UTC)[reply]
Oppose Mostly a non-problem; such links are very rare. They appear in a different color from en links, which mitigates the astonishment problem. No need to add more rules to ban a rare but occasionally useful tool. --Trovatore (talk) 18:46, 2 September 2025 (UTC)[reply]
I think this may be due to a skin. Non-enwiki links appear normal blue to me, so opening them and landing on a non-English page is astonishing. Wrackingtalk!20:10, 2 September 2025 (UTC)[reply]
Hmm. I use Monobook with a couple of customizations, but I don't think either of them affects this behavior. Maybe we could make the different color the default? --Trovatore (talk) 20:48, 2 September 2025 (UTC)[reply]
Comment on {{ill}}. I wasn't really familiar with this template, but I just looked it up, and to be honest I'm not convinced it's a good solution. Apparently it auto-converts the link to an en.wiki link when an article of that title is created. The problem I see with that is that there's no way of predicting in advance what the en.wiki article will be about. If, say, the title is a false friend, or just a different meaning, then all of a sudden you have a link that goes to an inappropriate article, and there's no human intervention to notice it. In general I think foreign-language links are not such a bad thing as some people seem to think. We should give readers credit for being able to deal with seeing stuff they can't read. It's not like they'll be in a situation they don't know how to deal with. Either they can read it, or they can't read it but they know they can't. In the latter case, they either try to find some way of understanding it, or they understand that this link is not useful to them, and no big deal. --Trovatore (talk) 18:54, 2 September 2025 (UTC)[reply]
I am a frequent user of {{ill}} and I love it. Indeed it requires some care to prevent wrong links, but so does just wikilinking a word in the article. The invisible automatic changing to an enwiki link is followed up by a bot edit that will show up on the watchlist.
The main downsides of direct interwiki links are that they are almost the same colour as enwiki links so there is no warning where you'll end up (I fix this in my user CSS by adding underlines), and that the links do not turn from red to blue when a suitable enwiki article is created, so they tend to stay in articles despite better targets being available. —Kusma (talk) 20:07, 2 September 2025 (UTC)[reply]
It really seems like this is more a problem with the default skin than it is a problem with direct interlang links. Could we get in a request to make them more distinct in the next update? --Trovatore (talk) 20:58, 2 September 2025 (UTC)[reply]
I don't know what interwiki links look like in the default skin (I use Monobook). Changing the link colour won't make people notice when an article matching the foreign one has been created though. —Kusma (talk) 21:09, 2 September 2025 (UTC)[reply]
I also use monobook and it comes out in light blue, whereas en.wiki links come out in dark blue.
True about the article-creation issue, but again, I don't see the foreign links as so bad, so this doesn't seem like a deal-breaker to me. The link can be upgraded in the normal review process. On the other hand links to the wrong article are bad; those are actual errors, not just a missed opportunity to link an article in English. --Trovatore (talk) 22:05, 2 September 2025 (UTC)[reply]
Depending on lighting conditions, I don't see the difference between the two shades of blue without effort. The"wrong link" issue you mention is something that can happen with every red link on Wikipedia and is not related to interlanguage linking. —Kusma (talk) 22:27, 2 September 2025 (UTC)[reply]
(edit conflict) There's already T333577, which is likely to continue being ignored. As for colors, looks like the default colors for unvisited links are
The problem I see with [auto-conversion of ill's by the bot] is that there's no way of predicting in advance what the en.wiki article will be about... all of a sudden you have a link that goes to an inappropriate article
You say you weren't familiar with the template, so as someone who has added hundreds of interlanguage links and seen many thousands more, I can say that this has not been a problem, or at least, no worse than people adding direct wikilinks to the wrong article. Both occur (rarely); both are annoyances; neither is a valid reason to deprecate ill's or autoconvert wikilinks. If there is a real problem with interlanguage links, it is that since by definition the English article does not exist yet, the ill creator has to invent an English title for the red link, and it can happen that two people each create an ill about the same thing with two different red link titles for the future English article. That does happen sometimes, but it is more of an inconvenience than a problem, analogous to two editors creating direct red links to the same topic and calling it two different things. If and when an English article is eventually created from one of the two ill red links, it usually gets shaken out eventually, either by the other one getting fixed, or becoming a redirect, and then eventually Cewbot comes along and culls it. So, you needn't worry too much about this case, as it is not a serious problem, and we needn't consider it as part of this Rfc. Mathglot (talk) 23:10, 7 September 2025 (UTC)[reply]
Comment - So if this is enforced by an abuse filter, will and/or how will this affect edit summaries that use those links? Usually for translation attribution these links are needed, so if this is disallowed how will this be done? The {{Ill}} template does not work in edit summaries (or any template I'm pretty sure). This could also very well be fixed in the abuse filter itself and I just don't know it, but I'm curious regardless. Sophisticatedevening(talk)19:36, 2 September 2025 (UTC)[reply]
Oppose – This is basically a 'best practices' issue, but forbidding one practice is not the best way to encourage a better one. I share your concerns upon clicking a blue link that takes you unexpectedly to nl-wiki—I don't like that, either. I am also a huge supporter of {{interlanguage link}}, so we see eye-to-eye there as well. Nevertheless, I must oppose your proposal; it is not necessary, the remedies are draconian, and there are better ways to deal with this. Additionally, you haven't considered some of the possible reasons for keeping them around, or alternative remedies. I also oppose it on the grounds of instruction creep; existing guidelines suffice for this. The fact is, that interlanguage links are part of Wikipedia, and there are legitimate uses of them. You did not mention their use in citations, for example. There are other situations where they might be useful, for example when the link is called out in running text as a foreign link and therefore the ASTONISHMENT goes away; e.g., at Kemperplatz#Sources or any of these articles.[slow link] Presumably you would make an exception for those, and there may be other cases like that as well. As has been said, many users of direct interlanguage links may be unaware that template {{ill}} exists, and forbidding use of the former is not the best way to promote the use of the template; that should be achieved with the carrot, not the stick. Some here have mentioned difficulty in using the {{ill}} template, and to the extent possible, that should be handled by improving the template doc. One positive step that could be taken that I have not seen mentioned thus far, is to trap new interlanguage links as they are typed and pop up a dialog box, similar to the disambig popup dialog that appears in edit mode when you type a link that is a disambig page. A solution like that would probably go a long way to minimizing growth of this problem, and WP:AWB could find and assist in repair of such links. Forbidding them is overkill, and not necessary. Mathglot (talk) 22:49, 2 September 2025 (UTC)[reply]
I don't want to click on your expensive link, but I'm curious about how many articles were found in that search.
Could we do a bot run to tag the links (skipping anything inside a template or otherwise feeling like it might break something)? It wouldn't necessarily have to be visible, but if we could get a group together to sort through these, like Wikipedia:WikiProject Disambiguation handles dab links, then we might be able to solve the problem. WhatamIdoing (talk) 00:35, 3 September 2025 (UTC)[reply]
There were 144 results but it is a lower bound, and probably only a small minority of the total, as I was looking for a particular pattern likely to yield on-page translation attributions similar to the Kemperplatz case. That said, every little bit helps, I suppose. (P.S., that search can be slow, but I don't believe it counts as expensive, as it includes a double-quoted insource term, which works off an index and is described as "ideal" here. That might be a good question for VPT, though.) Mathglot (talk) 01:07, 3 September 2025 (UTC)[reply]
Then I think it's missing most of the articles, because a simple search on insource:/\[\[\:de\:/ turns up about 20K articles, just for the one language. WhatamIdoing (talk) 01:38, 3 September 2025 (UTC)[reply]
It's only part of Mathglot's argument, but yes, I don't think there are many articles that link to other-language Wikipedia articles qua articles. And many that do should not – Kemperplatz § Sources treats a German Wikipedia article as a source, in violation of WP:CIRCULAR. Such uses should be replaced with {{translated page}} on the talk page and possibly a maintenance tag like {{expand language}} on the article. jlwoodwa (talk) 04:16, 3 September 2025 (UTC)[reply]
No, this discussion is not related to only those ~144 articles; the 20K for dewiki (and other non-enwiki) is what we're talking about. If you click the "slow link", it shows articles that link to non-enwiki articles andself-reference those articles, e.g., The German Wikipedia article [[:de:Konkordienbuch]] (at Book of Concord).
For Spanish, insource:/\[\[\:es\:/ returns 13K results. Not all are especially problematic—I wouldn't consider eswiki links in citation templates to be high-priority, e.g., |publisher = [[:es:Universidad Empresarial Siglo 21|Universidad Empresarial Siglo 21]] (at Jimmy Wales). Here is an example of a cleanup I did at Mexico after finding eswiki links via that search pattern. Wrackingtalk!05:36, 3 September 2025 (UTC)[reply]
Comment. I believe {{ill}} is expensive, and so one use case for other solutions I would bring up is possibly when the sheer number of links rule out using ill? CapnZapp (talk) 11:35, 3 September 2025 (UTC)[reply]
If seeing something written in a foreign language without being warned in advance is astonishing then I don't know what is non-astonishing. Some people must go through their whole lives being astonished. Phil Bridger (talk) 11:59, 3 September 2025 (UTC)[reply]
I don't think anyone here is saying seeing something written in a foreign language is astonishing. What many might find astonishing (or confusing) is to click on a wikilink that looks identical or nearly so to any other ordinary wikilink and being taken to an article in another language (and with the concomitant navigational framework in the other language as well). older ≠ wiser14:43, 3 September 2025 (UTC)[reply]
Comment I see several comments above discussing how to find the problematic links. Here are some possibilities, in approximate order of escalation:
People manually do searches like insource:/\[\[\:es\:/ for every language code.
Someone could re-enable CW Error #68 for enwiki (cf. the report for eswiki), which interested editors could use to find pages to clean up.
A log-only edit filter could be created, and people could use that log to find edits to follow up on.
An edit filter could add a tag to edits, without warning or preventing them. Interested editors could watch for edits with the tag for review.
An edit filter could warn users against adding such links, possibly teaching them about {{ill}}.
An edit filter could prevents edits that would add such links.
Seems like there's not much support for the last, and probably not a whole lot for the second-to-last either. But some arguing against seem to be overlooking the earlier options. Anomie⚔14:06, 3 September 2025 (UTC)[reply]
You missed out the most likely scenario - that people spend far more time than it would take to enact any of those proposals on discussing the "issue" here and end up being too exhausted to do anything about it. Phil Bridger (talk) 14:23, 3 September 2025 (UTC)[reply]
Good list @Anomie. Another possibility is to more clearly differentiate links to other language wikis. Unfortunately, as you've said, T333577 doesn't appear to be going anywhere. But perhaps, to also address concerns about {{ill}} being 'expensive' as well as cases where the link shouldn't change when an English article is created, there might be another template specifically for creating stable links to other language articles with color coding or other visual indicators. Perhaps include mention of the language, such as (German article: Bundestag) somewhat similar to how {{langx}} displays the language label. older ≠ wiser15:13, 3 September 2025 (UTC)[reply]
Having the link show a different color when you happen to read the article doesn't help an editor find articles that have this problem. I like the idea of re-enabling the WP:CHECKWIKI report. It'd probably be a good idea to find a couple of editors who are willing to work on the list before running it frequently. WhatamIdoing (talk) 16:58, 3 September 2025 (UTC)[reply]
Maybe if the color were more distinct it wouldn't be so much of a "problem". I'm still not convinced there's anything wrong with interlang links per se. --Trovatore (talk) 18:59, 3 September 2025 (UTC)[reply]
I'm not sure that any amount of fiddling with the color will work. On the one side, you have people saying "It must be different – really, really different, so it's super obvious that it's weird and different and not normal". When we do that, then other people appear and say "Now it doesn't look like a link! Nobody knows they can click on it. It just looks like someone randomly decided to put {green|purple|orange} text in the middle of an article for no reason at all!" (And most compromises are met with "It's basically unreadable in dark mode".) WhatamIdoing (talk) 19:03, 3 September 2025 (UTC)[reply]
Looking at Anomie's table, I think the Monobook dark contrasted with the Timeless light would work pretty well. Dark mode looks atrocious to me but I don't see that this would be any less readable in dark mode than dark mode is anyway. --Trovatore (talk) 22:00, 3 September 2025 (UTC)[reply]
Again: no amount of fiddling with the colors helps editors who are starting at the Main Page figure out which articles contain potentially unwanted links to non-English Wikipedia articles.
What's wanted – assuming we're trying to fix this problem – is "Here is the list of articles that need {{ill}} added to them". This is not a common enough problem that we can change the color and then tell people to click Special:Random a few hundred times and manually scan the page for the color change. WhatamIdoing (talk) 17:45, 14 September 2025 (UTC)[reply]
Oppose an edit filter (way too blunt), but support codifying {{ill}} as best practice, which is already de facto the case but isn't strongly codified yet. Indeed, guidelines should follow and codify community practices. It still leaves leeway for edge cases or people not knowing the guideline, as it would only mean that regular interlanguage links can be converted to {{ill}} (when reasonable) by later editors. Changing link colors to better distinguish interlanguage links is also a good thing, although such a visible change should probably be a proposal of its own. Chaotic Enby (talk · contribs) 14:08, 7 September 2025 (UTC)[reply]
Oppose all. The English Wikipedia already has a severe lack of information about non-anglophone countries, and any form of this proposal would just make matters worse. James500 (talk) 05:14, 10 September 2025 (UTC)[reply]
Bot to make list-defined references editable with the VisualEditor
Proposal: a bot that replaces {{reflist|refs=...}} with <references>...</references>
Rationale: The reason is that there are issues with the list-defined references that are based on the template {{reflist}}. The VisualEditor can't parse references that are inside templates. This comes from a design decision, it has been like this for over 10 years and developers apparently don't want to change it (see T52896). It means that in the VisualEditor, list-defined references that are within a reflist template can't be modified, and are not displayed (you instead get the message "This reference is defined in a template or other generated block, and for now can only be previewed in source mode"). So when using the VisualEditor, you can't visualize these references and you have to switch to the source editor in order to manipulate these references. However, the parsing works with list-defined references that use the <references> template. Here is an example of an edit that makes the replacement.
One more important benefit I just discovered: references within <references> can also be parsed by Wikipedia's translation tool, unlike those inside reflist. Which means that list-defined references within <references> are not removed by Wikipedia's article translation tool, and are instead properly converted to the corresponding reference format in the target language.
Technical details: This proposal is not about replacing all instances of {{reflist}}, only some of those that have the parameter "refs", which represents more than 55,000 articles. Replacing {{reflist|refs=...}} with <references>...</references> does not affect the rendering of the references (outside the VisualEditor) if the reflist only has a parameter |refs=. The reflist template can have some other parameters, like |colwidth=. One possibility is to apply the change if |refs= is one and the only parameter in the reflist template. This is safer and should still cover most instances of the problem. Another possibility would be to have a more sophisticated bot that can handle reflists with the parameter |refs= and some other additional parameters, which would allow for more replacements.
Previous discussions:
There was a long discussion in Wikipedia talk:Citing sources on this a few months ago. The discussion was initially about deprecating list-defined references (which didn't get consensus), and then switched to replacing {{reflist|refs=...}} with <references>, here of one of the paragraphs of the closing comment:
"There was 2:1 support in favor of deprecating {{reflist|refs=}} and replacing existing instances. I updated the linked documentation pages to do so. Someone will need to write a bot and follow the procedure at Wikipedia:Bots/Requests for approval. At least one editor had concerns about bots making incorrect edits. There was also discussion of whether or not such changes should be bot-flagged so they don't show up on watchlists, and whether it should be required that other changes be made at the same time. The bot approval process is designed to take these concerns into account and balance them against the proposed benefits; that would be the place to raise them. (It might be helpful if whoever makes the requests notifies the editors who participated in this discussion.)"
Support. This maintains list-defined references in that article while solving other problems. I think that this discussion is overkill, but BOTREQ frequently wants to make double-extra-certain that a bot task won't need to be reverted later. WhatamIdoing (talk) 22:16, 3 September 2025 (UTC)[reply]
For clarity: This will affect less than 1% of articles, and it will change this:
I have two questions: (a) Is the rendered result is perfectly identical what's being replaced? (b) Will it interfere with anything else contained in {{reflist|refs=}}? I employ HTML comments amongst list-defined sources for myself and others and want to be sure any bot changes won't strip or modify them. Thanks, all. — Fourthords | =Λ= |23:01, 3 September 2025 (UTC)[reply]
(a) Yes, it's exactly the same. AIUI the reflist template is just calling the <references>...</references> tags. (b) It shouldn't touch anything else except the exact characters planned to be replaced. (Why would it?) WhatamIdoing (talk) 23:12, 3 September 2025 (UTC)[reply]
Comment. If we are going to do something like this with the rationale that we cannot have refs inside templates, then we should more consistently examine contexts where refs are inside templates and eliminate all of them rather than piecemeal gutting our useful templates. Other templates that often have refs inside them include all of our infoboxes, {{efn}}, {{blockquote}}, and {{block indent}}. Should we perhaps discuss substing all of those? If not, why should this one context be treated exceptionally from others? —David Eppstein (talk) 23:17, 3 September 2025 (UTC)[reply]
In {{efn}}, {{blockquote}}, and {{block indent}} you generally have a text field in which you can see and edit the source code of references. It may not be ideal, but unlike for list-defined references, I don't see good alternatives and at least you don't need to switch to source editor. Alenoach (talk) 23:42, 3 September 2025 (UTC)[reply]
{{reflist}} has a field in which the source code of references appears. If VE is able to edit the source code of references in {{efn}} but not {{reflist}}, then the whole premise of this RfC (that VE is unable to edit refs in templates) would appear to be false. Are you suggesting that merely changing the type of the "refs" parameter of {{reflist}}, in the template parameter block of {{reflist/doc}}, from "String" to "Content", would allow VE to see and edit the source code of references in reflists? —David Eppstein (talk) 00:43, 4 September 2025 (UTC)[reply]
It might be able to see and edit them, but it still won't parse them so they won't show up on the "Re-use" tab when you insert a reference. --Ahecht (TALK PAGE)00:54, 4 September 2025 (UTC)[reply]
Does when I try it. Note there needs to be more than 10 references and your browser window needs to be wide enough. It also looks like Vector 2022's default settings (Medium text and "Standard" width) don't meet the "wide enough" criterion; I have to switch to Small text or "Wide" width to get it to wrap. Anomie⚔23:57, 3 September 2025 (UTC)[reply]
Hmm. Looks like the font size of the references themselves winds up the same with both {{reflist}} and <references />, but that's achieved with different CSS. The difference means that {{reflist}} applies the column-width of 30em based on the reduced font size, while <references /> applies the same 30em with the unreduced font size. Looks like T334941 exists already, although there they don't seem to have found this difference. Anomie⚔11:47, 4 September 2025 (UTC)[reply]
Is it possible to get tag-references to be responsive to more dense columns? I've found 30em far too wide in cases where short references are used. Ifly6 (talk) 00:25, 7 September 2025 (UTC)[reply]
Yeah, looks like the {{reflist}}30em is equivalent to telling .mw-references-columns to wrap on 27em because of that font-size:90% that reflist does.
On testing, even just knocking the default column width for <references/> down to 29em is enough to get us columns in Vector 2022 at standard width with the sidebars shown. Though obviously going a bit narrower makes it more likely that people with windows less-wide than the full "standard" width would still get the columns... DLynch (WMF) (talk) 01:46, 7 September 2025 (UTC)[reply]
Different order. reflist sets it on the wrapper-div that it creates, while core-references sets it on the ol that's inside the other wrapper that core uses for responsive columns. They both wind up reducing the font size that the actual references display at, but one affects the column widths and the other doesn't.
I would be fine with deprecation if the tag were sufficiently responsive for shortened footnotes. Most of the time it just picks the equivalent of |colwidth=30em when the output would save a lot of whitespace if it picked |colwidth=20em (or even |colwidth=15em) instead. Ifly6 (talk) 05:35, 5 September 2025 (UTC)[reply]
I have no idea. Replacing {{reflist}} with the references tag universally entirely would, I am under the impression, break three-column reference list formats. Ifly6 (talk) 20:25, 6 September 2025 (UTC)[reply]
Since this appears to be where the columns issue is actually discussed I'll repeat what I say below: I just implemented the {{refwidth}} thing I mentioned in the last discussion. It currently has three presets that correspond to 20em, 24em, and 27em respectively. An example of this in action is at User:Aaron Liu/sandbox#References.I had the idea after @Rjjiii also mentioned this concern in the previous discussion. For some reason I didn't see their reply, so I'll address it here: The refbegin thing is irrelevant as that isn't list-defined references. LDRs are defined in reference lists—the ones that are usually numbered and list uses of <ref></ref>—and the example based on the OSS page does not use them. See Help:List-defined references. Aaron Liu (talk) 20:40, 6 September 2025 (UTC)[reply]
Support: Although @David Eppstein is correct this doesn't solve every problem, that doesn't mean it doesn't solve a problem, and a pretty major one at that. This is a problem I run into often with the visual editor; I usually just have to change the reference format to move them out of refs to effectively edit the article. This would solve that, and only a modest # of articles would be affected, so I support it. Mrfoogles (talk) 00:01, 4 September 2025 (UTC)[reply]
Oppose. VE is broken and we should not extend the damage to the rest of Wikipedia by making our templates broken and clogging up our watchlists with bot edits as well. —David Eppstein (talk) 00:44, 4 September 2025 (UTC)[reply]
This it not completely specific to VE though: Wikipedia's translation tool somehow has a similar issue where it can't parse refs inside "reflist" and will just remove them. Alenoach (talk) 01:02, 4 September 2025 (UTC)[reply]
"VE is broken" doesn't really capture the issue here. The built-in MediaWiki references tag is how we used to do things, and the {{reflist}} wrapper is a hack workaround for a now-irrelevant issue. Templated wikitext is almost inherently impossible to parse, so mishandling of an expensive template is not a bug in VE but an inherent part of wikitext. Deprecating a redundant and useless wrapper for a built-in MediaWiki function is useful cleanup, even if VE handled it fine. Dan Leonard (talk • contribs)02:19, 4 September 2025 (UTC)[reply]
Support I'm of the opinion that we should deprecate {{reflist}} altogether for all instances where we're not using |group=, since that's the only thing where the bare tag doesn't have feature parity yet. Yes, the template allows you to specify a fixed column width, but we shouldn't be doing that anyway as the default responsive option is a more flexible and modern approach. Most of the other uses of reflist date back a decade or more to when the raw tag was much less capable. This is a good first step, and would be 55,000 more articles where editors can see an example of using the raw tag instead of the pointless wrapper. --Ahecht (TALK PAGE)00:47, 4 September 2025 (UTC)[reply]
@Dan Leonard{{reflist|group=lower-alpha}} actually formats the reference numbers as lowercase letters, but to do that with bare tags you need to do <divclass="reflist-lower-alpha"><referencesgroup="lower-alpha"/></div>. --Ahecht (TALK PAGE)18:06, 8 September 2025 (UTC)[reply]
This is something that's going to (sort of) solve itself as parsoid rendering rolls out, because parsoid is going to expose data-mw-group="lower-alpha" on the <ol>. Then wikis will be able to add their own site CSS on that attribute if they want. DLynch (WMF) (talk) 21:27, 8 September 2025 (UTC)[reply]
There are other problems with {{reflist}} than just VE compatibility, such as hiding all references if the page exceeds the WP:PEIS limit (the bare tag isn't affected by template limits, although some individual references may not render if they use a CS1 template after the limit is reached). --Ahecht (TALK PAGE)00:57, 4 September 2025 (UTC)[reply]
Support per above. Note that this proposal is only about replacing instances that define new references within the template and not all invocations of it (and even then, the fixed column width feature can be implemented through a separate templatestyles template that selects from one out of three widths). This template is being singled out among the templates that define refs because it's the most common one that would break the new subreferencing feature and changing invocations should not be very intrusive. Aaron Liu (talk) 01:39, 4 September 2025 (UTC)[reply]
Support. Seems like a sensible idea. I would strongly prefer that whatever tool or bot is used to do this should not make these edits in isolation, to avoid clogging watchlists. If this can be turned into something that's done as part of other edits, at least until the number of remaining articles to modify is much smaller, that would be best. Re the "fix VE" argument; sure, if that looked likely, but it doesn't, and there are more new VE users every day. There's no reason to make their lives harder for the sake of a principle. Mike Christie (talk - contribs - library) 02:16, 4 September 2025 (UTC)[reply]
Support deprecating {{reflist}} altogether except for instances where specific functions unique to the template are required for some reason. A lot of people, in this discussion and many others involving VisualEditor, love to use the refrain "our practices are fine, VisualEditor is broken". Even this proposal seems to think this is the VisualEditor team being lazy with this comes from a design decision, it has been like this for over 10 years and developers apparently don't want to change it. While the editor might have some bugs (the :0 ref naming scheme comes to mind), sometimes its limitations demonstrate an issue with our practices. Wikitext is essentially an unparsable language,[1][2][3] so it's almost inconceivably difficult for any WYSIWYG editor to handle the complexity of parsing <ref> calls hidden inside of a template call that is filled with conditional expressions. Not to mention how to handle that for a multilingual project where hundreds of language editions and sister projects have copied or adapted a similar wrapper. Sometimes, it's a good idea to deprecate templates that just wrap simpler basic wikitext functions. The community has shown distaste for templates that exist only to wrap basic wikitext syntax like boldface (Wikipedia:Templates for discussion/Log/2012 April 13 § Template:Bold) or italics (§ Template:Italic) and would certainly benefit from limiting use of a template that in 99% of cases just directly calls <references>. The bare Cite extension tag was how we used to use references, and {{reflist}} was only invented to wrap the tag in a <div> with columns. That became redundant in 2017 when the Cite extension got responsive design. Since then, there's almost never been a use for the template and its eleven-year reign should have ended. Instead it lives on as a zombie, mentioned in too many documentation pages and the muscle-memory of editors. As I mentioned at Wikipedia talk:Citing sources/Archive 58 § Sister projects have managed this, the Polish Wikipedia got rid of their wrapper template via a bot, and it has worked well for them. The VisualEditor is how people are learning to edit, for better or for worse, and it is crucial for this project's survival to meet our new editors with collegiality and help them productively edit the encyclopedia. Dan Leonard (talk • contribs)04:05, 4 September 2025 (UTC)[reply]
Italian Wikipedia also did a bot run to replace their {{reflist}} version [43] once there was no more need for it due to the introduction of <references responsive> in mw:Contributors (2015-2021)/Projects/Columns for references. My team (WMDE Technical Wishes) did an investigation last year (phab:T377043) to check which features of {{reflist}} equivalents across major wikis are still missing for <references>. Our main take away is basically that nowadays most features (except fore some rarely used ones and some right-to-left language specific features) are already part of <references> which many community members might not know. Johannes Richter (WMDE) (talk) 08:53, 4 September 2025 (UTC)[reply]
Thanks for the clarification! I would also support deprecating reflist, given your explanations. There could be a spin-off voting on this particular question to see if there is a sufficiently large consensus. But since it's less surgical, I expect that getting consensus would be harder. Alenoach (talk) 22:46, 5 September 2025 (UTC)[reply]
Comment, reposted from the Bot requests discussion: The monthly parameter usage report for Template:Reflist suggests that there are 183,000 articles using |refs=. It seems like any sort of replacement would need to start with a well-advertised RFC that successfully deprecated |refs=. This proposal (not an RFC) appears to be deprecating that parameter de facto, possibly without stating it explicitly. Maybe I missed it. – Jonesey95 (talk) 05:02, 4 September 2025 (UTC)[reply]
If this bot gets approval, I would just take it as given that the parameter should be deprecated, and then removed once all the substitutions are done. Otherwise we'll have to do ongoing work to remove instances that use it. This discussion is pretty visible, RFC or no. -- Beland (talk) 05:18, 4 September 2025 (UTC)[reply]
Suppport as proposed. I don't think it's a good idea to try to add unrelated tasks into the same bot, as Mike Christie has proposed. If the edits need to be rolled back due to malfunction, that will undo other useful edits, and the more tasks the higher the chances of malfunction. It would also delay and complicate the bot approval process unnecessarily. Part of the point of having a bot flag is so people can filter them out of their watchlists, to address complaints about cluttering those. So many bots are already running and making small changes, not to mention editors making small changes, the incremental annoyance caused by this run is pretty much negligible, especially considering what a tiny percentage of articles (0.78%) are affected. Also, long-term ease of use and its effect on editor retention are more important than avoiding a small one-time annoyance. I support letting the bot handle any additional parameters if they are present in, say, 100+ articles. My bias would be toward removing any customizations and going with the default rendering. For any low-frequency parameters we can review those articles manually and make sure the customizations aren't needed. I'd be happy to help with that. -- Beland (talk) 05:13, 4 September 2025 (UTC)[reply]
Supportprovided that no changes are made if {{reflist}} is invoked with |colwidth=. (Unless something is done to make <references> automatically select whatever column format that minimises its vertical space in 2022 Vector or something like that.) Ifly6 (talk) 05:18, 4 September 2025 (UTC)[reply]
I think it's better for Reflist to always be replaced as long as the |ref= parameter is present. On column widths, I just implemented the {{refwidth}} thing I mentioned in the last discussion. It currently has three presets that correspond to 20em, 24em, and 27em respectively. An example of this in action is at User:Aaron Liu/sandbox#References. Aaron Liu (talk) 15:50, 6 September 2025 (UTC)[reply]
I guess you mean specifying an arbitrary column size like |14em. To my knowledge, no, unless we implement inline styles for the <references> tag. Aaron Liu (talk) 20:55, 6 September 2025 (UTC)[reply]
Support limited to where |refs= is the only parameter in the reflist template. Like Mike Christie, I see no reason to hope for WMF improvement of this VisualEditor fault after a decade of inaction. ViridianPenguin🐧 (💬) 06:23, 4 September 2025 (UTC)[reply]
Support per above, and also support combining this work other task, if possible. A large portion of editors regularly use VE, especially new editors. This will help a lot IMO. ~/Bunnypranav:<ping>09:48, 4 September 2025 (UTC)[reply]
Support (weak). Many newer editors would benefit, and they are likely unaware of this discussion and the technical issue. This change would allow VE editors to see, reuse, and modify list-defined references. VE still would not support removing list-defined references. Also, the {{reflist}} template likely would never have been made for the current version of the "references" tag. Rjjiii (talk) 03:30, 5 September 2025 (UTC)[reply]
For what it's worth, this change happening would make it significantly more likely that we'd put time into fixing things like removing a list-defined reference. It's been low-priority because we knew that a large number of places that use list-defined references wouldn't be affected, but... DLynch (WMF) (talk) 20:48, 5 September 2025 (UTC)[reply]
This is tracked by issue T356471. I have pinged a developer to try to get some attention to it. I expect that fixing the bug for ref removal shouldn't be particularly hard, but they need to prioritize it. Alenoach (talk) 21:13, 5 September 2025 (UTC)[reply]
Support per Alenoach and Dan Leonard. Compelling proposal. It seems like ideally we should get rid of {{reflist}} altogether in favour of the native syntax, but this proposal is a good first step. – SD0001 (talk) 14:08, 5 September 2025 (UTC)[reply]
Support{{reflist}} being so widespread has been a major factor in us not investing time in improving VE's support for list-defined references in general. Ideally it'd be nice to remove the template altogether, because we'd still be left with needing a complex edit when someone wants to add the very first list-defined reference to an article in VE. It also won't help with one of our most common cases of uneditable template-defined references, which is those defined inside infobox parameters, but it'd be a step towards a simpler future. DLynch (WMF) (talk) 20:57, 5 September 2025 (UTC)[reply]
(I'd specifically throw a +1 behind all of Dan Leonard's comments above, which seem spot on to me about the general difficulties of dealing with wikitext-in-template-parameters.) DLynch (WMF) (talk) 21:20, 5 September 2025 (UTC)[reply]
Support. Making it possible to edit something is always a worthwhile goal, and worth the "downside" of bot spam. (A bot is not just improving a few articles, it is improving lots of articles!) And to be clear, the |refs= parameter should be eliminated so we don't end up in this situation again. I'd even go so far as to say {{reflist}} should be a subst-only template. My complaints about {{reflist}} can be saved for another day, but for now let's solve one problem at a time. HouseBlaster (talk • he/they)22:05, 7 September 2025 (UTC)[reply]
Oppose. Fix the actual problem where it lies, don't ask someone else to put up with a workaround.
*: [WMF, stage left] — Oh, Wikipedia, dear! We have this great VE tool, but we fucked up; it doesn't play nice with LDRs. Can you pretty please change the way you have always done it with {{Reflist}}, and pull our ass out of the fire on this one? Would really appreciate it; ta very much! *: [Wikipedia] — grumble... er, well, I dunno; sometimes I think I'm just too accommodating. All right, I guess... Just this once, then. *: [WMF exits stage right, smiling slightly] *: [later...] [Wikipedia] — Oh, WMF, there you are! You know, I really hate to pester you about this all the time, but there's this little thing about VE making inscrutable numeric citation names like <ref name=":17"> instead of something mnemonic like, say, <ref name="Einstein-1905">. I know it's been barely ten years since we first mentioned it, but, um, do you think... *: [WMF] — [coughs] Er, actually, I've been meaning to talk to yo about that, but I'm late, I'm late, for a very important date... [scurries off, stage right]
I've been editing for about 20 years and have created over a thousand articles. And I like list-defined references and have been using them since I discovered them comparatively recently. But the technical basics still seem obscure and unclear. What I'm still not fully understanding is the difference between:
Having the same keyword interpreted in different ways depending on the position of a slash seems quite arcane. And I'm not aware of any way of adding the latter pair using the Visual Editor. There still seems to be a long way to go to make this simple and easy for newbies.
In 20 years of editing Wikipedia, I have never used or even noticed <cite> and am not familiar with what it might do. So, I don't understand it at all. But I guess that it's a raw markup tag which is commonly buried in templates such as {{citation}} or {{cite book}}. I suppose that you have to be a real old-timer to have been exposed to Wikipedia's fundamental primitives.
More generally, I've not done much html or xml raw coding and so the slash syntax is not familiar. But now I check on it, it appears that closing slashes are somewhat deprecated in HTML5 in void tags, especially self-closing tags.
Editors writing articles shouldn't have to understand such technical tag issues. The problem in making life simple for them is that there are far too many ways of citing references – each with their own arcane and complex syntax. This violates the KISS principle.
I see. Well, I've used those various forms of <ref> but didn't understand that there was a general pattern to the syntax – I just copied what worked elsewhere. And with list-defined references, I've been using the {{r}} template rather than <ref> so that the inline citations are succinct. For example, rather than <ref name=BBC/><ref name=NYT/>, I put {{r|BBC|NYT}}.
As others have said, this is just regular HTML tag syntax that's already used similarly in a bunch of places. If you want, you could think of it as the difference between reflist and refbegin/refend.
The latter would just mean having a way to create list-defined references inside VE, since that's the only reason to have the open/close tags, so there's room to put something inside it -- and which is used is basically an implementation detail that VE should be able to switch between automatically depending on whether there's anything inside the tag.
This would be technically trivial, but there's UX complexities around asking a user whether the reference should live inside the list -- it's not a question that really makes sense to someone who's not editing the source, after all. We should probably work out what the community of a given wiki thinks is the "correct" place for references to live, and default to doing that. DLynch (WMF) (talk) 14:22, 8 September 2025 (UTC)[reply]
The correct place for references is where they appear in the article – down at the bottom in a section called References. Full inline references are nightmarish in the source code and that's why I quickly switched to using list-defined references when I discovered them. The short footnote ({{sfn}}) found in many featured articles is similar – listing the main sources in a section called Sources and then using short tags to cite them in the text.
But getting the community to agree on a simple uniform scheme won't happen easily because of WP:CITEVAR and the hard-core vested interests. The Visual Editor should focus on one good scheme and encourage that so that the new generation of editors grows up with a more uniform standard.
While some do find reading source code tricky, that isn't really an issue for visual editor editors. The big stumbling block for list-defined references is likely that such a reference system usually requires two edits instead of one, something visual editor also might be able to smooth out if it had some way to automatically shift the reference as part of the edit saving. CMD (talk) 16:14, 8 September 2025 (UTC)[reply]
VE already does some amount of automatic shifting-around, in the form of making sure that the definition of a reused inline ref is always attached to its first usage in the article. Attaching some similar behavior to add to attach the definition into the reference list wouldn't be a stretch. DLynch (WMF) (talk) 22:04, 8 September 2025 (UTC)[reply]
List-defined references are a minority on the site; I find it easier to have single-use references inline in the text so that nothing gets out of sync if they are removed or replaced. -- Beland (talk) 21:46, 8 September 2025 (UTC)[reply]
I'm personally a fan of list-defined references, particularly for anything that's being reused. If I was making completely arbitrary changes to the wikis to enforce my own aesthetic preferences, I'd probably make it so that <ref name="foo">only worked to reuse a list-defined reference. Alas, I'm not getting consensus on that one. ;-P
More-seriously, I think that VE has been working as it has for so long that suddenly switching the default behavior would require some thought. A starting point of working out an acceptable heuristic for VE that'd make it go with the flow to match whatever style is in use in an article, rather than always doing inline refs would probably not be too controversial, though. DLynch (WMF) (talk) 22:01, 8 September 2025 (UTC)[reply]
Support. This is a really minor change that would produce major benefits with no downsides. The opposition seems to consist of polemics against VE and misunderstandings of the technical purpose of the template being replaced. Toadspike[Talk]00:47, 10 September 2025 (UTC)[reply]
Support - I'd prefer if VE would fix their own bugs, but as the devs have been pretty consistent for a decade about not supporting use cases that they don't like and there isn't a visual difference, we might as well. Several hundred of those 55000 articles are from me, and I guess I'd rather have the page more fully work in VE then keep html syntax out of the wikicode. --PresN14:57, 10 September 2025 (UTC)[reply]
Support. Yes, VE is much better than it was 10 years ago, but it still has some bugs when it comes to things embedded in other templates. Since the developers aren't fixing the LDR issue, this should be a workaround. Not an ideal workaround, of course, but one that should be effective. Plus, there is already consensus to deprecate the |refs= parameter in {{reflist}}. Epicgenius (talk) 13:17, 17 September 2025 (UTC)[reply]
^Siebenmann, Chris (2011-11-12). "(Not) parsing wikitext". Wandering Thoughts. University of Toronto. Archived from the original on 2025-05-03. I don't know how to write a formal parser for it, something based on parsing theory in order to have all of the advantages of real parsers ... unlike a traditional language, wikitext doesn't have any errors
^Dohrn, Hannes; Riehle, Dirk (2011). "Design and implementation of the Sweble Wikitext parser: Unlocking the structured data of Wikipedia". Proceedings of the 7th International Symposium on Wikis and Open Collaboration. WikiSym '11. Mountain View, California. p. 73. doi:10.1145/2038558.2038571. ISBN978-1-4503-0909-7. Moreover, the generated HTML can be invalid. The complexity of the software also prohibits the further development of the parser and maintenance has become difficult. Many have tried to implement a parser for Wikitext to obtain a machine-accessible representation of the information inside an article. However, we don't know about a project that succeeded so far. The main reason we see for this is the complexity of the Wikitext grammar, which does not fall in any of the well-understood categories LALR(1) or LL(k).
^Wicke, Gabriel (2013-03-04). "Parsoid: How Wikipedia catches up with the web". Diff. Wikimedia Foundation. Archived from the original on 2025-08-13. There is no guarantee that the expansion of a template will parse to a self-contained DOM structure. In fact, there are many templates that only produce a table start tag (<table>), a table row (<tr>...</tr>) or a table end tag (</table>). They can even only produce the first half of an HTML tag or Wikitext element (e.g. ...</tabl), which is practically impossible to represent in HTML.
Match icons with Wikipedia skin (Vector 2010, Monobook)
For people using the Vector Legacy or MonoBook skins, there are quite obvious design inconsistencies between the rest of the skin and the new "flat" icons. In addition, many of these new icons were not designed for the scale of old Wikipedia skins and can look blurry.
The old icons are still hosted on Wikimedia.org at their old URLs; I propose that we match the old icons to these old skins one of these ways:
1) Check for and redirect users of a legacy (V2010, MonoBook) skin to the older icon URLs, or
2) Rehost the old icons under a new schema: wikipedia/en/ is already used for new icons, so have wikipedia/en/legacy for the older icons. Have the icon refs point to that directory instead for users of older skins. OmegaAOL (talk) 04:05, 5 September 2025 (UTC)[reply]
As a user of Vector 2010, I don't necessarily agree with this proposal. A lot of the reasons for using Vector 2010, such as the page layout, are independent of (or even despite) the skin's older style, and some users like myself do prefer the more modern look of flat icons. An alternate option would be to make the choice of icons separate from the choice of skin, which would suit both the users preferring V10 with flat icons and those preferring the old icons. Chaotic Enby (talk · contribs) 20:01, 8 September 2025 (UTC)[reply]
Change editnotice appearance for mobile contributors
Hi all. I've started editing on my phone recently, and I've experienced the annoyance of editnotices for editors on mobile devices:
They're disproportionate to the rest of the UI and imposing
Their icons cause the text to stack to sometimes a screen's length high
So I propose improving their appearance for mobile editors with responsive web design, particularly since mobile devices constitute more than 40% of all Wikipedia readers, and growing.
The proposed changes' visual effects can be seen in the before and after screenshots below, additions to the CSS can also be seen below, and the actual changes viewed on Template:Editnotice/testcases on your desktop and mobile device by enabling the mobile sidebar gadget in your preferences (or use Chrome DevTools to simulate it on your device); it can also be perused in its entirety with the Template:Fmbox CSS at Template:Editnotice/styles.css too. My changes also include updating the colors used from static Hex to global variables, so that they automatically change with dark mode.
Instead of making the table cells in the Editnotice display: block; which is a 'quick fix', it would be wiser to convert the HTML <table> layout used in Template:Fmbox (as well as all the other mboxes) to use <div> instead, then use flexboxes (display: flex;) to get the horizontal and vertical layouts as the layout would be more responsive.
Edit notice before adaptive CSS on iPhone 380px ✕ 844px.
Edit notice after adaptive CSS on iPhone 380px ✕ 844px.
@mediascreenand(max-width:639px){/* Target smartphones */.fmbox.mbox-image,/* Stack icon and text vertically */.fmbox.mbox-text,/* Make the font size normal */.fmbox.mbox-imageright,.fmbox.editnotice-header,.fmbox.editnotice-headerspan{display:block;font-size:100%!important;width:90%;}.fmbox.mbox-imageimg.mw-file-element,.fmbox.mbox-imagerightimg.mw-file-element{height:auto;width:auto;max-height:40px;text-align:center;}}@mediascreenand(max-width:300px){/* Target tiny screens */.fmbox.mbox-image{/* Hide the icon */display:none;}}
Instead of making the table cells in the Editnotice display: block; which is a 'quick fix', it would be wiser to convert the HTML <table> layout used in Template:Fmbox (as well as all the other mboxes) to use <div> instead, then use flexboxes (display: flex;) - agree, and IMO this should be done to all other message boxes too. Sapphaline (talk) 14:58, 6 September 2025 (UTC)[reply]
@Gnomingstuff: I hear you, and I agree that editnotices are important tools. The tricky part is weighing up the cost vs. benefit. Large, heavy editnotices might reduce vandalism, but they also risk discouraging good-faith editors (lowering editor retention) — and at some point the effect on vandalism bottoms out anyway. I don't think bumping the text size or icon slightly really changes that dynamic, since the notice still takes up a lot of space. We could always experiment with making the icon a bit larger (say 60×60px or more) and nudging the text size to 105%.
Your example I must disagree with though as it's a false argument, showing one example as the status quo is a hasty generalization and false equivalence. waddie96 ★ (talk)22:26, 6 September 2025 (UTC)[reply]
@Waddie96, I wonder if you could produce a mockup image that would help people understand what you're talking about. I doubt that anybody looks at the above screenshot and thinks "You know what's really great about edit notices? Having 25% of the screen be empty white space, with a blue dot most of the way down the screen, and all my important written instructions getting smushed over to the side in small text".
I don't understand this opposition. THEYCANTHEARYOU describes situations where editors can't see or understand things like editnotices. This proposal intends to repair serious HTML accessibility issues present in editnotices, thereby making them more readable to editors who might otherwise not understand them. Dan Leonard (talk • contribs)01:16, 8 September 2025 (UTC)[reply]
The original proposal took issue with edit notices being disproportionate to the rest of the UI and imposing. That's the entire point.
The upstream systems that care about message boxes only care about ambox, hence why Module:Message box/div/doc details a plan that makes ambox (and tmbox) last in the rollout. fmbox and cmbox should be pretty safe, but either way, that's why there's a staged rollout. Izno (talk) 21:13, 8 September 2025 (UTC)[reply]
It looks to me like the stop sign is slightly bigger (taller) than the others, but I believe these details can be changed. Also, I'm looking at this on a laptop, and the appearance on mobile (=66% of traffic) is going to be more important. WhatamIdoing (talk) 17:54, 14 September 2025 (UTC)[reply]
Yes, icon size and line-height we can adjust (I believe it may be line height I did not adjust, but sized down the text. Can size it down proportionally. But main thing is the concept for now.
What I think is most important is either coming across a community developer/contributor who knows if MediaWiki core has implemented some mobile adaptations for web (I know they have an entire interface etc. for mobile apps, that's fine)? Or anyone know of someone they can ask. Otherwise last resort, I can log a Phabricator ticket, asking if this is feasible, and ensuring it won't interfere with the mobile app implementation. Let me know what you think. waddie96 ★ (talk)00:34, 15 September 2025 (UTC)[reply]
Will the icons' appearance on Wikipedia Mobile (Web) be different from Wikipedia Mobile (App)?
Asking this because I viewed those icons on the web version, and wouldn't wanna give false inputs which might confuse you.
And we're discussing the web browser mobile app version yes, (I have used the app just not enough to confidently declare "I've used the app"), because the apps parse/process/sanitize the wikitext beforehand in some way I'm sure, for example the infobox is brought straight to the top just after one paragraph of lede (same as MobileFrontend), but also it doesn't go to the Main Page, it has it's own custom main page.
Hello, I was it would be really cool if entering the Konami Code did something crazy! I'm not exactly sure what, but it should be epic. Maybe on April 1st, it could make you an admin. 70.244.42.80 (talk) 00:27, 7 September 2025 (UTC)[reply]
Do people actually use game controllers to read Wikipedia? Where would they enter the Konami Code?
There would have to be a place for them to type the code. Think about it: if you are reading a Wikipedia article, and you accidentally press a few keys on your keyboard, nothing happens, right? It doesn't type those letters on the screen anywhere. Something would have to be 'listening' for the code. WhatamIdoing (talk) 01:45, 7 September 2025 (UTC)[reply]
It's also not 'typing the code'. If you actually push ↑+↑+↓+↓+←+→+←+→+B+A and then click the Search button, you'll end up at BA, because all the arrows get ignored by the search box. WhatamIdoing (talk) 16:53, 7 September 2025 (UTC)[reply]
Yeah, if you push the arrow keys that will happen but if you type the characters (which is easy for anyone with meta keys set up (e.g meta-> produces →) you get taken to the article. I presume getting mediawiki to interpret arrow keys as anything other than scrolling/navigating input boxes would require a very significant change to the code? Thryduulf (talk) 19:13, 7 September 2025 (UTC)[reply]
It would have to be done in Javascript, as that's the only way to capture keyboard events in a browser. The primary impact would be client-side, so for part of the same reasons that easter eggs became forbidden at Microsoft, I think we need to be cautious about deploying code for which most people won't see any net positive, particularly for those with slower devices. isaacl (talk) 21:53, 7 September 2025 (UTC)[reply]
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.
This doesn't seem suitable for RM, even if I could get past some technical obstacles.
Oppose, the name "idea lab" is perfectly descriptive. I like its slightly whimsical title, which pairs well with the likewise fun "village pump" (we aren't a village and there isn't a pump). "Proposals development and filtering" is a mouthful that is also confusingly similar to this page. It also isn't even correct, the idea lab is a lab, not a filtering process. Anyone can still post here without having gone through the "filter" of the idea lab. Dan Leonard (talk • contribs)01:07, 8 September 2025 (UTC)[reply]
It also isn't even correct, the idea lab is a lab, not a filtering process. Recent discussion seemed to disagree. I'm too old, tired, and semi-retired to go find that. And development = lab. Labs develop things. I understand the appeal of "friendly" names as a design principle, but we're generally not targeting an audience who need friendliness. If one really does, they probably lack the experience to be making site proposals anyway. anyway. This is not WP:TEAHOUSE. This is where big boys and girls play, that's just a fact of life. We shouldn't discourage low-experience editors here, but we needn't encourage it, either. ―Mandruss☎ IMO. 01:16, 8 September 2025 (UTC)Edited after reply 07:19, 8 September 2025 (UTC)[reply]
Recent discussion seemed to disagree. I'm too old, tired, and semi-retired to go find that. If it was a filtering process, then wouldn't you have posted this proposal there first? Dan Leonard (talk • contribs)01:19, 8 September 2025 (UTC)[reply]
LOL. Foxes guarding henhouse. I suspect that would have been summarily executed without a last cigarette. Not even worth much discussion, they would say. Go away, essentially. Three editors in firm opposition, zero in support, nobody else sees a need to even comment unless the situation changes before archival. I've been there a number of times and speak from some experience. ―Mandruss☎ IMO. 01:25, 8 September 2025 (UTC)[reply]
And even if it isn't, why would friendliness be bad? Unnecessary, maybe, but all the alternatives have far more wordword. Just why? And what's wrong with "Idea"? Proposals are when you develop and write an idea out, so the new title is just wrong. Aaron Liu (talk) 18:12, 8 September 2025 (UTC)[reply]
Anyone can still post here without having gone through the "filter" of the idea lab. And nothing in this proposal suggests that they can't. It does suggest that, if they go to VPPDF first, it will be to (1) develop the idea (potential proposal), and (2) decide whether the idea is proposal-worthy (filtering). This could easily be explained at the top of VPPDF (and/or this page), and I'm volunteering to write that. ―Mandruss☎ IMO. 07:50, 8 September 2025 (UTC)[reply]
"Proposals development and filtering" is a mouthful - Not a problem. So don't put it in your mouth. Just refer to VPPDF or WP:VPPDF, as the situation requires. that is also confusingly similar to this page. - Disagree. Unconfusingly similar to this page. Part of the rationale is to show that the two pages are (somehow) associated, which today is completely invisible at first glance. ―Mandruss☎ IMO. 10:44, 8 September 2025 (UTC)[reply]
Oppose, since a concise title is best. This would also likely cause confusion with the title of this page: Village pump (proposals) and Village pump (proposals development and filtering) both have "Village pump (proposals)" as part of their name. "Idea lab" is more accurate and makes a clear distinction between the two sections. SuperPianoMan9167 (talk) 01:13, 8 September 2025 (UTC)[reply]
'Comment. I will take this opportunity to preemptively respond to an argument that has not been made, but surely will be before this is over.
Argument: But what about the other village pump page titles? They're friendly. Why should this one stick out??
Response: This has been near the top of my user page for years: "Perfect is the enemy of good. Don't oppose small improvements because they fail to solve the problem 100%; the result is usually no improvement at all. Small improvements can be followed by other small improvements." Sure, we could expand the proposal to "un-friendly" all pages for consistency with VPPDF. I can't think of a better way to commit proposal suicide. That consistency is not critical. As a factor in this, it might have a little weight. Key word little. ―Mandruss☎ IMO. 07:34, 8 September 2025 (UTC)[reply]
That's a pretty dismissive response. Doesn't even respond to many of my points, suggesting that you can't counter them. "Non-problematic" - how so? Etc. Unhelpful, unconstructive, almost a democratic vote, a not-not-vote. We can do better. ―Mandruss☎ IMO. 13:37, 8 September 2025 (UTC)[reply]
Well, we could start with the proposal's rationale: More accurate and more descriptive. Call it what it is. Less accurate and less descriptive is problematic IMO. One can disagree, but they can't claim I haven't explained something. ―Mandruss☎ IMO. 21:48, 8 September 2025 (UTC)[reply]
Oppose new name is unnecessarily long and hard to remember. I fail to see how idea lab is bad; this is a place for developing on ideas which will eventually become proposals; while also filtering out ideas which may not work well the community and the project. The underlined part is my description of the current name, using most words from the proposed name which, I believe, conveys that the current name makes sense and is sufficient. (please ping on reply) ~/Bunnypranav:<ping>13:23, 8 September 2025 (UTC)[reply]
unnecessarily long - Feel free to suggest a way to shorten it while achieving the goals of this proposal. I'm at a loss. (This is called "collaboration", which is what Wikipedia editors are supposed to do as I understand it.) hard to remember - Thankfully, nobody needs to remember it. I suggest using the shortcut name. It's easier to remember in two simple steps:
Type "VP" for village pump.
Type the widely-used acronym used for that widely-used Adobe file format for documents. You know the one, it's virtually a household word these days.
Oppose Unconvinced by the rationale - the proposed title is a mouthful, doesn't accurately describe what the Idea Lab is for, and I see nothing wrong with the current name. I also agree with SuperPianoMan that having two village pumps whose subtitles start with 'proposals' is undesirable. Sam Walton (talk) 14:03, 8 September 2025 (UTC)[reply]
First, you're making a point or two that has already been countered, suggesting tha you haven't taken the time to read everything and fairly consider it. Second, does "idea lab" accurately describe what the Idea Lab is for? I don't see it. But if we can't improve our game substantially in a short time (two days?), I'll go ahead and pull the proposal and save myself a lot of time. This is what a 12-year editor should know to expect, but I'm somewhat thick at times. ―Mandruss☎ IMO. 14:10, 8 September 2025 (UTC)[reply]
(edit conflict) Oppose. Even after reading all of the comments in this section, I'm still at a loss as to how the proposed change is an improvement or quite why the supposed problem is actually something that needs improvement. The current title (well, the "idea lab" part at least) is succinct, descriptive and directly relevant to the page's content and purpose without be fussy or prescriptive. Not everything in the idea lab is, or is meant to be, a developing proposal - somethings are literally "I've had this idea, what do you think of it?". Thryduulf (talk) 14:10, 8 September 2025 (UTC)[reply]
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.
Remove non-ordinal series templates
The proposal (or at least this formulation of it) does not have consensus, and the proposer has indicated a desire to withdraw it from consideration (as well as linked to a VPIL thread for further brainstorming). jp×g🗯️09:22, 14 September 2025 (UTC)[reply]
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.
Hello all. My proposal is that all so-called "series" templates which do not indicate an order of the contained articles to be read should be deleted. Such templates clog up space in the article, and are merely glorified navboxes. A series box should present a set of articles to be read in (ideally) a particular order.
Here are examples of those series boxes which should be deleted:
Support, these duplicate the purpose of navboxes and additionally cause issues with MOS:SANDWICH. Having a chronological order (such as in campaignboxes) is a justifiable reason to keep a sidebar, as they add additional information. However, given the wide scope of this change, I wonder if it could be better to structure this proposal as a RfC. Chaotic Enby (talk · contribs) 13:15, 10 September 2025 (UTC)[reply]
To clarify, I placed the discussion there given its very wide scope (affecting thousands of templates, each of them in use on many content pages), rather than the current size of the discussion itself. Chaotic Enby (talk · contribs) 16:14, 10 September 2025 (UTC)[reply]
Oppose I don't think that the arguments in favor of removal are strong enough. To me, the situation is not anywhere near bad enough to justify this. JuxtaposedJacob (talk) | :) | he/him | 14:24, 10 September 2025 (UTC)[reply]
The argument is simple: these series boxes are unnecessarily taking up space in the article (usually at the lead paragraphs!) as they are mere duplicates of navboxes. ―Howard • 🌽3314:33, 10 September 2025 (UTC)[reply]
Strong Oppose - you are in effect suggesting the deletion of almost all sidebars on Wikipedia articles unless they happen to be a historical chronology.Bottom navboxes and sidebars can and do coexist, often times sidebars are a subset of bottom nav boxes that tend to be more complete, but also overwhelming to many readers.It would also force all readers to have to scroll to the bottom of articles instead of being able to open a main topic and being able to jump to related main topics right from the prominent sidebar.Like you are suggesting deletion of {{discrimination sidebar}} or {{Democracy sidebar}}, {{Psychology sidebar}}, {{LGBTQ sidebar}}, {{Research sidebar}} or {{Geography sidebar}}, or just about almost all sidebars outside of ordinal history. Likely snow close and most definitely needed CENT listing. The proposal should have been a lot clearer about the impact this would have, listing a lot more prominent examples as I just did. Raladic (talk) 15:56, 10 September 2025 (UTC)[reply]
I fully support the deletion of those templates also. These can all and should be formatted into navboxes. Take for example the Democracy, LGBTQ, Discrimination, and Geography sidebars which are filled to the brim with countless articles exactly as overwhelming a navbox would be. I oppose a snow close and prefer a full discussion into the matter. ―Howard • 🌽3316:06, 10 September 2025 (UTC)[reply]
These sidebars are how most readers navigate major topics. Template:Sidebar is currently transcluded 320,000 times Toolforge: Sidebar (~320,000). Likely the majority of such sidebars is not chronological or otherwise ordinal. We should get a quarry count to have a full understanding of the scope this would impact, which is going to be huge and will nto serve our readers by taking away the primary way how many readers navigate between articles.
If we have a sidebar with the same amount of content as a navbox, what is the purpose of the sidebar? I am not against all sideboxes, but I am against those sideboxes which claim to present a "series" but are overwhelming with content quite obviously not presented as a series. I believe ordinal sidebars are much more helpful as they have defined limits for inclusion and ordering. A navbox can serve as a more indiscriminate collection of topics. ―Howard • 🌽3316:48, 10 September 2025 (UTC)[reply]
Q: Why have a sidebar template at the top of an article, when you could have a navbox with the same links at the bottom of the article?
Strong Oppose Like Raladic, I do not understand how "chronology improves organization" can be used to conclude that non-ordinal series templates are so difficult to organize that they deserve across-the-board deletion. {{Donald Trump series}} is obviously an outlier given that Donald Trump is the most heavily covered individual on Wikipedia by many metrics. {{Progressivism sidebar}} and similar templates for political philosophies are highly useful in my reading experience to relate people of an ideology by their occupation. Having removed portals from the Main Page in 2022, we rely on such sidebars as a better maintained form of organization. ViridianPenguin🐧 (💬) 16:49, 10 September 2025 (UTC)[reply]
I’ll also note that if the OP has a problem with the Trump template - part of that is likely due to the fact that the template is poorly written right now and should use collapsible subgroups so that it’s transcluded use can have everything be default collapsed and only the relevant to the page section is expanded upon transclusion using section state parameters like we do on other more organized sidebars. Raladic (talk) 17:00, 10 September 2025 (UTC)[reply]
Strong Oppose This is a huge ask for an arbitrary reason. The OP is effectively requesting the mass-removal of sidebars for a reason not specified at the WP:SIDEBAR guideline and does not state any rationale apart from "I don't like it". The guideline addresses that sidebars can take up a lot of "real estate" but explains what should go into a sidebar vs. what should go into a navbox. When done well, sidebars (such as {{Joe Biden series}}) can aid readers in finding relevant articles to the topic at hand. If an article has both a sidebar and a navbox, the sidebar should either serve as a complement to the navbox or contain only a closely-related subset of articles in the navbox. IFF they are identical lists, then the sidebar can be removed from that article, but this wholesale approach is effectively using a wrecking ball instead of a ball peen hammer. — Jkudlick ⚓ (talk)17:20, 10 September 2025 (UTC)[reply]
Oppose. I cannot tell the difference between your examples of ordered and unordered sidebars. They all just look like sidebars to me. and I think removing all sidebars would be pretty drastic. do you have some diffs or evidence of complaints about sidebars? Is this maybe a solution looking for a problem? –Novem Linguae (talk) 18:19, 10 September 2025 (UTC)[reply]
From what I understand, ordered sidebars (like the example {{2023 United States banking crisis sidebar}}) show the articles in a specific, meaningful order (usually chronological or logical), which adds utility, although navboxes can also do that. I don't have specific diffs in mind (and it would have been good to see a WP:RFCBEFORE equivalent before jumping into a major discussion like this), but one aspect is that having more floating content can easily amplify MOS:SANDWICH issues. Chaotic Enby (talk · contribs) 18:25, 10 September 2025 (UTC)[reply]
I don't use these sidebars, so I do not think they are particularly useful (like most navboxes are not very useful) and they take up space that could be used for more images. However, per WP:LEOPARD, I oppose deprecating them via the Village Pump; if you want to delete them, just use WP:TFD. —Kusma (talk) 18:24, 10 September 2025 (UTC)[reply]
If WP:LEOPARD's guidance to tag each affected template were actually followed for this proposal, it would be interesting (purely academically) to see how many TfD's that would be, given that the {{TfD}} template is limited to a max of 50 at a time per WP:TFDHOW. Raladic (talk) 18:35, 10 September 2025 (UTC)[reply]
Yeah, no. Removing some class of templates en masse is precisely a case where you should use the RFC process. TFD is 1) not equipped to handle that kind of volume, and 2) is not the kind of place to establish a precedent for sending pages for deletion. Izno (talk) 21:06, 10 September 2025 (UTC)[reply]
My point is that TfD has proper mechanisms that ensure that interested parties get notified (tagging the templates). The Village Pump does not. I would be happy with any other notification mechanism that actually works. —Kusma (talk) 07:59, 11 September 2025 (UTC)[reply]
Oppose sidebars aren't redundant to navboxes, they're an alternative. In fact, I prefer sidebars, because unlike navboxes they look nice and high enough in the article content that readers are liable to actually use them. Cremastra (talk·contribs) 20:23, 10 September 2025 (UTC)[reply]
I am increasingly of the opinion that we should delete the use of {{sidebar}} in mainspace, but this proposal proposes only some half step that honestly doesn't make any sense. Sidebars like navboxes have for a long time not been required to have some order (lol), and changing what is effectively an inclusion criterion for links in a sidebar is nitpicking at what these do. Izno (talk) 21:11, 10 September 2025 (UTC)[reply]
Further comment: I will admit this is my first time starting a village pump discussion and was not expecting this level of attendance. I don't want to make this a full-blown RFC either, at least not at this point. It is perhaps my solution which is a bit too far (deleting all non-ordinal sidebars outright), but this is something I am willing to scale back if a different solution solves the following problem:
Some sidebars are just too long and indiscriminate. There are too many cases of them resembling or duplicating navboxes outright. These kinds of sidebars are taking up space in the first paragraphs and this can cause sandwiching.
If a consensus exists that this is a made-up problem, or merely opinion-based, then I will drop the entire discussion and move on. If there is a consensus that this is a genuine problem affecting the layout of pages but my solution is far-fetched, then I believe there should still be some kind of style guide to prevent these excessive side-bars. ―Howard • 🌽3322:11, 10 September 2025 (UTC)[reply]
Some sidebars are just too long and indiscriminate. There are too many cases of them resembling or duplicating navboxes outright. These kinds of sidebars are taking up space in the first paragraphs and this can cause sandwiching. - I'd say that's primarily opinion based.
While, as I mentioned above, some sidebars may not be well-designed (e.g. being default-expanded in all sections), that is an entirely differently fixable problem.
We have many very well-designed sidebars, that take up minimal space and can be controlled through parameters to only expand the section that is relevant to the page where it's transcluded, and they are serving many users to jump to related articles instead of having to scroll all the way down to a navbar at the bottom.
So I'd suggest if you have a particular template that you have an issue with, assuming it's not protected above your permissions, go, be WP:BOLD, or raise an edit-request at the talk page of the template if it might be a more contentious change, and improve it, give it collapsed sections, make unnecessarily big images a bit smaller. The world is your oyster.
I will say that of course you are not alone in that some other editors also may not like sidebars (as this thread has shown with some agreeing with you), but I think on-average, they serve more readers than they may annoy (some) editors and we do have to remind ourselves that we're writing this think primarily for our readers first and the average reader may not be as tech-literate as many editors are and appreciate a simple prominent box to find related articles that they may otherwise miss as statistically speaking, many readers don't go past the lead as WP:SUMMARIZE reminds us. Raladic (talk) 01:41, 11 September 2025 (UTC)[reply]
The LGBTQ and Discrimination sidebars are extremely cluttered (Psychology less so), so I would actually consider them bad examples. Even though the sections are collapsed, the content within them is still filled with a navbox-level amount of words. For example, when expanding the "manifestations" section of the Discrimination sidebar, one finds 211 words, and making the sidebar fully expanded gives 765 words. At what point can it be considered excessive? ―Howard • 🌽3312:53, 11 September 2025 (UTC)[reply]
I support the deprecation of all sidebars. They are fairly useless and take up a huge amount of horizontal space, which is in short supply for readers since we switched to Vector 2022. They also result in far too much strife to be worthwhile, like the recent nightmare over the Conservatism and Liberalism in China sidebars. Relegating this content to navboxes solves most of these issues, while leaving them intact for any readers who may still wish to use them. Toadspike[Talk]07:47, 11 September 2025 (UTC)[reply]
I must support starting to phase out sidebars. They are so cursed; infoboxes are already CVS receipts, and now these are tacked on underneath. If we want to sandwich a picture into the first section, in some cases we need to move the sidebar out of the lead for technical reasons. The navboxes at the bottom are much better. I would also give the (crackpot) idea that sidebars could work if they were instead placed in the vector 22 right side toolbox, but that idea might be too radical. 3df (talk) 08:22, 11 September 2025 (UTC)[reply]
Oppose as grossly disproportionate to the (mostly trivially) fixable problem of some sidebar templates being bloated and/or poorly organised. Thryduulf (talk) 13:10, 11 September 2025 (UTC)[reply]
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.
Fact tags after refs
Wikipedia:Citation Hunt just led me to an article that has an inline citation followed immediately by a fact tag, as in this example:
I suspect that some of these are content disputes (see WP:FETCH), others should be {{Better source needed}}, and that others are simply sources added by less experienced editors, who are expecting a "moderator" to check their work and remove the tag. But all of them are requests for a citation, when a citation is already present, which is an oxymoron.
I don't have an exact count, but I think it happens in a few thousand articles. I think we should have a bot remove these redundant tags. What do you think? WhatamIdoing (talk) 16:40, 11 September 2025 (UTC)[reply]
I've come across a few of these, it's definitely jarring, but I would be against mass removed by a bot. Some could just be removed, but other might highlight actual issues just with the wrong template. This search for {{citation needed}} times out, but returns 884 articles[45], {{fact}} - 74[46], {{CN}} - 411[47]. {{Citation needed}} has 81 redirects so there probably more, but these are all small enough that they could be cleaned up manually. -- LCU ActivelyDisinterested«@» °∆t°18:44, 11 September 2025 (UTC)[reply]
I did a search for >{{citation n and got three thousand articles before it timed out. My search also picked up non-refs (e.g., <!-- hidden comment -->{{citation needed so I tried again and got 2,300 for only </ref> tags. This misses all re-used refs like <ref name="Smith" /> and of course any redirect like {{fact}}.
There are many maintenance categories with tens of thousands of entries, and some of them have been cleared down. Even if it is a few thousand entries that is well in the realm of manual clearance. -- LCU ActivelyDisinterested«@» °∆t°19:18, 11 September 2025 (UTC)[reply]
I would be against removal by bot, because it is unlikely that a bot would be able to distinguish whether to remove the citation or the "citation needed" tag, and there are several other possibilities such as changing "citation needed" to something else. And human editors would relish having several thousand articles to work on. Phil Bridger (talk) 19:40, 11 September 2025 (UTC)[reply]
One possible case where this is not strictly an error per se (but is clearly far from optimal) is where where the citation supports only part of the associated content. Simply removing the CN template in such circumstances would be incorrect. What might work is for a bot to replace the citation needed tag with a new tag that states something like "The adjacent reference needs to be checked." and puts the article in a maintenance category. Thryduulf (talk) 23:39, 11 September 2025 (UTC)[reply]
That's only ever so slightly better than {{Citation needed}} but it's still not a great fit as that is for situations where someone has tried but failed to confirm the source verifies the article but has been able to for some reason (typically being unable to access the source). That's a specific issue that needs addressing, the problem here is that the combination of tags is not specific, it could mean multiple different things:
The citation needed tag is outdated
The reference failed verification
Someone was unable to verify whether the reference is correct or not
A better source is needed
The reference verifies only part of the associated content
What we want people reviewing this maintenance category to do is: identify what the issue is, fix it (if they can) or adjust the tagging to make it clear to other editors what the problem is. Thryduulf (talk) 10:11, 12 September 2025 (UTC)[reply]
remove {{citation needed}} (e.g., this is a reliable source and it supports the material as written; this is a reliable source, and I've corrected the Wikipedia article to match the cited source)
Why there are some undo/rollback edit such as edits 10 years ago like this or this did not contain Undo and Rollback tags? Can someone should tag Undo and Rollback for edits that were 10 years ago or more? Fabvill (Talk to me!)02:23, 12 September 2025 (UTC)[reply]
It's technically possible, at least in principle - tags are stored in a different database table than article text, or edit summaries, or other revision metadata, and there's nothing forcing it to only be updated at the time of an edit - but it's not practical to look at old edits and determine if they were actually rollbacks or undos. Edit summary doesn't help, since you can write whatever you want in there. I used a manually-constructed rollback-looking edit summary a couple times before registering, because I didn't know rollback existed and thought that was just the accepted etiquette when reverting someone, and looking back I'm sort of surprised nobody ever hollered at me for impersonating an admin or whatever. I suppose you could look for a combination of a proper rollback edit summary, contemporary presence of the rollbacker or administrator user group (which is itself difficult to prove programmatically), and an edit that restored a previous revision's text, but it would be difficult to program, likely slow to execute, and not be of much benefit: after all, you were already able to look at those old edits and determine they were undos and rollbacks despite them not being tagged. Proving an undo, when the edit being undo wasn't the most recent (and so not equivalent to a rollback) would be even worse. —Cryptic11:50, 12 September 2025 (UTC)[reply]
@Fabvill: The simple answer is that it isn't possible to do this, since mw-rollback and mw-undo tags are automatically applied by the software. The only way to apply a rollback-like tag or undo-like tag, would be to create a whole new tag just to deal with old edits and identify them as using rollback and undo, but that is of dubious benefit to the page history, honestly. If you have a tangible benefit to doing so, I suppose it's not impossible to add a new "manually-applied rollback tag" or similar for undo, but I'm not seeing a reason justifying that. EggRoll97(talk) 06:09, 14 September 2025 (UTC)[reply]
Proposal: Remove the Contents link from the sidebar
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 consensus to remove. Editors who expressed a clear opinion were evenly split between removing and keeping. Editors in favor of removal pointed to low click rate and said other navigation systems, like portals were better, and this link was a distraction. Many participants did not express a clear opinion, so it seems the need to remove this high-profile link is not obvious. Editors suggested improving the page or improving the links from the main page; this link was hard to find for some. This question might be worth revisiting if those efforts are made and do not result in a perceived improvement in usefulness or engagement. Proposing page deletion might be an appropriate forum next time, as some editors said this page is useless if it is not linked from the main menu. -- Beland (talk) 14:30, 12 September 2025 (UTC)[reply]
Considering the amount of pageviews this page gets, I just don't see the value in keeping this page. When looking at the page, it disappoints me that while it does cover most types of articles, it doesn't cover biographies pretty well. Biographies make up a huge portion of our Wikipedia pages, so unless the page is improved to include them, I think it would better to just remove the link. Interstellarity (talk) 12:28, 7 July 2025 (UTC)[reply]
The standard for appearing in the sidebar is much higher than "not causing harm." If it's not pulling its weight, it should be removed. SnowFire (talk) 15:53, 8 July 2025 (UTC)[reply]
The number of views is about 3800/day, essentially all of them from desktop, almost none from mobile. WP:Contents and its subpages are an attempt at providing alternative ways to discovering Wikipedia content (not through direct search), a time-honoured traditional approach. I am not sure it is working well for many people and I do not know how well-maintained it is, but if there is no link to this from sidebar or at least the Main Page, it won't work at all. —Kusma (talk) 16:11, 8 July 2025 (UTC)[reply]
Contents is indirectly linked on the Main Page, via Contents/Portals. Maybe replace that with a straight link to Contents? Dege31 (talk) 17:30, 8 July 2025 (UTC)[reply]
De-cluttering sidebars/menus generally has one underlying goal: to quit 'distracting' people with something that's not useful/helpful, so that they will be more likely to find/click on something that is useful/helpful. WhatamIdoing (talk) 07:10, 13 July 2025 (UTC)[reply]
Support removing the page, as it does not help navigation, nor does it make sense to have 7 million articles condensed into a scrappy and incomplete list in the sidebar. Portals probably do a better job. Pksois23 (talk) 07:31, 18 July 2025 (UTC)[reply]
Just to check, the sidebar and its links are only relevant for logged in users right? Taking action/no action would not affect most readers, so the links are mostly there for newer editors (or to try and beguile readers creating accounts into becoming editors)? CMD (talk) 07:53, 18 July 2025 (UTC)[reply]
As I said, there is no Main menu when I am logged out. I don't think logged out users can turn settings on and off. CMD (talk) 12:38, 18 July 2025 (UTC)[reply]
It's hidden as the three bars left of the Wikipedia logo in the top left. When you click it it should have an option that says move to sidebar. At least on vector 22 it's like this Pksois23 (talk) 12:45, 18 July 2025 (UTC)[reply]
I really don't understand the issue. How should we cover biographies on the Contents page? Or if you don't know (which is quite reasonable) what benefit would you expect to get that you don't now? All the best: RichFarmbrough21:45, 30 July 2025 (UTC).[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
RfC: merging Wikipedia:Requests for comment/User names with AN(I)
Survey (merging Wikipedia:Requests for comment/User names with AN(I))
Support as proposer. There have been three (3) archived requests in 2025, and there were six (6) in 2024. We have too many noticeboards, discussion venues, and processes; dealing with this one seems like some low-hanging fruit. We previously shut down WP:EAR and WP:N/N for disuse. At the VPI discussion, it was brought up that this might slightly discourage filing reports. I see that as a feature, rather than a bug: only two of those nine reports found consensus that the username was inappropriate, most recently over a year ago, so slightly increasing the threshold for a filing would cut down on unnecessary discussions. HouseBlaster (talk • he/they)16:16, 14 September 2025 (UTC)[reply]
Support per nom. While ANI is definitely getting a bit large, the very low volume of requests this would add isn't really an issue compared to the advantage of simplifying a whole noticeboard away. If we want to limit ANI bloat, we could move something like TPA requests away to AIV instead. Chaotic Enby (talk · contribs) 16:21, 14 September 2025 (UTC)[reply]
Oppose This will just create confusion I think. The current page is being used for when UAA has declined to block a username, but the person reporting would like a community opinion. Bringing it to AN or ANI will result in overblocking, I suspect as blocking admins may not be familiar with the detailed rules we have. Secretlondon (talk) 16:43, 14 September 2025 (UTC)[reply]
SupportWP:AN or the suggestion in the discussion below for WP:UAA. OpposeWP:ANI, for reasons similar to Secretlondon's (though I'd say the bigger problem will be the dramaboard mob not reading the rules, rather than admins). WhatamIdoing (talk) 17:39, 14 September 2025 (UTC)[reply]
Oppose. RFC/N is a specialized venue for a specialized set of cases—notably, applying a policy that many users, even experienced users, even admins, often misunderstand. The proposer hasn't presented any evidence that RFC/Ns are resulting in unjust outcomes or otherwise hindering the smooth running of the encyclopedia, just that there isn't much volume of cases and that some can be resolved through normal admin actions, neither of which is inherently a problem. Nor have they presented any evidence that AN or AN/I is better-equipped to handle such cases. If it ain't broke, don't fix it, and it ain't broke. Instead, I'd rather we better advertise the existence of RFC/N, particularly to UAA filers (who frequently report users on bases that do not justify a summary block, but might be disallowed at RFC/N if anyone bothered to file), and consider expanding RFC/N's scope to also include signature issues, which are related to username issues and are not well-suited to AN(I). -- Tamzin[cetacean needed] (they|xe|🤷) 17:46, 14 September 2025 (UTC)[reply]
Moving that "specialized set of cases" to a more widely used venue might result in more people understanding that policy better. That could result in fewer unjust accusations being made in the first place, which would support the smooth running of the encyclopedia. WhatamIdoing (talk) 18:10, 14 September 2025 (UTC)[reply]
Oppose (summoned by bot). ANI every time I drive by or am summoned to it is definitely too large, and having a specialized venue would enable admins to get to specific username requests quickly, and sort them out. I would be more open to making them a dedicated section, but I still feel like that one page for everything could have a load time impact, as well as increase the chance of edit conflicts. InvadingInvader (userpage, talk) 14:16, 16 September 2025 (UTC)[reply]
Discussion (merging Wikipedia:Requests for comment/User names with AN(I))
No - it's used when the submitter thinks it should be blocked but the admins don't agree. They've all gone through UAA and been found as borderline. Secretlondon (talk) 16:40, 14 September 2025 (UTC)[reply]
I see it as a separate section of the page. Given the very few username discussions it shouldn't be a problem. The other alternative would be to create a template to use and hold the discussion on the talk page of the user. Just spitballing here. 331dot (talk) 17:34, 14 September 2025 (UTC)[reply]
Honestly, a dedicated section for deeper discussions would be quite helpful. Avoids sending editors flying from one noticeboard to another, and especially avoids the risk of ANI drama, while keeping the number of noticeboards low. I'm inclined to support that as my first choice. Chaotic Enby (talk · contribs) 17:48, 14 September 2025 (UTC)[reply]
That might necessitate renaming UAA to something else; Usernames for attention; Username reporting and discussion; something else..... 331dot (talk) 18:25, 14 September 2025 (UTC)[reply]
Yet another perfect place to change "administrator" to "administration", just like with AN/ANI. They're not pages for administrators, they're pages for the administration of the encyclopedia. ScottishFinnishRadish (talk) 14:23, 16 September 2025 (UTC)[reply]
Automatically create a subpage draft for pages that are fully protected while being heavily edited
Every once in a while, we have a subject where the article is being heavily edited by editors with competing views from all sides, such that the article ends up being fully protected either due to addition of strongly contested content or edit warring or both. I propose that whenever an article is fully protected while being heavily edited in this manner, a subpage draft of the article should automatically be created, where editors can continue their efforts unimpeded by the page protection. That way, good additions can be made and sources added within the context of the appearance of the article without the actual article being touched. If editors want continue edit warring over the substance of the article, letting them do so on a draft subpage allows the dispute to play out and possibly even result in workable compromise language without either disrupting the article, which remains locked, or requiring administrators to fix every typo and add every legitimate point and reliable source proposed on the talk page. BD2412T22:59, 16 September 2025 (UTC)[reply]
And who gets to decide which of the edits on the sub-page get moved to the article? That's if any editing actually happens on the sub-page.
I can perhaps see the merits in a page that exists for the sole purpose of collecting additional sources (plus the minimum context needed to identify what they relate to). Only an uninvolved (admin? extended-confirmed?) editor would be allowed to remove citations from that page that had not been added to the main article with consensus. Anything else, discuss it on the talk page. Thryduulf (talk) 23:57, 16 September 2025 (UTC)[reply]
@Donald Albury: If editors are directed to make their proposed edits to the subpage, I expect a reasonable number will do that. As for who decides which edits get moved, that would probably still be the admins (until page protection expires), but they need not do it right away, so disputes will play out on the subpage. I think sometimes editors can't come to an agreement on the talk page because they can't envision what it will look like in the article, and can't edit the article. BD2412T00:00, 17 September 2025 (UTC)[reply]
I just have trouble envisioning that editors who edit war in main space are going to play nice on a sub-page. I suspect many won't bother because it isn't real. Donald Albury00:57, 17 September 2025 (UTC)[reply]
I've seen one or two varieties of this on specific contentious pages a long time ago. It might sometimes be helpful but in general we should not encourage the idea that people can continue to treat pages like a forum to erect their favorite theory. Johnuniq (talk) 02:52, 17 September 2025 (UTC)[reply]
The smaller action of locking the lead within a subpage would alleviate a large amount of potential conflict while still allowing work on the substance of the article. CMD (talk) 03:20, 17 September 2025 (UTC)[reply]
I actually haven’t seen a fully protected article before, and seeing now how rare it is, that makes sense. But in clicking through to Spinosaurus—an article I would presume is uncontentious—it is not at all obvious what has gone wrong to the point that experienced editors are unable to edit it. Clearly there’s some dispute, but there is no notice nor section on the talk page. Is it too much to ask that perhaps fully protected pages should have some section created, linking recent edits and or editors involved? Someone decided that Erika Kirk needed a banner, and while I disagree with this as a general solution (the talk page is a much better place for it), it speaks to a shared desire on the part of editors to understand what is going on. — HTGS (talk)09:17, 17 September 2025 (UTC)[reply]
I fully protected United States Department of Defense last week because of an edit war involving multiple users, including some with edit counts in the thousands. I modified that 12 hours later to ECP protection with BRD required. Most of the edit warriors have stayed away from both the article and the talk page since then. Editing the talk page doesn't appear to be attractive to those edit warriors, and I doubt a sub-page would be any more attractive. I think full protection of a page should be kept as short as possible, and, at least with articles that fall in a contentious topic area, other editing restrictions should be used to prevent edit warring. Donald Albury12:39, 17 September 2025 (UTC)[reply]
Apparently there's a debate over just how big that dinosaur is. There are three discussion on the talk page, and two of them are about it.
In re "Is it too much to ask that perhaps fully protected pages should have some section created, linking recent edits and or editors involved?": I think one of the purposes of protecting a page is to incentivize the edit warring factions to find the talk page. WhatamIdoing (talk) 21:12, 17 September 2025 (UTC)[reply]
EPSTEIN LIST (Epstein files in Wikipedia)
Is there really a problem with creating this list on Wikipedia? Then users, on a volunteer basis, could start adding everyone who might have been on that island.
You could create a Red List and a Yellow List — for those who were definitely there, and those who possibly were.
(BLP violation removed), for example, would go on the Red List — that's pretty obvious. (BLP violation removed) would go on the Yellow List, since he said that "this list doesn’t exist" — maybe he’s on it himself.
This list could then be treated as real and used to damage the reputation of those pedophiles.
Of course, all accusations must be backed by links to the sources or information the claims are based on. Ivapol (talk) 09:51, 17 September 2025 (UTC)[reply]
While a list of people who actually were on the island might have legitimacy, Then users, on a volunteer basis, could start adding everyone who might have been on that island. is way too broad. You might have been on the island. We (TINW) should be careful to not defame innocent people. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 09:59, 17 September 2025 (UTC)[reply]
This template uses the description list markup to display the "hatnote", which is bad for accessibility and also not compliant with the manual of style (Wikipedia:Manual of Style#Indentation: Do not use : (description list markup) to indent text in articles).
If you use a <div> rather than a <span>, it should avoid the manual notes will be on the same line as notes generated by the template difference. Anomie⚔13:18, 17 September 2025 (UTC)[reply]
🤷 If you want some things but not others, I guess you're out of luck to reproduce the current behavior without wikitext list markup of some sort. Anomie⚔13:53, 17 September 2025 (UTC)[reply]
If the implementation of the {{Updated}} template is modified to pass its message (including the reference) to {{Hatnote}}, then the message should be in a <div>...</div> element, with the reference contained within, and following text will be on a new line. However, any uses in the form of the testcase at Template:Updated/testcases § Reference following, with text on a new line after the reference would have to be changed so the reference is passed to the template. This does seem to be the originally intended way to use the template, but if it's true that a trailing reference is frequently used in football articles, then there may be a lot of instances of this alternate usage. isaacl (talk) 15:50, 17 September 2025 (UTC)[reply]
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.
I think this could be really useful as you have a choice to change your Wikipedia time that you see on your computer (a local option just for the computer itself)
How I think this would work is that you would go into preferences > appearance > time offset, and it would give you a list of options to change your "server time" to.
Your signature's time being your local time is just inconvenient to people whose signature's time is UTC. Imagine that your signature's timezone was UTC+3 at the moment you made this comment I'm replying to; it would appear as if you replied to me 3 hours after I left my comment. Sapphaline (talk) 12:39, 18 September 2025 (UTC)[reply]
The time after the signature is in UTC so that everyone sees the same time, which when referring to a post (e.g. "the post made by EditorShane3456 at 12:28 today") is a good thing. Phil Bridger (talk) 12:37, 18 September 2025 (UTC)[reply]
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.
UPDATE: On Monday, 11 August, the High Court of Justice dismissed the Wikimedia Foundation’s challenge to the UK’s Online Safety Act (OSA) Categorisation Regulations. While the decision does not provide the immediate legal protections for Wikipedia that we hoped for, the Court’s ruling emphasized the responsibility of Ofcom and the UK government to ensure Wikipedia is protected as the OSA is implemented.
The judge recognized the “significant value” of Wikipedia, its safety for users, as well as the damages that wrongly-assigned OSA categorisations and duties could have on the human rights of Wikipedia’s volunteer contributors. The Court stressed that this ruling “does not give Ofcom and the Secretary of State a green light to implement a regime that would significantly impede Wikipedia’s operations”, and indicated they could face legal repercussions if they fail to protect Wikipedia and the rights of its users. In order to achieve that outcome, he suggested that Ofcom may need to find a particularly flexible interpretation of the rules in question, or that the rules themselves may need amendment in Parliament.
If the ruling stands, the first categorization decisions from Ofcom are expected this summer. The Foundation will continue to seek solutions to protect Wikipedia and the rights of its users as the OSA continues to be implemented.
If enforced on Wikipedia, Category 1 demands would undermine the privacy and safety of Wikipedia’s volunteer contributors, expose the encyclopedia to manipulation and vandalism, and divert essential resources from protecting people and improving Wikipedia, one of the world’s most trusted and widely used digital public goods.
For example, the Foundation would be required to verify the identity of many Wikipedia contributors, undermining the privacy that is central to keeping Wikipedia volunteers safe. In addition to being exceptionally burdensome, this requirement—which is just one of several Category 1 demands—could expose contributors to data breaches, stalking, lawsuits, or even imprisonment by authoritarian regimes.
Aww, bye-bye then me lovlies. I have really enjoyed editing Wikipedia. Thank you to every editor who has helped me along the way. I've met some great people here. Thank you for the opportunity to help the worlds best encyclopaedia. Knitsey (talk) 12:32, 11 August 2025 (UTC)[reply]
+1, if this is it for Wikipedia in the UK then I would like to say it’s been an absolute pleasure being a part of this community for over a decade, and I will really miss it, as well as all the people here I’ve connected with as a result. Patient Zerotalk13:03, 11 August 2025 (UTC)[reply]
If this really does become it for Wikipedia in the UK which it might, then it has been a pleasure editing Wikipedia. I would like to give my thanks to everyone who has helped up to this point. I can't believe my time here could be up soon after 5 years and nearly 24,000 edits later. Maurice Oly (talk) 14:01, 11 August 2025 (UTC)[reply]
Is it possible you all are writing your resignation speeches a little quickly? Wouldn't it be better to try to circumvent whatever they're doing with a VPN or something? Is it even confirmed that they're doing anything to Wikipedia yet? –Novem Linguae (talk) 21:55, 11 August 2025 (UTC)[reply]
Since VPNs are routinely blocked by Wikipedia, and the edit restrictions would be imposed by Wikipedia to prevent it breaching the Category 1 threshold, I don't think that users of Wikipedia in the UK can rely on VPNs to be able to edit Wikimedia sites.Nigel Ish (talk) 22:12, 11 August 2025 (UTC)[reply]
In a situation where a VPN is needed, UK editors would probably want to apply for WP:IPBE. This is how Mainland China editors circumvent their country's restrictions, I think. –Novem Linguae (talk) 23:07, 11 August 2025 (UTC)[reply]
As a UK editor, if this were to happen, and I had assurance that Wikipedia administrators wouldn't block me for circumventing the OSA law, I would probably consider doing that. VPNs and browser proxies I have used previously however, have been slow and have issues with maintaining connection across tabs (which for Wikipedia is a must - partaking in multiple discussions on different pages for example). 11WB (talk) 23:18, 11 August 2025 (UTC)[reply]
This is good to know. I have IPBE already and would certainly want to use it to contribute using a VPN if anything does happen. I hope I would be allowed to do so. I believe that the OSA does plan on addressing VPN usage at some point, though, so if that were to happen it would only be a temporary fix. Patient Zerotalk00:51, 12 August 2025 (UTC)[reply]
It's not actually that bad of a loss for Wikipedia. The relevant extracts from the judgement (emphasis mine):
I stress that this does not give Ofcom and the Secretary of State a green light to implement a regime that would significantly impede Wikipedia’s operations. If they were to do so, that would have to be justified as proportionate if it were not to amount to a breach of the right to freedom of expression under article 10 of the Convention (and, potentially, a breach also of articles 8 and 11). It is, however, premature to rule on that now. Neither party has sought a ruling as to whether Wikipedia is a Category 1 service. Both parties say that decision must, for the moment, be left to Ofcom. If Ofcom decides that Wikipedia is not a Category 1 service, then no further issue will arise.
If Ofcom permissibly determines that Wikipedia is a Category 1 service, and if the practical effect of that is that Wikipedia cannot continue to operate, the Secretary of State may be obliged to consider whether to amend the regulations or to exempt categories of service from the Act. In doing so, he would have to act compatibly with the Convention. Any failure to do so could also be subject to further challenge. Such a challenge would not be prevented by the outcome of this claim
Note the use of the words "May be" my guess is that the government will do everything in its power to change may be to not have to. We will just have to wait and see what happens. Maurice Oly (talk) 14:03, 11 August 2025 (UTC)[reply]
I still can't see how we can fall under the Category 1 regulations? They keep talking about the number of users but the key part for us is surely "uses a content recommender system". I saw some saying things like Special:NewPagesFeed would count but it's not algorithmic as defined in the legislation. Even if it was classified as such instead of reducing access, as some have said, just put such feeds behind permissions and remove any perceived "content recommender system"s from the general readership. Worst case is IP editors get a bit restricted. KylieTastic (talk) 14:32, 11 August 2025 (UTC)[reply]
I mistakenly put this on Knitsey's talk page discussion instead of here. I'll repost here. This is my takeaway from this as a UK contributor:
The OSA and how Wikipedia will be categorised by Ofcom is concerning. However, looking at this which lays out how the categorisation works based on the 2 conditions - personally, I don't see how Wikipedia could meet condition 1, as for condition 2, 'allows users to forward or reshare user-generated content' I believe is true and 'has more than 7 million UK users on the user-to-user part of its service, representing c.10% of the UK population' is possible (I don't think the actual number of active registered UK Wikipedians is known publicly). Dependent on how Ofcom determines the second condition, Category 1 could be a possibility. It's clear though if that were to happen, the Wikimedia Foundation don't plan to leave it unchallenged. Hopefully that's some reassurance! 11WB (talk) 14:38, 11 August 2025 (UTC)[reply]
But option (b) needs to hit all three conditions as there is an and at the end of (ii) so if uses a content recommender system can be show to not be true or taken away from the main user base (the readers) then we can ignore the sharing part of the regulation (iii). KylieTastic (talk) 14:56, 11 August 2025 (UTC)[reply]
@KylieTastic: The app has some features that strike me as meeting this criteria more than NPP does. For example, "Places" (which shows articles about places near you if you enable location sharing), "Wikipedia games" (guess what event in history happened first), and actual recommendations for articles that might interest you based on your viewing history. Clovermoss🍀(talk)03:05, 19 August 2025 (UTC)[reply]
A VPN did cross my mind, however Wikipedia itself has very tough policies on those. Editors who are known to be from the UK that begin using VPNs to circumvent any (potential) Category 1 block run the risk of their Wikipedia accounts getting blocked by a Wikipedia admin in return! I think if Wikipedia editing rights were stopped in the UK I would have to hang my coat up on the rack and call it a day (as unfortunate as that would be). 11WB (talk) 15:03, 11 August 2025 (UTC)[reply]
When counting users, do you only count registered users or also IPs and temporary accounts? What about very infrequent editors who might make one edit a year?
The medium article about the original legal challenge that's linked to from the blog post does include some discussion of why it's potentially classifiable under category 1. It looks pretty plausible that with how broadly "content recommender system" is defined, there's a bunch of stuff on wikipedia that could qualify:
a “content recommender system” means a system, used by the provider of a regulated user-to-user service in respect of the user-to-user part of that service, that uses algorithms which by means of machine learning or other techniques determines, or otherwise affects, the way in which regulated user-generated content of a user, whether alone or with other content, may be encountered by other users of the service.
"By means of machine learning or other techniques determines, or otherwise affects" is... broad. I bet that a bunch of moderation tools fall under that definition. A sufficiently hostile reading could get "Special:Random" under it. DLynch (talk) 15:03, 11 August 2025 (UTC)[reply]
It certainly uses an algorithm to pick content to show to a user! It's not a very complicated algorithm, but the law doesn't seem to define "algorithm" in any way, so I think we have to read it as its plain-language meaning. DLynch (talk) 21:46, 11 August 2025 (UTC)[reply]
What about the search bar, which presumably uses an "algorithm" to determine what order the results appear in? "Algorithm" is such a vague word that I'm not sure we'll be able to expunge all algorithms for UK readers. Toadspike[Talk]15:04, 12 August 2025 (UTC)[reply]
@Roxy the dog, in the event editing rights were revoked, I think it comes down to the individual editor to decide what they would do. VPN IPs have the disadvantage of being accessible by anyone, including to those who vandalise, as a result many are already blocked from Wikipedia. It would probably be preferential to cease editing in that scenario (hopefully this won't be the case!). 11WB (talk) 17:47, 11 August 2025 (UTC)[reply]
That seems silly. If I am editing through a VPN, signed in, why would an admin sanction an editor in good standing in these circumstances? - Roxy thedog17:53, 11 August 2025 (UTC)[reply]
I refer to the IP address being used already being previously blocked as VPNs are usable by anybody, including vandals. 11WB (talk) 17:55, 11 August 2025 (UTC)[reply]
I dont care about what random IP editors do, and my Q wasn't about them. Vandals are vandals if they use a VPN or if they dont.
I repeat, "If I am editing through a VPN, signed in, why would an admin sanction an editor in good standing in these circumstances?" Roxy thedog18:01, 11 August 2025 (UTC)[reply]
Apologies, I didn't explain it in the best way. The VPN you log into may be assigned an IP address that has previously been used by a vandal (as IP ranges are the same by service and per chosen country), meaning you'll find it unusable on Wikipedia. That is what I meant to say! 11WB (talk) 18:16, 11 August 2025 (UTC)[reply]
Are you saying that the wiki software would automatically block my VPN, without human intervention, despite my being logged in? Roxy thedog18:33, 11 August 2025 (UTC)[reply]
Most proxies (especially free ones) have been blocked due to abuse. Others are blocked preemptively (due to abuse). Most are blocked by humans, but don't rule out a bot doing it. These blocks are usually hardblocks, not anononly (due to abuse). You take your chances being able to edit on a proxy without IPBE. -- zzuuzz(talk)18:39, 11 August 2025 (UTC)[reply]
The way Zzuuzz explained it is the best way to articulate what I was attempting (quite badly) to explain! Thank you for this! 11WB (talk) 18:42, 11 August 2025 (UTC)[reply]
I temporarily turned on my Chrome extension proxy so I could screenshot the message that shows when you attempt to make any edits using a VPN or proxy IP. You'll see something like this (those are not my regular IP addresses) when attempting to edit on a VPN usually, and you'll find you cannot make any edits as a result. Hope this helps visualise it for you! 11WB (talk) 18:46, 11 August 2025 (UTC)[reply]
This seems overall like the best we really could have reasonably expected out of the courts at this stage... Personally I view it as a strategic victory, it sets us up really well for when/if the OSA does actually have significant deleterious consequences. Horse Eye's Back (talk) 17:44, 11 August 2025 (UTC)[reply]
As I said to someone somewhere else, I think it's clear that Wikipedia has won the argument. Subjecting us to Category 1 rules would be a proper absurdity, in addition to being probably unlawful. -- zzuuzz(talk)18:34, 11 August 2025 (UTC)[reply]
The court case was really about whether Ofcom is required by law to put us in Category 1. The court said it didn't have to put us there, or subject us to Cat 1 rules, and agreed there's a good chance doing so might be unlawful. It's not as bad as it sounds. -- zzuuzz(talk)18:46, 11 August 2025 (UTC)[reply]
This is no way a victory of any sort - any editors from the UK (and possibly even readers) now have a Sword of Damocles over their head, where Ofcom or the Government can decide to designate Wikimedia as a Category 1 website at any time, with all the consequences and loss of editor base that would result.Nigel Ish (talk) 18:54, 11 August 2025 (UTC)[reply]
Whilst this is true, it is mostly out of our control! Your Sword of Damocles is a very good metaphor. The saying I am applying to this is, 'what will be, will be'. 11WB (talk) 18:58, 11 August 2025 (UTC)[reply]
Isn't the case that they already had a Sword of Damocles over their head and the court simply declined to remove said sword although they did comment on what a lovely head it was and what a problem it would be for such a sword to fall? Horse Eye's Back (talk) 19:04, 11 August 2025 (UTC)[reply]
I agree. The judge doesn't want (and may not be allowed) to issue an injunction barring a (currently) counterfactual scenario, but considers WMF's arguments logically and perhaps legally correct. —Compassionate727(T·C)20:30, 11 August 2025 (UTC)[reply]
Were it to come to that (which it seems it hasn't yet), I am sure IPBE would be liberally granted to editors in the UK who are in good standing. I certainly would be willing to do that. SeraphimbladeTalk to me21:37, 11 August 2025 (UTC)[reply]
@Seraphimblade If it does come to that, I'll send you a talk page message! I am kidding of course, I genuinely don't think it'll go to that extreme, things often have a way of working out! TikTok is still available in the US as far as I'm aware. This whole thing has given me a strange sense of déjà vu to be honest... 11WB (talk) 22:52, 11 August 2025 (UTC)[reply]
Not gonna last long for US TikTok users. And by the way, YouTube is starting to verify every US viewer with AI based ID scan. We can't let WMF projects do the same for US readers. WMF might find a workaround to stop implementation of privacy invading policies. Ahri Boy (talk) 07:23, 13 August 2025 (UTC)[reply]
I thought youtube was only doing the ID verification for UK users, I had no idea youtube was doing ID verification for US users. At the moment the WMF is only at risk of having to verify the ID's of UK users. I'm not sure quite how the WMF is going to get around having to do ID checks for UK users given the UK government will 100% want Wikipedia to be a Category 1 website. Maurice Oly (talk) 14:16, 13 August 2025 (UTC)[reply]
There are different requirements in play. There's age verification (for accessing 'harmful' content) and 'verification' (for Cat 1 user-to-user 'empowerment'). The user empowerment part is the shadow on the horizon and has implications that affects everyone here, and probably Youtube as well - UK users must have the option to filter out any non-verified user and any of their content,[49] whatever that means. In our context that means no more warnings or block notices from those pesky unverified admins, no more unverified editing the same page to remove vandalism or POV. It soon gets into bonkers territory. WMF is talking about restricting access from the UK to get out of Cat 1. I don't blame them. -- zzuuzz(talk)17:06, 13 August 2025 (UTC)[reply]
So if an article contains two sentences, and the first sentence is written by an unverified user while the second sentence is written by a verified user, only the second sentence should be shown? And if a verified user corrects a typo in an unverified user's text, only the word with the corrected typo should be shown? Sounds wonderful. --Stefan2 (talk) 17:41, 13 August 2025 (UTC)[reply]
Oh yeah. This was presented to the court in magnificent detail (see #9). But also if a verified user adds vandalism, or a page advertising their services, or writes about how great their idea or ideology is, you'll need to be verified to touch the article or go near them to point out policies. Bonkers I tell you. -- zzuuzz(talk)18:13, 13 August 2025 (UTC)[reply]
You're quoting a politician talking about the Internet? Yes it makes no sense, but here's the law: "A duty to include [...] features which adult users may use or apply if they wish to filter out non-verified users [which means...] prevent non-verified users from interacting with content which that user generates, uploads or shares on the service, and reduce the likelihood of that user encountering content which non-verified users generate, upload or share." -- zzuuzz(talk)20:40, 13 August 2025 (UTC)[reply]
So only adult users can filter out content provided by unverified users, while children would be required to view that content? It sounds like a wonderful suggestion to show something to adults and something else to children, in case the things shown to children are dangerous for children.
If you send a DMCA takedown request, then I suppose you're unverified and so the material provided in the takedown request should have no effect on what verified UK users see? Of course you have to provide your name and address in the takedown request, but are those verified against some kind of ID? --Stefan2 (talk) 03:43, 14 August 2025 (UTC)[reply]
"a variety of signals" determine whether a user is over or under 18, and the option to "use a credit card or a government ID" if you are incorrectly flagged. Yeah, right. Most of the people would be incorrectly flagged anyway and have to surrender their government ID in the name of "protecting the kids" or "national security". While blocking VPNs is protecting Wikipedia vandalism, balance needs to be thought out as well as governments increasingly use their powers to muzzle free speech, and editors are rightly concerned if the government could get their hands on their IP address. ✠ SunDawn ✠Contact me!00:33, 14 August 2025 (UTC)[reply]
Should also add that sooner or later, US lawmakers will catch wind of the "Wikipedia users must undergo ID verification before they are allowed to edit" idea, and that'll mark the beginning of the end for this project. Some1 (talk) 02:46, 14 August 2025 (UTC)[reply]
Wikimedia very much does not need your ID. It only needs to verify that you are older than 18. Wikimedia's statements are very much making this a bigger deal than it is. Wikipedia could just ask you questions you should know after graduating upper secondary school, assuming the test is reliable enough. According to the UK government 68% of pupils finished upper secondary school.
As for content moderation, Wikimedia Commons has c:Commons:Not_safe_for_work (NSFW) which does part of what Wikimedia needs, but needs to go much further. Being verified to post content is basically what FlaggedRevs allready does. I would like to see a page accepting categories of images and articles that are not safe for children and I think NSFW is done that way too. Then Wikimedia just refuses to show articles and images in the categories of said list to kids and people that fail the adult test (the test of whether you finished upper secondary school). Snævar (talk) 18:04, 17 August 2025 (UTC)[reply]
That is exactly what we shouldn't be doing; Wikipedia is not censored and shouldn't be for anyone. And, how do we decide this stuff? Could we, for example, show the article about breast cancer to someone who failed your hypothetical test? I might not pull it up at work, but I still would not consider it inappropriate for a minor to see. SeraphimbladeTalk to me18:25, 17 August 2025 (UTC)[reply]
@Snævar: By your own admission, that would deprive 32% of British adults of access to Wikipedia because they weren't educated enough for your liking. Not to mention the fact that education systems are different between countries, and the fact that people could just look up the answers. No, to verify your age, Wikipedia would need to identify you, and that isn't happening. I'd blackout the site in the UK before agreeing to censor "inappropriate" content (what if conservatives decide that the transgender article isn't appropriate for kids?) and I am not giving the WMF my identity anytime soon. QuicoleJR (talk) 19:04, 17 August 2025 (UTC)[reply]
The issue doesn't seem to be NSFW content moderation, but rather the legislation treating Wikipedia as a social media site, and requiring the ability to screen out content from non-verified persons (which presumably means non-verified persons anywhere - not just from the UK), which appears to include article content as well as talk pages. This would break Wikipedia's editing model.Nigel Ish (talk) 19:19, 17 August 2025 (UTC)[reply]
Still, this would ruin the site, like you said. I'd support any form of protest, even the most extreme options we have, up to an indefinite UK blackout. QuicoleJR (talk) 19:43, 17 August 2025 (UTC)[reply]
As much as I don't want to see an indefinite UK blackout that might be the only way forward, we will just have to wait and see which category Wikipedia ends up in. Though I do fear Wikipedia will end up in category 1. Maurice Oly (talk) 21:25, 17 August 2025 (UTC)[reply]
I support a full blackout on all Wikimedia projects. This is the way of pressing on against the legislation. I may support full blackout in other countries if they follow UK's example. Ahri Boy (talk) 22:40, 17 August 2025 (UTC)[reply]
@Ahri Boy: A blackout affecting all projects would need to be agreed upon at Meta-Wiki. A proposal made on enwiki would only affect enwiki. That being said, I would support such a proposal, here or globally. QuicoleJR (talk) 23:15, 17 August 2025 (UTC)[reply]
@QuicoleJR The test of wether someone has graduated from a secondary school is an example. An example is just that, do not try to frame that as some major point in my argument when it is not. Feel free to find any better way of distinguishing adults from kids.
@Snævar: My point is that there is no question that can reliably separate people by ages, as some adults may not have learned certain things and kids can just Google the answers. It doesn't matter what the question is, this solution would not work. QuicoleJR (talk) 22:31, 18 August 2025 (UTC)[reply]
Tests in schools that allow you to go the internet exist where I live. Those tests are just harder versions of their non-internet versions. We also have tests that give you a Gymnasium (school) pass in a particular field, like German. It could be a TestDaF test or some other standard. We also have an gymnasium competition where people that are good at memorizing compete in questionnaire, so the school system needs to account for those too. The test would test your ability, not whether you can remember an answer from your book from class or some notes from a student google found. Let's say you just go to one of those tests (for exaample TestDaF) and they allow you to go to the internet, do you really think they would allow that if you could just cheese it?
This brings me to my original main point of the example, although I have not said what it is yet. WMF would be convincing an governmental entity that their test works. Since the test is based on the curriculum, a work of the ministry of education, if the WMF test fails it most likely criticizes the government itself. The ministry of education would need to update the curriculum and the WMF would use that work to improve their own test. Snævar (talk) 05:38, 25 August 2025 (UTC)[reply]
The test would test your ability, not whether you can remember an answer
How would tests of skill in history analysis, language arts, mathematics, etc... apply to age? How do you even test someone's skill at aging over the screen?The CNIL article you linked says every age test known at the time of writing is bad; of what you say exists, it gives nothing of the sort.
The CNIL has analysed several existing solutions for online age verification, checking whether they have the following properties: sufficiently reliable verification, complete coverage of the population and respect for the protection of individuals' data and privacy and their security.
The CNIL finds that there is currently no solution that satisfactorily meets these three requirements. It therefore calls on public authorities and stakeholders to develop new solutions, following the recommendations described above. The CNIL deems it urgent that more effective, reliable and privacy-friendly devices be proposed and regulated as soon as possible.
Even being blocked for using the username of someone notable does not require sending id. {{Uw-ublock-wellknown}}
If you choose to keep your current username, please send an email [...] including your real name and your Wikipedia username to receive instructions from our volunteer response team about account verification. Please do not send documentation without being requested to do so. (emphasis added)
Do not send unsolicited scans of your passport or driver's license to the volunteer response team. Instead, you should contact them to find out the best way to prove your identity. The best way will vary, but could be by using an email address on a domain name that belongs to you. (links in original; emphasis added) JuniperChill (talk) 21:14, 19 August 2025 (UTC)[reply]
As an example, you probably have been to an intersection with lights before. Well, those lights can break and then the police dictates the traffic. Even if the lights are active, what the police says goes. With law, you have a hierarchy. The constitution is at the top, then statuary law, then regulations, then any community or company rules. Those rules are probably there to make it hard for the police to come after you, but you still need to follow the law, even if Wikipedia's rules say otherwise. Also see my comments on a passport not being necessary. You have the option to not answer an age test/submit an ID and then you will have some access to Wikipedia, but not anything unsafe to a child, like porn or violence. Snævar (talk) 06:02, 25 August 2025 (UTC)[reply]
If anyone cares, I received the following response from the Department of Science, Innovation & Technology:
Thank you for your correspondence of 15 August to the then Secretary of State, the Rt Hon Peter Kyle MP regarding the implications of the Online Safety Act for Wikipedia and your concerns about preserving anonymous participation and access for UK users. I am replying as a member of the Ministerial Support Team. The government is committed to implementing the Online Safety Act and will continue to work closely with Ofcom which is under a duty to ensure that the measures in its Codes of Practice are proportionate and appropriate for different kinds and sizes of services. As a public body, Ofcom is also under a duty to act compatibly with the European Commission of Human Rights (ECHR). The government does not make an assessment of services which are to be designated as Category 1, as this is the role of Ofcom as the independent regulator under the Online Safety Act. Ofcom have requested information from services and will make its categorisation determination in the coming months. Once the register of categorised services has been established, Ofcom will publicly consult on its draft Codes of Practice for the additional duties on categorised services by early 2026. Ofcom have a duty to consult with those they consider to have relevant expertise regarding the ECHR rights to freedom of expression and privacy. The duties, such as user empowerment and user verification, will not apply to services until the relevant codes of practice are in force, following Parliamentary scrutiny. Yours sincerely, Ministerial Support Team
The following discussion has been closed. Please do not modify it.
Writing an open letter to "the High Court of Justice/Ofcom/UK government/etc." isn't going to go anywhere. You will see that royal marriages are subject to certain impediments that other marriages aren't because they were removed by the Marriage Acts as regards the rest of the population, which say they don't apply to royal marriages [51]. So, as Lord Pannick said 21 years ago, Charles and Camilla's Marriage Act ceremony was null and void. A High Court action was duly filed after Charles' accession in October 2022. The deep state immediately got to work, enlisting officials in the court office to propagate lies, the defendant and the officials did not copy the defence to the plaintiff and a crooked judge was found to deliver a secret five-paragraph judgment which made no reference to the evidence submitted by the plaintiff, only the lies secretly submitted by the defendant.
The fraud was particularised in a further High Court action filed this month. The defendants should have been served two weeks ago and the plaintiff notified, but there has been silence. There are twelve defendants, including the king, the attorney general, the secretary of state, the government lawyer who failed to serve the plaintiff and those officials who have been identified. Wikipedia editors will only be able to save the encyclopaedia by giving extensive news coverage to these events and ensuring they remain in the forefront in the weeks ahead. Otherwise, Wikipedia will be shut down and the c ase will remain in the court office forever. 80.41.151.12 (talk) 17:56, 23 August 2025 (UTC)[reply]
Back to the main topic for a third time. The memory of the events of Sunday, 31 August 28 years ago is still fresh (comments, [52], procession [53]). Harry will be returning to the UK on 8 September to continue the work. So let's give it all we've got. I propose the following banner for the main page:
Errors (rare) in Wikipedia are spotted and corrected in seconds by anyone. The UK government proposes to inhibit this process by designating Wikipedia as a Category One website under the Online Safety Act. It is also preventing Judges from hearing cases brought against it which it knows it will lose. Read the amazing judgment here.
Errors (rare) in Wikipedia are spotted and corrected in seconds by anyone. Not as often as you seem to think. I routinely catch introduced errors up to 24 hours old in my daily watchlist patrol, and ocassionally find older ones. I once found an error that had sat uncorrected for eight years (sad to say, I had introduced it myself). - Donald Albury16:25, 31 August 2025 (UTC)[reply]
It is also preventing Judges from hearing cases brought against it which it knows it will lose.
Nothing to do with parliamentary privilege. The case was filed on 11 August and the court office should have served the defendants and notified the plaintiff within five working days. Instead it has done nothing, effectively telling the plaintiff to pound sand. 80.44.78.34 (talk) 13:01, 1 September 2025 (UTC)[reply]
Discussing a blackout in the UK
There seems to be zero appetite for a blackout right now. Closing this sub thread to focus on other topics which aren't so clear-cut. QuicoleJR (talk) 11:57, 18 August 2025 (UTC)[reply]
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.
I think it's time we begin discussing a blackout in detail. The primary downside of such a thing would be its effect on our British users, but I think we can get around that (for now at least) by giving them IP block exemption so that they can use a VPN. We should also probably discuss timing (when and how long to do a blackout) and logistics (how we will do a blackout). Of course, to actually initiate one, we would need an RFC. Anyway, what are everyone's thoughts? QuicoleJR (talk) 23:21, 17 August 2025 (UTC)[reply]
I think that, at this point, enough people would oppose on the basis that the court basically said "if they really do try to apply Category 1 to Wikipedia, you'd have very good grounds to sue then", with hints of "and you'd probably win", that the RFC would fail. There are enough people who will oppose any blackout at all that you need a very credible threat to motivate enough other people to overcome them. Anomie⚔23:31, 17 August 2025 (UTC)[reply]
Maybe, but I'd like to at least get the discussion started, even if it isn't time for a blackout yet. I've been considering, as an alternative to starting a blackout now, potentially having an RFC to pre-approve a black out to activate if and when we get declared as a Category 1. I'd personally support doing it earlier, but this would also be a decent option if that can't get enough support. QuicoleJR (talk) 23:40, 17 August 2025 (UTC)[reply]
According to the article, the first categorization decisions from Ofcom are expected this summer, so if we decide to do a blackout or any form of "protest", it should ideally occur days or weeks before Sept 22. Some1 (talk) 23:37, 17 August 2025 (UTC)[reply]
Similar to Anomie, I would oppose action on the basis of the court decision. The court decision didn't actually change anything immediately, and in general I would prefer responding to executive and legislative action rather than judicial. If any action is taken in relation to Category 1, it should be very clearly scoped around the direct impacts of the designation's implications (and I suspect those details would be clearer closer to the time given some of the legislation seems vague), and would need to be worth the risk of it being ineffective and setting a standard that community complaints can be ignored. CMD (talk) 00:56, 18 August 2025 (UTC)[reply]
Now is not the time for a UK blackout discussion, as at this point we don't know wether Wikipedia will be in category 1 or not. Once confirmed that Wikipedia is in category 1 and all legal options have run dry them we should start a discussion on a UK blackout. Maurice Oly (talk) 01:06, 18 August 2025 (UTC)[reply]
It looked more to me like the court was saying "It's premature to decide this right now, but categorizing Wikipedia that way would be a pretty questionable decision and we'd be very skeptical of that" than "Sure, go ahead and do that." So, I think at this point we should wait and see what happens; hopefully Ofcom will take the hint. If they do, great. If not, we can discuss next steps once something has actually happened rather than "might happen". SeraphimbladeTalk to me06:18, 18 August 2025 (UTC)[reply]
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.
Community Tech team is looking for idea/feedback regarding watchlist filtering
I think the way to keep updated would be to watchlist to the Community Tech Wishlist updates page. @JWheeler-WMF should be able to give more specific advice on that (I actually wonder if it would be too much work to convert the page to use the Newsletter extension?) Sohom (talk) 00:26, 8 September 2025 (UTC)[reply]
Trial: Replacing our CAPTCHA with a new bot detection service
Hello, we are the Wikimedia Foundation Product Safety and Integrity team, a team dedicated to the security and safety of users of the Wikimedia wikis. We have been integrating a new bot detection service, with the goal of replacing our current CAPTCHA with something that can hold up better against modern AI bots and other automated activity. In the coming weeks, we would start a trial here on English Wikipedia. We will be monitoring its deployment beforehand as we roll this out across several trial wikis, to make sure it is stable and performant.
This service will start by protecting the account creation page (Special:CreateAccount). We may extend it later to protect editing or other sensitive actions.
In this trial, we’ll be looking to see how well the new service does at stopping or slowing bot-driven activity, and how well it helps real humans more easily use Wikipedia.
Why our CAPTCHA needs replacement
Wikipedia needs strong tools to defend itself from malicious automated (including AI-driven) activity. The CAPTCHA we use today hails from an earlier era of the web. It has been aging poorly for some time, and is especially unsuited for the new era of AI. We know it also annoys many of our human users, and likely shuts some of them out.
We’ll be testing out replacing our current CAPTCHA with hCaptcha, a third-party service specializing in bot detection. They have a particular focus on privacy-sensitive customers, such as Signal and many other internet services, that make them a good fit for the Wikimedia wikis.
We want to be upfront that this trial will involve us integrating wikis directly with a third-party proprietary service. This is new for Wikimedia, and something we, as the Foundation, don’t take lightly. However, it’s not feasible for us to build a service ourselves that can keep the projects safe in this era. Organizations that are dedicated to running bot detection services have dramatically more expertise and resources to offer than us – especially the ongoing work of keeping up with the cat-and-mouse game of bot detection and evasion as it changes each year.
We’ve always operated Wikipedia in the most privacy-sensitive way we can, which has helped us avoid the kind of casual information sharing and online tracking that has become so common to the modern web. To maintain this commitment, we’ve set it up so that hCaptcha cannot see raw IP addresses of visitors, nor will it be able to see what specific actions are being taken or what URLs are being accessed. Any information about visiting devices that does get collected as part of bot detection will be discarded by hCaptcha within 10 days.
Our Legal department has approved such implementation of hCaptcha and confirmed that it is in line with our Privacy policy and Terms of Use.
hCaptcha is already live on test2wiki, where you can test it out today. If you do test it out manually, bear in mind that you are unlikely to actually see a CAPTCHA-style puzzle due to how hCaptcha works (see below).
How the bot detection trial will work
Unlike our current CAPTCHA, with this new approach, the service will work primarily invisibly. Most visitors (around 99.9%) will never see a puzzle to solve at all.
For those visitors that do see a puzzle, they will need to complete it to create an account. These are visual puzzles, but for users with sight issues or other accessibility needs, a text-based puzzle is available that can be completed using only a keyboard.
The service will send back a “risk score” that is their confidence level in the account having been made by an inauthentic user. This risk score will not be public, but will be saved privately to enable analysis and responses to potentially bot-driven activity by WMF and volunteer investigators.
Visitor IP addresses will not be sent to the service – all requests to the service go through a proxy we host ourselves that drops raw IPs and uses hashed versions instead.
The code we load from the service will be sandboxed so that it cannot see or interfere with the page context of the user session, and so that the service can’t see the specific URL of the page.
During the trial we’ll be analyzing how bots are engaging with the wikis, making sure hCaptcha isn’t making it unexpectedly harder to use Wikipedia, and identifying any further privacy and security measures we can take. We will review this analysis, and will engage publicly with the communities about how the trial went, before we make decisions on expanding the use of hCaptcha to replace our current CAPTCHA.
See our project page for more technical details and more information about risks and how we are mitigating them. See also our Diff post to read an expanded version of this announcement. Subscribe to our newsletter to stay in touch.
Thanks to the team for your work on this – I have really appreciated the thoughtfulness with which you've approached this deployment. I particularly appreciate the trial to collect data that informs technical decisionmaking going forward: I know that we're not yet confident about just what kinds or volume of abuse will be best addressed through this new service vs. other technical solutions vs. existing infrastructure, but I fully support the experimentation that it will take to gather the data to answer this question. Best, KevinL (aka L235·t·c) 15:02, 4 September 2025 (UTC)[reply]
I hope the trial is successful (just about anything must be better than CAPTCHA) but if it is not please accept that it has been unsuccessful. Far too many times I have seen things being trialled in Wikipedia and then the trial being lauded as a success (my guess is because of the sunken costs fallacy) when it is not. Phil Bridger (talk) 16:14, 4 September 2025 (UTC)[reply]
Will the risk score be available to checkusers? Similarly, will account creation attempts that were rejected due to hCaptcha feedback be logged in the CU database? RoySmith(talk)16:47, 4 September 2025 (UTC)[reply]
@RoySmith While we won't get into great detail here about exactly what checkusers will see, we were a little more explicit about incorporating these signals into investigation tools in our blog post: "We are also planning to incorporate the bot detection data we get from this into the tools we provide to our trusted volunteer investigators to respond to sockpuppeting and other inauthentic activity." We'll soon have a product page going up with some public details. EMill-WMF (talk) 18:01, 4 September 2025 (UTC)[reply]
The blog post says that the service drops raw IPs and uses hashed versions instead, but if the hash function is deterministic, one can easily create rainbow tables mapping each IP to a unique hash. Of course, if by hash you mean a randomly generated UUID, then this won't be a problem. I would say that some IPs are more problematic than others (proxies, botnets, etc.), so it might be worthwhile to do some local processing with, say, the Spur databases.
This is a massive change and would likely require site-wide consensus (listed at WP:CENT and everything). Introducing nonfree code onto Wikimedia sites can be seen as even more drastic than adding AI summaries to articles, especially when that code is obfuscated and performs deep fingerprinting of the browser (or device, for Wikipedia's mobile apps), including canvas fingerprinting.
Using a deliberately exaggerated configuration (navigator.webdriver === true, Chrome on Windows 10, user agent claims Firefox on Windows 10, DevTools set to emulate a mobile device), I managed to get an hCaptcha to appear and even got one of their text captchas. I had to solve 3 of these:
Within this data string 4355 * 8591 9489 + 7025 - 1616, retrieve the penultimate set of numerals
Find the center collection of numbers from the data shown: 3186 ... 5233 / 6930 * 2367 ... 2090
Point out the second group of digits in the provided set: 1821 9018 | 2321 - 7393 % 4377 ^ 2352
This was surprising, as I thought it would ask questions like "What is the colour when you look up on a sunny morning and there's no roof?", but it's all numbers. I'm pretty sure I got the first one wrong (I typed 81 when I was supposed to type 7025), but it still accepted my answer (despite the navigator.webdriver value ¯\_(ツ)_/¯).
@EMill-WMF, (and @Chaotic Enby) and I had a conversation about the fingerprinting aspect of the scripts, the long and short is that iff hCAPTCHA keeps the promises/guarantees they claim to provide, the risk of device re-identification by hCAPTCHA is low even through highly invasive techniques is low because they do not have access to surrounding information that identifies you as a contributor to Wikipedia. There is a seperate conversation to be had about the non-free nature of the code, but I think that a necessary tradeoff within this context. Sohom (talk) 16:28, 7 September 2025 (UTC)[reply]
Thanks for the ping. One of the key aspects is Any information about visiting devices that does get collected as part of bot detection will be discarded by hCaptcha within 10 days, which hasn't been explicitly codified in the contract with hCaptcha, and is currently more of a "verbal agreement" as far as I understand it. If this is followed through, there is less worry to be had, but codifying it could be a helpful step in terms of trust.Beyond that, I am sad to see that the possibility of running the hCaptcha model locally (which was mentioned during the conversation) hasn't been elaborated on in this announcement.Chaotic Enby (talk · contribs) 21:33, 7 September 2025 (UTC)[reply]
"hasn't been explicitly codified in the contract with hCaptcha" – If this is true then any kind of hCaptcha rollout is a non-starter, and it's concerning that this hasn't been communicated clearly in the original post or at mw.
Yeah, that's not acceptable and the initial communication is bad and misleading. The opening message here stated that the data "will be discarded by hCaptcha within 10 days"immediately before a sentence starting with "Our Legal department has approved such implementation of hCaptcha ..." with no mention of 180 days.
I'm sure the WMF and involved parties are trying to communicate openly, but the statements given so far give a false impression of what the reality of the agreements in place are. Device fingerprinting data is sensitive, and the difference between retaining sensitive data for ten days vs half a year is massive. A "verbal agreement" with hCaptcha is inadequate to ensure such sensitive user data is properly protected, and if WMF's legal team hasn't advised the same then I'd be very surprised. fifteen thousand two hundred twenty four (talk) 03:11, 9 September 2025 (UTC)[reply]
To my understanding of how this is came to be is that folks at hCAPTCHA have told engineers at the WMF that the way their current systems are architected, their systems only store customer data for 10 days for everyone. It is my understanding that WMF staff did not push for this 10 day restriction to be codified in the contract for specifically the trial period since there was a understanding the systems handling such data would not change significantly during that time period. A point to note is that, if the WMF terminates their contract with hCAPTCHA, per their ToS, WMF can ask for all the data to be deleted and destroyed. I'm not sure if this arrangement will continue going forward, after the trial, but my understanding is that is up for debate. (For what it's worth, I've lobbied for the 10-day data retention policy to be codified in the contract in conversation because of similar concerns to the ones you raise) Sohom (talk) 03:57, 9 September 2025 (UTC)[reply]
Thank you for cluing me into the backstory, my feelings remain unchanged. The WMF really shouldn't play fast and loose with user data like this. The data is sensitive and real, trial or not. The fact that this concern was raised previously and went unresolved and uncommunicated is disappointing and concerning. fifteen thousand two hundred twenty four (talk) 04:13, 9 September 2025 (UTC)[reply]
I am not especially worried either about hCaptcha keeping the user data from the trial. My bigger concern is that the contract for the trial might be used as a template for a future rollout, and will not address the 10 day restriction explicitly. This is compounded by the fact that this legal aspect wasn't mentioned in either announcement, meaning that the WMF might not be especially careful with codifying it. As Sohom said, the current data retention systems aren't a cause of worry, but third-party companies can easily change their architecture without giving us time to renegotiate the terms of the contract, if safeguards aren't codified in writing. Chaotic Enby (talk · contribs) 13:10, 9 September 2025 (UTC)[reply]
"the current data retention systems aren't a cause of worry" – This is also based on hCaptcha saying "trust us". I'm assuming the WMF was not given access to perform an audit themselves, so it's just the word of a for-profit company that tracks users at scale (to prevent abuse of course) that they only retain data for 10 days despite their ToS having a carve out for 180 days. A layperson should be skeptical, a lawyer should be scowling.
The fact that this is a trial is no different than if it is a full rollout when it comes to protecting user data, the data is the same and is just as sensitive as it will be during a full rollout, and the trial is not limited to ten days, so there is no strong legal barrier to hCaptcha retaining data for longer than what has been described in these announcements.
I think the difference between "a commitment by the vendor" and "a legal commitment by the vendor" is not zero, but not beyond the ability of WMF to judge, alongside meaningful other tradeoffs that forcing a legal commitment now for this trial could bring in timeline, cost, etc. Yes, we should make our position as a community known (that it would be much better to have a legal commitment). But in my view, this is not a blocker. Best, KevinL (aka L235·t·c) 23:53, 9 September 2025 (UTC)[reply]
A reasonable view. I think the community should be afforded the opportunity to make that judgement since it directly impacts the privacy of individual users, however due to lacking communication from the WMF it seems that the community is going to go mostly unawares which is possibly the more serious issue here. fifteen thousand two hundred twenty four (talk) 00:04, 10 September 2025 (UTC)[reply]
the part about using aggregate/de-identified data for “any purpose” also seems pretty vague and makes me nervous as well. There’s no industry standard term for what that means and in a lot of places and cases it’s not anonymized such that it can’t be de-anonymized. I have no idea whether this company does or doesn’t handle this well, but it’s all on faith. Driftingdrifting (talk) 04:11, 9 September 2025 (UTC)[reply]
hCaptcha's puzzles are image labeling tasks. The makers of hCaptcha also sell image labeling services to other companies - the labor involved is the labor of the users solving these hCaptcha tasks. Would Wikipedia's users be part of this labor pool? What sort of compensation would Wikimedia be getting for selling this labor? MrOllie (talk) 15:00, 7 September 2025 (UTC)[reply]
@MrOllie, citation needed, to my understanding, the CAPTCHA's served at Wikimedia are math puzzles and "move this shape here" which are typically more about mouse movement than image labelling. Sohom (talk) 15:07, 7 September 2025 (UTC)[reply]
No, if you get served a challenge, it will probably be an image labelling task (I tested it), though you can switch to a text-based "Accessibility Challenge" (see comment above). hCaptcha apparently still sells their labelling services despite them ending their payment program. Although, based on the fact that Enterprise users couldn't earn rewards for solves at all originally, I'd wager that hCaptcha simply does not send data labelling tasks to Enterprise users. I don't know where you got "math puzzles" from, although hCaptcha does sometimes use "move this shape here" puzzles. OutsideNormality (talk) 15:18, 7 September 2025 (UTC)[reply]
I was involved in testing some of this before this post was made, the CAPTCHA challenges that were served to me were almost always "move this shape here" and math/digit-based challenges in text mode. Sohom (talk) 15:45, 7 September 2025 (UTC)[reply]
For (non-public information reasons) hCAPTCHA's docs seem to be somewhat outdated, which is why I chose to ignore them (that's on me) :) Sohom (talk) 15:58, 7 September 2025 (UTC)[reply]
Going off into the weeds a bit, it would be interesting if we could customize this into some wiki-specific task, say "Select all the images containing a misspelled word", and showing them real screenshot fragments with words some automated process suspects might be misspelled. In addition to the bot-filtering function, it would also get some useful work done for the encyclopedia. RoySmith(talk)15:58, 7 September 2025 (UTC)[reply]
A big change from our current CAPTCHA, where every use of it involves solving a challenge, is that hCaptcha can work invisibly, and we've configured it so that the challenges are supposed to be quite rare (0.1% or less of the time). So, while we certainly do still have to care about them from a usability and accessibility perspective, they likely won't be at a volume that would be useful for deriving secondary value. EMill-WMF (talk) 19:33, 7 September 2025 (UTC)[reply]
The focus on IP and a cookie subset in the privacy discussions feels a little disingenuous. While I appreciate the effort to obfuscate IP addresses (assuming that hash is appropriately salted, otherwise it’s a nearly useless gesture), I’m a lot more concerned about the “thousands” of signals they are using to uniquely identify my browser. JavaScript + HTML5 include some very invasive, privacy violating features that it sounds like are now being shared with a third party? I’m more worried about that than IP tracking. Driftingdrifting (talk) 04:33, 9 September 2025 (UTC)[reply]
There is no meaningful technical way to isolate/elide those browser-based signals. Any attempt to do that would be not sustainable in the long term as a solution. Sohom (talk) 12:56, 9 September 2025 (UTC)[reply]
That's very true, but for me that feels more like a reason to either not do this or to be absolutely rock-solid in the privacy agreement with this company. I'm less than convinced this is impossible for them to do themselves if they wanted to, where WMF makes tech investments continues to baffle me; this seems like it should be up there in terms of priorities and it isn't rocket-science. Driftingdrifting (talk) 14:57, 9 September 2025 (UTC)[reply]
As the latest human authentication methods are based on behavioural analysis, large training datasets are invaluable for improvements. Even if the WMF were to turn on human authentication tests for everyone logging in, I think companies dominant in the field are able to collect much more data and have an ongoing revenue stream to support continually improving their models. To be able to match countermeasures that are also continuously updated, the WMF would need a business model that supported collecting a lot more data, and that would likely mean spinning up a for-profit subsidiary and attaining significant market share. isaacl (talk) 17:29, 9 September 2025 (UTC)[reply]
I'm less than convinced this is impossible for them to do themselves if they wanted to. My understanding is that filtering bot traffic is a game of whack-a-mole that would be hard to do in-house. Using a third party service that specializes in it and is used on multiple major websites makes those tools better than what we could develop. –Novem Linguae (talk) 20:34, 9 September 2025 (UTC)[reply]
I don't know much about current bot detection technologies, so I can't speak for whether hCaptcha is the right one or not. But I do agree with the idea that we can't be experts at everything and shouldn't try. There's a ton of things that need to get done that can only be done in-house. I'm sure we could all reel off a list of a dozen "must have" features or bug fixes that we want done in the MediaWiki code base by yesterday. Every person-hour spent working on bot detection is a person-hour that can't be spent on those things.
This is the kind of thing that benefits from a broad customer base. Let's say our bot detection vendor has (to pick an absurdly low number) 100 customers. If some new bot attack springs up and is launched against one of their other customers, the vendor starts working on analyzing it and implementing counter-measures. By the time the bot master gets around to launching it at us, the fix may already be in and we're protected. RoySmith(talk)20:54, 9 September 2025 (UTC)[reply]
Thanks to everyone who commented here. I wanted to just acknowledge the discussion here about privacy and data, including the strength of the guarantees we have around data retention. There will be an inflection point after the trial where we will be reviewing what would be needed -- on privacy, but also on accessibility, performance, volume, and cost -- from our implementation (and our agreement with hCaptcha) to support potential expansion if the trial is as promising as we hope it will be. It's helpful to have the community's perspective here for us to refer to when we reach that point, and you'll be hearing more from us again at that point as well. EMill-WMF (talk) 21:05, 17 September 2025 (UTC)[reply]
Excessive, obnoxious fundraising
I understand that I'm not the first user to make this complaint, but I'm astonished that the Foundation still feels the need to run extreme, screen-filling pleas for donations. I'm not sure how worldwide or coordinated these campaigns are across different WMF chapters, but (at least in Australia) Wikimedia places giant banners begging for donations on the Wikipedia homepage when logged in, and fills the entire screen with a similar plea for money when one even clicks on an article if they aren't logged in! Is this not just a bit excessive? The Foundation's article on this wiki has a whole section titled Excessive spending and fundraising and asserts that its budget has a "significant surplus" and that it's in ownership of "vast money reserves". Why on Earth does the WFM feel the need to use this Wiki to grab at users' wallets at every opportunity? Loytra (talk) 08:08, 7 September 2025 (UTC)[reply]
The short answer is that anything "obnoxious" the WMF does in donation banners has been A/B tested to work better than not doing it, getting more donations. Overall year over year, I think traffic to Wikipedia is declining because search engines and AI are using our content, so the overall strategic situation isn't great. The "significant surplus" and that it's in ownership of "vast money reserves" part is probably talking about the Wikimedia Endowment, which works like a retirement account but for organizations. The idea behind retirement accounts is to build up a huge reserve of money, invest it, then live off the interest, making it self-sustaining. So just because the WMF has a ton of money doesn't mean they should cancel all fundraising and spend the endowment down to $0. They are in my opinion prudently trying to build up the endownment so that it can generate enough interest to fund things in perpetuity. Hope that explanation makes sense. –Novem Linguae (talk) 09:56, 7 September 2025 (UTC)[reply]
Also this from the August 2025 Readers Newsletter: Wikipedia's pageviews have either stayed flat or declined in the past few years, while global internet usage has increased. This means that the percentage of internet users that find, use, and appreciate Wikipedia is decreasing significantly.Some1 (talk) 17:41, 7 September 2025 (UTC)[reply]
What on earth is that page, key takeaways, the tiny actual article, and then an FAQ section all identical. Columbia business school? Anyway, if anyone actually knows what is meant by articles whose content resembles what ChatGPT would generate (generalist articles?), it would be interesting to know. CMD (talk) 02:31, 8 September 2025 (UTC)[reply]
@Chipmunkdavis, Sections 2.1 and 2.2 in the paper explain this. They looked at articles created from 2021-12 to 2023-11 (to straddle the launch of ChatGPT). They cross reference that against the top 1000 most viewed articles per month to get 2206 articles created recently with high pageviews. Then they prompt Chat GPT 3.5 turbo with each of those articles:
"You are an assistant whose task is to write an encyclopedic article for a given topic chosen by the user, similar to those found on Wikipedia. Generate an encyclopedic article in English with title "[title of actual Wikipedia page]"
They compute a similarity score between the actual text of the Wikipedia article and the text Chat GPT generates. And their analysis goes on from there to say that articles that had high similarity experienced a drop in pageviews. But from figure 2(a) there on page 3 of the paper, the drop looks kind of tiny. And there's a bigger increase in pageviews to dissimilar articles.
As someone who works on this data, I'd have to do a lot of work to validate that what they found actually suggests what they say. Because there are just too many moving parts to make this clean of a conclusion. But it's certainly thought provoking. Milimetric (WMF) (talk) 13:47, 11 September 2025 (UTC)[reply]
Thanks. Agree with the concerns, and I'm not sure bucketing all articles as a binary similar/dissimilar is sensible at any rate. The data also suggests overall page views went up after ChatGPT's launch, which is not in my priors. I wonder which articles are more similar, my instinct is that it is the niche ones where Wikipedia is the primary accessible source. CMD (talk) 15:07, 11 September 2025 (UTC)[reply]
Just out of curiosity and planning(cause I kinda want to do something regarding it) where can I see a full list of newly "born", incubated and shut down(both ones that didn't get out of Incubator and ones that did) Wikimedia projects? Brickguy276 (talk) 20:05, 8 September 2025 (UTC)[reply]
Is there anyone at the foundation who can confirm that this attempt at contact actually happened? Or is the Nypost just making it up (as usual) Trade (talk) 22:17, 9 September 2025 (UTC)[reply]
Based on the nypost article and looking at the AFD, this nypost article seems to be a knee jerk to fan the flames of their dislike of liberal bias on WP. The AFD closed almost by snow to keep and they apparently did not look at that, only that it got nominated. It's a puff piece we should not worry about. Masem (t) 22:37, 9 September 2025 (UTC)[reply]
There should be a place where if you're an admin, you can sign up to be on the list of talking heads who give comments to the newspaper. The news will always quote someone from the WMF awkwardly saying "we can't comment on that", which is boring, when they could instead have some monument of outspoken and brilliantly erudite witticism, guaranteed to impress and edify, from a brain-genius, of which I can easily name several, including of course myself. jp×g🗯️09:17, 17 September 2025 (UTC)[reply]
I think this would be a bad idea. You definitely can't speak for me - we don't always agree afterall - and neither of us can speak for the WMF. But if there was that list then we would suddenly be official in ways we shouldn't be. There is COMCOM but I'm not sure how active that is these days nor am I sure what their turnaround is - they might not be able to get a comment out quickly enough for a New York Post deadline. Now, I do think there could be utility in a project page listing people who are willing to speak to reporters (and what they could speak about), but that feels like the extent such things could go. Best, Barkeep49 (talk) 14:43, 17 September 2025 (UTC)[reply]
Noting that I've passed on a link to this thread to a member of the WMF Communications team. I am on the committee Barkeep49 mentions above, but I also know that Comms does look to add to the ranks of people who are willing to participate in responding to media questions. Risker (talk) 16:02, 17 September 2025 (UTC)[reply]
Our proposal in a nutshell: Temporary accounts offer improved privacy for users editing without an account and improved ways to communicate with them. They have been successfully rolled out on 1046 wikis, including most large Wikipedias. English Wikipedia has defined the criteria for Temporary Accounts IP Viewer (TAIV) right and granted it to 100+ users. We plan to launch temporary accounts on enwiki on October 7th. If you know of any tools, bots, gadgets, etc. using data about IP addresses or being available for logged-out users, please help test that they work as expected and/or help update these.
Hello, from the Product Safety and Integrity team! We would like to continue the discussions about launching temporary accounts on English Wikipedia. Temporary accounts are relevant to logged-out editors, whom this feature is designed to protect, but they are also very relevant to the community. Anyone who reverts edits, blocks users, or otherwise interacts with logged-out editors as part of keeping the wikis safe and accurate will feel the impact of this change.
Temporary accounts have been successfully deployed on almost all wikis now (1046 to be precise!), including most large Wikipedias. In collaboration with stewards and other users with extended rights, we have been able to address a lot of use cases to make sure that community members experience minimal disruption to their workflows. We have built a host of supporting features like IP Info, Autoreveal, IPContributions, Global Contributions, User Info etc. to ensure adequate support.
With the above information in mind, we think everything is in good shape for deploying temporary accounts to English Wikipedia in about a month, preferably October 7th. We see that your community has decided on the threshold for non-admins to access temporary accounts IP addresses, and there are currently over 100 non-admin temporary account IP viewers (TAIVs).
Project background
The wikis should be safe to edit for all editors irrespective of whether they are logged in or not. Temporary accounts allow people to continue editing the wikis without creating an account, while avoiding publicly tying their edits to their IP address. We believe this is in the best interest of logged-out editors, who make valuable contributions to the wikis and who may later create accounts and grow the community of editors, admins, and other roles. Even though the wikis do warn logged-out editors that their IP address will be associated with their edit, many people may not understand what an IP address is, or that it could be used to connect them to other information about them in ways they might not expect.
Additionally, our moderation software and tools rely too heavily on network origin (IP addresses) to identify users and patterns of activity, especially as IP addresses themselves are becoming less stable as identifiers. Temporary accounts allow for more precise interactions with logged-out editors, including more precise blocks, and can help limit how often we unintentionally end up blocking good-faith users who use the same IP addresses as bad-faith users. Another benefit of temporary accounts is the ability to talk to these logged out editors even if their IP address changes. They will be able to receive notifications such as mentions.
How do temporary accounts work?
When a logged-out user completes an edit or a logged action for the first time, a cookie will be set in this user's browser and a temporary account tied with this cookie will be automatically created for them. This account's name will follow the pattern: ~2025-12345-67 (a tilde, year of creation, a number split into units of 5). All subsequent actions by the temporary account user will be attributed to this username. The cookie will expire 90 days after its creation. As long as it exists, all edits made from this device will be attributed to this temporary account. It will be the same account even if the IP address changes, unless the user clears their cookies or uses a different device or web browser. A record of the IP address used at the time of each edit will be stored for 90 days after the edit. Users with Temporary Accounts IP viewer right (TAIV) will be able to see the underlying IP addresses.
Impact for different editors
For logged-out editors
This increases privacy: currently, if you do not use a registered account to edit, then everybody can see the IP address for the edits you made, even after 90 days. That will no longer be possible on this wiki.
If you use a temporary account to edit from different locations in the last 90 days (for example at home and at a coffee shop), the edit history and the IP addresses for all those locations will now be recorded together, for the same temporary account. Users who meet the relevant requirements will be able to view this data. If this creates any personal security concerns for you, please contact talktohumanrightswikimedia.org for advice.
For community members interacting with logged-out editors
A temporary account is uniquely linked to a device. In comparison, an IP address can be shared with different devices and people (for example, different people at school or at work might have the same IP address).
Compared to the current situation, it will be safer to assume that a temporary user's talk page belongs to only one person, and messages left there will be read by them. As you can see in the screenshot, temporary account users will receive notifications. It will also be possible to thank them for their edits, ping them in discussions, and invite them to get more involved in the community.
User Info cardWe have recently released the User Info card feature on all wikis. It displays data related to a user account when you tap or click on the "user avatar" icon button next to a username. We want it to help community members get information about other users. The feature also works with temporary accounts. It's possible to enable it in Global Preferences. Look for the heading "Advanced options".
For users who use IP address data to moderate and maintain the wiki
For patrollers who track persistent abusers, investigate violations of policies, etc.: Users who meet the requirements will be able to reveal temporary users' IP addresses and all contributions made by temporary accounts from a specific IP address or range (Special:IPContributions). They will also have access to useful information about the IP addresses thanks to the IP Info feature. Many other pieces of software have been built or adjusted to work with temporary accounts, including AbuseFilter, global blocks, Global Contributions, User Info, and more.
For admins blocking logged-out editors:
It will be possible to block many abusers by just blocking their temporary accounts. A blocked person won't be able to create new temporary accounts quickly if the admin selects the autoblock option.
It will still be possible to block an IP address or IP range.
Temporary accounts will not be retroactively applied to contributions made before the deployment. On Special:Contributions, you will be able to see existing IP user contributions, but not new contributions made by temporary accounts on that IP address. Instead, you should use Special:IPContributions for this.
See our page Access to IP for more information about the related policies, features, and recommended practices.
Our ask of you, and next steps
If you know of any tools, bots, gadgets etc. using data about IP addresses or being available for logged-out users, you may want to test if they work on testwiki or test2wiki. If you are a volunteer developer, read the documentation for developers, and in particular, the section on how your code might need to be updated. If you know of tools, bots or gadgets that have not yet been updated and you don’t know of anyone who can update these, please reach out to us.
If you want to test the temporary account experience, for example just to check what it feels like, go to testwiki or test2wiki and edit without logging in.
Tell us if you know of any difficulties that need to be addressed. We will try to help, and if we are not able, we will consider the available options.
To learn more about the project, check out our FAQ – you will find many useful answers there. You may also look at the updates and subscribe to our new newsletter. If you'd like to talk to us off-wiki, you will find me on Discord and Telegram.
We would like to thank stewards, checkusers, global sysops, technical community members, enwiki functionaries and everybody else who has contributed their time and effort to this project. Thank you for helping us get here. NKohli (WMF) and SGrabarczuk (WMF) (talk) 11:38, 11 September 2025 (UTC)[reply]
Discussion
It's still not clear to me what would be allowed to discuss publicly.
Temp account X seems the same as Temp account Y
Temp account X seems the same as older IP editor Y
We should rangeblock IP adresses X to stop temp account A, B and C
Temp account X is a school account for school X / a government account for department Y / ...
...
Should all these only be had "behind closed doors" somewhere, or are these allowed in the same circumstances as we would discuss them now (SPI, ANI, ...)? Fram (talk) 11:53, 11 September 2025 (UTC)[reply]
Thanks @Fram, first we wanted to emphasize, to make it just clear to everybody around, that temp accounts are just a different paradigm; they don't match 1:1 with IPs, and in some cases it doesn't make sense or there's no need to link them with IPs 1:1.
These restrictions only apply when you (1) use data from the IP reveal tool to make the link and (2) discuss publicly. All of the above can be discussed in a private venue where only TAIV users can see the information. Also if the link is only behavioral, then any user, including those who have TAIV, can make the link publicly. But if you do have TAIV and talk publicly, there may be an implication that you used the tool to make the link. CUs often get around this by declining to comment about IPs if they have run CU on a user, so they can avoid the implication that they linked the IP and user together using CU data.
Now to your questions:
This is OK if necessary for anti-abuse purposes, and you can even say "Temporary account X is using the same IP address as temporary account Y" as long as you don't mention the specific IP.
Not publicly, unless the link is made purely through behavioral evidence (i.e. edits).
Not publicly. You can, however, say "Please block the common IP ranges used by temporary accounts A, B, and C" publicly where the admin could use IP reveal to find which range you were talking about. Another option for non-admin TAIVs is to say "Please block this IP due to abuse from temp accounts" (without naming the accounts).
If you are using access to IP addresses to get this information, then probably not okay. If using edits, then okay.
Finally, a very important note just for context: on other projects, including large Wikipedias, we have seen a significant decline in IP blocks, indicating that temporary account blocks are often effective remedies for one-off abuse. Even if we agree that English Wikipedia is unique and whatnot, there is a pattern and hopefully discussions about blocking IPs won't be that frequent (phab:T395134#11120266).
Thanks. So access to IP adresses is treated as CU access basically? That seems like a severe step backwards in dealing with vandalism, sockpuppetry, LTAs, ... Curs both ways of course, we now also exonerate people with things like "the IPs used by that vandal located all in country X, but this new IP comes from country Y, making it unlikely to be a sock. This happens in standard ANI discussions and the like, not requiring any CU access, but will no longer be possible for most editors.
Your "Finally, a very important note just for context: on other projects, including large Wikipedias, we have seen a significant decline in IP blocks, indicating that temporary account blocks are often effective" seems like a non-existent advantage. We had many "single" IP blocks, these will be changed to "single" TA blocksn this is not an advantage or disadvantage of TAs. The issues are rarely with the simple straightforward cases.
A very simple example: when I look at the revision history of [54] I immediately see that the last three IP edits are made by the same person, using two IP adresses. If we are lucky, in the future, this would be one temp account. If we aren't lucky, then these would be two completely unrelated temp accounts.
Or take this edit history for a school. Since March, I see different IPs in the 120.22 range; it seems likely that this is either the school or the village or city, so no socking, unless these 4 were all from an IP provider in, say, France, in which case it's much more likely to be the same person in each case. From now on, no more means to raise such issues or notice them if you are not of the few (and if you are, you can't raise it publicly).
Or to make it more concrete still: we have this current ANI discussion where a non-admin raises an issue related to completely disparate IP adresses: "a certain editor who has been editing over several months from various IPs, all geolocating first to South Korea, then more recently to Japan. " If said IP disables or removes cookies, there is no way that most of our editors would be able to adequately see or raise such issues, they would just have to say "there is a range of temp accounts, no idea if there is any connection between them".
@Fram With respect to Your "Finally, a very important note just for context: on other projects, including large Wikipedias, we have seen a significant decline in IP blocks, indicating that temporary account blocks are often effective" seems like a non-existent advantage. We had many "single" IP blocks, these will be changed to "single" TA blocksn this is not an advantage or disadvantage of TAs. [sic] The point being made here is that even in larger wikis there has not a significant requirement to resort to IP blocks (which are still going to be allowed). It appears that based on the trends WMF is monitoring, there is evidence that most typical vandals are not shifting across temporary accounts by disabling or removing cookies. Sohom (talk) 15:08, 11 September 2025 (UTC)[reply]
I understand the point being made, and I don't see the importance of it. Most IP blocks that are now being made also don't require CU, SPI, ANI discussions, ... Basically, for the "easy" IP problems nothing changes, but the more complicated ones get harder to spot, discuss, ... "Most typical vandals" are not the ones I am talking about.
A report like this one from this month could no longer be publicly posted. In the future, the editor who posted it has temp IP rights, so he could notice that a group of temp accounts is from "This large IP range in Australia ", but wouldn't be allowed to post this fact. They link to an IP range edit log[55] which would no longer be possible in such a discussion, as that would disclose the IPs of the temp accounts. It would lead to such discussions being had in back chambers, out of view of most editors, and more importantly still impossible to be initiated by most editors. That kind of stuff is the issue, not the "one-off vandals will get a 31h block on the temp account instead of on the IP". Fram (talk) 15:19, 11 September 2025 (UTC)[reply]
There's also a lot of "appears to be a one-off-vandals" that with a quick check of some small ranges turns out to be someone vandalizing for months or years. That visibility will be gone, too. ScottishFinnishRadish (talk) 15:21, 11 September 2025 (UTC)[reply]
@ScottishFinnishRadish, @Fram You will still be able list temp-account edits by IPs and ranges at [[Special:IPContributions/<insert IP address here>]]. I don't understand how we suddenly be unable to make the requests that you are pointing to. Sohom (talk) 15:49, 11 September 2025 (UTC)[reply]
I will not request the temp IP viewer right under the above rules. I have had one ridiculous outing block for coupring someone's handle to someone's real name, even though they were listed as such on their Wikidata page and they used both in combination elsewhere as well: I will not risk getting another block because I somehow "outed" and IP address I learned through that right but was not allowed to share with the masses no matter how useful that might be. And no admin c.s. will be allowed to show such IPcontributions list when they may not reveal the IP address behind the temp account name. Fram (talk) 15:54, 11 September 2025 (UTC)[reply]
That's on you, the above directive is pretty explicit that you can report "hey Special:IPContributions/192.168.0.0/16 (not exactly that, but you get the drift) is a bunch of school kids, can a admin block it" or "hey Special:IPContributions/192.168.0.0/24 appears to a bunch of temporary accounts with very similar disruptive edits to game engines". It's a change of vocabulary yes, but the kinds of reports you are talking about are definitely doable and not being explicitly disallowed. Sohom (talk) 16:05, 11 September 2025 (UTC)[reply]
""hey Special:IPContributions/192.168.0.0/24 appears to a bunch of temporary accounts with very similar disruptive edits to game engines". " That makes no sense. IPs are not temporary accounts. And in any case you restrict such reports and the checking of such reports!), now made by regular editors (see my link to such a report in the current ANI) to a much smaller group of people. By the way, the people with the right can see the IP address belonging to a temp account: but can they easily do the reverse? Fram (talk) 16:14, 11 September 2025 (UTC)[reply]
appears to be a bunch of temporary accounts sorry for the typo. (A IP range can map to multiple temporary accounts since a TA corresponds to a machine). Also, you do realize that almost anyone with rollback or NPR will be able to make the same report with no problems. The persons who will be able to take action (i.e. block, revert) is already limited and almost all of the folks who can respond will already have TAIV (or will be handed TAIV at PERM with zero questions). Sohom (talk) 16:28, 11 September 2025 (UTC)[reply]
Yes, and when they state "Special:IPContributions/192.168.0.0/24 includes temp accounts X, Y and Z, two of which have been blocked already" or some such, they should get blocked for outing as making that claim publicly (linking IP to temp account name) will be disallowed. If we follow the WMF rules on this, people will need to be very, very careful not to accidentally break them. Even claiming "temp accounts X, Y and Z all locate to Perth, Australia, so are likely socks" is not allowed, as one can only know that through the IP adresses, and publicly stating anything learned by seeing the IP addresses is, again, not allowed. Fram (talk) 16:49, 11 September 2025 (UTC)[reply]
So that'll add how many seconds to the average task that is done 10,000 times a month by a few dozen people? A ten second increase adds dozens of hours per month to an already overwhelmed workflow. Or this extra stuff doesn't get checked anymore, which is more likely, and everyone wastes even more time dealing with unmitigated vandals. ScottishFinnishRadish (talk) 16:44, 11 September 2025 (UTC)[reply]
@ScottishFinnishRadish, If your gripe here is "this adds 10 seconds to a existing workflow", I see that as a okay tradeoff to the other alternative, which is "WMF (and Wikipedia) gets sued out of existence by frivolous GDPR lawsuits" or "we lose legitimately a significant chunk of good contributions from IP addresses by blocking all IP editing". Sohom (talk) 18:10, 11 September 2025 (UTC)[reply]
You forgot "there's not enough labor available to keep up with the increased workload and trying to keep up leads to administrator burnout and even less labor available for the increased workload which leads to increased burnout..." ScottishFinnishRadish (talk) 18:14, 11 September 2025 (UTC)[reply]
@ScottishFinnishRadish Admin burnout and not electing enough admins is a "us" problem. The fix is nominating folks at WP:AELECT, WP:RFA (the very same processes you are defending as set in stone) and fighting to make it easier for the community member to elect worthy candidates to adminship, not arguing against the implementation of a system that has been brought on to prevent us from being sued from existence and where WMF has put in significant effort into reducing the friction down to 10 seconds. Sohom (talk) 18:22, 11 September 2025 (UTC)[reply]
Uh, the very same processes you are defending as set in stone, what?We don't actually know what the additional time required will be, and having worked with the interface to place over 13,000 blocks, I think 10 seconds is on the low end of the scale. Editor and administration time is not cheap and putting a system in place that will result in a huge increase in labor cost without looking at the available labor is probably going to be worse than what we've seen at ptwiki.We're routinely dealing with bot attacks that will require an IP block as well as a temporary account block that use multiple IPs a minute. The end result of increasing the workload of defending against these attacks is no one actually doing the work. ScottishFinnishRadish (talk) 18:34, 11 September 2025 (UTC)[reply]
Uh, the very same processes you are defending as set in stone, what? - We are talking about the inflexibility of community processes to deal with TAs and why they might not scale.
We don't actually know what the additional time required will be, and having worked with the interface to place over 13,000 blocks, - While I respect your opinions here, I think you are overestimating the amount of time here, you see a bunch of edits across different TAs, a non-TAIV editor starts reverting posts on AIV that a bunch of TAs are posting similar edits, a admin looks at the IP addresses for a few accounts (two or three more extra click than normal), clicks on the IPContributions and widens the search space untill all the TAIVs listed in the AIV report are covered and blocks the IP range and we are done. (If a TAIV editor sees the same edits, they directly report the IP address range and a admin blocks). I do understand your point about friction but I don't see it in the vast majority of the cases we aren't adding anywhere the amount of friction where folks will "just not do it". (and I assume with time user-scripts will be developed to make process smoother and less clicks). Sohom (talk) 19:42, 11 September 2025 (UTC)[reply]
There is Autoreveal mode for users with the checkuser-temporary-account-auto-reveal right, which reduces friction for users who need to be able to scan a list of IP addresses of temporary accounts when viewing logs. KHarlan (WMF) (talk) 21:03, 11 September 2025 (UTC)[reply]
Thanks. So if, there is an IP vandalizing pages infrequently over months or years, and once discovered, I would like to go back to check if their previous edits were also reverted, that would now be impossible? ARandomName123 (talk)Ping me!17:39, 12 September 2025 (UTC)[reply]
That was my thought as well. Even if someone who cleans up/investigates copyvio has TAIV, the lookback seems quite limited so you would have to hope that each temp account is doing something obvious on a behavioral level to link them. And then that circles back to if you can name a CCI after an IP address & list the temp accounts there. @SGrabarczuk (WMF): I'm not comfortable with "it may actually be OK to document IPs" - there should be definitive clarification one way or other before the rollout occurs. Sariel Xilo (talk) 20:03, 12 September 2025 (UTC)[reply]
Even if we agree that English Wikipedia is unique and whatnot, there is a pattern and hopefully discussions about blocking IPs won't be that frequent (phab:T395134#11120266). I hope we agree that if EnWiki isn't unique, it's uniqiue in size (though I would argue that EnWiki, like all other large projects actually is unique in its practices and challenges, even if much is common). And so even if the number of range blocks decrease, the scale of exceptions may cause more problems than even other large projects. Best, Barkeep49 (talk) 15:09, 11 September 2025 (UTC)[reply]
I think this line of thinking (disabling IP editing) is short-sighted and will lead to a eventual demise of the the project (if we don't let people know we allow editing, we lose potential new editors/contributors). We should not' be making it harder for people to edit, instead we should be looking at ways to make it easier for folks to engage and edit our content (especially in the context of the fact that a lot of our content is being indiscriminately being remixed by AI). Sohom (talk) 13:07, 11 September 2025 (UTC)[reply]
Bizarrely, the only major test we have had of this has not in any way lead to the demise of said project. Protuguese Wikipedia has disabled IP editing since October 2020 (according to the Temp Accounts FAQ, question "Would disallowing or limiting anonymous editing be a good alternative?" where the WMF claims "there is evidence that this came at the cost of a significant reduction in non-reverted edits, weakening the growth of content in the Portuguese Wikipedia, and potentially leading to other negative long-term effects."
These claims seem false or at the very least severely overstated (no surprise, sadly, to see this kind of thing when the WMF wants to promote what they want or suppress what they don't want), there is no reduction in the number of editor edits[56] compared to e.g. 2019 (2020-2021, the Covid years, are a bad comparison). The same can be seen for the number of new pages[57]. The number of new editors is stable as well[58].
So contrary to what the WMF claims and what you predict, there are no negative effects from disabling IP editing (on the one large wiki who has done this). Fram (talk) 15:33, 11 September 2025 (UTC)[reply]
The number of new editors is stable as well The chart you linked to shows a slow decline/downward trend since 2020 to the present day (August 2023 was 9K, August 2025 is 7K). Again, this is not a Freenode style sharp drop-off we are talking about but a slow downward decline not unlike stack overflow. Sohom (talk) 15:55, 11 September 2025 (UTC)[reply]
Er, August 2023 was 7894, not 9K. August 2025 was 7227. As comparison, enwiki August 2023 was 93052, August 2025 was 85195. So Pt is at 91.5%, and enwiki is at, hey, 91.5%. Frwiki 11989 / 10656, or 88%. Dewiki 5919 / 5594 = 94.5%. So it seems like the decline for ptwiki is exactly in line with that of other large Wikipedia versions in general, and identical to the enwiki one. Fram (talk) 16:07, 11 September 2025 (UTC)[reply]
I misspoke, I meant June 2024, I think we can quibble statistics for a hot second, but there is a significant anecdotal and UX research behind the fact that you present people with a "sign up before doing the thing" screen, you see a steady user-attrition in that area of the funnel. If you are telling me that Wikipedia is somehow so special that this doesn't apply, I'm going to need a to see a lot more data than what you are showing me at the moment. Sohom (talk) 16:22, 11 September 2025 (UTC)[reply]
So you have no evidence for your claims, you compared apples and oranges, but according to you it should happen as you predict and I somehow need more than figures of the past 5 years to prove that this didn't that didn't materialize, actually didn't materialize? Perhaps what you and your "sighificant anecdotical research" e.g. haven't taken into consideration, is that there may be many more editors who stick around because they no longer have to deal with lots of IP vandalism?
Anyway, "I misspoke, I meant June 2024"? Oh right, that month with 7880 new editors, that makes all the difference in explaining how you came up with 9K... Please don't make such a mistake a third time or I will have to consider it deliberate. Fram (talk) 16:37, 11 September 2025 (UTC)[reply]
Fram, your message above is extremely adversarial and abrasive. I will refrain from engaging in this particular thread any further unless you reword your statement because your point here appears to be engage with me personally rather than with the issue more broadly. Your comment implies that I'm trying to deliberately misrepresent information in some way, which I sincerely am not and is a asusmption of bad faith.
To explicitly answer your question, there is a clear slow decline visible and yes, I misspoke, I meant June 2023. Also, here is the other thing, we do need some kind of IPMasking, otherwise we open ourselves to lawsuits related to GDPR. I do not have access to any data about editor attrition due to IPMasking, but the whole reason the WMF is doing IP masking is to make sure admins and patroller have the tools they need to still continue doing anti-vandalism even with the legislation-required changes. Best, Sohom (talk) 17:30, 11 September 2025 (UTC)[reply]
I see no reason to change anything in my statement when you cherrypick one month and rwice fail to pick the right one to boot. June 2023 is also a thousand up from June 2022, so what´s that supposed to prove? One doesn´t check trends over 5 or more years by comparing one month from midway in the set with one from near the current end, unless one wants to prove some otherwise unsupported point. Fram (talk) 18:20, 11 September 2025 (UTC)[reply]
If temporary accounts goes poorly - something that seemingly hasn't happened on other large projects - that seems like a logical response for the community to make. However, many people have been in favor of turning off IP editing for a while and so temporary accounts aren't forcing those people, or the community to that position. I have seen the value of IPs on their own merits, and seen the from Editor reflections many editors with registered accounts started as IPs and so we should be careful about turning off that gateway. Best, Barkeep49 (talk) 14:25, 11 September 2025 (UTC)[reply]
This is what's known as the Brussels effect. Its why for example, caps on bottles are tethered in the UK, even though its required under EU law. Countries outside the EU may have this treatment, so that companies don't create a queue for EU and non-EU lanes. JuniperChill (talk) 18:18, 11 September 2025 (UTC)[reply]
I’m concerned that IP info will disappear after 90 days. This will make it difficult to address long term abusers with stable addresses, of which there are a significant number. Instead, we’ll be playing whack a mole every 90 days or so, unless we can somehow retain info on IP use. — rsjaffe🗣️15:10, 11 September 2025 (UTC)[reply]
As I’m thinking about this some more, one way to retain the ip record is to block the ip rather than the temp account when we suspect a long term abuser with perhaps a stable ip. If the block of the ip isn’t sufficient, then block the temp account. — rsjaffe🗣️15:33, 11 September 2025 (UTC)[reply]
As I understand it, I as a CU cannot do this because the Ombuds have decided this is the same as the longstanding prohibition on connecting IPs to an account. But I hope non-CU admins could without jeopardizing the right. Best, Barkeep49 (talk) 15:42, 11 September 2025 (UTC)[reply]
Even CUs can block on behavioural similarities, unless that's changing too. A bigger question is perhaps, if an IP is blocked, is that block visible on the temp account and can others see the reason for the block as they do now? CMD (talk) 15:45, 11 September 2025 (UTC)[reply]
Correct. I could block a temp account based on behavior. But I can't do what SFR and rsjaffe are mooting: block the IP as a signal before blocking the temp account (or at least can't without obfuscating it in some other way). Best, Barkeep49 (talk) 15:50, 11 September 2025 (UTC)[reply]
If the IP is blocked but not the temporary account: All temporary accounts on that IP address will be prevented from editing, because all IP address blocks apply to temporary accounts (even if the IP address block isn't a hardblock)
If the temporary account is blocked but not the IP: The temporary account targeted by the block will be unable to edit. Additionally, if autoblocking is enabled on the block targeting the temporary account then:
The last IP used will be autoblocked for 1 day (in the same way as autoblocking works for registered accounts)
Attempts to edit using that blocked temporary account will also cause an autoblock to be created
Thanks very much, hopefully this can all be collated somewhere. I suppose the remaining question is whether other users see IP blocks and their reasoning, and if so how. CMD (talk) 16:32, 11 September 2025 (UTC)[reply]
Blocks placed on IP addresses will continue to be visible on Special:BlockList and other places that show blocks. However, a user wouldn't be able to see that a temporary account is blocked by an IP address block, unless they use IP reveal (TAIV) to get the IP address and then look for the block targeting that IP (such as opening the contributions page for that IP). WBrown (WMF) (talk) 08:41, 12 September 2025 (UTC)[reply]
Really? If that is the case, how are admins expected to handle say vandalism reports of a temporary account where an IP is already blocked? Always block the temp account as well? CMD (talk) 09:58, 12 September 2025 (UTC)[reply]
If the IP address is blocked, then the temporary account cannot edit. Therefore, the admin wouldn't need to take additional blocking action on the temporary account. However, if the temporary account switches IP addresses then they will be able to edit.
Given that, if the target of the block is intended to be the temporary account the admin should block the temporary account. This will usually mean that it is better to block the temporary account first as opposed to the IP address.
We have seen that blocks of temporary accounts on other wikis have been enough to prevent abuse in most cases. Generally an admin would want to block the underlying IP address(es) if:
If this user has evaded blocks by logging out, waiting for the autoblock to expire, and making another edit
Multiple temporary accounts are editing for a sustained period on the same IP (therefore, it's easier to block the IP than multiple temporary accounts)
The issue I raise is vandalism reports, as given we now can't see if an editor is blocked multiple reports could be made. I suppose an admin could reply "Already IP blocked" and that wouldn't disclose the IP connection, but I suspect if multiple reports come in a dual block of teh temporary account as well will provide the clearest information. CMD (talk) 12:25, 12 September 2025 (UTC)[reply]
Yeah, a dual block would be the most clear. Blocking just the temporary account should be enough for any user that has not used TAIV to view the associated IP address.
This is useful information. Is there any compendium of lessons learned so far? That would help reduce the disruption that I’m sure will occur as we learn over time how to address this new way of tracking unlogged-in users. — rsjaffe🗣️13:19, 12 September 2025 (UTC)[reply]
Or rotate their IPv6 address by simply restarting their router. Autoblocks should inherit the block settings of the TA, and if they are using IPv6 addresses, they should apply across the /64 range as well. ChildrenWillListen (🐄 talk, 🫘 contribs) 20:04, 12 September 2025 (UTC)[reply]
@Barkeep49, I can't block the IP as a signal before blocking the temp account - I'm pretty sure you can, I'd like somebody else to confirm it but as far as I know, this happens on other wikis, it's a tradeoff Legal is OK with. SGrabarczuk (WMF) (talk) 16:17, 11 September 2025 (UTC)[reply]
I'm glad to hear admins can. But (and I would hope @RoySmith or some other Ombud reading this corrects me if I'm wrong) the Ombuds have written that I cannot as a checkuser. They did so in a message sent to checkusers in March and when I wrote in reply I find the implication that CUs will have to take similar measures to blocking two connected IPs as we do to blocking a registered account and an IP address to be incredibly surprising. no one corrected me or said I was misunderstanding in anyway. Best, Barkeep49 (talk) 16:32, 11 September 2025 (UTC)[reply]
It's great that we'll be able to block the temporary account MAB or Salebot is using, then spend additional time to view the IP and check if it's a proxy before placing the proxy block, and if we're lucky finish that process before their bot has moved onto the next temporary account on another IP that will require twice as many blocks and three times as much time to take care of. Or, as Barkeep points out, since we've gotten conflicting information I might have to block the temporary account, find an active checkuser or other trusted editor I can disclose the IP to, have them block it, and waste multiple people's time. ScottishFinnishRadish (talk) 16:49, 11 September 2025 (UTC)[reply]
@Barkeep49 I don't remember your specific comment, but I assume it was in response to the OC's email of 17 March, which is reproduced for public view at meta:Ombuds commission/2025/Temporary Accounts. I encourage anybody reading that to note that it's full of weasel words like "limited experience", "initial", "preliminary guidance", "evolving landscape", "current understanding", etc. I should also point out that just like ArbCom, the OC doesn't make policy; we (again, like ArbCom) just get blamed for trying to enforce it. RoySmith(talk)17:16, 11 September 2025 (UTC)[reply]
On the other hand, if an LTA comes back within 90 days on a new temp account and we can behaviorally link it to the prior temp account, and find that both are on the same ip, then we can go for a prolonged ip block. I think there’s going to be a significant learning curve to this as we figure out how to address chronic abusers. — rsjaffe🗣️16:02, 11 September 2025 (UTC)[reply]
There's also this: When it is reasonably believed to be necessary, users with access to temporary account IP addresses may also disclose the IP addresses in appropriate venues that enable them to enforce or investigate potential violations of our Terms of Use, the Privacy Policy, or any Wikimedia Foundation or user community-based policies. Appropriate venues for such disclosures include pages dedicated to Long-term abuse. If such a disclosure later becomes unnecessary, then the IP address should be promptly revision-deleted. (Source) SGrabarczuk (WMF) (talk) 17:28, 11 September 2025 (UTC)[reply]
You can configure your browser to reject cookies, and in that case, a new temporary account will be created for every edit you make. See this FAQ entry. Note that if you do this, you can edit only 6 times/day before you have to create a real account, per this FAQ entry. OutsideNormality (talk) 03:30, 12 September 2025 (UTC)[reply]
Hi! I want to note that we are not implementing any tracking cookies in your browser. Tracking cookies are used to track your browsing history and activities, typically across multiple websites. We are adding a cookie to attribute your edits to an anonymized username. And your data (IP address) will be stored for a limited amount of time and be exposed to a smaller group of individuals. We have a similar cookie for registered accounts, except that it lasts for a longer time period. -- NKohli (WMF) (talk) 09:32, 12 September 2025 (UTC)[reply]
Cookies don’t anonymize edits, they de-anonymize them. They enable activity to be tracked across IP addresses. (Or whatever you want to call it that isn’t “tracking”—haha, gotcha! It’s totally not tracking because we defined tracking as something you do with muffins, not cookies!) This cookie has no other purpose and I don’t want it. 98.97.6.48 (talk) 00:51, 13 September 2025 (UTC)[reply]
The alternative is the expose your IP address every edit. The purpose of temporary accounts is to de-anonymize your activities on Wikipedia (which must be done in some way so blocks apply to the same person) while hiding your real-life identity, the latter of which is what the WMF probably means by "anonymize". Aaron Liu (talk) 11:41, 17 September 2025 (UTC)[reply]
Some questions about temporary accounts:
Would there still be a way for an unregistered user to view all of their own IP's (post-rollout) contributions, or equivalently the list of their own IP's past temporary accounts?
Some questions about temporary account viewers:
If an unregistered user only edits constructively and without engaging in vandalism, trolling, or similar shenanigans, then would it be against the rules for a TAIV to check their IP address, or could they just decide to do it on a whim?
What's stopping a rogue TAIV user from programmatically checking the IP of every single temporary account that has edited in the last 90 days and dumping that list somewhere? Would there be ratelimits put in place or something? 98.170.164.88 (talk) 05:49, 12 September 2025 (UTC)[reply]
To answer your first question about temp accounts, what do you mean by "their own IP"? :) This was a fundamental concern with how we handle unregistered editors. IPs can change, sometimes very rapidly. We cannot say IP 1.2.3.4 is always User ABC.
Contributions made before the launch of temp accounts will not be affected. So a user can see edits made by logged out editors an IP/range from before the rollout. Post rollout, a temporary account holder can look at their contributions from their temp account. If they have happened to have other temp accounts in the past, they'll need to remember which ones those are if they want to see their contributions from those temp accounts.
To answer your questions about temporary account viewers:
The policy lays this out so please refer to it. We tried to make it as succinct and clear as we could. If you have clarifying questions about anything outlined in the policy, please let me know. Happy to answer.
There is a log in place but we do not have any rate-limits. We trust that editors with this right will exercise their judgement and act in the best interests of the project. We also expect that admins will ensure users who are granted this right truly need this right to carry out anti-vandalism efforts.
Chipmunkdavis, Rsjaffe, and other interested parties: I have made an attempt to document the answers to questions in this discussion at User:Perfect4th/Temporary accounts. It's roughly topical; anyone who wishes to or has a better understanding than what I wrote is free to correct it, reorder in a way that makes sense, add further answered questions, etc. Happy editing, Perfect4th (talk) 18:23, 12 September 2025 (UTC)[reply]
Nice. Thanks for making this. Perhaps you should consider moving it to projectspace, or someone should create something similar to it in projectspace. I think a projectspace page to put tips, tricks, and notes on temporary accounts is going to be needed to help get everyone up to speed. –Novem Linguae (talk) 21:07, 12 September 2025 (UTC)[reply]
Just checking — The cookie will expire 90 days after its creation means that the cookie expiration is not refreshed by subsequent visits by the same browser? So an "IP editor" will get a series of user names – a new name per browser every 90 days? Which means that any discussions in the user's talk page will need to be linked or moved to the new account if the discussion is to continue? Is the cookie lifetime 90 days on all wikis? — GhostInTheMachinetalk to me15:35, 11 September 2025 (UTC)[reply]
Since its not possible to delete an account on Wikipedia due to attribution issues, does it mean temporary talk pages will be kept after 90 days? Messages from IP users get deleted after a few years, but remains visible in the edit history. JuniperChill (talk) 18:13, 11 September 2025 (UTC)[reply]
It is up to each wiki to decide how they want to handle the talk pages of old temporary accounts (leave them unchanged, blank them, or delete them). I don't expect enwiki to delete them. jlwoodwa (talk) 23:56, 11 September 2025 (UTC)[reply]
To the best of my understanding: 1. it is 90 days after the temporary account was created (globally, not locally), which is public information, and 2. it has the same effect as blocking it for the remainder of its lifetime (modulo a brief difference in autoblock behavior at the end, perhaps). jlwoodwa (talk) 01:06, 12 September 2025 (UTC)[reply]
To answer your first question: When a temporary account has expired, this information is shown publicly on Special:CentralAuth. For example, at testwiki the temporary account ~2024-10120 is shown as having expired. I am not aware of an interface that shows when a temporary account is expected to expire (though you could estimate this by looking at when the account was registered and comparing it to the current date)
To answer your second question: Any block placed on a temporary account for longer than it's remaining lifetime will succeed. We do not prevent the blocking of temporary accounts for more than 90 days. One advantage with this is because there may be a need to track block evasion. For example:
A temporary account is editing disruptively and an admin decides to block the user behind the temporary account indefinitely (intentionally)
The admin communicates that this block is indefinite and editing the wiki again would be considered block evasion
The user ignores this and, after waiting till their old temporary account expires and waiting for any autoblocks expire, they edit again getting a new temporary account
A different admin receiving the report of block evasion can more easily see that there is still an active block on the first temporary account that applies to the user behind the account. Without a block longer than the expiry time of the temporary account, then the different admin would need to check that the intention was to block the user for more than the lifetime of their old temporary account
If there is no need to block the user behind the temporary account, then a block of 90 days as standard would be enough to always ensure that they are prevented from editing throughout the lifetime of that temporary account
"If there is no need to block the user behind the temporary account, then a block of 90 days as standard would be enough to always ensure that they are prevented from editing throughout the lifetime of that temporary account" Under what circumstances would we ever block a temp account without the need to block "the user behind the account"? Blocks (excluding some username blocks, which aren't relevant here) are always for the user behind the account, and not for the account itself. Fram (talk) 09:21, 12 September 2025 (UTC)[reply]
Yes, I agree that blocks are intended for the user behind the account and so in probably all cases the best approach would be to block the temporary account indefinitely.
I mentioned the last point primarily from the point of view that some wikis have requested that we change the default blocking period for temporary accounts on their wiki to 90 days (T398626). Without a change in blocking policy to indicate 90 day blocks apply to the user indefinitely, these 90 day blocks would no longer prevent that user from editing under the blocking policy after their original temporary account expires. WBrown (WMF) (talk) 09:38, 12 September 2025 (UTC)[reply]
Perhaps one nice thing about temporary accounts will be that they can be blocked like regular users, without special rules about block duration. There are many IPs out there that have only gotten 36 hour blocks or one week blocks, when a full account would have normally been indef'd. In other words, it simplifies blocking. (And of course the normal indef appeals process can be used. Indefinite is not infinite.) –Novem Linguae (talk) 21:47, 12 September 2025 (UTC)[reply]
WMF, in the FAQ it is claimed in the section "Would disallowing or limiting anonymous editing be a good alternative?" that this is "unlikely" because at the Portuguese wikipedia "On the other hand, there is evidence that this came at the cost of a significant reduction in non-reverted edits, weakening the growth of content in the Portuguese Wikipedia, and potentially leading to other negative long-term effects." As I described above, these claims seem false, and the growth or decline of ptwiki seems exactly in line with that of other large Wikipedia versions. There is no significant extra loss of new articles, user edits, or new editors compared to these other Wikipedias. See e.g. the number of active editors[59]. So based on what numbers do you claim these statements to be true? Fram (talk) 16:30, 11 September 2025 (UTC)[reply]
I'm very curious about this as well. Because the public research I've seen suggests it didn't harm ptwiki, but have had multiple conversations with various WMF staffers who firmly believe it did. While I expressed reasons other than this above why I supported keeping IP editing, that was before I realized that no matter what temp accounts reset after 90 days. So understanding what evidence we have about this would be important for me in any such discussion about disabling IP editing. Best, Barkeep49 (talk) 16:47, 11 September 2025 (UTC)[reply]
I too am interested in this question, and share Fram's concern that causal inference in statistics is very hard and at minimum a proper difference-in-difference model is necessary to attempt to capture the causal effect of disallowing IP editing on content, which we don't seem to have. KevinL (aka L235·t·c) 17:57, 11 September 2025 (UTC)[reply]
Hello! I want to first clarify about the metric. The leading metric we looked at for ptwiki is Net non-reverted content edits - defined as the number of content (main-namespace) edits that were not reverted within 48 hours, excluding bot edits, reverted edits, and edits that reverted other edit. We chose this metric because we felt it was most representative of the impact on the community's content health as a result of this change. Unfortunately this metric is not displayed by default on stats.wikimedia.org.
We have measured the impact of this change three times since the change was implemented: In August 2021, June 2022 and April 2024. Each time we saw a similar downward trend in Net non-reverted content edits. You can see how the numbers compare over the four years in the most recent report, Table 6. In Q1 of this year we saw a decline of as much as 36% compared to pre-restriction days. We also compared this trend with Spanish, German, French and Italian Wikipedias and did not see the same trend on those wikis.
You are right in noting that there have been many positive outcomes from this change as well - lower blocks, reverts, page protections -- all point to a decrease in vandalism on the project. The feedback from the survey was quite positive as well. However, we do not think the decline in net non-reverted content edits is worth the trade-off. @Benjamin Mako Hill and his team wrote about the Value of IP Editing to offer their perspective on this too in case you haven't seen it.
Lastly, I want to point out that before embarking on temporary accounts our team seriously considered turning off logged out editing as a viable alternative. Some of you might recall that we put out a call to communities that want to experiment with this change. The Farsi Wikipedia experiment was a result of this call. If this option did turn out to be viable, it would have been the easier way out - way less work than temporary accounts. Unfortunately the results from ptwiki and fawiki were not what we had hoped for. -- NKohli (WMF) (talk) 13:19, 12 September 2025 (UTC)[reply]
I find it disingenuous that you never mentioned the only metric that matters: the editors of ptwiki are happy with banning IP edits, and they have no intention of going back. Moreover, the metric you do focus on, net non-reverted content edits clearly shows that ptwiki was already in decline before it. Tercer (talk) 14:43, 12 September 2025 (UTC)[reply]
I disagree that editor happiness is the only metric that matters. I am here to serve our readers and so if our readers are being hurt by having old information, when new information would be possible, or (more importantly) incorrect information when correct information would be possible, that matters a great deal to me. It also matters a great deal to me about whether turning off IP editing harms the pipeline to gaining more new registered editors. Best, Barkeep49 (talk) 17:30, 12 September 2025 (UTC)[reply]
I generally tend to express my unhappiness instead of leaving right away if there is something I don't like, since I have invested a lot in the project. I imagine it's the same in other wikis Ita140188 (talk) 16:51, 15 September 2025 (UTC)[reply]
Perhaps you are a very dedicated editor that will stay no matter what, but you can't generalize this to everyone. Editors come and go all the time. I don't think there's really any doubt about whether unhappy editors tend to leave the project.
And in this particular case WMF has already been clear that it will push through regardless of editors' opinions, so "expressing your unhappiness" won't make any difference. Tercer (talk) 15:52, 16 September 2025 (UTC)[reply]
Also, it's not a good look reputation-wise if readers are exposed to more vandalism or long-term abuse, which they most likely will be in the long run with the temporary accounts feature. Not all vandalism is reverted quickly. For instance, to pick a relatively low-stakes example, if temporary accounts had been active here in May, I would never have discovered this edit because of the 90-day cutoff for retrieving IP information (see this comment of mine for more context). If push came to shove I would absolutely support discontinuing IP editing ... but we're basically damned if we do, damned if we don't. When I was invited to participate in the WMF's let's talk program, one of the reasons I agreed to do so was to bring up my concerns about this cutoff. ButI well know why it's been implemented. Graham87 (talk) 09:17, 14 September 2025 (UTC)[reply]
I think the only big issue with this is that everyone's complaining about traceability, since this doesn't really affect the reverting vandalism side of things aside from tracing. And this whole TA thing is literally reducing traceability, so you can't really get around that despite any attempt to do so. The alternative would be to set no expiration or longer expiration to the cookies, but then it would be basically 'we replaced IPs with something that looks a bit better but functions like an IP' 2A04:7F80:6E:D2B:900C:A6A9:FD99:F70 (talk) 14:31, 18 September 2025 (UTC)[reply]
Traceability is my main concern as well (see my comments above). In their FAQ, the WMF said that they are "open to extending" the 90 day period for IP retention. Maybe it should be increased?
In the same answer, they mention we could use "behavioral evidence or patterns of editing" but that's a bit hard to do for the occasional vandals with little edits. ARandomName123 (talk)Ping me!14:57, 18 September 2025 (UTC)[reply]
I could also see cases where a range IP user that clears cookies could either purposely or accidentally sock in a low volume way that would be really hard to notice based on behavioral evidence alone. In a recent AfD, I encountered an IP who nominated the article and then later voted when their range changed slightly. I don't think they intended to be malicious but I was able to flag that I thought these two edits were by the same user. But there wasn't really anything behavioral that stood out to connect the two edits and in the case of temp accounts, I wouldn't have been able to identify them as being from the same editor. Non-admins who frequently close discussions should probably have TAIV. Sariel Xilo (talk) 16:28, 18 September 2025 (UTC)[reply]
I wouldn't say the metric was already in decline before the date. It seemed to be just jumping up and down within the same range, but after that there was a very clear downward trend. Aaron Liu (talk) 11:47, 17 September 2025 (UTC)[reply]
There were roughly 195k non-reverted edits in 2017, 132k in 2019 (the baseline), and 107k in 2023. The decline from 2017 to 2019 was roughly 47%, much larger than the 22% decline from 2019 to 2023 that WMF considers so disastrous.
I'm not sure I agree with We chose this metric because we felt it was most representative of the impact on the community's content health as a result of this change. If community systems are overwhelmed in a community that has IP editing (with or with-out Temp Accounts) the edits that stay unreverted may be, on the whole, a net negative to the project and to its readers. Put another way: if a community is overwhelmed then the net non-reverted edits are lower pre-change than policies and guidelines would suggest they should be and if they are then not overhwelmed afterwards, may be showing the true rate. I also am not sure I agree that it is the only metric worth looking at - as I indicated above statistics about overall community health in terms of editor registration, retention, and "moving up the ranks" - also feel worth examination. I would suggest English Wikipedia is not currently overhwelmed and so we do have a good baseline - something I don't know was the case for ptwiki - but I do worry that these changes will overwhelm the system because of the extra work that it is going to require to dealing with unregistered accounts. Best, Barkeep49 (talk) 17:38, 12 September 2025 (UTC)[reply]
@Barkeep49 I did not mean to imply that this was the only metric worth looking at. Like you can see in the report we did examine multiple other metrics and also carried out community survey(s) to assess how the editors feel about the change. However this metric stands out as important to us because it indicates a sustained loss in high-quality contributions and has consistently been on a decline in ptwiki since the restriction was in place.
I would also like to add that our team has been continually working on delivering tools to assist with anti-vandalism work. hCaptcha, GlobalContributions, IP Info, AbuseFilter improvements (including IP reputation filters), UserInfo card etc to name a few. We strongly care about moderator burden and this is reflected in our team's priorities. If you have ideas for how we can do these better, your thoughts are welcome on the talk page. -- NKohli (WMF) (talk) 11:15, 15 September 2025 (UTC)[reply]
@NKohli (WMF) I did read the report and did see other metrics. In the most recent report the two other takeaways were favorable on disabling IP editing. The fact that the foundation has decided that the metric which showed a decrease is so alarming as to say it's a failure suggests that the WMF does think it's the only metric that matters. I appreciate you answer my question - I really do - but I think my original assessment the public research I've seen suggests it didn't harm ptwiki. needs to be amended to the public research I've seen suggests mixed results on ptwiki which does not, for me, justify the labeling the Foundation has chosen to attach to it. Best, Barkeep49 (talk) 14:36, 15 September 2025 (UTC)[reply]
It's also worth noting that @MuddyB: complained about the surge of vandalism on the Swahili Wikipedia (where he is an admin), following the enabling of temporary accounts, though as I understand IP editing may have been previously disabled outright on this wiki. [60]Hemiauchenia (talk) 23:32, 12 September 2025 (UTC)[reply]
Temporary accounts are going to be "rammed" down everyone's throats as they are being made for legal reasons. For better or worse, office actions exist for these sorts of matters. (And curiously Swahili Wikipedia was another one that had Vector2022 imposed over the wishes of the community. That said, Vector2022 has also now become universal across all wikis, as temporary accounts will also.) CMD (talk) 10:18, 13 September 2025 (UTC)[reply]
Please read the thread before commenting. The subject is banning IP edits as an alternative to introducing temporary accounts. It would also solve the legal problem. Tercer (talk) 11:25, 13 September 2025 (UTC)[reply]
You are misunderstanding the implications of the proposal. Banning IP edits is not an alternative to temporary accounts, both actions are technically independent of each other. Temporary accounts are becoming implemented whether IP edits are allowed or not. Even if en.wiki responds by banning article editing by IPs, we will still have to figure out how to work with temporary accounts on talkpages. CMD (talk) 14:35, 13 September 2025 (UTC)[reply]
Of course it is an alternative. If IP edits are banned there's no longer a legal reason for implementing temporary accounts. Are you claiming that WMF would nevertheless implement temporary accounts? Just out of spite? I find that hard to believe. Tercer (talk) 14:49, 13 September 2025 (UTC)[reply]
Why do you assume that when people say we should ban IP editing they are only referring to mainspace? But, yeah, as a practical matter, anonymous editing exists (and thus temporary accounts also exist) and that's not going to change any time soon. So the community needs to figure out how to handle them. RoySmith(talk)14:50, 13 September 2025 (UTC)[reply]
I think the WMF would implement temporary accounts because they already exist and have already been rolled out and will continue to be rolled out as a standard part of the underlying software for every wiki, whatever en.wiki does, rather than out of spite.I assume that in general the IP editing bans will be likely called for with the main space in mind because of the consistent raising of the pt.wiki precedent, as well as on-wiki precedent regarding how we currently handle protections and even weird situations like the ARBPIA ECP talk page restrictions. CMD (talk) 15:08, 13 September 2025 (UTC)[reply]
To be fair I don't think the latest surge in vandalism on swwiki is related to temporary accounts. WP:LTA/Wikinger decided to target swwiki in the past weeks/months on an almost daily basis. The LTA uses rapidly changing proxy IPs which is a burden to admins with or without temporary accounts.
I did a quick check and it seems to me that none of the swwiki admins enabled their access to temporary account IPs which also means they can't use features like IP autoreveal – and have no way of knowing (except based on behaviour) if a temporary account is a newbie or a potential LTA.
@Johannnes89 It's chaos—completely. Temp aacounts actors aee now on my blog, commenting gibberish. Good thing Wordpress can't comment without approval. Ditching them every now and then. Muddyb (talk) 13:21, 18 September 2025 (UTC)[reply]
I can’t see the blog comments but I bet all of them were written by WP:LTA/Wikinger. I don’t think the situation on your home wiki would be much different without temporary accounts (except that some tools currently require a few more clicks). Wikinger has annoyed different projects for years and unfortunately he currently chooses to annoy swwiki. You might want to check mw:Extension:IPReputation/AbuseFilter variables in case that’s helpful to fight against his proxy abuse (unfortunately many open proxy IPs are not known to IPoid). Johannnes89 (talk) 17:24, 18 September 2025 (UTC)[reply]
What's the point of comparing different months in different years (August 2021, June 2022 and April 2024)? This will not eliminate seasonality effects. Maybe it's not that 2024 saw less edits, but that April has generally less edits than August or June? Ita140188 (talk) 16:49, 15 September 2025 (UTC)[reply]
I think it inevitable that Wikipedia projects will disable anonymous editing in the future. As projects grow, the opportunity for anonymous editors to do anything productive continues to shrink. (1) The level of knowledge necessary to contribute positively to the projects keeps increasing. More policies, more guidelines, more standards, more templates. This growth in required knowledge is glacially slow but inexorable. (2) There is ever increasing lack of ability for editors to contribute in general due to the (ever unattainable, thankfully) goal of completing the project. The lack of productive work possibilities gives ever decreasing opportunities to anonymous users to contribute positively. (3) The ratio of administrators to the amount of work administrators need to do continues to worsen. Those are just a few of the factors in play that are driving this reality. Imagine, if you will, Wikipedia 50 years from now. There will always be growth to be sure, but the opportunity for anonymous users to do anything will be almost absent. There needs to be a long term strategy to reverse these trends, else new blood coming into the projects will die. We're already in a long term drought. --Hammersoft (talk) 14:52, 12 September 2025 (UTC)[reply]
There won't be any wikipedia 50 years from now. What wikipedia does is harness the energy of many people to read books, newspapers, journal articles, etc, and distill them into encyclopedia articles. In way less than 50 years from now, AI will be good enough to make that an obsolete concept. RoySmith(talk)01:26, 13 September 2025 (UTC)[reply]
Yeah, 50 years is quite optimistic. I can see the project lasting for another decade or two, but beyond that... I'm not so sure. Some1 (talk) 01:43, 13 September 2025 (UTC)[reply]
AI will be good enough to decide what is true? Leaving this to AI (ie. most likely to a private corporation) will never be acceptable, no matter how "good" the AI is. Wikipedia works because it's based on consensus among people. Ita140188 (talk) 16:37, 15 September 2025 (UTC)[reply]
I think, let's see how it goes, but certainly keep this option open if it proves untenable, as I suspect it well might. I'm not tremendously impressed with WMF over this whole thing; there was a lot of pushback on the idea, so they came up with "We're legally required to do this!", but then when they were asked "By what law, where?", they wouldn't answer that. SeraphimbladeTalk to me08:46, 16 September 2025 (UTC)[reply]
any information relating to an identified or identifiable natural person’, including an online identifier that identifies the person directly or indirectly. Like an account identifier created just for that person that persists across IP addresses? I still think it's a lot of work to have gone through just to have communities disable IP/anon editing entirely. ScottishFinnishRadish (talk) 10:48, 16 September 2025 (UTC)[reply]
I think the defense is that it is the equivalent of a anonymized, randomly generated username. The data is (for all intents and purposes) anonymized and after 90 days, and a "random party" will not be able to map your TA to you with any level of certainty. Sohom (talk) 16:01, 16 September 2025 (UTC)[reply]
@Seraphimblade, You are framing the events in the wrong order: "We're legally required to do this" (WMF does nothing for a while) -> "We had some light regulator scrutiny" -> "WMF scrambles to implement IP Masking" -> "Community outrage at the initial idea" -> "WMF slows down, spends a lot more time building some anti-abuse tooling around it" (and now here we are). Also, the reason the WMF is cagey about why they need to implement it is because it's typically bad legal strategy to publicly proclaim "we are currently breaking this exact provision of GDPR". (And, yes we are probably flouting multiple privacy laws including but not limited to GDPR's absolute stance on IP addresses and CCPA's slightly more nuanced take on IP addresses) It's frustrating as a volunteer but I think understandable from the point of the view of the WMF. Sohom (talk) 16:16, 16 September 2025 (UTC)[reply]
It’s also bad legal strategy to publicly proclaim that you’re going to violate the ePrivacy Directive instead of the GDPR, by openly admitting in an FAQ that your cookies are not strictly necessary. But here we are. 98.97.4.79 (talk) 02:35, 17 September 2025 (UTC)[reply]
This cookie is necessary iff you chose to edit. (If your argument is somehow "we should not ever set a cookie", I'd like to see you defend the concept of a session identifier.) Regarding the ability to refuse the cookie, you are welcomed to refrain from editing and the cookie will not be set at all. (And if you clear your cookies regularly, a new one will be set, every session). If you do edit, you will be given a anonymous identity that will be destroyed/expired after 90 days. I don't see how any of this violates the ePrivacy Directive. Sohom (talk) 02:55, 17 September 2025 (UTC)[reply]
The cookie is not “strictly necessary for the delivery of a service requested by the user”, because the FAQ admits that editing will work just fine even if a browser discards the cookie. The purpose of the cookie is apparently to reduce the number of extra database entries created by the WMF’s own software, which is not a service requested by the user, so users must be presented with the option to accept or decline it. Sites can’t just say that cookies are “necessary” for their own private reasons; the law would have no effect if that were the case. 98.97.4.79 (talk) 03:14, 17 September 2025 (UTC)[reply]
Again, you have the explicit ability to click cancel on a edit or not edit at all which would be a declination to the cookie (and a declination does not adversely affect your reading experience). Also, the cookie is required not because of "the number of extra database entries" created, but rather for attributing the edit to a user, a service you request and agree to by clicking the big blue "Publish changes" (or the large "Reply" button). By doing that you are agreeing that the cookie essential for attribution is set on your device. Your argument does not make sense in this context. Sohom (talk) 03:29, 17 September 2025 (UTC)[reply]
Also, to put things into context Wikimedia's infrastructure is largely open-source in a way that no other top-10 website is. The Foundation does not share any identifiers, and has a privacy policy that is much more detailed than any other top-10 site. If you are looking for technical privacy violations, you are barking up the wrong tree here. The search engine you used to get to this site probably collects a order of magnitude more data about you than Wikimedia will ever get from it's temporary account rollout. Sohom (talk) 03:38, 17 September 2025 (UTC)[reply]
Access to specific website content may still be made conditional on the well-informed acceptance of a cookie or similar device, if it is used for a legitimate purpose.
Surely "the service as can be provided with a specific amount of labor" is the service? We could, in a strictly literal sense, serve pages as printed paper via FedEx, employing millions of clerks and envelope-stuffers, and this would require no cookies at all, but I scarcely think this would prove they were unnecessary all along. jp×g🗯️09:09, 17 September 2025 (UTC)[reply]
Wikimedia Research Showcase: "Readers and Readership Research" will be the featured theme for the next research showcase taking place on September 24 at 16:30 UTC.
Update to banner and logo policies: Feedback is requested on proposed policy and documentation updates regarding the use of banners and logos for advocacy purposes.
Temporary Accounts: Temporary accounts are now deployed to almost all wikis except the last 11.
User Info: This new feature displays data related to a user account when you tap or click on the "user avatar" icon button next to a username. It's meant to be useful for different users with extended rights as well as newcomers.
Newsletter highlights: The latest Readers Newsletter is now available. It includes considerations about Wikipedia's declining pageviews in the recent years, how the Foundation and communities may work on addressing this together, and the formation of two new teams — Reader Growth and Reader Experience.
Activity Tab Experiment: The Foundation launched an experiment testing a new Activity tab in the Wikipedia Android app to our beta testers. Instead of only showing editing activity, this tab also surfaces insights about reading and donation behavior.
Search Suggestions: To make it easier for users to find articles, logged-out users on both desktop and mobile will see suggestions of articles for further reading on English Wikipedia beginning the week of September 22. All non-English wikis received this update in June and July.
Paste Check: The Foundation is working on a new check: Paste check. This check informs newcomers who paste text into Wikipedia that the content might not be accepted to ensure it is aligned with the Movement's values. This check will soon be tested at a few wikis.
CampaignEvents extension: The CampaignEvents extension has been enabled for all Wikisources. The extension makes it easier to organize and participate in collaborative activities, like edit-a-thons and WikiProjects, on the wikis. To request the extension for your wiki, visit the information page.
Structured Task: The Add a Link Structured Task has been fully released at English Wikipedia. This release is an important step in making editing more accessible for new contributors, especially on mobile.
Tech News: Read more updates from Tech News week 36 and 37.
Multilingual Contributors: The Language and Product Localisation team is launching a CentralNotice campaign to attract multilingual contributors to specific Wikipedias. The campaign will feature regionally targeted banners to reach potential native speakers.
Open Indonesia: Reflections on Open Indonesia, an event in Bandung gathering communities dedicated to advancing open knowledge to build the country's Open Knowledge Roadmap.
UK Online Safety Act: The Wikimedia Foundation will not appeal the UK High Court’s decision to dismiss our challenge to the UK’s Online Safety Act (OSA) Categorisation Regulations.
August board meeting: Updates on board appointments and selection, CEO search, work to strengthen Wikipedia's approach to neutral point of view and updates on three pilots around more shared decision-making and shared accountability across the movement.
For information about the Bulletin and to read previous editions, see the project page on Meta-Wiki. Let askcacwikimedia.org know if you have any feedback or suggestions for improvement!
I've rarely seen an editing restriction that is something like "one comment per talk page, per day" or "one edit per article, per day". This is meant to deal with editors who post many comments per day to the same talk page, especially low-value comments (e.g., demanding prompt responses, or posting nearly identical comments multiple times in the same thread). Does anyone know whether this is a formal thing, and if so, what it's called?
(@Locke Cole, this approach might also be useful for LLM problems. Imagine if suspected LLM bloviation could be reduced to a single comment per day, without needing any agreement that an LLM was actually being used.) WhatamIdoing (talk) 17:45, 13 August 2025 (UTC)[reply]
I think its a thing... I recently had issues with someone who, if I remember correctly, was under a two comments per talk page, per day restriction but they were able to get around it by posting massive comments with replies to multiple editors embedded within them. In light of that I would want any future restriction to come with some sort of size limit on the comment or the explicit understanding that it isn't to be circumvented by posting walls of text. Horse Eye's Back (talk) 17:53, 13 August 2025 (UTC)[reply]
I think there might be a WP:CTOP that could cover this, but it would require a willing administrator to place the ban and go through the process. I know the arbs are currently voting on some CTOP changes, but also one of the proposed principles at least supports the concept since non-stop comments invariably drag other editors back to reply. I know for the "nearly identical" they've been referred to as ForestFires before, which are generally viewed as disruption. —Locke Cole • t • c17:58, 13 August 2025 (UTC)[reply]
I'm actually hoping to find a "one sig, or we'll block you" kind of rule. I've been watching an editor (now indeffed) whose talk page comments are sometimes very long but frequently both very short and very low-value (e.g., just pinging editors who haven't replied fast enough to suit him/while it's the middle of the night in their timezone). WhatamIdoing (talk) 17:33, 16 August 2025 (UTC)[reply]
It's a lot easier to suggest a type of restriction if you can say "Why don't we try a WP:LOWVOLUME?" instead of "So, once upon a time, I remember seeing an admin try this one weird trick, and it really seemed to help..." WhatamIdoing (talk) 17:45, 17 August 2025 (UTC)[reply]
This is good, especially because it's not a binding ruling that covers each and every article.
Even in the CTOPs, Admins 'can' impose the limit if they see fit. Too much restriction might make Wikipedia much slower in updating even uncontroversial information. Cdr. Erwin Smith (talk) 13:26, 4 September 2025 (UTC)[reply]
Well, it'd be a binding rule for the few individuals who have had the limit imposed on them. I think that judicious application on those of us who are verbose (a group that includes me) has some real potential.
I think that one comment per day might have different/separate value. There are some editors whose names you just dread seeing on a talk page, because they seem to have nothing else to do than to reply as quickly as possible. I get it; back when I was a newbie, I remember one day refreshing my watchlist just to see what the reply was, and apparently the other editor was doing the same. With experience, you learn the value of letting the other person's reply sit for a day. It gives everyone a chance to level out emotionally, and gives other editors a chance to join the discussion. WhatamIdoing (talk) 15:04, 4 September 2025 (UTC)[reply]
I agree, mostly.
In case of the ruling violation penalty, I think it'd be better to modify it with an increasing time-limit : 1st violation> 1 Day, 2nd> 2 Days, 3rd> 4 Days, 4th> 8 Days, 5th> 16 Days & so on. Furthermore, if the man behaves well, his penalty should be reduced by 1 Level/30 Days (Eg. 32 Days to 16 Days).
This can be applied, both in case of the CTOPs, and the 1 Comment/Day proposal being discussed. I suggest so because I believe everyone deserves a chance of rectification. Although, it would require quite a bit of work to be done by the coders. Cdr. Erwin Smith (talk) 15:30, 4 September 2025 (UTC)[reply]
I don't think it's handled this way. If you're under this restriction, you've been give personal notice. Maybe on a first violation, especially if it's been a while since your last problem, the admin would revert the 'excess' comments and remind you about the rule. But mostly I think you'd expect the standard escalating blocks (often 1–3 days, 1–2 weeks, 1 month, 3 months, indefinite/until you can convince an admin that you won't repeat the same mistake, but there is no required pattern.) WhatamIdoing (talk) 15:42, 4 September 2025 (UTC)[reply]
This is my suggestion, nevertheless.
I think a couple of lines of coding would be much more neutral compared to human emotions, which would vary from one admin to another.
Personally, I don't think individual restrictions on commenting frequency is a good approach. I sympathize with the concept of cringing at rapid-fire off-topic comments from person X, but I think restricting one person would just encourage other participants to progress further without that person. When their personal respite period ended, person X would probably make a massive catchup comment, and the discussion could get fragmented each time it has to reset to cover this megacomment. I would prefer a round-robin discussion phase, where all participants are throttled, and a moderator flexibly manages when to proceed to the next round of comments, and when enough progress has been made to end the round-robin phase. isaacl (talk) 17:17, 4 September 2025 (UTC)[reply]
I think that "individual restrictions on commenting frequency" amounts to "Stop WP:Bludgeoning or I'll block you", and I'd rather have one comment a day than a block.
I see these possibilities:
Someone is bludgeoning the discussion, to the point that nobody else wants to participate in the discussion. They keep it up. The dispute ends up at the dramaboards for edit warring.
Someone is bludgeoning the discussion, to the point that nobody else wants to participate in the discussion. They get blocked for a while. During this time of relative calm, the rest of the editors achieve a consensus. The blocked editor vehemently disagrees, but consensus is reached, and when the blocked editor reappears (and probably re-edit wars), uninvolved editors can see that a consensus exists.
Someone is bludgeoning the discussion, to the point that nobody else wants to participate in the discussion. They are told that they can post one comment per day. During this time of relative calm, the editors have a discussion that reaches consensus. The restricted editor vehemently disagrees, but consensus is WP:NOTUNANIMITY, and with the lower volume, uninvolved editors can see that a consensus exists.
Personally I think if someone's participation is not desired any longer due to their uncooperative behaviour impeding progress, restricting them from any participation is the appropriate remedy. Restricting them to one comment a day is giving the false impression that their contributions are welcomed. If their contributions are still desired, just with a lower frequency, then in order for them to have a roughly equitable amount of input to the discussion, everyone else's contributions should be throttled down to a similar frequency. isaacl (talk) 23:21, 4 September 2025 (UTC)[reply]
I think most editors "self-throttle" (whether intentionally or due to external commitments), so restricting one or two people often has the same effect as throttling down everyone's contributions.
I've also been in conversations with people who I think are hopelessly bad at the process of collaboration and developing consensus, but who provide important information about the subject matter. I don't want to spend all day arguing with them (which is saying a lot, from me) or to read thousands of words from them, even though I have benefited from them saying "You've misunderstood that source" or "You've got Alice and Bob backwards" or "We need to pay more attention to _____". WhatamIdoing (talk) 23:39, 4 September 2025 (UTC)[reply]
That hasn't been my personal experience. I see editors continuing on, assuming that an agreement between themselves on one assumption is sufficient to starting building upon, and then chains of assumptions get built up. Then when someone who's been away for a while chimes in, their input can get lost, especially if they follow the usual convention of directly replying to the corresponding comment.
A frequency limitation won't end the need to read thousands of words; they'll just be delayed by a period of time and accumulate responses to everything that has been said in the meantime. A word limit might be more effective (though that depends on whether or not the editor chooses to keep the information you find important within the limited number of words). isaacl (talk) 00:21, 5 September 2025 (UTC)[reply]
In your scenario (editor stays away for a month, and comes back to say all the same things later), I don't see why one comment per day for a month is worse than blocking the editor for a month. WhatamIdoing (talk) 20:16, 5 September 2025 (UTC)[reply]
The scenario I discussed was if someone's participation is no longer desired due to their uncooperative behaviour impeding progress, then restrict them from any participation. The discussion would reach its conclusion without the disruption of the unwelcome editor. isaacl (talk) 03:45, 8 September 2025 (UTC)[reply]
Yes, the discussion would reach its conclusion without the blocked editor. But as we've both seen, the minute the block is lifted, the problematic editor will be back on the talk page saying that we need to discuss this again, because the article is wrong.
That postpones a problem. One comment a day might change the editor's behavior. If you spend a long while being required to think "I only get one comment today, so what is the single most important thing for me to say?", you might learn how to participate in a discussion without WP:Bludgeoning it. WhatamIdoing (talk) 22:17, 8 September 2025 (UTC)[reply]
If an editor's participation is no longer desired due to their uncooperative behaviour, then restrict them from any participation – namely, an indefinite topic ban. isaacl (talk) 22:59, 8 September 2025 (UTC)[reply]
I wrote a custom restriction a few years ago like this, which is categorized at WP:EDR as an "anti-bludgeoning restriction" (which appears to be the only place on that page that that phrase is used). It says that its subject is banned from making more than two comments per discussion per day, [but] may ... reply to questions provided the answer is reasonably short and ... may add very brief clarifications of their own comments. -- Tamzin[cetacean needed] (they|xe|🤷) 07:00, 1 September 2025 (UTC)[reply]
Reminds me of one in 2017 where we topic-banned someone but left an exception for may make a single !vote with a short (<300 words) rationale if the discussion calls for !voting, and give single short replies (<300 words) to other editors when directly asked a question (1 reply per direct question). It was just categorized as "topic ban" on WP:EDR though. ArbCom later superseded that one with a topic ban lacking that exception. Anomie⚔12:22, 1 September 2025 (UTC)[reply]
I'll try to write the problems highlighted so far, and the potential solutions.
Problem on 1 Comment/Day : Problematic editor will just write a single heap of text which will cover all his counters against the arguments made by his opponents throughout the day.
Problem on Word Limit : Problematic individual may be lesser represented.
Problem on Complete Ban : Problematic editor's viewpoint could be missed, and the editors having the opposite PoV could end up in a dominating position (I might as well add that this exact thing happened to me because of a delayed clarification from the Page Admin, of a rule suggested to me earlier by another Admin. Since then, the 2-3 ECUs having an opposite PoV started enjoying a field day of WP:POVPUSH against a handful of interested ECUs).
Potential Solution : To encourage neutrality and discourage disruption, a system that penalises bad behaviour, while incentivising the good will be perfect. I suggest the existing 'Word Limit' system be modified to add the timeout feature I suggested earlier.
An increasing time-limit : 1st violation> 1 Day, 2nd> 2 Days, 3rd> 4 Days, 4th> 8 Days, 5th> 16 Days & so on. Furthermore, if the man behaves well, his penalty should be reduced by 1 Level/30 Days (Eg. 32 Days to 16 Days).
Your proposal is too expensive in terms of admin/enforcement time. There are no school teachers or playground aides watching the students all day long, to decide whether someone is being disruptive today and, if so, to order an exponentially increasing series of time-outs. The approaches that usually work are simple, objective, and absolute: "One comment per day" or "500 words per discussion" instead of "Do what you feel like, and if teacher subjectively decides your behavior is bad, she will send you to the timeout bench". WhatamIdoing (talk) 14:20, 11 September 2025 (UTC)[reply]
"500 words per discussion" will stay. What I'm suggesting is to add the dynamic timeout feature to it.
Regarding Admin's time, my experience has been different. I got investigated for WP:PROXYING almost instantaneously. So I think they will have sufficient time to deal with this kind of a job.
Besides, most of the process will be automated. Admins will just have to enforce the restriction, and the rest of the process will be done automatically based on the behavioural data of the specific users stored in the servers. Cdr. Erwin Smith (talk) 16:20, 11 September 2025 (UTC)[reply]
As I believe I've told you before, we already use a "dynamic" block length, but we add something called "good judgment" to it. So instead of always increasing block length, we say things like "It's been five years since his last block, so we can restart with a short one" – or "He's made the same mistake repeatedly for five years, and even though he hasn't gotten blocked in the meantime, it's time for a long one". Or we say "He was blocked for edit warring in the past, but this is a completely different problem, so I can do a short block now." WhatamIdoing (talk) 16:52, 11 September 2025 (UTC)[reply]
Also, we really don't want people to be thinking "Hmm, I've only been blocked once before, so if I do this, I'll have a 48-hour block. I think breaking this rule is probably worth the chance of a 48-hour block, especially since I'll be out of town this weekend, so I won't be able to edit much during those 48 hours anyway." WhatamIdoing (talk) 16:55, 11 September 2025 (UTC)[reply]
That's why I too had given my example as a proof that Admins might not always possess a good judgement. Explaining the rules after an instant perma-ban in particular takes away all incentives to act better.
My suggestion is an escalation ladder, which people can climb up/down based on their own acts. Admins will always be the ones to report, but the rest will be dictated solely by the actions of the individual, good or bad.
This is not, however, intended as a memorial posting, as that has been taken care of elsewhere. This is a notification that the deceased editor left behind a large number of drafts in various stages of completeness, and it is the Wiki thing to do to honor the editor's contributions (and the potential interest of readers) by ensuring that those drafts that can be completed and turned into useful mainspace articles will, in fact, be completed. If anyone has interest in taking this further, this list could be subdivided by topic area and subsets could be directed to the attention of relevant Wikiprojects. The list follows. BD2412T03:12, 8 September 2025 (UTC)[reply]
As the user is deceased. Is this possible for someone working on one on these drafts to send it on the mainspace ?
The drafts are on the userspace , I don't know if someone can send a draft to the mainspace if this is not his/her/its own userspace.
I didn't read all the drafts but if someone is able to work on any on these drafts.
I don't know if this person should make a copy-paste on his/her/its own userspace or if it can be send to the mainspace from the userspace of MichaelQSchmidt. Anatole-berthe (talk) 17:09, 9 September 2025 (UTC)[reply]
@Anatole-berthe: Yes, it is possible to move the articles from userspace to mainspace, or from userspace to draftspace for further work (although, if moved to draftspace, they would be deleted if not worked on for six months). This content should not be copy/pasted, as that would break the edit history. BD2412T17:54, 9 September 2025 (UTC)[reply]
Note: Several of these are for articles that were separately created in mainspace by other editors. These should be checked for content that can be merged into the mainspace articles. They are:
Could someone who knows what has to be done, please, add the "Now Commons" mark into File:Diatret.jpg? The file is an exact duplicate of c:File:Cologne Diatreta detail.jpg. If you want to export the file from Enwiki to Commons you will get this information, as well. As an aside I would be interested what has actually to be added or edited in File:Diatret.jpg page to get the "Now Commons" information. — Speravir – 00:49, 12 September 2025 (UTC)[reply]
I wanted to say something on the Wikimedia Discord... until I saw it wasn't there. I think I got banned cause when I tried rejoining I could not. I had some... questionable behaviours but for sure not enough to get banned without notice. I also don't know how long is the ban. Brickguy276 (talk) 05:55, 12 September 2025 (UTC)[reply]
Display newcomer homepage. However disabling it also disables your homepage. isaacl (talk) 00:08, 16 September 2025 (UTC)
This section is resolved and can be archived. If you disagree, replace this template with your comment. Thank you. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:25, 14 September 2025 (UTC) 
Done nowiki'd that page. — xaosflux Talk 15:12, 15 September 2025 (UTC)
View all 24 community-submitted tasks that were resolved last week. For example, a bug was fixed that affected users who used the page-tabs to switch from wikitext editing of a section into the visualeditor. [27]
You are invited to join the discussion at Wikipedia:Village pump (proposals)#What to do with Template:Updated?. Sapphaline (talk) 12:37, 17 September 2025 (UTC)
from Wikipedia, the free Encyclopedia." Here I placed the icon after the phrase introducing the article class since it looked akward to have it immediately following the indefinite article "A" when I tried that first. Gramix13 (talk) 02:52, 8 July 2025 (UTC)
) next to the article title? TompaDompa (talk) 18:12, 22 July 2025 (UTC)
Display an assessment of an article's quality in its page header (documentation). Dan Leonard (talk • contribs) 16:37, 4 August 2025 (UTC)
.html#/media/File%3AWikimedia_Commons_Special-UploadWizard_2025-08-28_01-15-32.png){kind=link}
ambox.speedy .delete
ambox.content
ambox.style Not Codex, but is the OOUI for style icon...
ambox.notice
Option 2 ambox.notice
with 
but otherwise everything else looks good. Aasim (話す) 04:14, 11 August 2025 (UTC)
would be the most visually similar one, although 
or 
convey better the idea of looking for references in my opinion. Any of those would be fine to me.The icon in {{Unreliable sources}} also matches well with 
, if we take the rectangle being searched to represent the article rather than the sources). 
is closer visually, but could be more confusing as "question mark in rectangle" is a very common symbol and makes it less clear that the rectangle represents the article.{{Disputed}} easily gets 
.For {{Speculation}}, Codex sadly doesn't have a crystal ball yet (although I could make one in the Codex style if needed). The closest "magic woo" icons (and that's a stretch) are 
or 
.{{Current}} and {{Recentism}} can get different colors of 
.{{Globalize}} gets 
. Chaotic Enby (talk · contribs) 18:19, 15 August 2025 (UTC)
.jpg/20px-Broom_(PSF).jpg)
. Not good. Even rotating it 45 degrees doesn't really fix the issue: Aasim (話す) 07:00, 12 August 2025 (UTC)
(File:Codex icon edit.svg), to indicate issues that editors can solve?
(a generic tag icon) or 
(yes, it's officially the recent changes icon, but simple icons like this are very polysemic). Chaotic Enby (talk · contribs) 14:12, 12 August 2025 (UTC)
, but it goes a bit too far in the other direction. Surprised we don't have amber in the Codex or OOUI color palettes. Chaotic Enby (talk · contribs) 17:36, 13 August 2025 (UTC)
? Aaron Liu (talk) 18:28, 20 August 2025 (UTC)
→ 
→ 
(but modified to have an X inside rather than an !)
→ 
→ 
→ 
→ 
. Chaotic Enby (talk · contribs) 19:34, 18 August 2025 (UTC)
as well. –LaundryPizza03 (dc̄) 16:54, 21 August 2025 (UTC)
. The icons do look nicer on colored backgrounds that match them, but otherwise when not on a matching color it can look a little hideous. But a hideous color that is still legible is better than un-dark-modeable colors like the white clock that cannot be changed to black as inverting would mess up the color of the hands and the stop X. And on Vector 2022 and Minerva it seems broken, I don't know why. Aasim (話す) 03:27, 20 August 2025 (UTC)
, which has a white interior and is currently in use at kowiki's equivalent of Template:Uw-ublock. –LaundryPizza03 (dc̄) 16:55, 21 August 2025 (UTC)
→ 
→ 
→ 
→ 
(illustrative example only not a suggestion!).
Previous
New
This article documents a current event. Information may change rapidly and initial news reports may be unreliable. The latest updates to this article may not reflect the most current information. Feel free to improve this article or discuss changes on the talk page, but please note that updates without valid and reliable references will be removed.
This article documents a current event. Information may change rapidly and initial news reports may be unreliable. The latest updates to this article may not reflect the most current information. Feel free to improve this article or discuss changes on the talk page, but please note that updates without valid and reliable references will be removed.
) meshes well with the Codex signs and the proposed broom icon; it could be used for Template:Globalize if the Codex-style symbols are adopted for generic use. –LaundryPizza03 (dc̄) 17:06, 21 August 2025 (UTC)
wikimedia.org for advice.
.jpg/250px-Desire_path_(19811581366).jpg)
