Wikipedia talk:Featured article candidates

From Wikipedia, the free encyclopedia

Shortcut

Image/source check requests

Main page: Wikipedia:Featured article candidates
Current requests


Requests should only be posted here for FAC nominations that have attracted several reviews and declarations of support. Premature requests can be removed by any editor.

FAC mentoring: first-time nominators

A voluntary mentoring scheme, designed to help first-time FAC nominators through the process and to improve their chances of a successful outcome, is now in action. Click here for further details. Experienced FAC editors, with five or more "stars" behind them, are invited to consider adding their names to the list of possible mentors, also found in the link. Brianboulton (talk) 10:17, 30 August 2016 (UTC)

FAC source reviews

For advice on conducting source reviews, see Wikipedia:Guidance on source reviewing at FAC.

Templates in reviews?

I noticed just now that the instructions at the top of WP:FAC say not to use {{tq}}. Why not? I use that all the time as the most convenient way to quote excerpts from the article being reviewed. Nobody's ever complained. I also noticed that {{collapse top}} and {{collapse bottom}} are specifically called out as OK, yet I see Gog the Mild recently objected to their use. Do we need to review the instructions to make sure they jive with current reality? RoySmith (talk) 17:45, 19 February 2026 (UTC)

Fairly certain that {{tq}} dramatically worsens the WP:PEIS of WP:FAC. See this comment. ~~ AirshipJungleman29 (talk) 18:15, 19 February 2026 (UTC)
{{tq}} slows down the loading of the main FAC page and can cause it to crash out, which is why they are barred. Although {{collapse top}} and {{collapse bottom}} don't really slow it down, it means coords have to go through and open each set of comments when it comes to reviewing nominations, so it's a pain for them. - SchroCat (talk) 18:21, 19 February 2026 (UTC)
citation needed. I just tried an experiment. I built three test pages which transclude 50 copies of a review page:
Within the limits of what I can measure using either Chrome's network analysis tab or "curl" on the command line, I see no difference in load times. RoySmith (talk) 18:44, 19 February 2026 (UTC)
Well, it's a known problem which affects some people. Mike Christie did some of the technical stuff on it last time and would be able to provide some hard details. This discussion has further details as well as comments from people who see a degradation in load times and crashing out when templates are used. - SchroCat (talk) 18:55, 19 February 2026 (UTC)
Hi, Roy; at work at the moment so can't post much but will post to your talk page later. The problem is the multiplier effect on multiple long tq quotes; the transclusions of the individual FACs double the cost and it can add up quickly. Mike Christie (talk - contribs - library) 19:32, 19 February 2026 (UTC)
Your experiment demonstrates the problem. The post expand include size is breached at User:RoySmith/sandbox/t1-50 (and both the others). That is why parsing of all three pages fails and the last 30 transclusions are not expanded. This is why such templates are banned, to avoid breaking the WP:FAC page. DrKay (talk) 21:20, 19 February 2026 (UTC)

Proposal to change size guidelines in WP:SIZE

FYI: There is a talk page discussion about changing the article size guidance (9,000 words, etc) in WP:SIZE. Noleander (talk) 13:33, 21 February 2026 (UTC)

Removing archive.today links in source reviewing

Hello. I thought of bringing this to the attention of various active users involved in FAC, and this would probably be a crucial part of source reviewing. Basically, per an RfC, it's been decided to deprecate all archive.today links as soon as possible. Please note this is archive.today and not archive.org, the latter being the Web Archive. See WP:ATODAY for more details, but I shall quote the remarks here:

There is consensus to immediately deprecate archive.today, and, as soon as practicable, add it to the spam blacklist (or create an edit filter that blocks adding new links) and remove all links to it. There is a strong consensus that Wikipedia should not direct its readers towards a website that hijacks users' computers to run a DDoS attack (see [WP:ELNO#3]). Additionally, evidence has been presented that archive.today's operators have altered the content of archived pages, rendering it unreliable. Those in favor of maintaining the status quo rested their arguments primarily on the utility of archive.today for verifiability. However, an analysis of existing links has shown that most of its uses can be replaced. Several editors started to work out implementation details during this RfC and the community should figure out how to efficiently remove links to archive.today.

I don't think it should be a major problem, since most archived links would be using from the Web Archive, and the RfC has brought up alternatives in case the links aren't as accessible on the Web Archive (e.g. Ghost Archive and Megalodon).

I suppose this would be important in source reviewing here, so just want to inform people here about it, especially if any archive.today links are used.--ZKang123 (talk · contribs) 02:29, 22 February 2026 (UTC)

FAC reviewing statistics and nominator reviewing table for February 2026

Here are the FAC reviewing statistics for February 2026. The tables below include all reviews for FACS that were either archived or promoted last month, so the reviews included are spread over the last two or three months. A review posted last month is not included if the FAC was still open at the end of the month. The new facstats tool has been updated with this data, but the old facstats tool has not. Mike Christie (talk - contribs - library) 22:44, 6 March 2026 (UTC)

More information Reviewers for February 2026, # reviews ...
Close
More information Supports and opposes for February 2026, # declarations ...
Close

The following table shows the 12-month review-to-nominations ratio for everyone who nominated an article that was promoted or archived in the last three months who has nominated more than one article in the last 12 months. The average promoted FAC receives between 7 and 8 reviews. Mike Christie (talk - contribs - library) 22:44, 6 March 2026 (UTC)

More information Nominators for December 2025 to February 2026 with more than one nomination in the last 12 months, Nominations (12 mos) ...
Close

-- Mike Christie (talk - contribs - library) 22:44, 6 March 2026 (UTC)

  • @Mike Christie: Could you tell me about the number in that last column. Like, what sort of number is ideal? Bgsu98 (Talk) 23:27, 6 March 2026 (UTC)
    Some editors don't pay the number any attention and will review whatever articles they feel like reviewing. Some editors look at these numbers and are more predisposed to reviewing articles nominated by editors who have a higher review ratio, but I don't know if anyone has a particular minimum they feel like you should hit. My goal for myself is to review at least eight articles for every one I nominate, because that means I'm putting in more reviews than my nominations consume. Mike Christie (talk - contribs - library) 11:26, 7 March 2026 (UTC)

Use of sidebar in FAs

A discussion in the Crusading movement FAC about the use of {{sidebar}} sent me down a rathole, and I don't like what I found. According to {{Navbox visibility}}: Templates using [sidebar] are not displayed in article space on the mobile web site of English Wikipedia A little experimentation confirmed this. It also says Mobile page views accounted for 60% to 70% of all page views from 2020 through 2025. So I did some digging and discovered that {{sidebar}} is commonly used in FAs. I count 74 instances (my script may have missed a few).

More information The 74 miscreants ...
Close

It disturbs me that we're including in our best articles content which is not visible to the majority of our readers. The question is, what do we do about it? RoySmith (talk) 16:13, 10 March 2026 (UTC)

  • There are a few other things not visible on mobile -- red links, some ILLs, and navboxes, off the top of my head. I'm not sure I follow the argument that we should a priori remove things if they're not visible to mobile users (or any other large-ish subgroup). I wonder if we could think of this similarly to MOS:COLOUR or MOS:NOFORCELINK -- there are some things (like colour and links) that not all of our readers can use, so we should ensure that they aren't essential to understanding the article, but equally shouldn't necessarily take them away from the people for whom they're helpful just because not everyone can make use of them (EDIT: so, to make a completely unsolicited comment on the discussion at Crusading movement -- yes, add alt text). UndercoverClassicist T·C 16:25, 10 March 2026 (UTC)
    I'm not arguing that we should remove it. I'm arguing that we should find some other way to display it which works for the majority of our readers. RoySmith (talk) 16:33, 10 March 2026 (UTC)
    I'm not sure I see the distinction. What sort of concrete change do you have in mind? UndercoverClassicist T·C 16:56, 10 March 2026 (UTC)
    UndercoverClassicist kind of said what I was going to say: since there are several kinds of data that WP does not render on mobile platforms, FA editors have a responsibility to ensure that data (that is dropped on mobile) is given to mobile users in another manner. FA does this already (in an accessibility context) with MOS:COLOR where we permit FA articles to use colors to convey information in diagrams, but require that the data be also conveyed another way (e.g. text labels). So, for sidebars, I'd suggest FA use the guideline "any important data stated in the sidebar must also be stated elsewhere in the article, such as body text". Noleander (talk) 17:04, 10 March 2026 (UTC)
    Sidebars don't usually provide important data: they normally provide links to other related articles. In most cases I think those are very much "nice to have"s -- I don't think their absence will really be noticed. I suppose one question we could ask is "if all the non-mobile content is removed, does the article still meet the WP:FACR?". UndercoverClassicist T·C 17:13, 10 March 2026 (UTC)
    Sidebars and InfoBoxes tend to fall into two camps: (a) a bunch of wikilknks e.g. Bridge; or (b) A bunch of statistics e.g. Sun. The former, as UC says, don't require any special treatment; but the latter (vital statistics) may require special treatment. Do both Template:Sidebar and Template:Infobox have the same "not displayed on mobile" behavior? UC's guidline "if all the non-mobile content is removed, does the article still meet the WP:FACR?" is broader and more future-proof than my "any important data stated in the sidebar must also be stated elsewhere in the article, such as body text". Noleander (talk) 17:21, 10 March 2026 (UTC)
    Infoboxes do display on mobile: they're a different thing altogether from sidebars. Most FAs have infoboxes (yes, I know that there are strong opinions on that point!), so we would be well advised to keep them separate for this discussion. UndercoverClassicist T·C 17:24, 10 March 2026 (UTC)
    What I don't understand is what makes infoboxes and sidebars so different that one displays on mobile and the other doesn't? My template-fu is pretty weak, but on the surface they seem very similar so it's odd to me that they behave so differently. RoySmith (talk) 17:31, 10 March 2026 (UTC)
    The answer may lie with phab:T124168. UpTheOctave! • 8va? 17:35, 10 March 2026 (UTC)
    I had no idea that Sidebars and InfoBoxes were treated so differently on mobile. The guideline "If all the non-mobile content is removed, does the article still meet the WP:FACR?" is correct and useful. Should the FAC process add a new, mandatory task for "Displays okay on Mobile?" (in addition to existing "Image Review" and "Source Review" tasks)? Noleander (talk) 17:44, 10 March 2026 (UTC)
    We already have accessibility reviews, but nobody really does them anymore AFAIK. Maybe something to think about bundling in there? UpTheOctave! • 8va? 17:46, 10 March 2026 (UTC)
  • I fully agree with the above comment (and the alt text was added). Borsoka (talk) 16:29, 10 March 2026 (UTC)
  • Collapse them by default like infoboxes, works fine on mobile. FunkMonk (talk) 18:42, 10 March 2026 (UTC)

Crusading movement not appearing

Wikipedia:Featured article candidates/Crusading movement/archive2 is still in the list, but it's not appearing. I'm guessing there's some unclosed template in the previous transclusion, but I can't find it. RoySmith (talk) 13:32, 14 March 2026 (UTC)

No, the WP:PEIS limit has been reached. I don't know why @FAC coordinators: haven't been archiving noms—there are several month-old nominations with no or one support which surely should have been archived a while ago. Or maybe someone has been using {{tq}} in their reviews? ~~ AirshipJungleman29 (talk) 13:43, 14 March 2026 (UTC)
{{tq}} is used over 50 times in Wikipedia:Featured article candidates/Japan Cup/archive1, does that affect it then? —Serial Number 54129 (wake up Fortuna) 13:54, 14 March 2026 (UTC)
Yes, if someone could go through that and convert all the tq’s to green or something, that might help (not at my computer right now); but the problem of overdue archiving will remain. ~~ AirshipJungleman29 (talk) 14:05, 14 March 2026 (UTC)
That was me, from before I was aware that you weren't supposed to do that. I've changed them all to {{green}}.
From a software engineering point of view, this process of taking everything and transcluding it into one huge page seems like a very strange way to do things. DYK does that same thing, with the same result: running into the PEIS limit. If it hurts when you do that, don't do that. RoySmith (talk) 14:05, 14 March 2026 (UTC)
WP:RFD also does that (dumping all active RFD nominations on that page) and I think it also exceeds the WP:PEIS if you scroll all the way to the bottom. I see that you talked about the use of templates on FAC in case the main FAC page or its archives exceed the limit, which is the reason why they shouldn't be used on FAC. It would be WP:CREEP to apply it to DYK/RFD because I'm so used to using the tq template for quotes and there are far more DYK noms than FACs. JuniperChill (talk) 14:28, 14 March 2026 (UTC)
AirshipJungleman29: Several FACs were promoted this morning, so hopefully that helps clear up some space. Bgsu98 (Talk) 14:41, 14 March 2026 (UTC)
We need to be stricter about either 1) archiving 2) template usage or 3) both. Wikipedia:Featured article candidates/Japan Cup/archive1 currently calls 92 templates. 5 of these are from the FAC header and there are a few pings in here. Even though {{green}} and its kin are cheaper for PEIS than {{tq}} do we really ned to be using colorized text that often? Wikipedia:Featured article candidates/Bicentennial Capitol Mall State Park/archive1 has a PEIS when pulling the FAC as a separate page of 46,098 due to 15 uses of tq, including one that covers an entire proposed lead. Wikipedia:Featured article candidates/George Brown (cricketer, born 1887)/archive1 is another one with an excessive amount of template usage and as a stand-alone page runs at over 29,000. Comparatively, the Crusading movement FAC is under 15,000. Wikipedia:Featured article candidates/Battle of Goodrich's Landing/archive1 is currently under 10,000 as is Wikipedia:Featured article candidates/Carlisle & Finch/archive1, and several others I looked at are below 20,000 as well. Keep in mind that with how the FACs are being transcluded, the templates in these FACs are being transcluded again onto the main FAC page. There's no reason why it's necessary to use colorized text 70+ times in a single FAC. Hog Farm Talk 16:00, 14 March 2026 (UTC)
I use the green template when quoting from the nominated article, because I'm certain it makes my reviews a lot easier to read and understand. Maybe I'll switch to using italics or boldface for that purpose ... I presume those do not incur the template penalty? Noleander (talk) 16:32, 14 March 2026 (UTC)
I use colorized text because it's the most straightforward way to visually set off what I'm saying from what I'm quoting. Sure, I could just use ascii quotes, but when the text I'm quoting has quotes inside it, that gets messy. Why do we need to be transcluding all these things into one big page anyway? It's not like anybody even reads it as one big page; everybody has that nice script that hides the content of each individual page. Yet we still suffer from the PEIS limit of smashing everything into one big blob.
Why couldn't we do something like what WP:SPI does? Each SPI is its own page, and there's a bot that runs periodically to build a nice summary in WP:Sockpuppet investigations/SPI/Cases. Never any problem with PEIS, and it all loads a lot faster into the bargain.
PS: I'm happy to switch to using bold per Noleander's comment above. It's even easier to type than {{green}} or even {{tq}}. But I still think transcluding everything into one big blob is a sub-optimal way to do things. And, yes, I agree that it would be nice if archive/promotions happened quicker :-) RoySmith (talk) 16:35, 14 March 2026 (UTC)
A few issues with that approach that would need to be addressed. First, from my understanding SPIs are usually archived on a per-sockmaster basis, as opposed to FACs where archives are sorted by month - that means that noms with a lot of templates break not only the main FAC page but also potentially the archive pages. Second, It's not like anybody even reads it as one big page - says who? I sure do that, here as a reviewer and at FAR (which has a similar setup) as a coordinator. And I suspect the only way to make a summary like the SPI one which would provide enough information to not want to do that, would require a lot more templates - which, see first point. Happy to be proven wrong on that. Nikkimaria (talk) 03:32, 15 March 2026 (UTC)
I'm not sure I want to volunteer to write such a bot, but if one existed, what information would you want to see the summaries include to make it useful for you? RoySmith (talk) 14:28, 15 March 2026 (UTC)
Speaking for myself, I often scroll down thru the full FAC page, not so much to read the individual reviews, but rather to see how many reviewers each nomination has: I'm looking for nominations with only 1 or 2 reviewers that may need an additional reviewer. For my purposes, I'd be content seeing a summary of each nomination like this:
This is a Level 3 Vital Article about bridges, important structures that many of us use every day. Thanks to reviewers: .... I made heavy use of the new Veracity citation management tool, developed by User:Anne drew. Noleander (talk) 23:32, 5 December 2025 (UTC)
Introductory text provided by nominator at top of the nomination. (talk) 23:32, 5 December 2025 (UTC)
  • No reviews yet.
Introductory text provided by nominator at top of the nomination. (talk) 23:32, 5 December 2025 (UTC)
  • Review by Reviewer A ; 359 words.
  • Source Review by Reviewer C ; 1,900 words. "... Strongly Oppose ..."
  • Review by Reviewer D : 1,600 words. "... Leaning Support..."
  • Image Review by Reviewer B ; 566 words. Pass.
  • Review by Reviewer E ; 359 words. "Will oppose if that is not fixed"
The intention is to give a brief summary of the nomination, with links to the individual review subsections within the nomination. A crude word count of all words (including replies) for each review. To get the Support/Oppose/Pass/Passed/Fail/Failed information: to Keep It Simple, I'd be happy if the tool displayed any occurrence of those six words, plus a couple of words on either side of it. Sure, it would probably display some random phrases from the review ( "Did Lincoln really support the war?") but getting it more precise would be a difficult software task. On the other hand, there already is an FAC statistics tool that produces a monthly report, and it contains logic to parse the nomination to find reviewer names and their individual support/oppose conclusion. But I'd want to see phrases like "Leaning Support" which is ignored by that monthly stat tool ... so not sure if that tool can be re-purposed. Noleander (talk) 19:28, 15 March 2026 (UTC)
The problem with that is the extraneous number of false hits that will be thrown up. There are, for example, currently 30 uses of the word “oppose” in all FACs; only two are actual oppose !votes. I couldn’t face looking through all 267 uses of the word ‘support’ to see how many were just general comments.
Like Nikkimaria I also skim through the full open page with all dialogue showing, but if I’m after a summary, the current collapsed version covers 85% of what I want. (If it could also show the number of opposes in the summary, that would be much better - does anyone have any idea why it doesn’t?) - SchroCat (talk) 19:43, 15 March 2026 (UTC)
Yikes ... That is a lot of stray Support/Opposes that would be displayed. Noleander (talk) 19:50, 15 March 2026 (UTC)
The FAC statistics are generated by a tool, but there's a human editing step to correct all the mistakes it makes. It's about 80-90% accurate without human intervention, and I don't think that's good enough for the purposes you're looking for. Mike Christie (talk - contribs - library) 01:36, 16 March 2026 (UTC)
Interesting that there's so much ambiguity. DYK uses a small set of icons to communicate status and there never seems to be any problems with scripts mis-interpreting what they mean. RoySmith (talk) 13:25, 16 March 2026 (UTC)
I think the fact that the coords (and, often, the reviewers) want to preserve nuance is a natural consequence of the fact that FAC is in part a conversation rather than a well-defined process. If FAC were solely defined in terms of clearly delineated statuses we could use a set of icons, but it isn't, or at least a significant minority of the icons would be "Nuanced comment that you have to read", which would defeat the purpose. Mike Christie (talk - contribs - library) 16:01, 16 March 2026 (UTC)
That looks like a good starting point for a reviewer; a coordinator might need even more. For example, that "will oppose if that is not fixed" - did that happen yesterday or a while ago, and if the latter has the nom attempted to fix it? Nikkimaria (talk) 03:01, 16 March 2026 (UTC)
  • In the last couple of days since this thread opened, we have moved to four nominations that have dropped off the bottom (The Path to Rome, George Brown, Karma and Crusading movement). - SchroCat (talk) 15:41, 16 March 2026 (UTC)
    It has become fashionable to use lots of coloured text - usually green. If italics or quotation marks are used instead this might help to resolve the problem. Graham Beards (talk) 16:09, 16 March 2026 (UTC)
    Does substituting templates help? I find my green text makes for more readable reviews (bold is a bit shouty and italic much less visibly different), but I could do this if it helps. UndercoverClassicist T·C 16:32, 16 March 2026 (UTC)
    @UndercoverClassicist, I just tested it out, and a single use of Template:Green will only use up 37 bytes toward the PEIS. So substing it will probably have a moderate effect, which is unlikely to help much unless the only templates used on these pages are ten thousand Template:Greens. (By contrast, Template:Tq uses 154 bytes toward the PEIS.) – Epicgenius (talk) 20:29, 18 March 2026 (UTC)
    There must surely be a technical reason; this is very unusual, in my recollection. Mike Christie, can you see any possible byte-devouring templates? Or is it really just because there is so much text? ~~ AirshipJungleman29 (talk) 17:18, 16 March 2026 (UTC)
    I'm going to guess it's tq, because it usually is, but I don't know a quick way to tell. I guess that's another argument for a bot. I could put it on my todo list if there's support for it, but I wouldn't get to it for weeks at least, perhaps longer, so someone else might take it on. Hawkeye7? Mike Christie (talk - contribs - library) 22:36, 16 March 2026 (UTC)
    Mike Christie, a massive part of the problem seems to be Wikipedia:Featured article candidates/Great white shark/archive2, which has a byte size of 64kb but a PEIS size of 400kb. Only thing is, I can't figure out what the precise problem is. ~~ AirshipJungleman29 (talk) 11:17, 18 March 2026 (UTC)
    Turns out that the {{speciesbox}} was adding almost 300kb of PEIS. I'll move it to the talk page. ~~ AirshipJungleman29 (talk) 11:20, 18 March 2026 (UTC)
  • I am in favor of a summary page, such as Wikipedia:Peer review has, instead of transcluding everything on a single page. WP:FAC simply is too large for a single page, and loading it is, on my end, super slow and laggy (with or without the script). Of course, coordinators would still have to open the individual pages to see where the nom is standing, but when I scroll through the page, I'm usually just interested in what articles are on offer to begin with. At Peer Review, only longer reviews are summarized while very short ones are shown directly, which could channel additional attention to noms that didn't yet receive substantial feedback. Asking people to stop using "green" templates apparently does not work well enough and in any case, I think we should fix the underlying architecture issue rather than keeping this eternal workaround where we have to ask each new reviewer not to use standard templates that are in wide use on other pages. --Jens Lallensack (talk) 16:37, 16 March 2026 (UTC)
    Along those lines, one of my continual annoyances is that when I see an edit comment on my watchlist of "Promote 1, archive 1", I can't see which ones have been promoted and archived until I click the diff link, and that is, as Jens puts it "super slow and laggy". I just timed it in Chrome's network performance tool; loading https://en.wikipedia.org/w/index.php?title=Wikipedia:Featured_article_candidates&diff=prev&oldid=1343555285 took almost 11 seconds to load. I assume the actual diff of the source transclusion lines was trivial to compute, but it won't show me that until it's slogged through generating a full preview of "Revision as of 2026-03-15T01:45:47" RoySmith (talk) 16:52, 16 March 2026 (UTC)
    I'm inclined to agree with Jens Lallensack. But if the FAC community does insist on continuing to transclude FACs in their entirety, coordinators will need to be much more aggressive about archiving. If the page breaking is a semi-regular feature of the FAC process, FAC is not functioning properly. A. Parrot (talk) 16:54, 16 March 2026 (UTC)
    Technical issues should not drive policy. If the issue with archiving speed is that the coords want to give those nominations more time, that's their call, and I'd hate to force their hand because of a software problem. Much the same thing happens at DYK; the decision of when to switch to two-sets-per-day mode is usually driven by when they hit the PEIS limit. I'd hate to see FAC go down that same path. RoySmith (talk) 17:28, 16 March 2026 (UTC)

This list might capture some of the suggestions made above (apologies if I'm not representing the ideas accurately): Noleander (talk) 17:52, 16 March 2026 (UTC)

  1. Continue with full transclusion (like WP:DYK and WP:RFD). Occasionally hit WP:PEIS limits. Strive to promote/archive more frequently.
  2. Continue with full transclusion, but avoid PEIS limits by enforcing prohibitions against slow templates. Favor italics & boldface?
  3. Transclude all nominations: but truncate or omit if they are large (like WP:PR) "This review is too large to display here. Please go to the review directly."
  4. No transclusions: replace with a bot-generated summary of each nomination that displays: reviewer names; size of each review; support/oppose; link to individual reviews; date of last comment. Tool may have a hard time extracting support/oppose data.
  5. Keep transclusions: start using a bot that replaces expensive template calls (inside the nominations) such as {{tq}}, and perhaps even {{green}}, with non-template or cheaper template versions. May be fairly easy to write.
  6. ... other? ...
How about a bot that replaces expensive template calls such as {{tq}}, and perhaps even {{green}}, with non-template or cheaper template versions? That might not be hard to write. Mike Christie (talk - contribs - library) 17:46, 16 March 2026 (UTC)
Added to list above as (5). Noleander (talk) 17:49, 16 March 2026 (UTC)
I think we really need to adopt 3; I think it's a real problem we got a page so huge that it's a real pain to use without a userscript. The downsides are quite minor in comparison to the benefits. Generalissima (talk) (it/she) 13:58, 18 March 2026 (UTC)
Looks like a big part of the issue was the taxobox template I added. My apologies, although I'm genuinely surprised that it was that high. Following @Mike Christie's idea, would there be a way to enforce that prohibition, for example by adding a conditional to the taxobox template to not make it load when transcluded on pages like Wikipedia:Featured article candidates? Chaotic Enby (talk · contribs) 11:33, 18 March 2026 (UTC)
The bulk of it in the taxobox template comes from {{Fossil range}} (and its little cousin {{Period fossil range}}). The HTML size isn't that big (7kB in total, and some of it could be trimmed with a bit of rounding and/or TemplateStyles) but they both use some pretty number-heavy #expr calculations, and I'm wondering if rewriting them in Lua might be helpful in that regards. Chaotic Enby (talk · contribs) 11:44, 18 March 2026 (UTC)
My apologies if this sounds harsh, but I'm strongly opposed to changing how the taxobox template is implemented just to accommodate how FAC organizes its review process. That's the tail wagging the dog. RoySmith (talk) 13:02, 18 March 2026 (UTC)
Why do they need to be written at all? I'm not sure why they're needed in the course of a review anyway - it's something that should be in the article, not on a review page. - SchroCat (talk) 13:04, 18 March 2026 (UTC)
^--This right here. Bgsu98 (Talk) 13:31, 18 March 2026 (UTC)
There was a good rationale in this particular case (we were mocking up a proposed change to the taxobox), but agreed that this is a pretty rare situation. The section of the review with the box was moved to a Talk page after it ceased to be a live issue: that seems like a good practice for the future, and I've started doing it with resolved comments in my longer reviews. UndercoverClassicist T·C 14:28, 18 March 2026 (UTC)
Yes, I think it would help if that bit of WP:FACSUPPORTOPPOSE ("reviewers may transfer lengthy, resolved commentary to the FAC archive talk page, leaving a link in a note on the FAC archive") was followed more generally. I know Gog the Mild isn't the biggest fan, but some reviews are very very lengthy. ~~ AirshipJungleman29 (talk) 14:38, 18 March 2026 (UTC)
Yes, part of my reservation was that I've previously been told that it's discouraged to use collapse templates to condense a long review, since the co-ordinators would like to be able to see the whole discussion. I suspect it's getting to the point where I've been doing enough of these that if I've got a "support" underneath a hatnote saying "resolved comments moved to Talk", they have a fairly good idea of what that talk page will look like. However, that might not work for people whose reviews are fewer or less predictable. UndercoverClassicist T·C 15:46, 18 March 2026 (UTC)

Are there any objections to (5) above (bot cleanup of disallowed templates)? I can see we might need other actions too, but is there any problem in principle with this idea? Mike Christie (talk - contribs - library) 17:39, 18 March 2026 (UTC)

I'm fine with a bot changing {{tq}} to {{green}} since that seems like it would be non-disruptive and already identified as a problem. I'm not sure I'd want to see more than that. Certainly not auto-nuking taxoboxes. FWIW, I've been playing around a bit with some code to implement the summary page idea I described upthread. For now, it's really just some sketches of ideas. It may never get past that stage, and I certainly don't want to be a blocker if other people have better ideas they want to implement.
It might be useful if WP:NOMV (I think that's the right script) could compute the PEIS for each individual page and include that on the summary line. I don't know how expensive that would be to implement, though. It wouldn't fix anything, but at least would make it easier for people to spot which page was causing the problem. I assume AirshipJungleman29 diagnosed this by manually slogging through each page in turn; while I appreciate the effort, surely that's not an efficient way for humans to be spending their time. RoySmith (talk) 17:57, 18 March 2026 (UTC)
  • Support 5 - Options (3) and (5) are both effective, low-cost, incremental, and low-risk. Option (4) is effective, but would require a difficult software tool to be created, and would be a major change to the FAC display, so may get pushback. Options (1) and (2) are band-aids, not long-term solutions. Between options (3) and (5), both are fine, but (5) appears to have a volunteer ready to move forward with the work (Mike Christie, perhaps?) ... so I'd support (5). Noleander (talk) 18:25, 18 March 2026 (UTC)

Pardon my French

This is weird. Chrome has suddenly decided the FAC listing is written in French and has tried to translate it to English, notably turning "nomination" into "appointment". Any idea what happened to cause that? Or is this just another AI-induced hallucination? RoySmith (talk) 15:47, 18 March 2026 (UTC)

Strange... I also use Chrome, and the FAC listings are normal for me, even though I have the automatic translation thing enabled for nearly all languages (including French I believe). Icepinner (Come to Hakurei Shrine!) 16:06, 18 March 2026 (UTC)
Chrome is obviously detecting some French text on the page (or something that it thinks is French text). HJ Mitchell | Penny for your thoughts? 16:14, 18 March 2026 (UTC)

Related Articles

Wikiwand AI