Wikipedia

Wikipedia:Village pump (proposals)

(Redirected from Wikipedia:VPROP)
Latest comment: 28 minutes ago by JasonMacker in topic Propose to deprecate direct linking to non-English Wikipedia in articles
"WP:PROPOSE" redirects here. For proposing article deletion, see Wikipedia:Proposed deletion and Wikipedia:Deletion requests.
 Policy Technical Proposals Idea lab WMF Miscellaneous 
Shortcuts

The proposals section of the village pump is used to offer specific changes for discussion. Before submitting:

Discussions are automatically archived after remaining inactive for 12 days.

RFC: Adding featured and good content status to the tagline

edit
Latest comment: 5 days ago355 comments79 people in discussion

Should the site tagline display featured and good content status in the following style?

London Beer Flood
A featured article from Wikipedia, the free encyclopedia
List of English words containing Q not followed by U
A featured list from Wikipedia, the free encyclopedia
Archaeological interest of Pedra da Gávea
A good article from Wikipedia, the free encyclopedia
All horses are the same color
From Wikipedia, the free encyclopedia

Dan Leonard (talk • contribs) 19:33, 7 July 2025 (UTC)Reply

Background (tagline)

edit

Apologies for the long text to follow but I think a detailed RFCBEFORE and implementation is necessary for such a highly-visible proposal.

There's been perennial proposals for increasing the visibility of page status, with a fair amount of assent but no proposed directions. Many editors in prior discussions have felt the topicon is too small a notice that doesn't accurately reflect the amount of work put into raising articles to featured status. Other editors think the topicons are opaque to readers, and feel that more prominence will draw editors to these backend projects.

In this most recent discussion at the Idea Lab, I proposed using the tagline-modifying style of the metadata gadget which got some assent. Aaron Liu, WhatamIdoing, and Novem Linguae were helpful in pointing me toward Lua modules and how taglines are built into the software. While it wasn't feasible then, the recent implementation of phabricator:T380122 and addition of "Project-independent assessment" to the banner shell allows us to directly get FA/FL/GA status using Lua. Dan Leonard (talk • contribs) 19:33, 7 July 2025 (UTC)Reply

Implementation (tagline)

edit

I've developed Module:Page assessment raw, a simplified version of Module:Page assessment that uses the newest features in the MediaWiki pageAssessments extension. I wanted to have a duplicate module to reduce the expensive function count (since this will be on every page) and to allow full- or template-protecting the module (for the same reason).

I think the most efficient way to implement this proposal is to fully replace the page MediaWiki:Tagline with a switch-case function to change the tagline based on the output of the Lua module: 

{{#switch:{{#invoke:Page assessment raw|get_class|page={{FULLPAGENAME}}|project=Project-independent assessment}}
 | FA = A ''[[Wikipedia:Featured articles (linked from tagline)|featured article]]'' from
 | FL = A ''[[Wikipedia:Featured lists (linked from tagline)|featured list]]'' from
 | GA = A ''[[Wikipedia:Good articles (linked from tagline)|good article]]'' from
 | From
}} Wikipedia, the free encyclopedia

This example code also uses statistical redirects (suffixed with "linked from tagline") in the same manner as Elli's additions to the current topicons. This allows us to get a good view of how often readers click on these new taglines, and determine whether they're a useful addition to the project. In the month of June, about a third of visitors came to the featured articles page through the topicon. With these new statistical redirects, we can see how many use the tagline. Of course, if this passes, an admin should fully-protect these three redirects. Dan Leonard (talk • contribs) 19:33, 7 July 2025 (UTC)Reply

Survey (tagline)

edit
Notified: Wikipedia talk:Featured articles, Wikipedia talk:Featured lists, Wikipedia talk:Good article nominations, MediaWiki talk:Tagline. Dan Leonard (talk • contribs) 20:00, 7 July 2025 (UTC)Reply
  • Support as proposer. Dan Leonard (talk • contribs) 19:33, 7 July 2025 (UTC)Reply
  • Support a small change (probably smaller than people expect, considering the banner blindness phenomenon) which could nevertheless increase new editor attraction from people curious enough to click the link. I don't really see any downsides. ~~ AirshipJungleman29 (talk) 20:19, 7 July 2025 (UTC)Reply
  • Support. Good articles being invisible on mobile – 65% of our readers – doesn't make sense. Bringing us to some parity with the web version communicates to readers that some verification and vetting effort has been made, especially with the recently increased level of scrutiny required by GAs (and much-discussed at WT:GAN. — ImaginesTigers (talk) 20:23, 7 July 2025 (UTC)Reply
    This sadly won't affect mobile users as the tagline does not appear in Minerva. It would be a good impetus for bugging WMF over at Phabricator to show the tagline though. Dan Leonard (talk • contribs) 20:33, 7 July 2025 (UTC)Reply
    @Dan Leonard: Thanks for telling me that, although it is disappointing. I assume this affects web Minerva, too? If so, do we have any statistics on how many users aren't using Minerva at this point? I'd assume the number is relatively low, and largely our most engaged user base. — ImaginesTigers (talk) 22:31, 7 July 2025 (UTC)Reply
    I don't know where to find skin usage statistics. OVasileva (WMF) made a couple pie charts at commons:Category:MediaWiki skin statistics, but they're of editors, not readers, and don't have details on where the source data is from. It does seem like there's an open task for the tagline to be shown at phabricator:T349117. Presumably if this RFC passes it can also be seen as a request from the English Wikipedia community to finish that request. Dan Leonard (talk • contribs) 22:40, 7 July 2025 (UTC)Reply
    As someone who edits exclusively from mobile, I support adding the tagline to the mobile skin. QuicoleJR (talk) 19:26, 21 July 2025 (UTC)Reply
    Wow, I have to commend you on your dedication to the project if you do it entirely on mobile. Dan Leonard (talk • contribs) 21:19, 21 July 2025 (UTC)Reply
    This seems like a different problem - wouldn't adding GA indicators in Minerva solve this? — xaosflux Talk 12:33, 9 July 2025 (UTC)Reply
    Other respondents mentioned here that mobile topicons don't seem to have any progress and community work on adding a mobile tagline would probably be easier than adding a mobile topicon, not to mention the engineering needed to have parity with tooltips on mobile. Aaron Liu (talk) 16:18, 9 July 2025 (UTC)Reply
  • Support a minor change but a positive one. Anything that (1) raises awareness of our quality content and (2) might conceivably encourage readers to contribute is a good thing. Cremastra (talk) 20:48, 7 July 2025 (UTC)Reply
  • Support taglines are harder to miss, so this does seem like an improvement. Would this also remove the topicons, or would a highlighted article end up displaying both? Paprikaiser (talk) 20:51, 7 July 2025 (UTC)Reply
    I think it's worth keeping both, at least for a trial period, to compare clickthrough rates. But maybe I'm just too addicted to pageview stats. Dan Leonard (talk • contribs) 21:00, 7 July 2025 (UTC)Reply
    For the record, I support keeping both. Topicons are cute. Paprikaiser (talk) 21:09, 7 July 2025 (UTC)Reply
  • Support per Airship, though I think the current wording is needlessly verbose. I feel it could be more impactful if it said something like "A featured article, meaning it represents the best Wikipedia has to offer" IAWW (talk) 20:55, 7 July 2025 (UTC)Reply
    @It is a wonderful world I'm not sure I understand you. If you think the suggested wording is too verbose, why are you proposing a longer version? Cremastra (talk) 21:07, 7 July 2025 (UTC)Reply
    Sorry, verbose wasn't a good word. I mean the current wording doesn't make the best use of space. Adding "from Wikipedia, the free encyclopedia" is pointless, because the reader obviously already knows this. Those words could be replaced with something different that the reader doesn't already know, like what a "featured article" is. IAWW (talk) 21:23, 7 July 2025 (UTC)Reply
    The tagline "From Wikipedia, the free encyclopedia" has been stable for a while after many thorny discussions, so I think replacing the language wholesale would be much more controversial than just squeezing in "a featured article". See the many subheadings of MediaWiki talk:Tagline/Archive 1 § "that anyone can edit". Dan Leonard (talk • contribs) 21:33, 7 July 2025 (UTC)Reply
    I agree it would probably be tough to reach consensus and it should be a separate proposal to this. IAWW (talk) 22:43, 7 July 2025 (UTC)Reply
  • Support As a drafter of a similar RfC that failed to reach consensus, I assume my !vote is no surprise... Dege31 (talk) 20:58, 7 July 2025 (UTC)Reply
    Ah, I thought my RFCBEFORE was complete. Thanks, I've added your discussion to the above list. Dan Leonard (talk • contribs) 21:16, 7 July 2025 (UTC)Reply
  • Support I think this is a better way to make the good and featured stand out. If this proposal passes, I recommend removing the topicons. I would also like to implement this change to all the vital articles as well. For example, George Washington would say A level 3 vital and featured article from Wikipedia, the free encyclopedia while an article that is neither good nor featured, but vital like Christianity would say A level 3 vital article from Wikipedia, the free encyclopedia. Interstellarity (talk) 21:07, 7 July 2025 (UTC)Reply
    I'm not sure removing the topicons is necessarily a good plan, since many eyes will skip over the tagline entirely. Cremastra (talk) 21:08, 7 July 2025 (UTC)Reply
    Vital article status uses a very different method of data management so would require a different solution. Dan Leonard (talk • contribs) 21:18, 7 July 2025 (UTC)Reply
    That can be something we can discuss here or maybe the vital article talk page to figure out what level of organization is best. I'll leave a note on the talk page to get opinions on what method is best. Interstellarity (talk) 21:33, 7 July 2025 (UTC)Reply
    Vital article status seems less important, as not only is it less transparent to readers ("is level 1 vital the least or most important?"), but also only relates to the topic itself rather than the quality of the article they are reading. Knowing that what you are reading has been through a formal review process is great to gauge the level of trust you want to give to the article, knowing that the subject has been assessed to be important, less so. Chaotic Enby (talk · contribs) 21:48, 7 July 2025 (UTC)Reply
    Beyond the technical limitation raised by Dan, Wikipedia talk:Vital articles/Archive 25#Proposal for a VA "top icon" rejected a far smaller top icon for vital articles on the basis that unlike article quality, "vital" describes the subject itself which has little use to the reader already here to learn about it. ViridianPenguin🐧 (💬) 22:49, 7 July 2025 (UTC)Reply
  • Weak oppose. Current system seems fine. Interestingly, neither icons nor tagline work on mobile web. Example: https://en.wikipedia.org/wiki/Icelandic_Phallological_Museum?useskin=minerva –Novem Linguae (talk) 21:12, 7 July 2025 (UTC)Reply
    At phabricator:T75299, JScherer-WMF explained the current roadblock in showing topicons in Minerva:

    For example, a FA/GA badge with enough context could be an interesting and valuable trust signal for a reader, similar to how warning templates are often used as distrust signals when articles are low quality. On the other hand, I assume that a "protected" badge would be of little interest to anyone who isn't logged in and actively considering contributing to the wiki.

    Another tension in the current proposal is the form of the indicators themselves. As mentioned in the VP discussions about this, there may be a low awareness of FA/GA for casual readers, and an unlabelled icon might not "onboard" casual readers into explaining what FA/GA are and why they're useful.

    While the tagline isn't currently shown in Minerva either, WMF might be more amenable to displaying it as it is likely technically simpler than showing topicons and solves the problem of an unlabelled icon might not 'onboard' casual readers. It's currently tracked, albeit stale, at phabricator:T349117. Dan Leonard (talk • contribs) 21:25, 7 July 2025 (UTC)Reply
  • Support I'm already used to seeing it with Wikipedia:Metadata gadget, and, while classes below GA are more subjective, it could be great for our readers to highlight articles that have had a formal review process. Chaotic Enby (talk · contribs) 21:44, 7 July 2025 (UTC)Reply
  • Support been waiting a long time for this one. Very much needed! --JackFromWisconsin (talk | contribs) 22:09, 7 July 2025 (UTC)Reply
  • Support for GA/FA as long as we also keep the topicons; I think the visual cue is nice. ♠PMC♠ (talk) 22:39, 7 July 2025 (UTC)Reply
    2nd on this. Topicons are still nice and useful. JackFromWisconsin (talk | contribs) 23:32, 7 July 2025 (UTC)Reply
  • Support; I agree with AirshipJungleman that it likely won't be noticed by the vast majority of users, but if one percent are intrigued and find out more about the Good & Featured processes, I think that makes it more worthwhile. I also agree with the takes that it'd be more applicable to mobile than a topicon would be, and I think it adds context to the topicons on desktop if people don't realize you can click on them. Generalissima (talk) (it/she) 22:47, 7 July 2025 (UTC)Reply
  • Support as the overdue implementation of repeated consensus for greater visibility. Like Chaotic Enby, I would never want this expanded to other article classes because many (myself included) use Rater for an AI-generated classification that works for our technical needs but communicates little to readers. I would have this appear alongside the topicon, both because the aesthetic badge is a big motivator for article writers and to run Dan's click-through experiment. Hoping that even if the topicons are never added to mobile view, at least this expanded tagline can be. ViridianPenguin🐧 (💬) 22:55, 7 July 2025 (UTC)Reply
  • As I said in a previous discussion, I don't agree with the premise. I think the current amount of prominence given to the article rating is appropriate, given the way the rating is determined. Thus I do not support changing the tagline in this manner. isaacl (talk) 22:55, 7 July 2025 (UTC)Reply
    Since that comment is in turn referring to another comment, here's the link to isaacl's argument against greater visibility for GA/FA status. ViridianPenguin🐧 (💬) 23:13, 7 July 2025 (UTC)Reply
    To expand slightly on the determination concerns: I appreciate that the good article/featured article review processes are the only ones we have for this type of article rating. However they do not ensure evaluation by subject matter experts with the background knowledge to best evaluate the comprehensiveness and accuracy of the article. I think giving the rating higher prominence would raise reader expectations that an evaluation has been made by subject matter experts. isaacl (talk) 15:10, 11 July 2025 (UTC)Reply
  • Support per above. These two ratings are the ones with the least amount of arbitrariness so I don't think this status should have any less prominence. They're already displayed as topicons everywhere except Minerva, which shows the reader interest. If these statuses are any overprominent, there's already consensus for them being so. Aaron Liu (talk) 23:05, 7 July 2025 (UTC)Reply
  • Oppose as the tagline should be kept simple. I agree with isaacl that we don't need to give more prominence to article ratings, which are subjective anyway. Some1 (talk) 23:27, 7 July 2025 (UTC)Reply
    I don't see how this isn't simple. Aaron Liu (talk) 23:45, 7 July 2025 (UTC)Reply
    A tagline that changes depending on the article rating isn't simple, and I prefer that the tagline text remains the same for every article, regardless of its rating. Also, it's misleading to state that Example article is "A good article from Wikipedia, the free encyclopedia" when that rating reflects only one editor's review (opinion) of that article. In that instance, the tagline is more misleading than the topicon, especially when most readers won't bother to click on the good article link in the tagline.
    Many editors in prior discussions have felt the topicon is too small a notice that doesn't accurately reflect the amount of work put into raising articles to featured status Seems like this proposal is more for the editors than for the readers. Some1 (talk) 00:32, 8 July 2025 (UTC)Reply
    What's the impact of this small bit of added complexity?

    when that rating reflects only one editor's review (opinion) of that article

    I think that's only an argument for renaming GoodArticle. In my opinion, "good article" signifies only as much value as it should. This also means if a reader thinks "hey this is not good-article quality" they can start something on the talk page. Aaron Liu (talk) 18:20, 8 July 2025 (UTC)Reply
  • Support. As long as we can keep the topicons as well, I don't see any downsides to this. – Epicgenius (talk) 00:08, 8 July 2025 (UTC)Reply
  • I don't see the harm per se, but more visibility for GA/FA ratings makes more critical the need for participation at WP:FAR and WP:GAR and for those processes to function properly. CMD (talk) 00:38, 8 July 2025 (UTC)Reply
  • Support. As I mentioned in the 2023 RFC: I once observed a high school classroom that happened to be teaching research skills on using Wikipedia. The teacher said that the lock icon in the corner meant that it had been reviewed and was safe. Readers have no idea what our esoteric icons mean, so a little explanation of what exactly is verified and what isn't could go a long way towards mutual incentives. This is a smart way to start. czar 02:08, 8 July 2025 (UTC)Reply
  • Support I don't see the harm in mentioning the fact that the article has reached good/featured status, and it would certainly help reader to become aware of those statuses and as a compliment to the topicons. Speaking of those icons, why don't we include them in the tagline too so the reader will notice it when reading the tagline and be able to recognize it when reading another article on its tagline or on the corner of said artile. So maybe something like "A good article   from Wikipedia, the free Encyclopedia." Here I placed the icon after the phrase introducing the article class since it looked akward to have it immediately following the indefinite article "A" when I tried that first. Gramix13 (talk) 02:52, 8 July 2025 (UTC)Reply
    This thought came to mind for me as well. I like the idea of having a more prominent visual, but I feel like it'd be redundant presuming we're keeping the topicon. My preferred approach to accomplish this would be to move the icon from the top right to directly next to the article title, as was previously proposed. Sdkb talk 05:09, 8 July 2025 (UTC)Reply
    Noting that since that 2020 proposal argued for matching the Danish Wikipedia's practice, dawiki has switched to our practice of having the topicon appear in the top-right corner (e.g., da:Israel). ViridianPenguin🐧 (💬) 13:40, 8 July 2025 (UTC)Reply
    Interesting; any idea why? Sdkb talk 14:18, 8 July 2025 (UTC)Reply
    Unfortunately not. I checked through their relevant talk pages and Landsbybrønden (village well) archives to no avail in identifying why they switched. ViridianPenguin🐧 (💬) 16:04, 8 July 2025 (UTC)Reply
  • Support. An article's good or featured status is a key piece of information that every media-literate reader ought to pay attention to, but our current display is nowhere near prominent enough to make that happen. This is a well-thought-out step in the right direction toward making that happen. I support keeping the topicons, and ultimately moving them next to the article title per the prior proposal. I also continue to hope that phab:T75299 is taken up so that icons display on mobile. Sdkb talk 05:07, 8 July 2025 (UTC)Reply
  • Strong support and additional request. I have a script that already does this, but this being an automatic thing for other editors would be extremely useful in helping people maintain articles. Possibly, we could also have 'Currently a featured article candidate', 'Former featured article', 'Currently a good article nominee' too; that might be a bit too technical though. 750h+ 05:18, 8 July 2025 (UTC)Reply
    Being a candidate or having former status is mainly relevant for editors, not readers, so I would not support this. Sdkb talk 06:03, 8 July 2025 (UTC)Reply
    +1 Graham11 (talk) 07:09, 8 July 2025 (UTC)Reply
    Wikipedia:Metadata gadget? It's a good thing the code is already pretty much there. Chaotic Enby (talk · contribs) 18:25, 8 July 2025 (UTC)Reply
  • Comment – If we are to use a redirect like Wikipedia:Featured articles (linked from tagline), we should probably change the tooltip to simply "Wikipedia:Featured articles". Graham11 (talk) 05:34, 8 July 2025 (UTC)Reply
  • Support, great idea. I'd also support other measures to improve GA/A/FA visibility, like moving the topicon to be right beside the title. Toadspike [Talk] 09:12, 8 July 2025 (UTC)Reply
    My reaction to much of the opposition is that our readers are not stupid. They know what Wikipedia is. They will not see "good article" and think "this must be a 105% perfect article certified by the leading experts in the field and then fully-protected so no-one can edit the page again". They know that Wikipedia is a wiki written by regular people, many of whom are not experts on the topics they write about, and that Wikipedia articles can generally be edited by anyone, anytime. By calling something a "good article" or "featured article", whether in a tagline or with an icon, we simply argue that this article is better than many others. And while were bashing the names as "hokey" or "bizarre", I must point out that "featured" sounds stupid outside the context of being featured on the main page, while "good" is a simple English word that accurately describes the point of the rating. Toadspike [Talk] 13:34, 12 July 2025 (UTC)Reply
  • Oppose The top of many articles, including GA and FA, are already overly cluttered. I would support the reduction of clutter rather than the adding to it. -- LCU ActivelyDisinterested «@» °∆t° 16:01, 8 July 2025 (UTC)Reply
    I understand your point, but this would add practically no clutter, as "From Wikipedia, the free encyclopedia" is still a default tagline. I assume you are generically opposed to the tagline in the first place? Dege31 (talk) 17:17, 8 July 2025 (UTC)Reply
    Yes I would support removing it altogether, rather than adding to it. -- LCU ActivelyDisinterested «@» °∆t° 18:40, 8 July 2025 (UTC)Reply
    I agree with ActivelyDisinterested here Logoshimpo (talk) 05:08, 17 July 2025 (UTC)Reply
  • Support. Awareness of the featured article process is partially what inspired me to begin contributing to Wikipedia, and I feel like increasing this awareness wouldn't just inspire more people to edit, but would also inform readers which articles have been more diligently reviewed to eliminate gaps and verification errors. Sad that this won't be visible on mobile but it's a step in the right direction with no glaring downsides. Fathoms Below (talk) 19:50, 8 July 2025 (UTC)Reply
  • Support. I can see no downsides to this proposal - anything that helps promote good and featured content, and potentially bring in new editors, is a positive in my book, and this is a pretty nice and yet non-obtrusive way to do so. CoconutOctopus talk 20:40, 8 July 2025 (UTC)Reply
  • Comment. It sounds like we are proposing adding a module to every single page load on the entire wiki. Has someone who understands mediawiki caching and performance given some thought about if this will cause stress to the servers or performance issues? –Novem Linguae (talk) 22:48, 8 July 2025 (UTC)Reply
  • Notified: WP:VPT. –Novem Linguae (talk) 22:50, 8 July 2025 (UTC)Reply
    mw.title.new().pageAssessments is an WP:EXPENSIVE function, but since it is only called once it usually shouldn't often be an issue considering the per-page limit of 500. The module does access the class rating via iteration (see the for loop at lines 29–33) rather than via random access, which is admittedly inelegant but probably not too inefficient. Sadly, I got what feels like a WONTFIX for random access at phabricator:T396135.
    Regardless, whether the community wants something shouldn't be dependent on whether it is currently feasible. I trust the interface admins and WMF will fix things if the community breaks them.
    This isn't to say I am in any way opposed to a code review of this, which I welcome wholeheartedly. I am sure there is something here that could be made more efficient. Dan Leonard (talk • contribs) 23:10, 8 July 2025 (UTC)Reply
    I tend to agree with the link to WP:DWAP here (which has been relevant for parts of the interface like this before, the link to Category in the footer of each page used to be treated as sufficiently expensive for some reason or another that we couldn't let it vary by number of categories or something like that).
    The only way to get an authoritative answer to this question would be to ask WMF directly I think.
    That aside, I'm actually not really certain this will work the way OP wants it to. Has it been attempted on test Wikipedia? Izno (talk) 23:57, 8 July 2025 (UTC)Reply
    Putting my developer hat on, to my understanding the MediaWiki:tagline is added by a user's skin. As such, running page assessments at that layer is prohibitively expensive since the skin layer is re-rendered every time a user visits a page (as opposed to the parser cache layer where data is computed/rendered every edit and thus can have expensive functions). Unless folks contradict me, to my understanding this will require a significant investment of engineering effort to implement into core-mediawiki (or one of it's extensions) which I'm not sure is worth the outcome.
    Putting on my WP:INTADMIN hat on, I'm not sure I'm completely onboard with using JS (or even Lua) to hack and slash at the existing tagline at pages that we as enwiki are wanting folks to visit. (For context, every time such a thing is implemented folks with bad internet connection will see a flash of unstyled content that often makes the navigating/reading experience worse). Sohom (talk) 00:51, 9 July 2025 (UTC)Reply
    Oh dear, I didn't realize it was part of the skin. What a shame. Guess it'll have to rely on mw:Extension:CustomSubtitle if it's ever finished. I defer to SD0001 below, who wrote the MediaWiki code that makes this possible and seems to think it's potentially possible. Dan Leonard (talk • contribs) 01:01, 9 July 2025 (UTC)Reply
    I don't think it's prohibitively expensive, just a bit expensive. Performance is not affected for logged-out users as for them the entire page html, including the skin, is CDN-cached. For logged-in users, it does result in re-rendering, however note that the Lua .pageAssessments call is just a single SELECT call in the db. Being marked as WP:EXPENSIVE doesn't give the full picture. – SD0001 (talk) 05:35, 9 July 2025 (UTC)Reply
  • Tend to oppose, but only for technical reasons. This should be part of MediaWiki (→m:Community_Wishlist/Wishes), not a Lua hack. Then maybe one day even mobile users would get it. Ponor (talk) 23:14, 8 July 2025 (UTC)Reply
    It definitely isn't a Lua "hack". Functionality like retrieving page assessments have been exposed to Lua for use cases like this. It doesn't make much sense to implement everything natively in MediaWiki since most MediaWiki installations don't have a concept of FAs or GAs. – SD0001 (talk) 05:37, 9 July 2025 (UTC)Reply
    Exposing page assessments to Lua is a part of MediaWiki. Aaron Liu (talk) 16:18, 9 July 2025 (UTC)Reply
    It's a hack because it hacks a message that shows at a place convenient for desktop users (⅓), but is not shown to mobile web and app users (⅔). It's not a complete solution, it's a hack. Other than that, there's a javascript gadget that also hacks the message, used by some 1000 active users. Why reinvent the wheel? Ponor (talk) 15:37, 10 July 2025 (UTC)Reply
    Changed my mind, it's a complicated js script. I'd still like to see a solution that every reader can see. Indicators are fine. Ponor (talk) 15:48, 10 July 2025 (UTC)Reply
    Using client-side JavaScript to scrape the talk page and modify the DOM after page load is a very different solution than using a MediaWiki extension's intended functionality to modify pages server-side. Mobile users miss out on a lot of things, including navboxes, sidebars, and even categories. Are categories "hacks" because Minerva chooses to hide them? Dan Leonard (talk • contribs) 15:45, 10 July 2025 (UTC)Reply
    Agree about the gadget, just checked the code: ugh, that's an ugly one. But here, we're saying "this is important, we want everyone to see it", while at the same time we know that two in three readers will not see it. Categories and navboxes are the things at the bottom. Most users rarely go past the lead. So I'd say there is some importance difference. I'm not strongly opposed to "the hack" – I'd simply like to see a better solution. Use different indicators - find better icons? Use icon+text on desktop, icon alone on mobile? Ponor (talk) 16:10, 10 July 2025 (UTC)Reply
    Topicons aren't shown on mobile because it's a difficult implementation and because they're even more opaque to readers (see phabricator:T75299#10512584): on desktop, {{featured article}} at least benefits its readers with the tooltip "This is a featured article. Click here for more information", but touchscreens don't get tooltips. The tagline isn't shown on Minerva either, but it's probably a much simpler implementation and hasn't been done simply as a screen real estate saving measure. If we can get the tagline shown (phabricator:T349117), it'd serve the same purpose as the tooltip serves for desktop users. I do want mobile users to see this, and I think using the tagline is an important first step to getting WMF to increase visibility. Dan Leonard (talk • contribs) 16:19, 10 July 2025 (UTC)Reply
    You cannot see indicators on mobile either. Aaron Liu (talk) 17:37, 10 July 2025 (UTC)Reply
  • Oppose What is the point? FAs and GAs are not necessarily better than normal articles, and the reader does not care about who followed internal Wikiprocedures to get something declared FA/GA. Also per Ahecht. Polygnotus (talk) 03:36, 9 July 2025 (UTC)Reply
    While you are technically correct that some articles which haven't been formally reviewed are as good as GAs or FAs, the average GA is certainly better than the average article, which is a stub or not much more. Toadspike [Talk] 07:58, 9 July 2025 (UTC)Reply
    @Toadspike The best kind of correct! Polygnotus (talk) 09:12, 9 July 2025 (UTC)Reply
    They have necessarily underwent quality control, which includes things like "checking whether the sources confirm what the article say"- not exactly obscure, Wikipedia-only procedures. Dege31 (talk) 16:33, 9 July 2025 (UTC)Reply
  • Support as an idea. If the current technical implementation is insufficient, then it can still be recognised as something the community supports and perhaps be added at a later point. Even if that is not likely to happen any time soon given other technical priorities, it would be better having than having another RFC every time someone comes up with another way to make FAs/GAs more visible.  novov talk edits 08:26, 9 July 2025 (UTC)Reply
    I agree with the idea that consensus and technical details should be separate. The closer should feel free to find clear consensus that the community wants this (because they do). Then a consultation with a WMF dev good at performance and caching (maybe via a Phab ticket tagged #performance_issue and pinging someone like Krinkle?) and/or a trial should probably be encouraged in the close as a next step, but can leave that part vague / not as strong as the community consensus part. –Novem Linguae (talk) 09:10, 9 July 2025 (UTC)Reply
  • Oppose hacking a module in to the tagline for every single page is a poor technical implementation, especially for something that is only needed on an extreme minority of pages. — xaosflux Talk 12:29, 9 July 2025 (UTC)Reply
    Also oppose conceptually using the tagline for this purpose; work was already spent on indicators and if wanted I'd prefer improvement to indicators. Indicators are also much more consistent across the Wikipedia's in other languages. — xaosflux Talk 12:32, 9 July 2025 (UTC)Reply
    The French, German, and Russian Wikipedias all use different icons (from us and from each other). Of the Wikipedias I regularly visit only Chinese and Norwegian use the same icons we do. Smaller wikis like Alemannisch don't have quality ratings at all. Toadspike [Talk] 13:20, 12 July 2025 (UTC)Reply
    I wonder if it's possible to add code to {{good article}}, {{featured list}} and {{featured article}} that changes the tagline. Cremastra (talk) 14:59, 9 July 2025 (UTC)Reply
    That was my original thought too and I asked the same thing at the idea lab. The MediaWiki extension mw:Extension:CustomSubtitle could allow this with {{#subtitle:A ''[[Wikipedia:Featured articles (linked from tagline)|featured article]]'' from Wikipedia, the free encyclopedia}}, but the extension is in beta and hasn't been touched in years. It seems like it uses a deprecated function global $wgOut so would need to be updated. Dan Leonard (talk • contribs) 15:13, 9 July 2025 (UTC)Reply
    Additional oppose reason, as others have called out already, this will not solve the problem of casual readers (who increasingly use minerva) not seeing the rating - as the tagline element isn't even shown on that skin. I'd rather see indicator support added to minerva. — xaosflux Talk 14:54, 10 July 2025 (UTC)Reply
  • Support A tagline seems much more understandable than cryptic and tiny symbols that we use today. If this proposal passes, I would support the removal of original topicons, as they will be made redundant. I don't know how feasible it is, but I would like WMF develop a way to show the taglines in the minerva skin as well. Ca talk to me! 15:40, 9 July 2025 (UTC)Reply
  • Oppose The tagline is there to provide credit to Wikipedia, not provide extra information such as an assessment from a niche rating project that the vast majority of Wikipedia readers and editors don't participate in. I don't think we should be adding overhead to every single page, including non-article pages, just for increasing the visibility of page status. Not to mention that, to those not familiar with our lingo, "A good article from Wikipedia" sounds incredibly hokey, if not conceited.--Ahecht (TALK
    PAGE    )     15:53, 9 July 2025 (UTC)Reply
    And what will the readers do with this information? Nothing. Polygnotus (talk) 15:56, 9 July 2025 (UTC)Reply
    They're assured that the article has been reviewed. Aaron Liu (talk) 16:20, 9 July 2025 (UTC)Reply
    A previous version of the article was reviewed. NebY (talk) 16:51, 9 July 2025 (UTC)Reply
    @Aaron Liu That is not how they will interpret that, but even if it was, what will the readers do with this information? Nothing. Polygnotus (talk) 00:08, 10 July 2025 (UTC)Reply
    It's like the opposite of the unofficial secondary purpose of maintenance tags. Aaron Liu (talk) 00:59, 10 July 2025 (UTC)Reply
    @Aaron Liu You lost me. I am assuming the unofficial secondary purpose of maintenance tags is to give the tagger the feeling they did something useful. Polygnotus (talk) 01:03, 10 July 2025 (UTC)Reply
    It's to inform that there is (more likely to be) a problem with an extract from an article. Aaron Liu (talk) 01:07, 10 July 2025 (UTC)Reply
    That sounds like its the official primary purpose. Polygnotus (talk) 02:03, 10 July 2025 (UTC)Reply
    This is a very controversial opinion. The question of whether cleanup templates' visibility to readers is in conflict with the WP:NODISCLAIMERS philosophy has been a battle on here since the beginning. The official primary purpose, a little fiction we tell ourselves to resolve this, is to categorize articles and flag areas for other editors. Dan Leonard (talk • contribs) 02:12, 10 July 2025 (UTC)Reply
    @Dan Leonard to inform that there is (more likely to be) a problem with an extract from an article doesn't specify who gets informed, it might be the readers or editors or both. Polygnotus (talk) 02:26, 10 July 2025 (UTC)Reply
    I'm just explaining Aaron's comment, which I saw as a joke referencing the TfD battles over cleanup templates and the official policy that they aren't for informing readers. Dan Leonard (talk • contribs) 02:31, 10 July 2025 (UTC)Reply
    Ah. Well I am mostly asleep so any jokes will go over my head. Polygnotus (talk) 02:35, 10 July 2025 (UTC)Reply
    I meant "inform readers" lol. Dan is correct in what I'm talking about, but I did have a point with my joke though in that the tagline would have the inverse purpose. Aaron Liu (talk) 17:39, 10 July 2025 (UTC)Reply
    Readers should absolutely be paying attention to an article's assessed GA/FA status. The fact that something underwent (in the case of FAs) a rigorous review process is a key piece of information as a reader decides to what extent to trust an article (and yes, in an ideal world they'd be verifying everything, but in practice doing that rigorously would take nearly as long as writing the article). It's something we pay attention to even when just reading an article we do not intend to edit. And it's therefore something we should make noticeable enough to readers that they can do the name. Sdkb talk 23:30, 9 July 2025 (UTC)Reply
    @Sdkb I think one of the major weaknesses and strengths on Wikipedia is that the writers are completely clueless about the readers. should absolutely be paying attention to an article's assessed GA/FA status. No, of course not. It means only that someone jumped through some hoops. a reader decides to what extent to trust an article In my experience, people don't work like that. it's therefore something we should make noticeable enough to readers that they can do the name. Why should we tell a reader information that is not helpful to them and that they do not know how to interpret. Doesn't make sense to me. Polygnotus (talk) 00:13, 10 July 2025 (UTC)Reply
    GA/FA statuses only reflect the quality of an article at the time it was reviewed. Some (most?) of the articles with GA/FA status haven't been reassessed in several years or have undergone so many changes since achieving their status that their current quality differs significantly from when they were first reviewed. J.K. Rowling, a "Featured article" (which apparently means that it's "[one] of the best articles Wikipedia has to offer"), currently has two large templates on the article, one of which indicates that it has neutrality issues. So again, these article ratings are subjective, and readers do not need to be paying attention to them any more than they need to. Some1 (talk) 00:31, 10 July 2025 (UTC)Reply
    You're conveniently omitting that there is currently an effort to delist the Rowling article. Which illustrates exactly how it should be working: Quality articles that no longer meet standards should be reassessed. Sdkb talk 02:42, 10 July 2025 (UTC)Reply
    The J.K. Rowling discussion has been opened for almost a month now (and who knows how long it'll take for that discussion to close), and in the meantime, that FA status is there, misleading readers into thinking the article is still "one of Wikipedia's very best works" despite multiple experienced editors arguing that the article should be delisted. Some1 (talk) 03:31, 10 July 2025 (UTC)Reply
    And plenty of others arguing that it should remain listed (and those editors are arguing that the aforementioned maintenance tags were added in an effort to try to get it delisted). I take no position on whether it should or should not remain an FA, but the active discussion around it, as the example you chose, contradicts the notion that FAs are listed and then never looked at/reevaluated again. People who watch them periodically send them to FAR, and WP:URFA/2020 has been going through every single one systemically. Of course, as in most areas of the encyclopedia, we don't have the editor capacity to monitor everything as closely as we wish, but that's no reason to give up on the project or minimize the value it provides to readers — if they know about it. Sdkb talk 17:40, 10 July 2025 (UTC)Reply
    Hence the giant neutrality tag on the top of the article. It's just like a "Disputed" inline tag right after a claim, and here the claim is that this is once of Wikipedia's very best works. Aaron Liu (talk) 17:43, 10 July 2025 (UTC)Reply
    As an editor who has provided a very critical review, I’m not concerned about the time the review has been active. It has been Featured for several years in roughly the same state. A month is pretty normal and I expect it’ll be moved to FARC soon (I’m going to post a follow up review tomorrow, which is how the process works). The moment we start speeding up the process of delisting, you will see (for example) large swathes of gender related content beset by meaningless and inaction able critiques to force delistings. WP:There is no rush. — ImaginesTigers (talk) 09:16, 11 July 2025 (UTC)Reply
    All the common slogans of Wikipedia sound incredibly hokey, if not conceited, to those who are opposed to wikis, the free knowledge movement, ... even the tagline itself, what if someone thinks "no such thing as a free lunch!", we have pages explaining free as in libre vs free as in gratis! This is just a walking on eggshells mentality which is not productive. Dege31 (talk) 16:38, 9 July 2025 (UTC)Reply
    If it's for providing credit, it should say "from Wikipedia contributors", given that Wikipedia/WMF don't own the copyright of article content. Dan Leonard (talk • contribs) 16:39, 9 July 2025 (UTC)Reply
    I don't see how either the FA or GA process is niche. If you were talking about WP:ACLASS, then sure, that would be truly niche. But almost 1% of all articles are already either FAs or GAs. As long as it links to the actual WP:FA and WP:GA pages, it isn't any more niche than the topicons already there, which I'd argue are even more cryptic to the casual reader. Epicgenius (talk) 18:16, 9 July 2025 (UTC)Reply
    Less than 1% is pretty niche. How many Wikipedia articles would you have to read to have a 50:50 chance of stumbling on one of the 0.76% that are GA, FA, or FL? NebY (talk) 18:34, 9 July 2025 (UTC)Reply
    But GAs and FAs are some of the most-frequented articles that readers are likely to bump into. They're not randomly distributed. Cremastra (talk) 18:56, 9 July 2025 (UTC)Reply
    From Wikipedia:Popular pages § Top-100 list, quite a few of our most-viewed articles are GA or FA:
Rank Class Page Views in millions
  Main Page 46,800
  Special:Search 15,000
  Special:Random 7,900
  - 2,900
  Undefined 1,800
  United States Senate 350
  Special:Watchlist 344
  Special:Randompage 314
  YouTube 296
  Wiki 277
  Facebook 277
1   United States 254
2   Donald Trump 243
  Wikipedia 228
  404.php 225
  xHamster 212
  Portal:Current events 208
3   Elizabeth II 198
  Google 193
  Special:Book 185
  Special:CreateAccount 172
4   India 165
5   Barack Obama 161
  Search 153
  Bible 153
6   Cristiano Ronaldo 151
7   World War II 145
8   United Kingdom 144
9   Michael Jackson 142
  Wikipedia:Your first article 137
10   Elon Musk 135
  Special:RecentChanges 135
11   Sex 132
  Cleopatra 132
12   Lady Gaga 129
13   Adolf Hitler 129
14   Eminem 127
15   Lionel Messi 125
16   Game of Thrones 122
17   World War I 121
18   The Beatles 116
19   Justin Bieber 114
20   Canada 113
20   Freddie Mercury 113
22   Kim Kardashian 111
23   Johnny Depp 109
  Creative Commons Attribution 109
24   Steve Jobs 108
24   Dwayne Johnson 108
26   Michael Jordan 107
26   Australia 107
28   List of presidents of the United States 104
29   The Big Bang Theory 103
30   Taylor Swift 102
  Search engine 102
31   Stephen Hawking 101
31   List of highest-grossing films 101
33   China 100
  Portal:Contents 100
  XXXX 96
  Malware 96
34   Russia 96
34   New York City 96
34   Japan 96
34   Kanye West 96
38   List of Marvel Cinematic Universe films 95
38   Abraham Lincoln 95
40   LeBron James 94
40   Charles III 94
40   Darth Vader 94
40   Star Wars 94
40   Miley Cyrus 94
40   Germany 94
40   September 11 attacks 94
47   Leonardo DiCaprio 93
48   Kobe Bryant 92
48   Selena Gomez 92
50   Joe Biden 91
50   Tom Cruise 91
50   Rihanna 91
50   Albert Einstein 91
50   Academy Awards 91
55   Prince Philip, Duke of Edinburgh 90
55   Harry Potter 90
55   Elvis Presley 90
55   The Walking Dead (TV series) 90
59   Scarlett Johansson 89
59   Lil Wayne 89
59   Tupac Shakur 89
59   Angelina Jolie 89
63   Queen Victoria 88
63   Jeffrey Dahmer 88
65   John F. Kennedy 87
65   COVID-19 pandemic 87
67   Diana, Princess of Wales 86
67   Marilyn Monroe 86
69   Keanu Reeves 85
69   Arnold Schwarzenegger 85
69   How I Met Your Mother 85
69   Chernobyl disaster 85
69   France 85
69   Ariana Grande 85
75   Jennifer Aniston 84
75   Breaking Bad 84
77   Meghan, Duchess of Sussex 83
77   Muhammad Ali 83
77   Will Smith 83
80   Ted Bundy 82
80   Pablo Escobar 82
80   Mila Kunis 82
80   Vietnam War 82
80   Mark Zuckerberg 82
85   Manchester United F.C. 81
85   William Shakespeare 81
87   Titanic 80
87   Tom Brady 80
87   Jay-Z 80
87   Singapore 80
87   Earth 80
87   Bill Gates 80
  Wikipedia:Contact us 80
93   Winston Churchill 78
93   Bruce Lee 78
93   Nicki Minaj 78
93   Israel 78
97   Princess Margaret, Countess of Snowdon 77
97   John Cena 77
97   Charles Manson 77
97   Ryan Reynolds 77
97   Brad Pitt 77
97   Vladimir Putin 77
  • Dan Leonard (talk • contribs) 18:58, 9 July 2025 (UTC)Reply
    Thanks - more than I was guessing! NebY (talk) 19:01, 9 July 2025 (UTC)Reply
  • Support per above; I have an extension installed which does practically the same thing. To partially address the concerns some users have about the taglines being potentially misleading b/c the GA/FA is super old, the extension says Currently undergoing review of its featured status etc when articles get re-reviewed. ❤HistoryTheorist❤ 04:21, 10 July 2025 (UTC)Reply
  • Support It took me ages to find the tagline. I'd never noticed it, but support anything that lets our readers get more of a sense of relative fidelity of Wikipedia articles. A good thing that the GAR process is alive and kicking: we've been able to remove the icon from the 'worst' articles in recent years. —Femke 🐦 (talk) 07:32, 10 July 2025 (UTC)Reply
  • Oppose. We should not be misleading readers into thinking that the article rating is objective or meaningful when it is neither. Thryduulf (talk) 08:19, 10 July 2025 (UTC)Reply
    Ouch. Cremastra (talk) 14:48, 10 July 2025 (UTC)Reply
    Are you arguing the average featured article is not better than the average article? Because that's what article ratings having "no meaning" would mean. The reality is the opposite. The average featured article is way way better. IAWW (talk) 15:29, 10 July 2025 (UTC)Reply
    @It is a wonderful world by what objective measure is the comparison being made? What is the definition of an "average article" and an "average featured article"? The median-length featured article is definitely going to be longer than the median-length non-featured article but length alone is not a reliable indicator of anything other than length (e.g. an article that is two thirds reactions from random celebrities on Twitter is worse than an article one third its length that is purely encyclopaedic). Article ratings are meaningless in that they do not reliably convey to the reader any information about the quality of the current state of the article. Even a featured article rating simply says that someone put a lot of effort into satisfying a small number of other people that they put a lot of effort into the article at some point in the past. There is no requirement for writers or reviewers to be subject matter experts so there is no guarantee it is any more or less accurate than any other cited article. Ratings other than featured are worth less than the paper they are written on. Thryduulf (talk) 17:16, 10 July 2025 (UTC)Reply
    If there's a non-featured article whose quality is better than a featured article, that article should be made a featured article. Aaron Liu (talk) 17:45, 10 July 2025 (UTC)Reply
    That assumes that the current version of every featured article is of sufficient standard to be regarded as one of Wikipedia's best, that is simply not true. If you think the effort in getting a rubber stamp of approval from a self-selecting group of non-experts is worth the time it takes, good on you, but that doesn't make the rubber stamp meaningful to readers. Thryduulf (talk) 19:10, 10 July 2025 (UTC)Reply
    If an article does not meet the standards, you can be the one to delist it. The great bulk of articles do not meet Feature quality standards, therefore articles that do are in fact among the best. Aaron Liu (talk) 19:49, 10 July 2025 (UTC)Reply
    It doesn't matter what objective measure you use. Any measure which tries its best to rigorously define the heuristic concept of article quality will show featured articles are better than non-featured articles in 99% of cases. You can see this by picking random featured articles and random non-featured articles – seriously, just go and try it right now! You don't need to rigorously define "average" and "objective measure" or any other words to see this. IAWW (talk) 17:50, 10 July 2025 (UTC)Reply
    Any measure which tries its best to rigorously define the heuristic concept of article quality will show featured articles are better than non-featured articles in 99% of cases. citation needed. Thryduulf (talk) 19:07, 10 July 2025 (UTC)Reply
    The sentence after: "you can see this by picking random featured articles and random non-featured articles" – go try it IAWW (talk) 19:16, 10 July 2025 (UTC)Reply
    Without some measure which tries its best to rigorously define the heuristic concept of article quality I cannot. Thryduulf (talk) 19:17, 10 July 2025 (UTC)Reply
    If there is no objective measure you can think of (though I'm sure there is), your claim would be unfalsifiable. Aaron Liu (talk) 19:34, 10 July 2025 (UTC)Reply
    Eh? I'm not the one claiming that the average featured article is better than the average article (that's @It is a wonderful world's claim). Thryduulf (talk) 19:44, 10 July 2025 (UTC)Reply
    https://doi.org/10.1609/icwsm.v3i1.13959 empirically derived features of FAs from FAC discussions, and for two articles I've tried it seems to work. Regardless, Wond's claim did not say the measures have to be objective; that's what you introduced. To see whether an article has better quality, we only need to agree in our judgement, no matter whether it is based on subjective criteria or objective criteria. Aaron Liu (talk) 19:53, 10 July 2025 (UTC)Reply
    Reading the abstract of that 2009 study (I don't have time to read more), it seems to only show that articles that were awarded featured status reliably contained the features the FAC process looked for - which is unsurprising, not really relevant to this discussion, says nothing about whether those features do indicate quality (if the featured article criteria required every featured article to contain a sentence about the colour red and every featured article did contain such a sentence, that would indicate that the FAC process is following its own rules, but wouldn't say anything about the article quality) and may or may not still hold true nearly 15 years later.
    To see whether an article has better quality, we only need to agree in our judgement, no matter whether it is based on subjective criteria or objective criteria. true, but no criteria (objective or subjective) were specified let alone agreed - I asked what objective criteria were being used to back up the claim (and still haven't got an answer) because while we could agree to use subjective criteria to verify the claim I do not agree that such would be both relevant and meaningful. Also, it's worth pointing out that putting the article status in the tag line is not agreeing anything with anybody, or telling anybody anything about the average Wikipedia article. It is claiming that this version of this article is an example of Wikipedia's best work. That is not reliably true. Thryduulf (talk) 20:47, 10 July 2025 (UTC)Reply
    Fair point. I still maintain that you should use whatever subjective criteria you should stand behind, but ORES scores also show quality. I strongly disagree that subjective criteria are meaningless. I'm sure we all know the meaning in having "good" article quality, and that is of course subjective. It is meaningless to ask for objective assessments of something being better if we can agree using other criteria that something is better much faster, especially when the selection of such "objective" criteria is, in itself, subjective. All I'm saying is the near-tautology of subjective assessments being able to produce the subjective assessment of "good quality", while you're saying that only objective assessments will suffice, an unfalsifiable claim if you cannot provide an objective measure.
    The topic of "this version" is being discussed elsewhere in this RfC. Aaron Liu (talk) 21:33, 10 July 2025 (UTC)Reply
    I'm sympathetic to your main argument, that labeling articles at some point in time is incompatible with the wiki model. But I think your comments rubber stamp of approval from a self-selecting group of non-experts, even GA only requires that citations exist, an article that is two thirds reactions from random celebrities on Twitter is worse than an article one third its length that is purely encyclopaedic, and ratings other than featured are worth less than the paper they are written on are very dismissive of the work content reviewers do and I don't think you should be surprised you're getting piled on here over them. Dan Leonard (talk • contribs) 19:54, 10 July 2025 (UTC)Reply
    What pile on? It's about even in terms of people who (broadly) agree with me and people who (broadly) disagree. The final statement you quote from me is entirely a matter of opinion, we can agree to disagree regarding that. The quote about reactions relates only to article length not being a reliable metric of quality, I don't understand why you think that is dismissive of the work of content reviewers unless they do regard length as a reliable indicator of article quality? (If they do, that's definitely a black mark for the process).
    The first two are factual statements. Thryduulf (talk) 20:32, 10 July 2025 (UTC)Reply
    By calling the result a "rubber stamp", the first one is an opinion. For the claim to be factual, you would need to show FAC does not disagree with its insiders, which is verily false. Aaron Liu (talk) 21:34, 10 July 2025 (UTC)Reply
    I'm really disheartened by the comments decrying the content review process here. IAWW's review of an article I wrote was one of the most enjoyable editing experiences I've had on here, and it was very comprehensive and involved a text-source integrity check. Reducing his work to a rubber-stamp without citation checks is insulting. Dan Leonard (talk • contribs) 20:30, 11 July 2025 (UTC)Reply
    There are GA reviews like that, but there are also GA reviews like Talk:I-No/GA1. As Stepwise stated below, promoting articles to GA status only requires one person's approval. Some1 (talk) 20:40, 11 July 2025 (UTC)Reply
    Is there a problem with the subject article that makes you think the review was conducted improperly? It obviously has fewer BLP and political considerations than the one I cited so the prose does not need to be checked as closely. Regardless, it still gets a topicon with a "this is a good article" tooltip so I don't see why the modified tagline would be so extreme an addition. Dan Leonard (talk • contribs) 20:51, 11 July 2025 (UTC)Reply
    This is a little off topic, but @Some1, what makes you think that review you linked was not conducted properly? IAWW (talk) 22:47, 11 July 2025 (UTC)Reply
    I don't believe the review was conducted "improperly", but find the differences in the lengths and comprehensiveness of the two GA reviews quite jarring. Some1 (talk) 23:21, 11 July 2025 (UTC)Reply
    The first two are factual statements Ha ha. No they aren't. I'm not sure why you're taking this opportunity to complain about editors who want quality articles, but your second statements is clearly false. Perhaps you should look at the GA criteria, which are loose but set a baseline of acceptable quality content, before making clearly and egregiously incorrect statements, which at this point is approaching disinformation. Cremastra (talk) 01:22, 11 July 2025 (UTC)Reply
    Discussion elsewhere has identified that the GA criteria I was reading and the GA criteria that are actually applied are different, so while I thought that was factual it turns out that it wasn't. The first is though.
    I'm not complaining about editors wanting quality content - far from it - what I'm saying is that article rating labels are not a reliable guide to the quality of the current version of an article. I'm also saying that the FA and GA criteria used to award those labels are not a guarantee that the version of the article reviewed is one of Wikipedia's best, just that it meets those criteria. If you think that is an attack on editors then you haven't been reading what I've actually written. Thryduulf (talk) 01:35, 11 July 2025 (UTC)Reply
    I mean, the GA criteria excerpts the part from the "how the GA criteria should be applied" guideline on spot checks being minimum, so you could say it is in the GA criteria you were reading. That is an interesting state of affairs indeed. Aaron Liu (talk) 15:01, 11 July 2025 (UTC)Reply
    If the GA criteria as written differ from the GA criteria as applied in practice, then we definitely shouldn't be proclaiming GA status in the tagline. Overloading the ordinary word "good" with an insider meaning is confusing enough. Expecting that people will read a set of criteria and then a further guideline to figure out what "good" is supposed to mean is... not really practical. Stepwise Continuous Dysfunction (talk) 18:41, 11 July 2025 (UTC)Reply
    Again, the relevant part of that guideline is quoted in the set of criteria. Aaron Liu (talk) 19:07, 11 July 2025 (UTC)Reply
    Maybe you know that that's the only relevant part of that guideline. Maybe someone would figure that out after reading both. But it's not at all clear. Every time a reader has to investigate a behind-the-scenes Wikipedia page to understand what something means, we've failed. Stepwise Continuous Dysfunction (talk) 19:52, 11 July 2025 (UTC)Reply
    We have explanatory essays that go in depth on the specific meanings of everything. That does not undermine the meaning of what is explained at all. The criteria by itself sufficiently explain what is expected of GoodArticles. Aaron Liu (talk) 20:00, 11 July 2025 (UTC)Reply
    They don't differ, criteria 2 definitely requires sources verify the text. I don't follow the claim that there's a discrepancy here. Dan Leonard (talk • contribs) 20:08, 11 July 2025 (UTC)Reply
    That's a pretty serious claim you're making. Do you have any objective evidence that the process is this fundamentally useless? None of the criteria for good and featured articles, after all, are not length, so if they don't measure anything else, that's pretty serious. You think the process is so bad that even checking the sources doesn't increase the average accuracy, that it's just a rubber stamp? This all sounds pretty unbelievable to me, but maybe I'm wrong. If this is all true, why do you think the average participant of this RfC is ignorant of it? Dege31 (talk) 17:57, 10 July 2025 (UTC)Reply
    I do not have evidence for a claim I am not making. Checking the cited sources do verify the content they claim to verify is extremely valuable but only a small part of what is required to get the FA badge, not required for any other rating (even GA only requires that citations exist) [see later discussion, it turns out the documented GA criteria I based that comment on do not match the GA criteria that are actually applied. Thryduulf (talk) 01:42, 11 July 2025 (UTC)], and something that can be done completely independently of the FA process. My claim is that FA status does not reliably communicate anything useful to readers about the current version of the article. The current version of the article might be better than average, even one of Wikipedia's best, but it might even be below average now. Thryduulf (talk) 19:16, 10 July 2025 (UTC)Reply
    That's no longer true. Funnily, the new GA checks are in some sense more strict that the FA criteria on WP:TSI. All GANs require spot checks (since 2023 or so), whereas only newer FA nominators have their articles spot checked. —Femke 🐦 (talk) 20:27, 10 July 2025 (UTC)Reply
    That's not what is written at WP:GACR6. Thryduulf (talk) 20:56, 10 July 2025 (UTC)Reply
    Well in practice, spot checks are expected. See the guideline Wikipedia:Reviewing good articles#Assessing the article and providing a review. Aaron Liu (talk) 21:04, 10 July 2025 (UTC)Reply
    I'm sure the GA criteria used to include that a spot check was required. Did this get removed? IAWW (talk) 21:06, 10 July 2025 (UTC)Reply
    That's good to know, but if we can't even reliably communicate what the GA criteria actually are to editors who know that "good article" is jargon then it is even less useful information for readers than I previously thought it was. Thryduulf (talk) 21:16, 10 July 2025 (UTC)Reply
    The proposed destination for the modified tagline is Wikipedia:Good articles, which states (emphasis mine)

    A good article (GA) is a Wikipedia article that meets a core set of editorial standards, the good article criteria, passing through the good article nomination process successfully. They are well-written, contain factually accurate and verifiable information, are broad in coverage, neutral in point of view, stable, and illustrated, where possible, by relevant images with suitable copyright licenses.

    Also, I think you may have missed footnote 3 in WP:GACR6, which states "at a minimum, check that the sources used are reliable ... and that those you can access support the content of the article". I think these adequately explain to readers that a good article has had its sources checked for verifiability. Dan Leonard (talk • contribs) 21:23, 10 July 2025 (UTC)Reply
    Right, I see what you mean now. I understand the concern, but personally, with the (re)activation of the good & featured article review process, I don't personally think it's as critical. Would you also support removing the good article and featured article topicons, by the same logic? Dege31 (talk) 23:03, 10 July 2025 (UTC)Reply
    It's not something that bothers me enough to propose myself, especially as some people seem rather attached to them, but I would probably support if someone else were to propose it. Thryduulf (talk) 23:08, 10 July 2025 (UTC)Reply
    @Thryduulf: even GA only requires that citations exist please strike this factually incorrect statement. Cremastra (talk) 01:23, 11 July 2025 (UTC)Reply
    I've struck with a note as it's slightly more complicated than simply being incorrect, see discussion subsquent to my comment about why I made that statement. Thryduulf (talk) 01:42, 11 July 2025 (UTC)Reply
    Thank you. Cremastra (talk) 01:57, 11 July 2025 (UTC)Reply
    There is no requirement for writers or reviewers to be subject matter experts so there is no guarantee it is any more or less accurate than any other cited article. Yes, exactly. Schizophrenia is a Featured Article with almost 4k edits since its FA review back on May 2, 2011 (14 years ago). Who knows if that article is still accurate or up-to-date, but because of its FA status, readers will blindly trust that the article and its content are accurate. Some1 (talk) 18:39, 11 July 2025 (UTC)Reply
    I mean WP:MEDRS the policy is pretty good at tackling that exact problemSuperscript text Aaron Liu (talk) 19:08, 11 July 2025 (UTC)Reply
  • Oppose Per Thryduulf - GA particularly has little to do with quality and is more of an Wikipedia:Esperanza-like process to promote the participants. The GA talkpage currently has an RFC to enforce Quid pro Quo reviewing of articles and to reduce the standard of reviews. GA reviews are in many cases completely subjective and amount to little more than "I like this" or "I don't like this".Nigel Ish (talk) 17:23, 10 July 2025 (UTC)Reply
    It is a bit subjective, yes, but there are detailed criteria on how articles should be evaluated for GA. GAs that don't meet the criteria go through GAR. The linked "reduce the standard of reviews" discussion is not about reducing the standard of reviews but about reviewers who make additional comments beyond the standard of the reviews. And the quid prop quo proposal RfC is currently met with a swarm of opposition. Aaron Liu (talk) 17:48, 10 July 2025 (UTC)Reply
    At this point this discussion discussion has devolved into GA-bashing by people who apparently don't want any kind of quality control and for who any recognition of hard work is evidence of a social clique. Cremastra (talk) 01:18, 11 July 2025 (UTC)Reply
    This user specifically seems to have an axe to grind against the GA process: see their userpage. Cremastra (talk) 05:18, 11 July 2025 (UTC)Reply
    As a post I made is linked here, I feel obligated to comment that this is a misrepresentation of what I said. Thebiguglyalien (talk) 🛸 03:42, 11 July 2025 (UTC)Reply
  • I don't think I'd ever noticed the tagline before, but I've definitely seen the topicons. The fact that they're coloured images makes them more noticeable than small italics, but having linked text in the tagline would probably cover some of that deficit. Maybe I've overestimating the readers, but because "good article" doesn't have a standard colloquial meaning, I think that if a reader did notice that the tagline said that, there wouldn't be any standard meaning to assume. If they wanted to know what it meant, they might click the link and learn more about the internal processes of the encyclopedia. If they didn't, they wouldn't walk away with any wrong assumptions. "Featured article" is a little different - assumptions could be made - but the meaning could vary wildly. Maybe this so-called "featured" article was chosen at random somehow to feature on the main page at some point in the past. I think the topicons make the meaning clearer, appearing to be badges the article has achieved somehow, but I don't think the additional text in the tagline would harm the project (outside of potential technical burden). 207.11.240.2 (talk) 08:59, 10 July 2025 (UTC)Reply
  • Oppose - because as written, the tagline is misleading. For instance, the first example listed: London Beer Flood. When you go to the talk page, it is clearly tagged as: London Beer Flood is a featured article; it (or a previous version of it) has been identified as one of the best articles produced by the Wikipedia community. So it is misleading to imply to our readers that the current version they are reading is the FA version. Isaidnoway (talk) 18:28, 10 July 2025 (UTC)Reply
    I think that'd be a good thing. If an article's current state is incongruent with what one expects from being "one of the best articles", readers would be alerted to raise the issues somewhere. This can help ensure quality within FAs. Also, <pedantic>, the banner you quoted says the article or a previous version met the definition, and that the article is a featured article, not that it might be a previous version that is the featured article instead of the current version. Aaron Liu (talk) 20:00, 10 July 2025 (UTC)Reply
    No, what it means is that the FA article could be the current form or an earlier, possibly different, iteration of the article could be the FA. For instance, Michael Jackson was promoted to FA status 17 years ago, and on July 8, 2025, there was a brief edit war over a cleanup tag placed in a section. The article had 16,000+ pageviews that day, so how many readers (hundreds, thousands) read a version (current version) that didn't meet the criteria for a FA, and we shouldn't expect for our readers to try and hunt for a previous version that actually meets the FA criteria. I mean, if we are going to say to our readers with a tagline - the current version you are reading meets the criteria for a FA, but yet editors are squabbling over content that may not reflect what the cited sources actually say, then yeah, go ahead with a misleading tagline. Isaidnoway (talk) 23:54, 10 July 2025 (UTC)Reply
    The article was still designated FA. The definition of FA is that the article or a previous version was reviewed and met criteria, not necessarily the current version even if the FA-designation is the status quo. I'm not saying we should expect our readers to hunt for that previous version; I'm saying that increasing this prominence invites readers who realize the incongruence to challenge. I don't see how the cleanup tag changes anything in your argument's favor here. Aaron Liu (talk) 00:47, 11 July 2025 (UTC)Reply
    invites readers who realize the incongruence to challenge the vast majority of readers will not recognise the incongruence, but will blindly trust that an article that proclaims to be top quality is top quality, even if it contains blatant misinformation. Even editors with years of experience working with featured articles will not always see an incongruence for topics (or even topic areas) they are not familiar with. Thryduulf (talk) 00:55, 11 July 2025 (UTC)Reply
    Not if there's a giant orange banner. Aaron Liu (talk) 00:56, 11 July 2025 (UTC)Reply
    Sorry I missed this reply earlier, but I'm struggling to understand what relevance a banner has to anything in my comment? Thryduulf (talk) 18:58, 22 July 2025 (UTC)Reply
    It's alright. I was referring to maintenance tags. If the maintenance tags that are about eight times larger than the tagline (on desktop; on mobile it's probably gonna be like 3x) and colored in alarming ways say the article contains misinformation, the reader will believe the article contains misinformation over the tagline that says "featured article". Aaron Liu (talk) 19:15, 22 July 2025 (UTC)Reply
    True, but only a very small portion of current revisions (at the time any given reader loads the article) of good or featured articles that are not of that quality (due to vandalism, gradual degradation, changing standards, link rot, POV-pushing, real-world changes, editing disputes, etc, etc, etc) have maintenance tags. Thryduulf (talk) 20:25, 22 July 2025 (UTC)Reply
    I guess that's where we diverge. I have not seen any GA/FAs that have problems untagged for a significant amount of time. Would you give me a post-Coldwell example? Aaron Liu (talk) 20:33, 22 July 2025 (UTC)Reply
    I don't know what you mean by "post-Coldwell" but see everything just before it was sent to FAR/GAR, every vandalised revision, etc. It doesn't matter how long the page is below the standard, it matters that whenever someone views a revision that is below standard (for whatever reason) the tag would be misleading. Sometimes only in a very minor way, other times in extremely major ways and of course everything in between. Thryduulf (talk) 10:09, 23 July 2025 (UTC)Reply
    You have a point. Still, I think this deserves a trial to see if the increased visibility will bring more articles to maintenance categories or GAR and thus counter the issue you describe. Aaron Liu (talk) 17:59, 1 August 2025 (UTC)Reply
    The article had 16,000+ pageviews that day, so how many readers (hundreds, thousands) read a version (current version) that didn't meet the criteria for a FA - Kind of beside the point, but an article doesn't automatically change from "FA quality" to "not FA quality" just because there's a tag (and similarly for GA). Instead it's usually one of two situations:
    1. The tag was justified, and therefore the article was already not up to FA/GA standard beforehand. It can be resolved, or the article brought to WP:FAR/WP:GAR if issues are pervasive enough.
    2. The tag was not justified, nd therefore it changes nothing about the article's rating.
    Though, I can't argue with the fact that the current version of an article that previously passed an FAC or a GAN may not necessarily be up to standard. That's why substandard articles are (and should be) listed at FAR or GAR. Epicgenius (talk) 03:43, 11 July 2025 (UTC)Reply
    On MJ's article, if you or I ran across the maintenance tag, sure, we would know it could be either one of the two situations you listed, but would our readers? If this prominent tagline had been in place on MJ, bragging about this is one of our very best articles, and a reader scrolls down to a section that is tagged with - the content you are about to read may not reflect what the cited sources actually say, they are going to walk away scratching their heads, thinking, this is their very best? Of course, this situation would hold true with the FA icon already present, but I just don't see how adding this prominent tagline (more bragging) is a benefit to our readers, when it has the potential to be misleading. It's bad enough these unnecessary icons are already on the page. Isaidnoway (talk) 06:50, 11 July 2025 (UTC)Reply
  • Oppose, per a combination of Ahecht's arguments (scope creep: rating is not what the tagline is for; and "a good article from Wikipedia" sounds bizarre for everybody not familiar with the technical meaning) and Thryduulf's (rating status is far too unreliable for such a highlighting to be responsible). I may add that both arguments apply particularly strongly to "good articles", for which I would oppose this proposal very strongly. Fut.Perf. ☼ 19:20, 10 July 2025 (UTC)Reply
  • Oppose per Future Perfect at Sunrise. —Compassionate727 (T·C) 23:31, 10 July 2025 (UTC)Reply
  • Support - clearly sensible, not least as readers on mobiles do not get to see the FA or GA icons. Whatever the merits or demerits of the GAN and FAC procedures, these articles do have a defined level of quality and it's helpful for readers to know that. Chiswick Chap (talk) 08:56, 11 July 2025 (UTC)Reply
    Did you see above how readers on mobile also do not get to see the 'tagline'? — xaosflux Talk 09:25, 11 July 2025 (UTC)Reply
    these articles do have a defined level of quality. No they don't. A previous version of the article was assess as having a defined level of quality, but there is no guarantee that the version of the article the tagline is displayed on bears any resemblance to that version. Thryduulf (talk) 09:53, 11 July 2025 (UTC)Reply
    This is just one of the things where Wikipedia works better in practice than in theory. "There is no guarantee that any of this is true" is correct for all of Wikipedia, yet it is highly trusted and extremely widely used. —Kusma (talk) 10:11, 11 July 2025 (UTC)Reply
    Indeed, but that's completely different to a prominent banner saying "this is our best work" with links saying that our best work has been verified etc, being placed on articles that are anything but our best work. While many people seeing a page that has been very obviously vandalised will realise that it has been vandalised, not everybody will and the more subtle the vandalism (or POV pushing, etc) the fewer people will know not to take the statement at face value. Doubly so if the article's POV has been slanted towards a POV the reader happens to share. Thryduulf (talk) 10:26, 11 July 2025 (UTC)Reply
    Thryduulf, I think you overestimate the amount of change that quality articles, especially FAs, see after their review. Ovalipes catharus has some small additions of references and phrasing tweaks ([1]) since it was promoted in January. Malicious edits would be reverted, which leaves potentially problematic edits down to POV-pushing, addition of inaccurate information, and bad writing. These would probably all be caught by the person who brought it to FA in the first place. Cremastra (talk) 15:00, 11 July 2025 (UTC)Reply
    All those mallicious edits, etc were current revisions before reversion. The person who brought it to FA is not watching it 24/7. Also, changes accumulate over time God of War III was promoted to FA in February 2015, it has since undergone significant changes. Is it still FA quality? I have absolutely no idea. Do I trust a 10-year-old rating? if yes, then it's misleading if I happen to have viewed it one of the many reverted revisions was current. If no, then it's pointless. Thryduulf (talk) 15:48, 11 July 2025 (UTC)Reply
    GAs can see many changes: Western Roman Empire 527 intermediate revisions by more than 100 users so far[2]; Catilinarian conspiracy 68 by 39[3]; Biblical Hebrew 791 by more than 100[4]. FAs too: Ethiopian historiography 192 by >100[5]; Eagle (British comics) 323 by >100[6]; John Lennon >3000 since being TFA on 8 Dec 2010[7] (apologies if I've missed any intervening reviews). NebY (talk) 15:50, 11 July 2025 (UTC)Reply
    Taylor Swift has almost 10,000 intermediate revisions since its promotion to FA status back on October 31, 2016 (9 years ago), and there are complaints on the article's talk page that the article is a mess, outdated, and "completely bloated." Some1 (talk) 18:55, 11 July 2025 (UTC)Reply
    Well, yeah, these intervening 9 years count for almost half of Taylor Swift's career. I wouldn't expect any article, let alone Swift's article, to remain unchanged in that time period.
    As for the article being bloated and outdated, that is less relevant to the topic currently at hand (mentioning FA status in the tagline) and more like a WP:FAR issue. – Epicgenius (talk) 19:58, 11 July 2025 (UTC)Reply
    The fact that there are complaints about the featured article(s) just illustrates that these article ratings are subjective, provide little meaningful information to readers, and don't need to be given more prominence (and in this case, by modifying taglines, of all things). Some1 (talk) 20:17, 11 July 2025 (UTC)Reply
    I don't see how. It simply makes them wiki articles just as mistakes make us human. Aaron Liu (talk) 21:47, 11 July 2025 (UTC)Reply
    these article ratings are subjective,
    There are literally objective criteria (WP:GACR, WP:FACR) that are used to evaluate articles for GA or FA status. So no, it isn't a subjective rating.
    The fact that there are complaints about the article just mean that people have opinions. These may indicate that the article doesn't meet the criteria. They may also be unjustified, however, as Dan Leonard indicates below. – Epicgenius (talk) 21:51, 11 July 2025 (UTC)Reply
    That recent complaint from an unregistered editor is plainly false (the masters buyback is covered in the lead with a link to Taylor Swift masters dispute and extensively in § 2018–2021: Lover, Folklore, and Evermore). I get that FAs sometimes get delisted but choosing one with a drive-by nonsense complaint isn't a very good argument. Dan Leonard (talk • contribs) 20:22, 11 July 2025 (UTC)Reply
    I think it's fallacious to imply that just because an article has reached GA or FA status, it shouldn't undergo changes. It's one thing for an article to be modified significantly after its promotion to FA or GA status. Sometimes, this is even required in order for an article to keep its rating, especially for articles about people who are alive or things that still exist.
    It's another thing entirely for these changes to have significantly degraded the quality of the article, but even a small number of changes by a small number of editors can degrade an article's quality. In short, quantity of changes != quality of changes. – Epicgenius (talk) 16:27, 11 July 2025 (UTC)Reply
    Whatever fallaciousness you might infer, I was not implying that just because an article has reached GA or FA status, it shouldn't undergo changes. I was responding to I think you overestimate the amount of change, began by saying many changes, and didn't discuss their quality or materiality. NebY (talk) 16:50, 11 July 2025 (UTC)Reply
    Whatever fallaciousness you might infer, I was not implying that just because an article has reached GA or FA status, it shouldn't undergo changes.
    If I was mis-attributing that to you, then I apologize. I was speaking primarily in the context of Thryduulf's comment; they claimed that there is no guarantee that the version of the article the tagline is displayed on bears any resemblance to that version. Which may very well be true, but that comment also implied that articles have to remain more-or-less static after their promotion, which is not the case.
    I was replying to your comment about the number of changes to selected GAs/FAs because I was trying to convey the fact that a large number of changes may not necessarily be an indicator of an article's decline in quality. It can be an indication of such a deterioration of quality, but this can also be done by one or few editors who remove large parts of an article. – Epicgenius (talk) 17:19, 11 July 2025 (UTC)Reply
    I wasn't saying that articles have to remain more-or-less static after promotion, and I'm not sure how you read that into my comment. I'm simply saying that because articles are not static, a previous version being assigned a quality rating is not a reliable indicator of the current quality of the article. It might be that there have been a thousand changes but no material change, it could be that there have been ten changes and the article is substantially different (which could mean it is worse, better or about the same quality). It is this changing nature that means the assessments are not a reliable indicator of the quality of the version displayed, so we should not be proclaiming that something is an example of our best work when we have absolutely no idea whether it is or isn't. Thryduulf (talk) 17:50, 11 July 2025 (UTC)Reply
  • Support mildly increasing the visibility of our assessment processes. We should also strengthen GAR and FAR to ensure the designations remain meaningful. —Kusma (talk) 10:18, 11 July 2025 (UTC)Reply
    This seems to put the cart before the horse. Shouldn't we ensure that the designations mean something before we increase their visibility? Stepwise Continuous Dysfunction (talk) 18:46, 11 July 2025 (UTC)Reply
    I think they are meaningful. I am using the opportunity to assert that FAR and GAR are important in ensuring that the designations are meaningful. We do not have to improve all processes to perfection before considering something like the present proposal. —Kusma (talk) 19:37, 11 July 2025 (UTC)Reply
    @Stepwise Continuous Dysfunction The designations do mean something and always have. Cremastra (talk) 20:56, 11 July 2025 (UTC)Reply
  • Oppose on the grounds that we shouldn't be shoving words that have specialized Wikipedian meanings in front of every reader. "Good" is a particularly bad word to use in this way. Stepwise Continuous Dysfunction (talk) 17:19, 11 July 2025 (UTC)Reply
    Not only is the term "good article" overloading the ordinary word "good", but also, getting that status for an article really only requires the approval of one person. We shouldn't make that look more official than it is.
    I do not think this was intentional, but this proposal amounts to gratifying long-term editors at the cost of confusing readers. Stepwise Continuous Dysfunction (talk) 18:33, 11 July 2025 (UTC)Reply
    It also requires the article surviving challenges to the good article status and the reviewer being in good standing.
    Why not give it a try and see if readers are confused? A lot of people here doubt they will be. Aaron Liu (talk) 19:09, 11 July 2025 (UTC)Reply
    A similar number of people have made very strong arguments that readers will be confused and/or actively mislead. Why should we dismiss those concerns just because some experienced editors with detailed knowledge of the procedures vaugely hope that readers will understand that when shove jargon in their face they will understand both what it means and also that it might not actually mean that? Thryduulf (talk) 19:47, 11 July 2025 (UTC)Reply
    Nobody is claiming readers will know right away what these terms mean, the idea is that they'll be clearer than the status quo of topicons. Czar's story in § Proposal 21: Make GA status more prominent in mainspace shows that readers currently don't understand what these icons mean and actually have serious misunderstandings. A plain-text phrase "good article" or "featured article", with a clear link to these meanings, will hopefully both alleviate confusion and onboard future contributors. Dan Leonard (talk • contribs) 20:14, 11 July 2025 (UTC)Reply
    Another comment I somehow missed. If readers have serious misunderstandings about what the jargon means when it is tucked away in a corner and accompanied by a link and/or tooltip to an explanation, why would putting that same jargon front and centre not result in anything other than more readers with serious misunderstandings? Thryduulf (talk) 19:01, 22 July 2025 (UTC)Reply
    My complaint is not about the info being tucked away in a corner but about being obscured by an icon and a tooltip. Tooltip explanations are discouraged by most accessibility guidelines including our own because readers clearly aren’t hovering over them to learn what they mean. Replacing (or here, supplementing) icon-and-tooltip presentation with plaintext and a link is self-evidently clearer and less confusing. Dan Leonard (talk • contribs) 19:11, 22 July 2025 (UTC)Reply
    One reviewer "in good standing" is still just one reviewer. And "good standing" is one more thing that is not explained either at the criteria page, the instructions page, or the guideline (which is a different page than the instructions). Stepwise Continuous Dysfunction (talk) 19:59, 11 July 2025 (UTC)Reply
    It's not a defined thing but empirical, basically the chances of such reviews ending up at GAR. It's not a real thing besides just having reviews that fit the criteria. Aaron Liu (talk) 20:04, 11 July 2025 (UTC)Reply
    "Good" is a pretty good description, better than "featured" but I think the link will be enough for people to cope. —Kusma (talk) 19:39, 11 July 2025 (UTC)Reply
    If "Good article" actually meant something similar to the non-jargon meaning of "this article is good" then you might have a point. So while I applaud your optimism the evidence of how readers currently interact with Wikipedia suggest to me that it is significantly misplaced. Thryduulf (talk) 19:50, 11 July 2025 (UTC)Reply
    Many here that !voted support believe that good articles are good. Aaron Liu (talk) 20:05, 11 July 2025 (UTC)Reply
    That established Wikipedians can have a good faith disagreement about what the phrase "Good article" means is more than enough evidence that it will mislead some readers. Thryduulf (talk) 22:22, 11 July 2025 (UTC)Reply
    Is there a GoodArticle you think is not good? If so, you should nominate that article for Review after starting a discussion about it, no matter how much the article has changed since it was reviewed. By something approaching induction GoodArticles are therefore good articles. I think the only situation where the GoodArticle process fails to produce good articles is if you believe the criteria are not enough to ensure "good", in which case I'd like to know. Aaron Liu (talk) 22:31, 11 July 2025 (UTC)Reply
    My point is that in Wikipedia jargon "Good article" means that a specific revision of an article was judged by one person to meet a set of very specific criteria (that the current version of the article may or may not now meet). To most readers seeing a tagline saying "good article" would indicate that the version of the article has been assessed to be "good" and thus can be relied upon to be neutral, accurate, and at least reasonably comprehensive and thus by implication articles that are not "good" are "bad" and cannot be said to be poses any of those qualities. While it is true that the current version of many Good Articles is indeed good there are also current versions of Good Articles that are not good. There are also plenty of articles where the current version is accurate, neutral and comprehensive but which are not Good Articles simply because nobody has formally assessed it. Thryduulf (talk) 22:45, 11 July 2025 (UTC)Reply
    I think we're going round in circles at this point. I made a similar reply at #c-Aaron_Liu-20250711004700-Isaidnoway-20250710235400.

    there are also current versions of Good Articles that are not good

    (besides what I say in the linked reply) Those are also very few.

    by implication articles that are not "good" are "bad"

    I don't think that's true. The rest are just unreviewed articles, and even not meeting the standard for good doesn't necessarily mean bad. I think this also addresses your last point. Aaron Liu (talk) 01:48, 12 July 2025 (UTC)Reply
    As an editor familiar with the review process you know that "not good" doesn't mean "bad". The same is not true of the average reader who does not know that "Good article" is jargon, let alone what it means.
    Re current versions of Good Articles. If you mean stable versions then there probably are relatively few (but still a large number), however when you include every version that is current at some point it is much larger. There is no way for the casual reader to know whether the version they are seeing is the good version or the vandalised version. Thryduulf (talk) 02:41, 12 July 2025 (UTC)Reply
    Sorry, I meant that I doubt that's what readers'll interpret it is. WIthout "good" it's still "articles".
    I mean at any moment. I don't think aggregating anyone that had any version that was bad is meaningful. And it's not like RC patrol's gone handicapped. Aaron Liu (talk) 02:47, 12 July 2025 (UTC)Reply
    It does mean something similar, and I am indeed optimistic that our readers know that blue text means a link that can be clicked on to obtain clarification. Most of our readers are not using Wikipedia or the WWW for the first time. —Kusma (talk) 23:11, 11 July 2025 (UTC)Reply
    I'd argue that "featured" is a less confusing term than "good" in this context, since it's less generic and actually conveys the connotation that the articles were selected via some process. Stepwise Continuous Dysfunction (talk) 19:55, 11 July 2025 (UTC)Reply
  • Support a simple change to address a problem that has come up frequently. Phlsph7 (talk) 09:09, 12 July 2025 (UTC)Reply
    What problem? Thryduulf (talk) 10:46, 12 July 2025 (UTC)Reply
    Visibility of page status as addressed in the discussions listed at Wikipedia:Village_pump_(proposals)#Background_(tagline). Phlsph7 (talk) 13:36, 12 July 2025 (UTC)Reply
    The proposal has indeed come up frequently. Some editors see increased visibility of article ratings as an improvement to the status quo, but if there is a problem with the status quo it is that it overstates the reliability and importance of article ratings, which is not something making them more prominent can solve (indeed rather the opposite). Thryduulf (talk) 17:26, 12 July 2025 (UTC)Reply
  • Support as I like the idea of better signaling which of our articles have met a minimum bar for quality. GAs aren't perfect articles, but we show worse articles on the main page every day. Ed [talk] [OMT] 20:03, 12 July 2025 (UTC)Reply
  • Oppose Unnecessary embellishment Logoshimpo (talk) 04:05, 13 July 2025 (UTC)Reply
    An embellishment is defined as ornamental, or decorative detail, to make something more attractive. Is it to your belief that the good article, and featured article processes are likewise embellishments? Dege31 (talk) 01:54, 17 July 2025 (UTC)Reply
    Yes Logoshimpo (talk) 05:07, 17 July 2025 (UTC)Reply
  • Oppose unnecessary and potentially misleading use of wikipedia jargon.--Staberinde (talk) 09:31, 15 July 2025 (UTC)Reply
    Could you clarify what you mean by 'unnecessary'? Dege31 (talk) 01:52, 17 July 2025 (UTC)Reply
    There is no noteworthy problem that requires fixing here.--Staberinde (talk) 20:10, 17 July 2025 (UTC)Reply
  • Support – for the same reasons I proposed more prominent topicons in 2021. As Wikipedia matures, I think it's increasingly important we 1) focus on raising the quality of existing content and 2) help readers learn how to effectively use and understand the varying quality of articles, especially in the current information landscape. Drawing attention to the main ways we review articles, however flawed they are, is a step in the right direction for both these aims, and by raising awareness of peer review processes it might help improve them. I think it would be even better if the "featured article" or "good article" text linked directly to the article's most recent FAC/FAR/GAN, but perhaps that wouldn't be feasible. I understand the valid concerns about the varying quality of FA/GA status articles, but ultimately it is better than no review at all, I trust that most readers understand Wikipedia is not infallible, and the more we focus on peer reviews the better for raising quality and trust in the project. Jr8825 • Talk 12:26, 15 July 2025 (UTC)Reply
  • Support ways to make GA/FA status more prominently visible, including this proposal. My preferred way of going about it would be to have the icon next to the article title, kind of like how (on desktop) the icon is displayed next to the name of another language in the "Languages" list if that version of the article is good or featured (see e.g. Jupiter). Several of the opposing comments sound more to me like arguments to abolish GA/FA (or at minimum the icons) entirely, which I am fairly certain is a proposition that would be overwhelmingly rejected by the community. TompaDompa (talk) 23:35, 16 July 2025 (UTC)Reply
    To your point about opposing comments, I agree. Some of the oppose !votes bring up valid concerns, like Future Perfect at Sunrise's and Isaidnoway's comments that this tagline might not be appropriate for articles that actually need GAR or FAR. However, comments like "GA particularly has little to do with quality and is more of an Wikipedia:Esperanza-like process to promote the participants." and "Yes" (in response to a query about whether the respondent considered the GA/FA processes mere "embellishment") do seem to be rooted in opposition to the GA or FA processes, not to this specific proposal. – Epicgenius (talk) 01:54, 18 July 2025 (UTC)Reply
  • Oppose, per several of the arguments made above. If this is intended to bring in more editor participants, we're sending a confusing signal to a group very few of whom are the right target. The terms are opaque and likely to be misleading to our readers, since there are plenty of GAs that are no longer good quality but have not been reassessed yet. Fewer FAs are in that state, but there are some. If the GAR and FAR processes were working as well as we'd like, this would be less of an issue, but we haven't solved that problem yet. Future Perfect at Sunrise puts the case against well. Mike Christie (talk - contribs - library) 00:20, 17 July 2025 (UTC)Reply
  • Support trying this out, at least for some period. I believe Wikipedia should try to make GAs/FAs more visible to the common reader, and I think more awareness may also lead to more GAR and FAR helpers. ALittleClass (talk) 02:38, 18 July 2025 (UTC)Reply
  • Oppose for "A good article from Wikipedia"; which implies that other articles are "not good". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:22, 21 July 2025 (UTC)Reply
    Would you feel differently, @Pigsonthewing, if we renamed GAs/FAs to something like "high-quality article" and "top-quality article"? Sdkb talk 15:09, 21 July 2025 (UTC)Reply
    That would imply that other articles are "not high quality", so no. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:15, 21 July 2025 (UTC)Reply
    Is there some other language we could rename GAs/FAs to to connote that they have undergone more thorough review and received a higher quality assessment than other articles, without implying that all our other articles are trash? I do think the concept of article quality assessments for articles should be fairly intuitive to most readers, Wikipedia being a work in progress and all that. Sdkb talk 15:25, 21 July 2025 (UTC)Reply
    The problem is that, at least as things currently stand, articles that there is a set of articles that have been assessed as being of a particular quality at some point in their history and a set of articles that are currently that standard of quality. The two sets overlap but are not close to being the same with both high quality articles that have not been assessed as such and articles that were formerly high quality no longer being. Unless and until the significant majority of articles tagged as being of "X" quality currently (at the time any given reader loads the page) are that quality and the significant majority of articles that are that quality are tagged as such any tagline will be inherently misleading in some way. Thryduulf (talk) 15:39, 21 July 2025 (UTC)Reply
    You could get around some of that by something that says something like like "on <date>, a <version> this article was assessed as being <quality standard>" with a link to that quality standard and an explanation that the current version may or may not be of that quality standard, but (a) that isn't a tagline, and (b) is not what is being proposed here. Thryduulf (talk) 15:42, 21 July 2025 (UTC)Reply
    We cannot let the perfect be the enemy of the good. Part of our responsibility of editing the encyclopedia is to ensure that articles that should be FAs/GAs are nominated and that those designated as such but that no longer meet the standards are delisted. It's no different than having an article tagged as needing more citations: That tag was placed at a specific point in time, and represents our judgement at that time, but it doesn't imply that other articles don't also need more citations. And if, as the article evolves, it acquires enough citations, it's our responsibility to remove it. The articles tagged as needing more citations will never correspond precisely to those that actually do need more citations the most, but we still use the notice since it's a good enough (albeit imperfect) indicator. Ditto for quality article assessments. Sdkb talk 16:00, 21 July 2025 (UTC)Reply
    "Part of our responsibility of editing the encyclopedia is to ensure that articles that should be FAs/GAs are nominated..." No it isn't. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:22, 21 July 2025 (UTC)Reply
    It sounds like you do not support having the GA/FA system as an integral part of the encyclopedia. Sdkb talk 16:59, 21 July 2025 (UTC)Reply
    It isn't an integral part of the encyclopaedia, it's an optional status symbol. Just because that status symbol motivates some editors to improve articles doesn't make it integral - look at the countless articles that get improved in other ways and for other reasons. Thryduulf (talk) 17:20, 21 July 2025 (UTC)Reply
    I didn't say that; please read what I wrote. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:33, 21 July 2025 (UTC)Reply
    We cannot let the perfect be the enemy of the good. That's true in the abstract, but this proposal is not good - indeed for the reasons explained in detail multiple times it's actually harmfully bad. The comparison to dated tags that specify in detail what the problem is/was and do not proclaim or imply anything about other articles misses the mark in multiple different ways. Thryduulf (talk) 17:16, 21 July 2025 (UTC)Reply
    The German Wikipedia approaches this by putting de:Template:Exzellent at the bottom of pages with a notice "This article was added to the list of excellent articles on day (DD_MM_YYYY) in [permanent_link_to_version this version]. See today's featured article, de:Abreise König Wilhelms I. zur Armee am 31. Juli 1870. That also has serious downsides, for example de:J. R. R. Tolkien links to a version from 2004 that does not have a single inline citation and does not actually meet modern day standards. "The 2004 version of this article met the 2004 version of WP:FA?" is not particularly useful information. —Kusma (talk) 10:22, 31 July 2025 (UTC)Reply
    The latter issue might be mitigated by only displaying the message if the article was promoted or had its status confirmed within the last N years. The German Wikipedia has (or at least had) a very different approach regarding inline citation to the English Wikipedia, so the status of articles is not trivially comparable between the languages. Thryduulf (talk) 10:39, 31 July 2025 (UTC)Reply
    It does no such thing, especially since there is a link explaining what "good article" actually means. —Kusma (talk) 09:50, 22 July 2025 (UTC)Reply
    It might not do that to you, but it does to me and Andy and assuredly will to anyone who doesn't know that "good article" is jargon (regardless of whether there is or isn't a link). Thryduulf (talk) 09:54, 22 July 2025 (UTC)Reply
    I really don't think we have enough GAs or FAs that the absence of a "good article" tagline will be so widely noticed. I don't think the proposal will be as impactful as you and Andy seem to think, but we won't find out if we don't try it. —Kusma (talk) 10:01, 22 July 2025 (UTC)Reply
    Whereas I believe that the multiple severe downsides (not just this one) combined with the extremely low benefits that will come even if successful mean that even a trial will come up with a significantly negative benefit:cost analysis. Thryduulf (talk) 12:10, 22 July 2025 (UTC)Reply
    What will the net negative impacts of a trial be? Aaron Liu (talk) 13:44, 22 July 2025 (UTC)Reply
    All the negatives explained by multiple people multiple times already. Thryduulf (talk) 13:52, 22 July 2025 (UTC)Reply
    I don't see any argument that hasn't been responded to. Aaron Liu (talk) 13:56, 22 July 2025 (UTC)Reply
    The arguments have been responded to but have not been refuted. Thryduulf (talk) 14:28, 22 July 2025 (UTC)Reply
    For example, how does #c-Aaron_Liu-20250711005600-Thryduulf-20250711005500 and #c-Dan_Leonard-20250711201400-Thryduulf-20250711194700 not refute what you said? Aaron Liu (talk) 18:44, 22 July 2025 (UTC)Reply
    Is there any evidence of severe (!) downsides outside of hypothetical Wikipedia editor discussions? We already have the topicons. Why don't we see any inklings of these severe downsides, if they are a realistic concern? At least I'm not aware of any. Dege31 (talk) 04:08, 23 July 2025 (UTC)Reply
    The top icons are decoration that most people ignore and have to be investigated (but even then others have pointed out that they cause misconceptions). A tagline is extremely prominent and makes a bold statement to everybody reading the article (even more so if it is expanded to mobile) meaning the problems caused by misleading statements will be very significantly amplified. Thryduulf (talk) 10:13, 23 July 2025 (UTC)Reply
  •  
    Dopamine in the mobile view

    Oppose I'd not noticed the taglines before and suppose that I've been blanking them as fluff. The specific suggestion of calling out FAs and GAs seems quite marginal as we don't have many of them. Why not give an assessment of the article when it has a lesser status too? It might be more useful to warn readers that an article is a stub or just C-class or whatever.

    And I don't like the idea that this will be forced onto the mobile interface as space is at a premium in that. See the example of Dopamine which I took a snapshot of for another discussion recently. Notice that this doesn't manage to get all of the first sentence of the article onto the first screenful. Adding a tagline would push it off completely.

    So, the idea of giving readers an assessment of the article upfront has merit but the implementation needs work.

    Andrew🐉(talk) 17:55, 22 July 2025 (UTC)Reply

    Would you be in favour of putting the assessment class icon (                 ) next to the article title? TompaDompa (talk) 18:12, 22 July 2025 (UTC)Reply
    No, those icons are too obscure and unclear. Andrew🐉(talk) 22:24, 22 July 2025 (UTC)Reply
    Re: the specific suggestion of calling out FAs and GAs seems quite marginal as we don't have many of them: the good and featured systems have broad community support and are currently represented on articles already by topicons with tooltips like "this is a good article". This proposal is intended only as an extension of that as shown above in § Background (tagline), and so any extensions beyond what is already very highly supported would be undue. Also re: it might be more useful to warn readers that an article is a stub or just C-class or whatever a "warning" would violate WP:NODISCLAIMERS. Dan Leonard (talk • contribs) 18:30, 22 July 2025 (UTC)Reply
    WP:NODISCLAIMERS is irrelevant. Every page has a general disclaimer per WP:GENDIS. And there's already a well-established set of tags to show that that an article is a stub. The trouble is that these appear at the bottom of articles where the reader won't see them until it's too late. It's better to make the status of an article clear to the reader at the outset, so that they have this context as they are reading it. Andrew🐉(talk) 22:28, 22 July 2025 (UTC)Reply
    You literally used the word "warning", though. That's exactly what NODISCLAIMERS is about. This proposal is about promoting articles that have reached a high standard of quality that the community is proud to present to readers. Giving a "warning" to readers that an article is "just C-class" is the opposite. That could be considered at a later point but should not be part of this proposal. Dan Leonard (talk • contribs) 22:32, 22 July 2025 (UTC)Reply
    Exclusively promotional language is contrary to MOS:PUFFERY and WP:PROMO. It's more informative and NPOV to give the reader our quality rating in a uniform way, whether it's good or bad. Andrew🐉(talk) 09:13, 23 July 2025 (UTC)Reply
    B-class and lower can be changed by anyone anytime. I'm not confident in the quality assurance for those.
    Also, if you want more mobile screen space, dismiss that banner. Aaron Liu (talk) 18:42, 22 July 2025 (UTC)Reply
    Re:mobile accessibility- that might be easy for you or me, but the "dismiss banner" button is *really* tiny on mobile. I don't think my mother could reliably click it, for example, she just doesn't have the eyesight anymore. GreenLipstickLesbian💌🦋 18:51, 22 July 2025 (UTC)Reply
    Fair point. But that's an issue we could easily solve by enlarging the button; we don't even need to file a task for it as we can simply do it through an interface admin. Aaron Liu (talk) 19:11, 22 July 2025 (UTC)Reply
    I'd not noticed or understood that button. That's mainly banner blindness – Wikipedia has a very busy interface and so I tune out the clutter and extraneous excess. Andrew🐉(talk) 22:24, 22 July 2025 (UTC)Reply
    I would think that it's not very busy on mobile. There's only one banner at the top. Aaron Liu (talk) 02:44, 1 August 2025 (UTC)Reply
  • Support. This would be a positive for readers and editors alike. Perhaps people opposed should also advocate for removing WP:TMVs from articles—they link to editor-focused stuff as well. We have giant banners when an article has issues, but a small link when it has been determined to meet a set of standards is a bridge too far? Heartfox (talk) 03:15, 23 July 2025 (UTC)Reply
  • Weak oppose. I do not see further clutter is necessary. Janhrach (talk) 13:38, 23 July 2025 (UTC)Reply
  • Weak oppose I like tag lines to be the same for every article. If it is to be tried, I would propose to do it for the Featured articles first. Readers are more likely to have heard from them from the main page. The articles are higher quality and more editors are needed to certify them as featured. The Good article slogan sounds worse. Ideally it should be measured whether readers understanding of the featured article process increases after the change. Rolluik (talk) 09:02, 31 July 2025 (UTC)Reply
    Do you think the featured article tagline is worthy enough to be trialed and measured first? Aaron Liu (talk) 14:16, 31 July 2025 (UTC)Reply
    I think it makes sense to do that first. I have not myself participated in a FA or Good article process. I'm aware of the cleanup efforts for older FA and Good articles (and also that it seems to have stalled for the featured articles). I think that new featured and good articles seem mostly similar quality wise for most readers but as an editor I see that the featured ones have mostly better sources. Keep in mind that English is not my native language, so I care less about spelling mistakes and similar issues. I'm sceptical though that changing the tag line will have a big effect on anything (increase of FAC's, Good article nominations, FAR's, readers knowledge of quality assesments...). I don't think it will be detrimental either. Maybe we should give people an easy link to the version of the article that was reviewed in the tag or near the tag (not just on the talk page). I see no real problem with giving newer FA's that were on the main page this tag line (If we were confident enough to put it on the main page...). Rolluik (talk) 20:16, 4 August 2025 (UTC)Reply
  • Support A marginal improvement to the reader's experience I think. ~ HAL333 15:32, 31 July 2025 (UTC)Reply
  • Strong oppose. I'm sorry; I really believe the article status should be more visible, but I can't stand the tagline being modified in such a drastic way. In my opinion, the benefits of keeping the current tagline intact and free of links and other notices outweigh the benefits of letting the user know an article is good/featured. I'm all in for doing the same thing while keeping the precious tagline intact! --FaviFake (talk) 20:54, 31 July 2025 (UTC)Reply
    Do you have an alternate way to present the information? Maybe including plain text in the {{featured article}} topicon, etc.? Dan Leonard (talk • contribs) 21:01, 31 July 2025 (UTC)Reply
    I'm guessing like the "this article is a stub" messages but at the top, perhaps. It could also include the most recent date it was promoted/survived review as recommended above. Aaron Liu (talk) 21:06, 31 July 2025 (UTC)Reply
    This seems fine to me, I mostly opposed the tag changing due to esthetic reasons. The only downside is banner blindness (and scrolling distance) but most readers seem fine with maintenance templates and similar; and featured/good articles are not supposed to have those. Rolluik (talk) 20:27, 4 August 2025 (UTC)Reply
    Nope! I have no idea, but I am conviced the tagline of all things shouldn't be tampered with. FaviFake (talk) 21:37, 20 August 2025 (UTC)Reply
  • Strong oppose to "Good article" tagline, weak support to the rest. Our neutral point of view is one of Wikipedia's core content policies. It's not up to us to declare to the reader our articles are "good". I believe our quality article assessments are quite helpful for Wikipedia's editors and I'm happy with the current topicons (which [being icons] don't declare anything and link to the full explanation), but outright writing at the beginning that this is "A good article from Wikipedia" is not neutral. I'm attracted to the argument that this could increase new editor attraction but I don't see that outweighing the opposers' concerns. I also don't believe making the tagline more verbose in response would be a satisfactory workaround. Sophocrat (talk) 02:19, 1 August 2025 (UTC)Reply
    Note: I'm much more open to doing this only with Featured articles and lists due to the arguments others have made. As a bonus "Featured" is much more neutral than "Good". Sophocrat (talk) 02:24, 1 August 2025 (UTC)Reply
    Could you specify how exactly this proposal violates

    All encyclopedic content on Wikipedia must be written from a neutral point of view (NPOV), which means representing fairly, proportionately, and, as far as possible, without editorial bias, all the significant views that have been published by reliable sources on a topic.

    i.e. neutral point of view? An article assessment is not "view[s] that have been published... on a topic".
    Dege31 (talk) 17:33, 1 August 2025 (UTC)Reply
    This is pedantic. Sophocrat is talking about the principle.
    I was going to say that it would represent all significant views on the article until I realized I was just going to repeat #c-Aaron_Liu-20250710200000-Isaidnoway-20250710182800. Aaron Liu (talk) 18:00, 1 August 2025 (UTC)Reply
    As Aaron Liu says I refer to the principle. We don't declare ourselves to be a reliable source (even though we strive to be!) to the reader. In articles we should avoid stating opinions as facts as our aim is to inform the reader, not make judgements for them. That said, I think I would support doing this only with Featured articles and lists as they have the highest quality standards and because the descriptor "Featured" is just a fact (as those are indeed prominent articles) whereas "Good" is a judgement from us (however well-founded). Sophocrat (talk) 21:36, 1 August 2025 (UTC)Reply
  • Support I've been using a userscript that does something similar and it is quite useful. (Wish I could tell you which one, but nothing in my common.js is obviously it.) Loki (talk) 16:20, 4 August 2025 (UTC)Reply
    In § Background (tagline) I note this is explicitly based on the style of Wikipedia:Metadata gadget, which is not in your common.js but in Preferences → Gadgets → Appearance →   Display an assessment of an article's quality in its page header (documentation). Dan Leonard (talk • contribs) 16:37, 4 August 2025 (UTC)Reply
    Yes, that's it! Thanks. Loki (talk) 21:26, 8 August 2025 (UTC)Reply
  • Weak support: Why not? Children Will Listen (🐄 talk, 🫘 contribs) 18:36, 7 August 2025 (UTC)Reply
  • Weak oppose: On the one hand, it'd be simple, as there's already a gadget for this, it could just require flipping it to default-on. On the other hand, there's already a gadget for this - and more pointedly, we already put an icon in the upper right of the page header for FAs, FLs, and GAs, so having this be by-default seems slightly redundant. - The Bushranger One ping only 05:02, 8 August 2025 (UTC)Reply
    we already put an icon in the upper right of the page this proposal is mostly inspired by Czar's story here, detailing how readers are not just unaware of the meaning of icon-based indicators but actively misguided. I think text and a transparent hyperlink is a clearer presentation. Dan Leonard (talk • contribs) 05:22, 8 August 2025 (UTC)Reply
  • Strong support – I'll take anything at this point... time and time again we've needed increased visibility for our best articles (most readers don't even know these distinctions exist, let alone the difference between featured vs good)... – Aza24 (talk) 21:31, 8 August 2025 (UTC)Reply
  • Weak oppose My greatest concern is that most Wiki users have no idea about what this actually means, especially since "good" can be interpreted much differently. In my experience what most readers care about (almost exclusively) is factual correctness, being of course part of being a GA it's not the entire story and (hopefully) most other articles meet that standard too. Highlighting it there makes me feel like it's implying that other articles are inherently "bad" and cannot be trusted. I could however see it work out with FA as not being Featured misses such an implication in my opinion. Squawk7700 (talk) 23:08, 8 August 2025 (UTC)Reply
  • Oppose. As much as I'm a fan of the FA and GA processes and like to gain such honours for the articles I've written, it's basically a Wikipedia internal concept. I don't think we should be publishing such things in a single line tag which is used across the Web, and lacks context for readers of they're not familiar with the processes. While in general, on average such articles are likely to be better written and more reliable than others, it's not a universal truth and it would be a mistake to imply in the tagine such articles can be implicitly trusted.  — Amakuru (talk) 00:30, 15 August 2025 (UTC)Reply
    Don't FAs convey the quality status in a way that is already explicitly designed for public consumption, being featured on the home page, and indicated with an icon on pages for users that are not logged in? The GA process too implies a basic quality threshold has been reached, and is already displayed publicly. That some GAs or FAs fail to live up to their status is surely more of a clarion call for the review process than it is a reason to view the baby as no better than the bathwater. With the icons already present, the proposed changes aren't making anything visible that isn't already. As always, anyone interested in the context of the terms could navigate through to the explanations, as they can now with the icons. Iskandar323 (talk) 10:43, 15 August 2025 (UTC)Reply
    Amakuru isn't the only one to comment that the f.a. system is an internal process. Another problem is that this isn't available on mobile. Finally: I'm not aware if there was consensus or a discussion to implement the topicons. Logoshimpo (talk) 05:25, 22 August 2025 (UTC)Reply
    I don't see how being internal is something relevant to what Iskander said. Consensus: Wikipedia talk:Featured articles/Archive 4#Neat idea from Spanish Wikipedia, Wikipedia talk:WikiProject Good articles/Archive 4#Should GA and A-class articles be recognisable through a symbol on the article page? Aaron Liu (talk) 22:12, 22 August 2025 (UTC)Reply
    I would repeal the decision made for those two discussions since too many arguments here against this selfreference has been brought up. Logoshimpo (talk) 04:13, 23 August 2025 (UTC)Reply
    There's nothing preventing a discussion from being started on that if one truly believes the arguments have that much support. Aaron Liu (talk) 02:25, 26 August 2025 (UTC)Reply
  • Support as with other users. >^CreativeLibrary460 /access the library revision\ 01:09, 20 August 2025 (UTC)Reply
  • Support This small change would go a long way to help our readers see when an article is of a higher quality. The icons aren't immediately clear, but text with a link would be much more overt. The more we provide average readers with even a basic understanding of the back-end processes, which is sadly quite uncommon, the better I think they'll be able to engage with our articles. --Grnrchst (talk) 13:05, 20 August 2025 (UTC)Reply
    This small change would go a long way to help our readers see when an article is of a higher quality. no, it will let readers see when some previous version of an article was assessed as being "featured" or "good" and will imply that the revision of the article they are seeing is of that standard (it may or may not be) and that articles not so tagged are inferior (they might be, they might also be superior). I'm also not understanding why a reader should need to know anything about back-end processes in order to engage with articles? Thryduulf (talk) 13:37, 20 August 2025 (UTC)Reply
    I answered your question here — in short, it's helpful info for readers to know to what extent they should trust an article. And in the replies below, myself and others talk about the process by which editors monitor and delist GAs/FAs that no longer meet standards. It's not perfect, of course, but readers know that we are an imperfect work in progress. It's no different than maintenance tags, which also represent a judgement about an article from a particular point in time, which may be outdated but which we try to update if so. This proposal is also no different in kind from our current practice of displaying GA/FA topicons, which we do for the exact same reasons, the only distinction being that a tagline has a slightly higher chance of actually being noticed. Sdkb talk 14:43, 20 August 2025 (UTC)Reply
    This is a great point – the worst possible downside of this process is still no worse than maintenance tags (giant reader-facing banners that serve as an often outdated disclaimer) and is effectively the same as the long-accepted reader-visible icons in the top right. The average case, though, is an improvement that helps readers: re why a reader should need to know anything about back-end processes in order to engage with articles, readers have long shown a vague understanding that Wikipedia might have some kind of content review process, but are still very much unaware of how we make these judgments. See for instance the many first-timer comments like "who wrote this crap it's all wrong" that have plagued article talk pages since the beginning of the project. Linking curious readers directly to Wikipedia:Featured articles tells them exactly how articles are reviewed and provides an overview of our content policies. Dan Leonard (talk • contribs) 15:03, 20 August 2025 (UTC)Reply

Discussion (tagline)

edit

@Dan Leonard: Can we not also have FLC, FAC, GAN? like so... 

{{#switch:{{#invoke:Page assessment raw|get_class|page={{FULLPAGENAME}}|project=Project-independent assessment}}
 | FA = A ''[[Wikipedia:Featured articles (linked from tagline)|featured article]]'' from
 | FL = A ''[[Wikipedia:Featured lists (linked from tagline)|featured list]]'' from
 | GA = A ''[[Wikipedia:Good articles (linked from tagline)|good article]]'' from
 | FAC = A ''[[Wikipedia:Featured article candidates/PAGENAME/archive#|featured article candidate]]'' from
 | FLC = A ''[[Wikipedia:Featured list candidates/PAGENAME/archive#|featured list candidate]]'' from
 | GAN = A ''[[Talk:PAGENAME/GA#|good article nominee]]'' from
 | From
}} Wikipedia, the free encyclopedia

OR, if getting the archive# and GA# might be tedious, we could simply say... Can we not also have FLC, FAC, GAN? like so... 

{{#switch:{{#invoke:Page assessment raw|get_class|page={{FULLPAGENAME}}|project=Project-independent assessment}}
 | FA = A ''[[Wikipedia:Featured articles (linked from tagline)|featured article]]'' from
 | FL = A ''[[Wikipedia:Featured lists (linked from tagline)|featured list]]'' from
 | GA = A ''[[Wikipedia:Good articles (linked from tagline)|good article]]'' from
 | FAC = A ''[[Wikipedia:Featured article candidates|featured article candidate]]'' from
 | FLC = A ''[[Wikipedia:Featured list candidates|featured list candidate]]'' from
 | GAN = A ''[[Wikipedia:Good article nominations|good article nominee]]'' from
 | From
}} Wikipedia, the free encyclopedia

--Vanderwaalforces (talk) 15:42, 11 July 2025 (UTC)Reply

I don't see the point in reader-facing indicators of article nominations. Best to be left for the talk page. Dege31 (talk) 16:10, 11 July 2025 (UTC)Reply
This RFC proposal is intentionally limited to be an extension to the topicons, which already get enough community support to exist. I disagree with this idea (drive-by junk GANs shouldn't be shown to readers) but also just don't think we should overcomplicate the proposal by going beyond what is already represented by topicons. Dan Leonard (talk • contribs) 16:30, 11 July 2025 (UTC)Reply
@Dan Leonard that makes sense. Vanderwaalforces (talk) 19:14, 11 July 2025 (UTC)Reply

Personally, I would better understand those on the oppose side for non-technical reasons, if they could bring in some real data, or real examples, of harm caused by the smaller outreach variants already extant: that is, the topicons, and the talk page assessments. After all, if it is problematic, there should already be evidence. I haven't seen this presented in significant levels. To me, these pitfalls feel remote, and rare. I feel like the potential downsides aren't so big that we can't even do a test run to see how it goes. The large majority of readers read within the confines of the lead paragraphs, so that lessens the potential cumulative impact, too.

Nonetheless, valid concerns. The supporters should also answer: is there will, and capability for scaling up the maintenance of these articles? While this has been ramping up in recent years, this imposes a higher standard.

I've also thought about an idea (this is not a proposal, but fuel for separate discussions, if I, or anyone else, wants to take it further) that maybe takes into account some of the reluctance. It would involve an article losing its reader-facing indicators of GA status or FA status after X years of no review, or Y edits if it's very high activity. That way, there would be a guaranteed minimal level of accountability. Dege31 (talk) 00:38, 12 July 2025 (UTC)Reply

Eh, it’s a cosmetic change to the website so I think it's fine to balk at it subjectively. It is a shame that my proposal can't have any data or examples of how this would improve reader outreach (although there does seem to be some interesting-looking papers on FAs), as any analysis of such data would only be possible post hoc. If this passes I do hope to do a 30 day postmortem to see how many people click on the statistical redirects and see how many new editors participate in the project pages. Dan Leonard (talk • contribs) 00:51, 12 July 2025 (UTC)Reply
As you mention, I don't think there's enough problems to scale up the maintenance yet. Aaron Liu (talk) 01:52, 12 July 2025 (UTC)Reply
Regarding scaling up the maintenance of these articles, I hope that one side benefit of this passing may be that, if GA/FA status confers additional prominence compared to the status quo, there will be both more incentive for editors to pursue that status for articles that deserve it and more editors noticing/sending to FAR/GAR when an article has that status that does not deserve it. Sdkb talk 04:43, 15 July 2025 (UTC)Reply

I see some people voicing opposition because of reservations regarding WP:Good articles, specifically. An alternative might be to implement this for FA and FL, but not GA. TompaDompa (talk) 11:46, 22 July 2025 (UTC)Reply

Yeah, I also think such a proposal would be more likely to be accepted. Sophocrat (talk) 06:58, 9 August 2025 (UTC)Reply

If this proposal fails, I think it might be worth it to consider something like the dewiki way (wording very tentative):

 This article became a reviewed good article on {date} in this revision.

and something similar for FA. Though I do wonder how long after the RfC closers should the discussion be started and whether it should be started even if it succeeds. Aaron Liu (talk) 03:42, 9 August 2025 (UTC)Reply

I just took a look at de.wiki and their rating system and I'd be more supportive about this proposal if our system would be more similar to theirs because their equivalent to GA "Lesenswerter Artikel" lit. "Article worth reading" reflects the meaning of GA a lot better than "good" in my opinion. But I get that that's unfeasible already because the translation is way too long and sounds a bit awkward. Squawk7700 (talk) 09:26, 9 August 2025 (UTC)Reply
I don't see how that's any better either. It still has all the problems other commenters say about "good article" above. Aaron Liu (talk) 15:39, 9 August 2025 (UTC)Reply
I agree, what I ment is the problem of what “good” means and the implied opposite of “Bad”. Squawk7700 (talk) 15:54, 9 August 2025 (UTC)Reply
the opposite of "worth reading" is "not worth reading", which is the same thing to me. Aaron Liu (talk) 15:59, 9 August 2025 (UTC)Reply
In addition, quality is not the only factor in what makes an article "worth reading" - a generally terrible article is very much worth reading if it contains a single reliable source that verifies as correct (or not correct) the one claim you are attempting to verify or it unlocks your understanding of whatever it is you are researching. Even a featured article is not worth reading if it doesn't contain the information you are looking for (which could be for many reasons, including not quite being in scope, the article being outdated, a source no longer being available, the relevant portion being removed (with or without consensus) or vandalised, etc). Thryduulf (talk) 16:20, 9 August 2025 (UTC)Reply
That changed my perspective, thanks. I totally agree Squawk7700 (talk) 16:47, 9 August 2025 (UTC)Reply
I don't like this as much. While I support any addition of plaintext with wikilinks, the English Wikipedia has long had opposition to emphasizing old revisions. See for instance the massive difference between how pending changes are used between German and English. I think it goes against the wiki model and its core belief that articles always get better over time. Articles should never have prominent links to old revisions. Dan Leonard (talk • contribs) 17:18, 9 August 2025 (UTC)Reply
Could you elaborate on the PendChang difference or the opposition, especially its reason? I think when the wiki model works, it's isn't at all bad to highlight how the article has evolved since it was established to pass a minimum standard. I don't see how the inclusion of the link leads to any default implication that the article got worse. It's just a tool for all the examine, serving the "transparency" part of our ethos. AFAIK even on enwiki, logged-out users see the latest approved revision (an old one) on PendChang-protected pages by default. Aaron Liu (talk) 17:47, 9 August 2025 (UTC)Reply
The reason we gave GAR and FAR is because classifying an article as GA or FA applies to future revisions, unless and until that status is revoked. It isn't just for the one reviewed version. If it were, we wouldn't still call them GAs and FAs or have processes for removal. Linking to historic revisions can confuse readers, especially when transcluded templates have since been deleted (the deletion of the lang-xx family breaks the first sentence of many historic revisions). Dan Leonard (talk • contribs) 22:12, 9 August 2025 (UTC)Reply
Those are about effectively applying pending changes to every single article. If we can have pending changes protection as it is at enwiki today, I don't see why we can't have a link to an old revision especially when it's labeled as an old revision. I still believe that having a link to the old revision is a useful point of comparison. Anyways, we can drop the revision link if needed. Aaron Liu (talk) 00:37, 10 August 2025 (UTC)Reply
I referred to enwiki's rejection of dewiki Gesichtete Versionen as an example of the philosophical differences in the wiki model. You can see arguments like incompatible with the basic principles behind wikipedia ... they no longer qualify as a wiki (Erachima), against wiki ethos (IanOfNorwich), creeping implementation of flagged revisions in disguise (S Marshall), 'A rose by any other name?' (OmniArticleEditor). The German Wikipedia's practice of placing a little check mark on specific logged revisions of articles, and presenting them to readers as if they are better than or more reliable than the current one, represents a significant change to the wiki model akin to Citizendium. Articles are assumed to still improve after promotion, and if they decline then they are demoted. Kusma already discussed this above, with the example of a dewiki article that links to an old revision without images or inline citations and has broken template calls (as I mentioned). Dan Leonard (talk • contribs) 01:08, 10 August 2025 (UTC)Reply
Thanks for the ping to this interesting discussion. Although I personally oppose any and all implementation of Pending Changes, vehemently and on a philosophical level, if we are going to have to put up with the awfulness of Pending Changes in our Wiki, then Pending Changes interacts with Good and Featured Articles in complex ways and I'm leery of one-size-fits-all decisions. I think we need to be mindful that Good and Featured Articles are an anomaly -- a holdover from old days of Wikipedia, back when we got to say things like "This is a good article" without having a reliable source for that contention. I think the fact that these assertions are made by Wikipedians rather than by trustworthy sources is highly relevant to the decision of whether to link them.
Some good and featured articles are about things that scholars have largely finished thinking about. If our subject matter is, say, Tropical Depression Ten (2007) then I'm with Aaron Liu. I don't think any massive reevaluation of that topic is likely, so I think we could quite legitimately pick one revision of that article and say, "This! This is the Featured Revision of this Featured Article!" and crystallize it thus for all time.
But other good and featured articles are about things that are still in flux. If our subject matter is, say, DNA nanotechnology then I'm with Dan Leonard. There could be a new discovery that could substantially change the article, at any time, and I would say that to pick one historical revision and imply that it's the platonic ideal of that article isn't the greatest idea I've ever heard.—S Marshall T/C 03:08, 10 August 2025 (UTC)Reply
I remember having discussions about pending changes in the past but with edit filters in place, this wikipedia seems prefer protection Logoshimpo (talk) 04:20, 10 August 2025 (UTC)Reply
Thanks. I really don't think having a message like what I mentioned at all implies the old revision being the apex. "became a good article in {revision}" retains the meaning of "everything after this" Dan mentioned.
I also find what's extracted from the pending changes discussion weird as applied here. It seems Dan's point is that this is supposed to illustrate opposition to presenting a specific revision with a checkmark, a star, or a plus sign. But that's what we've lived with and supported for a decade and a half, just not at the scale of every single mainspace article. Aaron Liu (talk) 03:46, 11 August 2025 (UTC)Reply

Proposal to clarify WP:AIGI in line with MOS:AIUPSCALE

edit
Latest comment: 1 day ago35 comments21 people in discussion

Background

edit

A previous RfC on the use of AI imagery resulted in WP:AIGI, which made it WP policy that images wholly generated by AI should not generally be used in articles, with certain exceptions, mainly relating to when the AI imagery itself is notable.

That policy applies to images wholly generated by AI. In WP:AIGI, cases of "major AI enhancement" are mentioned passingly as "marginal cases [...] subject to case by case consensus." The draft policy Wikipedia:AI image use gets a bit further into this, but I found that the topic was not discussed much in the original RfC, and so I am creating a new RfC to clarify what our policy should be relating to images substantially redrawn by generative AI, but based on an existing non-AI image.

As I understand, within the context of the previous RfC, images wholly generated by AI are understood to be those generated from a text-based prompt. Substantially AI-redrawn images are generated by AI using an image with a "restoration" function. In these cases, the AI image generator uses its models to create an image which matches (perhaps roughly) the original input image. Often, these functions are advertised as AI upscaling or restoration.

This topic is already covered in the editing guidelines, but not enshrined in WP:AIGI. See MOS:AIUPSCALE: "AI upscaling software should generally not be used to increase the resolution or quality of an old or low-resolution image. Original historical images should always be used in place of AI upscaled versions. If an AI-upscaled image is used in an article, this fact should be noted in its caption." However, this resulted from an earlier discussion which was not discussed in depth when the RfC which led to WP:AIGI took place.

Here is an example. The photo on the right has been significantly redrawn by generative AI in a way that is intended to match the original photo; the details and color, as can be seen here, did not exist in the input photo.

 

In another case (from Wikipedia:AI image use), we can see an old image and the output of this AI process:

Let me give some other examples of images "restored" using this process which I found in use on actual mainspace pages.

In some other cases, an image created using one of these processes is uploaded without the original to accompany it. However, even without an original for comparison, images created using this process are generally (as of 2025) visually identifiable. The details are unnaturally sharp in some places while being unnaturally soft or reduced in quality in other places in a distinctively uneven way. Some details are smoothed, while others are filled in with detail that clearly does not match the original image. As seen in some of the examples above, the "restored" versions of these images can add excessive and unnatural detail in the faces while leaving the rest of the image jarringly different.

The reason why these images look like this, of course, is because they are not actually produced via a photographic process, but are instead modified using software that searches for certain types of elements (e.g., faces) and uses generative AI to redraw those elements.

While this is most often done to "restore" images of faces, a similar process can be used to redraw other types of scenes. See, for example, commons:Category:Historical images of Minsk restored by AI.

  •  
    Original photo
  •  
    AI-regenerated version

Of course, I do recognize (as should not be controversial) that some of the original images are of low quality, and, where possible, I would like to replace images with better versions. However, I feel that any attempt to do so using AI is, at the very least, misguided. The MOS:AIUPSCALE guideline to avoid using these images seems sound to me, for a number of reasons.

  1. These images can be misleading, because they include details which are not part of the original historical images, distorting the historical images which should be incorporated into an encyclopedia.
  2. These images tend to look ugly and unnatural.

Proposal

edit

Should WP:AIGI be modified to incorporate MOS:AIUPSCALE? D. Benjamin Miller (talk) 21:48, 19 July 2025 (UTC)Reply

I propose the following:

  1. Since the topic of AI-redrawing (restoration, upscaling, enhancement) is closely and substantially related to the topic covered at WP:AIGI, the guideline at MOS:AIUPSCALE should be made part of the WP:AIGI (my suggestion) or, alternatively, linked from WP:AIGI as a relevant and related topic.
  2. Based on some discussion (I am not entirely sure myself), a clearer definition (or outline) of what constitues an AI-generated version of an existing image should be devised. Preliminarily, I suggest that this would relate to substantial details present in the original image being replaced by new AI-generated details (as opposed to a small portion of a corner or in a watermark-covered area being generated by cloning or a perceptibly equivalent process).

D. Benjamin Miller (talk) 21:41, 19 July 2025 (UTC)Reply

I would support the proposal, although I believe that MOS:AIUPSCALE already has broad consensus. Not sure if a more specific definition of "AI-generated version" is needed, as smaller adjustments would likely also fall under the upscaling guideline, and would have even less of a need to be used as a separate version from the original. Chaotic Enby (talk · contribs) 21:47, 19 July 2025 (UTC)Reply
While I had thought there was consensus, a recent debate I ran into hinged on whether this was prohibited by policy (with an editor replacing/overwriting various historical images with AI versions on this basis). I think the MOS item fairly clearly falls within the same spirit as the WP:AIGI policy, serving a similar purpose on a closely related subject, so the combination could be helpful.
The main reason I bring up clarification here is because not all AI modifications of this kind are labeled "upscaling," even if "restoration" or "recovery" AI tools are substantially the same as AI "upscalers." And if we expand the definition, then we could end up being too broad, especially since many tools now are advertised as "AI" due to the power of the buzzword. For instance, I don't think that the regular noise reduction you'd find in photo editing software (which is now sometimes marketed as "AI") should be covered, because it is fundamentally quite different from AI "restoration" tools.
(All that said, I think I know it when I see it — but it would be better to have a slightly more defined standard.) D. Benjamin Miller (talk) 22:04, 19 July 2025 (UTC)Reply
I think there should be something said about uploading as a separate version of a file if something like this is used, i.e. instead of overwriting historical_photo.jpg with an upscaled (or otherwise potentially controversially enhanced version) upload it as historical_photo_(upscaled).jpg to allow editors to easily choose whichever they believe is the better image for their usecase (not all usecases are necessarily going to result the same choice). Thryduulf (talk) 08:54, 20 July 2025 (UTC)Reply
MOS:AIUPSCALE was BOLD-ly added to the MOS after a brief discussion at Wikipedia talk:Manual of Style/Images/Archive 11#Upscaling. There was no RfC, so it should never have been added to the MOS, and there is zero consensus on a blanket ban on photo restoration. Hawkeye7 (discuss) 18:31, 23 July 2025 (UTC)Reply
Checking with the policy pump, I'm told that a full RfC isn't required to amend the MOS, per WP:PGCHANGE. The discussion you link to was open for three months on the talk page before I added the paragraph, including a month-long wait for any objections to the proposed wording. Removing the paragraph at this point would require a consensus. Belbury (talk) 15:31, 24 July 2025 (UTC)Reply
I think I support both proposals. I believe I was against a blanket ban on AI images last time around, but using AI to "upscale" existing images feels like a form of fabrication completely unlike asking AI to create a diagram. To me, it seems dishonest to suggest that the AI version is in any way equivalent to the original photo. I also support Thryduulf's point that upscaled images shouldn't be overwriting the original files. Toadspike [Talk] 12:53, 20 July 2025 (UTC)Reply
Support interlinking/inclusion, the two are complementary and drive towards the same goal. A guideline might be a continuous work in progress, but as a very basic point is that we should expect that all enhanced images include such information in their description, as we would expect for example for a black and white image where colour has been added even before generative AI. CMD (talk) 14:58, 20 July 2025 (UTC)Reply
I continue to oppose AI-generated imagery broadly, and so support the prohibition of AI upscaling as a subset of my overall position. I agree with Toadspike that it in many cases feels even more fraudulent to doctor historical works in this way than even to generate new images wholesale. Dan Leonard (talk • contribs) 03:37, 22 July 2025 (UTC)Reply
  • Oppose MOS:AIUPSCALE is null and void, as it is contrary to policy (WP:CONEXCEPT). Many of our images are on Commons and there is nothing we can do to prevent them being overwritten by AI upscaled images over there. This has already happened to me this morning: Commons replaced an image with an AI upscaled one, followed by an editor placing a drive-by tag, which I have removed, since there was no discussion on the talk page. Hawkeye7 (discuss) 19:34, 22 July 2025 (UTC)Reply
    What are you talking about? Commons:Overwriting existing files already says that uploading a AI "restorations," AI-upscaled files, etc. should not be uploaded over original files, so, per Commons rules. So we should be able to expect that any non-AI file shouldn't get replaced by an AI file on Commons. There is no reason that the ENWP policy or MOS cannot prohibit users from using AI-regenerated images present on Commons. (As for the file you seem to be talking about — your image was not replaced with an AI-upscaled one; the original image that you uploaded appears to already be AI-upscaled, and someone was just labeling it as such. D. Benjamin Miller (talk) 20:13, 22 July 2025 (UTC)Reply
    That was not the case. An AI-upscaled file was uploaded over the original file I uploaded. So we must expect that any file may get replaced by an AI-upscaled file on Commons. Their use is not prohibited by our WP:AIGI, because it only refers to images wholly generated by AI. Hawkeye7 (discuss) 01:15, 23 July 2025 (UTC)Reply
    The file that you uploaded is also AI upscaled. The file that was uploaded over only removes the AI-added color. Look at the two versions of the file closely and you will see that, except for the colorization, they are the same.
    And, as I referenced, Commons rules already explicitly prohibit uploading AI-generated versions over non-AI files. Do people always follow the rules there? Surely not always. But that's not what this proposal is about.
    If someone fails to follow the Commons rules, that has nothing to do with WP:AIGI or MOS:UPSCALE. My proposal here is to incorporate MOS:UPSCALE into WP:AIGI. D. Benjamin Miller (talk) 01:26, 23 July 2025 (UTC)Reply
    How can I tell if an image has been AI-upscaled? Hawkeye7 (discuss) 04:03, 23 July 2025 (UTC)Reply
    The original version is here Hawkeye7 (discuss) 04:34, 23 July 2025 (UTC)Reply
    You can see the high level of detail in the facial features (which is artificial — compare with the uniform), then the "halo" separating it from areas not redrawn by the AI process. The full-face depth of field (with sharp "focus" whereas the uniform is not nearly as sharp) makes the fakery obvious. D. Benjamin Miller (talk) 23:10, 23 July 2025 (UTC)Reply
    @Adam Cuerden: Pinging my go-to for image restoration for an opinion. Hawkeye7 (discuss) 04:37, 24 July 2025 (UTC)Reply
    The biggest giveaway for me that this was retouched by AI rather than by hand was that the lips are very, very slightly pink. It becomes much more apparent you boost the saturation levels. AI upscalers often can't resist adding a little lip and eye colour to black and white photos. Belbury (talk) 10:05, 24 July 2025 (UTC)Reply
    This rationale doesn't make sense. Just because a user on Commons might maliciously replace an image with an AI-"upscaled" version, does not mean we cannot have a policy prohibiting the use of upscaled images on English Wikipedia. Elestrophe (talk) 12:45, 24 July 2025 (UTC)Reply
  • Support a clearly-worded ban on AI-"upscaled" images, since the nature of their task is to fabricate details which were not present in the source image. The use of such images inherently violates WP:OR, and it should be explicitly worded in policy. Elestrophe (talk) 12:41, 24 July 2025 (UTC)Reply
  • Support enforcing a ban on faked and tampered images. Cremastra (talk · contribs) 15:40, 29 July 2025 (UTC)Reply
  • Support based on the OR concerns raised above, and for clearer alignment between AIGI and AIUPSCALE.--Trystan (talk) 18:15, 29 July 2025 (UTC)Reply
  • Support. The extra information in AI upscaled images comes from the biases and preconceptions of the AI model, which is not a reliable source. Readers are better informed by what the original image looks like, not by what an upscaler thinks it should look like. Barnards.tar.gz (talk) 19:44, 29 July 2025 (UTC)Reply
  • Support Regarding the point that the nom makes about the quality of original images, it is in fact the case that the worse the quality of the original image is the more the AI will have to make up details to get (what presumably the prompter) thinks is an adequate quality. It should go without saying that the point of images on Wikipedia is primarily one of decoration point of images on Wikipedia is not primarily one of decoration. Cakelot1 ☞️ talk 14:37, 5 August 2025 (UTC)Reply
    Do you mean the opposite of that? Images on Wikipedia are not primarily for decoration. jlwoodwa (talk) 21:36, 5 August 2025 (UTC)Reply
    Yes, It should have said "not" decorative. Apologies, for any confusion Cakelot1 ☞️ talk 09:21, 12 August 2025 (UTC)Reply
    An awful lot of the images placed in articles are purely decorative. Donald Albury 23:07, 5 August 2025 (UTC)Reply
  • Support, for the reasons above and also because we should have as few contradictions and misalignments in our guidelines as possible. Gnomingstuff (talk) 19:06, 9 August 2025 (UTC)Reply
  • Support indefinite ban on AI-upscaled images, regarding the quality and texture of images. This violates MOS:IMAGE, and Wikimedia Commons should further discuss regarding about this. Fabvill (Talk to me!) 04:31, 10 August 2025 (UTC)Reply
  • Support ban on AI-upscaled images -- as people above have said, the AI upscale page already has decent consensus, and, less circularly, details invented by AI but presented as photographic are misleading and bad. The best images available should be provided, and if they are limited we shouldn't make up stuff and rely on some illusion that an AI making up things is more reliable or "true" than a human making up things. Mrfoogles (talk) 18:05, 24 August 2025 (UTC)Reply
  • Support ban on AI-upscaled images per above and others. >^CreativeLibrary460 /access the library revision\ 17:24, 25 August 2025 (UTC)Reply
  • Support. Agreed that the images are deceptive in principle, and noticeably unnatural in practice. There's also a practical concern that we would accumulate a long tail of mediocre upscales, creating a need to redo them regularly with better models. Most would also use not the best models but the cheapest ones, and we'd have no way to know which model was used, which will be needed when a systematic defect is inevitably found in the details invented by some model or other, akin to the Xerox JBIG2 bug. DFlhb (talk) 22:19, 28 August 2025 (UTC)Reply
  • Support – per Elestrophe, this is needed. FaviFake (talk) 10:26, 29 August 2025 (UTC)Reply
  • Partial support, partial oppose. As is sadly common when AI is discussed on Wikipedia, all nuance has gone out the window in favour of "AI bad". I support a prohibition on replacing an existing file with an AI-upscaled version, I oppose a complete ban on all AI-upscaled images. It should be for editors to evaluate in each individual instance whether the original version or the AI upscaled version is more encyclopaedic in the context - even if the answer to that is the original 99% of the time we harm the encyclopaedia by prohibiting the upscaled version in the 1% of cases without getting any benefit whatsoever from doing so. The first examples that come to mind are articles discussing AI-upscaling and where an AI-upscaled image is notable (e.g. it's a viral image). Thryduulf (talk) 13:04, 29 August 2025 (UTC)Reply

Wikipedia:Content contradictory to other language versions

edit
Latest comment: 8 days ago4 comments3 people in discussion

Hello,

I am the starter of this project. I would like to revive it. Kind regards Sarcelles (talk) 02:52, 1 August 2025 (UTC)Reply

You were essentially the only editor of the page and it has almost no inbound links, so I think it would be fine for you to move it to userspace now, fully overhaul it, and when it's up-to-date, propose moving it back to the Wikipedia namespace. Dan Leonard (talk • contribs) 19:09, 1 August 2025 (UTC)Reply
Hi Sarcelles, I figure you are a multilingual editor given the nature of your project. I speak a few additional languages, and would like to contribute to it. I have a couple suggestions for improvement though. First, per Dan Leonard, given that you are the only editor of that page, in its current state it probably belongs in your userspace.
Second, aside from the detailed contribution by 84user, the existing posts lack detail and clarity. Given the age of these contributions, I would archive the existing page, add more information to the introduction, and add some new contributions, should you have any. Agentdoge (talk) 15:03, 13 August 2025 (UTC)Reply
By this writing, I ask for a move to my userspace.
Kind regards, Sarcelles (talk) 16:57, 22 August 2025 (UTC)Reply

RfC: Update messagebox module with new Codex icons

edit
Latest comment: 14 hours ago204 comments44 people in discussion

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)

  Moved from Module talk:Message box § c-Waddie96-20250810120600-Update icons to Codex


Proposal to update the icons in Module:Message box/configuration from the current Ambox ones, to the new icons from Codex Design System for Wikimedia. (See below.)

The swops I'm recommending
  •  
    ambox.speedy .delete
  •  
    ambox.content
  •  
    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

Survey (Codex icons)

edit
  • Oppose No actual problem is being solved here, just pointless style changes for the sake of style changes. The current icons are fine. * Pppery * it has begun... 17:33, 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'm not convinced that was a good idea either. * Pppery * it has begun... 18:59, 10 August 2025 (UTC)Reply
    I'm unconvinced that style changes are pointless, and that no problem is being solved when visual appearance is improved. waddie96 ★ (talk) 15:10, 11 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
  • Support: consistency is always a good thing, and it's always a good idea to match what MediaWiki's doing. —Matrix(!) ping onewhen replying {u - t? - uselessc} 17:35, 10 August 2025 (UTC)Reply
  • Oppose per Pppery. It's also unclear what File:Merge-split-transwiki default.svg is replacing or being replaced by given it is the same icon used for requested moves currently. Tenshi! (Talk page) 17:49, 10 August 2025 (UTC)Reply
    @Tenshi Hinanawi: It's not replacing anything. —Matrix(!) ping onewhen replying {u - t? - uselessc} 18:28, 10 August 2025 (UTC)Reply
    Then I don't see any value in including it here when discussing changing icons between Codex and existing icons. Tenshi! (Talk page) 18:39, 10 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
    I tend to agree with the horrible, low-contrast, and at small sizes unsightable waddie96 ★ (talk) 15:13, 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
    I agree that the paintbrush licensing would be a major issue. However, I would expect WMF legal to somehow square it in the end, given the broom icon was created by the WMF itself and for a project to display amboxes on mobile as indicated by the broom image's source field. Aaron Liu (talk) 02:50, 11 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
  • Comment, considering how board this is, is it worth making into an RfC? —Matrix(!) ping onewhen replying {u - t? - uselessc} 21:55, 10 August 2025 (UTC)Reply
    I think so. I'd Template:Centralized discussion it even. And notify the users who previously discussed a similar discussion from @Awesome Aasim; to lazy to find the list right now. Aaron Liu (talk) 02:50, 11 August 2025 (UTC)Reply
    I didn't open the RfC... I didn't think it was at that stage yet either. waddie96 ★ (talk) 15:25, 11 August 2025 (UTC)Reply
  • Support, what matrix said, I'm not a fan of the current iconset since it makes things needlessly busy. -- Sohom (talk) 02:24, 11 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
  • 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'd replace   with   but otherwise everything else looks good. Aasim (話す（はなす）) 04:14, 11 August 2025 (UTC)Reply
    I think the former is more readable. Aaron Liu (talk) 19:59, 11 August 2025 (UTC)Reply
    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:
Normal Monochromacy
                               
Normal Monochromacy
                               
  • 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.
    I am struggling to figure out the CSS needed to accurately simulate protanopia, deuteranopia, tritanopia, etc. Maybe you can add it? {{color blindness check}} Aasim (話す（はなす）) 05:38, 19 August 2025 (UTC)Reply
    At that point I would just use the in-browser simulation devtools. Aaron Liu (talk) 16:45, 19 August 2025 (UTC)Reply
  • 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. Theres nothing wrong with the current icons. And this proposal doesn't account for maintenance templates that don't use these icons such as {{more citations needed}} and {{update}}. 2A0E:1D47:9085:D200:EDFB:7835:FC79:242D (talk) 10:22, 12 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 Codex icons function better in dark mode. Neutral on the broom change since in the new icon isn't Codex. – SD0001 (talk) 13:58, 12 August 2025 (UTC)Reply
  • Support most, oppose broom WP: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
  • Support on the basis of consistency as other users have pointed out, and I personally find the new icons easier to read. Note also that the mobile website already has different icons following this style, and a substantial proportion of users now view Wikipedia on mobile.  novov talk edits 07:45, 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.  novov talk edits 04:37, 14 August 2025 (UTC)Reply
  • Oppose The proposed icons are all worse — GhostInTheMachine talk to me 08:14, 13 August 2025 (UTC)Reply
  • Oppose All the proposed icons are ugly, and the existing ones look better. License is not a reason to change them. Graeme Bartlett (talk) 12:00, 13 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
    Yep, I did mean "shouldn't" Sohom (talk) 19:00, 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
    For the record I agree that option two looks bad. It might even introduce colorblind accessibility issues. Aaron Liu (talk) 17:39, 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
    Awesome! That would be a Support from me (if those other icons were actually changed to Codex). The main thing I was worried about was {{More citations needed}} as that is (unfortunately) a very common template on articles. OutsideNormality (talk) 05:23, 18 August 2025 (UTC)Reply
    Support from me as well (maybe this needs to be it's separate proposal?) Sohom (talk) 05:31, 18 August 2025 (UTC)Reply
  • Oppose, solution in search of a problem. Stifle (talk) 08:10, 15 August 2025 (UTC)Reply
  • Oppose, as a rare discussion where IDONTLIKEIT is a valid rationale. charlotte 👸♥ 17:46, 15 August 2025 (UTC)Reply
  • Oppose, solution in search of a problem. The existing icons are fine (even in dark mode I don't see any issues) as far as I know, and this proposal feels like bikeshedding. No need to fix something which isn't broken. JavaHurricane 10:26, 17 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
  • Oppose for several reasons, the most important of which is that the newer suggestions are substantially...ugly ~ LindsayHello 17:10, 20 August 2025 (UTC)Reply
  • Oppose The current icons look better than the proposed ones. Some1 (talk) 23:28, 20 August 2025 (UTC)Reply
  • Oppose per above. >^CreativeLibrary460 /access the library revision\ 02:04, 21 August 2025 (UTC)Reply
  • Support all, the current icons are too old. These also match the padlock icons we use for protected pages. --FaviFake (talk) 12:38, 21 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
  • Support except paintbrush. WP:Accessibility is a minimum requirement, so if the old icons don't work in dark mode, we have to move away from them anyway. Might as well use the Codex icons. —Femke 🐦 (talk) 07:26, 24 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
  • Support for consistency with the UI, though improve the broom. Graham11 (talk) 19:21, 24 August 2025 (UTC)Reply

Discussion (Codex icons)

edit
  • 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:
    Status quo:
Light mode Dark mode
               
  • Codex:
Light mode Dark mode
               
  • OOUI:
Light mode Dark mode
               
Light mode Dark mode
Tango
        (Status quo)
Codex
        (Proposed)
Tango
        (Status quo)
Codex
        (Proposed)
  • Aaron Liu (talk) 19:52, 11 August 2025 (UTC)Reply
    Sorry but putting the icons in black background is incorrect, they actually flip to white on skin-invert on MediaWiki.org waddie96 ★ (talk) 02:18, 12 August 2025 (UTC)Reply
    No they don't, or at least the tags at mw:Extension:Graph don't. The boxes here and there do not have the skin-invert class and the current icons don't get inverted in dark mode either. Aaron Liu (talk) 02:49, 12 August 2025 (UTC)Reply
    I'm in dark mode and all the icons under #The swops I'm recommending have light backgrounds. As do all the examples above in both the light and dark mode columns. CMD (talk) 02:54, 12 August 2025 (UTC)Reply
    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
    Wikipedia:Dark mode (gadget). Interesting that it functions differently to the appearance menu version. CMD (talk) 14:22, 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
    @Waddie96 What‽ That was uncalled for and I do not see your reasoning. I would advise you strike this WP:personal attack and focus on the arguments instead. Aaron Liu (talk) 02:51, 12 August 2025 (UTC)Reply
    Okay waddie96 ★ (talk) 02:55, 12 August 2025 (UTC)Reply
    Why not have the cleanup icon be File:Broom (PSF).jpg
    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: Aasim (話す（はなす）) 07:00, 12 August 2025 (UTC)Reply
  • The swops I'm recommending. What's a swop? Is that a typo for swap? –Novem Linguae (talk) 21:39, 11 August 2025 (UTC)Reply
    Not a typo, but a valid British English spelling variation. --Redrose64 🌹 (talk) 22:40, 11 August 2025 (UTC)Reply
    @Novem Linguae Why is this an insult competition? Are most the readers in this discussion from the USA? waddie96 ★ (talk) 02:20, 12 August 2025 (UTC)Reply
    I do not see reason to not Wikipedia:Assume good faith of Novem simply not knowing that spelling here. Aaron Liu (talk) 02:52, 12 August 2025 (UTC)Reply
    I went ahead and struck my comment. Should have googled first to see if this was ENGVAR. Thanks for letting me know. –Novem Linguae (talk) 08:33, 12 August 2025 (UTC)Reply
  • 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
    When I look in classic Vector, I see icons that are less harsh than these. If only because they're not 40×40px. Anomie⚔ 14:40, 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
    I think it is a bug, error messages from Codex have truncated icons too. Aasim (話す（はなす）) 21:05, 12 August 2025 (UTC)Reply
    Codex icons getting cut off is probably phab:T398529. –Novem Linguae (talk) 22:09, 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
    We do have  , 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)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
    waddie96 ★ (talk) 21:06, 15 August 2025 (UTC)Reply
    Color can be fixed pretty easily by changing it in the svg syntax. Sohom (talk) 23:49, 18 August 2025 (UTC)Reply
    How about  ? Aaron Liu (talk) 18:28, 20 August 2025 (UTC)Reply
  • 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
    I already believe the magnitude of this discussion is bikeshedding, let alone a whole Manual of Style page. Template colors aren't that important, accessibility aside (and that isn't the case for this proposal). Sophocrat (talk) 03:26, 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

Pings (Codex icons)

edit
From the original padlock discussion

User:SoWhy User:John Cline User:Boing! said Zebedee User:Amorymeltzer User:Frayae User:Rehman User:MarginalCost User:SemiHypercube User:Sandstein User:Ferret User:Pkbwcgs User:Funplussmart User:Zchrykng User:Ammarpad User:Alsee User:Jayron32 User:Barkeep49 User:Feminist User:JC7V7DC5768 User:Wugapodes User:Ruslik0 User:Headbomb User:Reywas92 User:Tazerdadog User:Mandruss User:Mz7 User:Ajpolino User:ElHef User:GermanJoe User:Cabayi User:Cthomas3 User:Tom (LT) User:Spintendo User:Teratix User:Abelmoschus Esculentus User:L235 User:weegaweek User:MichaelMaggs User:Kirbanzo User:Axisixa User:Alanscottwalker User:FenixFeather User:sp User:Thryduulf User:Elmidae User:LindsayH User:PointyOintment User:Pretended leer User:MusikAnimal User:Kudpung User:QEDK User:28bytes User:William Avery User:Theinstantmatrix User:Jonathunder User:Insertcleverphrasehere User:Ahecht User:Jéské Couriano User:De728631 User:-sche User:Patar knight User:Renata3 User:KCVelaga User:TheDragonFire300 User:Galobtter User:Ivanvector User:Tryptofish User:BrandonXLF User:CASSIOPEIA User:Dreamy Jazz User:Joshualouie711 User:Shoy User:344917661X User:pythoncoder User:Jc86035 User:Nosebagbear

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

Trout to me I guess —Matrix(!) ping onewhen replying {u - t? - uselessc} 15:00, 11 August 2025 (UTC)Reply
Because files displayed in dark mode have opaque backgrounds, I have compiled all the icons discussed to date (as well as a few color variations) at User:LaundryPizza03/Codex test as they would appear in amboxes, which do not have his limitation. –LaundryPizza03 (dc̄) 16:46, 21 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

Question 2: Should we update the warning and block templates to use Codex/OOUI icons?

edit
  • Temp block:
    Light mode Dark mode
      →     →  
  • Indef block:
    Light mode Dark mode
      →     →  
    • Indef block (option B):
      Light mode Dark mode
        →   (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:
Normal Monochromacy
                                               
Aasim (話す（はなす）) 19:37, 18 August 2025 (UTC)Reply
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
Oppose a solution in search of a problem. The new icons are also harder to see in dark mode because of their flat design. Cremastra (talk · contribs) 19:18, 18 August 2025 (UTC)Reply
Oppose all of these for basically the same reasons I oppose the main proposal. * Pppery * it has begun... 19:30, 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
Oppose per cremastra. -- 📎 JackFromWisconsin (talk | contribs) 01:25, 19 August 2025 (UTC)Reply
Oppose, new icons are much harder to distinguish from one another. CMD (talk) 04:29, 19 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
There are four different red blobs with white dots in them. CMD (talk) 02:57, 20 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
Oppose per my rationale above. JavaHurricane 18:19, 19 August 2025 (UTC)Reply
Oppose per explanations above. These new proposed icons seem to be unclear. Fabvill (Talk to me!) 08:49, 20 August 2025 (UTC)Reply
Support – they don't seem unclear to me. --FaviFake (talk) 14:03, 21 August 2025 (UTC)Reply

Discussion (Q2)

edit
  • 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 closest we have to a Codex-style stop sign with an X is  , 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)Reply

Question 3: Should we update the unblock templates to use Codex/OOUI icons?

edit
  • 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:
Normal Monochromacy
                               
Aasim (話す（はなす）) 19:37, 18 August 2025 (UTC)Reply
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
Support. Noting that the Wikipedia:Unblock wizard (functional, but still in development) uses the Codex icons. Chaotic Enby (talk · contribs) 19:26, 18 August 2025 (UTC)Reply
Oppose all of these for basically the same reasons I oppose the main proposal. * Pppery * it has begun... 19:30, 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
If someone is trying to understand a block message based purely on the decorative icon, no change is going to be sufficient to help them. Cremastra (talk · contribs) 23:42, 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
Oh, and not appearing BITEY while still being effective in communication. Aasim (話す（はなす）) 05:49, 19 August 2025 (UTC)Reply
Here's an icon that I found that might work for the "unblock declined": Material Symbols & Icons - Google Fonts
It does need to be recolored to be red, but otherwise is fine. Aasim (話す（はなす）) 22:20, 19 August 2025 (UTC)Reply
These icons appear to be licensed under Apache 2.0, which (TOO considerations aside) might be problematic for our use case? Chaotic Enby (talk · contribs) 22:31, 19 August 2025 (UTC)Reply
Would also be inconsistent style-wise even if you use this sharp-and-rounded version. And I'd say it's debatable whether literal interpersonal disapproval is any better than a red cross. Aaron Liu (talk) 23:40, 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
Oppose per Anomie. JavaHurricane 18:21, 19 August 2025 (UTC)Reply
Support the tick and cross: mw:Template:Tick   and mw:Template:Cross  . waddie96 ★ (talk) 20:35, 20 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!).
If you're looking for icons The Noun Project and Material Design 3 have great PD and freely licensed icons. A lot are uploaded to already Commons too: Just search the 'term' of the icon plus 'icon svg' or 'icon' and it'll come up. waddie96 ★ (talk) 20:42, 20 August 2025 (UTC)Reply
Oppose per my comment above in Question 1. Some1 (talk) 23:31, 20 August 2025 (UTC)Reply
Support – Anything other than a clock with different colors is better. And these also look decent. --FaviFake (talk) 14:04, 21 August 2025 (UTC)Reply

Discussion (Q3)

edit

Question 4: Should we replace the icon for current events?

edit
  •  
    Previous
  •  
    New
In addition, the {{current events}} icon replacement could be. Let me know what you think. waddie96 ★ (talk) 20:35, 20 August 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.
I don't think the proposed icon is Codex, either, so I'm not sure what the argument for replacement is in this case. Cremastra (talk · contribs) 20:39, 20 August 2025 (UTC)Reply
I accept your response. I'm just interested why you say anti-Mediterranean conspiracy theorist? waddie96 ★ (talk) 20:43, 20 August 2025 (UTC)Reply
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
@Cremastra But seriously, why do you say the person who drew the Earth is an anti-Mediterranean conspiracy theorist? waddie96 ★ (talk) 20:45, 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:
A better direction to head, I think, would be:
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

Discussion (Q4)

edit

Proposer is changing icons in mboxes

edit

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

Considering this discussion is still ongoing, I'd suggest someone revert and warn the user about Wikipedia:Fait accompli. Hopefully they stop so it doesn't have to escalate to a block. Anomie⚔ 12:27, 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. 😄
Do you mind confirming I have reverted appropriately or if I missed anything? waddie96 ★ (talk) 13:27, 30 August 2025 (UTC)Reply

Change all "Chinese Communist Party (CCP)" references to the official name, Communist Party of China (CPC)

edit
Latest comment: 11 days ago6 comments6 people in discussion

I've read a lot of Wikipedia articles about politics and I think they can be really helpful. However, it is undeniable that Wikipedia is dominated by liberal ideology and analysis, with a strong bias towards it. I believe Wikipedia should do more to consider outside perspectives, and a good way to do that would be using the official English name for the ruling party of the People's Republic of China, the Communist Party of China (CPC). Most articles on this wiki refer to the party using the name preferred by western media, which is incorrect and serves only to further the impact of these media outlets' ideological bias on the content of the English Wikipedia. Just because liberalism is the dominant ideology of the imperial core does not mean that liberal analysis is always correct. I would love to see more proper materialist analysis and better representation of diverse views on Wikipedia, and removing content indicative of liberal bias would definitely help us get there. Bunabyte (talk) 20:34, 11 August 2025 (UTC)Reply

I don't think a liberal vs. other ideological worldview has any real bearing on the decision to use CPC or CCP. Have you tried reading the prior discussions that we've had on English Wikipedia about this? From Talk:Chinese Communist Party: The name "Chinese Communist Party" is more commonly used by reliable sources in the English language. Consensus on the current title was reached on 23 July 2020 (see discussion). As of May 2024, there have been five failed proposals to revert this decision due to a lack of policy-based arguments (i.e. pertaining to WP:MOVE) on the part of the proposers. You should review those discussions and see whether you have any novel arguments to present. As one might say, if you have not investigated, you have no right to speak. signed, Rosguill talk 20:39, 11 August 2025 (UTC)Reply
Thanks for doing this lol. I wish we could highlight this response to copy paste waddie96 ★ (talk) 21:25, 15 August 2025 (UTC)Reply
Any article that mentions the Chinese Communist Party by name is liable to have that article hyperlinked, where the first 13 words of that article will clarify any confusion caused by not using the official name. Agentdoge (talk) 14:47, 13 August 2025 (UTC)Reply
Not sure what liberal ideology has to do with WP:COMMONNAME. In English people refer to the CCP as the CCP. Polygnotus (talk) 10:04, 19 August 2025 (UTC)Reply
Most reliable English language sources refer the CPC as "CCP". Per WP:COMMONNAME, there's nothing we can overturn the decision backed indirectly by available reliable sources. Outside Wikipedia, I would always refer the CPC by the proper name and acronym. Ahri Boy (talk) 10:15, 19 August 2025 (UTC)Reply

Function of idea lab

edit
Latest comment: 11 days ago15 comments6 people in discussion

I believe Village pump (idea lab) was conceived as an incubator for ideas, not as "pre-discussion" or gatekeeper for this page. In my opinion, editors should contribute to the development of the idea or sit out that discussion. If the thread is archived without any response, that's fine.

By "pre-discussion", I mean talk about the merits of the idea, which is for this page, not VPI. I'm not interested in hearing a small handful of editors at VPI telling me why my idea isn't needed or won't work. That's too much power in the hands of too few.

Sure, there is no hard rule that I can't bring my idea to this page after it was shot down at VPI. But that has been the expectation in my experience with VPI. I may have missed it, but I have never witnessed such a "VPI override"; so I guess most editors perceive the same expectation.

My use of the first person is merely a rhetorical device. My focus is on the editing community, not my personal needs and desires. ―Mandruss ☎ IMO. 03:34, 14 August 2025 (UTC)Reply

Is there something specific this is in response to? Gnomingstuff (talk) 06:47, 14 August 2025 (UTC)Reply
No. ―Mandruss ☎ IMO. 07:06, 14 August 2025 (UTC)Reply
Not really sure what you're proposing then. Gnomingstuff (talk) 11:31, 14 August 2025 (UTC)Reply
editors should contribute to the development of the idea or sit out that discussion. This is a departure. ―Mandruss ☎ IMO. 17:16, 14 August 2025 (UTC)Reply
I feel like that's what I'm doing? You've expressed your opinion about what editors should do. You haven't actually made any "concrete, actionable proposals." Gnomingstuff (talk) 17:47, 14 August 2025 (UTC)Reply
I feel like that's what I'm doing? Huh? I'm talking about how VPI operates.
You haven't actually made any "concrete, actionable proposals." I would've thought it was obvious, but here you go: I, Mandruss, being of sound mind if not body, hereby propose that editors at VPI refrain from commenting on an idea's merits, which should be reserved for this page. This discussion would represent a community consensus that could be enforced with reference to this discussion in the archive. Optionally, something to this effect could be added at the top of VPI with a link to this discussion. How bout that? ―Mandruss ☎ IMO. 17:58, 14 August 2025 (UTC)Reply
The only outcome for that will be a lot of time wasted developing ideas that have no merit into proposals that can never get consensus. Thryduulf (talk) 21:39, 14 August 2025 (UTC)Reply
Also it would be near impossible to stop people from commenting on an idea's merits, and a lot of work to police that. Polygnotus (talk) 10:07, 19 August 2025 (UTC)Reply
Suggesting that the idea is not worth spending further time and attention on is a contribution to the development of the idea. Anomie⚔ 14:15, 14 August 2025 (UTC)Reply
Too much power in the hands of too few. Roll the dice on a different day, when editors A, B, and C are out but editors D, E, and F are in, and you might very well get a different answer. A lot of this has to do with perspective, not some imaginary Truth. Experienced editor A thinks X is a problem. Experienced editor B has different experience than A, so he knows that X isn't such a problem. What happens when B isn't around during the discussion? Also, different editors will weight the factors differently. ―Mandruss ☎ IMO. 17:14, 14 August 2025 (UTC) Edited after reply 17:41, 14 August 2025 (UTC)Reply
Only if the discussion is closed/archived after the first small number of responses. There are a lot of reasons why someone might suggest that a given idea is not worth spending further time and attention on, including but not limited to:
  • The idea is not technically possible.
  • The idea has been suggested and rejected previously.
  • The idea is fundamentally incompatible with Wikipedia's core purpose/values (e.g. the recent idea to actively encourage original research)
  • It was tried previously and didn't work.
  • It duplicates existing functionality/processes/projects
  • A very similar idea is already being discussed/developed
  • It doesn't make any sense
  • I don't like it
The next steps for each of these differ and not all of them (arguably none of them) are final, but all of them (except possibly the last) can be useful feedback. Not every idea is a good one, and sometimes that's obvious to everyone, including the OP, when they know a certain thing but the OP doesn't know that (and there could be very many reasons for that). If nobody was allowed to say these sorts of things then they would be unable to learn and would potentially waste more of their/the community's time raising the issue again (in different venues). Thryduulf (talk) 17:36, 14 August 2025 (UTC)Reply
Many people have ideas, which is a good thing, but I reserve the right to say that "Wikipedia should make me a cup of tea in the morning" is a bad idea, wherever it is proposed. You, of course, have the right to ignore me. Phil Bridger (talk) 10:46, 17 August 2025 (UTC)Reply
Hyperbole. I seriously doubt anything approaching such a ridiculous idea has ever been raised at VPI (unless on 1 April or trolling), so your example is not useful here. ―Mandruss ☎ IMO. 13:05, 17 August 2025 (UTC)Reply
Many suggestions with equal likelihood of success have been made. Some examples include Wikipedia:Village pump (idea lab)/Archive 67#add games, Wikipedia:Village pump (idea lab)/Archive 67#pride flag, Wikipedia:Village pump (idea lab)/Archive 64#dissensus as an alternative to consensus, Wikipedia:Village pump (idea lab)/Archive 64#Implemeting "ChatBot Validation" for sentences of Wikipedia, Wikipedia:Village pump (idea lab)/Archive 64#Wikipedia 1 minute name change, etc. Thryduulf (talk) 08:39, 18 August 2025 (UTC)Reply

Replace all description lists without prior description terms in article namespace with appopriate alternatives

edit
Latest comment: 4 days ago26 comments9 people in discussion
  Moved from Wikipedia:Bot requests § Replace all description lists without prior description terms in article namespace with appopriate alternatives
 – Sapphaline (talk) 16:51, 15 August 2025 (UTC)Reply

There are currently approximately 13k articles with description list markup without prior description term markup, according to this search query. This is not allowed per Wikipedia:Manual_of_style#Indentation. So I propose to:

  • When this markup is used for indenting numbers (:1, : 1), replace with ordered list When this markup is used for an ordered list (:1. or : 1. followed by :2. or : 2. on a new line), replace it with proper ordered list markup (#);
  • When used just for a list (two or more : separated with a newline), replace it with bulleted list (*);
  • When used for a list inside a list (:* or :# or :: after a *), replace it with ** or ##;
  • When used just for indenting text (a single : without further list markup), replace it with Template:Block indent.

Sapphaline (talk) 16:08, 10 August 2025 (UTC)Reply

This likely needs consensus for such a task considering the last point verges on not being a substantive change per WP:COSMETICBOT. Tenshi! (Talk page) 16:26, 10 August 2025 (UTC)Reply
Any page where I can discuss this more? Sapphaline (talk) 17:13, 10 August 2025 (UTC)Reply
WT:MOS might be a good place to start. Primefac (talk) 17:29, 10 August 2025 (UTC)Reply
I mean, discuss reaching consensus for doing (or not doing) my request. I don't think that the talk page for discussing improvements to the Manual of Style page is the right place for that. Sapphaline (talk) 19:06, 10 August 2025 (UTC)Reply
Well, I was going to send you to WT:WPMOS but the banner at the top says that WT:MOS is the place to start discussions. Primefac (talk) 21:37, 10 August 2025 (UTC)Reply
Maybe Wikipedia:Village pump (proposals) will be a better fit? Sapphaline (talk) 07:50, 11 August 2025 (UTC)Reply
That's not cosmetic though, it's a critical fix. The chronic misuse of definition list formatting breaks the screen-reader experience, and so repairing it with proper HTML indentation is substatntive. Dan Leonard (talk • contribs) 22:08, 17 August 2025 (UTC)Reply
  • I'm not sure introducing a template to take over the role of : is a great idea - I'm all for replacing HTML and magic words where possible, but I think headers, links, indents and lists should be managed with punctuation.
  • It would be quite nice to have multiple list/indents on one line correctly laid out, the only issue is it would make it harder to transfer a chunk from one list to another.
  • Just because a colon (etc.) is followed by a number it doesn't follow that it's an ordered numbered list, let alone one supportable by *.
    3 calling birds
    5 gold rings
    1924 Birth of Jim Catchowsky
    1225 Publication of the Necronomicon
All the best: Rich Farmbrough 22:01, 11 August 2025 (UTC).Reply
Just because a colon (etc.) is followed by a number it doesn't follow that it's an ordered numbered list - then replace all : with # when there's a :1. or : 1. followed by :2. or : 2. on a new line. Sapphaline (talk) 16:51, 15 August 2025 (UTC)Reply
Are you under the impression that : is an indentation marker? It's not, and misuses as such should be corrected per MOS:BADINDENT. Dan Leonard (talk • contribs) 17:07, 18 August 2025 (UTC)Reply
For cases where an unbulleted list is appropriate, I think {{Unbulleted list}} should be used. For convenience, a wrapper template that adds margins to match the current appearance can be created. isaacl (talk) 18:03, 15 August 2025 (UTC)Reply
This will require a human reviewing all replacements, which is quite impractical for bot edits affecting 13k pages. Sapphaline (talk) 18:10, 15 August 2025 (UTC)Reply
wrapper template that adds margins to match the current appearance can be created - no need for that as Template:Unbulleted list supports inline styles. Sapphaline (talk) 18:16, 15 August 2025 (UTC)Reply
Yes, I'm aware of this parameter. That's why I said "for convenience", since it would ensure commonality and facilitate fixes if necessary.
I'm wary of automatically replacing the markup with a bulleted list without manual review. Using a block indent might be a more appropriate automated approach. isaacl (talk) 21:46, 15 August 2025 (UTC)Reply
Regarding cosmetic changes: since the change would alter how screen readers and other assistive technology describe the page, changing a description list to another form of formatting would be a substantive change. isaacl (talk) 18:06, 15 August 2025 (UTC)Reply
Support replacing definition-list formatting with proper indentation and numbered lists wherever possible (in article space, the ship has sailed on use of : in discussions). This is a great accessibility fix. Writing the regular expressions, however, will likely be tricky. Dan Leonard (talk • contribs) 16:40, 21 August 2025 (UTC)Reply
I support making changes of this form. I'm not totally certain I'm convinced of an unassisted bot because this feels like you could quickly run into WP:CONTEXTBOT issues. Izno (talk) 23:46, 23 August 2025 (UTC)Reply
I wonder how many of these are math articles. Look for the paragraph in MOS:MATH that begins A frequent method for displaying formulas on their own line has been to indent the line with one or more colons (:). I'm pretty sure this was officially recommended back in the day. WhatamIdoing (talk) 00:08, 24 August 2025 (UTC)Reply
Probably a significant chunk of this search is of that flavor (: :<math>), but the ^ operator doesn't work as expected so I can't refine the search any further (phab:T317599 should support it since \s is also now supported, which would incidentally tighten up the search that OP has provided us and maybe actually get it to complete).
To answer the question of recommendations, yes, that was recommended. It's not anymore for the same reason this topic is under discussion. The replacement with the preferred (<math display="block">) is trivial, but I suppose is a case where the suggested algorithm is bad.
I did think of another case here where CONTEXT is important, and it is that quotations and poetry often use this markup without being marked up otherwise e.g. with the <poem> or <blockquote> tags, often for multiple paragraphs. So the OP's algorithm is missing at least one case.
A third case would be using multiple indents of this sort for very big indentation. Izno (talk) 15:21, 24 August 2025 (UTC)Reply
The usual workaround of using [^ -􏿽] to match newline works. ^ and $, while they work for intitle://, don't for insource:// (yet?) and are still matching literal ^ and $ - insource:/^mb/, insource:/gry$/. Looking at the commits, I'm reasonably certain they'd only match at beginning- and end-of-document, not -of-line, anyway. —Cryptic 16:23, 24 August 2025 (UTC)Reply
20k articles of this sort is probably a better start for clearing this kind of issue up and is a trivial improvement. There's definitely scope for a bot to do that. IznoPublic (talk) 23:51, 25 August 2025 (UTC)Reply
It would be quite trivial to replace this markup for poetry though, as it's almost always preceded by a section named "Poem". Albeit it should use <blockquote>, not {{block indent}}.
Quotations are tough, I agree.
A third case would be using multiple indents of this sort for very big indentation - well how big is very big? I can't imagine any case where more than 10 nested "organic" lists (i.e. not generated with a template like template:tree list) would be appropriate for an article. Sapphaline (talk) 11:32, 26 August 2025 (UTC)Reply
As Izno noted, poems (and lyrics) should use <poem>...</poem>. isaacl (talk) 16:39, 26 August 2025 (UTC)Reply
A <poem> inside a <blockquote>, yes. Sapphaline (talk) 17:48, 26 August 2025 (UTC)Reply

Text to Speech for Wikipedia Articles

edit
Latest comment: 8 days ago46 comments20 people in discussion

Dear Community, My name is Amiel.

At TTSREADER we have undertaken to convert a large amount of Wikipedia articles to synthesized speech with the latest and most advanced AI voices available. We currently have some 50,000 articles synthesized both in Male and Female voices and have created an environment that allows one to navigate through different articles, listen and follow the article content. https://ttsreader.com/wiki/

Here is an example article: https://ttsreader.com/wiki/?article=Albert_Einstein

We currently hold also some 50,000 articles in Spanish. We are looking to expand this resource all the time.

I want to bring this project of ours to the attention of the community with the hopes of turning it into an inherent part of article's structure. We are looking to share/give the content that we have, both from our site as well as integrate the audio files in existing Wikipedia articles.

I have been in touch with a number of Authors and Editors as well as reviewed some past discussions on this matter and have received the impression that there is no desire to integrate such audio files in articles because of lack of human authenticity. I disagree with this stance, and would like this to be discussed once again.

Important to point out, the voices we employ have very realistic humanlike characteristics. They incorporate, emphasis, intonation, pauses and tone that are very engaging. All this leads to improved delivery and comprehension. The articles themselves are word for word the content of the original articles derived from the date of capture. The articles have been sanitized to ensure only free-flowing comprehensible content is conveyed. Thus, content of this nature goes a long way to make Wikipedia articles more accessible to the general population and simply accessible to those with disabilities such as the vision impaired or those with language and reading impairment such as Dyslexia and ADHD.

For those that I have had interactions with, I would like to hear your opinions. @ChildrenWillListen, @Tbhotch, @HiLo48, @LindsayH, @OpenCooper, @Cortador, @TheAmazingRaspberry, @Another Believer AmielRieger (talk) 14:37, 17 August 2025 (UTC)Reply

Has any of the audio material the AI voice model has been trained with been used without the permission of their copyright holders? Cortador (talk) 14:41, 17 August 2025 (UTC)Reply
The AI voice models we work with, are commercial models provided by leading vendors such as Azure, Google and OpenAI. There privacy policies are very stringent and from the research that we have done their model development is without copyright infringements.
The content of the output voice is purely controlled by us and how we apply these models, and the rights to the content produced by the models are of those who synthesize the voice.
I dont see, or at least not aware of any copyrights problems. @Cortador Do you suspect a problem?
Have you managed to see the example I linked above? What are your thoughts, would be very happy to hear. AmielRieger (talk) 14:51, 17 August 2025 (UTC)Reply
OpenAI alone is currently involved in at least a dozen lawsuits (see also here). I don't know whatever research you have done, but there's clearly some disagreement on whether or not these models have been built "without copyright infringements". Cortador (talk) 14:58, 17 August 2025 (UTC)Reply
While this looks very helpful as a separate service, I do not think an external tool such as this one should be integrated as an inherent part of article's structure, as it would make Wikipedia reliant on this external provider. If the tool was entirely free and open-source, integrating it to MediaWiki could be a possibility, but it isn't clear to what extent this is the case, and whether these latest and most advanced AI voices available are under a compatible license (or, like Cortador points out, were even trained with permission).
The promotional language in the proposal also bugs me a bit, but I believe that this tool should be analyzed on its merits. Sadly, there is little that I can see beyond a user interface, so it is hard to find more about the tool's capabilities or its technical details. Chaotic Enby (talk · contribs) 15:05, 17 August 2025 (UTC)Reply
Edit: seeing the replies above, I am sad to say that this simply cannot be possible. Wikipedia will not integrate inside our articles a tool that relies on commercial models, especially to that extent. Chaotic Enby (talk · contribs) 15:08, 17 August 2025 (UTC)Reply
Let me clarify what I meant by "inherent part of article's structure". I mean to say that the audio outputs/audio readings that we have generated I would be happy to give them/ provide them for use as part of Wikipedia articles. In this way, they can provide an added media that contributes to the content's accessibility. I dont want to turn Wikipedia to become reliant on us, that defeats my intention completely. What I have I want to share.
@Chaotic Enby Excuse my promotional language, im not yet attuned to the community's sensitivities. I believe I understand your concerns. I am trying my best to share resources that we have that I believe can contribute to Wikipedia. I ask that you judge what I share and the content based on merits. Ill go even further, if you believe there is a better way/fashion to improve the merits of what I have shared I would be the happiest to hear.
@Cortador thanks for sharing this. Could you please elaborate where there could be a problem with this matter? The Engines I mentioned above are used across the world across different platforms and fields of application all the time and are ever expanding their use and applicability. (Lawsuits take place all the time, does that stop the activity?, most often not.)
Why is this of concern to you? If the materials are developed lawfully and shared legitimately why should this limit the possibility of using these materials? I may be naive but if the outcome is of benefit then surely that should be the metric? Would love to hear. AmielRieger (talk) 15:55, 17 August 2025 (UTC)Reply
Wikipedia is distributed under a free license, and avoids using third-party services that do not have a compatible license. Even if you decide to provide these recordings for Wikipedia, it needs to be under a similar license (which allows for commercial re-use), which I am not sure is compatible with the terms of the commercial models you are using. Chaotic Enby (talk · contribs) 16:03, 17 August 2025 (UTC)Reply
Thank you for the feedback so far. To clarify:
  • No reliance on external services – I am not proposing embedding Azure/Google services into Wikipedia. Instead, I propose to provide the finished audio files, which can be uploaded to Wikimedia Commons and hosted like any other media file. Once uploaded, Wikipedia would not depend on us or any commercial provider.
  • License compatibility – We already do and will release the audio under CC BY-SA 4.0, the same license as the article text. The models we use (Azure, Google) explicitly grant users rights over outputs, and we have full rights to release them under a free license.
  • No training data risk – We do not train AI models ourselves. We only apply existing licensed tools to freely licensed Wikipedia text. The audio is a direct transformation of CC-BY-SA content, not a reuse of copyrighted material.
  • Accessibility benefit – The purpose is to make Wikipedia more accessible: helping vision-impaired users, language learners, and readers with dyslexia or ADHD engage with articles more easily
I fully understand the importance of licensing clarity, and I am happy to provide concrete proof of licensing rights if needed. My goal is to share this work in a way that strengthens Wikipedia’s mission of free, accessible knowledge for all.
Who would be an authority in this matter that will assist me in clarifying any issues? Is there someone I could turn to? Im convinced that the issue of licensing is not a problem. AmielRieger (talk) 17:58, 17 August 2025 (UTC)Reply
Was this comment composed by a large language model? It doesn't match the grammatical, spelling, or formatting patterns of the rest of your comments. Dan Leonard (talk • contribs) 22:20, 17 August 2025 (UTC)Reply
That's also the first thing thart came to mind. Only the last sentence looks human. FaviFake (talk) 14:14, 21 August 2025 (UTC)Reply
Do you agree to release all of these recordings under the CC BY-SA 4.0 license so people at Wikipedia:WikiProject Spoken Wikipedia could upload them to Wikimedia Commons and put them into corresponding articles using the Spoken Wikipedia template? Sapphaline (talk) 18:10, 17 August 2025 (UTC)Reply
Yes. I believe we have effectively already "released" these recordings under license. You can review them on our site https://ttsreader.com/wiki/.
On our site that we setup we already make these licensing declarations in accordance with the licensing required (as mentioned above). Please see a template for example: https://ttsreader.com/wiki/?article=Albert_Einstein (If you are already gonna visit the site then I would be very happy to hear your feedback)
Furthermore, as a test a couple of months back I uploaded an ogg file of the United States article. @Tbhotch at the time temporarily uploaded it after reviewing the recording in its entirety. It was also taken down by him a few minutes later.
https://commons.wikimedia.org/wiki/File:United_States.ogg but It was nominated for deletion, its still available you are welcome to review this.
We have many articles, both in English and in Spanish rendered both in Male and Female voices. AmielRieger (talk) 18:54, 17 August 2025 (UTC)Reply
  • Oppose Their answer about the source of their model's data is unsatisfactory. In the absence of an explicit statement that they personally sourced all of the inputs from freely licensed sources (i.e. they did not outsource the collection and vetting of inputs to another organization), and that they have and always will follow all of the requirements of those licenses, it is safe to assume that they, like every other AI model, are engaged in wholesale theft. Putting aside any legal arguments, as those are still working their way through the courts, it is unethical for a project built on and around a free license, and which has extensive policies about respecting copyright, to turn a blind eye to how the inputs of AI engines are collected and pretend that it's not a violation of our own community pillars to accept the outputs. The Squirrel Conspiracy (talk) 21:07, 17 August 2025 (UTC)Reply
    I also want to add that the accessibility angle rings hollow to me. People that need text to speech already have tools that are purpose-built for that function, and will do a better job of it then an AI transcript, with the added benefit that what they hear will always reflect the current version of the article. The Squirrel Conspiracy (talk) 21:14, 17 August 2025 (UTC)Reply
    Dear @The Squirrel Conspiracy. I have high regard for your concern for ethics, but I respecfully disagree with you. Furthermore to falsely accuse me and my organization of "wholesale theft" before honestly assessing, discussing and researching us and our content is unethical in its own right. ( I am somewhat taken aback by your smearing) So please deal with content of the discussion and refrain from judging or smearing us publicly. and now to respond to the points you are making:
    I recognize concerns about how commercial AI models are trained, but this is not relevant to the licensing of the outputs. The recordings we provide are derived solely from Wikipedia content (freely licensed text) and are released with the same free license. By ensuring outputs are CC BY-SA 4.0, we comply fully with Wikimedia’s requirements and contribute material that enhances accessibility without introducing copyright conflicts. As simple as that.
    Any further sophistry is not relevant.
    Im surprised that the argument to make Wikipedia even more accessible is a red blanket to you, and the solution to that is not within the realms of Wikipedia. That seems not in line with Wikipedia's ethics. And if we are speaking about ethics, then the ethics of providing such a service (sooner rather than later) and accessibility to those with real limitations far outweigh the counter ethics of legally developed and licensed content based on AI engines. Important to emphasize, the textual content and thus the vocal output is pure Wikipedia text and as mentioned in my previous response all of our WIKI media is available to be used free, in line with Wikipedia licensing requirements.
    I invite you to explore our available resources at: https://ttsreader.com/wiki/, As a sample: https://ttsreader.com/wiki/?article=United_States and its ogg is at: https://commons.wikimedia.org/wiki/File:United_States.ogg
    @Sdkb The intent is good the implementation is not as I would have imagined the standard to be. We already hold some 50k articles in English and some 50k articles in Spanish. Each of these articles has both Male and Female voices. These voices are the leading voices available in terms of their humanlike nature, including intonation, emphasis, pauses and tones. All Im offering is to provide our existing content to Wikipedia.
    @Sdkb and @The Squirrel Conspiracy I am open and interested to hear your continued thoughts on this matter. AmielRieger (talk) 21:54, 17 August 2025 (UTC)Reply
    this is not relevant to the licensing of the outputs This is where we fundamentally disagree. If your approach to concerns about the inputs is "it doesn't matter, just look at the outputs", our understanding of Wikipedia's goals and underpinning philosophy are wholly incompatible. The Squirrel Conspiracy (talk) 22:27, 17 August 2025 (UTC)Reply
  • I know that meta:Wikispeech seems to be doing something similar, only under a fully open license. Sdkb talk 21:27, 17 August 2025 (UTC)Reply
  • People can run text-to-speech software on articles at any time, locally and with flexibility. What's the point of taking specific versions of articles and making them into inflexible audio files that go out of date almost instantly? Dan Leonard (talk • contribs) 22:22, 17 August 2025 (UTC)Reply
    The point is that a for-profit company that no one's ever heard of gets to say that they have a partnership with Wikipedia - one of the most prominent brands on the internet - when they go to investors for their next round of funding. Let's not pretend for a moment that this effort is anything but self-serving. The Squirrel Conspiracy (talk) 22:29, 17 August 2025 (UTC)Reply
    Ah, good analysis there. I didn't dig in and just assumed this was a hobbyist software project. Dan Leonard (talk • contribs) 22:42, 17 August 2025 (UTC)Reply
    I appreciate the thoughtful concerns raised here and want to address them directly.
    First, regarding our company:
    I am proud to say that TTSReader and the overriding company Well Source Ltd, is a completely self-funded company. We have never undergone a round of funding, we have no investors, and we are entirely bootstrapped and self-sustaining. We have been in the market for over 10 years, and today we serve more than two million people around the world, many of whom rely on our completely free services. So, while we may not be a household name, it would not be accurate to say that “no one has ever heard of us.”
    Second, on the question of being a for-profit company:
    Yes, we are a for-profit company. We are not ashamed of that, and we have no intention of hiding it. That said, our interest in contributing to Wikipedia is not at odds with that reality. We believe we have built one of the best TTS products and we have developed relevant content, and so we see alignment between what we’ve achieved and Wikipedia’s broader goals of accessibility and knowledge sharing. We have invested real money to create this content, and want to offer it for free to the Wikipedia community as it is freely available now on our website.
    To be clear:
    • The content itself remains pure Wikipedia text.
    • The outputs (our audio files) are released under the appropriate free license and fully reusable under Wikipedia’s requirements.
    • Our intent is not to extract value from Wikipedia, but to add accessibility for audiences and yes to be proudly associated with contributing content to Wikipedia.
    I understand the skepticism, particularly around the role of commercial actors. But I would argue that being a for-profit does not automatically make our contributions misaligned with Wikipedia’s mission. If anything, our long-standing sustainability without outside investors demonstrates independence, stability, and seriousness of purpose.
    look forward to continued discussion. AmielRieger (talk) 23:09, 17 August 2025 (UTC)Reply
  • The audio file for an article becomes outdated as soon as the article is edited, which is one of the reasons why these text-to-speech projects aren't really popular on this site. Some1 (talk) 23:19, 17 August 2025 (UTC)Reply
    Thats a valid point. There are many points to ponder regarding this vision.
    Our considerations are that, many many articles are not that dynamic in nature and thus the audio files remain relevant over a significant period of time. Furthermore, in most cases the vast majority of content remains the same and so the overall value of the audio file remains high. On our website we "freeze" the articles in time.
    We are thinking of a mechanism where the audio files get updated (rerendered) when a certain threshold of change occurs. But this would require development and operating costs that at least for now we don't have those resources.
    An alternative would be to integrate a player of sufficient quality into all articles and render them dynamically. This has its own complications both technological and potential overheads. Both I believe beyond the scope of Wikipedia. We for example can provide such integrations, and even provide it for free, but in light of the earlier discussions and perhaps because of association concerns this may not be viable. If anyone in Wikipedia is open to consider this avenue, I would be happy to discuss it.
    At this time, we took a decision to create the content we have and "freeze" it so that at least it is available and accessible on our site. https://ttsreader.com/wiki/ AmielRieger (talk) 23:38, 17 August 2025 (UTC)Reply
    Why are we even having this discussion? If you want to "provide the finished audio files, which can be uploaded to Wikimedia Commons and hosted like any other media file", then nobody here can stop you from doing that. WhatamIdoing (talk) 01:48, 18 August 2025 (UTC)Reply
    Thank you @WhatamIdoing, I am new to this world of content contribution and I made an initial test with the United States article. I linked it earlier: https://commons.wikimedia.org/wiki/File:United_States.ogg but a couple of days after I posted It was put forward for deletion by @The Squirrel Conspiracy and I see now that @Krd has removed it as of a couple of hours ago. Could you please guide me how to upload content while making sure that it wont be deleted? What should I do different in order to avoid this the next time?
    Why we are having this discussion? Well, cause there is content available that I believe adds value to Wikipedia but I sense otherwise from certain players in the community. I have not been convinced. The content remains true to the original text and does not infringe on licensing guidelines etc. What if I load all 50k articles in Male and Female voice ie 100k files and because it bothers some they all get deleted, this is not clever on my part. Lets not forget the 50k Spanish articles we have too. Thus I preferred to raise this issue in this forum as I was recommended by @ChildrenWillListen and hopefully through open and honest dialogue I would be able to progress this topic. I was very encouraged initially when @Tbhotch had listened through the entire content and saw no flaw with the actual content. AmielRieger (talk) 08:02, 18 August 2025 (UTC)Reply
    As was mentioned above, you are free to upload your properly licensed audio files to Commons. Any uninvolved editor can link content from Commons in a Wikipedia article, but whether that link will be left in the article is subject to community consensus. I think it is clear that there is no appetite here for any formal connection with or endorsement from Wikipedia of your project. I suggest reading the essay at Wikipedia:Don't bludgeon the process before posting here again. Donald Albury 13:36, 18 August 2025 (UTC)Reply
    c:Commons:Deletion requests/File:United States.ogg doesn't seem to have been the cause of the deletion. Things that won't be used at the English Wikipedia are not automatically outside c:COM:SCOPE.
    The deletion note says something about a ticket, which means you were meant to send an e-mail message to them. WhatamIdoing (talk) 20:45, 19 August 2025 (UTC)Reply
    @AmielRieger Probably best to upload that stuff to your own website. Polygnotus (talk) 21:02, 19 August 2025 (UTC)Reply
A terrible American accent. Then it read "14 March" as "March fourteenth"! Sorry, but that's just wrong. You've lost me! HiLo48 (talk) 00:26, 18 August 2025 (UTC)Reply
If you prefer a British accent that can also be synthesized ;-). Either way Im glad you listened to the content. Much more than many others. AmielRieger (talk) 07:29, 18 August 2025 (UTC)Reply
  • You lost me at “recording”. Our articles change frequently (as editors add, subtract and reword information). So any recording would quickly become out of date. Non-starter right there. Blueboar (talk) 14:07, 18 August 2025 (UTC)Reply
  • Oppose any commercial integration with or commercial endorsement by Wikipedia. Wikipedia is not a place to show off your new product nor a place to experiment with novel technologies. Our license permits the company to host a spoken Wikipedia mirror if they so choose, but there are serious unresolved moral and ethical problems with the technology itself, as well as inherent conflicts of interest with commercial entities. AmielRieger's dismissive rebuttal to The Squirrel Conspiracy above suggests that they already lean into the "ends justifies the means" ethical fallacy so common with large language model techbros that Wikipedia has always rebuked, and should continue to rebuke. We should not do this unless it's developed in-house, despite the difficulties that the m:Wikispeech project seems to be highlighting. Ivanvector (Talk/Edits) 14:18, 18 August 2025 (UTC)Reply
  • Oppose for three reasons: the audio files would be outtdated the moment someone makes an edit, on-the-fly text-to-speech software is likely more useful for people with accessibility issues, and Wikipedia is not a platform to showcase technology based on large-scale theft. Cortador (talk) 15:23, 18 August 2025 (UTC)Reply
I have ... received the impression that there is no desire to integrate such audio files in articles because of lack of human authenticity. I disagree with this stance, and would like this to be discussed once again.
So despite the fact that people already explained to you that we don't want it, you are asking the same question again? We still don't want it. And the next time you ask the same question we still don't want it. And if you keep asking the answer will still be 'no'. Hope that helps. Polygnotus (talk) 09:59, 19 August 2025 (UTC)Reply
Looking at OpenAI's ToS: ChatGPT Voice Output is for non-commercial use only and may not be distributed or repackaged as a standalone audio recording Polygnotus (talk) 01:55, 20 August 2025 (UTC)Reply
If Commons considers AI audio uncopyrightable, OAI’s TOS are irrelevant. ꧁Zanahary꧂ 02:36, 20 August 2025 (UTC)Reply
Perhaps irrelevant to you, but not to OPs company. Polygnotus (talk) 02:41, 20 August 2025 (UTC)Reply
Well, irrelevant to Commons and Wikipedia, which are invested in copyright and not in the contractual agreements between two third parties. ꧁Zanahary꧂ 14:16, 21 August 2025 (UTC)Reply
  • Oppose for the reasons explained by Cortador, Polygnotus, and others above, but also and at least as importantly at the moment, i do not believe that any AI production currently sounds even close to natural and will therefore, at least misrepresent our content and, possibly be inaccurate in its mispronunciations and mis-emphases. While this last reason may, just possibly, one day be eradicated, there isn't any chance that currently such "recordings" would be worth integrating into the encyclopaedia ~ or even linking to ~ LindsayHello 16:15, 19 August 2025 (UTC)Reply
  • Hi Amiel. I'm sorry that people are being hostile towards you. If your audio is already freely licensed, and Wikimedia Commons allows AI-generated material (it does, last I checked), then you should feel free to upload it to Commons. But you should probably check in at the Commons village pump first. Off the top of my head, it may be Commons's position that AI output may not be under a CC license, and is instead presumed to be ineligible for copyright protection and thus necessarily in the public ___domain. There is a template on English Wikipedia that embeds audio recordings at the top of an article. People could use that template to embed your company's outputs. ꧁Zanahary꧂ 20:52, 19 August 2025 (UTC)Reply
We already have WikiProject Spoken Wikipedia for providing audible versions of articles, and I think that project needs more support before we even think of an automated solution. Issues with an automated TTS, like pronunciation problems and an audible version becoming outdated, are directly addressed by the project, which encourages its readers to look up pronunciation guides and focus on featured articles (which are not liable to greatly change over time). --Grnrchst (talk) 13:12, 20 August 2025 (UTC)Reply
  • No thanks. Even if only freely licensed models were used, it would still be necessary for every output to be manually reviewed for mistakes and then rectified as needed. And as can be easily gauged from the sentiment expressed at WP:VPW recently about the WMF's AI summaries project, the community isn't interested in undertaking such a large task. Not worth the effort and time spent. JavaHurricane 17:17, 21 August 2025 (UTC)Reply
    While I agree with the other concerns, I don't get this. TTS is not generative and does not hallucinate factual errors. Any minor audio glitches should be fixed with eyes wiki-style. Aaron Liu (talk) 17:36, 21 August 2025 (UTC)Reply
    This doesn't make sense. There is no reason to believe that TTS is more error-prone than humans at reading text aloud. ꧁Zanahary꧂ 17:59, 21 August 2025 (UTC)Reply
    does not hallucinate factual errors is untrue, at least in my experience with AI TTS tools. And this doesn't account for issues such as mispronounciations (especially with technical terms, for instance) which would still need correcting.
    Any minor audio glitches should be fixed with eyes wiki-style: wouldn't be an issue if the load of articles for which audio files are being generated was not too large (as would be the case with audio files generated by humans under, say, WP:SPOKEN). Maybe I'm a cynic, but I don't see the load not being large with an AI TTS service being used. JavaHurricane 12:36, 22 August 2025 (UTC)Reply

Automatically list closed AfDs on the article's Talk page.

edit
Latest comment: 11 days ago8 comments5 people in discussion

It would be useful to have previous AfDs for an article easily accessible on the Talk page. I think it would be good to have a bot automatically link closed AfD discussions to a Talk page, for future reference. ꧁Zanahary꧂ 18:35, 19 August 2025 (UTC)Reply

I thought that the most popular AFD-closing script automatically did this. WhatamIdoing (talk) 20:41, 19 August 2025 (UTC)Reply
Which is that? All I know is that most article Talks do not link to previous AfDs. And if there's consensus that this is a good feature, we should automate it for all AfDs. ꧁Zanahary꧂ 20:43, 19 August 2025 (UTC)Reply
@Zanahary WAID appears to be referring to Xfdcloser. Polygnotus (talk) 20:57, 19 August 2025 (UTC)Reply
Wikipedia:XFDcloser (which I've never used myself, and perhaps it doesn't have the feature I've assumed).
I'm not sure that we we want to fully automate this. Talk:Earth doesn't really need links to Wikipedia:Articles for deletion/Earth, Wikipedia:Articles for deletion/Earth (2nd nomination), Wikipedia:Articles for deletion/Earth (3rd nomination), Wikipedia:Articles for deletion/Earth (4th nomination), and so forth, through Wikipedia:Articles for deletion/Earth (21st nomination). (I actually like this particular Wikipedia:April Fools tradition. I just don't think it needs to be made more visible to casual users.)
Given a choice between tagging for AFDs vs other things, I'd much rather that declined/removed CSDs, PRODs, and unilaterial draftifications were tagged. Those are one-time events that cannot validly be repeated, so having something that Twinkle can recognize as evidence that a new PROD tagging would be inappropriate could be more practical. WhatamIdoing (talk) 20:58, 19 August 2025 (UTC)Reply
I feel like cases such as the Earth AfDs are very obvious and can be blacklisted easily. ꧁Zanahary꧂ 21:03, 19 August 2025 (UTC)Reply
+1 to the CSD/PROD/draftication part of @WhatamIdoing's comment. On April Fools, this is one reason to avoid joke deletion nominations, but more importantly, we shouldn't let edge cases define our overall approach. Sdkb talk 22:33, 19 August 2025 (UTC)Reply
+1 to CSD/PROD/draft also. But I agree with the Zanahary that this is a good idea. Cases such as "earth" should either be blacklisted or not continued in the AFD log (as is, have the joke nominations elsewhere) 📎 JackFromWisconsin (talk | contribs) 01:36, 20 August 2025 (UTC)Reply

Change the Village Pump's colour.

edit
Latest comment: 21 hours ago48 comments28 people in discussion
This colour is ugly :(
Do you think we should change the village pump's header color? Personally, I dislike this yellow-brownish color; it feels outdated and isn't in the usual Wikipedia style. We have so many better colour options over at pages like:

and many others. I suggest we pick a replacement for the current color. The colors below are just some examples; the first three are used on the Main Page.

Update 16:08, 21 August 2025 (UTC): Zanahary has created actual mockups; you can see them in the § Mockups section. (I also collapsed the other color choices below, which weren't being voted on.)

Option A
this is an example of black text with color applied to its background and border
Option B
this is an example of black text with color applied to its background and border


Option C
this is an example of black text with color applied to its background and border
Option D
this is an example of black text with color applied to its background and border


Option F
this is an example of black text with color applied to its background and border
(More color choices)
FEF FFE EFD EFE DFE EFF
FFD CFE DFF
FFC EFC DFC DFD BFE CFF
FFB EFB DFB CFB CFC CFD BFF
FFA EFA DFA CFA BFD AFF
FEE FF9 EF9 DF9 CF9 BFB BFC 9FF
FED FF8 EF8 DF8 CF8 AFC
FEC FF7 EF7 DF7 CF7
FEB FF6 EF6 DF6 CF6
FEA FF5 EF5 DF5 CF5
FE9 FF4 EF4 DF4 CF4
FE8 FF3 EF3 DF3 CF3 BFA AFD
FE7 FF2 EF2 DF2 CF2 BF9 AFE
FE6 FF1 EF1 DF1 CF1 BF8 9FE
FE5 FF0 EF0 DF0 CF0 BF7 9FD 8FF
EEC EED EEE EEF DEF






  • Ivory
  • MintCream
  • Azure
  • Snow
  • Honeydew
  • FloralWhite
  • GhostWhite
  • AliceBlue
  • Seashell
  • OldLace
  • WhiteSmoke
  • LavenderBlush
  • Beige
  • Linen
  • AntiqueWhite
  • LightYellow
  • LemonChiffon
  • LightGoldenrodYellow
  • PapayaWhip
  • Cornsilk
  • BlanchedAlmond
  • LightCyan
  • D9F1E6
  • FEE7D6
  • E7ECF4
  • FAE6F2
  • E6F5C9
  • FFF2AE
  • F5EAD9

FaviFake (talk) 21:26, 20 August 2025 (UTC)Reply

Survey (colours)

edit
support, the current color kinda looks like teeth. drinks or coffee or prime *GET OUT* 04:48, 30 August 2025 (UTC)Reply
We get it, you love coffee! ꧁Zanahary꧂ 05:17, 30 August 2025 (UTC)Reply

Discussion (colours)

edit

I note none of the examples given here actually show what the header would look like. Even the one that claims to be the current color isn't, nothing in the current header uses this color. If we want to make a choice, we should probably have accurate mockups to choose from. Here's some wikitext to mockup the current coloring:

 Selected tab Other tab Other tab Other tab Other tab Other tab 
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.)
If anyone wants to develop actual mockups, please do! FaviFake (talk) 12:30, 21 August 2025 (UTC)Reply
Collapsing nonconstructive discussion. Mz7 (talk) 22:44, 21 August 2025 (UTC)Reply
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
There's nothing half-baked about the proposal. ꧁Zanahary꧂ 14:18, 21 August 2025 (UTC)Reply
Yup, the proposal is perfectly fine. Seems like WP:BITING, imo. — EF5 14:21, 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
Are we supposed to stop talking about colors and start talking about how you've found FaviFake annoying lately? ꧁Zanahary꧂ 14:35, 21 August 2025 (UTC)Reply
No. You're the one harping on it. Anomie⚔ 14:37, 21 August 2025 (UTC)Reply
Oooooookay. Colors below, everybody! ꧁Zanahary꧂ 14:40, 21 August 2025 (UTC)Reply

Mockups

edit

Copy-pasted from § Discussion (colours) for comparison:

 Current color Other tab Other tab Other tab Other tab Other tab 
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.

--FaviFake (talk) 16:11, 21 August 2025 (UTC)Reply


Here are some mockups based on the standards at Help:Using colours#Colour generation guide:

 Option 1 Other tab Other tab Other tab Other tab Other tab 
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.

꧁Zanahary꧂ 14:31, 21 August 2025 (UTC)Reply

Thanks, these look great! I added the current color above you message to show the difference. FaviFake (talk) 16:11, 21 August 2025 (UTC)Reply

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.

Chaotic Enby (talk · contribs) 12:47, 22 August 2025 (UTC)Reply

RfC: Proposal to implement bureaucrat elections

edit
Latest comment: 5 days ago17 comments11 people in discussion
The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.
I am closing this discussion early per WP:SNOW. It has been nearly 3 days since the RfC started, and it seems like in the last 48 hours, no one has had much more to add. There is a near-unanimous agreement among participants that holding bureaucrat elections would not be worth the volunteer time that would be required to organize them. Mz7 (talk) 11:10, 25 August 2025 (UTC)Reply

Last year, we implemented a process of admin elections. However, there was little discussion on if we should include bureaucrat elections, which I personally think that we should. I am implementing this RfC to ask the community what they think of implementing these kinds of elections, maybe like every year or 2. Should we implement bureaucrat elections the same way we do with admin elections? Interstellarity (talk) 13:02, 22 August 2025 (UTC)Reply

Survey (bureaucrat elections)

edit
  1. Yes as proposer. Although we don't have many bureaucrats, it would be helpful for admins who want to become bureaucrats to have an easier process for doing do. Maybe we don't have them as frequently as admin elections, but it would be good to have them for an easier process of becoming a bureaucrat. Interstellarity (talk) 13:02, 22 August 2025 (UTC)Reply
  2. No. I think this is already a rare process and that building an election program for it is a waste of time. In the last 10 years there have been 7 successful and 4 unsuccessful RFB discussions, I'm not seeing a problem that needs solving here. — xaosflux Talk 13:44, 22 August 2025 (UTC)Reply
  3. No, mostly per Xaosflux and Thryduulf, although I will add another important point. A major perk of the admin elections are that they allow candidates to run alongside others, alleviating the pressure on individual candidates. There just aren't enough potential RfB candidates for that to be a meaningful point here, and we might end up either having crat elections with only one candidate, or spacing out elections to the point of being impractical (will candidates wait two years for an election when they could just run now?) Chaotic Enby (talk · contribs) 14:06, 22 August 2025 (UTC)Reply
  4. No. I think the community is not so eager to get more 'crats, so do not think this is helpful. Highly doubtful of the candidates that will run for this, if any at all in some elections. ~/Bunnypranav:<ping> 14:22, 22 August 2025 (UTC)Reply
  5. No. 'crat is a highly important role and its candidates must be scrutinized and well vetted. Anyone with access to appoint new admin accounts needs to be fully supported by the community. We also have no need for (many, many) more 'crats. I think its always good to see new candidates when people think they're ready, but an election would encourage people running just to run, and not because they want to do the (very limited) 'crat stuff. --📎 JackFromWisconsin (talk | contribs) 16:05, 22 August 2025 (UTC)Reply
  6. No. Every election cycle, for any position, consumes a large amount of our project's most precious resource, which is our volunteer editors' time. In the case of the administrator elections, there was a consensus that this investment would be worth it, because issues with RfA were perceived as interfering with recruiting new administrators who were clearly needed. In the case of the 'crats, this is not the case. I happen to believe that it is healthy to elect one or two new bureaucrats each year, even if they are not critically needed, but we should be able to do so through the traditional RfB process. Newyorkbrad (talk) 16:16, 22 August 2025 (UTC)Reply
  7. No I don't see much backlogs that crats have. Crats don't do much beyond the standard admin responsibilities. Second, if we want more crats, we need to have more admins first, or we are promoting admins/intadmin/bots at a more frequent cadence, like daily, or crats are have sole responsibility to more user rights promotion. I suspect that many admins, even those capable of being a crat, are okay or happy with the current arrangement. – robertsky (talk) 17:29, 22 August 2025 (UTC)Reply
  8. No, and this seems likely to be heading for a WP:SNOW close as such. Unlike admins, we don't have much need for more 'crats, and there's no widespread consensus that WP:RFB is "broken" like WP:RFA, and even the proposer here isn't claiming there is. I suspect if we do need more 'crats at some point, the better thing to do would be for existing 'crats to privately ask likely candidates if they'd stand for WP:RFB. Anomie⚔ 17:35, 22 August 2025 (UTC)Reply
  9. No We don't need more crats. We need new processes for finding crats even less. * Pppery * it has begun... 05:35, 23 August 2025 (UTC)Reply

Discussion (bureaucrat elections)

edit
  • (edit conflict) There is absolutely no question that RFA is not providing the number of admins we need, and that the problems with RFA are well-known (even if not everybody agrees on all the details). Admin elections are thus occupying an otherwise empty niche. I'm not certain that the same can be said in relation to 'crats and RFB: we don't have a chronic shortage of crats (unlike admin work which is functionally almost infinite, crat tasks are finite and so the role can be overfilled) and RFB hasn't shown itself incapable of promoting good candidates when required. So ultimately I'm not convinced that there is a need for the overheads in community time and energy involved with designing, running and administering a crat election. Thryduulf (talk) 13:21, 22 August 2025 (UTC)Reply
    Putting numbers out for perspectives, each election requires an election clerk, optionally a backup clerk, and 3 scrutineers. That's five persons working just to promote 1(?) crat over a month? A RfB requires just a crat to promote at the end of the discussion in 7 days. – robertsky (talk) 17:34, 22 August 2025 (UTC)Reply
  • Is there a need for more 'crats, @Interstellarity:? What backlogs are not getting done or tasks piling up? --📎 JackFromWisconsin (talk | contribs) 16:11, 22 August 2025 (UTC)Reply
    @JackFromWisconsin: I haven't thought about whether we need more crats or if the workload is piling up, but the reason why I am proposing this is because suppose an admin wants to become a crat, rather than go through the hassle of an RfB which requires a much higher community consensus than an RfA, it would be good to provide an alternate option for admins willing to take up the role since almost no non-admin runs for this position. Interstellarity (talk) 17:40, 22 August 2025 (UTC)Reply
    From what I understand, the bar for RfB being much higher than for RfA is by design, and I don't see why crat elections would change this. Chaotic Enby (talk · contribs) 17:46, 22 August 2025 (UTC)Reply
    (edit conflict) The reason why I asked is that (at least one) rationale for admin elections were due to a lack of admins. There was more work than there were admins. I don't think many people will be convinced to start a laborious process to allow for someone to get a hat easier (to them). If there is a need for 'crats, or some other good reason, I think more people would be convinced. 📎 JackFromWisconsin (talk | contribs) 17:49, 22 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.
edit
Latest comment: 3 days ago34 comments19 people in discussion

Should the Contents link be removed from the sidebar? Interstellarity (talk) 13:20, 22 August 2025 (UTC)Reply

edit
  1. Yes as proposer. I'm not convinced that this page is really helpful for browsing Wikipedia, so I think would be helpful to have a discussion on removing the link. I initiated a discussion regarding whether to remove the link, but the discussion got stale, and it was eventually archived. I hope to achieve this by doing an RfC regarding this. Interstellarity (talk) 13:20, 22 August 2025 (UTC)Reply
  2. No. WP:Contents is necessary until there's an option to exclude disambiguations and redirects from Special:AllPages. Sapphaline (talk) 13:32, 22 August 2025 (UTC)Reply
  3. Yes I'm always disappointed when I click it. Least valuable link.--Rolluik (talk) 14:08, 22 August 2025 (UTC)Reply
  4. I do not support the proposal. I think it is reasonable to have a starting framework for browsing an encyclopedia, and that a contents link in the side bar fits this purpose. The rationale expressed in the previous proposal was more suitable as motivation to improve the lists of content and their presentation. isaacl (talk) 15:34, 22 August 2025 (UTC)Reply
  5. Oppose per Isaacl. It's worth noting that the way most readers see Wikipedia (open an article in a logged out private browsing window if you haven't in a while), the main menu is hidden behind a hamburger (three dashes stacked on top of each other) dropdown option in the upper left. So it's not as if it's a terribly prominent link that needs to justify being shown to everyone all the time. Sdkb talk 15:42, 22 August 2025 (UTC)Reply
  6. Oppose per Sdkb and isaacl. "Contents" is a useful link and shouldn't just be removed. If you don't like clicking on the link, either don't, or suggest improvements to the article itself. I'm sure there is a better contents page design out there if we're motivated enough to find one. --📎 JackFromWisconsin (talk | contribs) 15:50, 22 August 2025 (UTC)Reply
  7. Support – This is not how most users browse Wikipedia, and it only clutters the sidebar. I wished they'd remove it with Vector 2022, but alas it's still here. --FaviFake (talk) 16:12, 22 August 2025 (UTC)Reply
    As I alluded to in my !vote, what Vector 2022 did was essentially remove all the sidebar links by placing them under a hamburger menu (rather than directly visible on the page) for most users. I think that was the right call. Since while the Contents link isn't particularly useful, nor are the others. The actual links in the sidebar are under community control. Sdkb talk 16:25, 22 August 2025 (UTC)Reply
    Well, while I agree they aren't really useful, contents in particular is more useless than the others imho. FaviFake (talk) 09:12, 23 August 2025 (UTC)Reply
  8. Yes * Pppery * it has begun... 16:50, 22 August 2025 (UTC)Reply
    Why? Thryduulf (talk) 16:58, 22 August 2025 (UTC)Reply
    My thinking was (which I agree that I should have explained), that people these days are far more likely to use search to find the content they are looking for rather than trying to navigate through a top-down list, and hence the link isn't useful. * Pppery * it has begun... 18:15, 22 August 2025 (UTC)Reply
  9. Oppose. If you just cut off the (subjectively) least-useful link you gain nothing but a different (subjectively) least-useful link until you have no links at all. We have nothing to suggest that those who use it don't find it useful, and we have no suggestions for something more useful to take its place. It's not causing any harm, and nobody is forcing you to click the link - heck someone with more technical know-how than me could probably give you some fancy custom CSS or js to hide the link if it bothers you. Thryduulf (talk) 16:56, 22 August 2025 (UTC)Reply
  10. Oppose If Wikipedia:Contents is considered poor, it seems like something that would better be improved than removed. No rationale is given for why improvement isn't the better option. Anomie⚔ 17:38, 22 August 2025 (UTC)Reply
  11. Comment Is there something better that could go there? qcne (talk) 17:43, 22 August 2025 (UTC)Reply
    I'm looking for something that is basically a list of articles rather than a list of lists. Something like an A-Z list, but Wikipedia has too many articles to list alphabetically. If we can find a page where similar articles are grouped together similar to an outline. Example: History of the United States goes under United States, similar to Outline of the United States, but for all Wikipedia articles. Not sure if we have a page for that, but I'd be willing to create one if there's a need for it. Interstellarity (talk) 17:49, 22 August 2025 (UTC)Reply
    Wikipedia:Contents/Overviews sounds similar to what you're describing. Sdkb talk 18:39, 22 August 2025 (UTC)Reply
    List of lists of lists :p.  novov talk edits 07:47, 23 August 2025 (UTC)Reply
    That looks much more useful! FaviFake (talk) 09:13, 23 August 2025 (UTC)Reply
    I was being tongue in cheek, but actually using this is probably a bad idea as not every article has a corresponding list (cf. WP:NLIST). Though I wouldn't be surprised if nevertheless it's still more useful for your average Wikipedia reader.  novov talk edits 09:43, 24 August 2025 (UTC)Reply
    I think I meant to reply to @Sdkb, but yeah anything is better than the current one. FaviFake (talk) 10:10, 25 August 2025 (UTC)Reply
  12. Oppose per the arguments above. If you think it's subpar, you are welcome to improve it. In my opinion, it makes sense for an encyclopedia to have a contents listing like Wikipedia:Contents. Consider also that, as mentioned above, Vector 2022 hides the entire sidebar in a dropdown by default, so it's not like the link clutters the page at all. (If you want to hide it, you can use this CSS: #n-contents {display: none;}) OutsideNormality (talk) 17:46, 23 August 2025 (UTC)Reply
  13. Yes – It's limited utility doesn't warrant that level of prominence. Graham11 (talk) 19:26, 24 August 2025 (UTC)Reply
  14. Yes It is. As with few other users. >^CreativeLibrary460 /access the library revision\ 07:56, 27 August 2025 (UTC)Reply
edit
  • @Interstellarity: could you link to that previous discussion please? Thryduulf (talk) 13:35, 22 August 2025 (UTC)Reply
    @Thryduulf: Sure, Wikipedia:Village_pump_(proposals)/Archive_220#Proposal:_Remove_the_Contents_link_from_the_sidebar. Interstellarity (talk) 14:46, 22 August 2025 (UTC)Reply
  • The page views for this page are kind of weird. ~450K per month until May 2020, when it halves. (What did we do that month, rearrange the Main Page?) Then it almost halves again, starting in late January 2023, when WP:Vector 2022 was deployed. The question that I'd like to be able to answer is: When readers get to that page, are they satisfied with it? What happens next, if an ordinary reader ends up on that page? WhatamIdoing (talk) 21:59, 23 August 2025 (UTC)Reply
    May 2020 is the month of WP:SIDEBAR20, although I don't think we did anything with the contents link then, so not sure what happened. Sdkb talk 22:04, 23 August 2025 (UTC)Reply
    This seems like a good thing for the WMF to do. They are good at making a/b tests and running experiments. Maybe a technical team get can involved a new approach could use categories and something a little more dynamic. Definitely dreaming big here. 📎 JackFromWisconsin (talk | contribs) 02:55, 24 August 2025 (UTC)Reply
  • Trying to formulate some sort of vote that runs along the lines of Keep but delete the most prominent part, which is the "Browse by subject area". Firstly, "Wikipedia's content is divided into broad subject areas" does not reflect how our content is divided, to the extent that it is this is through the category system which functions as a series of overlapping tags rather than discrete silos. Secondly, the specific subject pages like Wikipedia:Contents/Culture and the arts seem like weird duplications of outline articles such as Outline of culture. Thirdly, we already have a system that divides important content into subject, Wikipedia:Vital articles, which is included as part of Wikipedia:Contents so there's some weird nesting dolls of content division. And of course, the lists don't seem maintained (possibly because they duplicate the article space as well as Vital articles). Getting rid of these is a much better option than investing time into overhauls (of content that exists elsewhere!) as some have suggested above.
    However, while we don't divide out content into broad subject areas, it does seem useful to have a space that explains how we do divide our content. "Browse by format" seems useful to readers, give or take how much each format is used (hopefully it would be adjusted if those change). Introducing readers to the Featured and Good quality content systems would help them understand at least to some extent how content is developed. If readers do want subject lists, Vital articles provides an already curated list (although it should not be in the "Articles by quality" section). There are probably other tweaks that can be made, but repurposing the page to talk about Contents in the system sense rather than the Subject sense seems like it would be more helpful and duplicate the search bar less. CMD (talk) 04:14, 24 August 2025 (UTC)Reply
    I'm concerned that this is more of a pointy deletion....user for years has been unable to implement they preferred layout of vital articles being seen first. My concern is the vital article project is trying to take this over. I believe the vast majority of editors here see the vital article project as extremely unstable and not representative of our worldwide viewership. Moxy🍁 20:07, 24 August 2025 (UTC)Reply
    I am not familiar with past proposals, but I doubt Wikipedia:Contents is particularly more representative of a worldwide viewership. CMD (talk) 04:20, 25 August 2025 (UTC)Reply
    @Moxy: Only Level 5 is particularly unstable, and if you think it doesn't properly represent our worldwide viewership, the talk pages are open for you (or anyone) to propose improvements. QuicoleJR (talk) 12:40, 25 August 2025 (UTC)Reply

Unsalt of Gaza Holocaust

edit
Latest comment: 1 day ago58 comments27 people in discussion

I've noticed that an admin WP:SALTed the Gaza Holocaust page in 2021. I would argue that a lot has happened since then and people have started using that term to refer to the Gaza genocide. (e.g. this post by WikiLeaks that I stumbled upon yesterday).

I propose that an admin unsalts the title and to make it redirect to Gaza genocide (and maybe also the same for Gaza holocaust)

There is also precedent for a naming scheme like that with the Armenian genocide and the redirects Armenian Holocaust and Armenian holocaust.

I originally brought this up to the admin who did the salt and they stated that they "do not feel comfortable engaging with the protection status of that" but aren't fundamentally opposed to it. Laura240406 (talk) 14:12, 25 August 2025 (UTC)Reply

Oppose – the term Gaza Holocaust is not a likely search term for a redirect and is not a widespread term for the genocide (or alleged genocide). The Holocaust was an event, not a type of event, and therefore Gaza cannot 'have a Holocaust' even if its citizens are the victim of a genocide. The article Armenian genocide and the Holocaust explains the link between the two and the use of the term 'Holocaust' to describe the Armenian genocide. I would support if there was scholarly or widespread use of the time. Never mind UK Lawyers for Israel suing Wikipedia lol. JacobTheRox(talk | contributions) 20:56, 25 August 2025 (UTC)Reply
The term is definitely used (see the post I linked by WikiLeaks).
The name of The Holocaust was derived from the ancient Greek term for "a religious animal sacrifice that is completely consumed by fire" and has been used to describe other genocides other than the Holocaust.
Creating the redirect isn't about equation what is happening in Gaza with the Holocaust, it's about linking a (possibly non-neutral) term to the right article as people are using the term. (a quick google search also yielded this article by the Institute for National Security Studies (Israel)) Laura240406 (talk) 21:16, 25 August 2025 (UTC)Reply
As for the UKLIF legal threat: we can tag the redirect with Template:R from non-neutral name Laura240406 (talk) 21:18, 25 August 2025 (UTC)Reply
It's interesting that this redirect was around as early as 2010, it must have pointed to a different Gaza War at the time. Gråbergs Gråa Sång (talk) 09:39, 26 August 2025 (UTC)Reply
When it was created in 2009, it pointed to 2008–2009 Israel–Gaza conflict, which a few days later was renamed to Gaza War. Absent edit warring it seemed to stay at that topic until February 2016 when an IP changed it to Holocaust trivialization. Then Wikipedia:Redirects for discussion/Log/2016 August 10#Gaza Holocaust changed it back to Gaza War (which at the time had the content now at Gaza War (disambiguation)). The change of Gaza War to be about the current conflict (rather than a dab) wasn't until well after the deletion. Anomie⚔ 13:36, 26 August 2025 (UTC)Reply
Seems to be more of a name flexibly applied to whatever conflict's going on, I gather then. Without judging, there's something to be said for the IP's 2016 characterization. Wehwalt (talk) 14:22, 26 August 2025 (UTC)Reply
Actually holocaust is a type of event, just as crusade (in opposition to Crusade). Yacàwotçã (talk) 10:24, 26 August 2025 (UTC)Reply
Oppose IMO, Wikipedia:Redirects_for_discussion/Log/2021_June_20#Gaza_Holocaust got it right. The term exists, true, and it's on en-WP in mainspace a bit:[8]. Looking at that, I see someone has creatively made Gaza HOlocaust a redirect recently. Unless this ends with an unsalting, that should probably be deleted. Gråbergs Gråa Sång (talk) 07:25, 26 August 2025 (UTC)Reply
Striking my oppose, as has been pointed out, time has passed. Still not sure what to do with it, sources have applied the term to more than one thing. Perhaps a 2022 United Kingdom government crisis-style page (that one had some media-coverage:[9])?
This isn't really the place to discuss this but at the relevant wikiproject talk page. Logoshimpo (talk) 07:50, 26 August 2025 (UTC)Reply
I'd say this page works as well as a relevant Wikiproject, but feel free to WP:APPNOTE. A WP:DRV is another option. Gråbergs Gråa Sång (talk) 08:07, 26 August 2025 (UTC)Reply
Found the right venue for this discussion. Logoshimpo (talk) 10:36, 27 August 2025 (UTC)Reply
Strong support. Used in academic articles, for example, as a synonym of Gaza genocide: [10]. Perhaps was too inflammatory in the past, but today is as perfectly acceptable as "Gaza genocide" itself is. By the way, it's horrible to edit this page. Yacàwotçã (talk) 10:17, 26 August 2025 (UTC)Reply
Your argument might have more effect if you pick a couple of good examples instead of linking a search result, which is a bit of a mixed bag, including stuff from 2010 and 2016. Gråbergs Gråa Sång (talk) 10:39, 26 August 2025 (UTC)Reply
Support unsalting Someone searching for Gaza Holocaust (or Gaza holocaust, or any variation of this phrasing) is looking for the Gaza genocide article and any and all variations should redirect the user to the obviously intended article. Seems like weird gatekeeping to insist that the preferable option is to punish users searching for this phrase. JasonMacker (talk) 14:35, 26 August 2025 (UTC)Reply
Why would anyone search for this phrase? It’s not a common term. ꧁Zanahary꧂ 15:11, 26 August 2025 (UTC)Reply
Why prevent someone searching for it to be redirected to an article? Yacàwotçã (talk) 15:15, 26 August 2025 (UTC)Reply
Anyway, it's actually quite common, with at least a few dozen uses just in the last hour [11] Yacàwotçã (talk) 15:16, 26 August 2025 (UTC)Reply
Please read WP:R. Nowhere does it state that terms that aren't common shouldn't be redirected. For example, Biden recession redirects to Economic_policy_of_the_Joe_Biden_administration#2022 even though searching for "Biden recession" on Google only provides 4,870 results. In contrast, a search for "Gaza Holocaust" provides about 178,000 results ("Gaza genocide" is about 2,760,000 results). It is completely uncontroversial to redirect uncommon words or phrases when the presumed target is clear. The point is to direct readers to an article that most closely matches their inquiry, even if their inquiry is strange or unusual or uncommon. Offensive redirects or trolling can be salted, but this isn't an example of that. JasonMacker (talk) 01:14, 29 August 2025 (UTC)Reply
Reprotect as extended-confirmed, which is the default status for PIA topics, and leave the question of whether a redirect should be created to regular editing processes by extended-confirmed editors in good standing. signed, Rosguill talk 15:02, 26 August 2025 (UTC)Reply
+1; perhaps asking @El C: is a good idea, too. Lectonar (talk) 13:33, 27 August 2025 (UTC)Reply
Comment What would this article cover that Wikipedia is not already covering? Or would effect be just a duplicate article with a more strongly worded title? North8000 (talk) 15:26, 26 August 2025 (UTC)Reply
It would be a redirect, not a separate article. Bogazicili (talk) 15:33, 26 August 2025 (UTC)Reply
Strong support. The Holocaust refers to Holocaust, whereas a holocaust may mean massacre or genocide. See dictionary definitions: Oxford dictionary and Merriam-Webster. Reliable sources use holocaust to refer to different genocides:
Support unsalting and redirecting. Phrase is clearly in use per links provided in the discussion above. Much of the discussion in 2021 does not apply now that Gaza genocide exists.--Trystan (talk) 15:42, 26 August 2025 (UTC)Reply
I also support this. I agree with JasonMacker's sentiments above. David A (talk) 19:11, 26 August 2025 (UTC)Reply
Support The above links show that the phrase is used to refer to the Gaza genocide. Opm581 (talk | he/him) 21:52, 26 August 2025 (UTC)Reply
Support. Redirects do not need to be neutral, and they can embody viewpoints that other people find offensive. Compare War of Northern Aggression. --Trovatore (talk) 22:09, 26 August 2025 (UTC)Reply
Support per above. Yung Doohickey (talk) 00:30, 27 August 2025 (UTC)Reply
Oppose: This isn't the place to discuss this. This is. Logoshimpo (talk) 10:41, 27 August 2025 (UTC)Reply
If this isn't the "correct" place, why are you opposing then? Unnecessary stonewalling. Yacàwotçã (talk) 12:40, 27 August 2025 (UTC)Reply
For a contentious topic like this, this is probably a better place to establish a community consensus than a request page fewer people watch. Anomie⚔ 12:49, 27 August 2025 (UTC)Reply
17 people have commented so far, I think per the spirit of WP:NOTBURO, having this discussion here is ok. Also, if someone opened a discussion at WP:RFPP, I think a likely reaction would be something like "Heck, no, you have to establish a consensus for that first!"
Btw, we can finish this discussion with a request at WP:CR. Gråbergs Gråa Sång (talk) 13:17, 27 August 2025 (UTC)Reply
My link states at the beginning: "Before posting, first discuss with the protecting admin on their talk page. Post below only if you receive no reply.". If the nominator had followed these instructions: she might have been able get an outcome she wanted. Logoshimpo (talk) 07:45, 28 August 2025 (UTC)Reply
The nominator discussed and received a reply. If your quote is to be followed, WP:RFPP was then not an option. IMO it still was an option, but not a very good one. Gråbergs Gråa Sång (talk) 07:54, 28 August 2025 (UTC)Reply
Comment I'm pretty divided on this on. On one hand, yes, a small subsection of literature does compare the genocide in Gaza to the Holocaust. However I'm not sure that there's really any pedagogical improvement to Wikipedia by unsalting this and redirecting it to Gaza Genocide. On the other hand it's going to stir up a whole lot of acrimony from people who don't like the idea of the Holocaust being used to describe other genocides. There is a pretty large rift in genocide and holocaust scholarship over this topic. I don't know if this is a third rail we need to poke. Simonm223 (talk) 13:30, 27 August 2025 (UTC)Reply
It's not crystal clear, is it? At one point it was a redirect to Holocaust trivialization. Palestinian genocide accusation is not an unthinkable redirect. Gråbergs Gråa Sång (talk) 13:39, 27 August 2025 (UTC)Reply
It was because someone changed it without consensus. Anyway, today it's crystal clear that the term refers to the genocide currently taking place in Gaza. Yacàwotçã (talk) 14:13, 27 August 2025 (UTC)Reply
I guess the question I would ask is whether there are people searching for the genocide in Gaza who would search Gaza Holocaust and fail to find the relevant pages here as a result of that redirect's absence? If the answer is "no" or "we don't know" then I'd suggest this is not something we need to do at this time. The Holocaust is a specific genocide. Genocide studies does tend to focus on the particularity of genocides. We don't need to muddy these distinctions for little gain for our readership. Simonm223 (talk) 16:09, 27 August 2025 (UTC)Reply
On a related note, when I do a google search for "Gaza Holocaust" my top result is the WP page for Gaza Genocide anyway. This is circumstantial but suggests no actual benefit for discoverability. Simonm223 (talk) 16:10, 27 August 2025 (UTC)Reply
WP:RPURPOSE is clear: Closely related words
a holocaust is a related word to genocide per dictionary definitions above. Bogazicili (talk) 17:07, 27 August 2025 (UTC)Reply
Comment Should this discussion close with a consensus against unsalting or a consensus for a target other than Gaza genocide, I note that the user who created the intentionally typoed Gaza HOlocaust to get around the salting also created Palestinian Holocaust, Palestinian holocaust, Holocaust of Gaza, Holocaust of Palestine, and Holocaust of Palestinians at the same time, which might in that case need attention to align with the decision. Anomie⚔ 14:27, 27 August 2025 (UTC)Reply
Oppose - The term Holocaust is not a generic term. It refers to a very specific genocide, which is why Holocaust redirects to The Holocaust and not a disambiguation page of many different holocausts. Procedurally, having this discussion here, where any editor can participate, seems to run afoul of WP:CT/ARBPIA. Furthermore, per WP:SALT, "Editors wishing to re-create a salted title with appropriate content should either contact an administrator (preferably the protecting administrator) [and that was done here, with the protecting administrator not being willing to make the change], file a request for reduction in protection level, or use the deletion review process. ... [C]reation-protection is usually permanent." Coining (talk) 16:04, 27 August 2025 (UTC)Reply
This has already been refuted above by @Bogazicili. Yacàwotçã (talk) 16:34, 27 August 2025 (UTC)Reply
Not refuted convincingly, in my opinion. And in any case, I raised two addition points (about process) that have not been addressed. Coining (talk) 21:04, 27 August 2025 (UTC)Reply
  • Support unsalting Im not pro redirects in general, but this title meets our criteria for being a valid redirect: it's in use. Arguments that it isn't neutral don't address that the title is in compliance with WP:RNEUTRAL (redirects are not generally expected to be neutral). (t · c) buidhe 03:29, 28 August 2025 (UTC)Reply
Oppose - After this, as a reward, the word "hero" also redirects to the terrorist group Hamas. This is an encyclopedia, not a terrorist group's television! Edard Socceryg (talk) 17:43, 28 August 2025 (UTC)Reply
No clue what you're talking about here. Hero is an article in its own right, and basically always has been. It was moved once, in January 2016, to heroism, and quickly moved back. If it ever pointed to Hamas it was before the software started maintaining permanent move logs. --Trovatore (talk) 19:39, 28 August 2025 (UTC)Reply
This comment is so inappropriate that it is very nearly a UCOC violation. @Edard Socceryg I strongly encourage you to avoid making statements that seem to accuse other editors of being terrorists. Simonm223 (talk) 19:43, 28 August 2025 (UTC)Reply

Block all US federal IPs

edit
Latest comment: 1 day ago1 comment1 person in discussion

I feel that under the Trump adminstrations recent act against Wikipedia such as targeting editors who they think are negatively targetinf Israel, I feel that this could snowball into a thing where there will be a subsection of governent dedicated to remove information they dont like on Wikipedia under threat of litigation. I feel we should block IPs from US federal agencys from editing so that we can potentially stop any secret coordinated censorship efforts in advance. — Preceding unsigned comment added by 116.91.223.249 (talk) 12:19, 29 August 2025 (UTC)Reply

Discussion at Template talk:Tooltip § Render this as parenthesized text when used in the mainspace

edit
Latest comment: 1 day ago1 comment1 person in discussion

  You are invited to join the discussion at Template talk:Tooltip § Render this as parenthesized text when used in the mainspace. Sapphaline (talk) 21:21, 29 August 2025 (UTC)Reply

Propose to deprecate direct linking to non-English Wikipedia in articles

edit
Latest comment: 28 minutes ago5 comments4 people in 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
Add topic
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(proposals)&oldid=1308716973"