Policy | Technical | Proposals | Idea lab | WMF | Miscellaneous |
The proposals section of the village pump is used to offer specific changes for discussion. Before submitting:
- Check to see whether your proposal is already described at Perennial proposals. You may also wish to search the FAQ.
- This page is for concrete, actionable proposals. Consider developing earlier-stage proposals at Village pump (idea lab).
- Proposed policy changes belong at Village pump (policy).
- Proposed speedy deletion criteria belong at Wikipedia talk:Speedy deletion.
- Proposed WikiProjects or task forces may be submitted at Wikipedia:WikiProject Council/Proposals.
- Proposed new wikis belong at meta:Proposals for new projects.
- Proposed new articles belong at Wikipedia:Requested articles.
- Discussions or proposals which warrant the attention or involvement of the Wikimedia Foundation belong at Wikipedia:Village pump (WMF).
- Software changes which have consensus should be filed at Phabricator.
Discussions are automatically archived after remaining inactive for 7 days.
RfC: merging Wikipedia:Requests for comment/User names with AN(I)
[edit]- The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.
Should Wikipedia:Requests for comment/User names be merged to WP:AN/WP:ANI? HouseBlaster (talk • he/they) 16:16, 14 September 2025 (UTC)
Survey (merging Wikipedia:Requests for comment/User names with AN(I))
[edit]- 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)
- I really like the use a subsection of UAA, which gets a community opinion of informed editors. HouseBlaster (talk • he/they) 17:51, 14 September 2025 (UTC)
- 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)
- I also support making it a subsection of UAA. Chaotic Enby (talk · contribs) 18:59, 14 September 2025 (UTC)
- 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)
- Support WP:AN or the suggestion in the discussion below for WP:UAA. Oppose WP: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)
- 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)
- 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)
- 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)
- Oppose, largely as per Tamzin. We have a process and namespace already established and relied upon for this purpose, and there's absolutely no showing that it currently results in any issues of note. The vaguely ideological and (no offense to any party intended) fairly oversimplified argument that we should reduce and consolidate our processes wherever possible is, imo, uncompelling--at least in this instance where no evidence of confusion, substantial inefficiency in use of community resources, or abuse of process has proven demonstrable. The infrastructure of this project simply is a sprawling bureaucracy, by dent of the work we do and the challenges of coordinating so many different users with roughly equal standing across our consensus model. I'm very much with Tamzin especially with regard to their comments in the RFCBEFORE discussion, in that I do not think that "too many noticeboards" is really an issue for the project, let alone one of such magnitude that we should begin a process of eliminating niche administrative spaces without a substantial showing of need and funneling all of their traffic into an increasingly smaller number of work spaces. Indeed, I think the siloing of workflows is broadly speaking very healthy for our throughput and capacity and a not-insignificant part of the formula that keep the gears cranking here. I'm especially skeptical of diverting more discussion to AN/I as the supposedly most rational solution in this instance, as those boards have some of the most notoriously difficult issues with discussion tracking and admin response fatigue due to the number and variety of discussions that already take place there, the outsized attention demanded of controversial discussions, and just a lot getting lost in the mix because of the volume of contributions. Name change discussions tend to be relatively simple, straight forward and non-controversial, and moving them from a space where they seem to be readily and non-problematically resolved into the same fora that, depending on a given week, may be absolutely drowning in content and high emotions seems highly counter-intuitive to me. SnowRise let's rap 21:18, 22 September 2025 (UTC)
- Oppose Per other users. >^CreativeLibrary460 /access the library revision\ 05:57, 23 September 2025 (UTC)
- Oppose per Tamzin and throw signature issues there as well to give it more purpose. CNC (talk) 21:14, 26 September 2025 (UTC)
- Oppose per Tamzin, add sigs. --SarekOfVulcan (talk) 21:17, 26 September 2025 (UTC)
- Support this proposal and any alternative merge destination. Unlike some of my colleagues here I do think having too many noticeboards is a problem, and merging this one to AN or UAA would draw more attention to these discussions. I have no preference between those venues, but I do prefer these go on the main page and not a subpage, as that would kinda defeat the point of merging. Toadspike [Talk] 22:40, 26 September 2025 (UTC)
- To clarify, the proposal mentioned above was for a subsection (on the same page, with a separate header), not for a subpage. Chaotic Enby (talk · contribs) 22:44, 26 September 2025 (UTC)
- Support WP:AN, I do think we have too many venues. FaviFake (talk) 18:49, 30 September 2025 (UTC)
Discussion (merging Wikipedia:Requests for comment/User names with AN(I))
[edit]- Courtesy link to the VPI discussion; courtesy pings to participants at that discussion: @SuperPianoMan9167, WhatamIdoing, Tamzin, Chaotic Enby, and ScottishFinnishRadish. HouseBlaster (talk • he/they) 16:16, 14 September 2025 (UTC)
- Should it not be merged with WP:UAA? 331dot (talk) 16:33, 14 September 2025 (UTC)
- 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)
- From what I understand, UAA is for more clear-cut requests in the style of WP:AIV and wouldn't mesh as well with a RfC-like format. Chaotic Enby (talk · contribs) 16:42, 14 September 2025 (UTC)
- 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)
- 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)
- 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)
- Maybe "Usernames awaiting attention" to keep the acronym? Chaotic Enby (talk · contribs) 18:58, 14 September 2025 (UTC)
- 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)
- I appreciate what you are getting at, and don't disagree, and maybe there is something to be gained in our volunteer culture from making such changes, but I also tend to think there is nothing really wrong with keeping a slightly outdated and idiomatic title, once it has been grandfathered in for so long. It's really been a very, very long time since I've seen anyone, even a new user, imply that (for example) AN or ANI should be left to the mops. SnowRise let's rap 21:22, 22 September 2025 (UTC)
- 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)
- 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)
- 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)
Currently, we block all WP:Tor exit nodes such that any user wanting to edit through a Tor exit node would first need to contact a administrator and obtain the WP:IPBE user right before making any edits. (i.e. convince a admin that you will edit constructively and not sock, which is a much higher bar than typical autoconfirmed). However, currently MediaWiki artificially extends the period of time a user needs to edit for to be autoconfirmed to be atleast 90 day with a edit threshold of 100 edits. Given the way we currently handle Tor IPs, adding this extended time period seems counter intuitive. Would it be a good idea to remove the 90 day, 100 edit barrier for WP:AC users (especially those who have been granted IPBE)? (cc @W00zles and @Stwalkerster who were involved in the request, and @Risker, who I know has a lot of institutional knowledge of why certain features were implemented v/s weren't) -- If the community is okay/open to the idea of reducing/removing the WP:AC time/edit extension, I'll file a phabricator task to reduce the period! Sohom (talk) 20:07, 26 September 2025 (UTC)
- I'm generally supportive, but a couple of points. Global IPBE (torunblocked) can be granted by stewards, even for accounts which don't exist on this wiki. In those cases, and in some cases on this wiki, the bar can be very low - often we'll just take a look whether we believe someone is in China, or Iran, or wherever. No edits required. That said, having a high bar for AC doesn't really add much in today's environment. -- zzuuzz (talk) 20:34, 26 September 2025 (UTC)
- I support this motion. I will admit that this directly benefits me as a Tor editor. Failing the accepting of this proposal, I would ask that the tools that check for autoconfirmed to be unified. A lot of sources don't agree with the autoconfirmed status of Tor users. The MediaWiki API returns that I am confirmed, but the internal tools such as Special:UserRights indicates to me I only have IPBE. My Preferences page also disagrees with the API. W00zles (talk) 21:58, 26 September 2025 (UTC)
- Some groups are actually assigned in the database, while others are implicitly assigned at runtime. It appears that TorBlock changes the implicit assignment based on the source of the incoming request, so you when using Tor you'll see the higher requirements being applied even when you look at the implicit groups of other users who never use Tor. OTOH, if you're making the API request via Tor and it's not applying the higher requirements, that's probably a bug. Anomie⚔ 22:18, 26 September 2025 (UTC)
- Z@Anomie, I think the problem here is that they see very different results compared to me, if I make a query through the API, I see them as autoconfirmed, whereas when they try to edit a page that has a autoconfirmed restriction, they can't. If the answer is "keep the extended period", then we need better tools as administrator to know that this restriction is being applied. Sohom (talk) 13:37, 27 September 2025 (UTC)
- Some groups are actually assigned in the database, while others are implicitly assigned at runtime. It appears that TorBlock changes the implicit assignment based on the source of the incoming request, so you when using Tor you'll see the higher requirements being applied even when you look at the implicit groups of other users who never use Tor. OTOH, if you're making the API request via Tor and it's not applying the higher requirements, that's probably a bug. Anomie⚔ 22:18, 26 September 2025 (UTC)
- I'm not certain what your proposal is here, so I'll give two answers. I think I'm opposed to reducing Tor autoconfirmed status below non-Tor status especially if GIPBE allows Tor editing, but I don't have any reasons why we shouldn't equalise it between Tor/non-Tor while a blanket ban on non-(G)IPBE Tor users exists so I'm weakly supportive of that. stwalkerster (talk) 22:28, 26 September 2025 (UTC)
- To clarify, I want it back to normal levels that any other non-auto-confirmed user would face. Sohom (talk) 13:32, 27 September 2025 (UTC)
- I support. Tor requires IPBE, which isn't exactly an easy feat for a new user. I don't see much of a reason to have the higher bar these days, with the global ban on Tor. EggRoll97 (talk) 15:20, 27 September 2025 (UTC)
- Responding to ping. Tor is a form of open proxy, which is generally banned throughout the Wikimedia world for a lot of complex reasons. There are attribution issues, there is the longterm dramatically higher rate of vandalism, and there is the simple fact that Tor historically was used regularly by two groups: vandals and activists of various stripes. I genuinely do not know if the extended period for autoconfirmed applies only to those using Tor, or if it applies to all users with IP block exemption. (Logically, it should apply to all accounts with IPBE, because there is no "special" permission above that to enable access via Tor.) All known Tor exit nodes are blocked globally, and pretty much have been since the "no open proxies" global policy and philosophy was introduced. In response to EggRoll97, I can honestly say that probably 1/2 of IPBE requests coming in through the central checkuser VRT queue are from comparative newcomers; in about 5-10% of cases, we actually have to create their accounts for them. It's really not hard to find us or to ask for it. I'd suggest that the real debate here is whether the no open proxies policy needs to be revisited, in light of (often justified) concerns about personal internet security throughout the world, not just regions with authoritarian governments. I realize that doesn't really answer the subject of this thread, but on reading things through, I can't tell if this is a local issue or a global one; and given my personal opinion on autoconfirmed is that I'd rather increase the requirements for everyone, I'm probably not the best person to weigh in. Risker (talk) 15:43, 27 September 2025 (UTC)
- My recollection of the discussion is that there was seeming consensus for 7 days/20 edits, but (as I recall), the devs went with 4/10, as a preliminary test. Perhaps enough time has gone by to revisit this. - jc37 04:24, 14 October 2025 (UTC)
- I should clarify, my main reason for calling it not an "easy feat" is the specific case you mentioned, which is that they would need to go through the VRT queue. That's already a lot just to get an account created, involving manually contacting CheckUsers (I don't believe there's really an automated way to just submit a request to the CU VRT queue). I know it probably doesn't sound like a lot of work, but comparatively to just creating an account as normal, that's a much more involved process.
- Side note, I do think it probably would be good to start discussing autoconfirmed being bumped a bit, the low standard may be intentional, but it feels far too easy to game autoconfirmed socks with the current requirements. EggRoll97 (talk) 16:21, 27 September 2025 (UTC)
- I can say in my personal experience attempting to get my account usable was a real challenge. I had to go to an admin in real life and ask them to confirm me. I never got a response from the stewards when I made the IPBE request after getting my account made for me over Tor, leaving me with little ability to do anything.
- I am not opposed to a raised autoconfirm requirement due to vandals but I do think, as mentioned in the other reply thread, it should be equal at a minimum between IPBE and not. W00zles (talk) 23:10, 29 September 2025 (UTC)
- Per the generally positive outlook, I've filed a RFC below. -- Sohom (talk) 14:56, 3 October 2025 (UTC)
RFC: Should we equalize/remove the difference in autoconfirmed time between non-Tor and Tor users
[edit]![]() |
|
Background, currently, we block all WP:Tor exit nodes such that any user wanting to edit through a Tor exit node would first need to contact a administrator and obtain the WP:IPBE user right before making any edits. (i.e. convince a admin that you will edit constructively and not sock, which is a much higher bar than typical autoconfirmed). However, currently MediaWiki artificially extends the period of time a user needs to edit for to be autoconfirmed to be atleast 90 day with a edit threshold of 100 edits. This is enforced by the the TorBlock extension which was added some time in 2008. Since then, our policies have shifted, in the current day, due to our No open proxies rules, editing through Tor exit nodes are typically always blocked locally (and many times globally). Due to this, the bar for editing through Tor proxies has become "request the IPBE userright" + the aformentioned extended autoconfirmed userright. Given this, I would like to propose that we remove the special extended time period to get autoconfirmed for Tor users, and instead equalize the bar for recieving the autconfirmed userright for both Tor and non-Tor users. -- 14:56, 3 October 2025 (UTC)
!Votes
[edit]- Support, per what I have said above, getting IPBE userright is not a small task for users with no edits to show (since the bar often used is "has constructive contributions/will not edit disruptively" which is hard to show when you are blocked from making any edits). As such, the bar for getting IPBE is a higher one than to be autoconfirmed (which for normal users is 4 day and 10 edits) and given that IPBE is basically mandatory to edit through Tor, it does not make sense to create another meaningless hurdle here. Note that this proposal does not preclude (and is mutually exclusive from) discussion about increasing the level required for autoconfirmed users for everyone. -- Sohom (talk) 14:56, 3 October 2025 (UTC)
- Support per Soham Datta, the proposal and the preceding discussion. There is no reason to treat tor and non-tor users differently in this regard. Thryduulf (talk) 17:06, 3 October 2025 (UTC)
- Support * Pppery * it has begun... 17:08, 3 October 2025 (UTC)
- Support, Being on the receiving end of this policy, it's difficult to do useful work that would be expected of a typical editor. W00zles (talk) 23:11, 5 October 2025 (UTC)
- Support. The current rule is unnecessary given that IPBE provides a higher level of gatekeeping. -- Tamzin[cetacean needed] (they|xe|🤷) 03:50, 10 October 2025 (UTC)
- Support per all above; a leftover rule from an earlier time that is a needless layer of beuraucracy and woild be better off gone. CoconutOctopus talk 17:50, 12 October 2025 (UTC)
- Support. fifteen thousand two hundred twenty four (talk) 20:06, 12 October 2025 (UTC)
- Support. Using any other VPN through IPBE probably doesn't suffer from this issue. If we believe that autoconfirmation needs to have higher thresholds for people editing from blocked addresses, then that should be the criterion, not the use of a specific anonymization service. ~ ToBeFree (talk) 21:38, 13 October 2025 (UTC)
- How would that work? Just setting autoconfirmed to X for anyone with IPBE? Interesting idea. Though I think admins get that by default as well. I think it's worth discussing. - jc37 04:29, 14 October 2025 (UTC)
- @Jc37, In essence this would just be a mediawiki configuration change which removes/resets two configuration values to 0 (which previous defined the elevated cap for Tor users) Sohom (talk) 15:10, 14 October 2025 (UTC)
- How would that work? Just setting autoconfirmed to X for anyone with IPBE? Interesting idea. Though I think admins get that by default as well. I think it's worth discussing. - jc37 04:29, 14 October 2025 (UTC)
Discussion
[edit]Permission to create beetle articles at a pace that exceeds the normal limit
[edit]Hello everyone. I have been creating stubs and expanding existing articles on beetle species for a while. They range from very short, to start class (I guess). If they are very short, they always include: a taxobox (with all relevant info, including all synonyms), distribution of the species and host plant/prey (if known). It seems I create articles at a pace that has raised some eyebrows for some fellow wikipedians. See: User_talk:B33tleMania12 and Wikipedia_talk:Notability_(species) to read all about it. What I am requesting is permission to add beetle articles like I am doing (which may include a range of these very short articles). I was told that the normal daily limit is between 20-50 articles per day. I guess that if I could get a waiver to create about 100 per day, that would at least make clear to everyone that it is ok what I am doing. That being said: I am now working on a source that allows me to create these very short basic stubs. I do intend to get back to making more sizeable articles after that, see for examples all species articles I created for this genus Cephaloleia (but I might in the future like to work on a list of these basic stubs again if I find a good source). B33tleMania12 (talk) 22:26, 26 September 2025 (UTC)
- Oh, I dont make automated or semi-automated articles. I use a template in notepad which includes the static info. That is why the request is not a pure MASSCREATE request. B33tleMania12 (talk) 22:29, 26 September 2025 (UTC)
- And to add some more, this type of article is what people are opposed to Draft:Agoniella_horsfieldi B33tleMania12 (talk) 22:37, 26 September 2025 (UTC)
- I think this is okay. The subjects are all notable per Wikipedia:Notability (species), and there is basically no chance of them being deleted. A spot check shows that he's citing two sources in each stub. The {{Taxonbar}} links indicate that most of these have another half-dozen reliable sources available. Unlike other species, there doesn't seem to be an authoritative, comprehensive database for beetles, so I'm glad that he's checking them individually. Looking at articles such as Brontispa cyperaceae, even the shortest ones provide basic information (name, type, family, location, what it eats), plus the usual {{Speciesbox}}. Articles such as Gonophora whitei provide even more (that one even qualifies for WP:DYK).
- "The normal rate", or at least the normal maximum under WP:MASSCREATE, is 25–50 articles per day. I think B33tlemania12 recently created about 100 or so articles in one day. That's a lot, but reviewing these is so much quicker and easier than for, e.g., BLPs, that it's IMO not unmanageable on our end. I have seen discussions about the creations, and none of the comments are about an unfair load on page patrollers.
- Based on prior discussions, I believe that any complaints will take one of two forms:
- People who want everyone to Wikipedia:Beef up that first revision will be unhappy that some of these are only a few sentences long, even if the creator goes back to expand them later – which the creator seems to do when sources are available.
- People who (incorrectly) think that systematic article creation (as opposed to hopscotching through whatever catches your eye) turns Wikipedia into a database. WP:NOTDATABASE is about not putting unexplained raw data into an article; it's not about writing an ordinary sentence about whether we know what a given beetle eats.
- As someone has unilaterally draftified a few of these, I want to say that there is no point in sending these through AFC; species articles are evaluated only for notability, which means that species articles get kicked right back out into the mainspace. (AFC's job is not "protect my delicate eyes from all these WP:UGLY little stubs"; it's job is to determine notability of the subject, rather than the beauty of the current revision, and to get pages moved to the mainspace as soon as the AFC reviewer is confident that the article is unlikely to be deleted if it's sent to AFD.)
- I don't think that either of these are valid reasons to prevent or slow down the creation of these articles. IMO these are decent, if usually brief, articles on obviously notable subjects, and the creator should be encouraged to continue creating articles with a minimum of two cited reliable sources. If someone wanted to create, say, 500 articles a day, then I think we should have another discussion, but for anything in the 500 a week range, I think we're just fine. WhatamIdoing (talk) 23:22, 26 September 2025 (UTC)
- " The links indicate that most of these have another half-dozen reliable sources available. " Nope. E.g. Aspidispa maai has 8 links in the taxonbar, but at least two of them (Wikidata and iNaturalist) are not reliable sources, others are not independent of each other: Open Tree Taxonomy is an automatic representation of data from GBIF, also included in the taxonbar, similarly Catalogue of Life is a rehash of ITIS, and ITIS is already a reference in the article anyway. I wasn't able to access BioLib (thanks to AI scrapers overload), but the others are at best interdependent databases, not a series of reliable independent sources. Fram (talk) 13:45, 30 September 2025 (UTC)
- Sources don't have to be independent of each other to be reliable. WhatamIdoing (talk) 19:14, 30 September 2025 (UTC)
- No, but we don't count them as multiple sources (e.g. multiple newspapers reposting the same Reuters report = one source). The Taxonbar doesn't indicate what you claimed it did. Fram (talk) 08:50, 1 October 2025 (UTC)
- The notability of a species doesn't depend on how many sources exist.
- Those links overlap, but I think most of those sources also contain some unique information. For example, in Aspidispa maai, the first link in the taxonbar has very little information, but gives the family's common name of 'leaf beetles'; the second link says that it's an accepted species, which isn't in the first, and doesn't say anything about the common name, which is; the third link says it has bilateral symmetry, which isn't in either of the prior ones, and so on. Unlike the example of a Reuters or other wire service article, they are not simply duplicates of each other. WhatamIdoing (talk) 15:30, 1 October 2025 (UTC)
- Your first sentence is a rpeply to nothing. The "first link in the taxonbar" is to Wikidata, which is not a reliable source. Like I said already. The second link is another wiki, again not a reliable source, third one is one I had no issue with, and then you "and so on" the ones I actually did discuss to indicate that your "another half dozen reliable sources" was incorrect (three wikis, one other already used as a reference, so immediately you are down to 4 anyway; and then something like the "Catalogue of Life" entry[1] is just a copy of ITIS, the exact same data presented in a different layout; this is not "another" reliable source, this is two instances of the same database (just like opentree is a gbid copy, not a new source). So the taxonbox on this article gives us two new databases. Fram (talk) 15:57, 1 October 2025 (UTC)
- Well, for this subfamily, there will always be at least three reliable sources (if you include ITIS and its 'copies' if you want to classify them as such). That is: 1. World Catalogue of Hispines, 2. The original description of the species (this must exist for it to be an accepted species) and 3. ITIS. For most, more will exist, but I think these three would be enough to get it at least at the level of Aspidispa maai (which could be longer if I would have included more detail about the species description, but I think that would make it too technical and I don't want to add words just to make a certain imaginary threshold. I do copy the full species description from old sources sometimes, because they are written in such a way that make it hard for me to rewrite (I do try to make proper sentences though, which is often not the case in the original. All of that being said: I wont be able to get access to point 2 sources (the original description) if they are behind a paywall or in a language I dont understand (and if google translate isnt able to make me understand). However: even if that part of the article would be missing (for now or worst case forever), as I understood it, these would still be acceptable articles. So the debate is not IF I am allowed to make them, but at which pace. At least, that was the intention of the discussion. To add to this (I wont use any user names to spare them the ) but I have seen other articles being added constantly that are lower quality (bare URLs, only one sentence, etc.) and I have looked at the Talk pages for these users, and there is no discussion (sometimes suggestions to improve, that are not followed by that user, at which point nothin happens), so I am wondering what that is about. Besides not following the suggestion to merge species into genus pages and making too many in a short amount of time, I have (I think) taken to heart every comment made by others to improve the articles. Anyway: I think there will be no end to this discussion and I don't know how this works now.. the question was if I could make more than the normal daily limit. So far, there is not a clear answer I think? B33tleMania12 (talk) 17:37, 1 October 2025 (UTC)
- I was not commenting on the request you made (although I would prefer in general that much more often similar short articles would be combined into lists, by all editors), I was commenting on typical clearly incorrect statements by WhatAmIDoing. Requests like yours should be discussed on their actual merits, not on misconceptions from other editors. Fram (talk) 08:21, 2 October 2025 (UTC)
- My first sentence ("The notability of a species doesn't depend on how many sources exist") is a reply to your comment that we don't count them as multiple sources – as if that could be a problem, given that WP:NSPECIES does not require multiple sources.
- I ignored Wikidata in counting the links, because obviously we don't use wikis as reliable sources. I'm not sure where BioLib falls in the WP:UGC spectrum. The website says "Unlike other systems such as Wikipedia users are not directly changing content of BioLib but the added data is added as "unconfirmed" and our administrators review it first before accepting it among verified data". This constitutes "editorial oversight", to use the wording in WP:V and WP:RS, but is it good oversight, or rather perfunctory? Someone would have to know more about that site than I do. At first glance, though, I wouldn't describe it as a wiki myself. WhatamIdoing (talk) 23:41, 2 October 2025 (UTC)
- Well, for this subfamily, there will always be at least three reliable sources (if you include ITIS and its 'copies' if you want to classify them as such). That is: 1. World Catalogue of Hispines, 2. The original description of the species (this must exist for it to be an accepted species) and 3. ITIS. For most, more will exist, but I think these three would be enough to get it at least at the level of Aspidispa maai (which could be longer if I would have included more detail about the species description, but I think that would make it too technical and I don't want to add words just to make a certain imaginary threshold. I do copy the full species description from old sources sometimes, because they are written in such a way that make it hard for me to rewrite (I do try to make proper sentences though, which is often not the case in the original. All of that being said: I wont be able to get access to point 2 sources (the original description) if they are behind a paywall or in a language I dont understand (and if google translate isnt able to make me understand). However: even if that part of the article would be missing (for now or worst case forever), as I understood it, these would still be acceptable articles. So the debate is not IF I am allowed to make them, but at which pace. At least, that was the intention of the discussion. To add to this (I wont use any user names to spare them the ) but I have seen other articles being added constantly that are lower quality (bare URLs, only one sentence, etc.) and I have looked at the Talk pages for these users, and there is no discussion (sometimes suggestions to improve, that are not followed by that user, at which point nothin happens), so I am wondering what that is about. Besides not following the suggestion to merge species into genus pages and making too many in a short amount of time, I have (I think) taken to heart every comment made by others to improve the articles. Anyway: I think there will be no end to this discussion and I don't know how this works now.. the question was if I could make more than the normal daily limit. So far, there is not a clear answer I think? B33tleMania12 (talk) 17:37, 1 October 2025 (UTC)
- Your first sentence is a rpeply to nothing. The "first link in the taxonbar" is to Wikidata, which is not a reliable source. Like I said already. The second link is another wiki, again not a reliable source, third one is one I had no issue with, and then you "and so on" the ones I actually did discuss to indicate that your "another half dozen reliable sources" was incorrect (three wikis, one other already used as a reference, so immediately you are down to 4 anyway; and then something like the "Catalogue of Life" entry[1] is just a copy of ITIS, the exact same data presented in a different layout; this is not "another" reliable source, this is two instances of the same database (just like opentree is a gbid copy, not a new source). So the taxonbox on this article gives us two new databases. Fram (talk) 15:57, 1 October 2025 (UTC)
- No, but we don't count them as multiple sources (e.g. multiple newspapers reposting the same Reuters report = one source). The Taxonbar doesn't indicate what you claimed it did. Fram (talk) 08:50, 1 October 2025 (UTC)
- Sources don't have to be independent of each other to be reliable. WhatamIdoing (talk) 19:14, 30 September 2025 (UTC)
- " The links indicate that most of these have another half-dozen reliable sources available. " Nope. E.g. Aspidispa maai has 8 links in the taxonbar, but at least two of them (Wikidata and iNaturalist) are not reliable sources, others are not independent of each other: Open Tree Taxonomy is an automatic representation of data from GBIF, also included in the taxonbar, similarly Catalogue of Life is a rehash of ITIS, and ITIS is already a reference in the article anyway. I wasn't able to access BioLib (thanks to AI scrapers overload), but the others are at best interdependent databases, not a series of reliable independent sources. Fram (talk) 13:45, 30 September 2025 (UTC)
- I agree with the above that this seems OK. Being efficient and systematic are not problems. It sounds like enough care is being taken to avoid bad information being included in the encyclopedia, which is the most important thing. Stepwise Continuous Dysfunction (talk) 15:36, 27 September 2025 (UTC)
- I likewise agree. People may prefer longer articles, but these are longer than the alternative, which, unless you are prepared to write about the subject yourself, is of zero length. Phil Bridger (talk) 16:41, 27 September 2025 (UTC)
- Ok, thanks for your input all. I do not know how much time must pass to come to a conclusion, but I am going to at least move the drafted stuff back to Live. B33tleMania12 (talk) 12:04, 28 September 2025 (UTC)
- I think this is fine. Especially with species articles, stubs are much better compared to the longer articles of AI slop that we have been getting en masse in this topic area lately. Gnomingstuff (talk) 17:09, 27 September 2025 (UTC)
- I do question whether having separate articles on every species of beetle is the right approach (I would probably go with a list), but that is more a quibble with the notability guideline itself and not with the rate at which the articles are created. THAT is more an issue of not overwhelming new article reviewers. If they are comfortable with this, I don’t see a problem. Blueboar (talk) 17:12, 27 September 2025 (UTC)
- Oppose. If all the content you have for an article is this then please do not create a new article. Consider adding it to a list instead, as I have suggested to you multiple times. I do not understand why editors want to create so many low quality articles. You should get more satisfaction from writing a featured list and this would serve readers much better. In my opinion 25 new articles in a day is plenty, and allowing more means that editors will not be giving due attention to the new articles they create — Martin (MSGJ · talk) 08:26, 30 September 2025 (UTC)
- It is not the only thing I have, but like I said numerous times also: it is easier to first make the page at the right place (i.e. get the taxonomy right) before adding more detail. If I add more info right away, I have to do a dive into taxonomic changes for each individual species. The source to expand the article you just mentioned would be this: Wayback Machine, but I would like to get the species pages added first, so I don't waste time adding species that have now been placed in synonymy, moved to other genera, etc. B33tleMania12 (talk) 08:40, 30 September 2025 (UTC)
- Do we have any statistics that show how likely a separate article is to be expanded, as compared to an entry on a list? Intuitively it feels to me that a separate article is much more likely to be expanded. Phil Bridger (talk) 10:51, 30 September 2025 (UTC)
- The point of comparison would be what articles are created from a redlink on a list (or unredlinked item?), rather than expansion on the list itself. CMD (talk) 13:01, 30 September 2025 (UTC)
- Depends on the list? A table-formatted list, or one with descriptions for each item, might see expansion. A list of bare names (see Aspidispa#Species, for the example Martin gives) is unlikely to be expanded in the list. I guess the answer to your question is: B33tleMania12 made that list of redlinked species, and is now turning the red links blue, and Martin recommends that they should go make the list...that they already made. WhatamIdoing (talk) 15:25, 30 September 2025 (UTC)
- What was my question? CMD (talk) 17:22, 30 September 2025 (UTC)
- Depends on the list? A table-formatted list, or one with descriptions for each item, might see expansion. A list of bare names (see Aspidispa#Species, for the example Martin gives) is unlikely to be expanded in the list. I guess the answer to your question is: B33tleMania12 made that list of redlinked species, and is now turning the red links blue, and Martin recommends that they should go make the list...that they already made. WhatamIdoing (talk) 15:25, 30 September 2025 (UTC)
- The point of comparison would be what articles are created from a redlink on a list (or unredlinked item?), rather than expansion on the list itself. CMD (talk) 13:01, 30 September 2025 (UTC)
- I don't think it's a good idea to tell editors what kind of contribution "should" be satisfying to them.
- Also, Martin, the time to say that people should make lists instead of short articles was in Wikipedia talk:Notability (species)/Archive 2#Proposal to adopt this guideline (where that view was rejected). These aren't "low-quality articles". These are "short" articles. 16% of Wikipedia's articles have three sentences or less. 38% of Wikipedia's articles have two refs or less. These are not weirdly short outliers compared to the rest of Wikipedia's articles. WhatamIdoing (talk) 15:15, 30 September 2025 (UTC)
- Yeah, and I'd rather that admins didn't restore potential copyright violations[2] added by an editor with a history of source fraud, socking, and nationalist POV stuff, after being told they were likely copyright violations,[3], and I'd also really like it if their most recent article creation didn't have a bunch of close paraphrasing of a tourism site (ad) that they split from the main article, but I guess those were more satisfying? Beetle guy's article contributions are higher quality that than, anyway. If they want to make these articles, then I say let them. GreenLipstickLesbian💌🦋 09:39, 1 October 2025 (UTC)
- I'm with Martin, I don't support this but I also don't necessarily oppose it. It's worth noting that you've been denied autopatrolled twice, most recently in August, so I don't know if mass-creating would be the best idea. EF5 13:11, 30 September 2025 (UTC)
- To be fair, one of those denies was down to the fact that the editor creates articles that 'are easy reviews' (which did strike me as an odd rationale!) and the other was that the editor hadn't created any long articles (when they clearly create very short ones). It appears to me that many, many of these species type stubs are out there and the bar for creation (ie: not applying WP:GNG to the letter) appears to have long been set low for species stubs, no? Best Alexandermcnabb (talk) 14:20, 30 September 2025 (UTC)
- The GNG doesn't apply, because Wikipedia:Notability (species) is the relevant guideline. WhatamIdoing (talk) 15:16, 30 September 2025 (UTC)
- It's not that odd a rationale if you consider why autopatrol exists. It is a means of reducing the work involved in new page patrolling, rather than a hat to be collected. Phil Bridger (talk) 15:47, 30 September 2025 (UTC)
- Fair enough, but an editor creating hundreds of valid species articles (and I couldn't find one that NPP had rejected/tagged/draftified) could - and I believe should - be autopatrolled, even if each article isn't a huge overhead to review. But, hey, that's just me... Best Alexandermcnabb (talk) 16:10, 30 September 2025 (UTC)
- I did not ask for autopatrol myself, so I was not aware that I was 'denied'. I do not care for myself either, but I guess it would help others. Anyway: it seems reasonable not to give autopatrol too soon. You never know how that might turn out in the end. B33tleMania12 (talk) 16:32, 30 September 2025 (UTC)
- To be fair, one of those denies was down to the fact that the editor creates articles that 'are easy reviews' (which did strike me as an odd rationale!) and the other was that the editor hadn't created any long articles (when they clearly create very short ones). It appears to me that many, many of these species type stubs are out there and the bar for creation (ie: not applying WP:GNG to the letter) appears to have long been set low for species stubs, no? Best Alexandermcnabb (talk) 14:20, 30 September 2025 (UTC)
- It's fine I bet the boys and girls at New Page Patrol love you... The articles are indeed valid (and have been universally patrolled as such by NPP) and a nice, easy new page review at that! Best Alexandermcnabb (talk) 08:39, 30 September 2025 (UTC)
- haha yes, I must send them a huge thank you note one day B33tleMania12 (talk) 08:41, 30 September 2025 (UTC)
- Oppose this is a WP:PAGEDECIDE issue and here the answer is often "no". Instead of aiming for completion, we should ask: do these articles help the reader? And the answer is no, because the reader wants an encyclopedia article, which is not what they're getting. Wikispecies is a worthy project, but it's not this project. Microstubs which have very little hope of expansion aren't helpful; they're an annoyance. Cremastra (talk · contribs) 21:45, 30 September 2025 (UTC)
- I have a few suggestions for this. First, you could create pages in draft space and submit them for promotion. Second, as some have suggested above, you could start with list articles creating summaries of this information with many redirects pointing to those lists. BD2412 T 22:32, 30 September 2025 (UTC)
- AIUI redirects from (extant/non-fossil) species names are generally not wanted. See, e.g., Wikipedia:Redirects for discussion/Log/2023 August 12#Batillipes acaudatus and Template:R from species to genus. WhatamIdoing (talk) 22:42, 30 September 2025 (UTC)
- @WhatamIdoing Species to genus redirs are fine if there is, as BD suggests, actually information at the target. What generally get deleted is when the genus article is just a list of species which redirect back to the same article, with no actual information anywhere. Cremastra (talk · contribs) 22:58, 30 September 2025 (UTC)
- Sure, that is all possible. The way I wanted to work is create a basic stub and then use a source to expand them. Because this seems to keep going forever. I also refute the claims above that these 'can never be expanded'. So (as I already did before), I spend some extra time fleshing some out. If these are still not satisfactory, then I guess I am done with Wikipedia and wish future editors good luck with the bureaucrats. For the work I did the past hour on expanding: User contributions for B33tleMania12 - Wikipedia B33tleMania12 (talk) 22:43, 30 September 2025 (UTC)
- AIUI redirects from (extant/non-fossil) species names are generally not wanted. See, e.g., Wikipedia:Redirects for discussion/Log/2023 August 12#Batillipes acaudatus and Template:R from species to genus. WhatamIdoing (talk) 22:42, 30 September 2025 (UTC)
- Support. I have frequently encountered B33tleMania12's articles while doing new page patrolling. At first, I thought there was something up - the number of new creations in so short a time, and the brevity of the articles. But looking at new page criteria, all of the articles, while essentially stubs (at least initially) meet our criteria. Sure, there's an argument that they could be just some list articles, but they are being expanded, and - well, anyone is free to create a list article if they want? Why not both? (Also, Alexandermcnabb - yes! ;-) BastunĖġáḍβáś₮ŭŃ! 09:52, 2 October 2025 (UTC)
- This seems absolutely fine as proposed. Thank you for your work. MichaelMaggs (talk) 10:02, 2 October 2025 (UTC)
- Support. Up to 100 per day seems OK to me. These are not going to flood watchlists and there's no question of notability. Re the argument that they are permastubs: some are likely to remain stubs for a very long time, but as far as I can that's generally because there are a lot of them, not because they are inherently incapable of expansion. Mike Christie (talk - contribs - library) 11:22, 2 October 2025 (UTC)
- Support I don't see any problem with this. This is literally what we've been doing for a long time. Mikeycdiamond (talk) 13:43, 5 October 2025 (UTC)
- Question to B33tleMania12. Out of interest, how many articles are you intending to create? Apparently there's around 400,000 known species of beetle. WP:WikiProject Beetles remit covers about 45,000 existing articles, of which roughly 95% are stubs. Rupples (talk) 16:46, 5 October 2025 (UTC)
- So we're looking at about 400,000 articles. Is that an issue? It would be nice to have 400,000 images to go with them. But an enduring, free to access, record of them is a good thing, no? Best Alexandermcnabb (talk) 16:56, 5 October 2025 (UTC)
- I would say yes (create all of them), as long as the article is more than a bare taxonomic list, i.e., it has some description, and some indication of its range (I really dislike reading that a snail species is "endemic to the United States" [which was copied from a database] when it is actually endemic to a single spring.) The premise of the recent RfC establishing NSPECIES was that a description of the species had to have been published for it to be accepted by the relevant authority. So, at least summarize that description in our article. If you cannot find the description for a particular species, move on to another species for which you can find the description. There will be plenty of such species to write about for a long time to come. Donald Albury 17:40, 5 October 2025 (UTC)
- If they made all of the articles, it would take them 10.96 years. Mikeycdiamond (talk) 18:35, 5 October 2025 (UTC)
- That's good news. It means that Wikipedia isn't complete yet. Phil Bridger (talk) 19:09, 5 October 2025 (UTC)
- It would take me a lot longer than that. It has taken me a year to create eight new articles and expand 36 stubs in a plant genus, and there are 43 stubs and four redlinks to go. Of I course, I am continually being distracted by rabbit holes. Donald Albury 19:53, 5 October 2025 (UTC)
- Could you link the list of articles needed to be made? I'd be willing to help you once I'm done with my current project. Mikeycdiamond (talk) 19:55, 5 October 2025 (UTC)
- User:Donald Albury/Zamia stubs includes the missing articles. Donald Albury 20:14, 5 October 2025 (UTC)
- Could you link the list of articles needed to be made? I'd be willing to help you once I'm done with my current project. Mikeycdiamond (talk) 19:55, 5 October 2025 (UTC)
- No clue, as many as I can get info about I guess. I have seen some families with hardly any info about a large number of species. B33tleMania12 (talk) 19:18, 5 October 2025 (UTC)
- You've only been here for a few months and you have made 0.061% of Wikipedia articles. Good job! Mikeycdiamond (talk) 19:40, 5 October 2025 (UTC)
- And according to my friendly neighbourhood LLM 43.617% of statistics are made up. Phil Bridger (talk) 20:09, 5 October 2025 (UTC)
- You've only been here for a few months and you have made 0.061% of Wikipedia articles. Good job! Mikeycdiamond (talk) 19:40, 5 October 2025 (UTC)
- So we're looking at about 400,000 articles. Is that an issue? It would be nice to have 400,000 images to go with them. But an enduring, free to access, record of them is a good thing, no? Best Alexandermcnabb (talk) 16:56, 5 October 2025 (UTC)
Support On condition that you make the new articles as fleshy as possible. A meaty stub of no less than 1kb readable prose ideal. Given that I've been running contests to reduce the number of stubs, I would prefer it if you were able to generate start class ones over 1.5 kb if possible. Rate of creation is of no issue to me as long as they are accurate and error free. No short database stubs please.♦ Dr. Blofeld 20:19, 5 October 2025 (UTC)
- Support if they're going to be made of this size anyway I say let them be made quick. DervotNum4 (talk) 22:59, 12 October 2025 (UTC)
- I looked at some of the articles they made. It seems like the articles he makes is 200b or under. Mikeycdiamond (talk) 20:42, 5 October 2025 (UTC)
Should we have an essay or something on "Jew tagging"?
[edit]I think it could be useful. See[4] and [5]. It would make it easier to justify blocks for jew tagging. Doug Weller talk 09:26, 27 September 2025 (UTC)
- These 2 related discussions were pretty massive: [6][7] Gråbergs Gråa Sång (talk) 11:15, 27 September 2025 (UTC)
- Full disclosure: I just made such a block.[8] This, even though way back in the middle ages (2011), is also interesting IMO. Bishonen | tålk 12:53, 27 September 2025 (UTC).
- This feels like a BLP thing, like, just as we shouldn't push a person's religion or political views unless they are well-documented, we shouldn't go around pushing a person's ethnic heritage unless that's always well-documented and part of their history. Most well-researched biographies will include this info and will make it due for us to include, but I suspect in cases like these, the editor leaning into one source to include and pushing a type of agenda. Masem (t) 13:03, 27 September 2025 (UTC)
- The difference between Jew-tagging and inclusion of ethnicity and/or religion in a well-researched (and well-written) biography is generally readily apparent in the wording. 'X is jewish' with no further context is bad writing, if it isn't tagging, and anyone adding that to multiple articles needs looking at. Look out also for people insisting that ethnicity and religion are one and the same: it's a clear WP:BLP violation to assign religious beliefs to a living person based on descent, but far too many people think it appropriate. AndyTheGrump (talk) 13:14, 27 September 2025 (UTC)
- I guess I am saying while this Jew-tagging is most predominated, if we write something it should be neutral w.r.t to any ethnicity/religious background. Masem (t) 14:01, 27 September 2025 (UTC)
- Jew-tagging can probably affect articles on dead people too, Epstein, Einstein, Jesus etc. Gråbergs Gråa Sång (talk) 13:42, 27 September 2025 (UTC)
- So there are two situations where this is a factor:
- Situations where an editor who is proud of their ethnicity/religion/nationality/etc wants to “tag” the subject of an article as being “one of us”.
- Situations where an editor who dislikes a particular ethnicity/religion/nationality/etc wants to tag the subject as “one of them”.
- In both situations the editor is inserting (“tagging”) the information for the wrong reasons. The editor is being non-neutral. The editor is adding information because that information is important to the editor, not because the information is important to the subject. Blueboar (talk) 14:13, 27 September 2025 (UTC)
- For Jew-tagging I'd mostly say it's the latter, collecting people they think are Jews to justify some antisemitic canard (example). However, I've also seen the former in e.g. WP:CT/SA topics. A broader guideline/policy might help, such as only including ethnic labels when they show significant coverage in multiple reliable sources. Children Will Listen (🐄 talk, 🫘 contribs) 14:30, 27 September 2025 (UTC)
- Yeah, that's how I see it too. And I'm not saying these situations are equal in yukky-ness or whatever, but I think both motivations exist.
- And there are cases where one GF Wikipedian thinks "Jewish should be mentioned in article per coverage in existing WP:RS", and another GF Wikipedian thinks "You're wrong." Consensus might be achieved if both consider the other Wikipedian GF.
- And of course there can be plenty of devil in the details. Should "Born to a Jewish family" be in the second WP:LEAD sentence at Jeffrey Epstein? I'm guessing it's been discussed a bit somewhere. Gråbergs Gråa Sång (talk) 14:30, 27 September 2025 (UTC)
- In both the cases of Einstein and Jesus, being Jewish was critically important to their respective biographies, and belongs in the lead. I don't think we should categorically create a policy against so-called Jew-tagging, as this is already covered by MOS:ETHNICITY, and the need for everything in a BLP to be reliably sourced and in due weight for inclusion. Andre🚐 01:13, 28 September 2025 (UTC)
- Sure, it should be mentioned (and I'm not saying those current articles are WP-bad on this issue), but there is more to it than that, there is devil in the details and the article is bigger than the WP:LEAD. In both the cases of Einstein and Jesus, the question on "how" has been discussed and edited. See for example the mentions of Einstein in [9]. Paraphrasing page 13-15: "It should be mentioned... but not like that. Gråbergs Gråa Sång (talk) 06:31, 28 September 2025 (UTC)
- So there are two situations where this is a factor:
- The difference between Jew-tagging and inclusion of ethnicity and/or religion in a well-researched (and well-written) biography is generally readily apparent in the wording. 'X is jewish' with no further context is bad writing, if it isn't tagging, and anyone adding that to multiple articles needs looking at. Look out also for people insisting that ethnicity and religion are one and the same: it's a clear WP:BLP violation to assign religious beliefs to a living person based on descent, but far too many people think it appropriate. AndyTheGrump (talk) 13:14, 27 September 2025 (UTC)
- Btw, I know this may not be the really problematic kind of Jew-tagging, but I sometimes wonder about articles like Joshua Waitzkin. There is no mention in article text, but the categories are there, which is clearly undesirable if we follow WP:BLPCAT and WP:CATVER. It's not my basic assumption that whoever added these had an antisemitic motive, but I think of it as Jew-tagging nonetheless. I have also encountered what I consider LGBTQ-tagging, but that's off-topic in this thread. So yes, we should have an essay or something. Gråbergs Gråa Sång (talk) 14:01, 27 September 2025 (UTC)
- Its the same problem, as we are not using categories to create a classification system for articles, but instead to put articles into categories that they are well-known to be within. If the article makes no mention, the category absolutely should not be there, and even if there is mention, editors must use good judgment to add to the category. Masem (t) 14:04, 27 September 2025 (UTC)
- I think so too. Gråbergs Gråa Sång (talk) 14:10, 27 September 2025 (UTC)
- @Gråbergs Gråa Sång: Sometimes (and this is something I have found as a longtime user of AWB) that comes about because there was, once, some kind of reference to Judaism in the article that was later removed. But a category was added based on the reference, and that category remains...and then gets reinforced by the AWB search. I try to weed things out, but in a large category with many articles that's not always easy.
- Its the same problem, as we are not using categories to create a classification system for articles, but instead to put articles into categories that they are well-known to be within. If the article makes no mention, the category absolutely should not be there, and even if there is mention, editors must use good judgment to add to the category. Masem (t) 14:04, 27 September 2025 (UTC)
- That being said, there are always articles where someone has taken something and run with it, incorrectly. (I may be tooting my own horn, here, and forgive me for doing so, but in my own article someone added me to the category Category:American Ashkenazi Jews. Which...to be charitable, I can maybe see where it came from, though I do not agree. But I am not an Ashkenazi Jew, nor have I ever claimed to be one in an interview. And it really bugs me that someone has gone ahead and made that assumption for one reason or another.) --Ser Amantio di NicolaoChe dicono a Signa?Lo dicono a Signa. 16:19, 27 September 2025 (UTC)
- This subject has come up before. It reminds me of this piece about the importance of this information to readers:
- Yahr, Emily (2019-12-31). "Obsessed with Wikipedia 'personal life' entries? You're not alone". The Washington Post. ISSN 0190-8286.
- (If you can't read it, then go to https://wikipedialibrary.wmflabs.org/suggest/, scroll down until you see the entry for 'Washington Post', and click the Upvote button, and then search for the title in your Favorite Web Search Engine. The overall point is that having a Wikipedia article indicate whether someone belongs to a particular identity group is really important to a lot of readers.)
- I think we sometimes approach this from the wrong direction. The fact is, in all of human history, there have been "us" and "them". Who is in which group varies by time and place, and which factors are considered more or less salient varies by time and place, but if a person in a given time/place happens to be in a socially disadvantaged group (any group[s] that time/place disadvantages), then that's an important factor in those individuals' lives. I think we all know this, even if we're sometimes squeamish about acting on it because of our own personal political views (e.g., that Racial color blindness is a good thing and we should write articles to fit that view). We're happy to write "attended Big University for one term", even though this may have had no real effect on the person's life, and we cheerfully write "was orphaned at the age of 15", because we instinctively recognize that this matters, but we don't want to write "was Black" even if the person was born under Jim Crow laws and therefore almost everything about their life, including where they could live, whether they could learn to read, and what would happen if they told a joke at work, was determined by this fact.
- I would like to suggest editors consider this model for determining which factors should be included when verifiable: Look at the person's main reason for notability, and think about whether being "the first ____ " would constitute a Wikipedia:Credible claim of significance. If it would, then the fact that the person is ____ should be included. For example, if the person's claim to fame is being an artist who won the "Notable Artist Award", then as yourself what you would do for various categories of identity, if the person were the first from that identity group to win the award:
- The first woman to win the Notable Artist Award: Include her gender.
- The first Roma person to win the Notable Artist Award: Include their ethnicity.
- The first American to win the Notable Artist Award: Include nationality.
- The first Asian person to win the Notable Artist Award: Include race.
- The first gay man to win the Notable Artist Award: Include sexual orientation.
- The first Muslim to win the Notable Artist Award: Include religion.
- The first teenager to win the Notable Artist Award: Include age, assuming it usually goes to older adults.
- The first blue-collar worker to win the Notable Artist Award: Include social class, assuming it usually goes to people with higher socioeconomic status.
- The first Southerner to win the Notable Artist Award: Don't include geographic identity unless there are special circumstances (e.g., the award comes from a group that emphasizes their Yankee heritage).
- The first parent to win the Notable Artist Award: Don't include family status unless there are special circumstances.
- The first blonde to win the Notable Artist Award: Don't include hair color unless there are special circumstances.
- The first cancer survivor to win the Notable Artist Award: Don't include health status unless there are special circumstances.
- The first short man to win the Notable Artist Award: Don't include height unless there are special circumstances.
- The first Boomer to win the Notable Artist Award: Don't include generational identity unless there are special circumstances.
- The first schoolteacher to win the Notable Artist Award: Don't include occupational identity unless there are special circumstances.
- To be clear, try this exercise even if you know that the person isn't the first ____. The point is, if it would be obviously worth including (or obviously worth excluding) if the person were the first ____ to do this, then it's probably okay to mention (or probably not worth mentioning) the fact that the person is ____ somehow in the article.
- Also, don't we have a page somewhere that says to be careful about how we describe membership in an Ethnoreligious group or Ethnonational group? "Born to a Jewish family" doesn't make assumptions about the person's religious beliefs, and many people in the world should be described as "Israelis" instead of "Jews who live in Israel". WhatamIdoing (talk) 21:36, 27 September 2025 (UTC)
- I think the closest we have is WP:ETHNICRACECAT. There was a donnybrook a few years ago from a journalist who wrote about what he viewed as the tagging of his article, when according to him it does not matter to his life or his work, the account claiming to be him even participated in the discussion. I think it was ultimately excluded. I don't want to draw more attention to him, but it is not surprising that it is personal, and even going toward private, to some. Alanscottwalker (talk) 22:10, 27 September 2025 (UTC)
- I'm not so clear what the *specific* objective here is. I'm somewhat reluctant to separate out antisemitic editing from any form of discriminatory editing. I'd categorise philosemitism as of a different nature and intent. What is missing from our current toolkit that creates a loophole for antisemitic editing? Regards, --Goldsztajn (talk) 00:48, 28 September 2025 (UTC)
- MOS:ETHNICITY covers current practice concerning how ethnicity should be handled. Also edit filter 982 flags Jew-tagging pretty well. Until recently the proportion of malicious tagging has comprised about 80-90% of such edits. Over the past couple of years that seems to have fallen to maybe 60%, with the remainder appearing to be editors who are showing philosemitism (thanks Goldztajn). It can be hard to distinguish between the two at times, and I've seen malicious editors try to portray themselves as the latter, while editors motivated by ethnic pride have argued that someone's Jewishness is being "suppressed" inappropriately, complicating things. I think an essay describing how singling out Jews for special emphasis would be valuable. I see a lot of edits where people are described as "Jewish American" (insert actual nationality as appropriate), as if that's some other nationality than other Americans. I regard it as a pernicious form of othering that should be deprecated. Acroterion (talk) 01:11, 28 September 2025 (UTC)
- Indian-American, Mexican-American, Jewish-American, Italian-American, Irish-American, black or African-American, these are all terms in RS, they aren't neologistic, and if RS use them, they are appropriate to use to describe a person. That isn't necessarily othering or malicious. Diaspora communities exist in other countries that also retain their own cultural communities. The original Americans are of course indigenous Native peoples, First Nations etc. But in terms of X-American as an ethnicity+nationality, this can be specifically to describe an artist that draws specific inspiration from their work and embeds it in that work. For example, Ana Mendieta is described as a Cuban-American artist. Andre🚐 01:18, 28 September 2025 (UTC)
- Those are appropriate in the right context, but Jewish is also a religion. We don't say "Catholic-American." While ethnic identifiers may be appropriate where warranted farther in, the lede sentence or paragraph is where mixing ethnicity or religion is explicitly discouraged, and where we see the most trouble. We stick to nationality only, unless there is some unusual reason to mention ethnicity. We mention something like "Mexican-American" in the lede only where there is dual nationality. Jewish isn't a nationality. I often see nationality taken out entirely, and replaced with Jewish. Acroterion (talk) 01:39, 28 September 2025 (UTC)
- It is discouraged if and only if it is not an important part of the biography. Jewish is an ethnicity, not a nationality. There are Mexican-Americans who are not Mexican by nationality, just by ethnicity. For example, George Lopez lead mentions Mexican American, but he is a natural-born American. Andre🚐 01:48, 28 September 2025 (UTC)
- I want to distinguish between in the lede sentence and mentioning it in that context elsewhere. Remember that a lot of people and AI read only the first few lines. Lopez is mentioned only as American in the lede sentence, per the MOS. His Mexican-American heritage is important to his biography and is covered immediately after. What I see in many instances of Jew-tagging is something different - a negation of nationality in favor of ethnicity, or just random tagging of "he is Jewish" when it's not otherwise significant. An Orthodox rebbe would be another matter.. Acroterion (talk) 01:57, 28 September 2025 (UTC)
- I am talking about the lead paragraph, you just a moment ago said, the lede sentence or paragraph, and while it may not be in the lead sentence in Lopez's article, see the 3 Cuban-American artists below. Andre🚐 02:02, 28 September 2025 (UTC)
- I know. I'm not concerned about mentioning ethnicity in the lede where appropriate. What I'm talking about (and what the rest of this thread is about) is sticking in ethnicity or religion where it isn't appropriate, sourced, or significant. This happens a lot in the case of Jews. I think an essay covering the ins and outs of this kind of thingiwould be useful. Acroterion (talk) 02:06, 28 September 2025 (UTC)
- I know what you mean, but we have to distinguish the random tagging of just putting the sometimes inaccurate or sparsely sourced mention of someone being Jewish as a biographical detail that isn't "relevant to their notability" (which is vague, but I would interpret that pretty broadly), and certainly if it involves replacing American with Jewish (or the lowercase jew is often a sign of bad faith), versus what may not necessarily be a philosemitic boast or claiming, but simply an accurate read of someone's biography. Einstein was an American Jewish scientist, in my view, this is shown by the fact that Einstein left his papers to the Hebrew University that he helped found. "By an application of the theory of relativity to the taste of readers, today in Germany I am called a German man of science, and in England I am represented as a Swiss Jew. If I come to be represented as a bête noire, the descriptions will be reversed, and I shall become a Swiss Jew for the Germans and a German man of science for the English!" Dara Horn, Michael Chabon, and Regina Spektor could, in my view, reasonably be described in the lead as American Jewish. They aren't right now, but I personally do not think they would either be offended or dispute that that is just an accurate read of its importance to their oeuvres. Andre🚐 02:12, 28 September 2025 (UTC)
- Yes," significance" can be kind of vague. It can come from either the subject's personal experience or the emphasis placed by historians. That's not what I usually see - it's picking out people that an editor imagines embodying some kind of attribute associated with Jews - positive or negative - and dumping in ethnicity out of context. Again, we're talking about a potential essay that covers all of this. Acroterion (talk)
- You are an experienced and responsible admin, rolling in clue, who can easily distinguish between drive-by tagging and serious work. But I worry about others. For example, in the discussion below this point, several users have either opined that almost any descriptor of someone being Jewish is inappropriate, which I think as you gave in the example of an Orthodox rabbi, let alone my secular artist examples, is worrisome in terms of how this could be overzealously or mistakenly interpreted. Especially for historical figues and non-BLP with a historian source analysis consensus of the importance of their Jewishness, or Cubanness, not even getting into the living artists that, in my view, are obviously proud of and centering their culture and are not being singled out by right wingers to exclude or diminish them just by describing them as what they obviously describe themselves as in those cases. While I recognize that an essay could better elucidate the distinction, I don't necessarily feel that the right ingredients for what that essay would be have been brought forth in a consensus manner here, and I feel like any essay distilling the reasoning here would actually be non-neutral in terms of its rejection of any ethnic or national component of the biography. That is also a pattern that Wikipedia can fall into, namely erasure of difference and intersectionality in favor of a logical, neat, black and white modernism. Andre🚐 19:37, 28 September 2025 (UTC)
- Which to me means that we ought to impart clue to others. Few things in life or on Wikipedia are black-and-white. Acroterion (talk) 01:15, 30 September 2025 (UTC)
- You are an experienced and responsible admin, rolling in clue, who can easily distinguish between drive-by tagging and serious work. But I worry about others. For example, in the discussion below this point, several users have either opined that almost any descriptor of someone being Jewish is inappropriate, which I think as you gave in the example of an Orthodox rabbi, let alone my secular artist examples, is worrisome in terms of how this could be overzealously or mistakenly interpreted. Especially for historical figues and non-BLP with a historian source analysis consensus of the importance of their Jewishness, or Cubanness, not even getting into the living artists that, in my view, are obviously proud of and centering their culture and are not being singled out by right wingers to exclude or diminish them just by describing them as what they obviously describe themselves as in those cases. While I recognize that an essay could better elucidate the distinction, I don't necessarily feel that the right ingredients for what that essay would be have been brought forth in a consensus manner here, and I feel like any essay distilling the reasoning here would actually be non-neutral in terms of its rejection of any ethnic or national component of the biography. That is also a pattern that Wikipedia can fall into, namely erasure of difference and intersectionality in favor of a logical, neat, black and white modernism. Andre🚐 19:37, 28 September 2025 (UTC)
- Yes," significance" can be kind of vague. It can come from either the subject's personal experience or the emphasis placed by historians. That's not what I usually see - it's picking out people that an editor imagines embodying some kind of attribute associated with Jews - positive or negative - and dumping in ethnicity out of context. Again, we're talking about a potential essay that covers all of this. Acroterion (talk)
- I know what you mean, but we have to distinguish the random tagging of just putting the sometimes inaccurate or sparsely sourced mention of someone being Jewish as a biographical detail that isn't "relevant to their notability" (which is vague, but I would interpret that pretty broadly), and certainly if it involves replacing American with Jewish (or the lowercase jew is often a sign of bad faith), versus what may not necessarily be a philosemitic boast or claiming, but simply an accurate read of someone's biography. Einstein was an American Jewish scientist, in my view, this is shown by the fact that Einstein left his papers to the Hebrew University that he helped found. "By an application of the theory of relativity to the taste of readers, today in Germany I am called a German man of science, and in England I am represented as a Swiss Jew. If I come to be represented as a bête noire, the descriptions will be reversed, and I shall become a Swiss Jew for the Germans and a German man of science for the English!" Dara Horn, Michael Chabon, and Regina Spektor could, in my view, reasonably be described in the lead as American Jewish. They aren't right now, but I personally do not think they would either be offended or dispute that that is just an accurate read of its importance to their oeuvres. Andre🚐 02:12, 28 September 2025 (UTC)
- I know. I'm not concerned about mentioning ethnicity in the lede where appropriate. What I'm talking about (and what the rest of this thread is about) is sticking in ethnicity or religion where it isn't appropriate, sourced, or significant. This happens a lot in the case of Jews. I think an essay covering the ins and outs of this kind of thingiwould be useful. Acroterion (talk) 02:06, 28 September 2025 (UTC)
- I am talking about the lead paragraph, you just a moment ago said, the lede sentence or paragraph, and while it may not be in the lead sentence in Lopez's article, see the 3 Cuban-American artists below. Andre🚐 02:02, 28 September 2025 (UTC)
- I want to distinguish between in the lede sentence and mentioning it in that context elsewhere. Remember that a lot of people and AI read only the first few lines. Lopez is mentioned only as American in the lede sentence, per the MOS. His Mexican-American heritage is important to his biography and is covered immediately after. What I see in many instances of Jew-tagging is something different - a negation of nationality in favor of ethnicity, or just random tagging of "he is Jewish" when it's not otherwise significant. An Orthodox rebbe would be another matter.. Acroterion (talk) 01:57, 28 September 2025 (UTC)
- It is discouraged if and only if it is not an important part of the biography. Jewish is an ethnicity, not a nationality. There are Mexican-Americans who are not Mexican by nationality, just by ethnicity. For example, George Lopez lead mentions Mexican American, but he is a natural-born American. Andre🚐 01:48, 28 September 2025 (UTC)
- Mendieta is in fact a dual national. Acroterion (talk) 01:42, 28 September 2025 (UTC)
- Sorry, that is not a good example. Although I think if someone was born in Havana and came to Florida as a refugee that presents an interesting case to consider, but here are some examples born in the USA that work better: Tony Mendoza (artist), Harmonia Rosales, Coco Fusco Andre🚐 01:52, 28 September 2025 (UTC)
- Those are poorly done, they are American, per guideline. There is no good reason to 'other' them. To the extent their ethnicity is reflected in their work or plays a part in their career, it can be mentioned after the first sentence. Alanscottwalker (talk) 13:47, 28 September 2025 (UTC)
- The guideline specifically allows if this is relevant to their notability. They are not necessarily being "othered." Andre🚐 17:57, 28 September 2025 (UTC)
- Yes, they are. The guideline says the first sentence should focus on their nationality linking to citizenship. Citizenship in the United States, was so much trying to other, that there was the 14th Amendment passed to preclude that. And it has become a political football again. Alanscottwalker (talk) 19:56, 28 September 2025 (UTC)
- Multicultural representation and the celebration of diversity isn't necessarily othering, that is part of what makes America great and special - salad bowl and not a pure melting pot. In The Heights would be a very boring play if Lin-Manuel Miranda referred to every character as just generic Americans without portraying the challenges and joys of the Puerto Rican and Dominican immigrant community of New York. The Cuban-American artists I linked were all born in New York or Chicago, so they are American citizens by any plain reading of the amendment, and Wikipedia should decline to participate in any hysteria about birthright citizenship being on the chopping block: it can't be, and isn't. People can't just wish away constitutional amendments even SCOTUS judges. Anyway, the Cuban-American artists I linked all make their heritage and experience part of their work, and critical to their biography and notability, which is excepted in policy. Andre🚐 03:52, 30 September 2025 (UTC)
- You don't seem to be paying attention nor listening. Your comment on multiculturalism is not in the least responsive to what has been said. My comments never said nor suggested don't mention it anywhere, indeed they explicitly said put it elsewhere, as warranted. (As an aside, you seem to have no knowledge what is in fact going on in the Supreme Court, and even if the administration loses the active case, many people will still cling to the othering argument. But as your comment is generally irrelevant, we should move on.)
- The place we are talking about in the guideline, the first sentence, is reserved for citizenship, not race nor ethnicity. So, therefore doing something else, like replacing citizenship with ethnicity is othering, and its literally treating the bio unlike other American bios, so again, othering. -- Alanscottwalker (talk) 20:58, 30 September 2025 (UTC)
- That is an unnecessarily personal comment. We just don't agree. There's no reason to accuse me of not listening or paying attention. That kind of comment has no place in Wikipedia discussions. You were the one who brought up birthright citizenship, which is not relevant terribly to this discussion except peripherally. You are reading something that isn't in the guideline MOS:ETHNICITY/MOS:CONTEXTBIO.
most modern-day cases, this will be the country, region, or territory where the person is currently a national or permanent resident...Ethnicity, religion, or sexuality should generally not be in the lead unless relevant to the subject's notability.
It clearly makes an exception and allows for "most" cases, in fact most modern-day cases. Nowhere does it say that you can never mention an ethnicity in the lead paragraph or sentence. It is not othering, necessarily, to describe someone as Cuban-American or Jewish-American or American Jewish, as all three of those contain a nationality, not replacing it. Andre🚐 21:24, 30 September 2025 (UTC)- Well, when it is clear you are not listening. Then it needs to be said. Your the one who brought up these examples, which in the place of American for citizenship, literally have something other. So, my addressing American citizenship is spot on. Nor did I argue, ethnicity should necessarily not be elsewhere in those articles. So, your argument has to do with failure to to listen to what I, in fact, said. Alanscottwalker (talk) 21:33, 30 September 2025 (UTC)
- Let's dial it back, eh? Nobody here is a mind-reader and we can patient in our arguments. Cremastra (talk · contribs) 21:36, 30 September 2025 (UTC)
- No one is asking anyone to mind read, we do expect reading what was said. Alanscottwalker (talk) 21:42, 30 September 2025 (UTC)
- Your accusation that I am not listening or paying attention is a personal attack, so please refrain from saying that in the future. And perhaps you may want to strike part of your comment if you are seeking to resume good faith. Andre🚐 21:45, 30 September 2025 (UTC)
- What? Your not listening is what accounts for your irrelevant statements. Since acknowledging culture was literally what I said could be addressed elsewhere in the article, as appropriate. Alanscottwalker (talk) 21:53, 30 September 2025 (UTC)
- OK, I'll try one more time to reply and then we should drop this because I don't see how we can come to an understanding at this rate. My argument is that 1) the guideline allows for some situations where ethnicity may be mentioned in the first sentence and/or the lead, 2) you claimed it was othering due to what you mentioned about citizenship which I rebutted arguing that representing multiculturalism is not necessarily othering, EVEN when it involves using the exceptions in the guideline to express ethnicity in the first sentence. We obviously don't agree, and continuing to double down on a personal attack that I am not listening certainly won't help. Andre🚐 21:59, 30 September 2025 (UTC)
- Nothing I said, addressed elsewhere in the lead, expect to say ethnicity/culture could be addressed elsewhere than the first sentence, as appropriate (as guideline places the norm being citizenship in the first sentence). -- Alanscottwalker (talk) 22:10, 30 September 2025 (UTC)
- OK, I'll try one more time to reply and then we should drop this because I don't see how we can come to an understanding at this rate. My argument is that 1) the guideline allows for some situations where ethnicity may be mentioned in the first sentence and/or the lead, 2) you claimed it was othering due to what you mentioned about citizenship which I rebutted arguing that representing multiculturalism is not necessarily othering, EVEN when it involves using the exceptions in the guideline to express ethnicity in the first sentence. We obviously don't agree, and continuing to double down on a personal attack that I am not listening certainly won't help. Andre🚐 21:59, 30 September 2025 (UTC)
- What? Your not listening is what accounts for your irrelevant statements. Since acknowledging culture was literally what I said could be addressed elsewhere in the article, as appropriate. Alanscottwalker (talk) 21:53, 30 September 2025 (UTC)
- Your accusation that I am not listening or paying attention is a personal attack, so please refrain from saying that in the future. And perhaps you may want to strike part of your comment if you are seeking to resume good faith. Andre🚐 21:45, 30 September 2025 (UTC)
- No one is asking anyone to mind read, we do expect reading what was said. Alanscottwalker (talk) 21:42, 30 September 2025 (UTC)
- Cuban-Americans are American citizens, and the artists who identify that way because of those themes and that culture in their work aren't being othered by using the same name they use for their own identity. And those are modern-day cases. In many historical cases, it is hardly clear-cut that someone who lived in let's say Spain or Portugal or Italy or the Rhineland in the Middle Ages shouldn't say Sephardic Jewish instead of Spanish, or Italian-Jewish, for individuals who were not equal and full citizens or even citizens at all in the world they lived in, in a ghetto with restrictions on their movement and discriminatory legislation. Andre🚐 21:42, 30 September 2025 (UTC)
- You given no reason for not calling them American, as we do other Americans. American is the guideline word for citizenship, whereas, Cuban American, is culture or ethnicity. Alanscottwalker (talk) 21:58, 30 September 2025 (UTC)
- The reason is presented in the guideline. If it is relevant to their notability it may be included. Andre🚐 22:03, 30 September 2025 (UTC)
- You given no reason for not calling them American, as we do other Americans. American is the guideline word for citizenship, whereas, Cuban American, is culture or ethnicity. Alanscottwalker (talk) 21:58, 30 September 2025 (UTC)
- Let's dial it back, eh? Nobody here is a mind-reader and we can patient in our arguments. Cremastra (talk · contribs) 21:36, 30 September 2025 (UTC)
- Well, when it is clear you are not listening. Then it needs to be said. Your the one who brought up these examples, which in the place of American for citizenship, literally have something other. So, my addressing American citizenship is spot on. Nor did I argue, ethnicity should necessarily not be elsewhere in those articles. So, your argument has to do with failure to to listen to what I, in fact, said. Alanscottwalker (talk) 21:33, 30 September 2025 (UTC)
- That is an unnecessarily personal comment. We just don't agree. There's no reason to accuse me of not listening or paying attention. That kind of comment has no place in Wikipedia discussions. You were the one who brought up birthright citizenship, which is not relevant terribly to this discussion except peripherally. You are reading something that isn't in the guideline MOS:ETHNICITY/MOS:CONTEXTBIO.
- Multicultural representation and the celebration of diversity isn't necessarily othering, that is part of what makes America great and special - salad bowl and not a pure melting pot. In The Heights would be a very boring play if Lin-Manuel Miranda referred to every character as just generic Americans without portraying the challenges and joys of the Puerto Rican and Dominican immigrant community of New York. The Cuban-American artists I linked were all born in New York or Chicago, so they are American citizens by any plain reading of the amendment, and Wikipedia should decline to participate in any hysteria about birthright citizenship being on the chopping block: it can't be, and isn't. People can't just wish away constitutional amendments even SCOTUS judges. Anyway, the Cuban-American artists I linked all make their heritage and experience part of their work, and critical to their biography and notability, which is excepted in policy. Andre🚐 03:52, 30 September 2025 (UTC)
- Yes, they are. The guideline says the first sentence should focus on their nationality linking to citizenship. Citizenship in the United States, was so much trying to other, that there was the 14th Amendment passed to preclude that. And it has become a political football again. Alanscottwalker (talk) 19:56, 28 September 2025 (UTC)
- The guideline specifically allows if this is relevant to their notability. They are not necessarily being "othered." Andre🚐 17:57, 28 September 2025 (UTC)
- Those are poorly done, they are American, per guideline. There is no good reason to 'other' them. To the extent their ethnicity is reflected in their work or plays a part in their career, it can be mentioned after the first sentence. Alanscottwalker (talk) 13:47, 28 September 2025 (UTC)
- Sorry, that is not a good example. Although I think if someone was born in Havana and came to Florida as a refugee that presents an interesting case to consider, but here are some examples born in the USA that work better: Tony Mendoza (artist), Harmonia Rosales, Coco Fusco Andre🚐 01:52, 28 September 2025 (UTC)
- Those are appropriate in the right context, but Jewish is also a religion. We don't say "Catholic-American." While ethnic identifiers may be appropriate where warranted farther in, the lede sentence or paragraph is where mixing ethnicity or religion is explicitly discouraged, and where we see the most trouble. We stick to nationality only, unless there is some unusual reason to mention ethnicity. We mention something like "Mexican-American" in the lede only where there is dual nationality. Jewish isn't a nationality. I often see nationality taken out entirely, and replaced with Jewish. Acroterion (talk) 01:39, 28 September 2025 (UTC)
- Indian-American, Mexican-American, Jewish-American, Italian-American, Irish-American, black or African-American, these are all terms in RS, they aren't neologistic, and if RS use them, they are appropriate to use to describe a person. That isn't necessarily othering or malicious. Diaspora communities exist in other countries that also retain their own cultural communities. The original Americans are of course indigenous Native peoples, First Nations etc. But in terms of X-American as an ethnicity+nationality, this can be specifically to describe an artist that draws specific inspiration from their work and embeds it in that work. For example, Ana Mendieta is described as a Cuban-American artist. Andre🚐 01:18, 28 September 2025 (UTC)
- Perhaps an essay on "tagging" in general, basically explaining MOS:CONTEXTBIO (aka MOS:ETHNICITY, but covering more than just ethnicity), would be useful. Jew-tagging is definitely the example I've heard about the most often, but tagging issues do emerge in other cases as noted by some of the examples at CONTEXTBIO. WP:BLPCAT is in the same spirit, a category tag rather than a lead tag. CMD (talk) 02:38, 28 September 2025 (UTC)
- Do you know what would help here? A precise definition of "Jew Tagging". It's not a common term where I live. HiLo48 (talk) 02:42, 28 September 2025 (UTC)
- It seems to be invented by a Wikipedia critic and basically means labeling someone as a Jew (
he is a Jew
orshe is Jewish-American
) when their religion/ethnicity doesn't have much encyclopedic value. Children Will Listen (🐄 talk, 🫘 contribs) 03:20, 28 September 2025 (UTC)- To me, that would include almost every article that says someone is Jewish. HiLo48 (talk) 03:38, 28 September 2025 (UTC)
- The issue is outright saying, in so many works "So and so is Jewish." without any further context. Most of the articles I spotchecked did not do this but left this as an exercise to the reader (of a sorts) within the person's early history, like their family origins. That's reasonable, as that also gives context. Masem (t) 04:13, 28 September 2025 (UTC)
- If you're thinking about Kosner, the term is older than that:[10] And there is stuff like ((())) etc. Gråbergs Gråa Sång (talk) 07:08, 28 September 2025 (UTC)
- To me, that would include almost every article that says someone is Jewish. HiLo48 (talk) 03:38, 28 September 2025 (UTC)
- Here's one kind-of definition: ""Jew tagging" refers to the practice of unnecessarily or inappropriately mentioning a person's Jewish identity in Wikipedia articles. This term is used within the Wikipedia community to describe situations where an individual's Jewish heritage is highlighted even when it is not relevant to the subject matter of the article." AI-warning on that one though, but they're not always wrong. Gråbergs Gråa Sång (talk) 06:23, 28 September 2025 (UTC)
- I like @CMD's suggestion of an essay focussed on BLP tagging in general. There's other aspects that could apply, too - eg redbaiting. Goldsztajn (talk) 09:01, 28 September 2025 (UTC)
- Note: check out the creepy alt-right "early life" dogwhistle/meme, which relies on one kind of Wikipedia jew-tagging.[11][12] Used e. g. on t-shirts.[13] Bishonen | tålk 13:18, 28 September 2025 (UTC).
- Wow. Alanscottwalker (talk) 13:51, 28 September 2025 (UTC)
- This is honestly unnerving to see. I know we're not out to right great wrongs, but would cutting down on extraneous ethno-religious labels reduce this? Or would the alt-right simply find something else? Children Will Listen (🐄 talk, 🫘 contribs) 13:53, 28 September 2025 (UTC)
- Hiding or removing someone's Jewish heritage that they may be proud of to avoid it being on an alt-right T-shirt is a lot more troubling to me personally. Andre🚐 18:01, 28 September 2025 (UTC)
- We are regularly removing Jewish categories from Richard Feynman. Hawkeye7 (discuss) 01:46, 30 September 2025 (UTC)
- Because unlike Einstein, he doesn't have a personal story of fleeing Nazi Germany or of publicly expressed solidarity with a community of tradition, but he was painstaking in his secularism. So that is appropriate. Andre🚐 03:45, 30 September 2025 (UTC)
- Well, if they are publicly proud of their heritage, I see no problems including it in the article about them. Children Will Listen (🐄 talk, 🫘 contribs) 03:53, 30 September 2025 (UTC)
- We are regularly removing Jewish categories from Richard Feynman. Hawkeye7 (discuss) 01:46, 30 September 2025 (UTC)
- Of course the alt-right will find something else. Cremastra (talk · contribs) 20:09, 29 September 2025 (UTC)
- Hiding or removing someone's Jewish heritage that they may be proud of to avoid it being on an alt-right T-shirt is a lot more troubling to me personally. Andre🚐 18:01, 28 September 2025 (UTC)
- That certainly does frame the importance of any decisions made in this area. That said, I am extremely concerned about going into these kinds of questions about how we want to put our thumb on the scale here with the most virtuous of intentions and ending up somewhere deeply regrettable. There is substantial potential here for cultural erasure and letting bigots create social pressure for suppressing Jewish identity and representation. Because I am fairly confident that if we left the decision up to the actual Jewish BLP subjects themselves, that the vast, vast majority of them would be lay somewhere in the span between being ok with to being very insistent on having their Jewish heritage mentioned in any biographical entry about them, being proud of their heritage and probably offended at the implication that it should be concealed, whatever the context, and however rooted in sympathy and a protective impulse the motive in considering omitting that fact might be. I understand where the cause for concern comes from here, but let's take a step back here and remember that it's not actually the recognition of Jewish identity that is the problem here. It's the bigoted belief systems, scapegoating, hatred-mongering, and crack-brained conspiracy theories which constitute antisemitism itself that are an issue. I'm generally supportive of editors choosing to, in their individual capacity, decide wherever or not to mention Jewish heritage for a BLP subject on the basis of what they see in the sources, as a general application of WP:WEIGHT. Because, lacking any unambiguously good solutions, one might as well just default to standard practice and the general principle of WP:NPOV. But going a step farther and deciding we should implement a standard rule against mentioning Jewish heritage except where "it's really, really important to the understanding of that subject", or any rule that is out of lockstep with out usual coverage of ethnicity? Well, again, while acknowledging that the idea comes from a good place, I just don't think that's necessarily a good idea, nor one that Jewish people would generally thank us for, nor even a decision we should consider within our remit to make. I'm pretty sure most of the Jewish people I know would, in reaction to having their Jewish heritage noted in an article (even by someone we could prove was doing it as flagging maneuver) respond with something at least in the vicinity of "Yeah, and what of it? My people have suffered persecution for thousands of years, including pogroms and genocidal movements in the last century alone. You think I'm scared of you, a skinhead, keyboard warrior pussy? Yeah, I'm Jewish, and if you think I give one ten-thousandth of a shit that you and every inbred neo-Nazi fuck between Charlottesville to Munich knows it, you'd better guess again." I think that we need to consider the possibility that our approach should be ideologically in solidarity with that perspective. If we start second guessing whether it is appropriate to mention a demonstrably Jewish person's Jewishness in an article, even to the extent of creating a rule about it, we are very arguably handing a small victory to the racist troglodytes who want to inject into our culture the perspective that there is anything negative in that association. I think we should be very hesitant to treat the question of Jewish representation any different than any other ethnicity in terms of how we shape and apply our policies. SnowRise let's rap 04:14, 30 September 2025 (UTC)
- Snow Rise, I wasn't suggesting the "Early life" meme was a reason for not mentioning Jewishness. I merely thought people might be interested to know about it. Well, interested or depressed. Bishonen | tålk 21:16, 30 September 2025 (UTC).
- Yeah, don't worry, that was the sense that I got, Bish. And regardless of any other considerations, it is very important context that I thank you for raising. Even if our decision is not to alter our standard approach because it raises too many concerns for collateral harms, it is vital that we know when our content is being utilized in this way. Unfortunately, I think such situations may be outside our ability to effectively answer here. Memetic social ills like antisemitism can arguably only be effectively combated at the source of infection, and require inoculation through other and more foundational forms of education: early exposure to critical thinking, disciplined training in information and source assessment, and other efforts to promulgate skills which make the pathetic shortcomings of conspiracy theories more broadly apparent. There are always going to be people who, through tribalistic thinking, Dunning-Kruger styled self-aggrandizement, or propensity to fall prey to other common cognitive biases, will promote such nonsense. But as I think the last couple of decades of worrisome decline in this respect demonstrate, it is the quality of baseline education which has the greatest impact on the proliferation of such beliefs. Certainly there is also much to be said for the influence of technological developments in that same period. But even then, I still think the only even half-way effective solution is to be found in inculcating the general populous with familiarity with empirical reasoning and a rationalistic world view. Which is deeply disheartening when you see just how aggressive the needle is being pushed in the other direct right now, in many of the world's most powerful nations and largest societies. Unfortunately, our piece of the educational puzzle is providing information, not the mental tools to use it. So we are ill-prepared to do much to constrain such degredation of the collective intellect, especially when even the half-measures available to us have problematic trade-offs, as here. As you say, deeply depressing, but a basic tautology all the same, I fear. SnowRise let's rap 00:51, 1 October 2025 (UTC)
- Snow Rise, I wasn't suggesting the "Early life" meme was a reason for not mentioning Jewishness. I merely thought people might be interested to know about it. Well, interested or depressed. Bishonen | tålk 21:16, 30 September 2025 (UTC).
- Re "any rule that is out of lockstep with out usual coverage of ethnicity", my suggestion at the start of this subthread is to expand the essay to all tagging. Our policy on the lead already applies to all ethnicities, so there is already a standard rule against mentioning Jewish ethnicity and religion in the opening paragraph, as there is for other ethnicities and religions (and sexualities and former nationalities), unless it is important to the understanding of the subject. Any guidelines relating to the body would, if reflecting the spirit behind CONTEXTBIO, also apply to all ethnicities and religions. I do agree that the various postings dogwhistles and memes shouldn't factor at all into our decision-making however, the decisions should be based on what we find best for helping readers understand article subjects in an encyclopaedic manner. CMD (talk) 05:01, 30 September 2025 (UTC)
- It is hard to understand who this is in response too. No one has suggested not mentioning as appropriate, they have been discussing "Jew-tagging", because it is an issue that affects certain bios, not all bios. And on thing we definitely should not have is a discussion concerning your/my feelings based on your or my personal life, whatever that is. Your/my feelings are your/my feelings, but no basis for a discussion of editing essay or policy. Alanscottwalker (talk) 21:17, 30 September 2025 (UTC)
- But at least one participant in the discussion has opined that almost any mention of being Jewish in a bio would be extraneous, and several people are inventing a policy that doesn't exist that supposedly bars any mention of ethnicity in the first sentence. Andre🚐 21:27, 30 September 2025 (UTC)
- Who is this one person? Certainly not the person this comment is appeared to be responding to. And you again don't address the guideline, which was not called a policy. You have given no good reason to depart from the standard of the guideline. Alanscottwalker (talk) 21:39, 30 September 2025 (UTC)
- That comment does appear higher up in the same thread. And in terms of the guideline, it quite clearly contains wiggle room and an explicit exception. Andre🚐 21:48, 30 September 2025 (UTC)
- What comment? Whose comment? What thread? The guideline gives a norm, departing from the norm is literally not normal. Alanscottwalker (talk) 22:03, 30 September 2025 (UTC)
- That comment does appear higher up in the same thread. And in terms of the guideline, it quite clearly contains wiggle room and an explicit exception. Andre🚐 21:48, 30 September 2025 (UTC)
- Who is this one person? Certainly not the person this comment is appeared to be responding to. And you again don't address the guideline, which was not called a policy. You have given no good reason to depart from the standard of the guideline. Alanscottwalker (talk) 21:39, 30 September 2025 (UTC)
- But at least one participant in the discussion has opined that almost any mention of being Jewish in a bio would be extraneous, and several people are inventing a policy that doesn't exist that supposedly bars any mention of ethnicity in the first sentence. Andre🚐 21:27, 30 September 2025 (UTC)
- It seems to be invented by a Wikipedia critic and basically means labeling someone as a Jew (
- Do you know what would help here? A precise definition of "Jew Tagging". It's not a common term where I live. HiLo48 (talk) 02:42, 28 September 2025 (UTC)
- The comment was
To me, that would include almost every article that says someone is Jewish. HiLo48 (talk) 03:38, 28 September 2025 (UTC)
} Andre🚐 22:05, 30 September 2025 (UTC)- Well, that comment is certainly not clear, as you have presented it. You can ask that HiLo about it. No one else is suggesting they speak for HiLo, perhaps you misunderstood. Alanscottwalker (talk) 22:14, 30 September 2025 (UTC)
- What is not clear about that comment? It is an expression of an opinion that nearly every mention that says someone is Jewish lacks encyclopedic value. Andre🚐 22:17, 30 September 2025 (UTC)
- Was it? Wasn't the issue whether or not it is true that everyone who is Jewish is notable for being a Jewish? Alanscottwalker (talk) 22:28, 30 September 2025 (UTC)
- Huh? I don't see where you are getting that from. HiLo48 says in "almost every article that says someone is Jewish," it would not have any encyclopedic value, and be therefore Jew-tagging. Yes, only some people should have their ethnicity mentioned in the lead, as far a I know, this was never in dispute by anyone, except perhaps people who are saying that the set of notable-relevant people is negligibly large. The issue of "Jew-tagging" is when someone tags, probably a living person, probably someone not specifically known for or associated with Judaism, with that ethnicity. I am arguing that we should not make a special guideline for this, or a special essay about it, because it is already covered by existing guidelines, which are already not interpreted correctly, and we should not lean even more on the tendency to adopt a postmodern idealism that cultural and ethnic differences are rarely an important part of someone's biography. So I broadly agree with SnowRise. Andre🚐 22:40, 30 September 2025 (UTC)
- To clarify my now multiply reinterpreted position, it's really very simple. Almost every time I am told by Wikipedia that someone is Jewish, I fail to see any connection between that claim and anything else in that person's article. If I ever get an article, it will be of zero significance to mention that I am a failed Presbyterian, or have Scottish ancestry from seven generations ago. HiLo48 (talk) 00:20, 1 October 2025 (UTC)
- That is close enough to what I said or thought your position was, in my view. And demonstrably, there are myriad examples where your generalization is false, but I have no way of knowing what articles you read. I completely understand if you don't have any particular connection to Scottishness in your field, whatever that is. But Andrew Carnegie did. And Sean Connery did. Those are just the first 2 Scots I thought of, but consider that there are very many people for whom their ethnoreligious community was an important part of whatever they did. Maybe not for any random politician or businessperson or actor, but for some. Andre🚐 00:43, 1 October 2025 (UTC)
- My "Scottishness" is from seven generations ago. Carnegie's and Connery's was a little more recent. HiLo48 (talk)
- My great-great-grandparents and great-grandparents came to America, but that doesn't mean I don't have a connection to their experience and a bunch of stories and traditions that were handed down to me. There isn't a statute of limitations on how far back your family history can be relevant. If you go around wearing a kilt and eating haggis and telling people you came from Scotland, and then release an album of traditional Scottish folk music that hits the top charts, I'm willing to bet that RS will call you a Scottish American. Andre🚐 01:42, 1 October 2025 (UTC)
- My "Scottishness" is from seven generations ago. Carnegie's and Connery's was a little more recent. HiLo48 (talk)
- In re "Almost every time I am told by Wikipedia that someone is Jewish, I fail to see any connection between that claim and anything else": Okay, you admit that you don't understand how this affects people's lives. That's okay; not everyone understands the implication of every little detail in an article.
- I, for example, don't understand why the overly long lead for Trump needs to mention that he went to university. Maybe there's something I'm missing there, like it's a subtle slam on the "very stable genius" that he only got a bachelor's degree, or that he didn't get into a more prestigious school? Or it's meant to reassure people that even though the US hasn't elected a president without a graduate degree since the 1980s, he at least finished college? Or to irk the Vietnam vets, because graduating in 1968 probably meant that you were trying to avoid military service? But apparently it means something to others, because it's still there.
- However:
- I don't understand how Trump's college experience affected his life – but that doesn't mean that it didn't do so. Similarly, your lack of understanding of how someone's ethnoreligious status affected their lives doesn't mean that it actually didn't affect their lives.
- I don't find meaning in Trump's college experience – but that doesn't mean that other people don't find meaning in it. Similarly, you don't find meaning in knowing someone's ethnoreligious status – but that doesn't mean that all other readers also find it meaningless.
- "I fail to see any connection" means you have an opportunity to educate yourself on that subject. Of course, you may not want to (so many things to learn, so little time left to do it in...), and that's fine, but we shouldn't limit Wikipedia to things all editors understand or value. WhatamIdoing (talk) 01:50, 1 October 2025 (UTC)
- That is close enough to what I said or thought your position was, in my view. And demonstrably, there are myriad examples where your generalization is false, but I have no way of knowing what articles you read. I completely understand if you don't have any particular connection to Scottishness in your field, whatever that is. But Andrew Carnegie did. And Sean Connery did. Those are just the first 2 Scots I thought of, but consider that there are very many people for whom their ethnoreligious community was an important part of whatever they did. Maybe not for any random politician or businessperson or actor, but for some. Andre🚐 00:43, 1 October 2025 (UTC)
- To clarify my now multiply reinterpreted position, it's really very simple. Almost every time I am told by Wikipedia that someone is Jewish, I fail to see any connection between that claim and anything else in that person's article. If I ever get an article, it will be of zero significance to mention that I am a failed Presbyterian, or have Scottish ancestry from seven generations ago. HiLo48 (talk) 00:20, 1 October 2025 (UTC)
- You say there is Jew-tagging, but we should should not acknowledge it in an essay. That does not follow. Alanscottwalker (talk) 22:51, 30 September 2025 (UTC)
- Sure it does, that is consistent with WP:DENY. Andre🚐 23:54, 30 September 2025 (UTC)
- No, that reasoning means having the page, "DENY", itself, is in contravention of DENY. --Alanscottwalker (talk) 00:18, 1 October 2025 (UTC)
- WP:BEANS, then. Andre🚐 00:39, 1 October 2025 (UTC)
- This is not something no one knows about, just do google. For goodness sake, as someone else says above, knowledge of this is important to have. Alanscottwalker (talk) 01:45, 1 October 2025 (UTC)
- Alan, I'm going to respond here to your initial response to me above, since the intervening discussion and outdent makes it impractical to do so elsewhere. If I'm honest, I'm confused by your question of who my thoughts were directed at. Admittedly, I could have placed them in a different spot rather than where I did in relation to Bishonen's point. Most of the substance of my post was not meant as a response to her; rather I wanted to acknowledge that her mentioning that little turn-of-phrase adopted by the alt-right hate-mongers was a significant reminder of the reach of our content, and something to keep in mind when we make any decisions in this area. But the rest of my thoughts were only tangentially related to her observation. That said, I think the general thrust of my comments are broadly applicable to the inquiry being made here. This discussion began with the question of whether we should have advisory guidance on the issue of when to include reference to Jewish heritage for BLP subjects, and when and how to determine if such content is problematic. At least, that is my interpretation of Doug's question and elements of the discussion which followed. My position is that we should go incredibly softly along that path, particularly if it involves departing at all from our standard approach on references to ethnicity. Because we can start out with the best intentions there, intending to short-circuit bigotry, and yet end up playing right into the objectives of antisemites, by unintentionally implying that Jewish heritage is something that should typically not be acknowledged. While that would clearly never be the intent of any essay or PAG we promoted on this project, using too heavy a hand on this matter carries with it real danger of: 1) giving the impression that being labelled as Jewish is an undesirable thing, 2) reducing the overall profile of the Jewish people in our content, in a way that would not happen if we didn't lose sight of the forest for the trees by trying to "protect" Jewish individuals and our content about them, and 3) fuel the ever-mutating, ever-accelerating ecosystem of conspiracy theories about how the Jewish race is covertly infiltrating positions of influence in global culture and manipulating the levers of society. Now, so far the discussion about what we might do in this area has been incredibly vague, and so my concerns were equally generalized. Nevertheless, I think they are on point and involve factors very important to consider here. Does that clarify why I made the observations I did? SnowRise let's rap 03:34, 1 October 2025 (UTC)
- Thanks. My question was who your observations were in response to, and as you say, it was not in response, although it was formatted as one.
- At any rate, imo, having an Essay is 'going slow'. Not only does an Essay not require a broad consensus, an essay can be edited by you and others, interested. Essays often have the purpose of applying policy/guideline to particular issues, and here we have a particular known issue. Nor are essays often kept that go against policy, and essays can elucidate ways to better policy, through the lens of particular concrete issues. WAID, for example, has laid out an approach -- to understand that approach, it would likely be good if it is elucidated in an essay, and especially an essay addressing this concrete issue. Alanscottwalker (talk) 22:38, 2 October 2025 (UTC)
- Alan, I'm going to respond here to your initial response to me above, since the intervening discussion and outdent makes it impractical to do so elsewhere. If I'm honest, I'm confused by your question of who my thoughts were directed at. Admittedly, I could have placed them in a different spot rather than where I did in relation to Bishonen's point. Most of the substance of my post was not meant as a response to her; rather I wanted to acknowledge that her mentioning that little turn-of-phrase adopted by the alt-right hate-mongers was a significant reminder of the reach of our content, and something to keep in mind when we make any decisions in this area. But the rest of my thoughts were only tangentially related to her observation. That said, I think the general thrust of my comments are broadly applicable to the inquiry being made here. This discussion began with the question of whether we should have advisory guidance on the issue of when to include reference to Jewish heritage for BLP subjects, and when and how to determine if such content is problematic. At least, that is my interpretation of Doug's question and elements of the discussion which followed. My position is that we should go incredibly softly along that path, particularly if it involves departing at all from our standard approach on references to ethnicity. Because we can start out with the best intentions there, intending to short-circuit bigotry, and yet end up playing right into the objectives of antisemites, by unintentionally implying that Jewish heritage is something that should typically not be acknowledged. While that would clearly never be the intent of any essay or PAG we promoted on this project, using too heavy a hand on this matter carries with it real danger of: 1) giving the impression that being labelled as Jewish is an undesirable thing, 2) reducing the overall profile of the Jewish people in our content, in a way that would not happen if we didn't lose sight of the forest for the trees by trying to "protect" Jewish individuals and our content about them, and 3) fuel the ever-mutating, ever-accelerating ecosystem of conspiracy theories about how the Jewish race is covertly infiltrating positions of influence in global culture and manipulating the levers of society. Now, so far the discussion about what we might do in this area has been incredibly vague, and so my concerns were equally generalized. Nevertheless, I think they are on point and involve factors very important to consider here. Does that clarify why I made the observations I did? SnowRise let's rap 03:34, 1 October 2025 (UTC)
- This is not something no one knows about, just do google. For goodness sake, as someone else says above, knowledge of this is important to have. Alanscottwalker (talk) 01:45, 1 October 2025 (UTC)
- WP:BEANS, then. Andre🚐 00:39, 1 October 2025 (UTC)
- No, that reasoning means having the page, "DENY", itself, is in contravention of DENY. --Alanscottwalker (talk) 00:18, 1 October 2025 (UTC)
- Sure it does, that is consistent with WP:DENY. Andre🚐 23:54, 30 September 2025 (UTC)
- Huh? I don't see where you are getting that from. HiLo48 says in "almost every article that says someone is Jewish," it would not have any encyclopedic value, and be therefore Jew-tagging. Yes, only some people should have their ethnicity mentioned in the lead, as far a I know, this was never in dispute by anyone, except perhaps people who are saying that the set of notable-relevant people is negligibly large. The issue of "Jew-tagging" is when someone tags, probably a living person, probably someone not specifically known for or associated with Judaism, with that ethnicity. I am arguing that we should not make a special guideline for this, or a special essay about it, because it is already covered by existing guidelines, which are already not interpreted correctly, and we should not lean even more on the tendency to adopt a postmodern idealism that cultural and ethnic differences are rarely an important part of someone's biography. So I broadly agree with SnowRise. Andre🚐 22:40, 30 September 2025 (UTC)
- Was it? Wasn't the issue whether or not it is true that everyone who is Jewish is notable for being a Jewish? Alanscottwalker (talk) 22:28, 30 September 2025 (UTC)
- What is not clear about that comment? It is an expression of an opinion that nearly every mention that says someone is Jewish lacks encyclopedic value. Andre🚐 22:17, 30 September 2025 (UTC)
- Well, that comment is certainly not clear, as you have presented it. You can ask that HiLo about it. No one else is suggesting they speak for HiLo, perhaps you misunderstood. Alanscottwalker (talk) 22:14, 30 September 2025 (UTC)
- Are you also all aware that it is the High Holy Days and observant Jews who edit are probably not going to edit Wikipedia or participate in discussions? This discussion inasmuch as it leads to any proposals or actual changes should at least wait a few weeks. Andre🚐 18:21, 28 September 2025 (UTC)
- User:Doug Weller, yes an essay is a great idea. It serves a couple purposes: define the term. Examples of use. Links to previous discussions (including RfCs). Summaries of arguments. If it's good, it will inform a new MOS guideline. -- GreenC 05:49, 30 September 2025 (UTC)
- We already have WP:BLPCAT and WP:CAT/R, which contain such good advice as to only include religion/sexual orientation where the person seld-identifies as a member of a particular religion or orientation, and (my emphasis) they are notable because of their religion/orientation, and... they're rarely adhered to. I've not knowingly added or removed Jewish categories from any article, that I can recall, and I've been able to keep Category:Irish Roman Catholics manageable, but the objections and reverts when I dare to remove Category:American Roman Catholics when I also remove Category:Irish Roman Catholics from an Irish-American or dual-citizen actor or musician... So yes, an essay may well be useful, emphasising the BLPCAT guidelines. BastunĖġáḍβáś₮ŭŃ! 11:23, 2 October 2025 (UTC)
- Essays are cheap. You don't need to ask anyone before writing one, you can just write one and see if anyone cares about it or likes it. If you're not sure, put it in userspace. Anyway, I think that such an essay might be useful if the specific behavior it describes is common enough, especially to highlight how to identify it - it's the sort of thing that could slip under the radar, so being able to point to an essay that lays out what it is, how to recognize it, why it's an issue and so on has some value. Or even if people are just talking about it, an essay has some value for clarity. I think the discussion above shows that it might end up being a controversial essay, but so what, essays are allowed to be controversial; giving people who assert that it's happening in any particular case an easy essay to link for easy reference rather than repeating their explanations and arguments every time still has value. But you'd have to think hard about what exactly the essay covers, because just based on the discussions above there's a lot of confusion. Also, for anyone who's confused, for for background, see [14], which led to a signpost article with more details. And of course the relevant policy is MOS:ETHNICITY - all of this could reasonably be summarized in an essay. --Aquillion (talk) 15:44, 2 October 2025 (UTC)
- One good thing such an essay might consider addressing as context, is that with BLP's, especially, but often other bios, we are perhaps in a sense 'flying blind'. We have no single RS biography to follow (or at best a very brief RS biographical note), let alone any in depth RS biography, instead we collect info from here and there (often from journalism or tweets, etc.), and put it together ourselves. Perhaps, we should stress again what a serious undertaking and responsibility that is, that we are the only publisher of someone's biography, especially a living someone (highlighting the care we need to have for people, their self perception, their privacy, in such a circumstance). -- Alanscottwalker (talk) 23:05, 2 October 2025 (UTC)
- I wasn't aware of the term "jew tagging" before this. I've seen social media posts suggesting that Wikipedia tends to remove or diminish Jewish heritage in biographies: see [15], [16], and [17]. Given that it's giving some people a false impression, I agree that it would be helpful to have an essay explaining Wikipedia's response to "jew tagging". (I still think "born to a Jewish family" is an awkward phrase that creates more problems than it fixes, though.) Apocheir (talk) 21:20, 5 October 2025 (UTC)
- To be clearer, "Jew" and "Jewish" are not dirty words, and not every edit that adds "Jew" to an article is being made by an antisemite or a philosemite. "Jew tagging" is real, but we should be careful not to remove or exclude useful cited information, and that needs to be part of the essay too. Apocheir (talk) 19:50, 11 October 2025 (UTC)
This discussion may also apply to families in addition to individuals - see the discussion I'm having with Politrukki at Talk:Guggenheim family, concerning whether a single mention of ethnicity in the article warrants calling the family "Amerioan-Jewish" in the lede. Acroterion (talk) 16:36, 11 October 2025 (UTC)
- Mentioning that something is Jewish is not, in itself, "jew-tagging". I don't see anything about Politrukki's edit history that implies that it is. Please assume good faith. Apocheir (talk) 20:37, 11 October 2025 (UTC)
- You might want to AGF too; I am doing so with respect to Politrukki, I merely note that this topic can extend beyond individuals. Acroterion (talk) 02:34, 13 October 2025 (UTC)
- Unless the family is primarily known for religious activities (it is not), then that's an inappropriate descriptor. Bremps... 00:41, 12 October 2025 (UTC)
- Jewish people are an Ethnoreligious group, meaning that "religious activities" are not always relevant. Saying that someone is Jewish could mean that you are saying something about their religion or their ethnicity. "This is a Jewish family" is not the equivalent of saying "This is a Catholic family". To give an example, I know a woman who was born and raised in a Jewish family, and who is now a dedicated Catholic. She did not stop being ethnically Jewish when she became religiously Catholic. It's therefore accurate (though incomplete) to describe her as being Jewish in the sense of ethnicity, even though she engages in no Jewish religious activities. If she were notable, we'd probably try to clarify that her Jewishness is ethnic rather than religious by writing something like "Born into an observant Ashkenazi Jewish family, she converted to Catholicism in her 30s..."; if her family were notable, we'd probably describe them as "a Jewish American family". WhatamIdoing (talk) 19:35, 12 October 2025 (UTC)
- Thank you mentioning this discussion at the article talk page. Had you not done so, I would've missed you mentioning me here. This has nothing to do with you, but I disabled mention notifications out of annoyance few years ago.
- I have not fully read the discussion here, but if an essay says an editor can't reasonably disagree with someone who pulled out a "Jew tagging" card, the essay is wrong. If there ever was a "Jew tagging" problem at the Guggenheim family article, the problem ceased to exist when I reverted your bold edit (I assume that when you said
"was added by an IP"
you meant this edit from 2022). I took responsibility of a single edit and that is not what the essay should be about. Politrukki (talk) 16:44, 14 October 2025 (UTC)
Edit the article on pregnancy to make it clear not everyone capable of pregnancy identifies as a girl, woman or mother.
[edit]If we're going to respect trans identity at all, we should go forth and update other articles. The same goes for prostate cancer and men.
Hist4ian (talk) 21:37, 1 October 2025 (UTC)
- Why are you posting here rather than on the article talk page? When you do post there, have reliable sources lined up to support your position. Donald Albury 22:49, 1 October 2025 (UTC)
- Apparently they did post to the Pregnancy talk page before posting here at the VP (see Talk:Pregnancy § Replace all cultural identity language like "woman" and "mother" with alternatives such as "pregnant person," "human with a uterus," "AFAB", even "gravida" if we have to); an admin told them to post here if they wanted to discuss the "radical change" [18]. Some1 (talk) 23:38, 1 October 2025 (UTC)
- I see, now. So, does anyone have a more useful response than mine? Donald Albury 01:12, 2 October 2025 (UTC)
- Apparently they did post to the Pregnancy talk page before posting here at the VP (see Talk:Pregnancy § Replace all cultural identity language like "woman" and "mother" with alternatives such as "pregnant person," "human with a uterus," "AFAB", even "gravida" if we have to); an admin told them to post here if they wanted to discuss the "radical change" [18]. Some1 (talk) 23:38, 1 October 2025 (UTC)
- Rather than add explanatory sentences that lengthen the article, it would be easier to change "woman" (ambiguous) to "female" (exclusively refers to biological sex). And so on. Cremastra (talk · contribs) 01:45, 2 October 2025 (UTC)
- From the lead of Female: "In humans, the word female can also be used to refer to gender in the social sense of gender role or gender identity." WhatamIdoing (talk) 02:27, 2 October 2025 (UTC)
- Sigh, I didn't know that. That seems... unnecessarily confusing. Is "biological female" unambiguous enough? Cremastra (talk · contribs) 12:41, 2 October 2025 (UTC)
- Probably not - see Wikipedia:Redirects for discussion/Log/2025 September 23#Biological woman/man. Thryduulf (talk) 15:12, 2 October 2025 (UTC)
- I commented at the RfD, and I disagree with the nom's interpretation. I think "biological female" quite unambiguously refers to people with two X chromosomes with female reproductive organs. How much more specific do we need to get?
- Actually, we could just say "Pregnancy is the time during which one or more offspring gestates inside a uterus". That's unambiguous, and would work. It's also simpler than a footnote. Cremastra (talk · contribs) 21:53, 2 October 2025 (UTC)
- The fact that others disagree with you in good faith indicates that it is not unambiguous - for starters there are people who are biologically female but whose chromosomes are not XX. Thryduulf (talk) 22:21, 2 October 2025 (UTC)
- I don't want to argue with you right now. Comment at the RfD rather than deliberately sidetracking discussion here.
- Do you have constructive thoughts on my proposal? Cremastra (talk · contribs) 22:24, 2 October 2025 (UTC)
- I don't have a particular opinion about the redirect. I do however have a strong opinion that niether answering a direct question of yours, nor correcting your misstatement of fact in response to my reply, is "sidetracking discussion". Thryduulf (talk) 23:37, 2 October 2025 (UTC)
- By proposal I meant my suggestion of removing any "woman/female" qualifier and just saying "pregnancy is the time during which one or more offspring gestates inside a uterus". Your commenting on what is the domain of the RfD discussion as opposed to the specific phrasing being workshopped here is definitely sidetracking the discussion here. Cremastra (talk · contribs) 16:07, 3 October 2025 (UTC)
- “Deliberately “? You have been around enough to know you shouldn’t say that, AGF is something I’m sure you are aware of. Doug Weller talk 19:11, 3 October 2025 (UTC)
- I don't have a particular opinion about the redirect. I do however have a strong opinion that niether answering a direct question of yours, nor correcting your misstatement of fact in response to my reply, is "sidetracking discussion". Thryduulf (talk) 23:37, 2 October 2025 (UTC)
- The fact that others disagree with you in good faith indicates that it is not unambiguous - for starters there are people who are biologically female but whose chromosomes are not XX. Thryduulf (talk) 22:21, 2 October 2025 (UTC)
- I believe most trans masculine people would not find that very kind or appropriate Sock-the-guy (talk) 03:46, 3 October 2025 (UTC)
- @Sock-the-guy I very much understand that this is a sensitive topic and have no wish to needlessly offend people. However, as pointed out above, the word "female" can also be ambiguous. This is a biology article that clearly discusses physical sex rather than gender, and biological terms are going to be used.
- Do you think my suggestion above of removing the qualifier and just saying "Pregnancy is the time during which one or more offspring gestates inside a uterus" would be more appropriate? Cremastra (talk · contribs) 16:02, 3 October 2025 (UTC)
- Probably not - see Wikipedia:Redirects for discussion/Log/2025 September 23#Biological woman/man. Thryduulf (talk) 15:12, 2 October 2025 (UTC)
- Sigh, I didn't know that. That seems... unnecessarily confusing. Is "biological female" unambiguous enough? Cremastra (talk · contribs) 12:41, 2 October 2025 (UTC)
- From the lead of Female: "In humans, the word female can also be used to refer to gender in the social sense of gender role or gender identity." WhatamIdoing (talk) 02:27, 2 October 2025 (UTC)
- There are a half dozen discussions of this in the article talk page archives, none having resulted in a consensus to change the article lede. This is, of course, an issue that far transcends pregnancy, as I have also seen discussions of whether similar reference to people other than "women" should be included with respect to menstruation and abortion. The sense broadly expressed across these discussions is the same, and should be articulated on a policy page so that we have language to which to point when it is perennially raised again. BD2412 T 01:58, 2 October 2025 (UTC)
- I believe that the last general discussion about this was five years ago, in Wikipedia:Village pump (proposals)/Archive 161#Gender-neutral language in human sex-specific articles.
- Separately, a handful of us spent about a million bytes of discussion in 2022. The following things were learned:
- The 'real world' has only one agreed-upon standard: When healthcare providers are speaking directly to individual patients, the providers should adopt the patients' preferred language. That means that if you're a midwife or obstetrician, you will talk to your first patient of the day about whether "Mummy" can feel her "baby" kicking yet, and you talk to your second patient about whether "they" can feel their "fetus" kicking yet, and you treat both of them as if their preferred language is the most natural, obvious, normal thing in the world.
- There are multiple valid and traditional definitions of the word woman, including:
- adult human with a feminine gender identity
- adult human with a feminine gender expression
- adult human with a feminine gender role
- adult human whose perinatal testing or external genitalia caused her to be assigned female at birth
- adult human of the female sex (=produces ova instead of sperm during reproductive years)
- These are the models discussed in reliable sources:
- gender-specific (e.g., women or trans men, but not females or people; usually woman-centered)
- sex-specific (e.g., females instead of women)
- gender-neutral/gender-vague wording
- gender inclusiveness through strategic vagueness (e.g., write people or patients, and assume readers will glork the meaning from context)
- gender inclusiveness through biological reductionism (e.g., people with a uterus, the uterus contracts)
- gender-additive (e.g., women and other people who menstruate)
- varying language (e.g., some sentences are gender-specific and others aren't – this is common in Wikipedia articles, even if editors aren't trying to do this deliberately)
- separate content for trans people (not really feasible for Wikipedia)
- Some gender-neutral models are criticized for being dehumanizing (e.g., reducing people to their body parts) or ignoring social factors (e.g., illegal workplace pregnancy discrimination is frequently motivated by beliefs about "correct" gender roles, so it happens to women, not to females). Others are criticized for being confusing (40% of women in one survey weren't sure what a cervix is, so a statement like "People with a cervix should get checked for cervical cancer" is unclear to about 40% of the people who should get checked for cervical cancer). Most models are criticized for erasing cisgendered women.
- Almost no research specifies the gender identity of trial participants, so when a study says "women", it almost always means an adult human whose body is of the type expected to produce eggs instead of sperm, regardless of gender identity, expression, role, or anything else.
- Nearly all requests for gender inclusiveness (both on wiki and in the real world) involve making content about the female reproductive system not mention the word women. Almost no requests involve making content about the male reproductive system not mention men. For example, compare these lists of discussions on wiki:
- Requests related to making Wikipedia's article on Pregnancy gender-neutral: Talk:Pregnancy/Archive 2#POV and accuracy dispute, Talk:Pregnancy/Archive 8#Trans-inclusivity and replacing the word "woman", Talk:Pregnancy/Archive 8#Non-normative pregnancy, Talk:Pregnancy/Archive 8#"Women" or "female humans", Talk:Pregnancy/Archive 9#Changing pronouns and gendered language, Talk:Pregnancy/Archive 9#Semi-protected edit request on 23 April 2022, Talk:Pregnancy/Archive 9#Info box or edit note?, Talk:Pregnancy/Archive 9#Edit note wording, Talk:Pregnancy/Archive 10#Transgender in lead, Talk:Pregnancy/Archive 11#MOS:GNL in the lead, Talk:Pregnancy/Archive 11#Semi-protected edit request on 21 May 2024, and more.
- Other articles related to the female reproductive system: Talk:Mastectomy#Gender neutral language?, Talk:Premenstrual syndrome#Math lesson, Talk:Diabetes and pregnancy#Feedback, Talk:Breast reduction#Gender-neutral language, Talk:Female condom#Requested move 31 March 2024, Talk:Fetal scalp blood testing#Peer Review, Talk:Feminine hygiene#Naming of article, Talk:Feminine hygiene#Requested move 23 October 2019, Talk:Feminine hygiene#Requested move 27 October 2019, Talk:Labor induction#Gender Neutral Language, Talk:HIV and pregnancy#UCF COM Peer Review, Talk:Braxton Hicks contractions#Generality of the term pregnant, Talk:Polycystic ovary syndrome/Archive 1#People with ovaries, Talk:Polycystic ovary syndrome#Outdated Terminology, Talk:Childbirth positions#The word "Mother", Talk:Heavy menstrual bleeding#Peer Review 2, Talk:Antenatal depression#Gender inclusive page, Talk:Postmenopausal confusion#Improving article with inclusive language, Talk:Cervical effacement#Group Peer Review, Talk:Luteal phase#Edits to Luteal Phase Outline, and more.
- Similar-ish requests for male-focused articles: Talk:Ethics of circumcision#Any valid reason for reversion of gender-neutral language?, Talk:Sperm bank#Part 1, Talk:Sperm donation#Gender neutral language?, Talk:Vasectomy#Non-gendered language, and, um, that's about it.
- WhatamIdoing (talk) 02:26, 2 October 2025 (UTC)
- Should something (maybe a paragraph or two summarizing the 2019 RfC and related discussions) be added to MOS:GNL so that there's something to point to when this topic comes up again? Some1 (talk) 02:52, 2 October 2025 (UTC)
- Maybe, but what would we agree to say? WhatamIdoing (talk) 05:21, 2 October 2025 (UTC)
- Good question. For now, I think your idea of adding a FAQ template to the talk page(s) [19] is a good one. Some1 (talk) 22:43, 2 October 2025 (UTC)
- Maybe, but what would we agree to say? WhatamIdoing (talk) 05:21, 2 October 2025 (UTC)
- Should something (maybe a paragraph or two summarizing the 2019 RfC and related discussions) be added to MOS:GNL so that there's something to point to when this topic comes up again? Some1 (talk) 02:52, 2 October 2025 (UTC)
- Would it not be sufficient to merely state that in a paragraph, and then state that the rest of the article uses gendered language for clarity? Sock-the-guy (talk) 05:43, 2 October 2025 (UTC)
- I would be fine coming up with a standard footnote to drop in such articles on the first mention of "women". BD2412 T 18:02, 2 October 2025 (UTC)
- Perhaps something like
- Many people who are not women, such as Trans men can also be pregnant. For clarity, this article uses gendered language, which is not meant to imply that anyone who may experience such things is a woman. For more about queer reproductive issues, see <insert article here>. Sock-the-guy (talk) 03:52, 3 October 2025 (UTC)
- I think that's a good solution. Sapphaline (talk) 09:05, 3 October 2025 (UTC)
- A footnote is the best response to this. It would be undue and not adhering to NPOV to change the language entirely because most RS do not use that language either. EvergreenFir (talk) 16:37, 3 October 2025 (UTC)
- Count me in as another supporter of the footnote option. What we have now is not fully correct, but changing the language across the entire article would be unclear. So we should acknowledge the caveat briefly and move on. Loki (talk) 23:18, 4 October 2025 (UTC)
- I support a footnote, but it's not my #1 option. Maybe we should hold a multi-option RfC? Cremastra (talk · contribs) 01:13, 5 October 2025 (UTC)
- I would be fine coming up with a standard footnote to drop in such articles on the first mention of "women". BD2412 T 18:02, 2 October 2025 (UTC)
- I think this is a reasonable direction, provided we stick closely to verifiable, reliable sources and keep the tone neutral. Medical and public health guidance already acknowledge that pregnancy is possible for some transgender men and non-binary people with a uterus, and that trans women (and others who retain a prostate) remain at risk of prostate cancer.
- Proposed inclusive wording for the pregnancy article :
Pregnancy is the period during which one or more embryos or fetuses develop inside a uterus. People who can become pregnant include women (both cisgender and transgender) and other people who retain a functioning uterus, such as some transgender men and some non-binary people.
- Suggested clarifying sentence for prostate cancer articles :
Prostate cancer affects the prostate gland; people who currently have a prostate — primarily cisgender men, and some transgender women or other people assigned male at birth who retain a prostate — are at risk of prostate cancer.
- This way, we respect trans identities and follow WP:NPOV and WP:V by basing wording directly on high-quality medical sources (NHS, ACOG, CDC, Prostate Cancer UK, ACS).
- == References ==
- "Having a baby if you're LGBT+". NHS. Retrieved 4 October 2025.
- "Health Care for Transgender and Gender Diverse Individuals (Committee Opinion No. 823)". American College of Obstetricians and Gynecologists. March 2021. Retrieved 4 October 2025.
- "Pregnancy in transgender men". PMCID (open access). 2021. Retrieved 4 October 2025.
- "Testosterone Use and Risk for Pregnancy". U.S. Centers for Disease Control and Prevention (CDC). 19 November 2024. Retrieved 4 October 2025.
- "Trans women and prostate cancer". Prostate Cancer UK. Retrieved 4 October 2025.
- "Cancer care for transgender and gender-nonconforming people (PDF)" (PDF). American Cancer Society. 2024. Retrieved 4 October 2025.
- [Note : This reply was generated by an AI following human directions, with minimal human modifications] Cdr. Erwin Smith (talk) 06:31, 4 October 2025 (UTC)
- Those sources may be appropriate to an article titled Pregnancy in transgender men, but the article on general pregnancy should use general sources. A definitive treatise is Williams’ Obstetrics (McGraw Hill, currently 26th edition), which uses the words “woman” and “women”, unqualified, liberally. It would be extremely undue weight to devote lead space to explaining a niche medical edge case (occurring in perhaps ~1000s of patients) in a broad topic article about ~billions of patients. Barnards.tar.gz (talk) 07:32, 4 October 2025 (UTC)
- Thanks — that’s a fair point about relying on mainstream, authoritative textbooks for a broad article. Williams’ Obstetrics is a major reference and should certainly be cited where it supports general statements about pregnancy. At the same time, my concern is strictly factual accuracy: a small, sourced statement that some people who are not women can become pregnant is not advocacy, it’s a narrowly targeted factual clarification backed by clinical guidance and case literature. I think we can satisfy both priorities — respect the mainstream textbook view in the lead and keep the lead concise, while avoiding a technically incorrect blanket statement by adding a short, sourced clarification in the body.
- WP:V/WP:MEDRS : For medical topics, we should rely on high-quality sources. Cite Williams’ Obstetrics (or other standard obstetrics texts) for the general physiological statements, and cite NHS/ACOG/CDC/peer-reviewed clinical reviews for the factual point about pregnancies occurring in people assigned female at birth who now identify differently.
- WP:WEIGHT/WP:DUE : The lead should reflect what the best sources say about the topic as a whole. If mainstream textbooks describe pregnancy in terms of women, keep the lead framed around that majority. But WP:SUMMARY and WP:UNDUE don’t require us to erase documented clinically relevant exceptions from the body of the article — a short, sourced sentence in an appropriate section is an appropriate place for a minority but medically documented phenomenon.
- Readability & Accuracy : The lead’s job is to summarise; the body’s job is to provide necessary nuance.
- Cdr. Erwin Smith (talk) 09:33, 4 October 2025 (UTC)
- Is this an AI response? Barnards.tar.gz (talk) 10:57, 4 October 2025 (UTC)
- Yes, however it was read carefully by me multiple times to ensure it's not a meaningless wall of text.
- Since I added the disclaimer on the usage of AI on the first reply, and you replied after reading it, I thought it would've been repetitive and redundant to do so again and again. I can discontinue if you want, but I'd like to hear your thoughts on the proposal itself. Cdr. Erwin Smith (talk) 12:05, 4 October 2025 (UTC)
- I would prefer to talk to you directly; we can all ask AI for its opinion elsewhere. Regarding factual accuracy, you could also argue to put a footnote on the words “inside” or “uterus”, so as to be inclusive of ectopic pregnancy, a condition with incidence multiple orders of magnitude higher than trans-man-pregnancy - but I would argue this is also inappropriate, as we shouldn’t clutter the lead with details of rare edge cases. As another example, take a look at the lead sentence of Human. We could put a footnote against the word “bipedality” clarifying that, actually, some humans only have one leg. But none of this would serve the reader. Barnards.tar.gz (talk) 21:38, 4 October 2025 (UTC)
- Both of these are medical conditions; being trans is not a medical condition. 46.242.15.7 (talk) 23:15, 4 October 2025 (UTC)
- What is it then? cheers. anastrophe, an editor he is. 01:55, 5 October 2025 (UTC)
- It has to do with one's gender identity. I don't especially see how that's a "medical condition", seeing as "medical condition" usually suggests some kind of abnormality or infection, which is obviously not the case here. But I don't really care either way and this is off topic. Cremastra (talk · contribs) 01:58, 5 October 2025 (UTC)
- Whether being trans is "a medical condition" is a WP:POV. There is no scientific law that determines the meaning of any words. The meaning of all words is socially constructed, and society can (and, in previous centuries, did) construct the meaning of "medical condition" so that it includes being trans. I don't personally hold that POV myself, but I recognize that my POV is a POV, and not the absolute truth. WhatamIdoing (talk) 02:29, 5 October 2025 (UTC)
- No one said that it's the "absolute truth". Wikipedia should follow mainstream opinions; the current mainstream opinion is transgenderness not being a medical condition. Sapphaline (talk) 08:11, 5 October 2025 (UTC)
- Someone did, however, make an unqualifed, absolute assertion that being trans is not a medical condition.
- I agree that the current mainstream Western academic view is that being trans is not a medical condition. The mainstream Western popular view probably disagrees. I don't know if non-Western views match the Western ones. WhatamIdoing (talk) 01:39, 6 October 2025 (UTC)
- No one said that it's the "absolute truth". Wikipedia should follow mainstream opinions; the current mainstream opinion is transgenderness not being a medical condition. Sapphaline (talk) 08:11, 5 October 2025 (UTC)
- Leaving aside what WhatamIdoing pointed out about definitions, you could pick a lot of other words in the intro to human that might need footnoting despite not being a "condition". For example, "humans are highly social" (except for some hermits and misanthropes) and "humans are omnivores" (except some vegetarians and vegans). Anomie⚔ 12:09, 5 October 2025 (UTC)
- What is it then? cheers. anastrophe, an editor he is. 01:55, 5 October 2025 (UTC)
- Both of these are medical conditions; being trans is not a medical condition. 46.242.15.7 (talk) 23:15, 4 October 2025 (UTC)
- Thanks, I was testing it out just this once to see how helpful would an AI be in a complex discussion.
- As for your concern, I suggested to keep the header by the book as you had suggested. Only the body would get changed to reflect the gender nuances. Cdr. Erwin Smith (talk) 19:31, 12 October 2025 (UTC)
- I would prefer to talk to you directly; we can all ask AI for its opinion elsewhere. Regarding factual accuracy, you could also argue to put a footnote on the words “inside” or “uterus”, so as to be inclusive of ectopic pregnancy, a condition with incidence multiple orders of magnitude higher than trans-man-pregnancy - but I would argue this is also inappropriate, as we shouldn’t clutter the lead with details of rare edge cases. As another example, take a look at the lead sentence of Human. We could put a footnote against the word “bipedality” clarifying that, actually, some humans only have one leg. But none of this would serve the reader. Barnards.tar.gz (talk) 21:38, 4 October 2025 (UTC)
- Is this an AI response? Barnards.tar.gz (talk) 10:57, 4 October 2025 (UTC)
- Thanks — that’s a fair point about relying on mainstream, authoritative textbooks for a broad article. Williams’ Obstetrics is a major reference and should certainly be cited where it supports general statements about pregnancy. At the same time, my concern is strictly factual accuracy: a small, sourced statement that some people who are not women can become pregnant is not advocacy, it’s a narrowly targeted factual clarification backed by clinical guidance and case literature. I think we can satisfy both priorities — respect the mainstream textbook view in the lead and keep the lead concise, while avoiding a technically incorrect blanket statement by adding a short, sourced clarification in the body.
- Those sources may be appropriate to an article titled Pregnancy in transgender men, but the article on general pregnancy should use general sources. A definitive treatise is Williams’ Obstetrics (McGraw Hill, currently 26th edition), which uses the words “woman” and “women”, unqualified, liberally. It would be extremely undue weight to devote lead space to explaining a niche medical edge case (occurring in perhaps ~1000s of patients) in a broad topic article about ~billions of patients. Barnards.tar.gz (talk) 07:32, 4 October 2025 (UTC)
- There are aspects of that language that we cannot use in a neutrally worded encyclopedia. I don't think we can say
Many people who are not women can become pregnant
because this implies a more substantial number than sources agree on, and takes a stance on a political dispute in Wikipedia's voice. I think we can say thatA number of people who identify as not being women can become pregnant
. BD2412 T 13:53, 4 October 2025 (UTC)- I still think just saying "pregnancy is the period during which one or more embryos or fetuses develop inside a uterus" is the best plan. It's concise, WP:DUE, verifiable, correct, and avoids stuffing up every article with undue tangents. Cremastra (talk · contribs) 13:57, 4 October 2025 (UTC)
- I'm assuming that people who want to replace instances of the word woman in the Pregnancy article (and other human sex-specific articles) want to do so throughout the whole article, not just the lead sentence. (e.g. [20]) Some1 (talk) 14:31, 4 October 2025 (UTC)
- That's why we go for a Via Media.
- 1. Go by the book, and let the lead remain unchanged.
- 2. Add the narrow factual clarifications backed by medical sources, and change the body. Cdr. Erwin Smith (talk) 15:21, 4 October 2025 (UTC)
- The body of the Pregnancy article already says "Women as well as intersex and transgender people who have a functioning female reproductive system are capable of pregnancy." Some1 (talk) 15:47, 4 October 2025 (UTC)
- We have to change some wording in body to match this sentence too. Cdr. Erwin Smith (talk) 16:45, 4 October 2025 (UTC)
- I don't think the change away from "mother" is a necessity in that case. A "mother" is the person with the egg that got fertilized, regardless of their gender identity, which isn't relevant here. As I commented at the RfD,
It is common for conservative activists/writers etc. to misunderstand the sex/gender distinction, but it's very disheartening to see it from a progressive.
Cremastra (talk · contribs) 16:53, 4 October 2025 (UTC)- The US pro-choice movement strongly objects to calling pregnant women "mothers". Worldwide, most pregnant people are indisputably mothers (because most have already given birth in the past), but there are gendered and social implications to "mother", and they find that a statement like "A woman should be allowed to get an abortion" gets a different emotional/visceral response than "A mother should be allowed to get an abortion". WhatamIdoing (talk) 17:15, 4 October 2025 (UTC)
- Okay, but I think this is a niche objection. We're a global encyclopedia not, as it happens, an American pro-choice brochure. We can use the word 'mother' the way we choose. (For the record, I am pro-choice, but not American.) Cremastra (talk · contribs) 17:53, 4 October 2025 (UTC)
- I believe that this idea has no chance of being accepted. WhatamIdoing (talk) 02:30, 5 October 2025 (UTC)
- Okay, but I think this is a niche objection. We're a global encyclopedia not, as it happens, an American pro-choice brochure. We can use the word 'mother' the way we choose. (For the record, I am pro-choice, but not American.) Cremastra (talk · contribs) 17:53, 4 October 2025 (UTC)
- The US pro-choice movement strongly objects to calling pregnant women "mothers". Worldwide, most pregnant people are indisputably mothers (because most have already given birth in the past), but there are gendered and social implications to "mother", and they find that a statement like "A woman should be allowed to get an abortion" gets a different emotional/visceral response than "A mother should be allowed to get an abortion". WhatamIdoing (talk) 17:15, 4 October 2025 (UTC)
- I don't think the change away from "mother" is a necessity in that case. A "mother" is the person with the egg that got fertilized, regardless of their gender identity, which isn't relevant here. As I commented at the RfD,
- We have to change some wording in body to match this sentence too. Cdr. Erwin Smith (talk) 16:45, 4 October 2025 (UTC)
- The body of the Pregnancy article already says "Women as well as intersex and transgender people who have a functioning female reproductive system are capable of pregnancy." Some1 (talk) 15:47, 4 October 2025 (UTC)
- I'm assuming that people who want to replace instances of the word woman in the Pregnancy article (and other human sex-specific articles) want to do so throughout the whole article, not just the lead sentence. (e.g. [20]) Some1 (talk) 14:31, 4 October 2025 (UTC)
- Phrases like "people who are not women can become pregnant" are only true if the only definition of "women" is "person with a feminine gender identity". To write a sentence like that is to imply that the One True™ Definition of Woman is "person with a feminine gender identity", and that all other POVs are wrong.
- Rather than a footnote preferring one POV about who is/isn't a real woman, maybe we should point at Pregnancy#Capacity. WhatamIdoing (talk) 17:12, 4 October 2025 (UTC)
- I still think just saying "pregnancy is the period during which one or more embryos or fetuses develop inside a uterus" is the best plan. It's concise, WP:DUE, verifiable, correct, and avoids stuffing up every article with undue tangents. Cremastra (talk · contribs) 13:57, 4 October 2025 (UTC)
- Not every subject that uses words like "men" and "women" needs to be turned into a primer on gender studies. The trans community makes up somewhat less than 1% of the general population, some subset of which can become pregnant, and then some subset who do. It's rare enough that we mostly don't seem to know the prevalence. In at least one Australian study, you're looking at a few dozen trans people annually, compared with more than a quarter million annual births nationally, or something like 100th of 1%.
- I don't believe we normally (or ever) go to such length in any other instance to cater high level medical articles to such an exceedingly small cohort. For readers interested in this niche we have Transgender pregnancy and related articles like Use of assisted reproductive technology by LGBTQ people, Partner-assisted reproduction, and the neglected stub at Transgender parenting. GMGtalk 15:36, 4 October 2025 (UTC)
- I'm inclined to agree with this. Cremastra (talk · contribs) 16:38, 4 October 2025 (UTC)
- If we were going to write a FAQ for Talk:Pregnancy, what's the narrowest "rule" we could agree to recommend?
- Maybe something like "Do not remove the words woman and women from this article"? That would permit trans-inclusive formulations such as "women and other people who are pregnant". WhatamIdoing (talk) 23:32, 6 October 2025 (UTC)
- So far the closest thing I see to consensus in this discussion is the "use gendered language following MEDRS sources, with an explanatory footnote at the first occurrence" idea (although specific wording hasn't had much discussion yet), as pretty much every other suggestion has arguments against and few/no supporting comments. The rule might then be "don't change that status quo". OTOH, further discussion might come up with some other result. Anomie⚔ 01:17, 7 October 2025 (UTC)
- Yes, I agree with this. Cdr. Erwin Smith (talk) 19:20, 12 October 2025 (UTC)
- So far the closest thing I see to consensus in this discussion is the "use gendered language following MEDRS sources, with an explanatory footnote at the first occurrence" idea (although specific wording hasn't had much discussion yet), as pretty much every other suggestion has arguments against and few/no supporting comments. The rule might then be "don't change that status quo". OTOH, further discussion might come up with some other result. Anomie⚔ 01:17, 7 October 2025 (UTC)
- This is an unreasonable demand that places the burden of other people's idiosyncrasies on already stressed people. No one will want to study for ten or fifteen years if they can't even do their job because they're expected to constantly bend to the demands and touchiness of overly pampered people: "No, I don't like that word," "No, I have another identity but you can't ask which one," "Here, this is the glossary you have to use with me, memorize it in three seconds." 93.146.171.12 (talk) 12:26, 12 October 2025 (UTC)
- This is VP discussion, not an opportunity for ludicrously hyperbolic rants about changes in culture. Cremastra (talk · contribs) 15:39, 12 October 2025 (UTC)
- I'm inclined to agree with this. Cremastra (talk · contribs) 16:38, 4 October 2025 (UTC)
- Wanting to erase the 99.9% of women by using dehumanizing language to "respect" the "rights" of the 0.01% who are treated as if they were a priority over everyone else is the real offense. 93.146.171.12 (talk) 12:26, 12 October 2025 (UTC)
- No-one's dehumanizing anyone. Respecting people is a good thing, even if it for some reason irks you. Pulling statistics out of your hat doesn't help your case. None of the changes suggested are dehumanizing or rude to cis women. Cremastra (talk · contribs) 15:38, 12 October 2025 (UTC)
- Re: your last sentence, I think WhatamIdoing's fourth bullet point above (beginning with
Some gender-neutral models are criticized for being dehumanizing
) touches on this a bit. Some1 (talk) 23:25, 14 October 2025 (UTC)
- Re: your last sentence, I think WhatamIdoing's fourth bullet point above (beginning with
- No-one's dehumanizing anyone. Respecting people is a good thing, even if it for some reason irks you. Pulling statistics out of your hat doesn't help your case. None of the changes suggested are dehumanizing or rude to cis women. Cremastra (talk · contribs) 15:38, 12 October 2025 (UTC)
RfC: Use more descriptive CC image license tags
[edit]![]() |
|
The current CC image license tags (e.g. Template:CC BY-SA 4.0) are quite barebone, providing little information to the reuser. This is a proposal to make them more descriptive, like the equivalents at Commons, e.g. c:Template:Cc-by-sa-4.0. 15:46, 11 October 2025 (UTC)
This would change them to the following:
(old)
![]() ![]() ![]() | This work is licensed under the Creative Commons Attribution-ShareAlike 4.0 License. |
(new)
![]() ![]() ![]() | This file is licensed under the Creative Commons Attribution-Share Alike 4.0 International license.
|
(The above are just mockups) 15:46, 11 October 2025 (UTC)
This is just a mockup (I was a bit lazy to subst all the int statements) - I plan to create templates like c:Template:Cc-by-sa-layout on enwiki, obviously with a bit of reworking to remove unnecessary i18n. I also think width: 100% could be used, since we don't need to narrow width for a short license statement, unlike text. Please reply with whether you support or oppose the change along with comments. Thanks, —Matrix ping mewhen u reply (t? - c) 20:06, 2 October 2025 (UTC)
- Weak oppose - I'd rather editors who aren't familiar click through and get the official short and long license explanations, rather than duplicating it here and possibly misleading. But that's just my opinion right now, it could change. SarekOfVulcan (talk) 20:11, 2 October 2025 (UTC)
- Out of curiousity do you oppose the approach currently being used by Commons? —Matrix ping mewhen u reply (t? - c) 20:27, 2 October 2025 (UTC)
- Eh. They didn't ask me. :) SarekOfVulcan (talk) 00:48, 3 October 2025 (UTC)
- Out of curiousity do you oppose the approach currently being used by Commons? —Matrix ping mewhen u reply (t? - c) 20:27, 2 October 2025 (UTC)
- If we have a CC image on en.wiki, it should be moved to commons, so I would not worry too much about our templates here Masem (t) 20:12, 2 October 2025 (UTC)
- @Masem: {{FoP-USOnly}}, {{Keep local}} (I actually oppose the latter, but consensus is to keep them)? —Matrix ping mewhen u reply (t? - c) 20:18, 2 October 2025 (UTC)
- Also, we have 84k files at Category:Copy to Wikimedia Commons (bot-assessed) (which is actually a reduction by quite a bit from two years ago). Whilst you are happy to help, I doubt we are clearing that in the foreseeable future. —Matrix ping mewhen u reply (t? - c) 20:19, 2 October 2025 (UTC)
- @Masem: {{FoP-USOnly}}, {{Keep local}} (I actually oppose the latter, but consensus is to keep them)? —Matrix ping mewhen u reply (t? - c) 20:18, 2 October 2025 (UTC)
- Support aligning to Commons. If we had universal cross-wiki templates, this would be a no-brainer application of them. We unfortunately don't. But this is a hugely important template at Commons, where they have presumably put a lot of thought into it, whereas the template here is rather niche (as Masem points out) and quite possibly underdeveloped/outdated. The best approach is therefore to follow whatever Commons does. For editors who oppose the design spelling out the terms more explicitly, I'd suggest taking that up on Commons as a far more impactful course of action than arguing about the local version of the template. Sdkb talk 21:22, 5 October 2025 (UTC)
- Support as proposer to align with Commons, as well as provide useful information to reusers of media. —Matrix ping mewhen u reply (t? - c) 15:46, 11 October 2025 (UTC)
- Support per Sdkb – ideal to have consistent templates cross-wiki, especially since many of its uses here are for files to be copied to Commons, and I trust Commons editors on this one. Chaotic Enby (talk · contribs) 15:28, 12 October 2025 (UTC)
- Support aligning to Commons. Graham11 (talk) 22:42, 12 October 2025 (UTC)
Change the Village Pump's colour
[edit]- 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.
- There is consensus to change the Village Pump header colour to light purple, replacing the current beige. Although some editors opposed any change on WP:DONTFIXIT grounds, the majority of participants found the current beige unattractive and supported a refresh. Among the alternatives, purple consistently received the most support, with accessibility concerns addressed by adopting a lighter hue. Several editors also expressed a preference for using colours drawn from the standard palettes at Help:Using colours, and implementation should therefore select the closest appropriate light purple from those established schemes, with technical adjustments as needed for dark mode and contrast compliance. (non-admin closure) Vanderwaalforces (talk) 10:23, 12 October 2025 (UTC)
- EDIT: --Vanderwaalforces (talk) 11:12, 12 October 2025 (UTC)
- Created § Closure? section. FaviFake (talk) 17:56, 6 October 2025 (UTC)
- Wikipedia:WikiProject Usability/Color,
- Wikipedia:Manual of Style/Accessibility/Colors § Named web colors,
- Help:Using colours § Colour generation guide,
- Wikipedia:Infobox colours § Subcategories
and many others. I suggest we pick a replacement for the current colour. The colours 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 colour choices below, which weren't being voted on.)
(More colour choices)
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
FaviFake (talk) 21:26, 20 August 2025 (UTC)
Survey (colours)
[edit]- Anything in the purple spectrum is nice. Cremastra (talk · contribs) 00:03, 21 August 2025 (UTC)
- The current color is fine. There's no need to stir up chaos by pointlessly changing it. * Pppery * it has begun... 00:09, 21 August 2025 (UTC)
- Though I love mustard, I'm not a fan of its color ... come on, this isn't stirring up chaos! ---Sluzzelin talk 00:17, 21 August 2025 (UTC)
- This topic is about changing a background color, how's it "stirring up chaos"...? FaviFake (talk) 12:04, 21 August 2025 (UTC)
- waiting patiently for someone to suggest Pantone colour names – robertsky (talk) 17:37, 22 August 2025 (UTC)
- 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)
- The current dehydrated beige-yellow-ish looks fine as-is, but D also looks great. Everything else is too light, imo. EF5 00:29, 21 August 2025 (UTC)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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. Sdkb talk 15:01, 21 August 2025 (UTC)
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)
- Support D, purple is nice. qcne (talk) 15:23, 21 August 2025 (UTC)
- Oppose WP: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)
- I think that's called consensus. Sorry, but I can't find any reliable sources for any of the options. ―Mandruss ☎ IMO. 07:22, 11 September 2025 (UTC)
- It's called a popularity contest vote. Anomie⚔ 11:51, 11 September 2025 (UTC)
- 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)
- 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)
- 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. Instead, explain why the proposed change is not better than the status quo. "What we have is fine" is approaching "I just don't like it." ―Mandruss ☎ IMO. 12:32, 11 September 2025 (UTC)
- Fine. In that case,
- 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)
- 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)
- 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)
- It's called a popularity contest vote. Anomie⚔ 11:51, 11 September 2025 (UTC)
- I think that's called consensus. Sorry, but I can't find any reliable sources for any of the options. ―Mandruss ☎ IMO. 07:22, 11 September 2025 (UTC)
- 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)
- 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)
- 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)
- 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)
- Support C as the closest to what we have now. Sapphaline (talk) 18:34, 21 August 2025 (UTC)
- Support Colours 5, 6, 7, look great imo. Granted, My favourite colours tend to be purples.... VergilSparkles (talk) 18:59, 21 August 2025 (UTC)
- Support D Purple delivers strong appeal. Ahri Boy (talk) 01:43, 22 August 2025 (UTC)
- Support Options 2 and 4 in the #Mockups section below, just based on personal preference. Some1 (talk) 01:48, 22 August 2025 (UTC)
- Support the purpley or blue colors. Strongly support any change. --📎 JackFromWisconsin (talk | contribs) 03:36, 22 August 2025 (UTC)
- Support D on this proposal. >^CreativeLibrary460 /access the library revision\ 07:41, 22 August 2025 (UTC)
- Support any change - adieu, beige. Regards, --Goldsztajn (talk) 14:00, 22 August 2025 (UTC)
- Support A, B, or C, oppose D; purple in my opinion is less visually attractive than the current hue. novov talk edits 07:44, 23 August 2025 (UTC)
- Oppose any change, as the current dull and boring colour doesn't conflict with my visual sensitivity. -- LCU ActivelyDisinterested «@» °∆t° 12:11, 23 August 2025 (UTC)
- Oppose any change. All the suggested colors are garish and distracting. --User:Khajidha (talk) (contributions) 20:38, 23 August 2025 (UTC)
- And looking at the mock ups below, make the text hard to read.--User:Khajidha (talk) (contributions) 20:40, 23 August 2025 (UTC)
- Support any change. I prefer anything that uses our standard colors in Help:Using colours#Wikipedia. WhatamIdoing (talk) 21:49, 23 August 2025 (UTC)
- Support change. Graham11 (talk) 19:24, 24 August 2025 (UTC)
- support, the current color kinda looks like teeth. drinks or coffee or prime *GET OUT* 04:48, 30 August 2025 (UTC)
- We get it, you love coffee! ꧁Zanahary꧂ 05:17, 30 August 2025 (UTC)
- i use dark mode so the background color is black, the outline is still teeth color tho drinks or coffee or prime *GET OUT* 07:22, 2 September 2025 (UTC)
- Support a change, especially to light green, light blue, or light purple. Toadspike [Talk] 06:17, 30 August 2025 (UTC)
- Option A but using background:
var(--background-color-success-subtle)
and border:var(--border-color-success)
. i.e. use Wikimedia's new design system Codex color palette. waddie96 ★ (talk) 17:56, 31 August 2025 (UTC)- 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)
- 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)
- Yeah apologies that's why you define them like this:
- 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)
- The mockups don't look very nice in dark mode... dbeef [talk] 03:18, 6 September 2025 (UTC)
- On my screen, A, B, and F look like the winners.—S Marshall T/C 15:43, 7 September 2025 (UTC)
- Option A seems okay to me. James500 (talk) 06:00, 10 September 2025 (UTC)
- 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)
- 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.
Option | Light mode (black text) |
Dark mode (white text) |
---|---|---|
Current | 17.66 | 18.35 |
A | 17.40 | 17.63 |
B | 15.46 | 15.91 |
C | 17.89 | 18.44 |
D | 14.18 | 14.12 |
F | 16.20 | 16.80 |
―Mandruss ☎ IMO. 09:47, 11 September 2025 (UTC)
- 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)- Fraid I don't understand that. Are you saying any change would introduce a problem that doesn't already exist? ―Mandruss ☎ IMO. 13:00, 12 September 2025 (UTC)
- 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)
- There shouldn't be a problem if just the colors are switched in the existing {{Start tab}} invocation. You said
- Fraid I don't understand that. Are you saying any change would introduce a problem that doesn't already exist? ―Mandruss ☎ IMO. 13:00, 12 September 2025 (UTC)
- 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.
Option | Light mode (black text) |
Dark mode (white text) |
---|---|---|
Current | #000:#F2ECCE = 17.66:1 | #FFF:#1A1400 = 18.35:1 |
A | #000:#F5FFFA = 20.56:1 | #FFF:#000400 = 20.64:1 |
B | #000:#F5FAFF = 20.00:1 | #FFF:#01060A = 20.35:1 |
C | #000:#FAF6ED = 19.46:1 | #FFF:#0C0800 = 19.99:1 |
D | #000:#FAF5FF = 19.56:1 | #FFF:#0B060F = 20.05:1 |
F | #000:#F1F5FC = 19.20:1 | #FFF:#060A11 = 19.82:1 |
―Mandruss ☎ IMO. 16:59, 12 September 2025 (UTC)
- 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)
- 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)
- See Wikipedia:Talk page templates/vote. jp×g🗯️ 19:26, 14 September 2025 (UTC)
- The colors used at the Village pump are not the same as ClockworkSoul's Coffee Roll. For example, Coffee Roll uses #f8eaba for the background and Template:Village pump page header uses #f2ecce . WhatamIdoing (talk) 02:03, 6 October 2025 (UTC)
- See Wikipedia:Talk page templates/vote. jp×g🗯️ 19:26, 14 September 2025 (UTC)
- Option This colour is ugly :( or Option C. But in all fairness I don't really care. This is exactly WP:COLORWAR. We probably should have law of triviality (at least in non-article space) as a contentious topic because we keep on getting into heated debates over very minor details. Aasim (話す) 05:43, 20 September 2025 (UTC)
- Triviality is a matter of editor opinion, perspective, and standards. At least 22 editors currently think a color change is in order, and it's not for you or anyone else to say what editors should care about. If you shut down a discussion because it violates your law of triviality, how can you know how many editors would disagree that it's trivial? That's essentially a supervote among a handful of editors before the discussion even gets going, and we don't do that. Good luck with your law of triviality. ―Mandruss ☎ IMO. 09:11, 20 September 2025 (UTC)
- Like I said I don't really care. We shouldn't get wrapped too much on colors unless if the current colors are illegible or inaccessible. Aasim (話す) 23:15, 20 September 2025 (UTC)
- LOL. You're doing it again. Nobody is forced to "get wrapped on" anything, including you. I bypass dozens of uninteresting (to me) threads a day, with little effort. ―Mandruss ☎ IMO. 23:41, 20 September 2025 (UTC)
- It is my opinion that this is a trivial change and I don't care. Others are free to have different opinions as to the triviality of such a change. Aasim (話す) 22:33, 22 September 2025 (UTC)
- You proposed a law of triviality, which sounded a lot like caring to me. And you're saying a lot for somebody who doesn't care. Climb to the top of the bell tower and scream I DON'T CARE!!! so the whole town can hear you. But enough spent on such nonsense. ―Mandruss ☎ IMO. 23:18, 22 September 2025 (UTC)
- It is my opinion that this is a trivial change and I don't care. Others are free to have different opinions as to the triviality of such a change. Aasim (話す) 22:33, 22 September 2025 (UTC)
- LOL. You're doing it again. Nobody is forced to "get wrapped on" anything, including you. I bypass dozens of uninteresting (to me) threads a day, with little effort. ―Mandruss ☎ IMO. 23:41, 20 September 2025 (UTC)
- Like I said I don't really care. We shouldn't get wrapped too much on colors unless if the current colors are illegible or inaccessible. Aasim (話す) 23:15, 20 September 2025 (UTC)
- Triviality is a matter of editor opinion, perspective, and standards. At least 22 editors currently think a color change is in order, and it's not for you or anyone else to say what editors should care about. If you shut down a discussion because it violates your law of triviality, how can you know how many editors would disagree that it's trivial? That's essentially a supervote among a handful of editors before the discussion even gets going, and we don't do that. Good luck with your law of triviality. ―Mandruss ☎ IMO. 09:11, 20 September 2025 (UTC)
B or F but these arent dark mode compatible so difficult to be sure. Metallurgist (talk) 02:14, 8 October 2025 (UTC)
- Oppose making any change per WP:DONTFIXIT. --Gimubrc (talk) 19:00, 9 October 2025 (UTC)
- There is a problem, though; it's just a small one. Cremastra (talk · contribs) 21:25, 9 October 2025 (UTC)
- And if we want to quote WP:DONTFIXIT,
if something is slightly broken in a way that you care about, and fixing it improves the encyclopedia a little, then feel free to fix
. Some of the issues are an ugly colour and a low contrast ratio. FaviFake (talk) 15:19, 10 October 2025 (UTC)
- And if we want to quote WP:DONTFIXIT,
- There is a problem, though; it's just a small one. Cremastra (talk · contribs) 21:25, 9 October 2025 (UTC)
Discussion (colours)
[edit]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 |
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)
- 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.)
- If anyone wants to develop actual mockups, please do! FaviFake (talk) 12:30, 21 August 2025 (UTC)
Collapsing nonconstructive discussion. Mz7 (talk) 22:44, 21 August 2025 (UTC) |
---|
The following discussion has been closed. Please do not modify it. |
|
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)
The Village pump has six tabs. Use all of the above six choices (A-F) – a different colour for each tab — GhostInTheMachine talk to me 08:41, 11 September 2025 (UTC)
- 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)
- I have no problems with this idea either. But I think it would get some serious opposition for WP: DONTFIXIT.
- EDIT : Nevermind, I totally forgot about the colourblind. If we plan to go ahead with this idea, we should consider avoiding Deep Blue and Deep Purple as they might blend-in with the links. Might as well reject these two and go ahead with lighter/deeper tone/mixture of the rest of the colours. Cdr. Erwin Smith (talk) 18:45, 16 September 2025 (UTC)
Mockups
[edit]Copy-pasted from § Discussion (colours) for comparison:
Current color | Other tab | Other tab | Other tab | Other tab | Other tab |
--FaviFake (talk) 16:11, 21 August 2025 (UTC)
Here are some mockups based on the standards at Help:Using colours#Colour generation guide:
Option 1 | Other tab | Other tab | Other tab | Other tab | Other tab |
Option 2 | Other tab | Other tab | Other tab | Other tab | Other tab |
Option 3 | Other tab | Other tab | Other tab | Other tab | Other tab |
Option 4 | Other tab | Other tab | Other tab | Other tab | Other tab |
Option 5 | Other tab | Other tab | Other tab | Other tab | Other tab |
Option 6 | Other tab | Other tab | Other tab | Other tab | Other tab |
Option 7 | Other tab | Other tab | Other tab | Other tab | Other tab |
꧁Zanahary꧂ 14:31, 21 August 2025 (UTC)
- Thanks, these look great! I added the current color above you message to show the difference. FaviFake (talk) 16:11, 21 August 2025 (UTC)
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 |
150° row | Other tab | Other tab | Other tab | Other tab | Other tab |
Option B | Other tab | Other tab | Other tab | Other tab | Other tab |
Option C | Other tab | Other tab | Other tab | Other tab | Other tab |
Option D | Other tab | Other tab | Other tab | Other tab | Other tab |
Option F | Other tab | Other tab | Other tab | Other tab | Other tab |
Chaotic Enby (talk · contribs) 12:47, 22 August 2025 (UTC)
- 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)
- To clarify, the yellow of option C isn't the same as the current yellow, which is more dull and a bit darker. Chaotic Enby (talk · contribs) 18:55, 6 September 2025 (UTC)
- Well still, light-green is my choice ! Cdr. Erwin Smith (talk) 20:19, 6 September 2025 (UTC)
- @Cdr. Erwin Smith, do you personally have trouble seeing the links in the purple and/or blue examples? WhatamIdoing (talk) 02:08, 6 October 2025 (UTC)
- On a scale of 1-10, I will say the difficulty level's around 5.5. By this, I mean I might miss it if I'm reading the comment in a hurry. Cdr. Erwin Smith (talk) 07:17, 6 October 2025 (UTC)
- To clarify, the yellow of option C isn't the same as the current yellow, which is more dull and a bit darker. Chaotic Enby (talk · contribs) 18:55, 6 September 2025 (UTC)
Closure?
[edit]As the creator, I have a suggestion for how to satisfy both parties of this discussion. While it leaned toward a change to purple, (or blue? or green? I didn't count), a lot of the opposers specified that they preferred the current colour because the contrast between the text and the background wasn't enough, or the new colours were too dark.
This may be worked around by using the lighter hue of the proposed purple background for the text in the header—since it's what people have to actually read—and the darker purple for the "tab switchers" (the "Other tab"s in the mockups above). That will both: make the text even more readable ("contrasty") than it is currently, and satisfy many opposers' concerns. (I also personally think it makes more sense for the actual tab to highlighed, as is most often the case, and not the tabs that aren't selected.)
It also looks nicer! For example, the Option 5 would become:
Current option 5 | Other tab | Other tab | Other tab | Other tab | Other tab |
More readable :) | Other tab | Other tab | Other tab | Other tab | Other tab |
Thoughts? I hope this can satisfy the opposition? FaviFake (talk) 17:54, 6 October 2025 (UTC)
- FaviFake, I've added a pair of links to each example, as an editor raised concerns about the link colors. I think this is a good solution. In looking through the comments above, I believe that the purple was the most popular color. (I'd never have predicted this, but that's why we ask people!) WhatamIdoing (talk) 18:44, 6 October 2025 (UTC)
- Thanks! I'm not entirely surprised, purple is a very elegant colour. But honestly, I'm more excited about not having to see that ugly beige anymore :) FaviFake (talk) 18:55, 6 October 2025 (UTC)
#e6e6ff
doesn't meet WCAG AA contrast requirements with links color used in Vector-2022, so I suggest#eaeaff
with#eaeaf7
as an accent color:
More readable :) | Other tab | Other tab | Other tab | Other tab | Other tab |
- Sapphaline (talk) 20:56, 6 October 2025 (UTC)
- I've taken the liberty of correcting the text in the examples in this section where it was copy-pasted and no longer reflected the changes people had made. Anomie⚔ 21:28, 6 October 2025 (UTC)
- Thanks. Where did you get that colour from? FaviFake (talk) 15:17, 7 October 2025 (UTC)
- I used this tool with a bit of manual hex value editing. Sapphaline (talk) 20:50, 7 October 2025 (UTC)
- I'm at a bit of a loss here.
- If lighter tones is what people wanted for better contrast, why is only Light Purple being chosen? I, personally preferred Light Green because not only was it different from the current colour, but also provided the best contrast against the link colours - Blue/Purple.
- Since the discussion thus far was a mixture of input-based improvement along with voting, I think a clear and final !Vote should be conducted based on the lighter tones of each colour, and thus reach a final consensus. We can @ping every user who participated in this discussion so far to participate.Cdr. Erwin Smith (talk) 11:44, 8 October 2025 (UTC)
Most people voted because they wanted a better-looking colour, not a better contrast. Afaik, nobody who voted purple said they preferred the contrast. I do not understand nor agree with the need to discard the previous votes, which sounds like what you're proposing, and restart this discussion. The survey was alreadyIf lighter tones is what people wanted
based on the lighter tones of each colour
. FaviFake (talk) 12:14, 8 October 2025 (UTC)- I thought this was the first time lighter hues were being proposed.
This may be worked around by using the lighter hue of the proposed purple background
- Was it applied to every colour? - As far as I can see, most people voted even before seeing how the headers with links would actually look like. So I think we should do a proper pole, ofcourse, if the majority of the few remaining participants in this conversation agree to do so. Cdr. Erwin Smith (talk) 13:22, 8 October 2025 (UTC)
I misunderstood your comment. imo that was the first time someone suggested switching them. They had been posted ealier and used as tab background.I thought this was the first time lighter hues were being proposed.
Doesn't seem to be the case. By my count, only 5 people voted before the § Mockups we posted. I don't personally think we should spend more time on this relatively trivial change. We already have a "winner" colour and this switch potentially will satisfy the remaining opposition. FaviFake (talk) 13:33, 8 October 2025 (UTC)most people voted even before seeing how the headers with links would actually look like
- Whichever color is chosen, one can attempt to add dark mode transparency by computing what alpha values lead to the desired hue (a bit of algebra), i.e. if , it should be quite easy to figure out the desired alpha value necessary so that colors appear consistent in light and dark mode.
- This does not work obviously if the desired color is darker than the color in its pure hue, but I have used it with inline styles to save a huge ton of time trying to compute separate light and dark mode colors. Aasim (話す) 14:56, 8 October 2025 (UTC)
- Btw, I'm not telling to discard previous votes, but to include everyone. Cdr. Erwin Smith (talk) 16:20, 8 October 2025 (UTC)
- It's the same thing, though, isn't it? We "include everyone" by discarding the previous votes. Perhaps you are even hoping that the result will be your preferred color instead of purple. WhatamIdoing (talk) 18:51, 9 October 2025 (UTC)
- I have no problems either way. However, I do think this issue is getting dragged on longer than required.
- @Anomie, @Aasim, @Utfor, @Sapphaline, @FaviFake, @WhatamIdoing please state whether we should go ahead with the proposed Light Purple, or conduct a Final !Vote between the lighter hues of every deep colour among all the editors involved in this discussion.
- Whatever the final decision, please keep @Aasim's issue in mind. Cdr. Erwin Smith (talk) 12:30, 10 October 2025 (UTC)
- Personally I still think WP:NOTBROKEN, and I find the purples suggested to be getting confusingly similar to the color of {{archive top}}. But enough people above want some sort of change and not enough people agree with WP:NOTBROKEN, so 🤷. Anomie⚔ 14:02, 10 October 2025 (UTC)
- It is preferable that you pick a side. Cdr. Erwin Smith (talk) 14:37, 10 October 2025 (UTC)
- No, it isn't preferable. I'd rather people be WP:PRAGMATIC. Cremastra (talk · contribs) 15:04, 10 October 2025 (UTC)
- I said that because we've went much ahead in this discussion. Some other colour is going to get chosen, because a huge majority is in favour of a change. So while he can very well give a NOTA, it will be fruitless.
- Btw, I'm taking your !vote as Purple as you've stated already. Cdr. Erwin Smith (talk) 18:43, 10 October 2025 (UTC)
- No, it isn't preferable. I'd rather people be WP:PRAGMATIC. Cremastra (talk · contribs) 15:04, 10 October 2025 (UTC)
- It is preferable that you pick a side. Cdr. Erwin Smith (talk) 14:37, 10 October 2025 (UTC)
- I'm not sure why I have been pinged. I've stated my intention many, many, many, many times and I still stand by everything I said. FaviFake (talk) 15:16, 10 October 2025 (UTC)
- Noted. It's just a formal process. Cdr. Erwin Smith (talk) 20:25, 10 October 2025 (UTC)
- I think we should go ahead with "Light Purple", as "Purple" was the most popular and the light version reduces some of the color blindness and contrast concerns that were raised. I think that if you think this issue is getting dragged on longer than required, then we should not drag it on any longer by having a vote.
- I also think that everyone in this conversation should be prepared for a couple of people to show up and say that since he didn't participate in this discussion, that there was something procedurally wrong with it. After all, everyone knows that 116 comments from 41 editors (the biggest discussion on this page) is not nearly enough to make a fairly unimportant decision about the color of a box on a couple of backend pages – unless those 41 editors happen to include "me". But most people get used to changes of this type within a handful of days, so I think we should avoid reacting too soon or too strongly to any complaints. WhatamIdoing (talk) 15:46, 10 October 2025 (UTC)
- Fully agree with every word of your comment; especially the second paragraph! FaviFake (talk) 15:52, 10 October 2025 (UTC)
- Noted. By that sentence, I meant we are wasting time by wandering around, instead of taking swift decisions to conclude the topic. Cdr. Erwin Smith (talk) 20:36, 10 October 2025 (UTC)
- WP:NOTAVOTE. I am still confused how changing the color of the village pump header improves the encyclopedia. IMHO and in the opinion of the authors of WP:COLORWAR (from what I read), most any color does the job. We already have set color palettes for ANB and the Village Pump and I really do think changing the color may create some confusion as to whether they are on the right page for a task. But even then, as I have stated, I don't see a good reason to obsess over the color of the village pump headers. Maybe if there are valid accessibility concerns sure, but I just checked and there is more than enough contrast (at least 17.66 using the dev tools) and the only accessibility problem is probably the color of the links (which can be fixed by using a lighter shade of the same hue). Otherwise there isn't good justification to change the hue at all.
- Hope this clarifies my position. Aasim (話す) 16:40, 10 October 2025 (UTC)
- Personally I still think WP:NOTBROKEN, and I find the purples suggested to be getting confusingly similar to the color of {{archive top}}. But enough people above want some sort of change and not enough people agree with WP:NOTBROKEN, so 🤷. Anomie⚔ 14:02, 10 October 2025 (UTC)
- It's the same thing, though, isn't it? We "include everyone" by discarding the previous votes. Perhaps you are even hoping that the result will be your preferred color instead of purple. WhatamIdoing (talk) 18:51, 9 October 2025 (UTC)
- I thought this was the first time lighter hues were being proposed.
- Well some colour is going to get chosen, since a vast majority is in favour of a change. It's also not a war but the ending-phase of a civilized process. Nobody is losing their temper in a heated debate.
- From your highlighted previous reply, it seems you prefer both the current colour and a lighter-hue of the same.
- However from this reply, it seems you prefer the current colour with some mods. So should I take your !Vote to 'Neutral'/'Final Vote bw Lighter Hues' or both?
- [Neutral = Existing Colour]
Collapsing bickering. qcne (talk) 20:46, 11 October 2025 (UTC) |
---|
The following discussion has been closed. Please do not modify it. |
|
- If people voted for the header's background to be light purple, then it should be light purple, or more specifically
#eaeaff
, for the reasons I explained above. Sapphaline (talk) 19:44, 10 October 2025 (UTC)
- If people voted for the header's background to be light purple, then it should be light purple, or more specifically
Off-topic; the closer will decide. — Preceding unsigned comment added by Cremastra (talk • contribs) 21:36, 10 October 2025 (UTC)
|
---|
|
- @Mandruss I didn't ask you because it appeared that you lost interest and left. However since you're here, do you have a preference between the options, or would you rather stay neutral? Cdr. Erwin Smith (talk) 10:38, 11 October 2025 (UTC)
- Do I need to !vote again after this? From what list? ADD and other things on my plate have prevented me from following the more recent developments. ―Mandruss ☎ IMO. 10:48, 11 October 2025 (UTC)
- Light Purple or a comprehensive vote between lighter-hues of the deep colours proposed here and here.
- As for your highlighted previous reply, I had already seen it. But since a person had recently changed her previous preference, I thought it would be prudent to ask once more. Cdr. Erwin Smith (talk) 11:19, 11 October 2025 (UTC)
- I'm good with my !vote if it's still a valid !vote. When there are too many options to reach a majority (as contrasted to a mere plurality), a two-round !voting process such as here has proven useful. This assumes there is no objection to closing with the numbers when there is no policy in play. It's not the same as pure democratic voting, since an argument is expected with each !vote. It's a little time-consuming, it requires facilitation by a committed editor (me?), but it has worked several times at that article (for things more important than the color of village pump headers, including the first two sentences at one of the most-viewed articles in the encyclopedia). It has never failed to yield a majority consensus. ―Mandruss ☎ IMO. 12:09, 11 October 2025 (UTC)
- If I'm getting it right, the ongoing poll is going to decide whether or not we go for a comprehensive voting, the process and framework of which can very much be decided by a committed editor.
- As per this reply and your preferred colour highlighted previously, your desire for a !Final Vote has been noted. Cdr. Erwin Smith (talk) 13:11, 11 October 2025 (UTC)
Oh well, I thought you were of the opinion that[T]he ongoing poll is going to decide whether or not we go for a comprehensive voting, the process and framework of which can very much be decided by a committed editor
this issue is getting dragged on longer than required
. Good luck organising two additional polls to change the colour of a banner. FaviFake (talk) 13:21, 11 October 2025 (UTC)- I also stated
I have no problems either way
, which includes both the Light Purple and a Final !Vote. - As for that sentence, I've already stated what I meant by that. Cdr. Erwin Smith (talk) 15:20, 11 October 2025 (UTC)
- I also stated
- If you're getting it right, it sounds unnecessarily complex to me. I'd just go straight to Round One with all options that are still viable. Seven to ten days and then Round Two for seven to ten more days. It's more work for the "facilitator" than the !voting editors. As for dragging on longer than required, there is no deadline and ignoring some TOC entries is not an unreasonable burden. I don't run the place, for better or worse. ―Mandruss ☎ IMO. 13:22, 11 October 2025 (UTC)
- It's a little misleading to claim your runoff voting method
It has never failed to yield a majority consensus
IMO, if a NOTA or write-in vote isn't allowed. For this particular issue, if we're going to have an actual vote, I'd recommend either approval voting (note the "Support/Neutral/Oppose" method we've often used historically is basically approval-with-abstention) or a ranked voting system of some sort (one that's not as flawed as instant-runoff voting, please). Anomie⚔ 13:51, 11 October 2025 (UTC)- Good. Now begins the prerequisite spinoff discussion about process. I'll probably lose interest at some point. In my opinion, you are intellectualizing something that doesn't need to be so intellectual. Perfect is the enemy of good. ―Mandruss ☎ IMO. 13:58, 11 October 2025 (UTC)
- So 'Neutral' is your final call, or do you want a Final !Vote?
- Just for clarification, the closer can reject the results of this poll and go for any one of the suggested voting processes if he sees fit. Cdr. Erwin Smith (talk) 15:27, 11 October 2025 (UTC)
- I'm good with my !vote if it's still a valid !vote. When there are too many options to reach a majority (as contrasted to a mere plurality), a two-round !voting process such as here has proven useful. This assumes there is no objection to closing with the numbers when there is no policy in play. It's not the same as pure democratic voting, since an argument is expected with each !vote. It's a little time-consuming, it requires facilitation by a committed editor (me?), but it has worked several times at that article (for things more important than the color of village pump headers, including the first two sentences at one of the most-viewed articles in the encyclopedia). It has never failed to yield a majority consensus. ―Mandruss ☎ IMO. 12:09, 11 October 2025 (UTC)
- Do I need to !vote again after this? From what list? ADD and other things on my plate have prevented me from following the more recent developments. ―Mandruss ☎ IMO. 10:48, 11 October 2025 (UTC)
- @Mandruss I didn't ask you because it appeared that you lost interest and left. However since you're here, do you have a preference between the options, or would you rather stay neutral? Cdr. Erwin Smith (talk) 10:38, 11 October 2025 (UTC)
- Tally of Votes
- Support Light Purple = 4
- Support Final !Vote = 2
- No Change/Current Colour with Mods = 1
- [One person didn't participate, and another didn't give any particular opinion]
- Requesting closer to summarise and determine the consensus. Cdr. Erwin Smith (talk) 19:47, 11 October 2025 (UTC)
- Support option class="" Please apply classes to the header template. In this way, every registered user can (perhaps after reading an appropriate tutorial) pick the colors they want and nobody will be dissatisfied if they have an account. Utfor (talk) 19:23, 8 October 2025 (UTC)
- Like at Burger King! Extra pickles and hold the mayo.But why not. En-wiki does love user customization and making everybody happy, even at the cost in simplicity. Similar to Bill Clinton. That's why we have four equally usable shortcuts to the same thing, thereby quadrupling the learning curve for that thing. ―Mandruss ☎ IMO. 18:44, 11 October 2025 (UTC)
- I would not be opposed to any change that allows users to customise their experience. :) Aasim (話す) 19:07, 11 October 2025 (UTC)
- New campaign slogan: Wikipedia Your Way™: Objective 2030. ―Mandruss ☎ IMO. 19:13, 11 October 2025 (UTC)
- You rule! Aasim (話す) 19:21, 11 October 2025 (UTC)
- If only! My campaign slogan: Mandruss for King of Wikipedia. Tough on crime. Easy on language. Vote now and often! Prime Minister of Wikipedia will do. ―Mandruss ☎ IMO. 20:21, 11 October 2025 (UTC)
- You rule! Aasim (話す) 19:21, 11 October 2025 (UTC)
- New campaign slogan: Wikipedia Your Way™: Objective 2030. ―Mandruss ☎ IMO. 19:13, 11 October 2025 (UTC)
- I would not be opposed to any change that allows users to customise their experience. :) Aasim (話す) 19:07, 11 October 2025 (UTC)
- Like at Burger King! Extra pickles and hold the mayo.But why not. En-wiki does love user customization and making everybody happy, even at the cost in simplicity. Similar to Bill Clinton. That's why we have four equally usable shortcuts to the same thing, thereby quadrupling the learning curve for that thing. ―Mandruss ☎ IMO. 18:44, 11 October 2025 (UTC)
This is an accessibility nightmare
[edit]Why the heck did we pick this shade of purple out of all colors, the links on the page on Vector 22 explicitly fail both WCAG AA and WCAG AAA ( see [21]) making it hard to parse through with low vision or sunlight. Can we please have the brown color back for now and pick a different one where the links are readable and are within the WCAG AA standard of accessibility? (cc @Vanderwaalforces as the closer and @Chaotic Enby who I was just discussing this with) -- Sohom (talk) 15:48, 12 October 2025 (UTC)
Comment: The previous colours also explicitly fail both WCAG AA and WCAG AAA (see [22]). Restoring the brown colour won't improve the accessibility in any significant way. FaviFake (talk) 16:00, 12 October 2025 (UTC)
- Unlike what the documentation says, the previous color was actually #F2ECCE, which passes WCAG AA in this specific case. Chaotic Enby (talk · contribs) 16:04, 12 October 2025 (UTC)
- Thanks, you're right. I've fixed the documentation FaviFake (talk) 16:13, 12 October 2025 (UTC)
- Unlike what the documentation says, the previous color was actually #F2ECCE, which passes WCAG AA in this specific case. Chaotic Enby (talk · contribs) 16:04, 12 October 2025 (UTC)
- While I definitely won't hold it against the closer for trying their best to tame this sprawling discussion, I am disappointed to see that the "More readable" mockups did not test blue and purple link colors like the previous ones, which might have given the wrong impression about how readable/accessible they were. Chaotic Enby (talk · contribs) 15:55, 12 October 2025 (UTC)
- Now that I think about it, there are a few interwiki links (like the Phabricator one) in the headers, which are even lighter in color, so that is also something to keep in mind when testing for WCAG AA. Chaotic Enby (talk · contribs) 15:58, 12 October 2025 (UTC)
- The purple color (visited link) (see [23]) also fails WCAG AA in the current design :/ Sohom (talk) 16:09, 12 October 2025 (UTC)
What do you mean? In all three of the "more readable" suggestions there were blue and, if people clicked on them, purple links. FaviFake (talk) 16:07, 12 October 2025 (UTC)the "More readable" mockups did not test blue and purple link colors
- On the earlier mockups, there was a series of link-colored text (including in the tabs). The issue with raw links is that Vector 2022 uses a different link color palette than the other skins, meaning that editors couldn't have a full picture of how the colored links would display on every skin. Chaotic Enby (talk · contribs) 16:10, 12 October 2025 (UTC)
- Thanks. I did not notice the tabs were not coloured in the later mockups. FaviFake (talk) 16:15, 12 October 2025 (UTC)
- On the earlier mockups, there was a series of link-colored text (including in the tabs). The issue with raw links is that Vector 2022 uses a different link color palette than the other skins, meaning that editors couldn't have a full picture of how the colored links would display on every skin. Chaotic Enby (talk · contribs) 16:10, 12 October 2025 (UTC)
- Now that I think about it, there are a few interwiki links (like the Phabricator one) in the headers, which are even lighter in color, so that is also something to keep in mind when testing for WCAG AA. Chaotic Enby (talk · contribs) 15:58, 12 October 2025 (UTC)
- I don't need to fully understand what you guys are talking about, but it's clear there are viable, good faith concerns about this closure. So stop farting around and get started with Wikipedia:Closing discussions#Challenging other closures. ―Mandruss ☎ IMO. 16:28, 12 October 2025 (UTC)
- Okay Sohom, although I need to understand if it’s my closure that is a problem or the accessibility issues stem from it, or the issue is independent of my close. Did I incorrectly assess consensus? Vanderwaalforces (talk) 16:38, 12 October 2025 (UTC)
- @Vanderwaalforces, I don't think your reading of consensus is necessarily wrong, the community did vote for purple. The issue is that mock-ups did not test/represent all possible link colors and the folks voting did not consider the accessibility of link colors in Vector22, leading a majority to vote for a color that causes links in the header to fail MOS:CONTRAST (which requires compatibility with WCAG AA at a minimum) on Vector22. Sohom (talk) 16:53, 12 October 2025 (UTC)
- It's almost like these things need a manager. Not necessarily uninvolved. Off topic? I can't help it. I see a problem and the first question to myself is how similar problems could be avoided in the future. I'm barely interested in the immediate problem and tend to leave that to others. ―Mandruss ☎ IMO. 17:07, 12 October 2025 (UTC)
- @Vanderwaalforces, I don't think your reading of consensus is necessarily wrong, the community did vote for purple. The issue is that mock-ups did not test/represent all possible link colors and the folks voting did not consider the accessibility of link colors in Vector22, leading a majority to vote for a color that causes links in the header to fail MOS:CONTRAST (which requires compatibility with WCAG AA at a minimum) on Vector22. Sohom (talk) 16:53, 12 October 2025 (UTC)
- Beige was alright, but I guess I'll get used to purple. GoodDay (talk) 16:33, 12 October 2025 (UTC)
Comment: There is one more column at Help:Using colours § Colour generation guide that is lighter. Would the problem be solved if we used the "main background" column for the text background and the "2nd header, accent colour" for the tab backgrounds? (Instead of the ones we're currently using, i.e., the "2nd header, accent colour" for text background and the "main border, header background" for the tabs)It seems a bit too light however. FaviFake (talk) 16:46, 12 October 2025 (UTC)
- I do wish people had chosen a color that wasn't very close to the one used by {{archive top}}. "The whole VP is archived now? No, wait..." Anomie⚔ 17:26, 12 October 2025 (UTC)
- Agree - Wikipedia:Solutions looking for a problem. Moxy🍁 17:34, 12 October 2025 (UTC)
- I don't like it either, because now it's much harder to decipher the clicked purple links from before.
- Ironically, Purple is my favourite colour in real life. But I just couldn't support it here.
- Now the only way it can get changed, is if someone motivated enough challenges the closure (count me out from that list). Cdr. Erwin Smith (talk) 19:05, 12 October 2025 (UTC)
- If you challenge the closure, you're saying that the closer misjudged the consensus. The closer in this case 100% did not misjudge the consensus. FaviFake (talk) 19:32, 12 October 2025 (UTC)
- Try using words like 'someone' instead of 'you'. Cdr. Erwin Smith (talk) 07:14, 13 October 2025 (UTC)
- Sure. I hope you understood i wasn't talking to you spcifically. FaviFake (talk) 15:20, 13 October 2025 (UTC)
- It's okay, I AGFed on you much before : ) Cdr. Erwin Smith (talk) 19:48, 13 October 2025 (UTC)
- Sure. I hope you understood i wasn't talking to you spcifically. FaviFake (talk) 15:20, 13 October 2025 (UTC)
- Try using words like 'someone' instead of 'you'. Cdr. Erwin Smith (talk) 07:14, 13 October 2025 (UTC)
- If you challenge the closure, you're saying that the closer misjudged the consensus. The closer in this case 100% did not misjudge the consensus. FaviFake (talk) 19:32, 12 October 2025 (UTC)
|
- I changed on tab color to
#EAEAFF
and off-tab color to#EAEAF7
. Both have enough contrast for links color used in Vector-2022 and Timeless to comply with WCAG AA. sapphaline (talk) 17:27, 12 October 2025 (UTC)- Thanks, that's the kind of slight improvement we need! Chaotic Enby (talk · contribs) 17:30, 12 October 2025 (UTC)
- Sure, that works! (tho Anomie's point is probably something to consider -- tho I think it is a less pressing than the immediate accessibility problem) Sohom (talk) 17:37, 12 October 2025 (UTC)
To my eyes they're very different.I guess it'll take people a little while to get used to it.I had viewed a different template than the one discussed here. FaviFake (talk) 17:39, 12 October 2025 (UTC)- @FaviFake The archive template in V22 is #EDEAFF, the color chosen is #EAEAFF, the difference between the two almost imperceptible to my eyes. Sohom (talk) 20:15, 12 October 2025 (UTC)
- I agree. It looks outright blue to me, whereas the consensus was for purple. Cremastra (talk · contribs) 20:17, 12 October 2025 (UTC)
- Apparently one of these is purple, but I sure can't tell the difference. This is pale purple. Cremastra (talk · contribs) 20:20, 12 October 2025 (UTC)
- Yeah I think I viewed a different discussion template. To my eyes the 1st and 2nd above are purple/blue, but the third is just light pink. They are indeed incredibly similar, but it isn't really a bad thing. After all, the consensus was to use
colours drawn from the standard palettes [and the] implementation should therefore select the closest appropriate light purple from those established schemes
, and the {{Archive top}} colour is definitely standard. The {{Archive top}} seems to be the closest to Option D and Option 5, which were the colours that actually got the most !votes. If anything else, I think the header should either use the colour of {{Archive top}} or at least keep its current colour. But since they look almost identical, I'd prefer the standard,established
colour of {{Archive top}} be used. FaviFake (talk) 20:35, 12 October 2025 (UTC)- The problem is whenever I see the color, my (and I assume a lot of people on enwiki) simply go "okay, this is done. gonna skip" -- which isn't ideal for the village pump. Sohom (talk) 20:39, 12 October 2025 (UTC)
- I do think the novelty will wear off eventually. How many closed discussions have tabs? FaviFake (talk) 21:00, 12 October 2025 (UTC)
- My main concern is that the current colour is blue, rather than purple. Cremastra (talk · contribs) 21:02, 12 October 2025 (UTC)
- I do think the novelty will wear off eventually. How many closed discussions have tabs? FaviFake (talk) 21:00, 12 October 2025 (UTC)
- The problem is whenever I see the color, my (and I assume a lot of people on enwiki) simply go "okay, this is done. gonna skip" -- which isn't ideal for the village pump. Sohom (talk) 20:39, 12 October 2025 (UTC)
- I agree. It looks outright blue to me, whereas the consensus was for purple. Cremastra (talk · contribs) 20:17, 12 October 2025 (UTC)
- @FaviFake The archive template in V22 is #EDEAFF, the color chosen is #EAEAFF, the difference between the two almost imperceptible to my eyes. Sohom (talk) 20:15, 12 October 2025 (UTC)
- You or someone else may want to also update {{Village pump/styles.css}} so that {{Village pump}} and {{Village pump page header}} look the same. These are the colours that were changed which should be updated. FaviFake (talk) 17:44, 12 October 2025 (UTC)
- Done. sapphaline (talk) 17:45, 12 October 2025 (UTC)
- Thanks! I also updated the documentations once again. FaviFake (talk) 17:56, 12 October 2025 (UTC)
- Done. sapphaline (talk) 17:45, 12 October 2025 (UTC)
- It now looks more like the wiki blue, which Im okay with, just noting 212.70.110.25 (talk) 18:36, 12 October 2025 (UTC)
- The new color seems to be similar to the Template:Archive top color now. I don't like it, but I'll get used to it. Some1 (talk) 18:34, 12 October 2025 (UTC)
- 'cept we had consensus for purple, when the colour now used is quite unabashadly blue. Cremastra (talk · contribs) 19:17, 12 October 2025 (UTC)
- It's been a couple of different colors during the last hour or two, as people sort out what works. The version I see right now is lavender. One of the ones you put in (#E6D1FF) was Thistle (color), which is on the pinkish side of purple. There was also a version with lightsteelblue. But I think they've got it settled. WhatamIdoing (talk) 19:53, 12 October 2025 (UTC)
- 'cept we had consensus for purple, when the colour now used is quite unabashadly blue. Cremastra (talk · contribs) 19:17, 12 October 2025 (UTC)
As a side note, here's a stylesheet to make it brown again:
.mw-parser-output .vph > table td:nth-of-type(2n) {
border:2px solid #bfbaa3 !important;
background:#fffbe6 !important
}
.mw-parser-output .vph > table td:nth-of-type(2n+1) {
border-bottom:2px solid #bfbaa3 !important
}
.mw-parser-output .vph > div {
border:2px solid #bfbaa3 !important;
border-top:0 !important;
background:#f2ecce !important
}
.mw-parser-output .tpl-vp-colors .tpl-vp-heading, .mw-parser-output .tpl-vp-colors .tpl-vp-footer {
background:#eee9d9 !important
}
.mw-parser-output .tpl-vp-sections, .mw-parser-output .tpl-vp-blocks {
border:1px solid #a2a9b1 !important
}
.mw-parser-output .tpl-vp-sections.tpl-vp-colors {
background:#fffaea !important;
border:2px solid #bfb1a3 !important
}
.mw-parser-output .tpl-vp-block {
border-bottom:1px solid #a2a9b1 !important;
border-right:1px solid #a2a9b1 !important
}
.mw-parser-output .tpl-vp-footer {
border-top:1px solid #a2a9b1 !important
}
Paste all of this into your common.css user subpage. sapphaline (talk) 18:01, 12 October 2025 (UTC)
Wikipedia 25th anniversary landing page and visual changes
[edit](Courtesy pings to TonyTheTiger Fortuna imperatrix mundi Xaosflux CREditzWiki MSGJ Jolielover QuicoleJR The ed17)

English Wikipedia was launched on 15 January 2001, so 15 January 2026 marks the 25th anniversary of this event. Discussion on what to do about the 20th anniversary started 2 days before the date, but TonyTheTiger noticed slightly earlier this time around so we have a more practical chance of marking the milestone, if we wish to.
Ideas raised so far on the main page are a logo change, a banner, and a landing page. As an initial proposal, we have a possible head start on the logo from WMF. That would be simply adding a puzzle piece with 25 on it (see image right), which feels like it would easily slot into the existing UI element. We may want to slightly expand it to incorporate our "The Free Encyclopedia" tagline. An alternative or complementary change would be to do something to the globe itself, we could use the puzzle piece as an actual puzzle piece, or otherwise fit a 2 and a 5 in there.
The landing page for the 20th anniversary is Wikipedia:20th anniversary. For a potential Wikipedia:25th anniversary, perhaps we could consider including a few statistics, we just did the 7 million article milestone, so alternatives/other additions might be number of FAs, number of edits, number of page views, total article text size, etc. As for a banner, presumably it would include a summary of the landing page and point to the landing page. We might also use it as an opportunity to link to Help:Introduction, to entice new editors. CMD (talk) 17:17, 7 October 2025 (UTC)
- What would number of edits entail? Live edits or? CREditzWiki (Talk to me!!) 17:23, 7 October 2025 (UTC)
- That's a good question, perhaps someone knows, but we have some counter that produces the 1,310,849,014 number at Wikipedia:Statistics. CMD (talk) 17:30, 7 October 2025 (UTC)
- Letting my guard down for a sec because that is a lot more than I thought. CREditzWiki (Talk to me!!) 18:45, 7 October 2025 (UTC)
- I feel like total edits should be displayed. Not sure how hard it would be to go through and judge to get live edits. Just sounds like it should be total. CREditzWiki (Talk to me!!) 21:41, 7 October 2025 (UTC)
- Letting my guard down for a sec because that is a lot more than I thought. CREditzWiki (Talk to me!!) 18:45, 7 October 2025 (UTC)
- That's a good question, perhaps someone knows, but we have some counter that produces the 1,310,849,014 number at Wikipedia:Statistics. CMD (talk) 17:30, 7 October 2025 (UTC)
- Should WP:DYK, WP:TFA and WP:OTD have separate discussions or should their observance plans be here?-TonyTheTiger (T / C / WP:FOUR / WP:CHICAGO / WP:WAWARD) 21:01, 8 October 2025 (UTC)
- DYK and TFA have their own processes, and more importantly they would need eligible articles. OTD could be discussed there, but it also relies on articles being of sufficient quality. Wikipedia maybe, but English Wikipedia is yellow-tagged. CMD (talk) 05:55, 9 October 2025 (UTC)
- If OTD could be discussed here, I suggest we discuss it here. What shall we discuss regarding OTD? CREditzWiki (Talk to me!!) 15:52, 9 October 2025 (UTC)
- DYK and TFA have their own processes, and more importantly they would need eligible articles. OTD could be discussed there, but it also relies on articles being of sufficient quality. Wikipedia maybe, but English Wikipedia is yellow-tagged. CMD (talk) 05:55, 9 October 2025 (UTC)
- I'm fine with anything as long as it doesn't involve any specific article being highlighted. Still can't get the whole WP:7M thing out of my head. EF5 15:54, 9 October 2025 (UTC)
- I get what you mean. Personally, it took away from all the other good work being done. CREditzWiki (Talk to me!!) 16:17, 9 October 2025 (UTC)
- Support Why not? Seems like a pretty great idea. Agree with what EF5 said above, however. Bremps... 00:38, 12 October 2025 (UTC)
- this would probably take quite a lot of time, but would a new readership survey be possible to set up? the last survey was 15 years ago and things have changed quite a lot since then (especially the use of the internet) and it would be quite a nice way to commemorate the site's use; to encapsulate who wikipedia works for, and remind people of the extent of the site's functionality. i also support the above proposals.--Plifal (talk) 05:53, 13 October 2025 (UTC)
- @Plifal, the last reader research wasn't 15 years ago. There's been a lot of active research on readers, including current research such as m:Research:Readers' research 2025. Did you have something specific in mind, that you wanted? WhatamIdoing (talk) 17:41, 13 October 2025 (UTC)
- well, please forgive my ignorance, but research and the kind of broad readership survery we did in 2011 seem to be rather different in scope and questioning. the latter is more of what i had in mind.--Plifal (talk) 22:52, 13 October 2025 (UTC)
- You're thinking of m:Research:Wikipedia Readership Survey 2011? There are more in m:Category:Reader surveys. If you're looking for recent surveys, then m:Research:Knowledge Gaps Index/Measurement/Readers Survey 2024 is sometimes called the 2024 Global Readers Survey. m:Research:Surveying readers and contributors to Wikipedia should have just finished their second collection of data, but I wouldn't expect the results to be posted for a while. WhatamIdoing (talk) 05:13, 14 October 2025 (UTC)
- well, please forgive my ignorance, but research and the kind of broad readership survery we did in 2011 seem to be rather different in scope and questioning. the latter is more of what i had in mind.--Plifal (talk) 22:52, 13 October 2025 (UTC)
- @Plifal, the last reader research wasn't 15 years ago. There's been a lot of active research on readers, including current research such as m:Research:Readers' research 2025. Did you have something specific in mind, that you wanted? WhatamIdoing (talk) 17:41, 13 October 2025 (UTC)
Modify template:red and template:gray to be WP:COLOR-compliant
[edit]My edit requests (1, 2) were declined, so let's discuss my proposal here.
I don't get why these templates must output "gray" and "red" in the CSS meaning of these words, especially when their contrast ratio againt the background is insufficient for like 99.9% of their use cases (red
's contrast ratio against an #fff
(completely white - the one Wikipedia uses as a main one) background is 4.0:1, gray
's contrast ratio against an #fff
background is 3.95:1; WP:COLOR requires a contrast ratio of at least 4.5:1 - The contrast ratio should meet at least the WCAG 2.0 AA standard of 4.5:1
). "Red" and "gray" can mean very different colors to different people; it's only CSS where they strictly mean #f00
and #808080
, and I don't know any person for whom this text's and this text's color wouldn't be "red" and "gray", respectively.
Ping @Jonesey95: as the user who declined my requests. Sapphaline (talk) 19:57, 8 October 2025 (UTC)
- No, the CSS values "red" and "gray" do not have different meanings for different people. They are standardized. See this reference page for a list of the named CSS colors and their defined values. Editors are welcome to make other color templates, but a template called "red" should output the CSS color "red". – Jonesey95 (talk) 20:48, 8 October 2025 (UTC)
- I'm not arguing that they do; I don't agree with your idea that these templates should only use these colors in their CSS meaning. Sapphaline (talk) 20:57, 8 October 2025 (UTC)
- I agree with Jonesey95 - "red" in an internet context has a defined meaning, and it would be very surprising and arguably misleading for Wikipedia to arbitrarily pick a different colour. If there is a problem with the way the templates are used then what you need to do is get consensus to use different templates that use different colours. Arguably we should be using multiple templates that output semantic meaning appropriate to the given context for the benefit of e.g. screen readers. So e.g. when illustrating good and bad practice in the manual of style we should be using something like {{positive example}} and {{negative example}} rather than {{green}} and {{red}}. Thryduulf (talk) 21:31, 8 October 2025 (UTC)
- @Jonesey95 Why should {{red}} be red (RGB) and not red (CMYK), red (Munsell color system), red (Natural Color System), red (Pantone), or red (WP:RED)? There are lots of color systems with their own definitions of "red". Similarly, there's the HTML/CSS gray, but there's also gray (X11) --Ahecht (TALK
PAGE) 21:32, 8 October 2025 (UTC)- Because if we care about web accessibility standards, we should use the standard colours associated with the standard colour names in the standard issued by the web accessibility standards body. The relevant standard is Web colours#HTML colour names. Thryduulf (talk) 21:40, 8 October 2025 (UTC)
- I'm not arguing that they do; I don't agree with your idea that these templates should only use these colors in their CSS meaning. Sapphaline (talk) 20:57, 8 October 2025 (UTC)
- I agree with Sapphaline here. We should be using the accessible versions as close to the standardized name colors. Templates have a name but implementations can change, and literally nothing stops us from being red-enough or grey-enough in templates named red or grey. On this dimension, I would suggest using the APCA rather than the WCAG 2.0 AA standard e.g. this is the lightest grey against white with an accessible general text score.
- To some degree, if the criterion we base these templates on existing is "they match the web colors they're named after", then I think they are too simple to be templates and should simply be deleted (and/or in favor of {{color}} already existing).
- As Thryduulf says above, semantic meaning should generally have their own templates and not use random base colors (for machine readability and in some cases indeed screen readers). Izno (talk) 22:15, 8 October 2025 (UTC)
- If {{red}} and {{gray}} cause contrast issues, we should document those issues, then create and recommend {{red-accessible}} and {{gray-accessible}}, or whatever, if they do not already exist. Document those, link to them from relevant guidelines, and explain when and where each template should and should not be used. An army of annoying gnomes (disclaimer: I have achieved the rank of colonel in that army) will no doubt go around swapping out templates to improve accessibility. But for goodness sake, don't change a web-based template that is called "red" away from the CSS/HTML standard that explicitly defines what "red" means on web pages. Wikipedia is a web site. – Jonesey95 (talk) 22:32, 8 October 2025 (UTC)
- No, the default and easiest choice should always be the accessible one, and the follow on is that we should never make it easy to be inaccessible per se. Documentation doesn't work. Gnomes are only going to get yelled at for swapping stuff out and making noisy edits that ultimately add no value to the page history besides having changed the wikitext in 200+ places rather than the one that is the template. You know how that works as well as I do. (Hello, fellow colonel.)
- You're really stuck on the name of the template matching the color in the CSS. I don't get that, but it's not convincing. Just as easily, if there must be templates for the web colors (and per above I think if that's what's going on then no, they don't need to exist), you can as easily make {{web red}}. But I assert as-above such a template should not exist triply because it is known to be inaccessible in general body text, because it is too simple to be a meaningful template, and because it functionally duplicates an already-existing template that isn't the proposed changed {{red}}. Izno (talk) 22:46, 8 October 2025 (UTC)
- If the English Wikipedia community wants to fully support dark mode (or, for that matter, setting colours in skins), then it will have to move away from specifying literal colours and use semantic markup combined with colour settings in stylesheets. To this end, there should only be a small number of templates to set specific colours when the situation warrants it (such as {{color}}), and uses of others like {{red}} should be changed to templates with semantic meaning. However until that change is made, a workable transitional approach is for the colour set by templates like {{red}} to be managed by stylesheets, and to adjust it for accessibility. isaacl (talk) 00:21, 9 October 2025 (UTC)
- I'm sympathetic with both camps here. I get the argument for red = red and I also get the red should be an accessibility compliant red. There is a considerable amount of content - tables, templates etc that uses css color names in their code. If I'm coding a table I don't use
color=#ff0000
I writecolor=red
. So if there is a redefinition of red please amend all the stylesheets so that red is consistent across all areas, or make me start using hex/rgb whichever every time by undefining red so that it generates errors. Nthep (talk) 07:52, 9 October 2025 (UTC)- Hopefully when hardcoding a color in, say, a table cell, you're using something like
| style="color: red;" | cell value
? Hardcoded values like these can't be changed globally; the individual instances have to be updated. isaacl (talk) 17:24, 9 October 2025 (UTC)- Yep, I used = instead of : As a Brit it's enough effort to type color and not colour let alone get the symbols right 😀 Nthep (talk) 08:28, 10 October 2025 (UTC)
- As alluded to by Ahecht (and other editors in other threads), a stylesheet-friendly approach is to define a CSS custom property, or to reuse one that has already been defined by MediaWiki. This can be used directly when hardcoding a value, if the situation warrants it, or in a suitable wrapper template. Skins could then override the value in the property to accommodate their design (including both light and dark mode variations). isaacl (talk) 17:33, 9 October 2025 (UTC)
- Hopefully when hardcoding a color in, say, a table cell, you're using something like
- @Isaacl We could always use
var(--color-link-red,#bf3c2c)
, which wouldn't require any new CSS. --Ahecht (TALK
PAGE) 16:15, 9 October 2025 (UTC)- Sure, in general; the point is to set the colour in a way that can be managed by stylesheets. Regarding your specific example, I'm not sure if using the link red colour is the best semantic choice for the {{red}} template. isaacl (talk) 17:28, 9 October 2025 (UTC)
- I'm sympathetic with both camps here. I get the argument for red = red and I also get the red should be an accessibility compliant red. There is a considerable amount of content - tables, templates etc that uses css color names in their code. If I'm coding a table I don't use
- If {{red}} and {{gray}} cause contrast issues, we should document those issues, then create and recommend {{red-accessible}} and {{gray-accessible}}, or whatever, if they do not already exist. Document those, link to them from relevant guidelines, and explain when and where each template should and should not be used. An army of annoying gnomes (disclaimer: I have achieved the rank of colonel in that army) will no doubt go around swapping out templates to improve accessibility. But for goodness sake, don't change a web-based template that is called "red" away from the CSS/HTML standard that explicitly defines what "red" means on web pages. Wikipedia is a web site. – Jonesey95 (talk) 22:32, 8 October 2025 (UTC)
Community CT for Tropical Cyclones
[edit]The ongoing disruption around Typhoon Matmo makes me think administrators should have extra tools in the topic area. Previously, in 2022, the topic area was the subject of an arbcom case due to off-wiki coordination around these sorts of issues. Therefore, I propose that administrators are given the ability to use the standard set of community topic restrictions tools on articles related to tropical cyclones, broadly construed. This wording matches the wording that was used for WP:GS/ACAS, but I am open to anything where the meaning is broadly similar. -- Guerillero Parlez Moi 17:50, 9 October 2025 (UTC)
- Support, but preferably for weather as a whole. For reasons which I can’t really identify, the entire topic area is highly controversial and tends to be caught up in ArbCom cases, ANI reports and edit wars. EF5 17:57, 9 October 2025 (UTC)
- Climate change. Sapphaline (talk) 19:51, 9 October 2025 (UTC)
- It’s not even that, it’s just that there is a long history of disputes throughout the entire topic area. So much so that I proposed the same thing as a result of numerous LTAs, two ArbCom cases and overall disruption, but was shot down. EF5 20:10, 9 October 2025 (UTC)
- Contentious topics tend to arise when a majority of the editors involved start attaching significant emotional weight to whether articles are (by their definition) "right", which correlates with a high concentration of either special interests or special interests. There's a small amount of the former regarding weather, but it's mostly the latter. -- Tamzin[cetacean needed] (they|xe|🤷) 03:16, 10 October 2025 (UTC)
- It’s not even that, it’s just that there is a long history of disputes throughout the entire topic area. So much so that I proposed the same thing as a result of numerous LTAs, two ArbCom cases and overall disruption, but was shot down. EF5 20:10, 9 October 2025 (UTC)
- Climate change. Sapphaline (talk) 19:51, 9 October 2025 (UTC)
- I've been watching the most recent saga at AN/I, and while making no comments on that particular case, I think some of the disruption in the area is at least partially because the weather editor base skews very young. (At least, that's been my impression) Which isn't in itself an issue (there's plenty of younger Wikipedia editors who are, not just constructive, but highly skilled editors!), but if you put a bunch of developing humans learning conflict resolution for the first time in group, give them conflict and very little supervision, then edit wars and the like are just going to happen. Anyways, I support giving admins an increased ability to quietly separate people in this topic area (weather or tropical cyclones) and tell them to knock it off without dragging them through high-profile AN/I threads. GreenLipstickLesbian💌🦋 18:07, 9 October 2025 (UTC)
- To clarify, are you proposing that the community-authorised discretionary sanctions procedures be followed, with the standard set of contentious topic restrictions authorized for use? As I discussed earlier this year, the community-authorised discretionary sanctions procedures have different notification requirements and restriction durations than those under the contentious topics framework. isaacl (talk) 18:28, 9 October 2025 (UTC)
- What are the different notification and restriction requirements? I'm not seeing anything at WP:GS that indicates a difference. voorts (talk/contributions) 01:29, 10 October 2025 (UTC)
- The contentious topics framework requires a specific template to be used the first time an editor is made aware of a contentious topic, but any message can be used to make editors aware of further contentious topics (see Wikipedia:Contentious topics § Awareness of contentious topics). A single administrator can impose an indefinite restriction upon an editor (see Wikipedia:Contentious topics § Procedural summary).
- With the authorization for discretionary sanctions framework, a specific template must be used to make an editor aware for each topic covered by discretionary sanctions, and the notification must be re-issued every twelve months (see Wikipedia:Arbitration/Index/Discretionary sanctions (former) § Awareness). (Anyone participating in proceedings related to the discretionary sanctions area in the last twelve months is also considered to be aware; this is more generally covered by the "any message" condition for contentious topics.) Restrictions on an editor enacted on the basis of the authorization for discretionary sanctions can have a maximum duration of one year (see Wikipedia:Arbitration/Index/Discretionary sanctions (former) § Sanctions). One approach that some administrators take, when appropriate, is to impose a one-year restriction under the discretionary sanctions framework, and a subsequent indefinite restriction under regular policy (if it permits). This means that appeals of the restriction have to take place at the arbitration enforcement noticeboard for the first year, but then reverts to the usual appeal process.
- There may be other differences between the two frameworks that I do not recall at the moment. isaacl (talk) 02:00, 10 October 2025 (UTC)
- RE your second paragraph, there's a big notice at the top of that page that says:
voorts (talk/contributions) 02:08, 10 October 2025 (UTC)This Wikipedia page has been superseded by the contentious topics procedure and is retained primarily for historical reference. It is also referenced by some community sanctions. For more information on the transition to the contentious topics procedure, see the Committee's transition guide. This page reflects the text of the discretionary sanctions procedure immediately prior to the adoption of the contentious topics procedure.
- It says "referenced by some community sanctions", not all. We don't need to follow that for future community sanctions. voorts (talk/contributions) 02:09, 10 October 2025 (UTC)
- Yes. That's why the community should make it explicit: is this a proposal to use the older discretionary sanctions procedures, or to use the contentious topics procedures? The community hasn't obsoleted the use of the discretionary sanctions framework for new topics, and it hasn't converted any of the pre-existing community-authorized topic areas to use the contentious topics framework. (The arbitration committee did both of these, and they own the discretionary sanctions page, so they wrote the notice from their point of view.) isaacl (talk) 02:24, 10 October 2025 (UTC)
- It says "referenced by some community sanctions", not all. We don't need to follow that for future community sanctions. voorts (talk/contributions) 02:09, 10 October 2025 (UTC)
- RE your second paragraph, there's a big notice at the top of that page that says:
- What are the different notification and restriction requirements? I'm not seeing anything at WP:GS that indicates a difference. voorts (talk/contributions) 01:29, 10 October 2025 (UTC)
- For whatever reason our weather (as opposed to climate) articles appear to have attracted a rather immature crowd with (I'm not sure how to say this without offending anyone) trainspotterish tendencies. Most seem to be be prepared to listen, at least more so than the nationalist editors who inhabit many other contentious topics, so I think they just need a little more adult guidance than is usually the case rather than any formal declaratiom that this topic area is contentious. Phil Bridger (talk) 20:33, 9 October 2025 (UTC)
- No, you’re completely right - “weather nerds” do tend to have ASD-related conditions, something studied by the American Meteorological Society in 2020, a study visible on my userpage. Plus, a lot of the weather-interest community is younger (theres a newspaper somewhere mentioning how many of WPTC’s members are teenagers). EF5 20:47, 9 October 2025 (UTC)
- In my opinion,the best way to provide that adult guidance would be through empowering admins rather than dragging people through very public threads at AN or ANI -- Guerillero Parlez Moi 10:26, 10 October 2025 (UTC)
- Us "trainspotters" have been able to self-police and avoid major disruption just fine. Why is it that weather editors cannot? I'm quite literally on the spectrum myself... Trainsandotherthings (talk) 20:51, 10 October 2025 (UTC)
- No, you’re completely right - “weather nerds” do tend to have ASD-related conditions, something studied by the American Meteorological Society in 2020, a study visible on my userpage. Plus, a lot of the weather-interest community is younger (theres a newspaper somewhere mentioning how many of WPTC’s members are teenagers). EF5 20:47, 9 October 2025 (UTC)
- Support, I have spent the last couple of days going over this issue and started writing an essay about this which can be found here. I've pull some highlights and plots from that essay here to make my point but the tldr is we need to make some changes because this keeps happening.
- My recent interaction with the Typhoon Matmo (2025) article brought up a lot of challenges storm articles face as an outline of the Matmo storm I noticed the following.
- As of sometime yesterday of the 199 edits to the article 65 (or 32%) have been reverted or restored this week.
- Requested admin actions came into RFPP, Wikipedia:Requests_for_page_protection/Archive/2025/10#Draft:Tropical_Storm_Matmo_(2025)
- ANI Wikipedia:Administrators'_noticeboard#Can_someone_figure_out_what_is_going_on_with_these_tropical_storm_drafts? and Wikipedia:Administrators'_noticeboard/Incidents#Ban-evading_proxy_IP_causing_disruptions_across_typhoon_articles
- Even I screwed up! User_talk:Dr_vulpes#Draft:Tropical_Storm_Matmo_(2025).
- Standardized Chaos: When Everyone Has Their Own Storm
- One source of conflict I observed from a recent article Tropical Storm Mateo stems from how tropical cyclones are named and by which meteorological agency. For inexperienced editors or editors who are new to the project they either lack knowledge of the rules or only grasp the basic fundamental rules. From this perspective it creates an odd edge case as the material on storm names being added or removed from articles is not a case of unreliable versus reliable sources. To new editors all of these meteorological agencies qualify as reliable sources, further they are all being reported on by trusted reliable secondary outlets. So when the Japan Meteorological Agency calls a storm "Neoguri" while PAGASA calls it "Helen," both names are at least somewhat “correct”.
- In the Western Pacific, typhoons face a complex naming situation. The Japan Meteorological Agency assigns international names to tropical cyclones on behalf of the World Meteorological Organization, while PAGASA assigns names to any tropical cyclone that enters or forms in their country. This means a typhoon can legitimately carry two different names simultaneously. For example, CNN had to report both names last month “Typhoon Ragasa, known in the Philippines as Nando”. Other issues arise when agencies use different ways of describing typhoons. For example Hong Kong has used a numbered warning system since 1917 that had been introduced by the British.
- The New Editor Problem
- Active tropical cyclones attract editors who may be participating in Wikipedia for the first time. These storms are current events with readily available structured data, making them seem like easy and important articles to edit. However, editors’ unfamiliarity with Wikipedia's policies and culture, leads to a rise in problematic behaviors: article ownership, edit wars, and Misunderstanding when to get an admin involved. There is a longer version of this in my essay.
- Why is this all a problem?
- Active edit conflicts can create a lot of work our community. Instead of working on articles or performing admin tasks, resources are instead dedicated to:
- Monitoring and policing active storm articles
- Helping out and educating new editors with policies and guidelines
- Handling disputes that arise between new editors
- Page protection that are dealing with an edit war
- Handing out warnings to talk pages and blocks if needed
- Analysis
- I did some analysis in R (code) to look at the number of weather related issues at WP:RFPP, and WP:AN/I.
- Weather Related Page Protections at WP:RFPP
- Looking at this plot we see that there's a spike in page protection activity from WP:RFPP during tropical storm seasons in the northern hemisphere.
- Weather Related WP:AN/I Complaints
- 6053 weather related complaints brought to WP:AN/I between 2010 and early October 2025 by category.
- What can we do to address this?
- These were just some things I thought might address the issue with storm articles.
- Welcome templates: Creating a new welcome message for weather articles. Include links to policies and sources new users might find helpful. Clearly explain known issues like the multiple source naming issue for Typhoons.
- Talk page templates: Create banners for article talk pages that explain the issues these articles have.
- Proactive protection: Protecting active storms articles with semi-protection until a period of time has passed after the storm has dissipated
- Dr vulpes (Talk) 23:45, 9 October 2025 (UTC)
- This feels like a mis-analysis of the situation. Typhoon naming practices are long established and standardised: the JMA name is used for article titles and most text, other names are included where relevant in the lead in the normal Wikipedia fashion. Naming is not an issue. The most recent disruption is around DATEVAR, curiously enough. I'm not sure about the newness of all the editors, but the broad and somehow persistent problem (went to arbcom a few years ago) seems to be that WPTC develops an insular culture that drifts from the general expectations of en.wiki. If the community is going to intervene, the best way to do that would be to figure out why this drift happens, and try to develop the WikiProject to better guide new editors. CMD (talk) 01:45, 10 October 2025 (UTC)
- I think Dr vulpes' analysis matters less than the data, which are clearly cause for concern. voorts (talk/contributions) 01:50, 10 October 2025 (UTC)
- (edit conflict) "Naming" being the root cause of these issues is unconvincing. A few years back, the biggest issue was the constant conflict in updating storm data (pressure, wind speeds, position, etc.) but that hasn't been a problem since {{Infobox weather event/live}} was deleted (see discussion, related ANI). We've had a long history of including data from various meteorological agencies with no issue. What becomes an issue is when editors, especially new ones, jump into the weather article topic without any prior knowledge of Wikipedia, try to race to be the "first person" to add something to the article, and end up complaining or reverting when others get it done first. This applies to both edits and drafts; we even have editors making drafts under any conceivable potential name, which there are many as a storm develops (e.g. "Tropical Depression Matmo", "Tropical Depression Paolo", "Tropical Storm Matmo", "Tropical Storm Paolo", "Typhoon Matmo", "Typhoon Paolo", and all other variants of this with a year disambiguator). I find this issue to be a worse case of what we have on recent events articles in general: people trying to race to keep an article "up to date" and exhibiting WP:OWN-like behavior when they don't get their way.
- That aside, I'm wondering what methodology was used in the analysis of ANI topics related to weather complaints. 6,054 sections of weather-related complaints in a 15-year period does not seem likely. Doesn't look like any R code was included for this so I'm unable to tell just how this conclusion was made. I also find the need to point out that "proactive protection" is specifically against WP:PREEMPTIVE.
The LLM used here really missed the mark and it, much like the weather editors, seems unaware of how Wikipedia policies and guidelines work.Chlod (say hi!) 01:52, 10 October 2025 (UTC)- Please do not accuse other editors of illicitly using LLMs.That is a serious accusation. voorts (talk/contributions) 01:56, 10 October 2025 (UTC)
- The code writes
I used an AI/LLM to help with dates and regex because they always frustrate me.
in the comments and the full essay is something that I would consider as LLM-supported (not necessarily "written", I don't have an issue with people using LLMs to help them improve their own writing) text. Am I supposed to think otherwise? Chlod (say hi!) 01:59, 10 October 2025 (UTC)- I don't think I even mentioned that the use of the LLM here is "illicit" either. Last I checked, WP:LLM is just an essay. Chlod (say hi!) 02:01, 10 October 2025 (UTC)
- You stated that
[t]he LLM used her really missed the mark and it ... seems unaware of how Wikipedia policies and guidelines work.
That clearly implies that you believe Dr vulpes advanced the views of AI rather than his own. voorts (talk/contributions) 02:03, 10 October 2025 (UTC)
- You stated that
- I don't think I even mentioned that the use of the LLM here is "illicit" either. Last I checked, WP:LLM is just an essay. Chlod (say hi!) 02:01, 10 October 2025 (UTC)
- The code writes
- @Chlod the only LLM use that was used here was in the code section and is noted in the comments. At around line 2 and 446.
- "# I used an AI/LLM to help with dates and regex because they always frustrate me."
- "# I used AI/LLM here for the shading on dates in this plot because I'm lazy"
- Dr vulpes (Talk) 02:07, 10 October 2025 (UTC)
- I'll strike that section from my comment then. We're getting hung up over LLMs rather than the point that having different names for cyclones is not the proper analysis here. Chlod (say hi!) 02:10, 10 October 2025 (UTC)
- Does the cause of the disruption really matter all that much? Ultimately, we're deciding whether to authorize standardized sanctions. voorts (talk/contributions) 02:13, 10 October 2025 (UTC)
- I believe the reasoning for why we're deciding whether to apply sanctions is definitely relevant to the discussion and is highly important in informing anyone else who comes across this thread with no prior background on the 'situation' of tropical cyclone (and general weather-related) articles on the wiki. I, for one, would prefer not having sanctions on a topic area based on uninformed consensus. Much like we don't block users who haven't done anything, we shouldn't apply sanctions on topic areas without properly asserting the cause and, if applicable to whoever's participating in the discussion, determining whether such sanctions are necessary for the causes identified. Chlod (say hi!) 02:20, 10 October 2025 (UTC)
- Of course the cause matters in applying sanctions, it helps determine whether the sanctions are effective. We should not be making them on the back of lllm-analyses. The underlying issue has not yet been figured out, and proposed solutions like proactive protection are far outside of the usual community norms, as well as not going to do anything for any of the non-IP editors. CMD (talk) 02:28, 10 October 2025 (UTC)
- Sorry if it wasn't clear, this isn't a full analysis and breakdown of the issue. I should have put some more work into the post to explain that this is just what I saw as issues that came up or could come up and somethings I could support with data. For example there's this edit showing what I'm talking about with storm names. I'm not saying it's the whole issue at hand, it's an edge case that could be an issue (or might have been in the past). The real question to ask "is there abnormal disruptions in active storm articles? Should we do something about it?" and the answer to both I believe is yes. Dr vulpes (Talk) 03:47, 10 October 2025 (UTC)
- Does the cause of the disruption really matter all that much? Ultimately, we're deciding whether to authorize standardized sanctions. voorts (talk/contributions) 02:13, 10 October 2025 (UTC)
- I'll strike that section from my comment then. We're getting hung up over LLMs rather than the point that having different names for cyclones is not the proper analysis here. Chlod (say hi!) 02:10, 10 October 2025 (UTC)
- Please do not accuse other editors of illicitly using LLMs.That is a serious accusation. voorts (talk/contributions) 01:56, 10 October 2025 (UTC)
- This feels like a mis-analysis of the situation. Typhoon naming practices are long established and standardised: the JMA name is used for article titles and most text, other names are included where relevant in the lead in the normal Wikipedia fashion. Naming is not an issue. The most recent disruption is around DATEVAR, curiously enough. I'm not sure about the newness of all the editors, but the broad and somehow persistent problem (went to arbcom a few years ago) seems to be that WPTC develops an insular culture that drifts from the general expectations of en.wiki. If the community is going to intervene, the best way to do that would be to figure out why this drift happens, and try to develop the WikiProject to better guide new editors. CMD (talk) 01:45, 10 October 2025 (UTC)
- Support authorizing the standard set for all edits related to weather events, broadly construed (n.b. this would encompass, at the very least, all articles in Category:Weather events) and allowing administrators to impose preemptive semi-protection on articles or drafts related to weather events, broadly construed, per @Dr vulpes and @EF5. voorts (talk/contributions) 01:43, 10 October 2025 (UTC)
- FWIW, I would also support a broader topic area, such as weather events. I thought that the more narrow scope of just tropical cyclones would have a better chance here. -- Guerillero Parlez Moi 10:30, 10 October 2025 (UTC)
- Support for weather events, broadly construed. Oppose preemptive protection. In the ongoing AN/I thread, the greater disruption has come from registered accounts than from IPs. The main thing community CTOP would be useful for here is allowing admins to impose TBANs, page-level revert restrictions, and editor-level revert restrictions. A lot of weather editors seem to have fallen under the impression that they are allowed to revert freely and infinitely as long as they are on the right side of their wikiprojects' guidance or just an informal consensus of a few weather editors. They need to either course-correct or face editing restrictions. I've also added a proposal below for a warning to the wikiprojects collectively. -- Tamzin[cetacean needed] (they|xe|🤷) 03:42, 10 October 2025 (UTC)
- Comment: (Copy-paste from what I just posted at AN/I:) Whereas the recent events were all around tropical cyclones and DATERET (and are in fact still ongoing) I would rather say the actual problem in question was essentially (i) a general bias among some aggressive users against unregistered editors, (ii) the tendency among some admins to grant page protections and blocks too easily, again, against unregistered editors, and, most importantly, (iii) the non-compliance attitude among some editors towards established policies and guidelines, and the atmosphere that such policies and guidelines can be ignored or looked down upon and the reasonable expectation among them that they would face no sanctions for doing so. 219.79.142.128 (talk) 17:31, 10 October 2025 (UTC)
- It's not just recent events that are at issue. We don't propose community sanctions over recent events, but rather ongoing disputes. Weather events have long been contentious. voorts (talk/contributions) 20:01, 10 October 2025 (UTC)
- I don't know whether what I have observed happens only around weather topics. 219.79.142.128 (talk) 13:05, 12 October 2025 (UTC)
- It's not just recent events that are at issue. We don't propose community sanctions over recent events, but rather ongoing disputes. Weather events have long been contentious. voorts (talk/contributions) 20:01, 10 October 2025 (UTC)
- Support for weather events, broadly construed. I've been involved in the weather scene as an enthusiast (mostly off-Wikipedia) for over a decade, and the observations made above, such as by Phil Bridger, about the "trainspotterish" (or autism-related) tendencies of people in this scene I have found from my experience to be broadly correct. And it does not help that much of this audience tends to skew younger; and there are, well, other factors as well that, while relevant, are IMO not really worth talking about here. I'll only say that the toxicity I have witnessed both on and off Wikipedia in this topic area has got me to keep away from editing much in the area (partly due to a feeling of frustation). Leastways I think that a CTOP designation would help with dealing that toxicity and the related rampant edit-warring that has been common in the area, as well as the user-conduct issues that are periodically brought to the noticeboards. The WPTC ArbCom case dealt with some of these issues, but it is my experience that the area now has new troublemakers; and enabling admins to deal with them through the CTOP toolkit would make for a better editing environment in the weather area. JavaHurricane 10:52, 11 October 2025 (UTC)
Supplementary proposal: General warning to WikiProjects Weather and Tropical Cyclones
[edit]Why do Nigerians and Ethiopians have their own articles, but people like Congolese and Tanzanians don't?
[edit]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.
Hi. I would like to know why Congolese people (people from DRC) and Tanzanian people don't have their own articles, but Nigerians and Ethiopians have. I would love to make those articles myself, however, I'm currently banned from creating new articles. If someone could explain to me why these people groups don't deserve their own article, I would love to know. The population of Congo is over 112 million and the population of Tanzanians is over 67 million. --Pek (talk) 20:47, 10 October 2025 (UTC)
Playground — A Quarantine Zone to Keep the Encyclopedia Pure
[edit]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 fellow Wikipedians! I would like to propose a new namespace called Playground:, a fully separate, non-encyclopedic space from the main namespace for creative, experimental, and fictional content.
![]() |
Text generated by a large language model (LLM) or similar tool has been collapsed per relevant Wikipedia guidelines. LLM-generated arguments should be excluded from assessments of consensus.
| ||||||
The following discussion has been closed. Please do not modify it. | |||||||
Before you say that this conflicts with Wikipedia's mission, note that Playground: is explicitly non-encyclopedic, fully separated from mainspace, and clearly labeled; it will not affect the main encyclopedia in any way. Playground: allows editors to create original research, fictional articles, alternate history, fan creations, and other imaginative content safely. Playground: would be a shared, namespace-wide version of user sandboxes where multiple editors can collaborate, explore ideas, test article formats, and share imaginative or original content without affecting mainspace articles. It is explicitly non-encyclopedic and will not replace Wikipedia’s mainspace encyclopedia. Purpose[edit]The "Playground:" namespace would provide a dedicated area for:
Key Features[edit]
Anticipating Common Concerns[edit]“But we already have User Sandboxes for this!” • Purpose: Sandboxes are personal notepads for drafting mainspace articles. Playground is a collaborative, community-owned space for projects that will never belong in mainspace. • Collaboration: Editing in another user's sandbox is private and discouraged. Playground pages are shared from day one. • Discovery: Private sandboxes are isolated; Playground has a dedicated Special:RecentChanges feed, making experimentation visible to the community. “This conflicts with WP:NOTHERE!” • Playground reinforces Wikipedia’s mission by creating a clear boundary. It is not the encyclopedia. • Clear banners on every page prevent confusion with mainspace. • Editors are expected to maintain proper linking habits to prevent accidental contamination of mainspace. “Why allow original research or fiction? Shouldn’t everything be verifiable?” • Playground is non-encyclopedic; the content is intentionally experimental, creative, or speculative. • This separation ensures that mainspace remains fully verifiable and reliable. • Editors are free to innovate, imagine, and explore without conflicting with encyclopedia standards. “Won't content eventually try to move to mainspace?” • Playground is a permanent, clearly separate space. • Only content meeting mainspace criteria after rigorous review could be considered for mainspace; editorial processes will prevent accidental inclusion. • Playground serves as a sandbox and incubator, not a feeder for unverified content. “Copyright and legal concerns?” • All content must comply with copyright law. • Use of copyrighted material (images, storylines, text) without permission is prohibited. • Community monitoring and page protection help enforce compliance. “Maintenance and admin workload?” • Low stakes: non-indexed, clearly labeled pages reduce urgency. • Self-policing by the community is sufficient; only serious violations (hate speech, copyright infringement) require intervention. • Automated templates, banners, and clear deletion criteria help reduce manual workload. “This might attract the 'wrong kind' of editor.” • Playground provides a controlled environment for creativity. • Editors who learn policies and collaboration here can become valuable mainspace contributors. • It is a gateway for skill development, not a floodgate for chaos. “Search engines might index content anyway?” • Pages will be configured with noindex meta tags. • Regular checks and technical measures ensure content remains invisible outside Wikipedia. Benefits[edit]
Rules and Policy Considerations[edit]
Community Collaboration[edit]I want this idea to grow with the Wikipedia community, so please ask me anything about it! Suggestions, improvements, critiques, and additional ideas are welcome. Think of me as your co-pilot for building the "Playground:" namespace—let's make it safe, fun, and useful for everyone. Next Steps / Implementation Suggestions[edit]
Looking forward to your thoughts and feedback! Let's give Wikipedia a place to be playful, imaginative, and experimental—without compromising its mission of providing reliable, verifiable knowledge. |
Swarde11 (talk) 11:18, 11 October 2025 (UTC)
- You did not get any support when you (or your LLM) proposed this idea a few days ago. What makes you think things will be different this time? Phil Bridger (talk) 12:29, 11 October 2025 (UTC)
Bot to make list-defined references editable with the VisualEditor
[edit]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.
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.)"
There is also this discussion in Wikipedia:Bot requests, in which it was proposed to post a message here in the Village Pump.
Pinging Qwerfjkl, Jc3s5h, Rjjiii, David Eppstein, Anomie, WhatamIdoing, Michael Bednarek, Herostratus, Gawaon, Peter Southwood, Andrew Davidson, Dan Leonard, Sgerbic, Cremastra, Ahecht, Boghog, ActivelyDisinterested, Aaron Liu, Mike Christie, Chatul, Beland, Mrfoogles, Johannes Richter (WMDE), Ifly6, Rich Farmbrough, who participated to previous discussions, in case you want to do it here as well. Alenoach (talk) 22:00, 3 September 2025 (UTC)
- Support This seems a reasonable idea for the reasons given. Andrew🐉(talk) 22:13, 3 September 2025 (UTC)
- 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)
- For clarity: This will affect less than 1% of articles, and it will change this:
{{reflist|refs=
(the list of refs)
}}- to this:
<references>
(the list of refs)
</references>- It's just the 'wrapper' that's getting changed, not the list of refs or the location of the refs. WhatamIdoing (talk) 22:23, 3 September 2025 (UTC)
- 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)- (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)- Many thanks for the reply! If it's a benefit to some editors w/o any detriments to others, I support the bot action. — Fourthords | =Λ= | 23:39, 3 September 2025 (UTC)
- (a) Yes, it's exactly the same. AIUI the reflist template is just calling the
- 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)
- 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)
- {{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)
- 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)
- 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
- {{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)
- 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)
- Doesn't this need to be <references responsive> to match {{reflist}}? -- LCU ActivelyDisinterested «@» °∆t° 23:19, 3 September 2025 (UTC)
- No, because responsive has been the default for years now. WhatamIdoing (talk) 23:27, 3 September 2025 (UTC)
- Then why does <references> not autoformat into columns? At least it hasn't from experience. -- LCU ActivelyDisinterested «@» °∆t° 23:37, 3 September 2025 (UTC)
- 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)
- This doesn't match the behaviour of {{reflist}}. -- LCU ActivelyDisinterested «@» °∆t° 11:16, 4 September 2025 (UTC)
- 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)- That would explain the differences I've seen. -- LCU ActivelyDisinterested «@» °∆t° 11:56, 4 September 2025 (UTC)
- 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)
- Yeah, looks like the
{{reflist}}
30em
is equivalent to telling.mw-references-columns
to wrap on27em
because of thatfont-size:90%
that reflist does. - On testing, even just knocking the default column width for
<references/>
down to29em
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)- Don't both systems have
font-size: 90%
? Or does the formatting get applied in a different order? Dan Leonard (talk • contribs) 01:51, 7 September 2025 (UTC)- Different order.
reflist
sets it on the wrapper-div that it creates, while core-references sets it on theol
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. - Anyway: patch at 1185300. DLynch (WMF) (talk) 02:09, 7 September 2025 (UTC)
- Merged, so it'll be out by WP:ITSTHURSDAY. DLynch (WMF) (talk) 21:49, 8 September 2025 (UTC)
- Different order.
- Don't both systems have
- Hmm. Looks like the font size of the references themselves winds up the same with both {{reflist}} and
- 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)- Do people often use LDR with shortened footnotes? Anomie⚔ 11:47, 5 September 2025 (UTC)
- 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)
- 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)
- If <references> was applying the column width to the right font size[24] we'd be a lot closing to not needing {{reflist}} at all. -- LCU ActivelyDisinterested «@» °∆t° 20:58, 6 September 2025 (UTC)
- Patch making that equivalent to the column-sizing reflist uses is going out this week. DLynch (WMF) (talk) 00:19, 9 September 2025 (UTC)
- Your suggested standard widths was the subject of a discussion I started on TT:Div col. There wasn't much traction there. Izno (talk) 23:15, 8 September 2025 (UTC)
- It looks like the big problem there was the names suggesting exact numbers of columns. Aaron Liu (talk) 00:02, 9 September 2025 (UTC)
- If <references> was applying the column width to the right font size[24] we'd be a lot closing to not needing {{reflist}} at all. -- LCU ActivelyDisinterested «@» °∆t° 20:58, 6 September 2025 (UTC)
- 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)
- 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)
- Do people often use LDR with shortened footnotes? Anomie⚔ 11:47, 5 September 2025 (UTC)
- This doesn't match the behaviour of {{reflist}}. -- LCU ActivelyDisinterested «@» °∆t° 11:16, 4 September 2025 (UTC)
- 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)
- Then why does <references> not autoformat into columns? At least it hasn't from experience. -- LCU ActivelyDisinterested «@» °∆t° 23:37, 3 September 2025 (UTC)
- No, because responsive has been the default for years now. WhatamIdoing (talk) 23:27, 3 September 2025 (UTC)
- Support Makes sense to me. Anomie⚔ 23:57, 3 September 2025 (UTC)
- 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)
- Oppose This does not seem worth running a bot to make 55,000 edits over to me. * Pppery * it has begun... 00:14, 4 September 2025 (UTC)
- 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)
- How would this make our templates broken? --Ahecht (TALK
PAGE) 00:58, 4 September 2025 (UTC) - 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)
- "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)
- How would this make our templates broken? --Ahecht (TALK
- 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 defaultresponsive
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)- What part of
|group=
isn't supported by<references>
? As far as I can tell, {{reflist}} just passes the parameter directly to the Cite extension as<references group={{{group}}} />
, so they should function identically. Dan Leonard (talk • contribs) 05:04, 4 September 2025 (UTC)- Ahecht was probably referring to it missing these styles. Looks like T198021 is related. Anomie⚔ 11:50, 4 September 2025 (UTC)
- @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<div class="reflist-lower-alpha"><references group="lower-alpha" /></div>
. --Ahecht (TALK
PAGE) 18:06, 8 September 2025 (UTC)- Do you know if there's a task for adding the class and style attributes to references, by any chance? Aaron Liu (talk) 18:15, 8 September 2025 (UTC)
- 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)- Sooner if 991614 gets merged, which backports that exact attribute onto the legacy parser. DLynch (WMF) (talk) 21:44, 8 September 2025 (UTC)
- This is something that's going to (sort of) solve itself as parsoid rendering rolls out, because parsoid is going to expose
- Do you know if there's a task for adding the class and style attributes to references, by any chance? Aaron Liu (talk) 18:15, 8 September 2025 (UTC)
- What part of
- Oppose (weak) I'm of the general opinion that problems with the VE should be fixed by fixing the VE. Headbomb {t · c · p · b} 00:53, 4 September 2025 (UTC)
- 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)
- 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
- 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)
- 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)
- 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)- Italian Wikipedia also did a bot run to replace their {{reflist}} version [25] 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)- It would be helpful if the bug described by Anomie here[26] was fixed. -- LCU ActivelyDisinterested «@» °∆t° 22:57, 5 September 2025 (UTC)
- 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)
- Italian Wikipedia also did a bot run to replace their {{reflist}} version [25] once there was no more need for it due to the introduction of
- 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)- 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)
- 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)
- Support provided 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)- 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)- Would it be possible to get something corresponding to {{refbegin}} in ems? Just to make the interface consistent. Ifly6 (talk) 20:40, 6 September 2025 (UTC)
- 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)
- Would it be possible to get something corresponding to {{refbegin}} in ems? Just to make the interface consistent. Ifly6 (talk) 20:40, 6 September 2025 (UTC)
<references />
automatically uses theresponsive
option which adds columns as needed. --Ahecht (TALK
PAGE) 18:08, 8 September 2025 (UTC)
- I think it's better for Reflist to always be replaced as long as the
- 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) - 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)
- 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)- 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)
- 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)
- I've written a patch for it (1185227), but I'm going to need to run it by some people to make sure I'm not missing some complexities. DLynch (WMF) (talk) 23:52, 5 September 2025 (UTC)
- That sounds good. I've struck the "weak" from my support above. Rjjiii (talk) 03:55, 6 September 2025 (UTC)
- Patch is merged, so it'll be out by WP:ITSTHURSDAY. DLynch (WMF) (talk) 21:50, 8 September 2025 (UTC)
- Update: in the fine tradition of Thursdays, we realized that there was a problem with this approach and had to revert that patch. The problem was that when the only use a of a references was within a template (generally the Infobox), we couldn't tell that it existed and so were removing it (phab:T404421 / phab:T356471#11175267).
- There's a new patch up (gerrit:1187849) and we're talking about how to more safely make this change. It may need to be held up for a change to Parsoid (phab:T404608)... but if that happens it'd also unlock a bunch of other useful improvements to template-defined references in VisualEditor (like: them working at all, finally). DLynch (WMF) (talk) 15:03, 22 September 2025 (UTC)
- Patch is merged, so it'll be out by WP:ITSTHURSDAY. DLynch (WMF) (talk) 21:50, 8 September 2025 (UTC)
- That sounds good. I've struck the "weak" from my support above. Rjjiii (talk) 03:55, 6 September 2025 (UTC)
- I've written a patch for it (1185227), but I'm going to need to run it by some people to make sure I'm not missing some complexities. DLynch (WMF) (talk) 23:52, 5 September 2025 (UTC)
- 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)
- 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)
- Comment If the references tag is preferred to the point many are considering a bot replace, there should be much stronger language at Template:Reflist/doc about the preferred syntax. CMD (talk) 04:04, 5 September 2025 (UTC)
- Support Mobile editors would also benefit from this change (I assume). 🌻 A♭m (Ring!) (Notes) 05:43, 5 September 2025 (UTC)
- 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)
- 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)- (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)
- Support Everything should be editable using Visual Editor. Rolluik (talk) 12:46, 6 September 2025 (UTC)
- The benefits are clear, and the downsides are minor. Support.—S Marshall T/C 15:41, 7 September 2025 (UTC)
- 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) - Support. Yeah doesn't seem like {{reflist}} is really needed anymore and certainly not in this case. Galobtter (talk) 23:03, 7 September 2025 (UTC)
- Oppose. Fix the actual problem where it lies, don't ask someone else to put up with a workaround.*:Mathglot (talk) 00:16, 8 September 2025 (UTC)
[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]
- {{reflist}} is the workaround,
<references />
is the "way we had always done it" until the 2010s. The wrapper template was not described as "commonly used" until 2011. I don't understand why you're attributing this request to the WMF. As far as I can tell, Alenoach is not a WMF staff developer, and neither am I (who made the original proposal for this). Dan Leonard (talk • contribs) 01:01, 8 September 2025 (UTC)- 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:
<references />
<references>
</references>
- 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.
- Andrew🐉(talk) 10:33, 8 September 2025 (UTC)
- This is an HTML/SGML/XML standard syntax; TL;DR: they're {{}}, {{, and }} respectively. Aaron Liu (talk) 11:55, 8 September 2025 (UTC)
- It's the exact same system as
<cite>...</cite>
and<cite />
<ref>...</ref>
and<ref />
, which editors already seem to understand quite well. Dan Leonard (talk • contribs) 13:26, 8 September 2025 (UTC)- 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.
- Andrew🐉(talk) 14:27, 8 September 2025 (UTC)
- I think Dan meant to say <ref></ref>. Aaron Liu (talk) 16:19, 8 September 2025 (UTC)
- Yes, early morning confusion between
<ref />
and the name of the extension that powers the tag. Dan Leonard (talk • contribs) 16:50, 8 September 2025 (UTC)- 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}}. - Andrew🐉(talk) 22:54, 8 September 2025 (UTC)
- I see. Well, I've used those various forms of
- Yes, early morning confusion between
- I think Dan meant to say <ref></ref>. Aaron Liu (talk) 16:19, 8 September 2025 (UTC)
- In 20 years of editing Wikipedia, I have never used or even noticed
- 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
andrefbegin
/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)
- 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.
- Andrew🐉(talk) 15:14, 8 September 2025 (UTC)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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:
- {{reflist}} is the workaround,
- 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)
- 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. --PresN 14:57, 10 September 2025 (UTC)
- Support - facilitates editing. Sandstein 21:12, 10 September 2025 (UTC)
- Support Progress. jp×g🗯️ 19:56, 13 September 2025 (UTC)
- 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) - Support per nom makes sense waddie96 ★ (talk) 10:51, 18 September 2025 (UTC)
- Comment What about
{{notelist|refs=}}
and{{notelist-talk|refs=}}
? -- Shmuel (Seymour J.) Metz Username:Chatul (talk) - Support – VE is here to stay, clearly, let's do what we can people. – Aza24 (talk) 22:13, 20 September 2025 (UTC)
- Support Yes please! I love using VE and it's always annoying when it can't parse references. Who knew the solution was so simple. CaptainEek Edits Ho Cap'n!⚓ 03:15, 21 September 2025 (UTC)
- Support please! Legoktm (talk) 14:49, 21 September 2025 (UTC)
References
- ^ 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. ISBN 978-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.