The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.A summary of the conclusions reached follows.
The community did not numerically support this change, mostly for aestheic reasons, though some because they did not see a good reason to take any action. Even among those who supported the change, many complained about the broom icon not looking like a broom or otherwise looking bad (and apparently it's not even part of Codex?). The icon colors also did not match the accent colors of amboxes. Ambox.notice option 2 was also disliked, and it is only distinguished from ambox.content by color, which is an accessibility problem.
Arguments in favor cited improvements for dark mode and color-blind users. Perhaps someone will try again with better aestheics and those goals in mind. -- Beland (talk) 07:33, 19 September 2025 (UTC)[reply]
Should the icons in the message box module be updated from the current Ambox ones to the Codex ones? 13:56, 11 August 2025 (UTC)
ambox.style Not Codex, but is the OOUI for style icon...
ambox.notice
Option 2 ambox.notice
The UI on Wikipedia employs Codex components/design tokens/icons (see Special:Version) such as the message system with the Message component. These messages employ CSS and JavaScript, which we can't do yet in wikitext, see T401186. Instead, the icons have to be uploaded to Commons and used from there, as was the case with OOjs/OOUI on other wikis. We missed the 2019 update to OOUI icons unlike MediaWiki's mw:Module:Message box/configuration.
The license for Codex icons is MIT license, the entire package is GNU Public License. I believe the license might be an issue, as I was informed by @Redrose64 that MOS:PDI states one cannot remove image link= for attribution reasons, the only mention of this is this line:
For CC BY-SA, GFDL, or similarly licensed images, blank |alt= and |link= attributes should not be used. It is Wikipedia's policy to link those images for attribution...
Contrary to that point, Codex is already widely implemented on wikipedia.org: Codex icons and its components are used extensively in the Wikimedia ecosystem as its default UI system. So it makes me wonder if GPL is considered similarly licensed images. I don't see us able to maintain a consistent style and appearance (one of Wikimedia's architecture/guiding principles) with the Wikimedia sister projects, if we don't implement this workaround until the Codex-Wikitext extension (T357463) is released. waddie96 ★ (talk)16:39, 10 August 2025 (UTC)[reply]
@Pppery: Style changes are a necessary part of wiki, in order to modernise. For instance, the padlocks for protection changed in order to fit the theme of the wiki better. This is another example of that. —Matrix(!)ping onewhen replying {u - t? - uselessc} 18:33, 10 August 2025 (UTC)[reply]
I note the padlock discussion was about images displayed at 20×20px and significantly depended on changing from using color as the only distinction to including symbols as well for improved accessibility. This discussion relates to images displayed at 40×40px where the existing icons already differ significantly in shape (more so than the proposed replacements!) and are supplemental to the text of the box itself. Anomie⚔16:42, 11 August 2025 (UTC)[reply]
I removed it for your convenience, but I thought it important to point out as at my edit request I would like to make it clear that those icons were to remain the same and not be replaced with any other ones. waddie96 ★ (talk)15:12, 11 August 2025 (UTC)[reply]
Yes, I removed it, as you could see it was in the lower quadrant as simply carried over as it already exists in its latest format. waddie96 ★ (talk)15:11, 11 August 2025 (UTC)[reply]
Copying what I said in the discussion section since its partly the basis of my oppose: The existing designs are clear and easily identifiable, whereas the new Codex designs are thinner and can be confused. Accessibility needs to be taken into account here, not just ILIKEIT and IDONTLIKEIT arguments.Tenshi! (Talk page) 20:59, 14 August 2025 (UTC)[reply]
Strong oppose – it ain't broke. The new icons are also hard to interpret and, well, ugly, as the broom doesn't look like a broom at all, and the other ones follow the hideous trend of having icons look more and more like letters. Let's not make things more complicated for our readers to understand. Cremastra (talk·contribs) 20:05, 10 August 2025 (UTC)[reply]
It looks like the format brush from MS Word, which is just as a good as a broom. In fact I personally abhor that old motherbleeping[Joke] broom. It may have looked good and trendy in 2005 but since my (wiki)birth it's always looked aesthetically absolutely horrible, low-contrast, and at small sizes unsightable. Aaron Liu (talk) 02:50, 11 August 2025 (UTC)[reply]
It looks like the format brush from MS Word thanks, I didn't know that... and I expect many others didn't either. We shouldn't expect our readers to know the icons from a word processor. Also, a brush is not a broom. That looks like a paintbrush. Cremastra (talk·contribs) 14:24, 11 August 2025 (UTC)[reply]
Maybe I shouldn't have mentioned the Word format brush, because the paintbrush has the same although less specific connotations either way. ambox.style is for stylistic issues. Brooms shift that meaning to "cleaning up the lint", while a paintbrush continues the meaning of "lick of paint" or "dressing it up", which is how style tags are resolved. Aaron Liu (talk) 14:29, 11 August 2025 (UTC)[reply]
Oppose Personally, I find these new icons ugly and would rather keep the existing ones. Not going to fight over that though.As far as the license goes, the Expat (MIT) license states The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. For uploaded images, we've interpreted this as meaning that we need the link to the file description page where the notices are "included". The CC BY-SA license has similar language for notices about copyright, license, and attribution. Images included in the software may not be subject to those terms in the same way, since "all copies" might be taken to refer to the distribution of the software as a whole rather than the rendered HTML. Find a lawyer to try to figure that out. Anomie⚔20:58, 10 August 2025 (UTC)[reply]
Although most of those seem like they'd probably be {{PD-simple}} anyway. The stylized paintbrush is the only one that's not a plain shape with a single text character on it. Anomie⚔21:14, 10 August 2025 (UTC)[reply]
After giving it more thought, switching to "oppose" as I find the new icons to be distractingly harsh and soulless. They might be ok at small sizes, but 40×40px in amboxes is not that. Anomie⚔13:44, 12 August 2025 (UTC)[reply]
If feasible, I have Strong Support in Vector 2022 only: V22 uses the Codex design system. I get that a lot of people hate that skin in general too because it wain't broke, but I'm fairly sure these people would not be using Vector 2022. Technical musings: This might be feasible if we output both images and do a conditional-CSS thing to hide one of them, and unlike JS approaches loading CSS will block the display instead of creating a content flash. For when CSS doesn't load, the page would already look broken enough anyways. Otherwise, I support the original proposal We've had a flat site interface design for a very long time; the time to prevent that has long passed. Now, most of our users do see the new flat design. And unlike the last flat-design proposal, there's no possibility for confusion of the content and notice icon among colorblind users (unless we go with Option 2, which I oppose) and the subtle improvements between the OOUI and Codex circle symbols make it actually look good now. Aaron Liu (talk) 02:50, 11 August 2025 (UTC)[reply]
Was there ever really a "time to prevent that"? Paid designers are going to make trendy new designs whether we want them to or not, and their work falls under WP:CONEXCEPT unless they give us the option or we stage a major revolt. Anomie⚔12:19, 11 August 2025 (UTC)[reply]
There's a whole lot more going on there than "flat design". Discussion there seems to have been far more concerned with the functionality changes. Anomie⚔16:32, 11 August 2025 (UTC)[reply]
Support but note that Codex icons are identical to OOUI. There are several reasons behind this including supporting dark mode, ensuring visual consistency and improving accessibility. I came up with this list a while ago to identify icons that can be replaced with flat design with little problem.
I also want to discuss web accessibility and color blindness in this discussion. Here is what the original vs proposed icons potentially look for someone with total color blindness:
Although I'm not sure that just throwing a greyscale filter over the images is really an accurate representation of any real-world color blindness. Anomie⚔22:36, 18 August 2025 (UTC)[reply]
It isn't, but it probably represents the worst case scenario of complete color deficiency. I did put some permalinks to an online non-WMF tool used to check color accessibility below.
Oppose Laughably bad. No reason given for change other than ILIKEIT and a claim that enwiki should change its style to match some other style (why not the reverse?). Johnuniq (talk) 04:41, 11 August 2025 (UTC)[reply]
Support per Aasim. Consistency is good and the new icons look more modern. WP:BROKE is an unconvincing argument given the low effort that is required to make these changes. Sam Walton (talk) 05:41, 11 August 2025 (UTC)[reply]
Oppose the broom change, that new icon is clearly a paintbrush, which brings to mind very different connotations. CMD (talk) 07:55, 11 August 2025 (UTC)[reply]
Oppose per Pppery. We shouldn't radically change appearances without having demonstrated a real benefit. I don't see how icons that blend into text are a benefit -- they are harder to notice and can be skimmed over easier. They're less 'in your face', which is what we want from warning notices. JackFromWisconsin (talk | contribs) 17:22, 11 August 2025 (UTC)[reply]
Support for consistency and style reason. WP:BROKE isn't a good argument if there is a specific issue with the existing icons (in this case, a striking lack of consistency with the surrounding MediaWiki interface). The first option for ambox.notice is preferable as it is closer to the original intent. Chaotic Enby (talk · contribs) 18:37, 11 August 2025 (UTC)[reply]
Regarding the broom being replaced by a paintbrush, I agree that it is a major change in meaning that might not be ideal, and would prefer having a broom icon in a matching style instead. Chaotic Enby (talk · contribs) 18:41, 11 August 2025 (UTC)[reply]
I never noticed the ambiguous meaning. It looked like a broom to me. Must this be another ambiguous image illusion? Aasim (話す) 18:43, 11 August 2025 (UTC)[reply]
Support most, oppose broom. Whatever that is, it's not a broom. But otherwise, consistency is good. More generally, even if nothing is broken, changing icons every 10 years or so helps prevent a website from looking too stale, even if the change is totally cosmetic. The likes of Apple and Google make sure to include some pointless style changes so you can "tell" that this is the latest version of IOS or Android. While we aren't a business, we also don't want to be TOO boringly consistent in style. SnowFire (talk) 19:37, 11 August 2025 (UTC)[reply]
Support. I support switching to Codex when the changes are small, such as in this case, where the icons basically look the same. The whole point of having a design system such as Codex is to get everything on the website to have a unified look, which is more professional and is (usually) easier for maintenance purposes. –Novem Linguae (talk) 21:38, 11 August 2025 (UTC)[reply]
Oppose. We don't want the modernization of icons, which may somewhat be unclear, especially the broom one. We don't need consistencies in icons especially in maintenance templates. Consider use the old icons. Fabvill (Talk to me!)12:07, 12 August 2025 (UTC)[reply]
Support most, oppose broomWP:ILIKEIT arguments seem fine in discussing our aesthetic presentation, but beyond that, Aasim and Aaron Liu have shown that the new icons are clearer than the status quo in dark mode. Disagree with JackFromWisconsin, as the existing icons were not intentionally designed to be garish, nor would the new icons be ignored on a primarily text-based site only using black text and blue hypertext. ViridianPenguin🐧 (💬) 06:39, 13 August 2025 (UTC)[reply]
Support for consistency. Like it or not, Codex is the common design system of all Wikimedia projects so the decision to eventually standardise on it has already been made (and so IMO !votes on the basis of WP:NOTBROKEN are invalid here). Consistent style is an important part of any professional publication and we are no exception. – Joe (talk) 07:05, 13 August 2025 (UTC)[reply]
The mobile website does all sorts of really stupid stuff. Pointing at it hacking in different, often poorer icons doesn't seem like a good argument to me. Anomie⚔10:40, 13 August 2025 (UTC)[reply]
Regardless of how one feels about the new icons on desktop (or the other changes in mobile), the current desktop icons would be rather illegible at the size of the current mobile ones. novovtalkedits04:37, 14 August 2025 (UTC)[reply]
@Graeme Bartlett Have you seen the existing icons in dark mode? Ugly is a understatement for how they look (they have flipped shadows, and are unnecessarily bright). We really should be adopting a stance/culture of "Our interfaces must look good in the light mode, folks who use dark mode will have to just live with it". There are often cases when I do need to switch to the dark mode because of accessibility reasons (eye strain when reading in lower-light conditions) and the iconset that we use has really been a sticking point for me personally when it comes to reading and editing articles. Sohom (talk) 14:32, 13 August 2025 (UTC)[reply]
I'm guessing you mean shouldn't. I really agree that dark mode accessibility is one of the strongest points in favor of the new icons, and something that I'm happy to see the WMF incorporate in their recent design philosophies. That is one of the reasons why "consistency" here is not only about aesthetics, but also about going along with a more widely accessible system. Chaotic Enby (talk · contribs) 16:32, 13 August 2025 (UTC)[reply]
Oppose the replacement for ambox.style and ambox.notice option two, support the rest. Ambox.notice has an "i" for "information", which the first option replicates. The proposed replacement for ambox.style looks more like a paintbrush than a broom, which can be interpreted as "whitewash this" or "cover this up" rather than "clean this up". The first two are fine. I'm actually in the camp of "if it ain't broke," but I also recognize that it appears very unprofessional when there is inconsistency between projects. Since WMF converted to Codex, we should as well. — Jkudlick ⚓ (talk)15:51, 13 August 2025 (UTC)[reply]
Support the red, orange, and the blue i. I agree with the others that the paintbrush is not a broom, and the exclamation point would fit better in other places than a "notice". Izno (talk) 20:55, 14 August 2025 (UTC)[reply]
Support all except for the paintbrush. I also support the "blue i" icon. The current designs are indeed broken in dark mode, which is available to people who are logged out (in other words, the vast majority of readers). Using the Codex designs fixes this actual problem for a large chunk of our target audience. A personal taste for the older icons should not overcome the needs of our readers.
The paintbrush is neither a broom icon nor actually part of Codex, so I guess I am a weak oppose. I think a broom icon would be a great addition to Codex (the ethos of a wiki is to make mistakes easy to fix, rather than hard to make, so a broom is clearly helpful). Or even if there is some reason not to add to Codex, perhaps we could request a broom in Codex style from the relevant WMF team and/or volunteers. If we find a Codex-style, dark-mode-compatible broom, I support using that. HouseBlaster (talk • he/they)01:43, 15 August 2025 (UTC)[reply]
Oppose as I believe the current icons are easier to recognize. I also believe they are satisfactorily consistent: they are all clean SVGs with pleasant gradients and thin contours. They don't benefit much from being more consistent than that. And that's without considering that thing about I believe the license might be an issue. Sophocrat (talk) 01:47, 15 August 2025 (UTC)[reply]
I do not consider the current icons consistent. The only similarity is all being skeuomorphic/frutiger aero, which is as much as saying Monet and Van Gogh have a consistent artstyle. The speedy-deletion sign and the broom are clearly from very different styles of design compared to the other two signs. (Also, the bigger benefit is consistency with the interface.) Aaron Liu (talk) 16:44, 19 August 2025 (UTC)[reply]
Oppose per 2A0E:1D47:9085:D200:EDFB:7835:FC79:242D. It will create more inconsistencies as some templates (I'm thinking of maintenance templates on articles, which will be seen by readers) will have flat icons while others will have non-flat icons. If someone finds suitable alternatives for the most commonly used ones (such as the book icon in {{More citations needed}}), support all per Joe but weak oppose the broom as it barely looks like a broom at all. OutsideNormality (talk) 01:55, 15 August 2025 (UTC)[reply]
For {{More citations needed}}, would be the most visually similar one, although or convey better the idea of looking for references in my opinion. Any of those would be fine to me.The icon in {{Unreliable sources}} also matches well with (or , if we take the rectangle being searched to represent the article rather than the sources). is closer visually, but could be more confusing as "question mark in rectangle" is a very common symbol and makes it less clear that the rectangle represents the article.{{Disputed}} easily gets .For {{Speculation}}, Codex sadly doesn't have a crystal ball yet (although I could make one in the Codex style if needed). The closest "magic woo" icons (and that's a stretch) are or .{{Current}} and {{Recentism}} can get different colors of .{{Globalize}} gets . Chaotic Enby (talk · contribs) 18:19, 15 August 2025 (UTC)[reply]
Support, those icon suggestions are nice. Sometimes simplicity is better, especially when they're paired with text-heavy boxes. The flat style, though "in vogue" at the moment, is definately easier on the eyes. qcne(talk)20:07, 18 August 2025 (UTC)[reply]
Support Aesthetics are important for webpage design. The Wikipedia logo isn't usually seen on mobile, so it doesn't clash with the codex icons. –LaundryPizza03 (dc̄) 16:44, 21 August 2025 (UTC)[reply]
if the old icons don't work in dark mode Define "work". Except for the broom's shadow, they're all perfectly visible, some just think they're ugly or maybe not dark enough in dark mode. As for accessibility, I note the icons are mainly decorative anyway, the real meaning is communicated by the text of the message box. Anomie⚔13:00, 24 August 2025 (UTC)[reply]
The seven types of ambox (four of which would have their icons changed) are not just decorative. The type is chosen not on aesthetics but is based on the type of issue that the template describes. As with what I mentioned for the unblock icons below, these icons are very functional for a quick glean of this information on the type of ambox, so one can decide faster whether to ignore it, for one. Aaron Liu (talk) 22:31, 25 August 2025 (UTC)[reply]
Oppose I'm unable to easily read the symbols in the new icons due to my astigmatism; they look like plain vertical lines (|) inside the shapes. On the current icons, it's very easy for me to tell that these are exclamation points and a letter i. On dark mode, I'm unable to see the paintbrush handle without squinting whereas the current icon is easily identifiable as a broom. 3df (talk) 05:49, 2 September 2025 (UTC)[reply]
Strongly oppose. 1: I like skeuomorphism and think the older icons look better. 2: Ignoring my aesthetic preferences, the older icons are easier to distinguish. 3: Your icon change will ruin the messagebox for everybody who uses MonoBook or Vector 2010. OmegaAOL (talk) 00:37, 5 September 2025 (UTC)[reply]
As with OOUI buttons, the (upcoming) Codex-Wikitext feature mentioned should or should be easily modifiable to allow alternative icon sets per skin. Aaron Liu (talk) 00:52, 5 September 2025 (UTC)[reply]
Support Important part of UI design is consistency. Although if we wait long enough, I guess skeumorphism will come back so we will avoid having to do anything.. Galobtter (talk) 23:28, 7 September 2025 (UTC)[reply]
Partial oppose. An even more important part of design is making sure that images look like what they're intended to represent. As someone noted above, the new broom icon doesn't look like a broom: it makes me think of a backscratcher or paintbrush, but not a broom. I like all the older images better, but aside from the broom, I don't have a strong opinion; since most of the non-broom icons use exclamation points, the exception looks like ¡ rather than "i", but that's still not a huge problem. Regarding the colourblindness issue — I'm a bit red-green colourblind, but I don't have any difficulty with the current images. Why would this matter anyway? Each icon has a different character or background shape, so even if you're a total monochromat, you can easily distinguish them. Nyttend (talk) 08:03, 11 September 2025 (UTC)[reply]
Strong support for all suggested (including the Qs below) per nom, Aasim, Chaotic Enby, Waddie. as a Vector 2020 and dark mode user, these are a nice change. the whole skin has been very visually appealing and accessible for a user with bad vision, and these would add to it. the (constructive, see below) criticisms for some of the design icons should be taken into account for reworking them as needed. I would also say that the boxes themselves would warrant a bit of change. Juwan (talk) 00:08, 13 September 2025 (UTC)[reply]
I think ILIKEIT and IDONTLIKEIT are going to be themes in this discussion. WP:ILIKEIT and WP:IDONTLIKEIT really apply to deletion discussions mostly but they are also bad arguments for other kinds of discussions. I brought up my reasons for preferring it including dark mode compatibility, consistency with other aspects of Wikipedia (including the protection icons), and accessibility (although I did suggest one change). Arguments on principles on visual design are probably going to be themes similar to the Vector 2022 RfCs. Aasim (話す) 05:37, 11 August 2025 (UTC)[reply]
@Cremastra, Pppery, and Tenshi Hinanawi: my strongest critique would be that much of the discussion relies on subjective perception and analogy rather than user research or accessibility testing. I'm also just going to point out the fallacies in the invalid construction of your argument as comments expressing support or opposition if they are going to represent the community’s position should surely be reasonably substantiated with relevant reasoning, evidence, or examples.
Status quo bias: assumes that because something currently works (or isn’t perceived as broken), it shouldn’t be changed — without addressing whether improvement might be possible or beneficial.
Subjective aesthetic judgment without objective criteria: While personal preferences are valid in casual conversation, as arguments they are weak unless tied to objective usability, accessibility, or design standards.
Personal dislike: This is an ad hominem toward the design, not the proposal. The focus shifts to personal feelings rather than the proposal's functional merits.
False analogy: like the format brush from MS Word comparison assumes visual similarity equals functional equivalence, without establishing that readers will interpret the icon the same way
Overgeneralisation: We shouldn’t expect our readers to know the icons from a word processor. This may or may not be true, but it’s stated as a certainty without evidence of actual reader familiarity. waddie96 ★ (talk)15:34, 11 August 2025 (UTC)[reply]
The existing designs are clear and easily identifiable, whereas the new Codex designs are thinner and can be confused. Accessibility needs to be taken into account here, not just ILIKEIT and IDONTLIKEIT arguments. Tenshi! (Talk page) 15:45, 11 August 2025 (UTC)[reply]
Yes, this. The new icons are less accessible; it is your argument that amounts to ILIKEIT. By definition flat designs with less information are more likely to be confusing, and they should be avoided. Why not have the cleanup icon be File:Broom (PSF).jpg, perhaps rotated 45°? Cremastra (talk·contribs) 16:40, 11 August 2025 (UTC)[reply]
I don't see how they are more easily confused with each other. The key to distinguishing between icons is their differences, not their total size. The added skeumorphic lighting in the Tango icons cancel out as that's something all of them have.I don't see how .content and .notice are any less distinguishable; they have the same amount of differences: color, "direction" of symbol, and an alteration to make it clear the i is a letter. You could I guess say the serif is bolder than just shortening the height but they're already far past the differentiation-baseline for me to dent my subjective differentiation index. Same thing goes for the speedy icon's white inside vs no white inside. Aaron Liu (talk) 03:01, 12 August 2025 (UTC)[reply]
I don't think the new icons are less accessible. What I do know is that the original icons don't look good in dark mode. See this as an example:
Weird, that doesn't happen even logged-out for me in the light/dark comparisons; they only happen in the gallery from Waddie for me. If you click on Extension:Graph and enable dark mode, does the same thing happen? Aaron Liu (talk) 02:56, 12 August 2025 (UTC)[reply]
I'm using the default dark mode gadget. In light mode there is no square around the Dark mode column, but it's there in actual dark mode. CMD (talk) 07:09, 12 August 2025 (UTC)[reply]
Not sure what you mean by "default gadget". I was talking about Vector 2022's built-in dark mode from the appearance menu, which looks like an incognito icon when hidden. Aaron Liu (talk) 14:14, 12 August 2025 (UTC)[reply]
They don't flip, even though IMHO they should. This is because MW renders SVG icons in the backend and then throws out a simple PNG image that is supposed to be appropriately scaled. It would be better to instead have the SVG code spat out to render in the frontend, then stuff like changing the color based on the current theme can work. Aasim (話す) 06:48, 12 August 2025 (UTC)[reply]
Why not have the cleanup icon be: @Cremastra As always, your argument synthesis is derogoratory and your 'discussions' are 'win' or 'lose' mentality—not constructive. waddie96 ★ (talk)02:17, 12 August 2025 (UTC)[reply]
I wanted to add on to the icon you recommended for the "broom".
First, it is grayscale, not colored in. Second, it becomes invisible in dark mode. I am pretty sure the second one can be fixed by inverting the broom, but it does not solve the first problem. This is not being displayed on a grayscale CRT, it is being displayed on a variety of screens from television sets (because yes some people hook their computer to their 4K OLED TV) to HDR monitors to smartphone screens. It should look good on almost all of them. And all the problems as well with the image not being an SVG.
Here is how that icon looks like for the record: . Not good. Even rotating it 45 degrees doesn't really fix the issue:
A few people above are mentioning "consistency with the MediaWiki interface", by which I'm guessing they specifically mean Vector2022. Personally, I really don't see it. Looking at some random pages in a private-browsing window, I see a whole lot of nothing to be consistent with other than the Wikipedia logo in the corner, which these new icons don't match, and whatever we have in the articles themselves, which these new icons don't really match either. I guess "whole lot of nothing" kind of goes with "harsh and soulless", which is the vibe I get from the new codex icons. Anomie⚔22:27, 11 August 2025 (UTC)[reply]
Having a triple-dot menu, the entire top bar, the sticky top bar and user dropdown (only accessible when logged-in for some reason), everything to do with discussion subscriptions, everything to do with notifications, Recent Changes/the Watchlist, the graphic for empty talk pages and editing onboarding, the mentor dashboard, newcomer homepage.... There's also built-in dialog boxes somewhere, beyond the reference previews gadget we have. Aaron Liu (talk) 00:56, 12 August 2025 (UTC)[reply]
So, a bunch of stuff that only shows up when logged in, and changing icons to match logged-in Vector2022 would cause them to mismatch for logged-in users of classic Vector, Monobook, and other skins. I can't say I find that terribly convincing. Anomie⚔13:39, 12 August 2025 (UTC)[reply]
Nope, as a classic Vector user, I also have Codex/OOUI icons in the interface, like the notification icons. If anything, that change is also an improvement for us. Chaotic Enby (talk · contribs) 13:57, 12 August 2025 (UTC)[reply]
Firstly, I'm surprised that no one has commented on what I said about making them only show on V22. Secondly, a quarter of this shows when logged out too. In fact, the Codex warning sign for "You are not logged in" only shows up for logged out users. It's also in all of the editing interfaces. Aaron Liu (talk) 14:18, 12 August 2025 (UTC)[reply]
IMO embedding both and hiding one or the other with CSS is not a very clean solution. Looking at various other places you mention, I again find that 20×20px or smaller icons have a different impact compared to 40×40px ambox icons. I also find the Codex warning sign for "You are not logged in" is oddly truncated, FYI. Anomie⚔14:40, 12 August 2025 (UTC)[reply]
Instead of a brush or a broom, maybe we could go for a color version of the more inviting (File:Codex icon edit.svg), to indicate issues that editors can solve? Other ones I like are (a generic tag icon) or (yes, it's officially the recent changes icon, but simple icons like this are very polysemic). Chaotic Enby (talk · contribs) 14:12, 12 August 2025 (UTC)[reply]
The flat colors make it obvious that these icons don’t match the existing accent colors for the amboxes. I also feel like the orange and red colors are too similar. Amazing how we got it right years ago and yet the WMF tries to reinvent the wheel and makes a simple color-clash mistake like this. —pythoncoder (talk | contribs)17:05, 13 August 2025 (UTC)[reply]
Yeah sorry I don't have time to read all 56 comments since I was last here but:
If we use the icons for accessibility we should ideally not use the current yellow ones, we should use the prescribed yellow warning color at Codex color palette for consistency and for sufficient W2A contrast. See Codex color tokens and Color palette.
Current yellow icon on yellow background would be: #FFCC33 bg/ #FDF2D5 (1.352:1) Fail for large and regular text (AA) Fail for large and regular text (AAA) Fail for UI components and graphical objects (non-text)
The @color-icon-warning on @background-color-warning is: var(--color-icon-warning) bg/ var(--background-color-warning)
(Pretty much trying to match .mbox CSS with @cdx-message CSS
I wonder if a manual of style for icons and colors in templates would be a good idea. It probably can detail stuff like accessibility and icon color, and how maybe we should not solely use color to distinguish function of an icon, as people can have varying degrees of color blindness. WP:DONTFIXIT seems to be one theme in this discussion, as is WP:ILIKEIT and WP:IDONTLIKEIT. But I am not seeing that many arguments based on web accessibility. Sure some icons are supplementary, but even supplementary icons and shapes help people who have dyslexia or do not speak English (like in this Exit sign), people who are color blind (like this traffic light), people who are skimming and want a general idea of what is happening on a specific page, and people in all of these mentioned categories and more. We do have MOS:COLOR and MOS:ICON, but they largely pertain to the use of colors and icons in the prose of articles and not in maintenance templates, user interface, etc. Aasim (話す) 01:48, 20 August 2025 (UTC)[reply]
I think there would be a significant amount of clashing/bikeshedding within the context of such a discussion and a high amount of community inertia (not to mention that we would clash with the WMF Codex/Design team as and when such a style guide becomes out of date). Sohom (talk) 02:46, 20 August 2025 (UTC)[reply]
Yeah the law of triviality is definitely a problem, and I think what kind of icons we are using (flat or skeumorphic or nuvola or old) aren't really worth debating unless if there is an accessibility or readability concern. When I first suggested converting to flat icons all the way back in 2020, the RfC was ended early for not being prime for an RfC, and the only few other times I even entertained the idea in the idea lab, they never went to fruition as RfCs (most recent idea lab post I can find is here). The only things I really do think would be worth including somewhere either on this new style page or in the existing MoS is:
When icons are used as indicators in templates, template colors should match the color of such icons
For accessibility reasons other properties such as icon shape should be used to distinguish between sets of icons part of template series such as the user warning and block templates.
Otherwise, I don't think there is a good reason to revert changes to icons. I think this issue will become less contentious if and when there is an in-built extension tag or parser function that automatically loads the SVG code for any one of the growing icons in the Codex library (and they can potentially be expanded and customized for each design system). Aasim (話す) 04:18, 20 August 2025 (UTC)[reply]
FYI this section did not actually ping anyone because you have to sign your post in the same edit as you added the user names, and you can't ping more than 50 users in the same edit. I really don't think pinging 76 people was necessary here, though. * Pppery *it has begun...14:51, 11 August 2025 (UTC)[reply]
The plan with ambox is to eventually somehow replace the dark-mode background color with --background-color-neutral-subtle (#202122) while fixing the ribbon colors to the left. Aaron Liu (talk) 17:00, 21 August 2025 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Question 2: Should we update the warning and block templates to use Codex/OOUI icons?
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.A summary of the conclusions reached follows.
→ (but modified to have an X inside rather than an !)
→ (but modified to have an X inside rather than an !)
Lv. 4im:
Light mode
Dark mode
→
→
Lv. 4:
Light mode
Dark mode
→
→
Lv. 3:
Light mode
Dark mode
→
→
Lv. 2:
Light mode
Dark mode
→
→
Lv. 1:
Light mode
Dark mode
→
→
(note there is no noticeable difference between the appearance Codex and OOUI icons, and Codex icons already exist for this or can be created easily for this) Aasim (話す) 19:08, 18 August 2025 (UTC)[reply]
As proposer: support, but it would be preferable to wait until it is possible to use Codex icons inline with wikitext before updating. The old templates have this problem of file links to files that can no longer be deleted or updated because they are used so much. There definitely are major accessibility changes to this, including different shapes for Lv. 1 and Lv. 2 warnings, as well as better appearance on dark mode. It's also useful to consider what this looks like with a total color blindness filter I found online.Aasim (話す) 19:08, 18 August 2025 (UTC)[reply]
Okay, I tried creating a template to illustrate the problem clearer. Web accessibility is not an option:
As above, I don't know why you're showing the icons at a quarter the size (by area) that they're actually used at. Anomie⚔22:40, 18 August 2025 (UTC)[reply]
Support. I feel like the new icons are better in dark mode – while flat design and contrast are indeed something to consider, the lighting and white text on the old ones are more problematic in my opinion. I can easily make the cross-inside-octogon since we already have . Chaotic Enby (talk · contribs) 19:34, 18 August 2025 (UTC)[reply]
Oppose for the same reasons I oppose the main proposal: these are harder to recognize (particularly in dark mode) and I haven't seen any convincing arguments why more consistency with the surrounding UI is a good thing. Plus judging by the monochromacy table someone made they seem less accessible. Sophocrat (talk) 20:33, 18 August 2025 (UTC)[reply]
Oppose Same reasoning as above. I note that any argument of "accessibility" is going to be a red herring, since the icons are decorative anyway and the real message of any box is communicated by the text, not the icon. Anomie⚔22:40, 18 August 2025 (UTC)[reply]
Can you clarify which icons you are having trouble distinguishing? For the old icons having an i for both level 1 and level 2 warnings with the only difference being color is problematic from an accessibility standpoint. Aasim (話す) 22:14, 19 August 2025 (UTC)[reply]
Can you maybe reference which icons you are having trouble distinguishing? It would be helpful maybe to help improve this proposal and reach an adequate compromise. Aasim (話す) 03:11, 20 August 2025 (UTC)[reply]
I assume CMD is talking about the solid red clock, the solid red hand, the solid red stop sign, and the dark orange triangle. I agree they are more difficult to distinguish. Cremastra (talk·contribs) 03:27, 20 August 2025 (UTC)[reply]
I think the issue is at the size I am showing them in my half-baked attempt at showing what it might look like for color blind users, even I am struggling to make out the details. But then I am not hunched against my laptop, I have a proper mechanical keyboard in front of my laptop keyboard on my desk that essentially doubles the minimum viewing distance when on a docking station.
Maybe the solution would be to make the icons bigger, so they are 50px rather than 25px, but then that interferes with line placement, necessitating table substitution rather than inline substitution. Aasim (話す) 03:33, 20 August 2025 (UTC)[reply]
A bit ago I was experimenting with unifying all the uw templates in Template:Uw/sandbox and I realized in one of my iterations I used both and in combination with . The icons do look nicer on colored backgrounds that match them, but otherwise when not on a matching color it can look a little hideous. But a hideous color that is still legible is better than un-dark-modeable colors like the white clock that cannot be changed to black as inverting would mess up the color of the hands and the stop X. And on Vector 2022 and Minerva it seems broken, I don't know why. Aasim (話す) 03:27, 20 August 2025 (UTC)[reply]
I've boldly replaced the lv 1 and 3 OOUI icons with the Codex icons, since there is in fact meaningful difference for those. Also, for an ambitious change, one might consider {{cdx-message}}. Aaron Liu (talk) 18:37, 20 August 2025 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Question 3: Should we update the unblock templates to use Codex/OOUI icons?
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.A summary of the conclusions reached follows.
Yes. 2:1 in favor. Supporters found not distinguishing based on color alone is an accessibility improvement, and the new shapes more clearly communicate their meanings. -- Beland (talk) 07:44, 19 September 2025 (UTC)[reply]
Unblock:
Light mode
Dark mode
→
→
Unblock on hold:
Light mode
Dark mode
→
→
Unblock declined:
Light mode
Dark mode
→
→
Unblock accepted:
Light mode
Dark mode
→
→
(note there is no noticeable difference between the appearance Codex and OOUI icons, and Codex icons already exist for this or can be created easily for this) Aasim (話す) 19:08, 18 August 2025 (UTC)[reply]
As proposer: support. The unblock templates have some of the most inaccessible icons IMHO, with only a recolored clock used for all of them. It's also useful to consider what this looks like with a total color blindness filter I found online. Aasim (話す) 19:08, 18 August 2025 (UTC)[reply]
Okay, I tried creating a template to illustrate the problem clearer. Web accessibility is not an option:
As above, I don't know why you're showing the icons at a quarter the size (by area) that they're actually used at. Anomie⚔22:39, 18 August 2025 (UTC)[reply]
The key aspect here is color in this case. If I were to show the icons any bigger I am afraid they would overflow off the screen especially on mobile devices. Feel free to adjust the size of the icons if you think it is necessary for this discussion. Aasim (話す) 23:32, 18 August 2025 (UTC)[reply]
Size is relevant for at least some contrast ratios – for example, WCAG AA and AAA are not the same for regular-sized and large-sized text. However, in this specific case, it is clear that the useful information in the current icons only depends on the colors, which is problematic from an accessibility standpoint. Chaotic Enby (talk · contribs) 23:53, 18 August 2025 (UTC)[reply]
Oppose Same reasoning as above. I note that any argument of "accessibility" is going to be a red herring, since the icons are decorative anyway and the real message of any box is communicated by the text, not the icon. Anomie⚔22:39, 18 August 2025 (UTC)[reply]
Umm... Isn't dyslexia definitely going to cause problems for some editors? Colored icons are much faster to identify than walls of text. Also not everyone who gets blocked here speaks English and an X implies denied and a check implies accepted (in the Western world at least). Aasim (話す) 23:41, 18 August 2025 (UTC)[reply]
Further, if this passes only because people don't like the colored clocks being the only difference, I'd rather see them changed to something like the existing clocks with symbols superimposed in the lower-right corner, like we do for various other things, than the brutalist Codex style icons. Anomie⚔12:26, 25 August 2025 (UTC)[reply]
Support This one has a far better rationale since the original icons are not accessibly differentiable from each other. Sure, there's always other text that tells you that status, but the icon is not purely decorative at all. As a colorsighted person, it serves as a great, fast way to see the status of an unblock request that you can quickly scroll by. On the other hand, you'd have to slow down and read text. There also isn't an easy way to guess that yellow means on hold and blue means it's new without knowing that beforehand. Aaron Liu (talk) 03:12, 19 August 2025 (UTC)[reply]
Not a fan of a big red X for unblock declined, it feels a lot more like rubbing it in than a palette-swapped clock. CMD (talk) 04:31, 19 August 2025 (UTC)[reply]
Maybe check/thumbs down would be more appropriate. I haven't made any changes because I mostly abandoned development of the idea until someone else brought it up. My opinions have not changed that much in the past seven years, but I did see that since we are discussing some of the icons right now we can discuss the others as well.
It really shouldn't matter too much what icons we use and what icons we don't use (apart from accessibility and UI/UX testing), we are an encyclopedia after all, and icons are not part of encyclopedia proper. I don't even know how consensus was achieved for the nuvola icons in the first place, nor the information icons that have not changed since 2005 at the earliest. Aasim (話す) 05:48, 19 August 2025 (UTC)[reply]
I know Phabricator uses ✅ and 👎. That is where I got the idea from. But yeah I see how it can be debatable whether it is appropriate. Aasim (話す) 00:41, 20 August 2025 (UTC)[reply]
Support per Aaron Liu and also common sense: a / makes more sense than coloured clocks for declined/accepted requests respectively, and a pause icon is also more symbolic of "on hold" than a random yellow clock. OutsideNormality (talk) 16:30, 19 August 2025 (UTC)[reply]
However, if it's related to a block, I think there should be a central image to keep the theme (like in this case it was a clock), and then in the bottom right have a changing image based on 'status'. For example: (illustrative example only not a suggestion!).
Support Different-colored clocks don't convey much on their own. For warnings and blocks, there is also the necessity of communicating with users with limited English fluency. –LaundryPizza03 (dc̄) 16:57, 21 August 2025 (UTC)[reply]
Support as of now the icons are basically identical for someone who hasn't spent looking at them. Change in the symbol will be beneficial. (please ping on reply) ~/Bunnypranav:<ping>11:43, 31 August 2025 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
I still think it would be worth considering whether people really want to change to these icons, or if an alternative that keeps a similar style to the old ones while being different in more than just color would be more accepted. Anomie⚔11:19, 19 September 2025 (UTC)[reply]
Considering that the other discussions here closed without consensus to change to flat icons, it seems unlikely that this would have gone that way if another option were given. Several of the supporting comments were more along the lines of "against the clocks" than "for flat icons". Unfortunately I'm not much of an icon designer to create alternatives to propose. Anomie⚔03:10, 20 September 2025 (UTC)[reply]
Hmm I tend to agree with anomie, in my opinion the flat icons are a bust for the moment, in the way that it's safer to assume that the color difference was the reason for the pick between the two sets and it's probably erroneous to deduce the Codex set truly got a thumbs up on this one considering the entire discussion waddie96 ★ (talk)03:21, 20 September 2025 (UTC)[reply]
So I'd say it's likely safe to boldly change them to icons that meet the middle somehow, I have ideas but my taste is too modern so I won't be the one to do it. Then someone is bound to say something if it's not liked. waddie96 ★ (talk)03:23, 20 September 2025 (UTC)[reply]
Do you want to maybe find other icons and see which icon set has more support? This would be a great way to test the water for whether the consensus is for these particular icons or some other icons. But even then, we shouldn't be too obsessed over which style icons are used as icons like the color of templates are the most pointless thing to get into a heated debate about. We are here to build an encyclopedia, not to fuss about with template colors and icon styles. Aasim (話す) 04:38, 20 September 2025 (UTC)[reply]
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.A summary of the conclusions reached follows.
Not with this replacement. The rationale "bikeshedding" is kind of hard to interpret. The only way to make decisions about whether a given change is an improvement without consulting the community is for people to just decide what to do on their own and do it. If the objection is to having the discussion in the first place, it would be helpful to say what the alternative mechanism should be for the next time this comes up. I'm not sure "never make any minor aesthetic changes" is a long-term viable strategy.
Anyway, there were plenty of other editors opposed for more normal reasons. Some provided encouragement to keep looking for a better alternative, saying the existing icon is unsatisfactory. -- Beland (talk) 08:17, 19 September 2025 (UTC)[reply]
Oppose no significant improvement. The current icon has a globe that looks like the Earth and a clock that looks like a clock. The proposed change looks way too cartoony, has an Earth apparently drawn by an anti-Mediterranean conspiracy theorist, and an oversimplified clock. Let's have a nice icon instead of the simplest one available.
No it's not, I was just making the proposition since I thought the above was also derailing to other icons but I see it's simply going to change other icons to Codex. :-) waddie96 ★ (talk)20:44, 20 August 2025 (UTC)[reply]
Just a joke, because the second globe has North America, Greenland, and South America rendered in good detail but doesn't distinguish between Europe and Africa: hence, no Mediterranean Sea. Cremastra (talk·contribs) 21:12, 20 August 2025 (UTC)[reply]
Oppose, no improvement beyond making it flat, and too busy (in terms of colors) to fit with the Codex design language. To fit the theme, a much better choice would be , , or a combination of the two. Chaotic Enby (talk · contribs) 21:24, 20 August 2025 (UTC)[reply]
I think Codex is better suited to smaller icons, like the buttons in the source editor tab in the reply tool. Larger icons like this benefit from a bit more detail and colour, but if we were to move to flat, I don't think Codex would be the right answer, because it would be at this size:
The first thing you notice about that icon is that it is very ugly, because I have no design sense, but I think if we want flat icons that's the level of detail to maintain. Cremastra (talk·contribs) 00:35, 21 August 2025 (UTC)[reply]
Strong oppose: I have seen three topics created by you so far concerning the corporatization of various Wikipedia images and icons. I am opposed to all of those changes. OmegaAOL (talk) 00:40, 5 September 2025 (UTC)[reply]
Please don't discourage people from expressing their opinions. The tradeoff in participating or not is up for each person to weigh. isaacl (talk) 14:58, 10 September 2025 (UTC)[reply]
Support No strong preference between the Icons8 composite and Cremastra's globe-patterned clock (as an SVG). The Icons8 globe by itself () meshes well with the Codex signs and the proposed broom icon; it could be used for Template:Globalize if the Codex-style symbols are adopted for generic use. –LaundryPizza03 (dc̄) 17:06, 21 August 2025 (UTC)[reply]
I concur. There's plenty of nice flaticons similar. A lot of noun project, SVGrepo etc. You just have to dig through 1000+ to get one. But also Microsoft Fluent UI, Antu SVG, Breeze, Icons8, Iconoir, Material Design 3 waddie96 ★ (talk)11:17, 10 September 2025 (UTC)[reply]
Neutral This feels like a trivial change like the color of templates. This icon is flat and consistent with the other Codex icons, but the icon doesn't look that good in dark mode (especially with the white clock). There may be a better icon that is suited for this that can be added as an option B or C. Aasim (話す) 16:13, 22 August 2025 (UTC)[reply]
Strong oppose, we should not be replacing a decently accurate coastline with some really poor blobs. We're trying to be an encyclopaedia, let's try to get some small details right. CMD (talk) 11:28, 10 September 2025 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Just an FYI to those who are watching this discussion: waddie96 is actively changing mboxes and also submitting mbox template edit requests that include these new, flat icons, despite what looks to me like significant opposition in the discussions above. I think they may also be removing linking to the icons, possibly failing to comply with licensing for the icons (I am not a licensing expert, so I could be wrong on this one). You can review their contributions in Template space if you want to see the extent of their recent editing. – Jonesey95 (talk) 04:33, 30 August 2025 (UTC)[reply]
Hey, sorry I didn't think those template edits were controversial or considered as part of this discussion because they're not Codex icons. I will revert the edits. waddie96 ★ (talk) 12:51, 30 August 2025 (UTC) (scratch that, I see one did use a Codex icon waddie96 ★ (talk)13:00, 30 August 2025 (UTC))[reply]
Anomie, I think it's far from a block, when this is the first mention of it. I'm a regular editor of enwiki yes, but to be honest didn't think those template changes were applicable to this discussion. As an administrator you should know that typically, before seeking a block, a final warning in an escalating series should have been posted to the user's talk page. waddie96 ★ (talk)12:58, 30 August 2025 (UTC)[reply]
Thank you for responding appropriately to the notification above! 🙂If behavior is disruptive and continuing, then a block would be appropriate and I don't see a problem in noting that a block is a possible outcome when discussing behavior that may be disruptive if continued. I also don't see the statement you quote in any policy or guideline; I do see something similar in Template:Report vandal, but that wouldn't apply here anyway since WP:Fait accompli is not vandalism. Anomie⚔13:21, 30 August 2025 (UTC)[reply]
Look, I appreciate your thank you. And what I mean to say is, a block is obviously a very serious action. And it will only incite an unfavourable response in a discussion. I believe what makes most users leave enwiki is how we speak to one another. We're generally not kind, or understanding, nor do we AGF as often as we should. I am just as guilty. But I do appreciate bringing up the issue here before reverting my edits. And giving me an oppurtunity to fix up the issue I created. 😄
@Beland: Hi Beland, I'd like to revisit the outcome you summarised for the first part of the discussion, as I have concerns about its accuracy.
One significant issue is the phrasing did not numerically support this change. That raises red flags, since consensus on Wikipedia is not determined by counting heads or votes, but by evaluating the strength and policy-basis of arguments. Using numerical language gives the impression of a vote tally rather than a consensus assessment.
Another point is that substantial weight was given to opinions that did not fully engage with the matter at hand. The issue wasn't solely about the paintbrush icon; it was about updating the maintenance template icons to the Codex set as a whole. While one particular icon drew attention, that should not overshadow the broader question of whether the set itself is suitable.
In addition, the arguments summarised in your close seem too narrow compared to the range that was actually presented. To restate more fully:
Arguments in favour highlighted alignment with MediaWiki’s Codex system (already used in Vector 2022 and mobile), improved accessibility (especially in dark mode), and the benefits of a modern, consistent, and professional appearance.
Arguments against emphasised that the current icons are already clear, recognisable, and functional, while some of the Codex icons were seen as thinner, harder to distinguish, or less meaningful (e.g., the broom vs. paintbrush concern). Opponents also cited potential confusion, lack of demonstrated functional gain, and inconsistency with templates not yet updated.
Intermediate views generally supported Codex adoption in principle, but suggested deferring until more appropriate icons (such as a Codex broom) are available, or until all maintenance templates can be updated together for consistency.
From my reading, the discussion pointed to no clear consensus. There is interest in Codex alignment for long-term consistency, but significant opposition remains regarding specific icon choices and the timing of implementation.
I don't see any practical difference between "no clear consensus" and "the community did not support this change"; either way, this icon set is rejected and the possibility of trying again remains open. Tallying seems to me an appropriate way to answer the question of whether these icons are clearly interpretable and aesthetically pleasing, and how people evaluate the consistency argument. There are also guideline considerations, such as accessibility, but a successful set of icons would presumably satisfy aesthetics, clarity, and accessibility. Your summary of the discussion seems reasonable. -- Beland (talk) 15:47, 19 September 2025 (UTC)[reply]
The fate of future discussions? Including the likelihood they'll be tossed out as consensus already reached against or open for rediscussion because consensus wasn't clear... waddie96 ★ (talk)15:56, 19 September 2025 (UTC)[reply]
I specifically left open the possibility of another try in the last paragraph of my closure; I think it's clear that would be fine. I think it's sufficient to let both the closure and your comments stand. -- Beland (talk) 16:17, 19 September 2025 (UTC)[reply]
modern, consistent, and professional appearance is your own subjective opinion and not a good argument. There are many among us who think flat icons look bland, corporate, likely to go out of fashion in two years, and uninformative. Cremastra (talk·contribs) 16:06, 19 September 2025 (UTC)[reply]
The opinion that these icons are not acceptable has already carried the day. Let's not burn volunteer time on relitigating the whole discussion. -- Beland (talk) 16:19, 19 September 2025 (UTC)[reply]
Looking at the arguments, I genuinely don't see a need to revisit the current closure, especially since it does leave open the possibility of a future discussion over a different set of icons. There is also nothing in the closure that suggest that only opinions on the broom/paintbrush were considered – to the contrary, the closer explicitly mentions supporters of the broader proposal who had reservations over this particular icon.Additionally, while consensus isn't exclusively counting heads, numerical weight does play a role alongside the strength of the arguments, and the closer was right to at least mention it. Chaotic Enby (talk · contribs) 22:02, 19 September 2025 (UTC)[reply]
I have always felt it be pointless to argue over changing the icons (see WP:COLORWAR) but apparently the community has strong reservations about changing the icons. Maybe if there was a way to instead allow users to change the icons just for them then fewer people would care about the icons.
A future question might be if there are cases when we should remove icons entirely. I think we should work towards a proposal that has a chance of passing and whether we should use Codex, OOUI, MDN, or some other icon pack for the entire user interface.
If there was one success it was that some of the icons I suggested in Q3 had consensus for change due to accessibility concerns. Aasim (話す) 23:38, 19 September 2025 (UTC)[reply]
Team, sorry maybe I didn’t make it clear that my reason for creating this thread isn’t to take issue with or rehash the outcome of the discussion.
It was sparked by:
one, the closing editor counted !votes to determine consensus as evidenced by their statement mentioned above – literally the most significant rule when it comes to consensus/rough consensus and not vote;
two, absence of a brief synopsis of the arguments brought to the table by either side to evidence understanding of the arguments by the closer
and using the aforementioned to explain how the decision was reached.
My reasoning is that a lot of editors’ time was spent contributing to this lengthy discussion. And it just feels like “oh it’s done now let’s slap a sticker on it” and pack it away. In future, someone will gain very little insight in the archives to the arguments posed, etc. Instead the closing statement references only a few viewpoints and is lacking substance.
I just don’t think it is fair to summarise a huge discussion in such a way. Alas I know this is a volunteer project, but I thought I’d give approaching the closer a try. waddie96 ★ (talk)00:02, 20 September 2025 (UTC)[reply]
About "counting votes": There are times when counting votes is completely inappropriate. Majority doesn't win when the question is "Shall we blatantly and intentionally violate their copyright?"; the answer is always "No".
There are other times when counting votes is a good thing, or even the only thing. Vote counting is the basis for Wikipedia:Requests for adminship. We might strike some inappropriate votes, and when the vote count is borderline, we might have a 'crat chat, but fundamentally the decision is about what most of the community wants, and that's determined primarily by counting up the votes.
For a question like this, there really isn't any set of official rules to apply. There is no Wikipedia:Maintenance template icons policy or Wikipedia:Icon aesthetics guideline. Either folks agree to make the change, based on common sense, their personal preferences, etc., or they don't.
If you want to revisit this in the future (meaning: next year at the earliest), I think you might have more success if you stop talking about it like it's a design project (e.g., "consistent style and appearance") and instead pick the one (1!) icon on one(!!!) template that you think would produce the most improvement, and propose that. I suggest using words like "easier for people to see in Wikipedia:Dark mode" or "WP:ACCESS improvement for people with low vision" instead of anything about design principles or the "Wikimedia ecosystem". If people agree to that, let the dust settle for a few months, and try again for another. Most people really don't care which icons are used, but a big proposal with high-falutin' justifications will get their backs up. WhatamIdoing (talk) 16:54, 20 September 2025 (UTC)[reply]
I'd endorse the current closure."There wasn't enough support" is not "There is consensus against" either, so I agree with the above that there's no difference changing to "no consensus" would make. The only thing I disagree with is The icon colors also did not match the accent colors of amboxes as 1. hese concerns were addressed 2. the wording makes the close seem lke the closer's opinion instead of prevalent attitudes in the discussion, though I know enough about this discussion to know it's the latter.Regarding counting heads, see the at-lengths explanation at User talk:Aaron Liu/Archive 4#Lab Leak Archive closure (shameeless plug for Wikipedia talk:Closing discussions#Guideline, an RfC I haven't started yet). TL;DR: That is how closure is done when there is no clear precedent that dominates the weight of arguments. I think it's debatable enough to be at the closer's discretion here whether usability in dark moe and consistency trumps the other arguments by precedent, though it would do good to see more of the discussion's arguments addressed for an RfC with such wide participation. Aaron Liu (talk) 00:31, 20 September 2025 (UTC)[reply]
Considering that a lot of arguments are from the perspective of more experienced editors (rather than new ones), I wonder if A/B testing could help discern which icon set is better suited (be it Codex, OOUI, or the current status quo). This could help us as well make a more informed decision into which icon style is preferred. Aasim (話す) 05:16, 20 September 2025 (UTC)[reply]
To be honest, icons of the type under discussion—those that exist to help provide some categorization of the information messages—aren't likely to be a deciding factor in whether or not someone continues to edit English Wikipedia. People will adapt to whatever is used (with more or less effort) and continue on. Thus I don't see an easy way to construct an A/B trial that will produce anything more than the "I like it" opinions being received now. We could have two groups of new users and serve one set of icons to one and the other set to the other, and then poll them afterwards to see how quickly they learned the meaning of the icons. But I suspect we'll just get information on how fast banner blindness kicks in, and the only thing that will matter is how distinct the icons are within a set. isaacl (talk) 17:18, 20 September 2025 (UTC)[reply]
Moving the needle on overall contributions is really difficult. I wouldn't expect that to happen. I'm not sure what you would measure in an A/B test over these icons (except for "I like it" kinds of personal aesthetic preferences).
To give a similar example, two years ago, I initiated a small change to the colors of the header at the top of the Village Pump. Only one editor said something after we made the change. I assume, but can't prove, that some other editors noticed but didn't say anything. It's just not that important. WhatamIdoing (talk) 18:06, 20 September 2025 (UTC)[reply]
Do you think we should change the village pump's header color? Personally, I dislike this yellow-brownish color; it feels outdated and isn't in the usual Wikipedia style. We have so many better colour options over at pages like:
and many others. I suggest we pick a replacement for the current color. The colors below are just some examples; the first three are used on the Main Page.
Update 16:08, 21 August 2025 (UTC): Zanahary has created actual mockups; you can see them in the § Mockups section. (I also collapsed the other color choices below, which weren't being voted on.)
Option A
this is an example of black text with color applied to its background and border
Option B
this is an example of black text with color applied to its background and border
Option C
this is an example of black text with color applied to its background and border
Option D
this is an example of black text with color applied to its background and border
Option F
this is an example of black text with color applied to its background and border
LMFAO. Chaos! Hyperbole much? Encountering an unexpected color change, editors will be beside themselves and won't know what to do! If I didn't know you, I'd suspect trolling. ―Mandruss☎ IMO. 07:10, 11 September 2025 (UTC)[reply]
The current dehydrated beige-yellow-ish looks fine as-is, but D also looks great. Everything else is too light, imo. EF500:29, 21 August 2025 (UTC)[reply]
Support for decorative reasons. This will give visual impact and this will be decoratively clear for colorblind users. Additionally, this will make the Village Pump creatively nice and beautiful. Fabvill (Talk to me!)01:09, 21 August 2025 (UTC)[reply]
Whatever you do, don't forget about dark mode whenever you pick colors nowadays. it has to be legible in both, or you need additional colors for dark mode. —TheDJ (talk • contribs) 11:48, 21 August 2025 (UTC)[reply]
All of the options look ok to me in dark mode. A and C are pretty dark, but I don't see how that would be a problem in dark mode. You want dark? You got dark. Mustn't wake up the wife. Text-background contrast is fine for all. ―Mandruss☎ IMO. 07:59, 11 September 2025 (UTC)[reply]
Support D as proposer; I like purple in general and D is also used on the Main Page, so I agree with the other comments. The village pump should be welcoming and purple is perfect for that. FaviFake (talk) 12:01, 21 August 2025 (UTC)[reply]
Support, the color is indeed ugly right now. I have no problem with any of the mockups made by the proposal nor by myself below. ꧁Zanahary꧂14:34, 21 August 2025 (UTC)[reply]
Sure, no harm, purple would probably look nicer than the current option. But this really isn't the most pressing issue facing us at the moment; bold editing might have been better than launching a giant survey. I'd suggest this be moved to the talk page. Sdkbtalk15:01, 21 August 2025 (UTC)[reply]
But this really isn't the most pressing issue facing us at the moment - Oh I wasn't aware we were supposed to limit discussion to the most pressing issue (wouldn't that mean one thread on the page at a time?). bold editing might have been better than launching a giant survey. Bold editing would have been promptly reverted by one of the Opposers in this discussion. Then we'd be here anyway. We just skipped two needless steps in the process, B and R, and led with D. No, it doesn't need to go to talk. ―Mandruss☎ IMO. 07:28, 11 September 2025 (UTC)[reply]
OpposeWP:DONTFIXIT, there's nothing wrong with the current color and there's nothing better about any of the suggestions below. All this will come down to is which color happens to get the most "I like it" votes from people who bother to comment at all. Anomie⚔16:11, 21 August 2025 (UTC)[reply]
Not so much. We're looking at actual real tangible things like contrast ratios. Besides, I have no problem with popularity for something like this. ―Mandruss☎ IMO. 11:56, 11 September 2025 (UTC)[reply]
The only discussion of contrast ratios is making sure all the options have good ratios. Your own chart below shows that the current one has a better ratio that many of the proposed options, but even the worst is well above the minimum. So, no, that doesn't really seem to be part of anyone's decision here. Anomie⚔12:06, 11 September 2025 (UTC)[reply]
Fine. In that case, I have no problem with popularity for something like this. Also, one of my greatest Wikipedia pet peeves is resistance to change. "What we have is fine" is a horrible argument, just horrible. ―Mandruss☎ IMO. 12:32, 11 September 2025 (UTC)[reply]
Did the current color set even get so much as "a popularity contest vote"? The colors for talk page templates did (Wikipedia:Talk page templates/vote). It would be unfortunate if we rejected the results of current discussions as a mere vote, if the current state didn't even get a discussion in the first place. WhatamIdoing (talk) 16:08, 11 September 2025 (UTC)[reply]
Support D (or option 6 below, with option 5 as a second choice). I don't think WP:DONTFIXIT applies here as there is an identifiable issue, even though it is of an aesthetic nature. I also wouldn't be opposed to revamping the tab design entirely, as the border still gives it a very dated feel. Chaotic Enby (talk · contribs) 17:30, 21 August 2025 (UTC)[reply]
After trying the mockups below, also support option F as a third choice. My only worry is that it might be a bit too close to the WP:CENT color. Although Option D would likely look better with a lighter border like F's. Chaotic Enby (talk · contribs) 12:54, 22 August 2025 (UTC)[reply]
One thing I forgot to consider: on blue and purple skins, blue and purple links will naturally be less readable. I added colored links to my mockups – looking at the contrasts, I now have a preference for option F over option D. Chaotic Enby (talk · contribs) 18:19, 22 August 2025 (UTC)[reply]
Looks like that would only work in Vector 2022 and Minerva. Those CSS variables don't seem to be defined in Vector, Monobook, or Timeless. Anomie⚔18:20, 31 August 2025 (UTC)[reply]
Yeah apologies that's why you define them like this: var( --background-color-success-subtle, #dff2eb );. thanks for letting me know, I didn't actually know that :) waddie96 ★ (talk)22:59, 31 August 2025 (UTC)[reply]
Option A. Tastefully understated, calming, not one of the overused blues. Like the paint in a doctor's office. Brown looks like dirt; if I see that on the walls of my doctor's office, I'm finding a different doctor. And that's how to put together a proposal, by the way. ―Mandruss☎ IMO. 07:13, 11 September 2025 (UTC)[reply]
Comment. I used Snook's Colour Contrast Check. For the uninitiated, higher numbers are better, and all values exceed WCAG 2.0 Level AA (4.50) and WCAG 2.0 Level AAA (7.00) by a wide margin. Black-on-white and white-on-black are 21.00. I'm assuming #000000 for black and #FFFFFF for white, though I can't get Firefox's color picker to verify that for text.
The examples here (as well as the current header) all specifically set color:black, overriding the Vector 2022 (and Minerva) default text color of #202122. When I toggle Vector 2022's dark mode, the current header's colors are overridden entirely (we wind up with #eaecf0 text on a transparent background (showing through black), with the colored border remaining unchanged) while the examples here are not changed for dark mode at all. Anomie⚔12:00, 11 September 2025 (UTC)[reply]
There shouldn't be a problem if just the colors are switched in the existing {{Start tab}} invocation. You said I'm assuming #000000 for black and #FFFFFF for white, though I can't get Firefox's color picker to verify that for text, so I was providing more information on the text color used for the header and why it's actual black rather than Vector's normal dark-grey. Anomie⚔13:57, 12 September 2025 (UTC)[reply]
Comment. Revised table. For the purposes of contrast checking, I think we need to look at the paler of the two shades in each option sample. For the previous table, I was looking at the darker shades. I'm just correcting the record; the conclusion is the same: Contrast is not an issue.
Comment. This is not a suggestion for proposal expansion (I know better). But I note that there's a lot of brown on the site; just look at the top of an article talk page, for starters. I can imagine the output of this proposal becoming the new en-wiki color, thereby conveying a certain site-wide cohesion—like there is actually somebody in charge of the whole site; like there is some coordination happening. If it's good at village pump, it's good anywhere. One could argue that the brown does exactly that; problem is, it's a terrible color choice. And the browns aren't the same, anyway.As I understand it, this is what CSS is for. With a virtual flick of a switch, we should be able to change en-wiki's color site-wide. Anything less is 20th century technology. The uses for that switch are yet to be imagined, but I'm certain they would exist. ―Mandruss☎ IMO. 02:41, 13 September 2025 (UTC)[reply]
I think it would be nice if the Villages Pump had different color schemes to more easily distinguish them, but for the record, the heretofore-besmirched "yellow-brownish color" is actually a quite venerable piece of Wikipedia design history: the palette used by talk page headers and message boxes is called "ClockworkSoul's Coffee Roll" and it dates to a big RfC from some twenty or so years ago (prior to that, there was no unified formatting for the headers at all, and they were just all totally different styles and it looked like puke). jp×g🗯️19:20, 14 September 2025 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
I note none of the examples given here actually show what the header would look like. Even the one that claims to be the current color isn't, nothing in the current header uses this color. If we want to make a choice, we should probably have accurate mockups to choose from. Here's some wikitext to mockup the current coloring:
Selected tab
Other tab
Other tab
Other tab
Other tab
Other tab
This is the actual current village pump color. It uses the 50° row from Help:Using colours: "header background" as the background, "header border only" as the border, and "accent color" for the inactive tabs.
Unfortunately I can't guess at what was intended for any of FaviFake's suggestions here to mock them up similarly. Anomie⚔12:09, 21 August 2025 (UTC)[reply]
You're right. I only copy-pasted these "coloured boxes" from the pages i linked to to get a general sense of which one people would prefer. If a colour is more liked than others, say, green, we could then figure out all the specific shades of green for the border, inactive state, background, etc. I could work on creating more accurate mockups, but I think other people would do a much better job than me. I'm no colour scientist. (However, I've changed the incorrect colour you pointed out; it was intended to be more visually pleasing, but I agree it should match the current colours.)
The following discussion has been closed. Please do not modify it.
If you don't know what you're doing, perhaps you should take a step back and ask people for help before making half-baked proposals. Anomie⚔12:50, 21 August 2025 (UTC)[reply]
Excuse me? Again, my goal wasn't to propose specific colors. I wanted to see if there was consensus for changing the current colour. As I stated in my proposal, the examples were just that, examples of colours I thought looked better. FaviFake (talk) 14:10, 21 August 2025 (UTC)[reply]
An initially inaccurate summary along with suggestions that don't correspond to how the colors would actually be used doesn't sound fully baked to me. FaviFake has been doing a lot of this sort of thing lately. Anomie⚔14:33, 21 August 2025 (UTC)[reply]
I do agree there is something wanting in the current color choice. However, I'm not sure whether to support, due to a lack of discussion on which color, if any, is best accessibility-wise. A second concern is how the new header would appear in light vs dark mode, and on mobile vs. desktop. Dege31 (talk) 00:41, 3 September 2025 (UTC)[reply]
That is actually genius! But we might need to create another VP topic to gather consensus for this, I suspect it'd be much more controversial. FaviFake (talk) 17:49, 13 September 2025 (UTC)[reply]
This is the village pump header using the 50° row. That's "header background" as the background, "header border only" as the border, and "accent color" for the inactive tabs.
This is the village pump header using the 40° row. That's "header background" as the background, "header border only" as the border, and "accent color" for the inactive tabs.
Option 2
Other tab
Other tab
Other tab
Other tab
Other tab
This is the village pump header using the 90° row. That's "header background" as the background, "header border only" as the border, and "accent color" for the inactive tabs.
Option 3
Other tab
Other tab
Other tab
Other tab
Other tab
This is the village pump header using the 140° row. That's "header background" as the background, "header border only" as the border, and "accent color" for the inactive tabs.
Option 4
Other tab
Other tab
Other tab
Other tab
Other tab
This is the village pump header using the 190° row. That's "header background" as the background, "header border only" as the border, and "accent color" for the inactive tabs.
Option 5
Other tab
Other tab
Other tab
Other tab
Other tab
This is the village pump header using the 240° row. That's "header background" as the background, "header border only" as the border, and "accent color" for the inactive tabs.
Option 6
Other tab
Other tab
Other tab
Other tab
Other tab
This is the village pump header using the 290° row. That's "header background" as the background, "header border only" as the border, and "accent color" for the inactive tabs.
Option 7
Other tab
Other tab
Other tab
Other tab
Other tab
This is the village pump header using the 340° row. That's "header background" as the background, "header border only" as the border, and "accent color" for the inactive tabs.
Options A, B and D derive their color palettes from the 150°, 210° and 270° rows respectively, with the only difference being the use of "main background" for the lightest color instead of "accent color", while options C and F have unique color palettes. Here is what the header would look like using these color palettes directly (as well as the 150° row for comparison).
Option A
Other tab
Other tab
Other tab
Other tab
Other tab
This is the village pump header using the Option A palette. That's "Title background" as the background, "Title border" as the border, and "Light Box background" for the inactive tabs. On Vector 2022, blue links look like this and purple links look like this. On other skins, blue links look like this and purple links look like this.
150° row
Other tab
Other tab
Other tab
Other tab
Other tab
This is the village pump header using the 150° row. That's "header background" as the background, "header border only" as the border, and "accent color" for the inactive tabs. On Vector 2022, blue links look like this and purple links look like this. On other skins, blue links look like this and purple links look like this.
Option B
Other tab
Other tab
Other tab
Other tab
Other tab
This is the village pump header using the Option B palette. That's "Title background" as the background, "Title border" as the border, and "Light Box background" for the inactive tabs. On Vector 2022, blue links look like this and purple links look like this. On other skins, blue links look like this and purple links look like this.
Option C
Other tab
Other tab
Other tab
Other tab
Other tab
This is the village pump header using the Option C palette. That's "Title background" as the background, "Title border" as the border, and "Light Box background" for the inactive tabs. On Vector 2022, blue links look like this and purple links look like this. On other skins, blue links look like this and purple links look like this.
Option D
Other tab
Other tab
Other tab
Other tab
Other tab
This is the village pump header using the Option D palette. That's "Title background" as the background, "Title border" as the border, and "Light Box background" for the inactive tabs. On Vector 2022, blue links look like this and purple links look like this. On other skins, blue links look like this and purple links look like this.
Option F
Other tab
Other tab
Other tab
Other tab
Other tab
This is the village pump header using the Option F palette. That's "Title background" as the background, "Title border" as the border, and "Light Box background" for the inactive tabs. On Vector 2022, blue links look like this and purple links look like this. On other skins, blue links look like this and purple links look like this.
Contrary to the popular opinion, Palette 'Blue' and 'Purple' (Options B, D & F) are clearly mixing-up with the Blue & Purple links, which will make it very hard for the color blind to distinguish.
That only leaves us with 'Green' (A) and the current 'Yellow' (C). Yellow is going to be replaced, so I would prefer Green - Light Green (Option 2 in this list) since not only is it different from the existing Green 'tq' function, but also it has a tint of legacy of its 'soon to be predecessor' Yellow. Cdr. Erwin Smith (talk) 08:21, 4 September 2025 (UTC)[reply]
The proposal as written — in which an AbuseFilter would be created to forbid direct inline linking to foreign-language Wikipeda articles in mainspace — did not secure consensus. In general, commenters overwhelmingly did not concur with GZWDer's invocation of WP:ASTONISH, and found an AbuseFilter to be unnecessary overkill for the problem outlined. Some supported a more minimal version of the proposal, in which these links were discouraged in the Manual of Style; some held that the problem did not require a policy solution at all (and that, to the extent that a problem existed with misleading links, {{ill}} would suffice). For this issue, a separate proposal (with an according diminution in the severity of the proposed remedy) may prove beneficial. jp×g🗯️21:28, 1 October 2025 (UTC)[reply]
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
E.g. I am viewing Maheboob Khan, and click the link "Maula Bakhsh" which bring me to Dutch Wikipedia article. Similarly, the link "Maritim Hotelgesellschaft" in Maritim Travemünde links to German Wikipedia. This has two disadvantages: (1) It clearly violates WP:ASTONISH; (2) This does not encourage creation of articles in English Wikipedia. So I propose we should only link to foreign Wikipedia via {{Interlanguage link}} and create an AbuseFilter to prevent users from adding direct links to non-English Wikipedia in articles. GZWDer (talk) 01:56, 31 August 2025 (UTC)[reply]
Comment - This is already deprecated per H:FOREIGNLINK, which explains that you should use the inter-language link template so that the English Wikipedia article for it shows up as a redlink which is accompanied by a smaller bracketed link to a foreign language article. I've gone ahead and fixed the issue with the article.--JasonMacker (talk) 03:13, 31 August 2025 (UTC)[reply]
I was surprised to see this, because it's been officially discouraged for years. @GZWDer, do you really mean to be asking if someone would figure out how many of these errors exist and fix them for you, or were you just trying to get a rule written down, even though nobody will read it? WhatamIdoing (talk) 04:53, 31 August 2025 (UTC)[reply]
WP:AFD is neither a policy nor a guideline. WP:RFC is neither a policy nor a guideline. WP:BRD is neither a policy nor a guideline. WP:5P is neither a policy nor a guideline. WP:TE is neither a policy nor a guideline. Editors want to do the right thing, and they don't require good advice to say "policy" or "guideline" at the top of the page to do the right thing anyway. WhatamIdoing (talk) 20:13, 31 August 2025 (UTC)[reply]
Not sure if interwiki links are explicitly "deprecated" by H:FOREIGNLINK, but the ill template is the best practice and avoids the issues raised. What gets tricky is edits such as Special:diff/1308072402, which places the link somewhere a template may break things. CMD (talk) 05:21, 31 August 2025 (UTC)[reply]
Oppose per Thryduulf. We shouldn't get in the way of adding links to other Wikipedias when relevant. Of course, I don't have any objection to banning links like the one you propose (I agree with your references to ASTONISH and RED), but if we go creating an abuse filter, it won't be able to distinguish between good and bad. Nyttend (talk) 09:51, 31 August 2025 (UTC)[reply]
Oppose. This does not seem to be a big enough problem to justify an edit filter, which can only be edited by a few people and needs testing. The use of {{Interlanguage link}} is already listed as best practice by H:FOREIGNLINK and it doesn't matter a bit whether it is called a policy or a guideline. What matters is that it's a good idea. Phil Bridger (talk) 10:25, 31 August 2025 (UTC)[reply]
Comment I like this idea but I'm not exactly sure what is being proposed. My complaint is that articles should be internally linked to internal wikipedia articles. What I mean is that English wikipedia articles should only link to other English wikipedia articles. Logoshimpo (talk) 11:05, 31 August 2025 (UTC)[reply]
We also link to Wiktionary and Wikisource. We don't do this very often, so you might not have seen it, but one hardly wants to dumb down our writing ("but readers won't know what that word means!"), and sometimes a link to the dictionary definition makes a good compromise between brilliant prose and helping readers understand it. Wikisource links tend to be for non-notable historical documents ("issued the 1789 proclamation for the election") or in a list of works (* "The Bluebell" by Anne Brontë). WhatamIdoing (talk) 20:22, 31 August 2025 (UTC)[reply]
I'd support upgrading a slimmed-down version of H:FOREIGNLINK to guideline status or adding it to the MOS, but I strongly oppose an addition to the AbuseFilter as overkill for a really minor problem. Toadspike[Talk]17:57, 31 August 2025 (UTC)[reply]
Thanks, I missed that. We should consider upgrading "may be helpful" to "should be used" based on the strong preference for the Ill template here and elsewhere. Toadspike[Talk]14:07, 9 September 2025 (UTC)[reply]
Oppose articles in other language Wikis are useful in the absence of an English article since translation programs, however flawed they are, are available and better than nothing.--Wehwalt (talk) 19:56, 31 August 2025 (UTC)[reply]
That's exactly the role of {{ill}}: it does give a bluelink to the existing article in the other language, explicitly identified by what language it is, but it also has a redlink to the enwiki article. That means readers can immediately read (and decide if they are able to read) but there's also a tracked inbound link and an easy route to creating the article (for example, de novo or by translation). DMacks (talk) 02:14, 1 September 2025 (UTC)[reply]
Oppose, seems to already be covered by the MOS and Help. No need for more instruction creep, and there are potential reasons to allow such links. —Locke Cole • t • c00:26, 2 September 2025 (UTC)[reply]
Oppose. there are many times when linking to a non-English Wikipedia entry is actually the best option, as we don't always have corresponding articles. The template is the best solution, but adding an abuse filter seems unnecessary. Firsfron of Ronchester00:45, 2 September 2025 (UTC)[reply]
Oppose abuse filter; per Toadspike, I would support strengthening of language at MOS:IWL with more precise directions for the use of {{ill}}. In my opinion, {{ill}} should always be used when linking to a non-English wiki. Wrackingtalk!01:59, 2 September 2025 (UTC)[reply]
Except in rare cases, it's my impression that if {{ill}} isn't used, it's not for a lack of directions. It's because the editor didn't know that the option existed, and they'd be happy to have someone add it for them. If we could find a way to locate 'missing' uses of the template, and had a volunteer to fix them, then I would expect that to be welcome assistance. WhatamIdoing (talk) 02:24, 2 September 2025 (UTC)[reply]
Fair enough. I agree that editors not knowing about {{ill}} is probably a primary cause of this, and a way to locate 'missing' uses of the template would be great. Wrackingtalk!02:37, 2 September 2025 (UTC)[reply]
{{ill}} is also a real pain to use. Highly non-intuitive. I have to consult the documentation every time I have to use it. Usually takes a couple of goes to get it right. Hawkeye7(discuss)02:43, 2 September 2025 (UTC)[reply]
+1 all of this. I think something like {{ill|langcode:article}} would rock, exactly matching the style of [[:langcode:article]] interwiki links (and the natural extention of piping, as {{ill|langcode:article|displaytext}} for [[:langcode:article|displaytext]]). Or {{ill|:langcode:article}}, which probably makes it trivial to program (a "if first parameter has leading colon, parse off the first colon-delimited string and push it into the second parameter" wrapper converts it directly to the currently-handled syntax). DMacks (talk) 02:57, 2 September 2025 (UTC)[reply]
I would object to introducing such complexity across every use of this template when most of the usages probably won't use this complex feature (complex as it involves string operations). How about instead introducing a new template that uses this syntax? Aaron Liu (talk) 01:05, 3 September 2025 (UTC)[reply]
Nearly all uses of the template link to a single language code, but the template is optimised for multiple languages. So we can have things like: {{ill|Charles Darwin (botanist)|lt=Charles Darwin|fr|Charles Darwin|de|Charles Darwin|es|Charles Darwin}}. This illustrates the difficulty remembering how it works. The first guess of most users would be {{ill|fr|Charles Darwin}}. That is wrong; the English text has to come first. And while the editor might expect the next parameter to default to the display text, this actually requires |lt=, an abbreviation I'm not aware of being used anywhere else. Hawkeye7(discuss)01:43, 3 September 2025 (UTC)[reply]
If I were writing the parameters from scratch, I'd have chosen something like {{ill|target=local link|text=display text|lang=code|article=other wiki article|lang2=code|article2=other other wiki article}} (e.g. {{ill|target=London|text=Capital of the United Kingdom|lang=cy|article=Llundain|lang2=fr|article2=Londres}}) as those are names and ordering that intuitively make sense to me. Whether they made sense to anybody else I'm not sure but the ordering seems to match what others are suggesting. I don't have a clue how easy this would be to program. Thryduulf (talk) 03:41, 3 September 2025 (UTC)[reply]
I don't see why that means we can't have a lang alias for just the first language.I agree that "lt" is weird. I'd use display, text, or something. Aaron Liu (talk) 16:25, 3 September 2025 (UTC)[reply]
Can't an edit filter not just disallow an edit, but also tag an edit? Not sure how hard/easy it is to add a custom tag, but if there were a way to filter recent changes to show edits that added an interwiki, it might make what you're thinking of easier to track. =) —Locke Cole • t • c04:31, 2 September 2025 (UTC)[reply]
Answering my own question, but yes, from WP:EFBASICS, denying altogether is an option, but so is warning, tagging, or simply logging. Warning might not be a bad option, if the warning is customized to let the editor know about the interlanguage templates, it could be both educational and a way to remind editors in case they forgot. —Locke Cole • t • c04:44, 2 September 2025 (UTC)[reply]
I did a search and found that this was an edit filter before (780); it was disabled in 2016 by MusikAnimal (Too infrequent and for the good-faith edits I'm not too happy with even throwing a warning) Also, I left a note at WP:EFN to alert watchers of this discussion.Wrackingtalk!05:27, 2 September 2025 (UTC)[reply]
Correcting myself. It seems 780 (hist·log) was meant to catch attempts at connecting different-language, same-topic articles via a link at the bottom of the article (also called interlanguage linking); this is now handled via Wikidata. The issue we're discussing here is the in-text linking of non-English wiki articles instead of using {{ill}} template (per MOS:IWL, WP:ASTONISH). Wrackingtalk!05:42, 2 September 2025 (UTC)[reply]
Oppose per WP:CREEP and WP:IAR. Note that there are Wikipedias for Simple English and Scots which would not be especially astonishing. Fixing up such usage with templates or whatever is routine work for gnomes. Andrew🐉(talk) 05:42, 2 September 2025 (UTC)[reply]
I disagree - anytime a link sends the user outside en.wikipedia.org this should be clearly messaged before the click is made. There's no reason to have exceptions to this principle. (I for one would find it very astonishing to find myself at the Scots(?) wikipedia w/o prior heads-up). Regards CapnZapp (talk) 08:12, 2 September 2025 (UTC)[reply]
Comment What does "deprecate" mean? I thought this was already discouraged. I don't think trying to actively prevent users from direct links is useful. Generally, spending effort making it hard or impossible to do wrong is futile; we should instead trust users to do the right thing. We can always revert/admonish/ban mistakes and errors after the fact. Discouragement should be sufficient. Does this mean I'm opposing? Then so be it. If this proposal's "deprecation" includes a suggestion to make sure our discouragement is clearly communicated, however, I'm in support. CapnZapp (talk) 08:08, 2 September 2025 (UTC)[reply]
Even if you considered it "already discouraged", there are still many such links existing and should potentially be replaced with templates. GZWDer (talk) 12:59, 2 September 2025 (UTC)[reply]
GZWDer That's not the proposal discussed here? Certainly not ALL such links should be replaced. When context makes the out-of-English-Wiki link obvious, {{ill}} is less necessary. {{ill}} is less desirable on pages with very many links. So if you want to discuss how to find them so you can manually convert them, go ahead, nothing is stopping you. Cheers CapnZapp (talk) 11:25, 3 September 2025 (UTC)[reply]
Declaring something to be unwanted doesn't help us find and fix the problems. I realize that since I spend so much time working on policies and guidelines, it surprises people to hear me say it, but Wikipedia:Nobody reads the directions. This is just the reality we work in. It often takes two years for editors to notice changes even to the highest-traffic policy pages. Writing down the answer is IMO good, and it's helpful to the rare person who goes looking, but seriously: Policy and guideline pages are not magic pixie dust. Not one of us has actually read them all. Need proof? This whole discussion began because someone thought we needed a rule that has already been documented in at least two guidelines and one help page for years.
WhatamIdoing First off, maybe you're responding to GZWDer and not me? (Your first sentence appears directed at me; your last at them) Anyway, of course nobody always read the rules. That doesn't mean we should always (or even often) back up the rules with things like edit filters that physically stop editors from breaking them. Is this a case where strong measures are warranted? I say no. Yes, I've found cases where an "invisible" off-en-wiki link was inappropriate, but... then I fixed it. This is not on par with, say, how we ask IP editors to solve a captcha before they can add external links to articles. CapnZapp (talk) 11:30, 3 September 2025 (UTC)[reply]
I would be happy to have stronger wording that discourages linking to other Wikipedias by means other than {{ill}} and would support some project to systematically search and eliminate such links (for example, insource:/\[\[\:de\:/ helps search for German Wikipedia links; I also use CSS to underline these links so I notice them more easily), but I can imagine some places (like tables where the linking is explained outside of the table) where they are appropriate, so I hesitate to support this as written. —Kusma (talk) 10:21, 2 September 2025 (UTC)[reply]
Support in principle. This should not be blocked by an edit filter, but if an EF can flag and/or log such additions so they can by fixed by the gnomishly inclined, that would be great. older ≠ wiser11:46, 2 September 2025 (UTC)[reply]
Playing around with the insource: search code above, it looks like this might affect something on the order of 1% of articles (~70K articles). If we assume (for nice round numbers) an average of 10 edits per article, that suggests that it might tag one edit per day. Would 1–10 edits per day be worth flagging? Is anyone here committing to watching for and fixing the flagged edits? WhatamIdoing (talk) 17:53, 2 September 2025 (UTC)[reply]
This is definitely something I would watch for. I already use {{ill}} quite a bit in normal copy-editing when I come across underlinked articles or articles with existing non-enwiki links. Wrackingtalk!20:29, 2 September 2025 (UTC)[reply]
If an article change on my watchlist was flagged, I'd likely check it out. I'm not sure I'd going hunting them down in other articles. older ≠ wiser10:19, 3 September 2025 (UTC)[reply]
Opppose, looks like we have enough guidance already, and to physically block with edit filters is overkill. I'd rather see a bot that converts bare links to {{ill}} as a solution. -- GreenC18:22, 2 September 2025 (UTC)[reply]
Would you be OK with the an edit filter for the purposes of warning (to let the editor know, or at least remind them, of the template method of linking in article-space) or tagging the edit? —Locke Cole • t • c18:33, 2 September 2025 (UTC)[reply]
Oppose Mostly a non-problem; such links are very rare. They appear in a different color from en links, which mitigates the astonishment problem. No need to add more rules to ban a rare but occasionally useful tool. --Trovatore (talk) 18:46, 2 September 2025 (UTC)[reply]
I think this may be due to a skin. Non-enwiki links appear normal blue to me, so opening them and landing on a non-English page is astonishing. Wrackingtalk!20:10, 2 September 2025 (UTC)[reply]
Hmm. I use Monobook with a couple of customizations, but I don't think either of them affects this behavior. Maybe we could make the different color the default? --Trovatore (talk) 20:48, 2 September 2025 (UTC)[reply]
Comment on {{ill}}. I wasn't really familiar with this template, but I just looked it up, and to be honest I'm not convinced it's a good solution. Apparently it auto-converts the link to an en.wiki link when an article of that title is created. The problem I see with that is that there's no way of predicting in advance what the en.wiki article will be about. If, say, the title is a false friend, or just a different meaning, then all of a sudden you have a link that goes to an inappropriate article, and there's no human intervention to notice it. In general I think foreign-language links are not such a bad thing as some people seem to think. We should give readers credit for being able to deal with seeing stuff they can't read. It's not like they'll be in a situation they don't know how to deal with. Either they can read it, or they can't read it but they know they can't. In the latter case, they either try to find some way of understanding it, or they understand that this link is not useful to them, and no big deal. --Trovatore (talk) 18:54, 2 September 2025 (UTC)[reply]
I am a frequent user of {{ill}} and I love it. Indeed it requires some care to prevent wrong links, but so does just wikilinking a word in the article. The invisible automatic changing to an enwiki link is followed up by a bot edit that will show up on the watchlist.
The main downsides of direct interwiki links are that they are almost the same colour as enwiki links so there is no warning where you'll end up (I fix this in my user CSS by adding underlines), and that the links do not turn from red to blue when a suitable enwiki article is created, so they tend to stay in articles despite better targets being available. —Kusma (talk) 20:07, 2 September 2025 (UTC)[reply]
It really seems like this is more a problem with the default skin than it is a problem with direct interlang links. Could we get in a request to make them more distinct in the next update? --Trovatore (talk) 20:58, 2 September 2025 (UTC)[reply]
I don't know what interwiki links look like in the default skin (I use Monobook). Changing the link colour won't make people notice when an article matching the foreign one has been created though. —Kusma (talk) 21:09, 2 September 2025 (UTC)[reply]
I also use monobook and it comes out in light blue, whereas en.wiki links come out in dark blue.
True about the article-creation issue, but again, I don't see the foreign links as so bad, so this doesn't seem like a deal-breaker to me. The link can be upgraded in the normal review process. On the other hand links to the wrong article are bad; those are actual errors, not just a missed opportunity to link an article in English. --Trovatore (talk) 22:05, 2 September 2025 (UTC)[reply]
Depending on lighting conditions, I don't see the difference between the two shades of blue without effort. The"wrong link" issue you mention is something that can happen with every red link on Wikipedia and is not related to interlanguage linking. —Kusma (talk) 22:27, 2 September 2025 (UTC)[reply]
(edit conflict) There's already T333577, which is likely to continue being ignored. As for colors, looks like the default colors for unvisited links are
The problem I see with [auto-conversion of ill's by the bot] is that there's no way of predicting in advance what the en.wiki article will be about... all of a sudden you have a link that goes to an inappropriate article
You say you weren't familiar with the template, so as someone who has added hundreds of interlanguage links and seen many thousands more, I can say that this has not been a problem, or at least, no worse than people adding direct wikilinks to the wrong article. Both occur (rarely); both are annoyances; neither is a valid reason to deprecate ill's or autoconvert wikilinks. If there is a real problem with interlanguage links, it is that since by definition the English article does not exist yet, the ill creator has to invent an English title for the red link, and it can happen that two people each create an ill about the same thing with two different red link titles for the future English article. That does happen sometimes, but it is more of an inconvenience than a problem, analogous to two editors creating direct red links to the same topic and calling it two different things. If and when an English article is eventually created from one of the two ill red links, it usually gets shaken out eventually, either by the other one getting fixed, or becoming a redirect, and then eventually Cewbot comes along and culls it. So, you needn't worry too much about this case, as it is not a serious problem, and we needn't consider it as part of this Rfc. Mathglot (talk) 23:10, 7 September 2025 (UTC)[reply]
Comment - So if this is enforced by an abuse filter, will and/or how will this affect edit summaries that use those links? Usually for translation attribution these links are needed, so if this is disallowed how will this be done? The {{Ill}} template does not work in edit summaries (or any template I'm pretty sure). This could also very well be fixed in the abuse filter itself and I just don't know it, but I'm curious regardless. Sophisticatedevening(talk)19:36, 2 September 2025 (UTC)[reply]
Oppose – This is basically a 'best practices' issue, but forbidding one practice is not the best way to encourage a better one. I share your concerns upon clicking a blue link that takes you unexpectedly to nl-wiki—I don't like that, either. I am also a huge supporter of {{interlanguage link}}, so we see eye-to-eye there as well. Nevertheless, I must oppose your proposal; it is not necessary, the remedies are draconian, and there are better ways to deal with this. Additionally, you haven't considered some of the possible reasons for keeping them around, or alternative remedies. I also oppose it on the grounds of instruction creep; existing guidelines suffice for this. The fact is, that interlanguage links are part of Wikipedia, and there are legitimate uses of them. You did not mention their use in citations, for example. There are other situations where they might be useful, for example when the link is called out in running text as a foreign link and therefore the ASTONISHMENT goes away; e.g., at Kemperplatz#Sources or any of these articles.[slow link] Presumably you would make an exception for those, and there may be other cases like that as well. As has been said, many users of direct interlanguage links may be unaware that template {{ill}} exists, and forbidding use of the former is not the best way to promote the use of the template; that should be achieved with the carrot, not the stick. Some here have mentioned difficulty in using the {{ill}} template, and to the extent possible, that should be handled by improving the template doc. One positive step that could be taken that I have not seen mentioned thus far, is to trap new interlanguage links as they are typed and pop up a dialog box, similar to the disambig popup dialog that appears in edit mode when you type a link that is a disambig page. A solution like that would probably go a long way to minimizing growth of this problem, and WP:AWB could find and assist in repair of such links. Forbidding them is overkill, and not necessary. Mathglot (talk) 22:49, 2 September 2025 (UTC)[reply]
I don't want to click on your expensive link, but I'm curious about how many articles were found in that search.
Could we do a bot run to tag the links (skipping anything inside a template or otherwise feeling like it might break something)? It wouldn't necessarily have to be visible, but if we could get a group together to sort through these, like Wikipedia:WikiProject Disambiguation handles dab links, then we might be able to solve the problem. WhatamIdoing (talk) 00:35, 3 September 2025 (UTC)[reply]
There were 144 results but it is a lower bound, and probably only a small minority of the total, as I was looking for a particular pattern likely to yield on-page translation attributions similar to the Kemperplatz case. That said, every little bit helps, I suppose. (P.S., that search can be slow, but I don't believe it counts as expensive, as it includes a double-quoted insource term, which works off an index and is described as "ideal" here. That might be a good question for VPT, though.) Mathglot (talk) 01:07, 3 September 2025 (UTC)[reply]
Then I think it's missing most of the articles, because a simple search on insource:/\[\[\:de\:/ turns up about 20K articles, just for the one language. WhatamIdoing (talk) 01:38, 3 September 2025 (UTC)[reply]
It's only part of Mathglot's argument, but yes, I don't think there are many articles that link to other-language Wikipedia articles qua articles. And many that do should not – Kemperplatz § Sources treats a German Wikipedia article as a source, in violation of WP:CIRCULAR. Such uses should be replaced with {{translated page}} on the talk page and possibly a maintenance tag like {{expand language}} on the article. jlwoodwa (talk) 04:16, 3 September 2025 (UTC)[reply]
No, this discussion is not related to only those ~144 articles; the 20K for dewiki (and other non-enwiki) is what we're talking about. If you click the "slow link", it shows articles that link to non-enwiki articles andself-reference those articles, e.g., The German Wikipedia article [[:de:Konkordienbuch]] (at Book of Concord).
For Spanish, insource:/\[\[\:es\:/ returns 13K results. Not all are especially problematic—I wouldn't consider eswiki links in citation templates to be high-priority, e.g., |publisher = [[:es:Universidad Empresarial Siglo 21|Universidad Empresarial Siglo 21]] (at Jimmy Wales). Here is an example of a cleanup I did at Mexico after finding eswiki links via that search pattern. Wrackingtalk!05:36, 3 September 2025 (UTC)[reply]
Comment. I believe {{ill}} is expensive, and so one use case for other solutions I would bring up is possibly when the sheer number of links rule out using ill? CapnZapp (talk) 11:35, 3 September 2025 (UTC)[reply]
If seeing something written in a foreign language without being warned in advance is astonishing then I don't know what is non-astonishing. Some people must go through their whole lives being astonished. Phil Bridger (talk) 11:59, 3 September 2025 (UTC)[reply]
I don't think anyone here is saying seeing something written in a foreign language is astonishing. What many might find astonishing (or confusing) is to click on a wikilink that looks identical or nearly so to any other ordinary wikilink and being taken to an article in another language (and with the concomitant navigational framework in the other language as well). older ≠ wiser14:43, 3 September 2025 (UTC)[reply]
Comment I see several comments above discussing how to find the problematic links. Here are some possibilities, in approximate order of escalation:
People manually do searches like insource:/\[\[\:es\:/ for every language code.
Someone could re-enable CW Error #68 for enwiki (cf. the report for eswiki), which interested editors could use to find pages to clean up.
A log-only edit filter could be created, and people could use that log to find edits to follow up on.
An edit filter could add a tag to edits, without warning or preventing them. Interested editors could watch for edits with the tag for review.
An edit filter could warn users against adding such links, possibly teaching them about {{ill}}.
An edit filter could prevents edits that would add such links.
Seems like there's not much support for the last, and probably not a whole lot for the second-to-last either. But some arguing against seem to be overlooking the earlier options. Anomie⚔14:06, 3 September 2025 (UTC)[reply]
You missed out the most likely scenario - that people spend far more time than it would take to enact any of those proposals on discussing the "issue" here and end up being too exhausted to do anything about it. Phil Bridger (talk) 14:23, 3 September 2025 (UTC)[reply]
Good list @Anomie. Another possibility is to more clearly differentiate links to other language wikis. Unfortunately, as you've said, T333577 doesn't appear to be going anywhere. But perhaps, to also address concerns about {{ill}} being 'expensive' as well as cases where the link shouldn't change when an English article is created, there might be another template specifically for creating stable links to other language articles with color coding or other visual indicators. Perhaps include mention of the language, such as (German article: Bundestag) somewhat similar to how {{langx}} displays the language label. older ≠ wiser15:13, 3 September 2025 (UTC)[reply]
Having the link show a different color when you happen to read the article doesn't help an editor find articles that have this problem. I like the idea of re-enabling the WP:CHECKWIKI report. It'd probably be a good idea to find a couple of editors who are willing to work on the list before running it frequently. WhatamIdoing (talk) 16:58, 3 September 2025 (UTC)[reply]
Maybe if the color were more distinct it wouldn't be so much of a "problem". I'm still not convinced there's anything wrong with interlang links per se. --Trovatore (talk) 18:59, 3 September 2025 (UTC)[reply]
I'm not sure that any amount of fiddling with the color will work. On the one side, you have people saying "It must be different – really, really different, so it's super obvious that it's weird and different and not normal". When we do that, then other people appear and say "Now it doesn't look like a link! Nobody knows they can click on it. It just looks like someone randomly decided to put {green|purple|orange} text in the middle of an article for no reason at all!" (And most compromises are met with "It's basically unreadable in dark mode".) WhatamIdoing (talk) 19:03, 3 September 2025 (UTC)[reply]
Looking at Anomie's table, I think the Monobook dark contrasted with the Timeless light would work pretty well. Dark mode looks atrocious to me but I don't see that this would be any less readable in dark mode than dark mode is anyway. --Trovatore (talk) 22:00, 3 September 2025 (UTC)[reply]
Again: no amount of fiddling with the colors helps editors who are starting at the Main Page figure out which articles contain potentially unwanted links to non-English Wikipedia articles.
What's wanted – assuming we're trying to fix this problem – is "Here is the list of articles that need {{ill}} added to them". This is not a common enough problem that we can change the color and then tell people to click Special:Random a few hundred times and manually scan the page for the color change. WhatamIdoing (talk) 17:45, 14 September 2025 (UTC)[reply]
Oppose an edit filter (way too blunt), but support codifying {{ill}} as best practice, which is already de facto the case but isn't strongly codified yet. Indeed, guidelines should follow and codify community practices. It still leaves leeway for edge cases or people not knowing the guideline, as it would only mean that regular interlanguage links can be converted to {{ill}} (when reasonable) by later editors. Changing link colors to better distinguish interlanguage links is also a good thing, although such a visible change should probably be a proposal of its own. Chaotic Enby (talk · contribs) 14:08, 7 September 2025 (UTC)[reply]
Oppose all. The English Wikipedia already has a severe lack of information about non-anglophone countries, and any form of this proposal would just make matters worse. James500 (talk) 05:14, 10 September 2025 (UTC)[reply]
MOS is not something even supposed to read all of to understand. It's uncohesive and does not need cohesion, so I don't see how any of the proposals here would diminish understanding. Aaron Liu (talk) 14:21, 1 October 2025 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Bot to make list-defined references editable with the VisualEditor
Proposal: a bot that replaces {{reflist|refs=...}} with <references>...</references>
Rationale: The reason is that there are issues with the list-defined references that are based on the template {{reflist}}. The VisualEditor can't parse references that are inside templates. This comes from a design decision, it has been like this for over 10 years and developers apparently don't want to change it (see T52896). It means that in the VisualEditor, list-defined references that are within a reflist template can't be modified, and are not displayed (you instead get the message "This reference is defined in a template or other generated block, and for now can only be previewed in source mode"). So when using the VisualEditor, you can't visualize these references and you have to switch to the source editor in order to manipulate these references. However, the parsing works with list-defined references that use the <references> template. Here is an example of an edit that makes the replacement.
One more important benefit I just discovered: references within <references> can also be parsed by Wikipedia's translation tool, unlike those inside reflist. Which means that list-defined references within <references> are not removed by Wikipedia's article translation tool, and are instead properly converted to the corresponding reference format in the target language.
Technical details: This proposal is not about replacing all instances of {{reflist}}, only some of those that have the parameter "refs", which represents more than 55,000 articles. Replacing {{reflist|refs=...}} with <references>...</references> does not affect the rendering of the references (outside the VisualEditor) if the reflist only has a parameter |refs=. The reflist template can have some other parameters, like |colwidth=. One possibility is to apply the change if |refs= is one and the only parameter in the reflist template. This is safer and should still cover most instances of the problem. Another possibility would be to have a more sophisticated bot that can handle reflists with the parameter |refs= and some other additional parameters, which would allow for more replacements.
Previous discussions:
There was a long discussion in Wikipedia talk:Citing sources on this a few months ago. The discussion was initially about deprecating list-defined references (which didn't get consensus), and then switched to replacing {{reflist|refs=...}} with <references>, here of one of the paragraphs of the closing comment:
"There was 2:1 support in favor of deprecating {{reflist|refs=}} and replacing existing instances. I updated the linked documentation pages to do so. Someone will need to write a bot and follow the procedure at Wikipedia:Bots/Requests for approval. At least one editor had concerns about bots making incorrect edits. There was also discussion of whether or not such changes should be bot-flagged so they don't show up on watchlists, and whether it should be required that other changes be made at the same time. The bot approval process is designed to take these concerns into account and balance them against the proposed benefits; that would be the place to raise them. (It might be helpful if whoever makes the requests notifies the editors who participated in this discussion.)"
Support. This maintains list-defined references in that article while solving other problems. I think that this discussion is overkill, but BOTREQ frequently wants to make double-extra-certain that a bot task won't need to be reverted later. WhatamIdoing (talk) 22:16, 3 September 2025 (UTC)[reply]
For clarity: This will affect less than 1% of articles, and it will change this:
I have two questions: (a) Is the rendered result is perfectly identical what's being replaced? (b) Will it interfere with anything else contained in {{reflist|refs=}}? I employ HTML comments amongst list-defined sources for myself and others and want to be sure any bot changes won't strip or modify them. Thanks, all. — Fourthords | =Λ= |23:01, 3 September 2025 (UTC)[reply]
(a) Yes, it's exactly the same. AIUI the reflist template is just calling the <references>...</references> tags. (b) It shouldn't touch anything else except the exact characters planned to be replaced. (Why would it?) WhatamIdoing (talk) 23:12, 3 September 2025 (UTC)[reply]
Comment. If we are going to do something like this with the rationale that we cannot have refs inside templates, then we should more consistently examine contexts where refs are inside templates and eliminate all of them rather than piecemeal gutting our useful templates. Other templates that often have refs inside them include all of our infoboxes, {{efn}}, {{blockquote}}, and {{block indent}}. Should we perhaps discuss substing all of those? If not, why should this one context be treated exceptionally from others? —David Eppstein (talk) 23:17, 3 September 2025 (UTC)[reply]
In {{efn}}, {{blockquote}}, and {{block indent}} you generally have a text field in which you can see and edit the source code of references. It may not be ideal, but unlike for list-defined references, I don't see good alternatives and at least you don't need to switch to source editor. Alenoach (talk) 23:42, 3 September 2025 (UTC)[reply]
{{reflist}} has a field in which the source code of references appears. If VE is able to edit the source code of references in {{efn}} but not {{reflist}}, then the whole premise of this RfC (that VE is unable to edit refs in templates) would appear to be false. Are you suggesting that merely changing the type of the "refs" parameter of {{reflist}}, in the template parameter block of {{reflist/doc}}, from "String" to "Content", would allow VE to see and edit the source code of references in reflists? —David Eppstein (talk) 00:43, 4 September 2025 (UTC)[reply]
It might be able to see and edit them, but it still won't parse them so they won't show up on the "Re-use" tab when you insert a reference. --Ahecht (TALK PAGE)00:54, 4 September 2025 (UTC)[reply]
Does when I try it. Note there needs to be more than 10 references and your browser window needs to be wide enough. It also looks like Vector 2022's default settings (Medium text and "Standard" width) don't meet the "wide enough" criterion; I have to switch to Small text or "Wide" width to get it to wrap. Anomie⚔23:57, 3 September 2025 (UTC)[reply]
Hmm. Looks like the font size of the references themselves winds up the same with both {{reflist}} and <references />, but that's achieved with different CSS. The difference means that {{reflist}} applies the column-width of 30em based on the reduced font size, while <references /> applies the same 30em with the unreduced font size. Looks like T334941 exists already, although there they don't seem to have found this difference. Anomie⚔11:47, 4 September 2025 (UTC)[reply]
Is it possible to get tag-references to be responsive to more dense columns? I've found 30em far too wide in cases where short references are used. Ifly6 (talk) 00:25, 7 September 2025 (UTC)[reply]
Yeah, looks like the {{reflist}}30em is equivalent to telling .mw-references-columns to wrap on 27em because of that font-size:90% that reflist does.
On testing, even just knocking the default column width for <references/> down to 29em is enough to get us columns in Vector 2022 at standard width with the sidebars shown. Though obviously going a bit narrower makes it more likely that people with windows less-wide than the full "standard" width would still get the columns... DLynch (WMF) (talk) 01:46, 7 September 2025 (UTC)[reply]
Different order. reflist sets it on the wrapper-div that it creates, while core-references sets it on the ol that's inside the other wrapper that core uses for responsive columns. They both wind up reducing the font size that the actual references display at, but one affects the column widths and the other doesn't.
I would be fine with deprecation if the tag were sufficiently responsive for shortened footnotes. Most of the time it just picks the equivalent of |colwidth=30em when the output would save a lot of whitespace if it picked |colwidth=20em (or even |colwidth=15em) instead. Ifly6 (talk) 05:35, 5 September 2025 (UTC)[reply]
I have no idea. Replacing {{reflist}} with the references tag universally entirely would, I am under the impression, break three-column reference list formats. Ifly6 (talk) 20:25, 6 September 2025 (UTC)[reply]
Since this appears to be where the columns issue is actually discussed I'll repeat what I say below: I just implemented the {{refwidth}} thing I mentioned in the last discussion. It currently has three presets that correspond to 20em, 24em, and 27em respectively. An example of this in action is at User:Aaron Liu/sandbox#References.I had the idea after @Rjjiii also mentioned this concern in the previous discussion. For some reason I didn't see their reply, so I'll address it here: The refbegin thing is irrelevant as that isn't list-defined references. LDRs are defined in reference lists—the ones that are usually numbered and list uses of <ref></ref>—and the example based on the OSS page does not use them. See Help:List-defined references. Aaron Liu (talk) 20:40, 6 September 2025 (UTC)[reply]
Support: Although @David Eppstein is correct this doesn't solve every problem, that doesn't mean it doesn't solve a problem, and a pretty major one at that. This is a problem I run into often with the visual editor; I usually just have to change the reference format to move them out of refs to effectively edit the article. This would solve that, and only a modest # of articles would be affected, so I support it. Mrfoogles (talk) 00:01, 4 September 2025 (UTC)[reply]
Oppose. VE is broken and we should not extend the damage to the rest of Wikipedia by making our templates broken and clogging up our watchlists with bot edits as well. —David Eppstein (talk) 00:44, 4 September 2025 (UTC)[reply]
This it not completely specific to VE though: Wikipedia's translation tool somehow has a similar issue where it can't parse refs inside "reflist" and will just remove them. Alenoach (talk) 01:02, 4 September 2025 (UTC)[reply]
"VE is broken" doesn't really capture the issue here. The built-in MediaWiki references tag is how we used to do things, and the {{reflist}} wrapper is a hack workaround for a now-irrelevant issue. Templated wikitext is almost inherently impossible to parse, so mishandling of an expensive template is not a bug in VE but an inherent part of wikitext. Deprecating a redundant and useless wrapper for a built-in MediaWiki function is useful cleanup, even if VE handled it fine. Dan Leonard (talk • contribs)02:19, 4 September 2025 (UTC)[reply]
Support I'm of the opinion that we should deprecate {{reflist}} altogether for all instances where we're not using |group=, since that's the only thing where the bare tag doesn't have feature parity yet. Yes, the template allows you to specify a fixed column width, but we shouldn't be doing that anyway as the default responsive option is a more flexible and modern approach. Most of the other uses of reflist date back a decade or more to when the raw tag was much less capable. This is a good first step, and would be 55,000 more articles where editors can see an example of using the raw tag instead of the pointless wrapper. --Ahecht (TALK PAGE)00:47, 4 September 2025 (UTC)[reply]
@Dan Leonard{{reflist|group=lower-alpha}} actually formats the reference numbers as lowercase letters, but to do that with bare tags you need to do <divclass="reflist-lower-alpha"><referencesgroup="lower-alpha"/></div>. --Ahecht (TALK PAGE)18:06, 8 September 2025 (UTC)[reply]
This is something that's going to (sort of) solve itself as parsoid rendering rolls out, because parsoid is going to expose data-mw-group="lower-alpha" on the <ol>. Then wikis will be able to add their own site CSS on that attribute if they want. DLynch (WMF) (talk) 21:27, 8 September 2025 (UTC)[reply]
There are other problems with {{reflist}} than just VE compatibility, such as hiding all references if the page exceeds the WP:PEIS limit (the bare tag isn't affected by template limits, although some individual references may not render if they use a CS1 template after the limit is reached). --Ahecht (TALK PAGE)00:57, 4 September 2025 (UTC)[reply]
Support per above. Note that this proposal is only about replacing instances that define new references within the template and not all invocations of it (and even then, the fixed column width feature can be implemented through a separate templatestyles template that selects from one out of three widths). This template is being singled out among the templates that define refs because it's the most common one that would break the new subreferencing feature and changing invocations should not be very intrusive. Aaron Liu (talk) 01:39, 4 September 2025 (UTC)[reply]
Support. Seems like a sensible idea. I would strongly prefer that whatever tool or bot is used to do this should not make these edits in isolation, to avoid clogging watchlists. If this can be turned into something that's done as part of other edits, at least until the number of remaining articles to modify is much smaller, that would be best. Re the "fix VE" argument; sure, if that looked likely, but it doesn't, and there are more new VE users every day. There's no reason to make their lives harder for the sake of a principle. Mike Christie (talk - contribs - library) 02:16, 4 September 2025 (UTC)[reply]
Support deprecating {{reflist}} altogether except for instances where specific functions unique to the template are required for some reason. A lot of people, in this discussion and many others involving VisualEditor, love to use the refrain "our practices are fine, VisualEditor is broken". Even this proposal seems to think this is the VisualEditor team being lazy with this comes from a design decision, it has been like this for over 10 years and developers apparently don't want to change it. While the editor might have some bugs (the :0 ref naming scheme comes to mind), sometimes its limitations demonstrate an issue with our practices. Wikitext is essentially an unparsable language,[1][2][3] so it's almost inconceivably difficult for any WYSIWYG editor to handle the complexity of parsing <ref> calls hidden inside of a template call that is filled with conditional expressions. Not to mention how to handle that for a multilingual project where hundreds of language editions and sister projects have copied or adapted a similar wrapper. Sometimes, it's a good idea to deprecate templates that just wrap simpler basic wikitext functions. The community has shown distaste for templates that exist only to wrap basic wikitext syntax like boldface (Wikipedia:Templates for discussion/Log/2012 April 13 § Template:Bold) or italics (§ Template:Italic) and would certainly benefit from limiting use of a template that in 99% of cases just directly calls <references>. The bare Cite extension tag was how we used to use references, and {{reflist}} was only invented to wrap the tag in a <div> with columns. That became redundant in 2017 when the Cite extension got responsive design. Since then, there's almost never been a use for the template and its eleven-year reign should have ended. Instead it lives on as a zombie, mentioned in too many documentation pages and the muscle-memory of editors. As I mentioned at Wikipedia talk:Citing sources/Archive 58 § Sister projects have managed this, the Polish Wikipedia got rid of their wrapper template via a bot, and it has worked well for them. The VisualEditor is how people are learning to edit, for better or for worse, and it is crucial for this project's survival to meet our new editors with collegiality and help them productively edit the encyclopedia. Dan Leonard (talk • contribs)04:05, 4 September 2025 (UTC)[reply]
Italian Wikipedia also did a bot run to replace their {{reflist}} version [2] once there was no more need for it due to the introduction of <references responsive> in mw:Contributors (2015-2021)/Projects/Columns for references. My team (WMDE Technical Wishes) did an investigation last year (phab:T377043) to check which features of {{reflist}} equivalents across major wikis are still missing for <references>. Our main take away is basically that nowadays most features (except fore some rarely used ones and some right-to-left language specific features) are already part of <references> which many community members might not know. Johannes Richter (WMDE) (talk) 08:53, 4 September 2025 (UTC)[reply]
Thanks for the clarification! I would also support deprecating reflist, given your explanations. There could be a spin-off voting on this particular question to see if there is a sufficiently large consensus. But since it's less surgical, I expect that getting consensus would be harder. Alenoach (talk) 22:46, 5 September 2025 (UTC)[reply]
Comment, reposted from the Bot requests discussion: The monthly parameter usage report for Template:Reflist suggests that there are 183,000 articles using |refs=. It seems like any sort of replacement would need to start with a well-advertised RFC that successfully deprecated |refs=. This proposal (not an RFC) appears to be deprecating that parameter de facto, possibly without stating it explicitly. Maybe I missed it. – Jonesey95 (talk) 05:02, 4 September 2025 (UTC)[reply]
If this bot gets approval, I would just take it as given that the parameter should be deprecated, and then removed once all the substitutions are done. Otherwise we'll have to do ongoing work to remove instances that use it. This discussion is pretty visible, RFC or no. -- Beland (talk) 05:18, 4 September 2025 (UTC)[reply]
Suppport as proposed. I don't think it's a good idea to try to add unrelated tasks into the same bot, as Mike Christie has proposed. If the edits need to be rolled back due to malfunction, that will undo other useful edits, and the more tasks the higher the chances of malfunction. It would also delay and complicate the bot approval process unnecessarily. Part of the point of having a bot flag is so people can filter them out of their watchlists, to address complaints about cluttering those. So many bots are already running and making small changes, not to mention editors making small changes, the incremental annoyance caused by this run is pretty much negligible, especially considering what a tiny percentage of articles (0.78%) are affected. Also, long-term ease of use and its effect on editor retention are more important than avoiding a small one-time annoyance. I support letting the bot handle any additional parameters if they are present in, say, 100+ articles. My bias would be toward removing any customizations and going with the default rendering. For any low-frequency parameters we can review those articles manually and make sure the customizations aren't needed. I'd be happy to help with that. -- Beland (talk) 05:13, 4 September 2025 (UTC)[reply]
Supportprovided that no changes are made if {{reflist}} is invoked with |colwidth=. (Unless something is done to make <references> automatically select whatever column format that minimises its vertical space in 2022 Vector or something like that.) Ifly6 (talk) 05:18, 4 September 2025 (UTC)[reply]
I think it's better for Reflist to always be replaced as long as the |ref= parameter is present. On column widths, I just implemented the {{refwidth}} thing I mentioned in the last discussion. It currently has three presets that correspond to 20em, 24em, and 27em respectively. An example of this in action is at User:Aaron Liu/sandbox#References. Aaron Liu (talk) 15:50, 6 September 2025 (UTC)[reply]
I guess you mean specifying an arbitrary column size like |14em. To my knowledge, no, unless we implement inline styles for the <references> tag. Aaron Liu (talk) 20:55, 6 September 2025 (UTC)[reply]
Support limited to where |refs= is the only parameter in the reflist template. Like Mike Christie, I see no reason to hope for WMF improvement of this VisualEditor fault after a decade of inaction. ViridianPenguin🐧 (💬) 06:23, 4 September 2025 (UTC)[reply]
Support per above, and also support combining this work other task, if possible. A large portion of editors regularly use VE, especially new editors. This will help a lot IMO. ~/Bunnypranav:<ping>09:48, 4 September 2025 (UTC)[reply]
Support (weak). Many newer editors would benefit, and they are likely unaware of this discussion and the technical issue. This change would allow VE editors to see, reuse, and modify list-defined references. VE still would not support removing list-defined references. Also, the {{reflist}} template likely would never have been made for the current version of the "references" tag. Rjjiii (talk) 03:30, 5 September 2025 (UTC)[reply]
For what it's worth, this change happening would make it significantly more likely that we'd put time into fixing things like removing a list-defined reference. It's been low-priority because we knew that a large number of places that use list-defined references wouldn't be affected, but... DLynch (WMF) (talk) 20:48, 5 September 2025 (UTC)[reply]
This is tracked by issue T356471. I have pinged a developer to try to get some attention to it. I expect that fixing the bug for ref removal shouldn't be particularly hard, but they need to prioritize it. Alenoach (talk) 21:13, 5 September 2025 (UTC)[reply]
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)[reply]
Support per Alenoach and Dan Leonard. Compelling proposal. It seems like ideally we should get rid of {{reflist}} altogether in favour of the native syntax, but this proposal is a good first step. – SD0001 (talk) 14:08, 5 September 2025 (UTC)[reply]
Support{{reflist}} being so widespread has been a major factor in us not investing time in improving VE's support for list-defined references in general. Ideally it'd be nice to remove the template altogether, because we'd still be left with needing a complex edit when someone wants to add the very first list-defined reference to an article in VE. It also won't help with one of our most common cases of uneditable template-defined references, which is those defined inside infobox parameters, but it'd be a step towards a simpler future. DLynch (WMF) (talk) 20:57, 5 September 2025 (UTC)[reply]
(I'd specifically throw a +1 behind all of Dan Leonard's comments above, which seem spot on to me about the general difficulties of dealing with wikitext-in-template-parameters.) DLynch (WMF) (talk) 21:20, 5 September 2025 (UTC)[reply]
Support. Making it possible to edit something is always a worthwhile goal, and worth the "downside" of bot spam. (A bot is not just improving a few articles, it is improving lots of articles!) And to be clear, the |refs= parameter should be eliminated so we don't end up in this situation again. I'd even go so far as to say {{reflist}} should be a subst-only template. My complaints about {{reflist}} can be saved for another day, but for now let's solve one problem at a time. HouseBlaster (talk • he/they)22:05, 7 September 2025 (UTC)[reply]
Oppose. Fix the actual problem where it lies, don't ask someone else to put up with a workaround.
*: [WMF, stage left] — Oh, Wikipedia, dear! We have this great VE tool, but we fucked up; it doesn't play nice with LDRs. Can you pretty please change the way you have always done it with {{Reflist}}, and pull our ass out of the fire on this one? Would really appreciate it; ta very much! *: [Wikipedia] — grumble... er, well, I dunno; sometimes I think I'm just too accommodating. All right, I guess... Just this once, then. *: [WMF exits stage right, smiling slightly] *: [later...] [Wikipedia] — Oh, WMF, there you are! You know, I really hate to pester you about this all the time, but there's this little thing about VE making inscrutable numeric citation names like <ref name=":17"> instead of something mnemonic like, say, <ref name="Einstein-1905">. I know it's been barely ten years since we first mentioned it, but, um, do you think... *: [WMF] — [coughs] Er, actually, I've been meaning to talk to yo about that, but I'm late, I'm late, for a very important date... [scurries off, stage right]
I've been editing for about 20 years and have created over a thousand articles. And I like list-defined references and have been using them since I discovered them comparatively recently. But the technical basics still seem obscure and unclear. What I'm still not fully understanding is the difference between:
Having the same keyword interpreted in different ways depending on the position of a slash seems quite arcane. And I'm not aware of any way of adding the latter pair using the Visual Editor. There still seems to be a long way to go to make this simple and easy for newbies.
In 20 years of editing Wikipedia, I have never used or even noticed <cite> and am not familiar with what it might do. So, I don't understand it at all. But I guess that it's a raw markup tag which is commonly buried in templates such as {{citation}} or {{cite book}}. I suppose that you have to be a real old-timer to have been exposed to Wikipedia's fundamental primitives.
More generally, I've not done much html or xml raw coding and so the slash syntax is not familiar. But now I check on it, it appears that closing slashes are somewhat deprecated in HTML5 in void tags, especially self-closing tags.
Editors writing articles shouldn't have to understand such technical tag issues. The problem in making life simple for them is that there are far too many ways of citing references – each with their own arcane and complex syntax. This violates the KISS principle.
I see. Well, I've used those various forms of <ref> but didn't understand that there was a general pattern to the syntax – I just copied what worked elsewhere. And with list-defined references, I've been using the {{r}} template rather than <ref> so that the inline citations are succinct. For example, rather than <ref name=BBC/><ref name=NYT/>, I put {{r|BBC|NYT}}.
As others have said, this is just regular HTML tag syntax that's already used similarly in a bunch of places. If you want, you could think of it as the difference between reflist and refbegin/refend.
The latter would just mean having a way to create list-defined references inside VE, since that's the only reason to have the open/close tags, so there's room to put something inside it -- and which is used is basically an implementation detail that VE should be able to switch between automatically depending on whether there's anything inside the tag.
This would be technically trivial, but there's UX complexities around asking a user whether the reference should live inside the list -- it's not a question that really makes sense to someone who's not editing the source, after all. We should probably work out what the community of a given wiki thinks is the "correct" place for references to live, and default to doing that. DLynch (WMF) (talk) 14:22, 8 September 2025 (UTC)[reply]
The correct place for references is where they appear in the article – down at the bottom in a section called References. Full inline references are nightmarish in the source code and that's why I quickly switched to using list-defined references when I discovered them. The short footnote ({{sfn}}) found in many featured articles is similar – listing the main sources in a section called Sources and then using short tags to cite them in the text.
But getting the community to agree on a simple uniform scheme won't happen easily because of WP:CITEVAR and the hard-core vested interests. The Visual Editor should focus on one good scheme and encourage that so that the new generation of editors grows up with a more uniform standard.
While some do find reading source code tricky, that isn't really an issue for visual editor editors. The big stumbling block for list-defined references is likely that such a reference system usually requires two edits instead of one, something visual editor also might be able to smooth out if it had some way to automatically shift the reference as part of the edit saving. CMD (talk) 16:14, 8 September 2025 (UTC)[reply]
VE already does some amount of automatic shifting-around, in the form of making sure that the definition of a reused inline ref is always attached to its first usage in the article. Attaching some similar behavior to add to attach the definition into the reference list wouldn't be a stretch. DLynch (WMF) (talk) 22:04, 8 September 2025 (UTC)[reply]
List-defined references are a minority on the site; I find it easier to have single-use references inline in the text so that nothing gets out of sync if they are removed or replaced. -- Beland (talk) 21:46, 8 September 2025 (UTC)[reply]
I'm personally a fan of list-defined references, particularly for anything that's being reused. If I was making completely arbitrary changes to the wikis to enforce my own aesthetic preferences, I'd probably make it so that <ref name="foo">only worked to reuse a list-defined reference. Alas, I'm not getting consensus on that one. ;-P
More-seriously, I think that VE has been working as it has for so long that suddenly switching the default behavior would require some thought. A starting point of working out an acceptable heuristic for VE that'd make it go with the flow to match whatever style is in use in an article, rather than always doing inline refs would probably not be too controversial, though. DLynch (WMF) (talk) 22:01, 8 September 2025 (UTC)[reply]
Support. This is a really minor change that would produce major benefits with no downsides. The opposition seems to consist of polemics against VE and misunderstandings of the technical purpose of the template being replaced. Toadspike[Talk]00:47, 10 September 2025 (UTC)[reply]
Support - I'd prefer if VE would fix their own bugs, but as the devs have been pretty consistent for a decade about not supporting use cases that they don't like and there isn't a visual difference, we might as well. Several hundred of those 55000 articles are from me, and I guess I'd rather have the page more fully work in VE then keep html syntax out of the wikicode. --PresN14:57, 10 September 2025 (UTC)[reply]
Support. Yes, VE is much better than it was 10 years ago, but it still has some bugs when it comes to things embedded in other templates. Since the developers aren't fixing the LDR issue, this should be a workaround. Not an ideal workaround, of course, but one that should be effective. Plus, there is already consensus to deprecate the |refs= parameter in {{reflist}}. Epicgenius (talk) 13:17, 17 September 2025 (UTC)[reply]
^Siebenmann, Chris (2011-11-12). "(Not) parsing wikitext". Wandering Thoughts. University of Toronto. Archived from the original on 2025-05-03. I don't know how to write a formal parser for it, something based on parsing theory in order to have all of the advantages of real parsers ... unlike a traditional language, wikitext doesn't have any errors
^Dohrn, Hannes; Riehle, Dirk (2011). "Design and implementation of the Sweble Wikitext parser: Unlocking the structured data of Wikipedia". Proceedings of the 7th International Symposium on Wikis and Open Collaboration. WikiSym '11. Mountain View, California. p. 73. doi:10.1145/2038558.2038571. ISBN978-1-4503-0909-7. Moreover, the generated HTML can be invalid. The complexity of the software also prohibits the further development of the parser and maintenance has become difficult. Many have tried to implement a parser for Wikitext to obtain a machine-accessible representation of the information inside an article. However, we don't know about a project that succeeded so far. The main reason we see for this is the complexity of the Wikitext grammar, which does not fall in any of the well-understood categories LALR(1) or LL(k).
^Wicke, Gabriel (2013-03-04). "Parsoid: How Wikipedia catches up with the web". Diff. Wikimedia Foundation. Archived from the original on 2025-08-13. There is no guarantee that the expansion of a template will parse to a self-contained DOM structure. In fact, there are many templates that only produce a table start tag (<table>), a table row (<tr>...</tr>) or a table end tag (</table>). They can even only produce the first half of an HTML tag or Wikitext element (e.g. ...</tabl), which is practically impossible to represent in HTML.
Change editnotice appearance for mobile contributors
Hi all. I've started editing on my phone recently, and I've experienced the annoyance of editnotices for editors on mobile devices:
They're disproportionate to the rest of the UI and imposing
Their icons cause the text to stack to sometimes a screen's length high
So I propose improving their appearance for mobile editors with responsive web design, particularly since mobile devices constitute more than 40% of all Wikipedia readers, and growing.
The proposed changes' visual effects can be seen in the before and after screenshots below, additions to the CSS can also be seen below, and the actual changes viewed on Template:Editnotice/testcases on your desktop and mobile device by enabling the mobile sidebar gadget in your preferences (or use Chrome DevTools to simulate it on your device); it can also be perused in its entirety with the Template:Fmbox CSS at Template:Editnotice/styles.css too. My changes also include updating the colors used from static Hex to global variables, so that they automatically change with dark mode.
Instead of making the table cells in the Editnotice display: block; which is a 'quick fix', it would be wiser to convert the HTML <table> layout used in Template:Fmbox (as well as all the other mboxes) to use <div> instead, then use flexboxes (display: flex;) to get the horizontal and vertical layouts as the layout would be more responsive.
Edit notice before adaptive CSS on iPhone 380px ✕ 844px.
Edit notice after adaptive CSS on iPhone 380px ✕ 844px.
@mediascreenand(max-width:639px){/* Target smartphones */.fmbox.mbox-image,/* Stack icon and text vertically */.fmbox.mbox-text,/* Make the font size normal */.fmbox.mbox-imageright,.fmbox.editnotice-header,.fmbox.editnotice-headerspan{display:block;font-size:100%!important;width:90%;}.fmbox.mbox-imageimg.mw-file-element,.fmbox.mbox-imagerightimg.mw-file-element{height:auto;width:auto;max-height:40px;text-align:center;}}@mediascreenand(max-width:300px){/* Target tiny screens */.fmbox.mbox-image{/* Hide the icon */display:none;}}
Instead of making the table cells in the Editnotice display: block; which is a 'quick fix', it would be wiser to convert the HTML <table> layout used in Template:Fmbox (as well as all the other mboxes) to use <div> instead, then use flexboxes (display: flex;) - agree, and IMO this should be done to all other message boxes too. Sapphaline (talk) 14:58, 6 September 2025 (UTC)[reply]
@Gnomingstuff: I hear you, and I agree that editnotices are important tools. The tricky part is weighing up the cost vs. benefit. Large, heavy editnotices might reduce vandalism, but they also risk discouraging good-faith editors (lowering editor retention) — and at some point the effect on vandalism bottoms out anyway. I don't think bumping the text size or icon slightly really changes that dynamic, since the notice still takes up a lot of space. We could always experiment with making the icon a bit larger (say 60×60px or more) and nudging the text size to 105%.
Your example I must disagree with though as it's a false argument, showing one example as the status quo is a hasty generalization and false equivalence. waddie96 ★ (talk)22:26, 6 September 2025 (UTC)[reply]
@Waddie96, I wonder if you could produce a mockup image that would help people understand what you're talking about. I doubt that anybody looks at the above screenshot and thinks "You know what's really great about edit notices? Having 25% of the screen be empty white space, with a blue dot most of the way down the screen, and all my important written instructions getting smushed over to the side in small text".
I don't understand this opposition. THEYCANTHEARYOU describes situations where editors can't see or understand things like editnotices. This proposal intends to repair serious HTML accessibility issues present in editnotices, thereby making them more readable to editors who might otherwise not understand them. Dan Leonard (talk • contribs)01:16, 8 September 2025 (UTC)[reply]
The original proposal took issue with edit notices being disproportionate to the rest of the UI and imposing. That's the entire point.
The upstream systems that care about message boxes only care about ambox, hence why Module:Message box/div/doc details a plan that makes ambox (and tmbox) last in the rollout. fmbox and cmbox should be pretty safe, but either way, that's why there's a staged rollout. Izno (talk) 21:13, 8 September 2025 (UTC)[reply]
It looks to me like the stop sign is slightly bigger (taller) than the others, but I believe these details can be changed. Also, I'm looking at this on a laptop, and the appearance on mobile (=66% of traffic) is going to be more important. WhatamIdoing (talk) 17:54, 14 September 2025 (UTC)[reply]
Yes, icon size and line-height we can adjust (I believe it may be line height I did not adjust, but sized down the text. Can size it down proportionally. But main thing is the concept for now.
What I think is most important is either coming across a community developer/contributor who knows if MediaWiki core has implemented some mobile adaptations for web (I know they have an entire interface etc. for mobile apps, that's fine)? Or anyone know of someone they can ask. Otherwise last resort, I can log a Phabricator ticket, asking if this is feasible, and ensuring it won't interfere with the mobile app implementation. Let me know what you think. waddie96 ★ (talk)00:34, 15 September 2025 (UTC)[reply]
Will the icons' appearance on Wikipedia Mobile (Web) be different from Wikipedia Mobile (App)?
Asking this because I viewed those icons on the web version, and wouldn't wanna give false inputs which might confuse you.
And we're discussing the web browser mobile app version yes, (I have used the app just not enough to confidently declare "I've used the app"), because the apps parse/process/sanitize the wikitext beforehand in some way I'm sure, for example the infobox is brought straight to the top just after one paragraph of lede (same as MobileFrontend), but also it doesn't go to the Main Page, it has it's own custom main page.
Support – they do look incredibly ugly. They'd still not be good-looking, but at least the font sizes won't be all over the place. In general I think we should turn ALL editnotices into a standardised template, which has set levels of importance and makes the notices appear accordingly. Like we did for Mbox in the 2000s. But that's a lot more work. FaviFake (talk) 18:57, 30 September 2025 (UTC)[reply]
RfC: merging Wikipedia:Requests for comment/User names with AN(I)
Support as proposer. There have been three (3) archived requests in 2025, and there were six (6) in 2024. We have too many noticeboards, discussion venues, and processes; dealing with this one seems like some low-hanging fruit. We previously shut down WP:EAR and WP:N/N for disuse. At the VPI discussion, it was brought up that this might slightly discourage filing reports. I see that as a feature, rather than a bug: only two of those nine reports found consensus that the username was inappropriate, most recently over a year ago, so slightly increasing the threshold for a filing would cut down on unnecessary discussions. HouseBlaster (talk • he/they)16:16, 14 September 2025 (UTC)[reply]
Support per nom. While ANI is definitely getting a bit large, the very low volume of requests this would add isn't really an issue compared to the advantage of simplifying a whole noticeboard away. If we want to limit ANI bloat, we could move something like TPA requests away to AIV instead. Chaotic Enby (talk · contribs) 16:21, 14 September 2025 (UTC)[reply]
Oppose This will just create confusion I think. The current page is being used for when UAA has declined to block a username, but the person reporting would like a community opinion. Bringing it to AN or ANI will result in overblocking, I suspect as blocking admins may not be familiar with the detailed rules we have. Secretlondon (talk) 16:43, 14 September 2025 (UTC)[reply]
SupportWP:AN or the suggestion in the discussion below for WP:UAA. OpposeWP:ANI, for reasons similar to Secretlondon's (though I'd say the bigger problem will be the dramaboard mob not reading the rules, rather than admins). WhatamIdoing (talk) 17:39, 14 September 2025 (UTC)[reply]
Oppose. RFC/N is a specialized venue for a specialized set of cases—notably, applying a policy that many users, even experienced users, even admins, often misunderstand. The proposer hasn't presented any evidence that RFC/Ns are resulting in unjust outcomes or otherwise hindering the smooth running of the encyclopedia, just that there isn't much volume of cases and that some can be resolved through normal admin actions, neither of which is inherently a problem. Nor have they presented any evidence that AN or AN/I is better-equipped to handle such cases. If it ain't broke, don't fix it, and it ain't broke. Instead, I'd rather we better advertise the existence of RFC/N, particularly to UAA filers (who frequently report users on bases that do not justify a summary block, but might be disallowed at RFC/N if anyone bothered to file), and consider expanding RFC/N's scope to also include signature issues, which are related to username issues and are not well-suited to AN(I). -- Tamzin[cetacean needed] (they|xe|🤷) 17:46, 14 September 2025 (UTC)[reply]
Moving that "specialized set of cases" to a more widely used venue might result in more people understanding that policy better. That could result in fewer unjust accusations being made in the first place, which would support the smooth running of the encyclopedia. WhatamIdoing (talk) 18:10, 14 September 2025 (UTC)[reply]
Oppose (summoned by bot). ANI every time I drive by or am summoned to it is definitely too large, and having a specialized venue would enable admins to get to specific username requests quickly, and sort them out. I would be more open to making them a dedicated section, but I still feel like that one page for everything could have a load time impact, as well as increase the chance of edit conflicts. InvadingInvader (userpage, talk) 14:16, 16 September 2025 (UTC)[reply]
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 rap21:18, 22 September 2025 (UTC)[reply]
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)[reply]
No - it's used when the submitter thinks it should be blocked but the admins don't agree. They've all gone through UAA and been found as borderline. Secretlondon (talk) 16:40, 14 September 2025 (UTC)[reply]
I see it as a separate section of the page. Given the very few username discussions it shouldn't be a problem. The other alternative would be to create a template to use and hold the discussion on the talk page of the user. Just spitballing here. 331dot (talk) 17:34, 14 September 2025 (UTC)[reply]
Honestly, a dedicated section for deeper discussions would be quite helpful. Avoids sending editors flying from one noticeboard to another, and especially avoids the risk of ANI drama, while keeping the number of noticeboards low. I'm inclined to support that as my first choice. Chaotic Enby (talk · contribs) 17:48, 14 September 2025 (UTC)[reply]
That might necessitate renaming UAA to something else; Usernames for attention; Username reporting and discussion; something else..... 331dot (talk) 18:25, 14 September 2025 (UTC)[reply]
Yet another perfect place to change "administrator" to "administration", just like with AN/ANI. They're not pages for administrators, they're pages for the administration of the encyclopedia. ScottishFinnishRadish (talk) 14:23, 16 September 2025 (UTC)[reply]
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 rap21:22, 22 September 2025 (UTC)[reply]
It's easy to fix this in MediaWiki. There's no need to hack it via the message as it has some side effects, like the inputbox showing up again when you enter an invalid username. – SD0001 (talk) 10:06, 24 September 2025 (UTC)[reply]
I've gone ahead and implemented the inputbox as a stopgap. We can remove it if/when T404930 is resolved (just because a fix in MediaWiki is easy doesn't mean it will be fast). --Ahecht (TALK PAGE)14:15, 24 September 2025 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
Permission to create beetle articles at a pace that exceeds the normal limit
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)[reply]
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)[reply]
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 (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)[reply]
" 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)[reply]
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)[reply]
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)[reply]
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[4] 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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
Yeah, and I'd rather that admins didn't restore potential copyright violations[5] added by an editor with a history of source fraud, socking, and nationalist POV stuff, after being told they were likely copyright violations,[6], 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)[reply]
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. EF513:11, 30 September 2025 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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. BD2412T22:32, 30 September 2025 (UTC)[reply]
@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)[reply]
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 - WikipediaB33tleMania12 (talk) 22:43, 30 September 2025 (UTC)[reply]
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)[reply]
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)[reply]
Should we have an essay or something on "Jew tagging"?
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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. ChildrenWillListen (🐄 talk, 🫘 contribs) 14:30, 27 September 2025 (UTC)[reply]
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.
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)[reply]
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 [12]. 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)[reply]
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)[reply]
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)[reply]
@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.
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)[reply]
This subject has come up before. It reminds me of this piece about the importance of this information to readers:
(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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
It seems to be invented by a Wikipedia critic and basically means labeling someone as a Jew (he is a Jew or she is Jewish-American) when their religion/ethnicity doesn't have much encyclopedic value. ChildrenWillListen (🐄 talk, 🫘 contribs) 03:20, 28 September 2025 (UTC)[reply]
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)[reply]
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? ChildrenWillListen (🐄 talk, 🫘 contribs) 13:53, 28 September 2025 (UTC)[reply]
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)[reply]
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)[reply]
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 rap04:14, 30 September 2025 (UTC)[reply]
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ålk21:16, 30 September 2025 (UTC).[reply]
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 rap00:51, 1 October 2025 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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 rap03:34, 1 October 2025 (UTC)[reply]
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)[reply]
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. -- GreenC05:49, 30 September 2025 (UTC)[reply]
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)[reply]
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 [17], 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)[reply]
We have gone back and forth about mass deletions of problematically sourced stubs on supposed settlements. Generally there has been enough resistance to keep this from being done, with some few exceptions. In the case of Myanmar, however, the problem is particularly acute. Innumerable settlement stubs which are sourced either to Maplandia or to GEOnet. Neither of these I would consider a reliable source, and the detail they offer is minimal. What we have found is that a high percentage of these cannot be verified against mapping tools such as GMaps: there is nothing but forest at the location given.
I have been systematically going through reviewing similar articles in the US, where such articles were entered starting from GNIS entries. This database also presents us with issues, both in their own entries and in our interpretation of them as settlements, which you can read about in WP:GNIS. At the moment I am going through Indiana, and I estimate I'm somewhat over half done, and I have nominated over 350 articles for deletion in the year and a half I've been working on the state, and I've probably looked at twice that many articles or more. At present I appear to be the only person doing such systematic review; in the past we've had multiperson efforts directed at some states (most notably California). And I largely have to leave articles I don't nominate in their original, often poor state; there's just not time. Many articles I do nominate are kept and improved, but it takes the threat of deletion to get that work done. And inevitably we have people new to the effort who show up and want to keep everything on principle if for no other reason than that they are unaware of the problems, and it takes time to explain it all to them again and again.
I think this is a bad way to go about this, particularly where we know things are bad. It just makes more sense to start over from scratch and create non-crappy, non-stubby articles in the first place on places that we can verify rather than have to wade through each of these places and put up individual discussions on the failures. I have to hope we can find a listing that is better than what was used for this. Therefore I am proposing to delete all the Myanmar settlement stubs which have no other citation than to Maplandia and/or GEOnet. Mangoe (talk) 04:52, 30 September 2025 (UTC)[reply]
You need to give more detail about what the actual problems with Maplandia and GEOnet (in relation to Myanmar) are and link to discussions that show the community agrees with you that these are problems that deletion is required (or the best way) to fix. Problems with articles about places in a different country and/or based on different sources are completely irrelevant to this proposal yet that's what the majority of the above is about. Thryduulf (talk) 10:17, 30 September 2025 (UTC)[reply]
They are not completely irrelevant, because a great deal off the issue here is the effort actually doing the work. And I've done this already in another country (Somalia), and I never finished because it was too much work and because I felt it was more profitable to work on US locations, for various reasons. And also, frankly, because there was so much opposition in principle against the clean-up.
I will take some time and give a sample of how bad the data is. Maplandia and GEOnet are both repackagers and not original secondary sources, so they are only as good as whatever they are using, which I suspect is GNS and maybe even us. We have had some recent discussion of this here and there has been off-and-on discussion over a long period, but really the place for a discussion is here, now, because no matter what was said in the past, it's going to get relitigated here. Mangoe (talk) 14:26, 30 September 2025 (UTC)[reply]
If you want to make a strong proposal for this, then I think you'll have the most success if you start with a narrow, 100% objective, bot-detectable set of circumstances. A few examples of "See, they said it's a village, and here's the OSM and Google Map links: there's nothing there" will be necessary. You will also need to be able to produce a complete list of the articles in question.
In terms of criteria, try something like "is in this country/region, was created by this user (or in this time span), and contains only these unreliable sources". You could add other things, e.g., nobody else has added content, or it's not linked to articles at other Wikipedias. If you're uncertain that this would be accepted, then getting a declaration in Wikipedia:Reliable sources/Perennial sources that those two websites are WP:GUNREL would probably help a lot. (And if RSN surprises you by saying that it's actually reliable after all, then maybe a blanket approach isn't desirable.) WhatamIdoing (talk) 19:11, 30 September 2025 (UTC)[reply]
Edit the article on pregnancy to make it clear not everyone capable of pregnancy identifies as a girl, woman or mother.
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)[reply]
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. BD2412T01:58, 2 October 2025 (UTC)[reply]
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 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:
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)[reply]
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)[reply]
The current CC image license tags (e.g. Template:CC BY-SA 4.0) are very, very barebone, providing little information to the reuser. This would change them to the following:
to share – to copy, distribute and transmit the work
to remix – to adapt the work
Under the following conditions:
attribution – You must give appropriate credit, provide a link to the license, and indicate if changes were made. You may do so in any reasonable manner, but not in any way that suggests the licensor endorses you or your use.
share alike – If you remix, transform, or build upon the material, you must distribute your contributions under the same or compatible license as the original.
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, —Matrixping mewhen u reply (t? - c) 20:06, 2 October 2025 (UTC)[reply]
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)[reply]
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)[reply]
ambox.speedy .delete
ambox.content
ambox.style Not Codex, but is the OOUI for style icon...
ambox.notice
Option 2 ambox.notice
with 
but otherwise everything else looks good. Aasim (話す) 04:14, 11 August 2025 (UTC)
would be the most visually similar one, although 
or 
convey better the idea of looking for references in my opinion. Any of those would be fine to me.The icon in {{Unreliable sources}} also matches well with 
, if we take the rectangle being searched to represent the article rather than the sources). 
is closer visually, but could be more confusing as "question mark in rectangle" is a very common symbol and makes it less clear that the rectangle represents the article.{{Disputed}} easily gets 
.For {{Speculation}}, Codex sadly doesn't have a crystal ball yet (although I could make one in the Codex style if needed). The closest "magic woo" icons (and that's a stretch) are 
or 
.{{Current}} and {{Recentism}} can get different colors of 
.{{Globalize}} gets 
. Chaotic Enby (talk · contribs) 18:19, 15 August 2025 (UTC)
. Not good. Even rotating it 45 degrees doesn't really fix the issue: Aasim (話す) 07:00, 12 August 2025 (UTC)
(File:Codex icon edit.svg), to indicate issues that editors can solve?
(a generic tag icon) or 
(yes, it's officially the recent changes icon, but simple icons like this are very polysemic). Chaotic Enby (talk · contribs) 14:12, 12 August 2025 (UTC)
, but it goes a bit too far in the other direction. Surprised we don't have amber in the Codex or OOUI color palettes. Chaotic Enby (talk · contribs) 17:36, 13 August 2025 (UTC)
? Aaron Liu (talk) 18:28, 20 August 2025 (UTC)
.jpg){kind=small}
→ 
→ 
(but modified to have an X inside rather than an !)
→ 
→ 
→ 
→ 
. Chaotic Enby (talk · contribs) 19:34, 18 August 2025 (UTC)
as well. –LaundryPizza03 (dc̄) 16:54, 21 August 2025 (UTC)
in combination with 
. The icons do look nicer on colored backgrounds that match them, but otherwise when not on a matching color it can look a little hideous. But a hideous color that is still legible is better than un-dark-modeable colors like the white clock that cannot be changed to black as inverting would mess up the color of the hands and the stop X. And on Vector 2022 and Minerva it seems broken, I don't know why. Aasim (話す) 03:27, 20 August 2025 (UTC)
, which has a white interior and is currently in use at kowiki's equivalent of Template:Uw-ublock. –LaundryPizza03 (dc̄) 16:55, 21 August 2025 (UTC)
→ 
→ 
→ 
→ 
/
makes more sense than coloured clocks for declined/accepted requests respectively, and a pause icon is also more symbolic of "on hold" than a random yellow clock. OutsideNormality (talk) 16:30, 19 August 2025 (UTC)
(illustrative example only not a suggestion!).
Previous
New
This article documents a current event. Information may change rapidly and initial news reports may be unreliable. The latest updates to this article may not reflect the most current information. Feel free to improve this article or discuss changes on the talk page, but please note that updates without valid and reliable references will be removed.
This article documents a current event. Information may change rapidly and initial news reports may be unreliable. The latest updates to this article may not reflect the most current information. Feel free to improve this article or discuss changes on the talk page, but please note that updates without valid and reliable references will be removed.
) meshes well with the Codex signs and the proposed broom icon; it could be used for Template:Globalize if the Codex-style symbols are adopted for generic use. –LaundryPizza03 (dc̄) 17:06, 21 August 2025 (UTC)
You are invited to join the discussion at Template talk:Navbox § Rfc: Deprecation of the image and imageleft parameters. 2600:1700:6180:6290:B0E2:DAA1:CCE8:7D41 (talk) 18:27, 21 September 2025 (UTC)
