View source for Wikipedia talk:Reliable sources/Perennial sources/Archive 13

{{Automatic archive navigator}}

== Addressing hard template limits ==

{{WP:RSPPEIS|1,863,757|time=21:00, 18 October 2025 (UTC)}}<!-- For 'time' value, you can enter five tildes.  -->
<div style="width:40em; background-color:#f8fff8; border:thin solid #ddd">
{{hidden
  | header = Section contents <span style="font-weight:normal; font-style:italic; font-size:smaller; padding-left:3em;">([[#toc|page contents]])</span>
  | headerstyle = background:#f8fff8; padding-left:-4em
  | style=text-align:center; margin:0.8em 1.2em;
  | expanded=true
  | content= {{ubl |<!--style not working: style=width:30em-->
  | §.1	 [[#WaId's central list, and click to longer explanation|WaId's central list, and click to longer explanation]]
  | {{ubl | item_style=padding-left:1.6em
      | §.1.1 [[#sidebar on PEIS capacity and saving PEIS bytes by manipulation of templates|sidebar on PEIS capacity and saving PEIS bytes by manipulation of templates]]
      | §.1.2 [[#arbitrary break|arbitrary break]]
    }}
  | §.2	 [[#Raladic's table options|Raladic's table options]]
  | §.3	 [[#Mg's central list plus multiple landing pages|Mg's central list plus multiple landing pages]]
  | §.4	 [[#Infobox design|Infobox design]]
  | §.5	 [[#Showcasing different approaches|Showcasing different approaches]]
  | {{ubl | item_style=padding-left:1.6em
      | §.5.1 [[#Approach summary|Approach summary]]
    }}
  | §.6	 [[#Yikes, four bytes left|Yikes, four bytes left]]
  | §.7	 [[#One giant table approach|One giant table approach]]
  | §.8	 [[#Implementation planning|Implementation planning]]
  | §.9  [[#Row-builder module approach|Row-builder module approach]]
  | {{ubl | item_style=padding-left:1.6em
      | §.9.1 [[#Python demo|Python demo]]
      | §.9.2 [[#Aidan's demos|Aidan's demos]]
    }}
  | §.10 [[#How should we word an rfc?|How should we word an rfc?]]
  | §.11 [[#Barring new rows from the live table|Barring new rows from the live table]]
}}
}}
</div>

This page is hovering around the hard template limits imposed by [[WP:PEIS]] (see section above). Tinkering with some templates as Aaron Liu and I have done is a temporary solution at best. I believe we must contemplate other larger-scale solutions. I think we need to gather some data first, and then talk over where we want to go. For starters, the general design of the page involves one big table that sources in eight subtables, accounting for roughly 60% (1,259,287) of the hard PEIS limit of 2,097,152 bytes, and they are the following:
{{/chunk table}}
* [[Wikipedia:Reliable sources/Perennial sources/1]] – 116,373
* [[Wikipedia:Reliable sources/Perennial sources/2]] – 220,091 &nbsp; <small>(update: 218,245; see below)</small>
* [[Wikipedia:Reliable sources/Perennial sources/3]] – 170,887
* [[Wikipedia:Reliable sources/Perennial sources/4]] – 196,889
* [[Wikipedia:Reliable sources/Perennial sources/5]] – 145,381
* [[Wikipedia:Reliable sources/Perennial sources/6]] – 150,100
* [[Wikipedia:Reliable sources/Perennial sources/7]] – 148,957
* [[Wikipedia:Reliable sources/Perennial sources/8]] – 110,609
One approach would be breaking up the page into two (e.g., A–J, M-Z or wherever the midpoint is), which would bring each half down to roughly 70% of max PEIS, and still allow some room for growth. Another approach is to analyze the custom RSP templates used in each row ([[WP:RSPSHORTCUT]], [[WP:RSPSTATUS]], [[WP:RSPLAST]], and [[WP:RSPUSES]]—didn't I miss one?) and see how they might have a lower footprint. Along with those, there are the two templates {{t|anchor}} and {{t|efn}} which are fairly easily replaced with non-template code, and would be an immediate savings. I'll have more later, but I'd like to get some feedback at this point. [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 03:26, 15 September 2025 (UTC)
:Splitting the list in any way without giving us a full list somewhere was widely opposed at [[Wikipedia talk:Reliable sources/Perennial sources/Archive 10#Page size]]. [[User:Aaron Liu|<span class="skin-invert" style="color:#0645ad">Aaron Liu</span>]] ([[User talk:Aaron Liu#top|talk]]) 04:26, 15 September 2025 (UTC)
:: If a page is unrenderable by Wikimedia software due to hard limits, consensus to display the page anyway holds no water, if it is impossible for technical reasons; consensus can simply be ignored in cases like that. However, we needn't worry too much about that yet, because other approaches are available. [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 04:54, 15 September 2025 (UTC)
:::Participants would prefer to centralize the wikitext on one page rather than not have a centralized page. [[User:Aaron Liu|<span class="skin-invert" style="color:#0645ad">Aaron Liu</span>]] ([[User talk:Aaron Liu#top|talk]]) 11:39, 15 September 2025 (UTC)
::I would suggest making use of the search function. Instead of trying to view a page that's nearly impossible to load, "search in subpages" could save the day without giving away the ability to quickly locate the sources people want to find. [[User:SuperGrey|'''<span style="color:#765CAE">Super</span><span style="color:#525252">Grey</span>''']] ([[User talk:SuperGrey|talk]]) 08:12, 15 September 2025 (UTC)
:::If making full use of the "search in subpages" function, we could also go even further and make all entries in subpages, like what we do with good article reviews. [[User:SuperGrey|'''<span style="color:#765CAE">Super</span><span style="color:#525252">Grey</span>''']] ([[User talk:SuperGrey|talk]]) 08:17, 15 September 2025 (UTC)

As an experiment, I took subpage #2, the largest template expansion size at 220,091 bytes originally, and applied just the conversions of {{t|anchor}} and {{t|efn}} to see what would happen. The new size was 218,245, for a savings of 1846 bytes, or 0.84%. If we projected that over all eight sources with similar results, we might save around 10,500 bytes, out of 1,259,287 for all eight. That is very slim savings; perhaps enough to stave off immediate disaster, but doesn't allow for much expansion, if any. We should investigate simplification of the RSN-related templates used in the rows, to see if there are any savings available there. [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 05:10, 15 September 2025 (UTC)
:I mentioned pruning the excessive unused shortcuts that have been added in recent months above. [[User:Aaron Liu|<span class="skin-invert" style="color:#0645ad">Aaron Liu</span>]] ([[User talk:Aaron Liu#top|talk]]) 11:24, 15 September 2025 (UTC)
:I know this is going to be ugly, but moving the current sub-page to an 'original' (where template changes update and which can be edited), having a bot on a daily basis (and/or on demand) do a nearly full subst to a protected page which we then transclude? [[User:Beetstra|Dirk Beetstra]] <sup>[[User_Talk:Beetstra|<span style="color:#0000FF;">T</span>]] [[Special:Contributions/Beetstra|<span style="color:#0000FF;">C</span>]]</sup> 11:26, 15 September 2025 (UTC)
:Also note that a random sample RSP entry (Baidu Baike) took up just 3,407 bytes. 10,500 is more than enough for three new entries. [[User:Aaron Liu|<span class="skin-invert" style="color:#0645ad">Aaron Liu</span>]] ([[User talk:Aaron Liu#top|talk]]) 11:40, 15 September 2025 (UTC)

=== WaId's central list, and click to longer explanation ===

What about having a single, central minimal list, with each entry linking to a longer explanation?  For example:
* ''{{fake link|The Daily News}}'' (dailynews.com)
and you click through to [[Wikipedia:Reliable sources/Perennial sources|Wikipedia:Reliable sources/Perennial sources/D#Daily_News]] to see the whole entry.  Shortcuts would go straight through to the whole entry.  The central list would primarily exist for people who aren't sure whether the publication/site they're looking at actually has an entry. [[User:WhatamIdoing|WhatamIdoing]] ([[User talk:WhatamIdoing|talk]]) 17:24, 15 September 2025 (UTC)
:Support - Good solution. And can pair with the "search in subpages" if people can't find what they want in the central list. [[User:SuperGrey|'''<span style="color:#765CAE">Super</span><span style="color:#525252">Grey</span>''']] ([[User talk:SuperGrey|talk]]) 19:42, 15 September 2025 (UTC)
: Yes, had already started in on that approach (which I think of as the "Summary + Detail" approach); wanted to get a working mockup before saying anything, but if you want to see 1/8 of it, and not yet ready for general discussion, see [[User:Mathglot/sandbox RSP/1]]. PEIS is 43,580  – only 37% of current size of subpage 1. When I have all 8, or maybe just 4, I'll sew them together, and expose the mockup. Note that this initial attempt mostly borrows the current style of the fuller table, but it doesn't need to; it uses new classes at the [[Wikipedia:Reliable sources/Perennial sources/styles.css|stylesheet]] and can be easily changed, without touching the table. [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 23:00, 15 September 2025 (UTC)
::What I'm thinking of would look more like this:
::On RSP itself, just a simple list with links:
:::{{fake heading|Sources}}
:::* [[Ad Fontes Media]] – [[WP:ADFONTES|entry]]
:::* [[Agence France-Presse]] – [[WP:RSPAFP|entry]]
:::* [[Al Jazeera Media Network|Al Jazeera]] – [[WP:ALJAZEERA|entry]]
::and then on the alphabetical subpages, basically showing them what we have now.  This would be a navigation directory with the fewest possible number of templates, smallest amount of decoration, etc., on this page. It would not be a dumbed-down or oversimplified version of this page.
::{{anchor|23:11 15 Sept}}I believe it is ultimately not in Wikipedia's interest to give editors a classification without also putting the various explanations and notes in front of them as well.  Editors should not see "Al Jazeera – green is good" without also seeing "oh, and they tend to be a bit biased on ARBPIA CTOPs". [[User:WhatamIdoing|WhatamIdoing]] ([[User talk:WhatamIdoing|talk]]) 23:11, 15 September 2025 (UTC)
::I agree with Whatam: If we do this, we should not include the unexplained status on the centralized page. That would worsen issues with the three/four-color system's reductionism (see e.g. [[Wikipedia talk:Reliable sources/Perennial sources/Archive 11#MREL subpage]]) and people asking why a source is a certain status.{{pb}}(Though again, I do not think any splitting is necessary yet.) [[User:Aaron Liu|<span class="skin-invert" style="color:#0645ad">Aaron Liu</span>]] ([[User talk:Aaron Liu#top|talk]]) 00:13, 16 September 2025 (UTC)
====sidebar on PEIS capacity and saving PEIS bytes by manipulation of templates====
::: I don't understand why you don't think splitting is necessary, unless you have some kind of ace up your sleeve. We have already gone over the limit once recently, and only through edits by both of us (some of mine were sketchy and would be better off undone) have we managed to claw back minimal breathing room, to arrive at 2,091,215/2,097,152 bytes which amounts to 99.7% of available resources. This leaves us with only 5,937 free bytes (2,097,152-2,091,215), and no room for expansion. 
::: Take a middleweight row with respect to PEIS such as [[WP:BUZZFEEDNEWS|Buzzfeed News]]: this row is 2,794 raw wikicode bytes, and a PEIS of 10,214 (just the row, without a table header), so it is twice the size of our remaining capacity; another row like that one would break the table again.
::: There are still multiple approaches to consider, and I think one we should discuss is making every row into its own atomic subpage. At 2,794 bytes, the Buzzfeed News row already exceeds the size of plenty of small stubs, and with every RSP website on its own subpage, that opens up the possibility of direct search, similar to how the search box works at [[Help:YFA#Search for an existing article]] to look for articles or drafts. We could have a search box where the user types in the website name, and it searches only RSP websites we define (using the {{para|prefix}} param of [[mw:Extension:InputBox]]) and as they typed, they would start to get pop-up suggestions. Structured properly, the RSP subpage could be rendered in various ways, including as a table row as currently, although why you would want to see other, unrelated websites in a big table when you already found the one you want via search, I don't know. Browsability would still be covered by the simple flatlist idea, which could be another index into the subpage collection. With atomic subpages, other list subsets could be devised to access them in different ways as well. And of course, there would no longer be any limit on the number of them, which is only likely to increase. [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 01:43, 16 September 2025 (UTC)
:::: Sorry, I did not see that {{u|SuperGrey}} has suggested something pretty similar to this, iiuc what you meant. [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 01:51, 16 September 2025 (UTC)
::::I've mentioned pruning unused shortcuts multiple times, and if it comes to that merging the subpages back in (as Johnuniq said) should free up a ton of room. [[User:Aaron Liu|<span class="skin-invert" style="color:#0645ad">Aaron Liu</span>]] ([[User talk:Aaron Liu#top|talk]]) 02:51, 16 September 2025 (UTC)
:::::When you talk about "unused shortcuts", do you mean "blanking unpopular shortcuts"?  As in, the first shortcut in the list, [[WP:112UKRAINE]], has no incoming links unrelated to this page (not counting edit summaries, etc., but it also has an average of 1 page view/day, and the editor who created it appears to have been on a shortcut-creating spree rather than needing one for a discussion), so just remove that, and hope that will free up some breathing room?  
:::::How much room would we free up, if every single shortcut were removed?  If the answer is "less than 5%", then I think this approach will be too small to solve the problem.   [[User:WhatamIdoing|WhatamIdoing]] ([[User talk:WhatamIdoing|talk]]) 03:47, 16 September 2025 (UTC)
::::::Every shortcut takes up about 300 bytes, and there's 613 redirects to RSP. Assuming 200 of them are unused, we'd free up 60,000 bytes. But I'm also using a byte counting methodology that results in far lower numbers than the ones Mathglot has so it might be even more. [[User:Aaron Liu|<span class="skin-invert" style="color:#0645ad">Aaron Liu</span>]] ([[User talk:Aaron Liu#top|talk]]) 11:50, 16 September 2025 (UTC)
:::::::That's 2.8% of the limit.  It would take us from a panic-inducing 99.7% down to 96.9%, but I don't think that's a big enough change.  
:::::::Using [[Wikipedia talk:Reliable sources/Perennial sources#c-Mathglot-20250916014300-Aaron Liu-20250916001300|Mathglot's numbers]], a typical table entry is 10K.  Your suggested change would let us add just six (6) more average-sized sources to the table before we would be right back here with the same problem again.  [[WP:RSN]] has more than six RFCs listed at the moment.
:::::::What can we do that would give us room for a hundred new entries, or even 500? [[User:WhatamIdoing|WhatamIdoing]] ([[User talk:WhatamIdoing|talk]]) 17:26, 16 September 2025 (UTC)
:::::::: Placing one per page allows virtually limitless entries. In the early days of the (browsable) internet, [[Jerry and David's Guide to the World Wide Web]] was just a list, then a hierarchical list as it grew, and finally was renamed the Yahoo Directory. Finally, in 1995, Jerry and David hit upon the idea of providing a search mechanism instead of just a bigger and bigger list. I think we are approaching 1995 in this discussion. [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 00:32, 17 September 2025 (UTC) 
::::::::Firstly, if we [[#c-Aaron_Liu-20250916115300-Mathglot-20250916014300|the difference between mine and Mathglot's methodology]], we get 10214/3721*60000/10000=16.5 new BuzzFeed News–size sources, which... isn't much but does give us a lot more time to look at simplifying templates.{{pb}}Secondly, I believe unsplitting would also do so, besides the "links" method. With everything on one page we had 1531890/2097152 bytes, and that was before [[Wikipedia talk:Reliable sources/Perennial sources/Archive 11#Mostly done|I deployed drastic PEIS measures]] to what was then 1728538/2097152 bytes. (I'm taking these counts from the Internet Archive to avoid counting the current versions of transclusions instead.) When we get far nearer to the tipping point, by which time it will become evident whether simplification has been successful, we should make a discussion on which option we the RSP people prefer.{{pb}}Another thing we could drop on top of the links thing if it comes to that is a toolforge thing that renders one big table from the subpages but doesn't put it on the wiki. [[User:Aaron Liu|<span class="skin-invert" style="color:#0645ad">Aaron Liu</span>]] ([[User talk:Aaron Liu#top|talk]]) 04:02, 17 September 2025 (UTC)
::::::::: I think drastic measures isn't the way to go, as it is only an emergency stopgap doomed to future failure. I admit to engaging in the same type of thing, motivated by the emergency I guess, but I'm not really happy about it, and would prefer to undo them; one in particular may degrade accessibility in dark mode; that one needs to be reverted when a better solution is found. [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 06:14, 17 September 2025 (UTC)
::::::::::I currently don't see any problem with any of the measures we have right now; an example of something I would have a problem with is substing citations to invoke the modules directly.{{pb}}Another measure we could do is creating one "shortcut" template for of the statuses you could specify for the RSPSTATUS template. This would make use of the "invoke without any parameters" cache.{{pb}}{{tqb|one in particular may degrade accessibility in dark mode}} Which one is that? I feel a vague déja vu like I did something that caused this before but I don't remember what it is. [[User:Aaron Liu|<span class="skin-invert" style="color:#0645ad">Aaron Liu</span>]] ([[User talk:Aaron Liu#top|talk]]) 21:20, 17 September 2025 (UTC)
::::::::::: I had replaced a dozen {{t|cross}} templates in [[WP:RSP]] with <code><nowiki>[[File:X mark.svg|20px]]</nowiki></code> ([[File:X mark.svg|20px]]) saving 868 PEIS bytes. (And no, I don't know why that results in a fractional average.) I just did a test with [[Wikipedia:Reliable sources/Perennial sources/2|*/2]], replacing 24 occs of {{tlx|WP:RSPSTATUS|gr}} with <code><nowiki>data-sort-value=0|[[File:Yes Check Circle.svg|20px|Generally reliable|link=Wikipedia:Reliable sources/Perennial sources#Generally reliable]]</nowiki></code> for a paltry PEIS savings of 6,792 (219,211-212,419). Admittedly, that savings would increase if you replaced all 80 occs of WP:RSPSTATUS (guessing 21k) and with the other 7 (smaller) files, maybe reaching 100-120k in total savings, and perhaps bringing RSP PEIS down to 1,972,370/2,097,152 bytes, or 94.0% of capacity. Worth it? I strongly think not on the face of it; and if you factor in the increase in difficulty of maintenance without WP:RSPSTATUS and the files all being more fragile and error-prone, I think that would be a very bad bargain.  [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 23:02, 20 September 2025 (UTC)
::::::::::::I would not subst the RSPSTATUS templates; these are things that should have centralized change possible. I meant creating separate RSPSTATUS/gr, RSPSTATUS/gun, etc. templates to make use of the PEIS cache, which only activates when you call a template without any parameters, so that's probably why your cross replacements saved so little. [[User:Aaron Liu|<span class="skin-invert" style="color:#0645ad">Aaron Liu</span>]] ([[User talk:Aaron Liu#top|talk]]) 16:13, 21 September 2025 (UTC)
::::::::::::: I wouldn't either, and I have pretty much abandoned the futile hunting around for crumbs which might save a few tenths of a percent here and there. It isn't worth the effort for the extremely modest gain, and I think all the fat has been squeezed out of the table by this point anyway (with the possible exception of Johnuniq's monolithic table, but that has maintainability or other issues, although it could buy us time). I think we need a ground-up rethink of the entire system, and at this point, I think that WaId's summary + explanation approach is the way to go, and offers limitless expansion. I am extending or branching that idea by looking at non-table solutions which offer the possibility to have more user-friendly landing pages such as [[Wikipedia:Reliable sources/Perennial sources/all/Ballotpedia|Ballotpedia]] and [[Wikipedia:Reliable sources/Perennial sources/all/BBC|BBC]] which are easier to read and expand, and am looking into this via [[Wikipedia:Reliable sources/Perennial sources/Index|this mock-up]]. [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 04:47, 22 September 2025 (UTC)
:::::::::::::: [[User:Aaron Liu|Aaron]], Well, I wasn't hunting, but by chance I was browsing [[2026 United States House of Representatives elections]] which has 688 citations, and I wondered how they dealt with it. Turns out they use [[Module:Cite]], which I had never heard of. Check out the first sentence under [[Module:Cite#Usage]]. The Perennial sources page has only 35 refs, so not sure how much savings would come out of it, but we are now at 99.77% capacity, so anything we picked up might be worth it. I'm focused more now on the links+landing pages scenario than on clawing back PEIS bytes, but I thought you would like to know. [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 06:10, 23 September 2025 (UTC)
::::{{od|::::::::::}} Yeah, that's what I meant with the {{tq|substing citations to invoke the modules directly}} above; the module is just what all the citation templates use under the hood for obvious PEIS reasons. I would prefer other measures over that, though it'd be our equivalent of extraordinary budgeting measures.
::::Speaking of, how about we merge all the RSP templates into one Lua module that generates table rows? Would also make the table VE-editable at last. crazy idea but hey I prefer this over substing citations. [[User:Aaron Liu|<span class="skin-invert" style="color:#0645ad">Aaron Liu</span>]] ([[User talk:Aaron Liu#top|talk]]) 15:39, 23 September 2025 (UTC)

{{hatnote|[[WP:THREAD|Threading]] note: the following comment is a reply to the comment of 01:43, 16 Sept. at the [[#sidebar on PEIS capacity and saving PEIS bytes by manipulation of templates|top of this sidebar]].}}
::::{{tqb|this row is 2,794 raw wikicode bytes, and a PEIS of 10,214}} Where's this number from? Is that the total size of the final (MW)HTML output? I'm fairly post-expand size only counts the size of expanded wikitext; counting the size of the output from [[Special:ExpandTemplates]], that should be 3,721 bytes for Buzzfeed News. [[User:Aaron Liu|<span class="skin-invert" style="color:#0645ad">Aaron Liu</span>]] ([[User talk:Aaron Liu#top|talk]]) 11:53, 16 September 2025 (UTC)
::::: No, it is only the PEIS. If you extract just the "Buzzfeed News" row from [[Wikipedia:Reliable sources/Perennial sources/2|table 2]], you will have 2,790 bytes of wikicode (2,786 chars, 2,529 printable). Take that and paste it into a sandbox by itself and Preview it; the PEIS for that page containing only the one row should show 10,214/2,097,152 bytes. There is another row called, "Buzzfeed" (contrast, "Buzzfeed News"); could that be the source of the discrepancy? [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 05:21, 17 September 2025 (UTC)
::::: I see how you got your figure (I get 3,743 bytes by counting up the result field in ExpandTemplates). I was using the PEIS value reported directly in the table in the Parser profiling data on the wikipedia page after pasting the row there and previewing it. If you also save the page (e.g., [[User:Mathglot/sandbox6|here]]) you can view it either in Preview mode, or in the [[WP:NewPP limit report|NewPP limit report]] in the page Html; both yield 10,216 bytes. [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 07:25, 17 September 2025 (UTC)
::::::Thanks; I was ignorant of how the transitive dependencies counted as well. Slightly fortunately, quite a bit of that number is invocations without any parameters that are cached, so adding a BuzzFeed-like entry to any existing page would only add 6,521 bytes. Still worrying, though. [[User:Aaron Liu|<span class="skin-invert" style="color:#0645ad">Aaron Liu</span>]] ([[User talk:Aaron Liu#top|talk]]) 18:28, 17 September 2025 (UTC)

Good news/bad news: if we get desperate, replacing [[WP:RSPSHORTCUT]] will save us quite a bit of PEIS room. I tested replacing all RSPSHORTCUTs in [[Wikipedia:Reliable sources/Perennial sources/2]] with non-template code, generating [[Wikipedia:Reliable sources/Perennial sources/2/sandbox]] in [[Special:Diff/1315647153/1315662004|this edit]], and PEIS went down from 215,537/2,097,152 to 108,543. The replacement code is [[Special:Diff/1315647153/1315662004|quite ugly]], and I don't think we can expect anyone editing that file to adhere to that pattern when adding new rows, but it would buy time for adding rows the old way, i.e. with the template shortcut. Does anyone think this changes anything in a major way, or that it could be a possible solution option in an Rfc? I don't; I just think it makes the file even more fragile and error-prone than ever, and I would strongly oppose it as even a medium-term solution. I think we can use it in case of dire emergency, so that if someone adds one row that tips the table over 100% PEIS and breaks it, we can replace a couple of [[WP:RSPSHORTCUT]]s with their ugly twin to save us just enough PEIS room so the whole table doesn't break. But I wanted to expose the idea, just so we could have something else in our toolkit in case we need to buy a little time while working on the long-term fix. Your thoughts? Adding {{ping|Aaron Liu|WhatamIdoing|SuperGrey|Gråbergs Gråa Sång}}. Thanks, [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 23:23, 7 October 2025 (UTC)
:Not a possible option, could be emergency measure, though still I'd prefer just removing underused shortcuts. Unfortunately I haven't much time lately so it would be nice if someone could do it. [[User:Aaron Liu|<span class="skin-invert" style="color:#0645ad">Aaron Liu</span>]] ([[User talk:Aaron Liu#top|talk]]) 00:25, 8 October 2025 (UTC)
:: Do we know which ones those are? [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 00:28, 8 October 2025 (UTC)
:::That's the hard part! I'm planning on writing a bot and am [https://github.com/aaronliu0130/kwbf somewhat close (?)] to fixing an old bot framework so I can code a bot to remove those shortcuts in glorious [[Kotlin (programming language)]]. Man I do it to myself. [[User:Aaron Liu|<span class="skin-invert" style="color:#0645ad">Aaron Liu</span>]] ([[User talk:Aaron Liu#top|talk]]) 00:35, 8 October 2025 (UTC)
:::As a manual determination, one can just go to the WhatLinksHere page for [[m:User:Aaron Liu/What redirects here.js|WhatRedirectsHere]], ignore the entries from transcluding/copying parts of RSN, and remove the ones that subjectively aren't used much. [[User:Aaron Liu|<span class="skin-invert" style="color:#0645ad">Aaron Liu</span>]] ([[User talk:Aaron Liu#top|talk]]) 00:37, 8 October 2025 (UTC)
:::: If the bot works as expected, what would be its intended use? As part of a proof-of-concept for the first bullet at {{slink||Approach summary}} (remove some templates) in order to demonstrate the usability or likely benefit of that approach in an Rfc, or as something you want to do now before we get to an Rfc, or something else? {{ec}} [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 00:49, 8 October 2025 (UTC)
:::::It's going to take time before we get to a more permanent solution, so we do this in the interim so new entries can still be added, and I kinda want to see where this'll get us. [[User:Aaron Liu|<span class="skin-invert" style="color:#0645ad">Aaron Liu</span>]] ([[User talk:Aaron Liu#top|talk]]) 01:26, 8 October 2025 (UTC)
:Another emergency thing we could do is remove {{tl|no redirect}} from RSPSHORTCUT. The negative implications should be obvious for this option. [[User:Aaron Liu|<span class="skin-invert" style="color:#0645ad">Aaron Liu</span>]] ([[User talk:Aaron Liu#top|talk]]) 00:43, 8 October 2025 (UTC)
:Seems like a minor cosmetic change, maybe a little less elegant, if it helps, do it. [[User:Gråbergs Gråa Sång|Gråbergs Gråa Sång]] ([[User talk:Gråbergs Gråa Sång|talk]]) 06:36, 8 October 2025 (UTC)

Well, we are (were) in a desperate situation. I've swapped chunk /2 and its sandbox to gain a little breathing room. This doesn't preclude us from using one of the other stopgaps suggested above, and if they are preferable, we can simply unswap the pages. Note: hitting the hard limit and what to do about it is also being discussed [[#Approach summary|here]], in the context of whether this means we have to start an rfc in a hurry or not. [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 18:19, 10 October 2025 (UTC) And [[#How should we word an rfc?|here]], about how to word an rfc. [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 18:49, 10 October 2025 (UTC)
: After the fact, I realized it would have been easier just to change the transclusion of chunk 2 in the main table to point to 2/sandbox instead, rather than do the round-robin move. Oh, well; next time, if we need to do it again. For the record: parsing and row-building based on content of the chunks should parse 2/sandbox, not 2 as things currently stand, or risk possibly getting hung up on the wikicode introduced to replace RSPLAST and reduce PEIS. [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 21:46, 10 October 2025 (UTC)

Forgot to mention that there is one more way of saving some PEIS capacity not previously mentioned I don't think. For the record, it involves spinning off the table onto its own page, thus reducing PEIS by the size of the expanded templates in the non-table portion of the current page. If you move the table to its own page with nothing else but the table (and a textual Intro), PEIS would drop by 77,698 bytes, and you could link to it from the main page with the instructions. That would buy you a small amount of time, but hardly seems worth it. [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 01:16, 11 October 2025 (UTC)

====arbitrary break====
{{hatnote|[[WP:THREAD|Threading]] note: the following comment is a reply to the comment of [[#23:11 15 Sept|23:11 15 September]] above.}}
::: {{u|WhatamIdoing}}, combining your list idea with {{u|SuperGrey}}'s search idea could yield something like [[Wikipedia:Reliable sources/Perennial sources/Index|this demo]]. Note that the demo only works for B-C-D sources for the moment. Also, the search function links small (one- and two-row) tables, but given that we have search, they don't need to be structured as a single table row anymore, so could be completely rewritten as sectioned pages, however best presents the data, and are not limited to columnar style anymore. The only reason they are one-row tables now, is because it was fast/easy to do that. [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 08:53, 21 September 2025 (UTC)
::::Looks neat! [[User:SuperGrey|'''<span style="color:#765CAE">Super</span><span style="color:#525252">Grey</span>''']] ([[User talk:SuperGrey|talk]]) 09:00, 21 September 2025 (UTC)
::::@[[User:Mathglot|Mathglot]], I like this.  I don't have a preference for whether you end up at a larger table (e.g., all entries start with "B–D") vs a single page.  
::::In terms of layout, sometimes people are looking for alternative names or website domain names.  Would you suggest the search box for that, duplicating entries, or expanding them to name+URL (which would require wider columns)? [[User:WhatamIdoing|WhatamIdoing]] ([[User talk:WhatamIdoing|talk]]) 16:45, 21 September 2025 (UTC)
::::: {{u|WhatamIdoing}}, sorry, thought I responded to this. For alternative source names, we could just add extra links to the page. Already done, in a few cases; see, e.g., any of the four [[WP:RSPDEMO#PQRST|'T'-sources]] currently in the demo; those all point to the same landing page (in this case, [[Wikipedia:Reliable sources/Perennial sources/all/Dotdash Meredith|Dotdash Meredith]]). Ditto 'Conservative Review' and 'Bloomberg profiles'. 
::::: For abbreviations or common short names, e.g., 'Cosmo' ⟶ 'Cosmopolitan', if their links would be adjacent on the Index page, or nearly, I don't think we need to add separate links for them (t.b.d., case by case, I would say). Otoh, to facilitate someone searching 'Cosmo' from the search box<!--(and neglecting to add a trailing asterisk because they view it as common usage, and not intended as a 'partial word' search, as e.g., 'Cosmop*' would be)-->, or 'Kos', we could add redirects; but regular Cirrus search is pretty good at finding strings anywhere on the page, preferring title words, so that a [https://en.wikipedia.org/wiki/Special:Search?search=Telegraph&prefix=Wikipedia%3AReliable+sources%2FPerennial+sources%2Fall%2F&ns4=1&fulltext=Search&fulltext=Search search for 'Telegraph'] turns up the [[Wikipedia:Reliable sources/Perennial sources/all/The Daily Telegraph|Daily Telegraph landing page]] first, followed by two other landing pages that happen to mention it, namely, BBC and CoinDesk. Adding a redirect bumps it up in importance, so that a Cosmo or Kos redirect would appear first, followed by landing pages containing those strings elsewhere on the page.
::::: For domain names, or indeed, any string on the landing page, the search box is always a possibility. I don't think we should add urls to the index page, for the reason you stated, and also because it would double or triple the size of the index, for an edge case easily handled by search. (And also, because it keeps the index page less of a departure from the current table approach, as far being nearly one-to-one wrt table row ⟶ landing page, so less of an adjustment for users if this scheme is adopted.) [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 20:40, 5 October 2025 (UTC)
:I like that demo and think that ditching the table and splitting to individual, searchable pages is definitely the way to go. [[User:Audiodude|audiodude]] ([[User talk:Audiodude|talk]]) 20:16, 10 October 2025 (UTC)

The problem would be fixed by copying each section (such as [[Wikipedia:Reliable sources/Perennial sources/1]]) to where it is needed on the main page, rather than transcluding it. Has that been rejected as too ugly? [[User:Johnuniq|Johnuniq]] ([[User talk:Johnuniq|talk]]) 02:27, 16 September 2025 (UTC)
:[[Wikipedia talk:Reliable sources/Perennial sources/Archive 10#Page size]] [[User:Aaron Liu|<span class="skin-invert" style="color:#0645ad">Aaron Liu</span>]] ([[User talk:Aaron Liu#top|talk]]) 02:53, 16 September 2025 (UTC)
::To be fair, I don't think those RFC participants knew this would break the PEIS limit (who can blame them). Of course though, the same accessibility concerns would still exist if you put everything back on the main RSP page. [[User:Endwise|Endwise]] ([[User talk:Endwise|talk]]) 13:14, 16 September 2025 (UTC)
: Johnuniq's solution would work, but would make the long table harder to edit. One could solve that problem (at a cost) by copying all the data to the page, but dividing it into tables, each in its own section, which would enable section editing of segments that are the same size as the numbered subpages are now. So the editing burden on editors would remain the same, and PEIS would be decrased, allowing for more growth. (Although eventually it would still hit a limit somewhere, likely before it is twice the size it is now.) However, there would be a cost: the utility of sortable columns would be much reduced, being limited to whichever one of the eight tables you are looking at. 
: The functionality of "show me all the sources of status=X together" could be regained however, using a workaround. The idea would be to tag every row to make it selectable, and create a new page per status, such as */Perennial_reliable, which would simply pick up all the reliable rows by [[WP:SELTRANS|selective transclusion]]. This method is doable, but would require maintenance every time some source changed from reliable to some other status or vice versa; how often does that happen? Does it happen more often than us bumping into the hard limit on PEIS now, with concomitant maintenance we are now doing, not to mention all the time talking about various solutions? 
: Another way, could be to extract the reliable rows and paste them into another file, e.g. [[Wikipedia:Reliable sources/Perennial sources/reliable]]. If we did one of these for each status, then we wouldn't need sortable columns, and could just link to the appropriate status table. The cost here, is multiple copies of the same data, although if it doesn't change too often, that is probably not too serious, plus the extraction is doable by regex <!--m/^\|-.*?\n\|.*?\n\|\s*{\{WP:RSPSTATUS\|gr\}\}(?s).*?\n(?=\|-)/-->so could be automated. Plus, the "reliable" table has a PEIS of only 353,306 bytes so it can grow for a very long time (and loads fast). [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 08:42, 21 September 2025 (UTC)
Selective transclusion incurs the PEIS cost of the entire page, not just the cost of the parts selected (unless you're using onlyinclude/includeonly/noinclude tags, but you'd need more than those to sort into 4 statuses). There's been talks to change it to the latter but nobody has done the coding to do so yet. [[User:Aaron Liu|<span class="skin-invert" style="color:#0645ad">Aaron Liu</span>]] ([[User talk:Aaron Liu#top|talk]]) 16:18, 21 September 2025 (UTC)

=== Raladic's table options ===

I have a different idea, with two options on elegance, though one will require us to install an extension, but it would be both elegant in that we can still keep the table, while reducing the issue of the PEIS, and as a bonus, cutting the entire thing in about half for the average browse to [[WP:RSP]], so perf would also improve.
The biggest reason of why our list is so big is because the "Summary" column, which is more or less free text (and plenty of it) and accounts for about 50-60% of the content. So, if we get rid of it for normal page loads, then we're probably good as it would give us a lot of room to breathe.
There are two options, they both share the same basis of doing a little bit of simple template magic using conditional wrapping based on whether we're on the subpage, or the root page. 
Here's the template I cobbled together: [[User:Raladic/templates/lazySummary]] (it can serve both scenarios, though if we go with option 1 it can be simplified as it doesn't need the extra scaffolding). The template assumes we have a structure of a root page, with subpages behind it like RSP has with the transcluded subpages.
And then there's two options:
;Option 1:
The template will simply show a traditional link that brings a user directly to the subpage of the entry for when they want to read the summary
:Benefits: Simple, requires just a very basic template that checks if it's being loaded on the subpages or the root page, head on over to my [[User:Raladic/sandbox]] for illustration purposes (and could strip a good chunk of the template, as most of it is for the lazy loading)
;Option 2:
The second option, which is a lot more elegant, but takes a tiny bit more effort is that we can dynamically lazy-load the summary on a click of a button. this is pretty easy using JS client-side script and invoking the [[:mw:API]] to fetch the subpage when a user clicks on "show summary". To make things extra spiffy, we could break down the current fracturing of the subpages into the literal alphanumeric space (aka have 26 ABC + 1 alphanumeric page), as it means the on-demand load would be able to load an even smaller page. The client can also cache the page while the user is on it, so if they want to see a few summaries, we only need to load the pages of the letter and can otherwise just grab it from the temporary cache in the browser.
I have a live demo over in my [[User:Raladic/sandbox]].
:Note - you will need to install [[User:Raladic/scripts/lazySummary.js]] into your [[user scripts]] (common.js) and then you can click on the "show summary (lazy load)" buttons and it will dynamically fetch the summaries from the sub-pages as needed).
:In order for this option to work for all users, we will need to turn my POC JS script into a proper extension published on MW so that en-wiki can install it and will take a few moments to get through the vetting process. That being said, it would allow the user not to have to leave the page and still get all the information if they want to read the summary.
Anyway, that's my thoughts and ideas on what I've been cobbling together as a proof of concept. Let me know what you think. Given that the two options are not mutually exclusive, we could start with option 1 and just have a static go to summary for now, while working on making option 2 solid. [[User:Raladic|Raladic]] ([[User talk:Raladic|talk]]) 09:55, 21 September 2025 (UTC)

:I have doubts on its [[WP:ACCESSIBILITY]]. See [[MOS:PRECOLLAPSE]]: {{Tq|Wikipedia articles should be accessible to readers using browsers and devices that have limited or no support for JavaScript or Cascading Style Sheets, which is referred to as "progressive enhancement" in web development.}} [[User:SuperGrey|'''<span style="color:#765CAE">Super</span><span style="color:#525252">Grey</span>''']] ([[User talk:SuperGrey|talk]]) 10:59, 21 September 2025 (UTC)
::No, it's not an accessibility issue as long as the selective element is clearly targetable by screen readers, and hasn't been for a long time.
::Also, the RSP are not a main space article. But I think it might also be time to seriously overhaul some of the language of that guidance. "Progressive enhancement", a 2003 term when the internet was full of blinking GIFs, is nowhere near where we are 22 years later.
::Every reasonably recent browser supports CSS and JavaScript, you can't browser the web without it. Wikipedia is little exception to that nowadays.
::The [[MOS:PRECOLLAPSE]] is literally citing a 2016 paper from WMF. In computer age, that is literally getting close to historic, in [[Moore's law]] terms we've since shrunk chip size two full times. So, we should probably overhaul some of those sections. [[User:Raladic|Raladic]] ([[User talk:Raladic|talk]]) 11:57, 21 September 2025 (UTC)
:{{anchor|16:21, 21 Sept}}See [[#c-Mathglot-20250915230000-WhatamIdoing-20250915172400]]—the status is inseparable from the summary. People are annoyed enough already by editors relying on the status for blanket judgement ignoring the nuance expressed in the summary. We could do the index idea above + a script/toolforge webpage to transform the index of just links into a table, though. [[User:Aaron Liu|<span class="skin-invert" style="color:#0645ad">Aaron Liu</span>]] ([[User talk:Aaron Liu#top|talk]]) 16:21, 21 September 2025 (UTC)
::Maybe I’m misunderstanding what you’re saying, but my proposals don’t separate them - they are still together in the source subpages, optically exactly as they are right now as far as readers are concerned and pretty much what @[[User:Mathglot|Mathglot]] was suggesting (note that my manual nav links are also deep links by way of the template jumping to named anchors).
::And if we did go down the route of the lazy load even the main list could have the summary still. We could even trigger the lazy loading automatically when a user jumps to an entry and it becomes part of the visible frame in their browser window instead of being click based. [[User:Raladic|Raladic]] ([[User talk:Raladic|talk]]) 18:16, 21 September 2025 (UTC)
:::Ah you’re referencing your reply to that sub thread that you’re concerned if people don’t see the summary immediately but have the rest that it causes issues - fair, though I think solving that via Option 2 then makes it very elegant if instead of being manual click based, we make it automatic nav-based, which is very easy to do as it’s basically what happens for images already as they get loaded lazy after the page is loaded, but without clicks required, the user just needs to scroll to an image and it will be there by way of background loading. [[User:Raladic|Raladic]] ([[User talk:Raladic|talk]]) 18:25, 21 September 2025 (UTC)
::::We can't expect every viewer of RSP to install a userscript; the display under default settings has to be somewhat good enough. In regards to writing an Extension, check out [[Phab:T355150]] for an idea of the deployment process. [[User:Aaron Liu|<span class="skin-invert" style="color:#0645ad">Aaron Liu</span>]] ([[User talk:Aaron Liu#top|talk]]) 18:44, 21 September 2025 (UTC)
: Raladic said,
:: {{talk quote|we can still keep the table, while reducing the issue of the PEIS...}}
: Before we get into your options 1 and 2, I much prefer WaId's list of links idea. Can you please explain what advantage there is to keeping the table, other than that's the way it's always been done? I see no advantage to it, and it is the source of the problems that this entire discussion is trying to solve. WaId's solution solves it forever, with room for near-infinite expansion. I don't see why we should tie ourselves into expensive, lengthy, complicated knots, just to keep the one-giant-table layout. [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 19:11, 21 September 2025 (UTC)
::Well for one it’s the software engineering principle of [[Useability]].
::The current table, while not small is extremely easy to use by way of load page, hit ctrl+f and search and have your answer in a single navigate (unless it’s not listed, then you gotta go do the archive search).
::The list without status and the other details means we’re splitting this user flow into a multi-page process. It will now require users a minimum of two distinct page loads. [[Customer satisfaction|CSAT]] will go down and users tend to give up when things are frustrating.
::So  I think just a list and link to entries is really no better than just having nothing and a search page that is well scoped to be able to get the answer in just as many clicks.
::That being said if we go with option two, we also have the option of instead of lazy loading just summary we could in fact, lazy loads entire section transclusions and append them to the page. This would basically just mean you have an infinite scroll list and whether we automatically just async load it, which is what wiki does for all images on Wikipedia, they’re all tagged for {{code|1=decode=async}}, which basically means the browser knows where the images are, but it won’t stop rendering the page, even if the images are not yet loaded and they just get loaded in the background. Now our case obviously because we want not just images but entire sections of text to load. We can replicate that behavior with a little bit of client side work since the mediawiki API query is what would do the parsing, meaning it doesn’t count towards the page PEIS because as far as the page is concerned, there is not a single page expansion, instead, as far as the page is concerned, it only needs to expand the page with hints for the fact that we are going to load something afterwards and tell us where it is, and the client side job takes care of when loading happens after the metadata for the page itself is loaded. This is also infinitely expandable because we can start with what we have right now of 10 sub pages, but we can break it down like I said into 26+1 alphanumeric pages, which would have the benefit for users as well that if they know the name of something they could just directly bounce to that letter page without having to go through redirect or knowing the range of the multi letters that it is right now, but also it still leaves the door open for the future. like say a block gets too big. We can break a block down into sub blocks just like dictionaries do sometimes too, where you have Aa - Am, An - Az subsection and because we would asynchronously load actual page fragments as needed, preloading all of them after the page is loaded or only do it when the viewfinder gets there that’s up to us, but it’s pretty easy from a purely technical standpoint. [[User:Raladic|Raladic]] ([[User talk:Raladic|talk]]) 19:55, 21 September 2025 (UTC)
:::Experienced Wikipedia editors usually hate [[lazy loading]] of text.  The first complaint is that it interferes with ⌘F text searching, because you have to wait for the page to load, and then scroll to the end/take an action that will trigger the lazy loading.   
:::But maybe you're talking about something a little bit different?  It sounds like you dislike this process:
:::* Go to RSP (which will load quicker than it does now).
:::* Find name of source/website in the list.
:::* Click the link to read that entry.
:::and want to suggest this process:
:::* Go to RSP.
:::* Find name of source/website in the list.
:::* Click "Show summary" button to read that entry.
:::I also wonder how your proposal would work when the editor is going straight to [[WP:RSPFACEBOOK]] instead of the list. [[User:WhatamIdoing|WhatamIdoing]] ([[User talk:WhatamIdoing|talk]]) 20:27, 21 September 2025 (UTC)
::::The term [[lazy loading]] is a bit overloaded these days, but there is two principal uses:
::::* Traditional lazy loading - load something on demand only at the point it is needed 
::::** My POC right now falls into this with having a button to show summary only when a user wants to see it, 
::::** but as I mentioned, it could also be changed to auto-pull them based on viewport (where the browser is going)
::::* Deferred loading, or sometimes called async loading or [[lazy initialization]] also kind of falls into this - here we are not not loading something, but we're not doing it all at once.
::::** [[HTML5]], which was "finalized" around 2014 (turning into recommended status, aka telling browsers to start implementing) basically changed the way that the web is being used nowadays. One of the biggest aspect of it was that JavaScript morphed from being something to make blinky things appear, to now being the base bone of modern website interaction and various frameworks such as [[React]], [[Angular]] have taken it to new levels. 
::::** One of those aspects was that browsers were empowered to load things as needed and tell server what and when they need it by way of the introduction of {{code|async}} properties throughout the framework. 
::::** One of those pieces led to browsers natively doing this for images since images are stored somewhere and just referenced through the {{code|img}} tag, which now natively has a {{code|decoding}} property in modern browsers (for the past 5-10-ish years or so, see the link following for the full compat table, most browsers built it between 2016-2020 as part of the adoption of HTML5, which can be controlled using the [https://developer.mozilla.org/en-US/docs/Web/API/HTMLImageElement/decoding HTMLImageElement property] set to either load all images synchronously (aka alongside the page DOM), hybrid (browser decides what to load when), or fully asynchronously (browser will basically finish loading and rendering page to the user and the images get loaded in the background threads and will appear when they're ready
::::*** This is the behavior on en-wiki for images, which are set to {{code|1=decode=async}}. Now for images this is native functionality in the browser because without it, most webpages nowadays would make people thing we're back in the early 2000's of modems and early broadband.
::::** For text elements, there is no native browser tag for this, since they are not typically referenced by a URL, but just simply placed inline a span/div/table... But that isn't to say that it's not easily doable through a bit of client handling code, which just needs to know where to fetch something from and will then do it asynchronously using the async stack.
::::So, while I didn't initially go down the full-deferred route, all it would take is a few changes to my script to instead of waiting for a user clicking the link, to just load it asynchronously in the background when the DOM is ready and then just fill it in. Whether we keep it limited to just defer loading the summaries, or whether we'd defer load the entire sections, either are totally doable. Personally, I think keeping the sections loaded, but deferring the load of the summaries gives the benefit of users being able to load the page (a lot faster than today since it will be about half the size), and we just kick off the loading of the summaries in the background to happen as soon as the page is rendered. Since users mostly come here hitting CTRL+F looking for the title of a publication, this info would already be available, and chances are that by the time they hit enter, the summary is loaded in as well.
::::We can do this by means of an extension, or we could even log a ticket and see if it should be a new native feature of the [[:MediaWiki]] stack (as it could potentially be used for other actual uses beyond this backend use here for project space).
::::Hope this helps explain. Also just to be clear, I'm not saying we must do it. But I do think it could solve the issue elegantly and means we are not strictly limited by the current native server-side expansion. At the end of the day, we are using bots and other tools for all sorts of tasks that would not be possible by the native stack. This is no different. Basically, RSP has reached a point where the native tools alone currently just might not cut it, so since we're having this discussion here on addressing it, I think it is worthwhile to consider more technically "advanced" techniques like this. [[User:Raladic|Raladic]] ([[User talk:Raladic|talk]]) 23:16, 21 September 2025 (UTC)
:::::Leaving all the rest aside, "technically advanced techniques" sound like a way for this page to fail the [[wikt:en:bus_test|bus test]] someday. [[User:WhatamIdoing|WhatamIdoing]] ([[User talk:WhatamIdoing|talk]]) 23:38, 21 September 2025 (UTC)
::::::Well I put "advanced" in parenthesis, because it really isn't (if you check out the code, you'll see it's very little).
::::::If you haven't tried out the script to see it in action at my [[User:Raladic/sandbox]], here are two screenshots to help illustrate:
{{Gallery|width=120 | height=100 |noborder=yes |whitebg=no |align=center |mode=packed
|File:RSP demo table with summary text deferred to ad-hoc loading.png
|Summary text deferred to ad-hoc loading by clicking on a "show summary" button
|File:RSP demo table with summary text deferred to ad-hoc loading with one summary loaded.png
|First summary loaded after the click}}
{{clear}}
::::::Note I didn't hide the "show summary" button link in the second screenshot, but obviously there's many different options including hiding it.[[User:Raladic|Raladic]] ([[User talk:Raladic|talk]]) 23:45, 21 September 2025 (UTC)
:::::::Displaying either summary or status without the other is still a no-go for me. I mentioned that we could have a scripted way of transforming an index of links into a full table. [[User:Aaron Liu|<span class="skin-invert" style="color:#0645ad">Aaron Liu</span>]] ([[User talk:Aaron Liu#top|talk]]) 04:24, 22 September 2025 (UTC)
:::::::: By scripted transform of links and index, I presume you are referring to your comment of {{slink||16:21, 21 Sept}} and mean programmatically  producing the live table we have now given some input links? I don't see how this would be possible, as the summary is the largest section in each row, and is hand-drafted. [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 05:00, 22 September 2025 (UTC)
:::::::::Every link goes to a subpage with the summary text placed in a standardized location, no? [[User:Aaron Liu|<span class="skin-invert" style="color:#0645ad">Aaron Liu</span>]] ([[User talk:Aaron Liu#top|talk]]) 13:16, 22 September 2025 (UTC)
::::::::As I mentioned above - doing on demand loading like my demo is not what we have to do. It’s just the easiest to demonstrate the “how” it works.
::::::::We can automatically load all of it as soon as the page is rendered (as far as the browser is concerned). As far as users are concerned it likely makes little difference in user experience as the asynchronous load-ins will happen faster than they can get to the entry they need. We can also optimize it to prioritize loading a section earlier than another. [[User:Raladic|Raladic]] ([[User talk:Raladic|talk]]) 05:45, 22 September 2025 (UTC)
:::::::::I still wouldn't count on all users to install a script, and an extension would take a very long time to deploy. [[User:Aaron Liu|<span class="skin-invert" style="color:#0645ad">Aaron Liu</span>]] ([[User talk:Aaron Liu#top|talk]]) 13:15, 22 September 2025 (UTC)
::::::::I'm with Aaron:  If you can see red/yellow/green/gray color coding, you ''must'' be able to see the text that says "Oh, BTW, the general category doesn't apply to the exact scenario you're looking at".   [[User:WhatamIdoing|WhatamIdoing]] ([[User talk:WhatamIdoing|talk]]) 15:51, 22 September 2025 (UTC)
::: Regarding "{{xt|hit ctrl+f and search and have your answer in a single navigate}}" – we might be getting into the weeds of what constitutes "a single operation", but finding a link on WaId's link page and clicking it seems like one operation to me. But regardless of how many events or operations it is, seeing link+clicking link (and typing nothing) is faster imho than 1) hitting Ctrl+F, 2) typing a search term (five key clicks? ten? more?), and 3) spying the highlighted term on the page, and 4) clicking it. That is, if it is the right one. Is that your main supporting pillar for this scheme? Because I think this "single navigate" argument is a weak one. Unless you are talking about number of page loads rather than events or operations, but I think we are way past the point where we have to worry about server load based on a clicked link. [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 05:43, 22 September 2025 (UTC)
::::Whether you manually scroll down the list of the several hundred sources to find the one you’re looking for, or you search for it using ctrl+f, it takes you a few seconds (unless you followed a direct entry shortcut.
::::Note that scanning visually gets a lot harder when it’s just a dense list of single line links, our brain gets overwhelmed past [[Working_memory#Capacity|7 items, plus minus 2]]..
::::Scanning the current table manually doesn’t typically have that issue because one page will typically give you 3-4 entries at a time since they are long sections (due to the summary and links pieces).
::::But to your question, no, I was talking that currently if I need to check if a source is reliable I know to go to [[WP:RSP]] and I’ll have the answer without leaving the page in many cases if there’s an entry for it.
::::With your proposal, this changes to 2 page navigations. One for going to the list, and then another one clicking on it, waiting for that page to load and only then being able to see the info I needed.
::::That is, in addition to the how to find the entry, which still applies just as it does today, but will get harder because human cognitive function will become a bigger factor as I referenced above. [[User:Raladic|Raladic]] ([[User talk:Raladic|talk]]) 06:04, 22 September 2025 (UTC)
::::: I disagree with almost all of your assertions, some of which are based on incorrect assumptions, but I will leave that for another day. Perhaps someone else will chime in in the meanwhile with some fresh views. But I will follow your development with interest, to see what it yields. [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 06:34, 22 September 2025 (UTC)
::::::I based my assumption of the single line link list based on [[Wikipedia talk:Reliable sources/Perennial sources#c-WhatamIdoing-20250915231100-Mathglot-20250915230000|WAIDs example]].
::::::I see you also just posted your proposal below now, but that 3 column list doesn’t negate the cognitive brain limits, if anything it adds more elements.
::::::I do value your thoughts however, so I’d love to hear them another day :) [[User:Raladic|Raladic]] ([[User talk:Raladic|talk]]) 06:50, 22 September 2025 (UTC)
:::::A direct-entry shortcut like WP:RSPYOUTUBE should take you to the full list entry, not to the bare list. [[User:WhatamIdoing|WhatamIdoing]] ([[User talk:WhatamIdoing|talk]]) 15:52, 22 September 2025 (UTC)

: {{u|Raladic}}, coming back to this, I can see how your options are a way to reduce initial page load time, but I don't get the part about PEIS improvement. Taking option 1 first, the summary field consists of text and usually some wikilinks, and rarely has any templates at all. For example, I searched the summary field in all 45 rows of [[Wikipedia:Reliable sources/Perennial sources/1]], and not one had a template in it. (The first one I saw was at iNaturalist in [[WP:Reliable sources/Perennial sources/4]], but I might have missed some.) Anyway, templates appear to be rare in the summary field, so whether you move summaries off to another page that loads later, or on demand, that should not affect PEIS of the initial table much. As a test, I checked PEIS of [[Wikipedia:Reliable sources/Perennial sources/1]] and got 117,695/2,097,152 bytes. Then I replaced the summary field in all 45 rows with 'Summary', and now PEIS was 110,301/2,097,152 bytes, for a savings of about 7,400. If subpage 1 is typical, we can multiply by 8 to project savings to the whole table of 59,200 bytes, which is about 3% of PEIS capacity. That doesn't seem like much savings. Or am I missing something? [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 09:09, 5 October 2025 (UTC)
::it depends on how far we’d go with the idea, we can do the asynchronous loading for just the summary portion. Though theoretically the entire text content itself should be part of the bytes contributing to the PEIS since they are being expanded with the transclusion of the page itself.
::But we could also do it for the entire rows (or ranges of rows, like say we actually asynchronous loaded the subpages like /A, /B and so on. In which case, it would outsource the entire template expansion for each row/letter to be done by the server call.
::So that means the initial page load of /RSP would be very light PEIS wise. [[User:Raladic|Raladic]] ([[User talk:Raladic|talk]]) 18:29, 5 October 2025 (UTC)
::: {{u|Raladic}}, I get the gist of it, thanks for the explanation; the details escape me somewhat, but that's okay. Part of the reason for these questions, is that I have been trying to compile a very brief summary at {{slink||Approach summary}} of all of the PEIS-reduction approaches we have all come up with, so that eventually it would be possible to describe the approaches as multiple options to choose from as part of an Rfc question. Unfortunately, I don't trust my understanding of your approach sufficiently to be confident about being able to encapsulate your suggested approach in a couple of sentences. Could you please have a look at {{slink||Approach summary}}, and add something there describing the core of your approach? Thanks, [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 18:57, 5 October 2025 (UTC)
:Regarding Option 2, is there a way to get similar "lazy loading" behavior with existing extensions? [[User:Audiodude|audiodude]] ([[User talk:Audiodude|talk]]) 20:19, 10 October 2025 (UTC)
:: None that I know of, and in any case, this approach appears to be moribund at the moment. See {{slink||Approach summary}}. [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 20:56, 10 October 2025 (UTC)

=== Mg's central list plus multiple landing pages ===
{{Courtesy link|Wikipedia:Reliable sources/Perennial sources/Index}}
{{hatnote|Further information: [[Wikipedia:Reliable sources/Perennial sources/all/Ballotpedia|*/Ballotpedia]], [[Wikipedia:Reliable sources/Perennial sources/all/BBC|*/BBC]]}}

This is an offshoot of {{u|WhatamIdoing}}'s [[#WaId's central list, and click to longer explanation|§&nbsp;Central list, and click to longer explanation]] above. Where WaId's approach involves a central list of links that point into a table (which could be the big one, or one of the eight smaller, numbered tables depending how it was set up), this approach copies her central list of links, but each link goes to its own landing page. That is, there will be one page for Ballotpedia, one page for BBC, and so on. I have mentioned this approach in passing before, but it has a tendency to get lost amidst other topics so I thought it was worth starting this section to centralize information about it here.

Benefits of this approach, is that it is a complete, forever-solution to the PEIS problem that sparked this discussion. But there are other important benefits: instead of the reliability assessment for one source being squeezed into a table row, with practical limitations on the text so that the rows don't get too <s>wide</s> <u>tall</u>, and liberal use of icons requiring a legend to keep some columns narrow, the landing page approach looks more like a page for an SPI investigation or Afd nomination, in the sense that you get full use of the page, and while there is an overall suggested format from one landing page to another (just as there is for one SPI or one Afd nom to another) you are free to use the page and expand it to whatever extent is necessary to cover the topic of reliability of that source. Another benefit is that if this approach (or something like it) gained consensus, there would not have to be a "big-bang" cutover when it was all done, trying to keep two systems in sync. A hybrid system is possible, where links on the index page could point into the table until a landing page was ready, and updated at the appropriate time. 

Downsides of this approach: no table means no browsing up and down the rows for "neighbors" of this row. That seems minor to me, though, as the fact that 'Blaze Media' and 'Blogger' are near each other alphabetically doesn't bring any benefit that I can see to an editor investigating reliability of a source. And for that, you have the link index anyway. Also, no sorting the table on status, like for example, all the reliable ones. But this is not a big deal, because it can be solved by building per-status tables (a single regex operation to extract all the "reliable" rows, say) and linking them, for example, [[Wikipedia:Reliable sources/Perennial sources/reliable]]. Another downside is that many are used to seeing this page as a table, and there may be resistance to replacing the table with individual landing pages.

The main index demo page is at [[Wikipedia:Reliable sources/Perennial sources/Index]], and currently works for sources starting with 'B', 'C', or 'D' (those originating in [[Wikipedia:Reliable sources/Perennial sources/2]]). That's it for now; more to say about this later. [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 09:06, 22 September 2025 (UTC)

:'''Support''' - I especially like how we have these detailed pages like [[Wikipedia:Reliable sources/Perennial sources/all/Ballotpedia|/Ballotpedia]]. It can store a lot of useful information. [[User:SuperGrey|'''<span style="color:#765CAE">Super</span><span style="color:#525252">Grey</span>''']] ([[User talk:SuperGrey|talk]]) 09:21, 22 September 2025 (UTC)
:'''Comment''' This looks quite usable. I can search or ctrl-f on the same page. [[User:Gråbergs Gråa Sång|Gråbergs Gråa Sång]] ([[User talk:Gråbergs Gråa Sång|talk]]) 13:41, 22 September 2025 (UTC)
:'''Support''' This approach addresses the size problems. I don't think it would take editors much time to adjust. I'm assuming all subentries (for example, the table's '''''New York Post''''' row includes '''''NY Post''''', '''''The Evening Post''''', '''''Page Six''''', and '''''Decider''''') will have individual entries in the list, which makes it easier to locate them than the table where you have to use ctrl-F rather than look alphabetically for those entries. If it gains consensus, during the transition, I suggest an informational banner on the table to caution editors that the table is being phased out so they don't get in the habit of going directly to the table and bypassing the index. [[User:Schazjmd|<span style="color:#066293;">'''Schazjmd'''</span>]]&nbsp;[[User talk:Schazjmd|<span style="color:#738276;">''(talk)''</span>]] 14:03, 22 September 2025 (UTC)
:: {{u|Schazjmd}}, my assumption is like yours regarding '''''NY Post''''' and the other related pages; they should be individual landing pages. There are a couple of edge cases where I wasn't quite sure what to do:
::* clearly related entities where the terms match on the left, such as the two separate entries on the Index page for 'BuzzFeed' and 'BuzzFeed News'. I ended up linking both of these index entries to a single landing page at [[Wikipedia:Reliable sources/Perennial sources/all/BuzzFeed|*/BuzzFeed]]. But now I am not so sure; based on {{u|WhatamIdoing}}'s comment below about having a See&nbsp;also section, I now believe that these ought to be two separate landing pages, interlinked via See&nbsp;also. What do you think?
::* same source, different topics rated differently: at [[WP:TELEGRAPH]] in the live table, the ''The Daily Telegraph (UK)'' gets two rows, because there were discussions sufficient to rate them as 'no consensus' with respect to transgender topics, and 'generally reliable' for everything else. It seems to me that we should have one landing page per source; now that these pages are not straitjacketed into a table format that requires a single status/background color, the landing page (currently unconverted at [[Wikipedia:Reliable sources/Perennial sources/all/The Daily Telegraph|*/The Daily Telegraph]]) has two table rows, with the assumption that when converted to a landing page, it will contain all of the information in both table rows, arranged in whatever format makes the most sense. I think the guiding principle here is: one source, one landing page. 
::* same source, different time periods: see the three rows about CNET in the main table starting with the one labeled 'CNET (pre-October 2020)' in column one (go to [[WP:CNET]], and scroll up a bit). These are all one source, and like the ''Telegraph'' should all be on one page. The unconverted landing page at [[Wikipedia:Reliable sources/Perennial sources/all/CNET|*/CNET]] has all three rows at the moment, with the assumption that they all belong on the same page when converted.
::* usurped source: this is an entirely theoretical issue, as I know of no entry in RSP like this. Let's suppose (counterfactual ahead) that after being sued by [[Sandy Hook]] victims for defamation at [[Infowars]], [[Alex Jones]] would have had to [[Infowars#Bankruptcy and proposed acquisition|turn over his conspiracy website]] to the [[SPLC]], which transformed Infowars into a conspiracy theory-debunking website under the same name. Now what do we do—one landing page, or two? Note that being theoretical, this is less worthy of a response, but it might set some expectations about what the guidance for having 'a single landing page' ought to say. Imho, these would be two entirely different sources pre- and post-takeover, that happened to have the same name (and url), and therefore would require two landing pages, maybe Infowars (Jones) and Infowars (SPLC) or something.
:: Your thoughts on any of these would be appreciated. [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 20:38, 22 September 2025 (UTC)
:::@[[User:Mathglot|Mathglot]], thanks for creating an example page to spark discussion. For "groups" of sources like the ''NY Post'' example, I don't think having a single landing page that encompasses all of the related discussions is a problem; I just think they need to be listed separately in the index. If I were looking for the status of ''Page Six'', I wouldn't know to look at the page for '''''New York Post''''' (as it's currently listed in the table). For BuzzFeed and BuzzFeed News, a see-also section would work.{{pb}}I agree that it's more useful for editors to have ''all'' guidance about a source on a single page rather than separate pages (such as CNET and the ''Telegraph''). That would also apply to the three rows of ''Forbes''. [[User:Schazjmd|<span style="color:#066293;">'''Schazjmd'''</span>]]&nbsp;[[User talk:Schazjmd|<span style="color:#738276;">''(talk)''</span>]] 20:50, 22 September 2025 (UTC)
:::: Taking this on board, then for the entry above it in the table, at [[WP:RSPNEWYORK]], we would have separate entries in the Index for ''New York'' (the magazine), and for ''Vulture'', ''The Cut'', ''Grub Street'', and ''Daily Intelligencer'', which are all part of the mag; but they would all link the ''New York'' landing page, where they would all be described, as appropriate; right? [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 21:39, 22 September 2025 (UTC)
:::::That's what I'm hoping for, yes. When I'm looking up a source at [[WP:RSP]], it's usually because I'm unfamiliar with it. Being unfamiliar with ''The Cut'' (for example), I'd have no idea that guidance for it falls under the ''New York'' umbrella. So having its own entry in the index, it would be easy for me to find and if it then takes me to the overall page for ''New York'', well, then I've learned even more than I was looking for which is a good thing but it also gets me to the guidance that I'm looking for. [[User:Schazjmd|<span style="color:#066293;">'''Schazjmd'''</span>]]&nbsp;[[User talk:Schazjmd|<span style="color:#738276;">''(talk)''</span>]] 21:41, 22 September 2025 (UTC)
:::::: Makes sense to me. I think as this discussion evolves, all these points could be digested and assembled into what might form the basis for a proposal to redo the RSP page. It's good to air all these issues, even the more minor ones, to see what there is support for, so if and when it comes to it, a proposal could be drafted that is coherent, and not too vague or fuzzy. [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 21:48, 22 September 2025 (UTC)
:::::I also like this idea. [[User:Aaron Liu|<span class="skin-invert" style="color:#0645ad">Aaron Liu</span>]] ([[User talk:Aaron Liu#top|talk]]) 22:30, 22 September 2025 (UTC)

:I like the concept, but I'm not wild about the first mockup.  Maybe an infobox instead of a nutshell?  And ==Summary== first? [[User:WhatamIdoing|WhatamIdoing]] ([[User talk:WhatamIdoing|talk]]) 15:55, 22 September 2025 (UTC)
::Also, some sort of ==See also== for related RSP entries. [[User:WhatamIdoing|WhatamIdoing]] ([[User talk:WhatamIdoing|talk]]) 15:55, 22 September 2025 (UTC)
::: Yes, absolutely. Am thinking about creating a [[Template:Edit|preload file]] to make creating new landing pages easier, and will add this to it. [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 18:57, 22 September 2025 (UTC) 
:: Re mock-up style, including nutshell v. infobox and layout order: all of these are great ideas. I think we are in the embryonic stage of this, and I strongly believe in demos/mock-ups to get something out there that people can look at, and improve. I had to come up with something to look at, and that was just a first attempt with no claim that is the best format, or even a good one. In that vein, would you be able to take one of the unconverted landing pages and do it your own way? The [[Wikipedia:Reliable sources/Perennial sources/all/Boing Boing|*/Boing Boing]] page is a fairly simple one, or just pick any one you want that hasn't been converted yet (i.e., lacks the document icon). Note that there is a [[Wikipedia:Reliable sources/Perennial sources/styles.css|stylesheet]] for these page, and you are welcome to use it in your mock-up if you wish, and also to alter any selector that starts {{kbd|.source-}} (or create new ones). Thanks, [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 19:10, 22 September 2025 (UTC)
:::I've put together a mockup at [[Wikipedia:Reliable sources/Perennial sources/all/Deutsche Welle]].   [[User:WhatamIdoing|WhatamIdoing]] ([[User talk:WhatamIdoing|talk]]) 21:24, 25 September 2025 (UTC)
:@[[User:Mathglot|Mathglot]] In this scenario, would it be possible/not-stupid to put the status-icon next to every item in the list? [[User:Gråbergs Gråa Sång|Gråbergs Gråa Sång]] ([[User talk:Gråbergs Gråa Sång|talk]]) 16:25, 22 September 2025 (UTC)
:: [[User:Gråbergs Gråa Sång|GGS]], my understanding of [[User:Aaron Liu|Aaron]]'s comment of {{slink||16:21, 21 Sept}} is that we can have the unadorned links, but not links with status, as that would separate status from the summary, which iiuc is verboten. <small>(subscribed; no ping needed)</small> [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 18:57, 22 September 2025 (UTC)
:::If we can't, we can't. [[User:Gråbergs Gråa Sång|Gråbergs Gråa Sång]] ([[User talk:Gråbergs Gråa Sång|talk]]) 19:01, 22 September 2025 (UTC)
: Another benefit is categorization. Standalone source evaluation pages can be categorized in [[WP:PROJCATS|administrative categories]], e.g.: "Perennial sources deemed reliable", "Perennial sources deemed unreliable", (ditto other statuses), "Perennial sources deemed reliable in 2021", etc., "All perennial sources". Rows in a table cannot be categorized separately as categories are applied to the page they appear on (or are transcluded into, barring [[WP:NOINCLUDE|inclusion control]]), and any category in a table row would be applied to the page as a whole, and thus be useless (except the table could be categorized as "Perennial sources", but it would be the only one in the category, so not useful. In addition, this could be made almost transparent by using [[WP:TCAT|categorization by template]]; for example, the [[WP:RSPSTATUS]] template could be updated to categorize the template in the correct status category, [[WP:RSPLAST]] in the correct year category, and the Infobox could categorize it in the top level  'perennial sources' category. [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 07:40, 29 September 2025 (UTC)

Didn't know where else to put this, as it is not germane to the already [[WP:RSP RFC 2025|ongoing Rfc]], so I am putting it here. Separating the links from the content in the List of subpages approach has another advantage I hadn't considered, as it allows for the possibility of custom indexes. For example, [[WP:MILHIST|WikiProject Military History]] might decide they wanted a quickref access point to all Perennial sources evaluations relevant to their project, and they might make a subpage on their WikiProject with a few dozen links to sources they refer to most often. I think that's fine and could be handy for a project. (A possible minor downside is missing new relevant links, but if they watchlisted the main index, that shouldn't be too problematic. An Alexbot-like process could probably even alert them to new relevant landing pages, just as it does for new relevant articles.)  For that matter, not only WikiProjects, but maybe some users might pin a few links to their user page for easy reference, and so on. What is less clear, is what happens if a project starts to create their own, local landing pages as well. Imho, that could lead to undesirable fragmentation with ensuing possible dilution of the central landing page repository, but now we are getting into a hazier future, and am content to let that evolve organically. Just wanted to raise this while I was thinking about it. [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 19:54, 25 October 2025 (UTC)
:I think this is unequivocally a good thing. [[User:Aaron Liu|<span class="skin-invert" style="color:#0645ad">Aaron Liu</span>]] ([[User talk:Aaron Liu#top|talk]]) 19:58, 25 October 2025 (UTC)
: Serendipity: after I wrote that, CMD commented at the [[WP:RSP RFC 2025#Survey|Rfc Survey]] (@14:58, 27 October) about a possible different Index style, so I created [[Wikipedia:Reliable sources/Perennial sources/Index/alt|this alternate index]] style to illustrate my reply. [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 08:33, 28 October 2025 (UTC)

=== Infobox design ===
:See examples: [[Wikipedia:Reliable sources/Perennial sources/all/Ballotpedia|Ballotpedia]], [[Wikipedia:Reliable sources/Perennial sources/all/BBC|BBC]], [[Wikipedia:Reliable sources/Perennial sources/all/California Globe|California Globe]], [[Wikipedia:Reliable sources/Perennial sources/all/China Daily|China Daily]], [[Wikipedia:Reliable sources/Perennial sources/all/Deutsche Welle|Deutsche Welle]].

I think that having an [[Wikipedia:Manual of Style/Infoboxes|infobox]] on individual RSP pages would be helpful.  So far, we've tried two different styles (in terms of content; aesthetics can be worked out later).  Here are my initial thoughts on comparing them (numbered for convenience):

# I think it's a good idea to provide some simple 'types', like 'news' or 'website'.  IMO the BBC should be considered a 'news' type.  We have very few entries in RSP for offline sources, so they're almost all 'websites'.
# I think the infobox is a good place for overall summative judgement (e.g., "[[WP:GUNREL]]").  I'd like to see more specific contents, especially for no consensus/other considerations apply.  
# I don't like having that summative judgment in a {{tl|nutshell}} because I worry that nobody will read anything else.  I don't think we should have a "nutshell" on these pages.
# I like having the [[WP:SHORTCUT]] at the top of the page.  I don't care whether it's in the infobox or elsewhere, as long as it's easy to spot.
# I don't like having spam-related tools shown for generally reliable sources.  For less/unreliable sources, I'm not sure whether these should be in the infobox or in a ==Uses in Wikipedia== section, but probably not both. 
# I like providing a basic factual description the source (e.g., "is a newspaper").  Excerpting from the lead, when we have an article, is convenient but maybe not as relevant to RSP's needs. 
# I like having other names/abbreviations in an infobox.
# I like having something on each page that indicates the purpose of the page (e.g., "____ is a source that has been repeatedly discussed").
# I like showing the dates of prior discussions and RFCs.  
# I also like showing the section titles for prior discussions, but they're not always useful/relevant/appropriately informative.
# I like reminding editors that the simple summary isn't the whole story, so they should go read the prior discussions.
# I'm doubtful that RFCs should be highlighted in the infobox.  The current consensus is more important than whether the RFC advertising mechanism was used at some point in time.
# On sources with multiple bits (e.g., BBC News itself vs their [[h2g2]] website), we might want separate entries with links between all the pages.  Or at least separate bits in the infobox.
# I wonder how much of the custom summary text could be standardized (e.g., "As with any news source, [[WP:RSOPINION]] applies to [[opinion pieces]].  As with any source, [[WP:RSBIAS]] applies to material that an editor believes to be biased.  As with any...").
# I like having infobox entries for "deprecated" and "blacklisted".  I'd also like to consider one for "biased", linking to [[WP:RSBIAS]].
# I would like to have as much of this conversion done via bot as possible.  Later entries can be hand-formatted, but the list is long, and help starting would be, well, helpful.

What do you think?  [[User:WhatamIdoing|WhatamIdoing]] ([[User talk:WhatamIdoing|talk]]) 01:02, 26 September 2025 (UTC)
:Haven't read all of these points yet, but from a quick lock:
:# Obviously, title-case everything before shipping to production
:# I like this design in general but I like Mathglot's page layout design better
:# Ideally the link searches should be presented as icons near the infobox... somewhere? At the bottom?
:# I liked RSP's three tiers of links: RfCs, RSNs, other. I think it should at least be represented somewhere, though maybe not the infobox.
: [[User:Aaron Liu|<span class="skin-invert" style="color:#0645ad">Aaron Liu</span>]] ([[User talk:Aaron Liu#top|talk]]) 01:42, 26 September 2025 (UTC)
:: By the 'link searches', do you mean the trio of links involving insource-search, external link search, and spam search, as produced by {{t|domain uses}} in the last column of each row of the giant RSP table? There are equivalent links produced by template {{t|domain uses long}} which is invoked by {{t|Infobox source reliability}}, and can be seen in any the four or five entries on the [[Wikipedia:Reliable sources/Perennial sources/Index|Index page]] tagged with 'ⓘ' (for '''i'''nfobox) , such as at [[Wikipedia:Reliable_sources/Perennial_sources/all/Ballotpedia|*/Ballotpedia]], where it can be seen in the three links at the bottom of the Infobox. Are those the link searches you meant? [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 05:53, 26 September 2025 (UTC)
:::Yes, the trio of links. No objection to using another template for it instead or even cutting down the amount of links, but I'm saying that I like how it's currently presented as icons. [[User:Aaron Liu|<span class="skin-invert" style="color:#0645ad">Aaron Liu</span>]] ([[User talk:Aaron Liu#top|talk]]) 03:27, 13 October 2025 (UTC)
:[[m:Meta:Cite Unseen|Cite Unseen]] has "news" rating ([[m:Meta:Cite_Unseen/sources/type#news]]). Could be useful if you want to create some "types." [[User:SuperGrey|'''<span style="color:#765CAE">Super</span><span style="color:#525252">Grey</span>''']] ([[User talk:SuperGrey|talk]]) 01:44, 26 September 2025 (UTC)
: I think it's great that you started this subsection, so we can hopefully solicit wider input. For starters, let me just say that I am agnostic going into it about exactly what it should look like, though like anybody, I have my opinions, but the main thing driving this for me is, get something out there for people to look at, and stimulate discussion. So this is great. (And numbering them makes it easier to respond.)
: Some process notes: I wouldn't say no to bot conversion, but if somebody else is going to be writing it, we don't want to abuse their willingness and effort too much by asking them to run it repetitively if our format keeps changing, so I'd like to see a reasonable level of participation and agreement first as to how it should look, before we ask for a bot. And more importantly, before we get to a bot, we would need a consensus to swap out a tabular format that many are familiar with and has existed for a long time. (Unless you meant a bot to generate landing pages for the demo, that we could then use to formulate a proposal to adopt a new format. But if you meant a bot just to create some of the mock-up pages to present in an Rfc, then sure. But tbh, if we are just doing the B's, C's, and D's for a demo or mock-up, then I don't think we'll need a bot; I just converted Change.org with a regex; admittedly, it was a monster, and probably wouldn't work on rows that look different, but it is doable. That was kind of a flyer to see if it would work at all, and since it did, a clever template would be more powerful and might be able to convert a lot of them. (The preload file is another method; that would require some manual intervention, but not much.) One thing we could do, is either divide up the list, or maybe better, just leave it open, and tag the entries with some kind of format tag that indicates which demo format it is; e.g., you could tag with ⓦ, I with Ⓜ, and so on for approaches by other contributors. Then if we finally do a proposal, responders could view a variety of options. 
: I'll respond individually to some of your points later, although I'll just mention that I am partial to the nutshell, but not wedded to it. I don't think it causes more bias, in the sense of causing a viewer to rely on the nutshell and look no further. At least, not any more than, say, a viewer seeing a no-entry symbol (meaning unreliable) in column two of the table, right next to the name. For example, how is that big, no-entry symbol in the [[WP:RSPDA|DeviantArt row]] in the table any less likely to cause that behavior (i.e., skipping the rest) to happen? We trust our readers with a nutshell on policy and guideline pages, partly to orient them or give them the highlights of what the P/G page is about, without thinking they will stop there, or that the rest of the page is unimportant. I don't think Perennial sources is all that different from a P&G page in that sense, in that we can orient them with a nutshell without fear, or assuming the worst about how a reader might use the nutshell. And if there *are* readers who won't go a single step further, well, they will probably act similarly whether you take them to a table row or a landing page; in the end, we can't make them be thoughtful and read the whole page. I like the slight orientation of a nutshell, and I think we can direct it at our most diligent readers, and not worry too much about the least diligent ones. It's kind of like the trailer on a film I am eager to see: seeing the two-minute trailer, doesn't mean I am done and don't need to see the film, it orients me, and helps me get the context of the film. Just my two cents, but I would of course follow whatever consensus turns out to be for the format. Future flash: I like most of your suggestions, and don't have strong opinions about them generally. More later; but in the meantime, I hope we get more feedback to your points. {{ec}} [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 03:06, 26 September 2025 (UTC)
:: From that (ec) I just got, looks like we already have, which is great!  I encourage everyone to pick one of the linked, B–C–D pages you see in the List section at [[Wikipedia:Reliable sources/Perennial sources/Index]], and build a landing page for it according to how you would like to see it done. Thanks, [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 03:11, 26 September 2025 (UTC)
::: {{anchor|monster regex}}For the record: I have mentioned various regexes: one is to extract rows from the table; that is a trivial match on the wikitable start row delimiter. The tough one is a replacement regex that parses a table row and converts it to a landing page, and it is not perfect, in that it cannot handle all the variability in row format in the table. (It also does not currently handle discussion links, which have to be added in in a second regex step.) It can handle *some* row variability, which makes it match more rows, but there is a point of diminishing returns in regex design where you get few additional rows for a lot of increased pattern complexity, so any such row conversion regex is a compromise between utility and complexity. The 'monster' I have previously alluded to converts quite a few rows, and is now on version 7. I am including it here just for the record, as I would hate to have to construct it all over again. Note that this is a [[PCRE]], not a Cirrus or Scribunto regex.
{{cot|bg=khaki|indent=6.4em|Row-conversion PCRE regex that handles many table rows}}
The match portion is this:
<pre>
(?s).*?id="([^"]+)"
\|\s*(?-s).*?\[\[([^]]+)\]\]\s*'?'?.*?{{WP:RSPSHORTCUT\|([^}]+)}}(?s)\s*.\|\s*{{WP:RSPSTATUS\|([gruncdb]{1,2})[^}]*}}(?s:.*?)
\|\s*{{WP:RSPLAST\|\s*([^|]+)(?:\|\s*stale\s*=\s*([^}]+))?}}(?s)..?\|\s*(.*?)
\|\s*{{WP:RSPUSES\s*\|\s*([^|}]+)[|}].*$
</pre>
Note that the match pattern has internal dotall switches ('dot matches newline') to turn it on and off inside the pattern, to properly deal with newlines in the table row wikicode, rather than the global pattern modifier for dotall.

The replace portion (v. 3) is this:
{{cot|indent=0.8em|bg=Cornsilk|replace string}}
<pre>
<templatestyles src="Wikipedia:Reliable sources/Perennial sources/styles.css" />
{{WP:Reliable sources/Perennial sources/Header}}
{{WP:RSPNutshell|\4|shortcut=}}
{{Infobox source reliability
 | type			= website
 | shortcut		= \3
 | status		= \4
 | last			= \5
 | domain1		= \8
 | rfc			= 
 | rfcdate		= 
}}

{{WP:RSPIntro}}
__TOC__

== Summary ==
\7

== Excerpt ==
{{hatnote|Excerpt from the lead of [[\1]]:}}
<div class="source-excerpt">
{{excerpt|\1|paragraphs=1|only=paragraphs|hat=no|references=no|inline=yes}}
</div>

== Discussions ==

=== Links ===
<div class="source-disc-list">
# first discussion
# second discussion
</div>

=== Recency ===
<span class="source-talk-last">{{WP:RSPLAST/sandbox|\5|table=no}}</span>

=== Rfcs ===
# yyyy   link

== Notes and references ==
{{reflist}}

== Original table row for comparison ==
<!-- intentional blank line here, without this comment -->
</pre>
{{cob}}
{{cob}}
::: Putting them together has created the majority of landing pages at [[WP:RSPDEMO#List]], augmented by a second, simple regex to add in the discussion links. Often, some manual post-processing is needed to fix up some field or other. [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 02:00, 29 September 2025 (UTC)
:::: {{u|WhatamIdoing}}, if you would like to add a few more landing pages to [[WP:RSP#List]] in the same style you used at [[Wikipedia:Reliable sources/Perennial sources/all/Deutsche Welle|*/''Deutsche Welle'']], all you have to do is redesign the 'replace' pattern to indicate what output you want, and I could run the same parsing regex with your replace pattern against a bunch of rows in the list, so there will be more examples to look at in your style. Lmk if you would like to try this. Bear in mind that a regex cannot create or look up content not already in the table row, such as organization logo and so on; you would have to add such content in manually after the fact. [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 02:12, 29 September 2025 (UTC)
::::Would it be better to do this with something like mwparserfromhell and a Python script, rather than regex? [[User:Audiodude|audiodude]] ([[User talk:Audiodude|talk]]) 20:20, 10 October 2025 (UTC)
::::: {{u|Audiodude}}, better than any single bare regex, yes, it would. But any script is going to use a regex, or more likely, a series of simpler regexes, and any such script would probably start by looking at the regexes we have so far. The table rows look similar enough at first glance, but there is a fair bit of variability, and no single monolithic regex will match every row. If you can do scripting and would like to volunteer, we could certainly use your help! [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 20:34, 10 October 2025 (UTC)
::::::That's why I mentioned mwparserfromhell, because it is a Python library that actually parses wikitext, as opposed to clawing at it with regex. [[User:Audiodude|audiodude]] ([[User talk:Audiodude|talk]]) 20:51, 10 October 2025 (UTC)
::::::But to your second point, I would love to help but I'm not sure what the requirements '''or''' the deliverable would be at this time. [[User:Audiodude|audiodude]] ([[User talk:Audiodude|talk]]) 20:52, 10 October 2025 (UTC)
:::::::Nobody is sure yet, but just knowing that someone with some technical skills is willing to help is already great news. [[User:WhatamIdoing|WhatamIdoing]] ([[User talk:WhatamIdoing|talk]]) 21:01, 10 October 2025 (UTC)
:::::::: Well, we kind of do know what they would be, or at least, a key component that would quickly lead to a full solution in several different approaches, namely [[#WaId's central list, and click to longer explanation|central list + longer explanation]], the [[#Row-builder module approach|Row-builder module approach]], and the [[#Mg's central list plus multiple landing pages|central list plus landing pages]] approach. 
:::::::: {{u|Audiodude}}, the deliverable would be a table row parser that takes one row from the table as input, and returns about a dozen key=value pairs, which are roughly the ones outlined by [[User:Aaron Liu|Aaron]] in the 22:17, 4 October post at {{slink||Row-builder module approach}} ([[Special:Diff/1315105739|diff]]). That would need to be specified more formally and precisely as far as exactly where to pull them from in the row (and we already have that info; it just needs to be specified). A second (easier) deliverable is to wrap that in a script that marches through the table and calls the parser for each row, and then does &lt;something>, which could be a module invocation that emits the table row without templates, or it could be creating a landing page in a predefined format (see [[Wikipedia:Reliable sources/Perennial sources/all/Ballotpedia|*/Ballotpedia]] for an example format) with those items. But this is the wrong subsection in which to talk about this, so we should probably continue this at {{slink||Row-builder module approach}}. [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 15:35, 11 October 2025 (UTC)
:::::::::There are over 200 comments in this ==Section==.  We should be creating new ==Sections==. [[User:WhatamIdoing|WhatamIdoing]] ([[User talk:WhatamIdoing|talk]]) 18:31, 11 October 2025 (UTC)

: Here are some responses, by the numbers, as promised:
:: 1. '''Types''' (news, website) – am fine with that; would this be a) a control string or something that we have to limit to 'just these N choices' and validate? Or is it b) just a string, and editors can enter any 'type' they want? Or is it c) a doc page thing, where they can enter anything, but the doc page has some recommended values?
:: 2. '''Overall summative judgement''' (SJ) – don't understand {{xt|like to see more specific contents}}; where, in the body? 
:: 3. '''Avoid SJ in nutshell''' – have to disagree, here. I think we should AGF and hope they will treat a nutshell here, the way they would at a policy page. In neither case can we force them to read the details, and in both cases we hope to maximize the likelihood they will do so. Imho, the nutshell sets some context for what lies ahead, and *increases* the likelihood that diligent editors will read on. As for the flakes, well, flakes gonna flake, and that isn't a good argument for removing the nutshell for the diligent users.
:: 5. '''Spam tools''' –
::* a) present for generally reliable (gr) sources: dropping them for gr sources seems reasonable. Then, keep them for gu, nc? What about deprecated (d)? I'll just mention that in the current, big-table format, spam tools are an indissoluble part of a trio of links produced by {{t|domain uses}}, i.e., the spam tool links never appear in the table by themselves, but always in the trio. In the new scheme, I followed that same pattern of a trio of links (using {[t|domain uses long}} with longer verbiage) but I see no particular reason we have to follow that old 'trio' pattern. When talking about where or whether to place them, would you like to propose a new way of handling these? Or, always suppress the trio for gr sources?
::* b) where to place: I don't feel strongly where they should appear. First, we should decide about a) (the trio) then get back to this point.
:: 6. '''Excerpt/Basic factual description''', e.g. 'newspaper': Agnostic about excerpting the lead; more typical is to just link it (but it already is, in the Infobox header. Am okay with dropping the excerpt, and understand the advantages of just having,  the only advantage being, it 
:: 7. '''Other names''' — this is currently param {{para|other}} in {{t|Infobox source reliability}}, and it is a free form string. I am just entering a comma-sep series, but we could put each name on a new line, or check to see if the names exist and link them if they do, and so on.
:: 8. '''Intro''' – that comes from template [[WP:RSPIntro]]; feel free to edit it. We could perhaps combine it with #6; then we would have: "FOO is a [newspaper|source] that has been repeatedly discussed", defaulting to 'source' if the {{para|type|newspaper}} was not given?
:: 11. '''Remind editors''' – how should we do this? Perhaps another boilerplate template?
:: 12. '''Don't highlight Rfcs''' – I think I disagree, here. An Rfc is not any old discussion, and not just an advertising mechanism that was used; it has some force of structure, formality, and a considered close. Whereas I don't know who is writing up the summary column in the table—are they even interpreting it right?—I do know, or at least I can find out, who wrote an Rfc closure, and I know there is a certain amount of seriousness involved, as they can be overturned, and even sanctioned if they are overturned a lot. So, I do want to know when someting is "just a discussion" vs. an Rfc, and I think that is an important enough distinction to mention an Rfc in the Infobox, but not random discussions. By the way, I think we should only mention one Rfc in the Infobox, regardless how many there were, and that should be the most recent one. The infobox currently has a link to the page section where other Rfcs can be found, if there was more than one Rfc, but I don't know if we even that, as normally only the most recent one is important, and in any case, the most recent one will mention others, if they are still relevant.
:: 13. '''Sources with multiple parts''' — we need to define what we really mean by multiple parts. If it is just a collection of related domains, Foo.com, Foo.org.uk, Foo.news.net, then we already handle that with one landing page, and multiple domains in the Infobox (and the body). If it is something more like multiple departments or divisions, as {{u|Schazjmd}} discussed, we might have ''Vulture'', ''The Cut'', ''Grub Street'', and ''Daily Intelligencer'' as individual links in the Index which would all link to the the New York magazine landing page; and ''The Evening Post'', ''Page Six'', and ''Decider'' all pointing to the ''NY Post'' page. There might be some cases where they are so different, they might need separate landing pages; we already have one case where a division is deemed reliable, where the main unit is not; I will have to go back and find that one again, but should we still handle that on one landing page, or two?
:: 14. '''standardize custom summary text''' – not entirely sure what you mean, but am I correct in assuming that this is unrelated to the possible use of a new approach, in that even if we kept the table somehow, the summary text could be customized there as well, in whatever way you are proposing. What are you proposing, exactly, and is it related solely to this new approach?
:: 15. '''infobox 'biased' entry''' – where would this information come from, if it is not currently in the table row somewhere? And again, is this about the new approach, or could this apply equally well to the table approach?
:: 16. '''bot conversion''' – covered in my previous comment. Before asking for a bot, we would need to know what we wanted. On the one hand, I don't think we are there yet; on the other hand, the sense of increasing urgency is palpable. Also, do you mean bot conversion just to build a demo, or only after some proposal gains consensus? If only the demo, I think we maybe have enough examples already, although I still do want to do the Daily Mail one, because it is an outlier in many ways, and would be a good example to add to the mix for that reason.
: Thanks [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 02:33, 28 September 2025 (UTC)
::# I'd like to suggest a few things, but to leave the ability for custom text.
::# About "more specific comments":  Imagine that instead of ''only'' saying "GUNREL", it ''also'' says "politically biased" or "uses AI" or whatever common reasons we have for rejecting a source.
::# I don't think we need to have a nutshell box at all, and I don't think we need to have a nutshell box that only repeats the same thing as you can find in the infobox two inches away.  If we're going to clutter up the page with a nutshell box, it would be nice if that use of screen real estate could contain more than one word's worth of information.
::# &nbsp;
::# I'd only include the tools for finding links to this source when we want editors to remove/replace that source.  (I liked having them in the body of the article, where there's more room to describe what they are.)
::# I like having a description of the source, and for non-notable sources, we'll need to have this option available in the design.
::# I think that "other names" can be freeform.  
::# I like [[Wikipedia:Reliable sources/Perennial sources/Intro]] as-is.
::# &nbsp;
::# &nbsp;
::# Imagine something like [[Wikipedia:Reliable sources/Perennial sources/Intro]] at the top of the list of links to the discussions, only saying something like "Consensus is determined in discussions.  This simple summary is provided for convenience.  If this summary doesn't reflect the discussions, please help out by updating the summary".
::# [[Wikipedia:Requests for comment]] says at the top that RFCs really are just discussions with an advertising mechanism.  They do not produce binding decisions (which would violate the [[WP:No binding decisions]] policy).
::# When sources have multiple parts (e.g., Vulture), then I don't care whether it's one or two pages.  If it's one, we need redirects.  If it's two, we need links between them.  Flip a coin, or tell me which is easiest to convert from the existing table.
::# About standardizing the custom text:  Right now, we have a lot of entries in which we say the same thing using different wording.  For example, there are a lot of sources that are biased.  We could standardize some of this by always using the same wording for each common concern.  This means writing "Editors are concerned that the publication lacks a reputation for fact-checking and accuracy" every time, instead of using different language each time.  This could be handled by a template (e.g., <code><nowiki>{{RSPconcerns|fact-checking|self-publish|bias|non-independent}}</nowiki></code>).  This idea could be implemented later, assuming we want to do it at all.
::# {{tl|Infobox source reliability}} has infobox parameters for <code>|deprecated= |blacklisted=</code> I think that adding a row for <code>|biased=</code> would also be a good idea.  I think these would have to be added manually.
::# I'm interested in a bot conversion later.  I agree that we have enough examples for discussion.
::[[User:WhatamIdoing|WhatamIdoing]] ([[User talk:WhatamIdoing|talk]]) 19:03, 29 September 2025 (UTC)
::: {{u|WhatamIdoing}}, I've been thinking more about this, and about drawing up an Rfc about the critical PEIS issue. I think that the latter is way more important than any Infobox question. Indeed, imho an Rfc should be solely about offering options to resolve the PEIS issue, only one of which would be the "Index page + individual landing pages" approach. Compared to that, all this discussion about whether to have an infobox and what should be in it, whether to have a nutshell, where the Summary should appear on a landing page, and so on—all of those are stylistic choices which pale in comparison to deciding if we want to keep the table with modularized rows, use a giant table, use lazy loading, switch to this approach, and so on. I see the current style of the [[WP:RSPDEMO]] landing pages as "just one way to do it", and any Rfc question should focus on which of several radically different approaches we should take for the future design of Perennial sources, and not try to decide the minutiae of style. Do you agree? If the landing pages approach gains consensus, then either a follow-up Rfc later, or even just plain discussion could resolve any stylistic choices involved, as we have started to do here already. What do you think? [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 21:05, 5 October 2025 (UTC)
::::I think that simplifying for the RFC is a good idea.  People need to be told that the current structure ''will'' break soon and ''must'' be replaced.  Then we solicit their opinions for the general replacement approach (e.g., something that will probably break in a couple of years, something that will never break again, etc.).  There can be a future RFC if we want to design an infobox, but there's no need for that now, because they might choose a different approach. [[User:WhatamIdoing|WhatamIdoing]] ([[User talk:WhatamIdoing|talk]]) 02:17, 6 October 2025 (UTC)
::::: Thanks. One more thing: I am using section {{slink||Approach summary}} as a prequel to help inform a probable forthcoming discussion about how to word an Rfc question. Can you have a look and make sure your approach is fairly characterized, or just rewrite is as needed? There will be more opportunities to do so, but this is just a first attempt to make a brief roll-call of what we've to to work with, as it were. Thanks, [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 02:32, 6 October 2025 (UTC)

=== Showcasing different approaches ===

Ideally, I'd like to see several approaches to compare. One thing that occurs to me, is that larger entries could be a good test bed for showcasing different approaches, to see how they handle some of the limitations imposed by a table row structure. The Daily Mail entry in the table (at [[WP:DAILYMAIL]]) is one of the longest I have seen. The row height takes up about 3/4 of the screen height on my 15-inch laptop. 

It has two shortcuts (in col. 2), a 'deprecated' icon, three Rfc icons, 54 previous discussions (which are relegated to an explanatory note, as the table-row format is ill-equipped to handle links to 54 discussions), a 226-word summary (which currently occupy 16 lines in my setup, and determine row height), and 11 domains with three links each in the last column, protected with a show/hide toggle to keep the row height from growing further. I plan to convert this one, but I think it's fine if we have multiple conversions of the same table row page linked from the [[Wikipedia:Reliable sources/Perennial sources/Index|Index page]] showcasing different approaches. It might even help interested users compare the same source being rendered in different ways. They should all be linked from the Index page, maybe with uniqueness suffixes or something, and could interlink each other via their See_also sections.

P.S. Regarding the summary text: I don't think ipso facto that 226 words is too much by any means, and especially not for this particular entry. Indeed, freed from the confines of a table row, the summary could be broken up into paragraphs, or even subsectioned if that were deemed helpful. [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 06:18, 26 September 2025 (UTC)

==== Approach summary ====

Recapping the critical issue facing the [[WP:Reliable sources/Perennial sources]] page: we have been over 99% of [[WP:PEIS]] capacity for some time (and occasionally [[#Reflist is broken?|over it]]), and a solution is urgently needed to prevent the page from breaking. Each time that threatens, it is [[#Yikes, four bytes left|patched up again]] with rubber bands and sticky tape. Here is a capsule summary of the approaches discussed so far as possible solutions to the PEIS problem:

* [[#sidebar on PEIS capacity and saving PEIS bytes by manipulation of templates|§&nbsp;remove some templates]] to reduce PEIS
** pros: first thing we tried; easy fix to reduce PEIS slightly
** cons: only a stopgap; everything that reasonably can be removed has been, and still at > 99% full; no room for growth; will likely not stop another failure soon
* [[#Row-builder module approach|§&nbsp;module-generated rows]]
** pros: should reduce PEIS considerably; would allow for growth of approx. 150 rows
** cons: module needs to be written to test the concept; at some point would face the same issue again, although not for a while (years?)
* [[#WaId's central list, and click to longer explanation|§&nbsp;central list, and click to longer explanation]]
** pros: permanent solution to PEIS issue; links page easier to find the source you are looking for
** cons: one extra click (on the links page) to get to the description of the source; 
* variant of above: [[#Mg's central list plus multiple landing pages|§&nbsp;central list with landing pages]] and mocked up [[WP:RSPDEMO|demo]] 
** pros: permanent solution to PEIS issue; more at [[WP:RSPDEMO#Q3]]
** cons: see [[WP:RSPDEMO#Q4]]
** mockup: see [[Wikipedia:Reliable sources/Perennial sources/Index]] (shortcut: [[WP:RSPINDEX]])
* <s>{{slink||Raladic's table options}}</s>
** <s>pros: ''t.b.d.''</s>
** <s>cons:</s>
* {{slink||One giant table approach}}
** pros: reduces PEIS from 99.7% to around 63%; room for growth of about <s>150</s> <s>600</s> <u>300+</u> sources (i.e., table rows)
** cons: table would be around 477kb with 497 rows currently, with concomitant maintainability and load issues; would hit the same threshold again after ~<s>150</s> <s>600</s> <u>300+</u> new rows were added, when the table will be around <s>715kb</s> <u>920kb</u>. <small><small>updated by [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) at 05:28, 14 October 2025 (UTC); and at 19:50, 16 October 2025 (UTC)</small></small> 

If I missed or unfairly summarized anything, please feel free to edit my comment ''in situ'' to fix it (just please add a note below or in the edit summary to leave some breadcrumbs). Thanks, [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 23:13, 30 September 2025 (UTC)
:I think this is accurate, but not the overview summary of the different approaches that I would provide in an RfC to laymen users. [[User:Aaron Liu|<span class="skin-invert" style="color:#0645ad">Aaron Liu</span>]] ([[User talk:Aaron Liu#top|talk]]) 01:19, 7 October 2025 (UTC)
:: Thanks for the feedback. You have expressed what I think is the trickiest issue we will face when trying to devise an Rfc question, namely, how to word it in order to make it as clear as possible to a general audience, while not oversimplifying. I don't have a good answer for that, but we'll get there.  I think when we get to that point, we should list the options (looks like five?) where each is at most a sentence or two; I think it would be fine if each option summary linked to a more detailed explanation further down. This is an inherently complex topic, and each option has its fine points; we should at least have details available for the more tecchie editors who may show up and want to give thoughtful consideration and would need a deeper dive in order to do so. I don't see how its possible to do justice to the various options with just a brief description for each.
:: {{u|Raladic}}, I assume you are still interested in having your lazy-load option(s) included in any future Rfc. Could you add a brief pros-and-cons description to the bullet point above for it? There will be an opportunity to link it to a more substantial description later. Thanks, [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 02:59, 7 October 2025 (UTC)
:I think we can reduce this down to three options:  
:# Try to maintain the current environment until it collapses, which could be soon.  
:# Build something similar-ish.  Collapse predicted in approximately 150 new entries, which might be three years from now.  <small>(Time estimate based on seeing that about 100 were added in the last two years.)</small>
:# Do something completely different, using subpages and getting essentially infinite room for expansion (thousands of new entries could be added).
:This is a manageable number of options, and non-technical editors should be able to express a preference for postponing change as long as possible vs a bigger change that fixes the problem permanently.   [[User:WhatamIdoing|WhatamIdoing]] ([[User talk:WhatamIdoing|talk]]) 02:51, 8 October 2025 (UTC)
::Thanks for the concise and very on-point summary. Can we head to the RSN page and propose them now? I feel like we have already analyzed a lot -- the approaches and their pros & cons -- that we can share with the RSN participants. [[User:SuperGrey|'''<span style="color:#765CAE">Super</span><span style="color:#525252">Grey</span>''']] ([[User talk:SuperGrey|talk]]) 20:27, 8 October 2025 (UTC)
:::Nothing will happen today, because we need to give the other participants in this discussion a chance to see this and share their thoughts about such a vague question.
:::Also, there's no need to have the RFC at RSN specifically. [[User:WhatamIdoing|WhatamIdoing]] ([[User talk:WhatamIdoing|talk]]) 21:53, 8 October 2025 (UTC)
::: Not only that, but it would be helpful to users participating in any future Rfc to understand what is involved in implementing the various approaches; i.e., what is the migration path, are bots or scripts required, how hard are they, and so on. Wherever it is held, [[WP:VPR]] and/or [[WP:VPT]] should be notified. [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 09:16, 10 October 2025 (UTC)
:::: I've struck pro's and cons of Raladic's approach above, as {{they|Raladic}} appears to be retired, and won't be available to support and explain that approach. At first blush, that seems to leave us with five approaches, but I don't know if the first one, i.e., removing some templates, is really a valid one anymore as we have pretty much removed everything we could, so I think we are down to four or maybe three choices, as enumerated by WaId above. That is a good number for an Rfc. [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 09:25, 10 October 2025 (UTC)
::::: P.S., slightly o/t for this subsection, but we are over 100% again, and I've added a template-based notice that alerts us to where we stand, at the [[#Addressing hard template limits|top of this section]]. [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 09:30, 10 October 2025 (UTC)
::::::Or two, since "it collapses" has already happened.
::::::@[[User:Mathglot|Mathglot]], unless you object in the next small-number-of-hours, I'll start an RFC today on the simple/vague question of kicking the can down the road a couple of years vs providing near-infinite room for growth.  We no longer have time to sort out the details. [[User:WhatamIdoing|WhatamIdoing]] ([[User talk:WhatamIdoing|talk]]) 17:43, 10 October 2025 (UTC)
::::::: [[User:WhatamIdoing|WhatamIdoing]], Well, I'd rather wait, as I don't think that being in a crisis situation is the best environment for choosing a good path in an Rfc. We can still buy some time using the "ugly" method I mentioned earlier to RSPSTATUS in subpage /2, and then request protection on all of the pages to stop any new entries from being added. (We are already in a situation where new entries effectively cannot be added, at least, not without breaking something somewhere else.) We can have a hatnote directing users to an "overflow" page were new entries can be added instead. Then we can calmly start an Rfc. That would be my preference. [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 17:55, 10 October 2025 (UTC)
:::::::: So, we are down to 98.31%, which gives us time to discuss how best to formulate an Rfc. [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 18:23, 10 October 2025 (UTC)
:::::::::Okay.  
:::::::::We have two main options with the RFC:  One is to ask for preferences on temporary vs permanent solutions, then sort out functional proposals for whichever is chosen and have another RFC.  The other is to develop all of the proposals first and propose them all at once in a single RFC. 
:::::::::I'm inclined to the first but will support whichever approach you and @[[User:Aaron Liu|Aaron Liu]] want to take, since you're the two that would have to make the functional proposals. [[User:WhatamIdoing|WhatamIdoing]] ([[User talk:WhatamIdoing|talk]]) 19:30, 10 October 2025 (UTC)
:::::::::: I have '''copied the comment above''' (@19:30) to {{slink||How should we word an rfc?}} and have responded there. [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 19:42, 10 October 2025 (UTC)
::I think this analysis summarizes the options quite well and is understandable for non-technical editors, assuming they accept our report that the page is at the PEIS limit, even if they don't inherently understand what that is. [[User:Audiodude|audiodude]] ([[User talk:Audiodude|talk]]) 21:03, 10 October 2025 (UTC)
:::I've sometimes needed to have a screenshot to show people what the PEIS limit means.  My most recent one ([[:File:Template limits PEIS post-expand include size screenshot.png]]) actually isn't that good.   [[User:WhatamIdoing|WhatamIdoing]] ([[User talk:WhatamIdoing|talk]]) 21:29, 10 October 2025 (UTC)
:::: [[WP:NewPP limit report]] has a writeup that includes it; no image, but a wikicode facsimile, which may be just as good?  Otherwise, an image could be added there. Another approach might be the [[WP:Graphics Lab]]; the folks there do a great job, and sometimes an illustration can be clearer and more informative than a screenshot, or can start with a screenshot and then have explanatory callouts and labels added, identifying the important bits. If you do try the GL, please request 'svg with translatable labels'. This allows a single image to be generated, with labels stored as text not pixels in such a way that any of us can translate the labels without any image design knowledge using a toolforge image label translate tool, and the same svg can be used by other Wikipedias without starting over again with a new image. [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 22:04, 10 October 2025 (UTC)
:::::I don't see a wikicode facsimile at that link.  It looks like a long XML comment instead. [[User:WhatamIdoing|WhatamIdoing]] ([[User talk:WhatamIdoing|talk]]) 00:21, 11 October 2025 (UTC)
:::::: Yah, not even wikicode, just plain text, but doesn't really matter what it is, the point was whether that section is useful or not as an illustration instead of the image you didn't like. There's only one line about PEIS there and tons of irrlevant stuff about other things, so maybe not so much. Perhaps an extract of it showing just a few lines of text near the PEIS line near the top might be better. [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 01:04, 11 October 2025 (UTC)

=== Yikes, four bytes left ===

I just checked [[WP:PEIS|PEIS]] on a browser that doesn't have a history of my loading WP:RSP, and got this from [[WP:NewPP limit report|NewPP limit report]]:
<pre style="width:30em; margin-left:1.6em">
Post‐expand include size: 2097148/2097152 bytes
CPU time usage: 6.611 seconds
Real time usage: 7.202 seconds
</pre>
We used to have ~ 4,500 bytes or so; don't know what happened. Can someone double-check me on this? {{ping|Aaron Liu|WhatamIdoing}} Thanks, [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 23:31, 27 September 2025 (UTC)
:{{anchor|23:59, 27 Sept}}Maybe some entries were added? I've manually removed some unused shortcuts from /2 for now. I still want to see how turning table-row generation into a module goes. [[User:Aaron Liu|<span class="skin-invert" style="color:#0645ad">Aaron Liu</span>]] ([[User talk:Aaron Liu#top|talk]]) 23:59, 27 September 2025 (UTC)
::If we're looking at an emergency situation, should we just list the subpages, simply as a temporary expedient?
::That is, shall we replace the single table with something like:
::---
::{{info|Sorry, the table got too big to display everything on one page.  [[Wikipedia talk:Reliable sources/Perennial sources|We're working on it]].  In the meantime, you can go directly to the alphabetical subpages.}}
::* [[WP:Reliable sources/Perennial sources/1]] – Spans 1,A 
::* [[WP:Reliable sources/Perennial sources/2]] – Spans B,C,D
::* [[WP:Reliable sources/Perennial sources/3]] – Spans E,F,G
::* [[WP:Reliable sources/Perennial sources/4]] – Spans H,I,J,K,L
::* [[WP:Reliable sources/Perennial sources/5]] – Spans M,N
::* [[WP:Reliable sources/Perennial sources/6]] – Spans O,P,Q,R
::* [[WP:Reliable sources/Perennial sources/7]] – Spans S,T 
::* [[WP:Reliable sources/Perennial sources/8]] – Spans U,V,W,X,Y,Z
::---
::and then get busy splitting things up and repointing the shortcuts? [[User:WhatamIdoing|WhatamIdoing]] ([[User talk:WhatamIdoing|talk]]) 00:17, 28 September 2025 (UTC)
:: Or maybe some existing template used in every row had 15 bytes added to it? Anyway, we are down to 2088852/2097152 bytes, or 99.6% usage, with 8,300 bytes left. Thanks for walking us back from the cliff. {{ec}} [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 00:24, 28 September 2025 (UTC)
:: A module would doubtless be a big savings, probably solving the PEIS problem for the foreseeable future. And maybe also the performance, which is now at a sluggish seven seconds or so. It feels a little odd to write a module to produce just that row style, it just feels a little arbitrary somehow, or like it locks in a format in a way that would make it very resistant to change. Maybe I just prefer the landing page approach because it is low-tech, i.e., "anybody can do it", and doesn't require a particular format. With a module, editors won't be able to simply cut and paste a new row into the table anymore; presumably they'll have to paste a new template (or even direct module invocation). Not sure how I feel about that. But if it solves the current crisis, that's definitely a point in its favor. [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 02:47, 28 September 2025 (UTC)

At this moment, we are at 100% (2,097,111/2,097,152 bytes) and a dozen templates fail to render. [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 07:01, 10 October 2025 (UTC)

=== One giant table approach ===

{{u|Johnuniq}} mentioned the possibility of copying all the table rows from the eight subpage chunks into one table. Inspired by that and the precipice we nearly fell off of in the [[#Yikes, four bytes left|previous section]], I decided to give that a try; see [[Wikipedia:Reliable sources/Perennial sources/One giant table]]. It blows through PEIS and ends up with dozens of broken refs (loads slowly). I am not saying John's approach won't work, it seems to me that it ought to. There is a strange width problem with column one taking up 1/2 the screen width and adding a horizontal scroll bar (my attempt to fix that with {{kbd|max-width}} in the column header had no effect). I must have made a mistake somewhere. It's possible that I made a mistake copying the eight pieces. It is perhaps possible that different pieces need the same named ref or note, and when merging them, you might get a duplicate key error; but that's not the kind of error I am seeing. Be that as it may, there are dozens of ref errors, which look more like a symptom of having hit the PEIS limit somewhere in the table, or maybe only during the resolution of the notes and refs (which I changed from templates {{t|notelist}} and {{t|reflist}} to &lt;references />). If I have learned anything from the exercise, it is that dealing with a table of that size (547kb) is fraught with difficulty, and even if this can be made to work, it will be facto impossible to maintain. So I am happy to hand off the [[Wikipedia:Reliable sources/Perennial sources/One giant table|One giant table]] to whoever would like to give it a try. Note that the page in its current state takes 15 to 25 seconds to load.  Or maybe just starting over from scratch is a better idea. Good luck! [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 01:42, 28 September 2025 (UTC)
:I notice that you transclude each subpage and then subst that subpage. It seems obvious to me that duplicating the giant table that we have would easily exceed PEIS. Am I missing something? [[User:Aaron Liu|<span class="skin-invert" style="color:#0645ad">Aaron Liu</span>]] ([[User talk:Aaron Liu#top|talk]]) 02:58, 28 September 2025 (UTC)
:: No, I don't transclude each subpage, I copy its content. Where do you see a transclusion? If I hit Ctrl+V twice somewhere, that could account for something being doubled, but it's unlikely I made that mistake eight times, and if I did it even once, there would be duplicate rows in the table; are there any?  Btw: the templates start failing in the table starting in column six of the ''Natural News'' row. {{ec}} [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 03:04, 28 September 2025 (UTC)
:::You have:<syntaxhighlight lang="wikitext">
{{WP:Reliable sources/Perennial sources/1}} <!-- Spans 1,A -->
|- class="s-gu" id="112 Ukraine"
<!--{entries 1–A....}-->
{{WP:Reliable sources/Perennial sources/2}} <!-- Spans B,C,D -->
<section begin="deprecated"/>
|- class="s-d" id="Baidu Baike"
<!--{entries B–D...}-->
</syntaxhighlight>and so forth for each of the eight subpages.{{pb}}I wonder if you've tried adding subst: to the start of each transclusion instead of what sounds like some furious Ctrl+C, Ctrl+V-ing? [[User:Aaron Liu|<span class="skin-invert" style="color:#0645ad">Aaron Liu</span>]] ([[User talk:Aaron Liu#top|talk]]) 03:08, 28 September 2025 (UTC)
::::I've now mocked up the page fully with my method. 1326557/2097152 bytes, but with all of the edit lag and overhead problems that caused us to switch to transclusion in the first place.<syntaxhighlight lang="csv">
Transclusion expansion time report (%,ms,calls,template)
100.00% 3026.315      1 -total
 27.90%  844.343    406 Wikipedia:RSPSHORTCUT
 24.52%  742.072    406 Template:No_redirect
 21.38%  647.125    492 Wikipedia:RSPUSES
  5.82%  176.022     19 Template:Cite_web
  5.13%  155.118    497 Wikipedia:RSPSTATUS
  5.02%  151.784      1 Template:Notelist
  4.94%  149.493      1 Template:Reflist
  4.17%  126.222    495 Wikipedia:RSPLAST
  3.63%  109.741     19 Template:Shortcut
</syntaxhighlight> [[User:Aaron Liu|<span class="skin-invert" style="color:#0645ad">Aaron Liu</span>]] ([[User talk:Aaron Liu#top|talk]]) 03:16, 28 September 2025 (UTC)
:: Okay, I do see a problem now, but I don't know how it happened yet; probably that page is junk and should be abandoned. It would have to be recreated from scratch. Okay I see it now: I had extra end-hidden text delimiters taht was causing an id line to transclude the files, as you said; fixing the hidden delimiters fixed the problem. [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 03:14, 28 September 2025 (UTC)
:: It's already fixed. I wouldn't try substing it as god knows what kindd of awful code that would cause. Anyway, it is working, and we have 1,326,523/2,097,152 bytes PEIS (65%), with page load=7.684 seconds, Real time usage=8.396 seconds. Not great, but not a crisis anymore. But it is a very long page. [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 03:17, 28 September 2025 (UTC)
:::I substed. :){{pb}}Not sure what you meant by hidden-text delimiters—the transclusions were out in the open. [[User:Aaron Liu|<span class="skin-invert" style="color:#0645ad">Aaron Liu</span>]] ([[User talk:Aaron Liu#top|talk]]) 03:18, 28 September 2025 (UTC)
:::: Sorry, but we edit conflicted while I tried to save my change, and I removed your changes and completed my edit with the removal of the extra comment delimiters. It is now at 1,248,178/2,097,152 bytes. [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 03:25, 28 September 2025 (UTC)
:::Ah, I see; you meant to place the subpage names within hidden comments instead of out in the open.{{pb}}Still, I assure you that substing the subpage transclusions worked and was what was in my edit. [[User:Aaron Liu|<span class="skin-invert" style="color:#0645ad">Aaron Liu</span>]] ([[User talk:Aaron Liu#top|talk]]) 03:26, 28 September 2025 (UTC)
:::: I think the point is that this is tricky, and leaves us a very long, somewhat slow, but working page. I really don't know how to proceed now; should we try to get some local consensus and install a version of it? Should this be a long-term solution (I don't think so; still worth looking into your module approach). Or should we just keep the current page as is, and fully protect it and the eight chunks while we come up with a permanent fix? Or is this it? {{ec}} [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 03:31, 28 September 2025 (UTC)
:::::I don't think we should revert to something consensus has decided to move away from (albeit without realizing PEIS problems) when alternatives exist.{{pb}}I don't think we need to lock the pages from editing until we actually hit the limit. I got through less than half of a single (though admittedly the longest) subpage and we've already saved over 8000 bytes. [[User:Aaron Liu|<span class="skin-invert" style="color:#0645ad">Aaron Liu</span>]] ([[User talk:Aaron Liu#top|talk]]) 05:27, 28 September 2025 (UTC)
::::::{{anchor|06:00, 28 Sept}} I don't quite understand what you are favoring and what you are opposing here. I get that you are continuing efforts to try to save space in the table, but I am not sure if that is because you are trying to buy time while favoring another, more lasting approach, or whether with sufficient savings you hope to keep the table viable for the foreseeable future. [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) <!--Template:Undated--><small class="autosigned">—&nbsp;Preceding [[Wikipedia:Signatures|undated]] comment added 06:00, 28 September 2025 (UTC)</small>

=== Implementation planning ===

@[[User:Mathglot|Mathglot]], [[User:Aaron Liu|Aaron Liu]], [[User:Raladic|Raladic]], [[User:ActivelyDisinterested|ActivelyDisinterested]], [[User:SuperGrey|SuperGrey]], anyone else:

After this scare over the PEIS limits, I think we need to get something done.  Here's what's on my mind:

# Make a way to convert the table into individual pages.  ({{Awaiting}} design of individual pages)
# Make a way to convert the table into a list that links to the individual pages.  (Is regex enough?)
# Settle the design for individual pages.
## Settle the overall design
## Settle the infobox design
## Create/update an infobox template
# Communicate changes to relevant groups of editors (e.g., RSN, [[WP:ADMINNEWS]]).
# Create all the individual pages.  (Must have stable URL pattern before this.)
# Repoint all the shortcuts to the new individual pages.  (@[[User:Gonnym|Gonnym]], do you have any suggestions for automating this?)
# Add a search box on main RSP page.
# Replace the big table on the main RSP page with a simple list of all the individual pages.

Is there anything else? [[User:WhatamIdoing|WhatamIdoing]] ([[User talk:WhatamIdoing|talk]]) 02:04, 28 September 2025 (UTC)
:I want to estimate how much PEIS savings porting the page to using a single module for generating each table row instead of our current assortment of templates would provide first. [[User:Aaron Liu|<span class="skin-invert" style="color:#0645ad">Aaron Liu</span>]] ([[User talk:Aaron Liu#top|talk]])
:: I think it would be substantial, and stave off PEIS limits for a long time, which means we could keep the table approach for a long time. If that works out, would you then prefer to keep it as a table, and if so, organized how: in the eight transcluded chunks, or as one, large, fast-loading table that is not close to the PEIS limit?  I think it is just unwieldy at this size, and I prefer the new approach now, even if it isn't required to avoid hitting the limit anymore. Otoh, I don't know if the effort to convert is worth it, vs. the effort to build a module-based row-builder. I think the latter is fewer moving parts, but someone has to do it;  the former has more pieces to it, but I think it is relatively low-tech and accessible to more people. I guess I vote to convert, just because it seems easier to grasp, and I can picture it being more useful to more people. I was never that fond of the big table, which just feels restrictive, compared to the way we display project content that comes in multiples in separate pages, like Afds, SPIs, and the like. And then there is the clearly working, albeit unwieldy {{slink||One big table approach}}; now that we have proof of concept on that one, we have a guaranteed fallback position that could be used to buy time in case there is a problem getting over the finish line with some other method. [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 05:11, 28 September 2025 (UTC)
::If some technical magic could solve this problem for at least the next several years, then I'm okay with kicking that can down the road. [[User:WhatamIdoing|WhatamIdoing]] ([[User talk:WhatamIdoing|talk]]) 17:12, 28 September 2025 (UTC)
: Your point #2 (create links) can be done with regex. I first tried it with the 'id' field in the start row delimiter ({{kbd|{{!}}-}}), and that created [[Wikipedia:Reliable sources/Perennial sources/List of linked ids]]. But that hit some snags, suc has at #167 gnis-coord; but right under that in the table at that point, is &#91;&#91;Geographic Names Information System&#93;&#93;, so maybe we want what is on that line, so I'll have to look at that tomorrow. I'm sure we can create the file one way or another about 95% accurate, and then fix up some stragglers manually. 
: Your point #1 (create page from table row) is a little trickier, not because we don't have the landing page format, but because the source layout (contents of the table row) is not always the same. If it were, we wouldn't need the destination format just yet; we would just convert the table rows into a canonical list of key=value sets, e.g., id=..., shortcut=..., rfc=..., summary=...., last=... an so on, and then when the format was decided upon, we just convert the k=v file into whatever format we chose. So the stumbling block is the variability in the table we have now, not the unknown destination format. There are still ways to parse variable rows, but it won't be just one regex that works for everything (although my regex worked for quite a few pages, it didn't work for all of them). The way to do it, is multiple patterns pulling out one field at a time, and stringing them together in a template or module; that is more powerful. Doable; just needs more time. [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 06:50, 28 September 2025 (UTC)
::About point #1:  If we say that the existing table has entries mostly in style A, but also in styles B, C, D, E, etc., could we send a script through that creates the page for style-A entries, skips the incompatible styles, and removes/tags those style-A entries (so we know which ones are done)?    [[User:WhatamIdoing|WhatamIdoing]] ([[User talk:WhatamIdoing|talk]]) 17:11, 28 September 2025 (UTC)
::: Yes, that is one part of the iterative approach [[#22:32, 28 Sept|below]]. [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 23:43, 30 September 2025 (UTC)
:@[[User:WhatamIdoing|WhatamIdoing]] regarding the question you asked of me at 6, if you know what group of shortcuts have changed to a specific sub-page, then you can use AWB to quickly update those links. If not, then manually fix the links. [[User:Gonnym|Gonnym]] ([[User talk:Gonnym|talk]]) 12:30, 28 September 2025 (UTC)
:: {{anchor|22:32, 28 Sept}} The key phrase there being, {{xt|what group of shortcuts have changed}} (by which I read, "the table-row target of which shortcuts have been successfully converted to a landing page"). That in turn, is dependent on #5, which is the heavy-lift item ("create all the pages"), so 5 and 6 are kind of the meat of the conversion. Given the number of table rows (497), and the dependence of any conversion procedure on pattern-matching in order to convert table rows to pages, it is not practical to assume that #5 will happen all at once and convert all 497 rows without glitches, which is to say, no pattern (or pattern suite) will be perfect and match all of them. That implies that this #5 is likely to be most efficient as an iterative process rather than hoping for one big bang that converts everything, because the time required to design a perfect conversion that would match all of the rows—if even possible—probably greatly exceeds the time it would take to run a "good-enough" conversion that can be quickly designed and is pretty good at converting a large majority of the rows, observe what remains, tweak the converter to handle the majority of what is left, and iterate until the number of unconverted rows remaining is small enough to convert them manually. I.e., points 4, 5, and 6 actually sit inside a loop, with new points added after point 6, and the list of links should be created before anything is converted, not after; so we would have roughly this:
::* 4.1: Make a simple list of all the individual pages (similar to former #8) 
::* 4.2: point every item in the list into the table using existing shortcuts &nbsp; &nbsp; <small><small>(updated @[[#22:41|22:41 below]] )</small></small>
::* 5: Run converter on <s>all</s> <u>remaining unconverted pages</u> (the first time, that is all of them)
::* 6.1: make lists of converted, and unconverted pages remaining
::* 6.2: Repoint <s>all the</s> shortcuts <u>of converted pages</u> to the new individual pages
::* 6.3: Is the unconverted list small enough that it's easier to convert them manually than tweak the converter patterns again?
::** 6.3a: yes
::*** 6.3a.1 convert them manually
::*** 6.3a.2 go to 7
::** 6.3b: no
::*** 6.3b.1 Adjust converter to handle most of what remains
::*** 6.3b.2 go to 5 
:: (renumber steps as appropriate). Based on my experience of how these things go in RL, this needs to be conceived of as an iterative process, with manual steps involved (at 6.3a&b) being part of it, because it isn't going to happen all at once; i.e., there will be a transitional period where not all rows have been converted, and most links on the Index page will point to landing pages, but some minority of them will still point into the table, fewer with each conversion iteration, and then gradually picking up the stragglers manually at the tail end of the process. I welcome additional opinion, but I think any planning that is dependent on an all-at-once conversion is very risky. [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 22:32, 28 September 2025 (UTC)
::: {{anchor|22:41}}Actually, I have an improvement on {{xt|some minority of them will still point into the table}}: if we simply copy all table rows into the landing pages at the outset, similar to how the [[WP:RSPDEMO|Demo]] is set up, then we can skip step 6.2, and all the links can always point to the landing pages from the start, which will either be converted or not; in the worst case, users follow one of the links, and end up at a landing page having just an unconverted table row, the way the demo is now. That woul give us, 4.1 "Copy all the table rows to landing pages" and 4.2 "Point every item in the index list into the <s>table</s> <u>landing pages</u> using existing shortcuts". [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 22:41, 28 September 2025 (UTC)
::::So instead of going from current table row at RSP → fancy new layout on subpage, we would instead go from current table row at RSP → copy of that exact table row on subpage → later convert to fancy new layout.
::::I like it, assuming Aaron doesn't convince us to keep the existing setup with a more efficient module. [[User:WhatamIdoing|WhatamIdoing]] ([[User talk:WhatamIdoing|talk]]) 00:58, 29 September 2025 (UTC)
::::: Yes. Basically, it is what the [[WP:RSPDEMO|Demo]] does now, albeit only for B–C–D. Click a few links in section [[WP:RSPDEMO#List]] that do *not* have the Document symbol icon ([[File:Document icon (the Noun Project 27904).svg|17px|alt=document icon]]) meaning, 'oonverted', and compare to ones that do. (There is also the table icon  ([[File:Codex icon table color-success.svg|14px]]), meaning, "This is an unconverted row: click the link text to see the row by itself on its own subpage, or click the icon to see the identical row in its original context in the live table." But I don't know that it is worth including this in a conversion implementation.) [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 01:13, 29 September 2025 (UTC)
:I still pretty much prefer individual pages. It solves the PEIS limits once and for all, and can display more information that one row of table entry cannot provide. [[User:SuperGrey|'''<span style="color:#765CAE">Super</span><span style="color:#525252">Grey</span>''']] ([[User talk:SuperGrey|talk]]) 17:39, 28 September 2025 (UTC)

=== Row-builder module approach ===

[[User:Aaron Liu|Aaron]], I believe you were the one to first suggest this; at least, you mentioned it [[#23:59, 27 Sept|here]]. This is worth breaking out into its own section. [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 23:00, 28 September 2025 (UTC)
: And your [[Special:Diff/1312965156|earlier]] comment. [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 16:12, 1 October 2025 (UTC)

The first question that occurs to me, is that for existing content, perhaps we could have a generic row builder where you simply pass it six parameters, c1, c2, ..., c6 for the six columns, with the value of param c1 being the content of column one, and so on, and split out the existing table, and pass each row to the module with those params. (If feasible, this could theoretically work for any table.) But that would require being able to pass content including new lines, pipe characters, brackets, and other metacharacters; do we know if that can that be done with a module? For adding new rows, passing params with newlines etc. might be very messy and error-prone; it might be more user-friendly to have a dedicated module with parms dedicated to relevant items in an RSP row, like shortcut, status, article (if any) summary, rfc, discussions, and so on. How were you thinking about the module invocation? [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 23:26, 28 September 2025 (UTC)
:I'm thinking something like <syntaxhighlight inline lang="wikitext">{{RSP row|name=Aaron Is Awesome|alias1=AIA|status=gu|deprecated=y|summary={insert wikitext here}|domain1=example.org|domain2=example.com|discussions=[[link|1]]<br/>[[VGRS link|A]]|last=2018}}</syntaxhighlight> [[User:Aaron Liu|<span class="skin-invert" style="color:#0645ad">Aaron Liu</span>]] ([[User talk:Aaron Liu#top|talk]]) 22:17, 4 October 2025 (UTC)
:: I was thinking something like that, but template-based rather than module based (as I don't know Lua yet). That doesn't solve the PEIS problem in the same way, but it might either solve it by substituting a ream of template calls for just the one, and also, it could just be a prototype to get something up relatively quickly, that could later be ported to Lua for even more savings. I had in mind a further refinement for a template (or module) of that nature, namely, the output of it could be defined by a config file (or set of them) where each config specified what to do with the params, so that using one config would generate a page looking like [[WP:Reliable sources/Perennial sources/all/Ballotpedia|*/Ballotpedia]] (the landing page format I have been using in the [[WP:RSPDEMO|demo]]), and another would generate [[WP:Reliable sources/Perennial sources/all/Deutsche Welle|*/Deutsche Welle]] (in {{u|WhatamIdoing}}'s format), and another one might generate a Wikitable row, except without all the templates it currently uses, which I believe is what you had in mind, but am not entirely sure, as I [[#06:00, 28 Sept|mentioned earlier]]. 
:: Are you hoping to keep the table format, either because you prefer the table approach or because you believe it is the quickest path to a solution (whether temporary or permanent) to the PEIS problem, or are you considering some of the [[#Approach summary|§&nbsp;other approaches]] mentioned in this discussion? Without prejudicing any short-term solutions we might come up with on an emergency basis on our own, it seems to me we now have multiple approaches that deserve to be aired more widely, perhaps via an Rfc, when we are ready for that (not quite yet, imho, but soon). Are we in agreement about that?
:: In order to prepare for that possibility, we should try to neutrally summarize all the approaches, with a view to drawing up an Rfc question we can all agree on. Section {{slink||Approach summary}} is my attempt to get started on that, and a precursor, in my view, to discussing any Rfc question, because we have to agree what the alternatives are before us, before we can present them to anybody else. Can you please have a look and make sure it fairly describes the approach you have in mind, as well as any of the others as well, and that I haven't missed anything. I should add that I would make any rfc question strictly about the different approaches, and exclude purely stylistic concerns which could and should be worked out later via consensus.
:: For my part, I am continuing to flesh out the [[WP:RSPDEMO|demo]] for the landing page approach; if you haven't perused it lately, it has upgrades as well as more pages converted. (I originally had decided to stop converting pages for the demo, as we had more than enough, but it turns out that some table rows had unique features, and in thinking how to deal with them, I came up with solutions that were helpful not only individually  but more generally, and there was a synergistic effect, so I kept going.) 
:: In a couple of three days I will come to a stopping point with the [[WP:RSPDEMO|demo]], and I would hope that there would be interest among us in debating whether and how to word an rfc question for general consumption. That doesn't mean that we should stop looking at how to deal with critical PEIS issues in the very short term, and I am available to help with that however I can, but my main focus now is looking at how we are going to have a stable Perennial sources system going forward that is scalable, lasting, and has community support. Thanks, [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 23:39, 4 October 2025 (UTC)
:::I prefer the table approach because it minimizes the number of page loads and sorting is sometimes useful. [[User:Aaron Liu|<span class="skin-invert" style="color:#0645ad">Aaron Liu</span>]] ([[User talk:Aaron Liu#top|talk]]) 02:47, 5 October 2025 (UTC)
::::If we can sort the entries in the [[Wikipedia:Reliable_sources/Perennial_sources/Index|index page]] (e.g., use a bot to auto-update sorted lists by last update dates or by reliability ratings), that could make the table approach minus one advantage. And I believe "one huge page load" also isn't an advantage to "two small page loads." [[User:SuperGrey|'''<span style="color:#765CAE">Super</span><span style="color:#525252">Grey</span>''']] ([[User talk:SuperGrey|talk]]) 03:01, 5 October 2025 (UTC)
:::::Aaron, would a category meet the same need as sorting the table?  I think it would work for, e.g., finding all the deprecated items. [[User:WhatamIdoing|WhatamIdoing]] ([[User talk:WhatamIdoing|talk]]) 04:35, 5 October 2025 (UTC)
::::::Having categories is one great solution, and having a bot that auto-create sorted lists also solves the problem (and doesn't need users to install any gadgets). The one-page advantage is also defeated by the progressive loading via modules, which also takes API calls and costs memory usage. I would say that the table approach doesn't really have advantanges imo, except that it's "our tradition." [[User:SuperGrey|'''<span style="color:#765CAE">Super</span><span style="color:#525252">Grey</span>''']] ([[User talk:SuperGrey|talk]]) 04:54, 5 October 2025 (UTC)
::::::: SuperGrey, not sure I follow what the bot is supposed to do, or why we need one. Also, what about a gadget? [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 05:06, 5 October 2025 (UTC)
::::::::The row-builder module is a gadget, no?
::::::::I'm just suggesting that if Aaron find it useful to have the sources sorted by last discussion dates or by countries/regions, they can use an automated bot to do the trick -- auto generate the sorted lists whenever a new RSP entry (subpage) is added/modified. [[User:SuperGrey|'''<span style="color:#765CAE">Super</span><span style="color:#525252">Grey</span>''']] ([[User talk:SuperGrey|talk]]) 05:11, 5 October 2025 (UTC)
::::::::: No, a row-builder module is a [[WP:Module|Lua program]], located in the [[WP:NS|Module namespace]]; for example, [[Module:Row numbers]] is a Lua module, and runs on the server that builds the Html that your browser downloads and interprets. A [[WP:Gadget|gadget]] is a [[javascript|javascript program]] that runs in your browser on your machine. I still don't follow you about the bot, though. Aaron wouldn't need a bot to see sorted by last discussion date; you just scroll to the top of the table, and click the sort arrow in column four, and then the whole table is sorted by last discussion date. No bot required. [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 05:31, 5 October 2025 (UTC)
::::::::::The row-builder module itself is a Lua program, but is the "lazy loading" also written in Lua? I though it needs to have Javascript gadget infused, but maybe I was wrong and Aaron's approach doesn't need that.
::::::::::About the bot thing -- What I meant is that the "index page approach" need a bot to get sorted lists; Aaron's row-builder approach deosn't need a bot, of course. [[User:SuperGrey|'''<span style="color:#765CAE">Super</span><span style="color:#525252">Grey</span>''']] ([[User talk:SuperGrey|talk]]) 05:43, 5 October 2025 (UTC)
::::::::::: I'm a step closer to understanding, but still not quite there. Why would you want a bot in the Index + landing page approach? What would you sort? The index page is sorted by definition. Status, deprecation, and last discussion are all categorized on the landing pages, and proper use of [[WP:DEFAULTSORT|Defaultsort]] keeps the source page names in each category alphabetized. See for example: [[:Category:Perennial sources deemed generally reliable in 2020]]. What would a bot do? [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 05:56, 5 October 2025 (UTC)
::::::::::::I already said -- categorizations is already great solution; I'm just suggesting that a bot can also solve the problem. Therefore, we have at least two solutions that can counter the "disadvantages" Aaron said. [[User:SuperGrey|'''<span style="color:#765CAE">Super</span><span style="color:#525252">Grey</span>''']] ([[User talk:SuperGrey|talk]]) 06:05, 5 October 2025 (UTC)
::::::::::::Details to the bot solution: Bot can extract params from infobox, and use that to generate lists sorted by other params, that serves as alternate versions of the index page which is sorted by defition. It is definitely more work than simple categorization, but also feasible. Anyway, I was just proposing this additional idea to counter Aaron's points; the categorization is good enough. [[User:SuperGrey|'''<span style="color:#765CAE">Super</span><span style="color:#525252">Grey</span>''']] ([[User talk:SuperGrey|talk]]) 06:10, 5 October 2025 (UTC)
::::::::::::: Thanks for the details; I understand now what you meant. [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 06:35, 5 October 2025 (UTC)
:::::::::::What I'm talking about doesn't include lazy-loading. [[User:Aaron Liu|<span class="skin-invert" style="color:#0645ad">Aaron Liu</span>]] ([[User talk:Aaron Liu#top|talk]]) 16:09, 5 October 2025 (UTC)
:::::: The [[WP:RSPDEMO|demo]] has categories, and we can find all deprecated items in [[:Category:Perennial sources deemed deprecated]]. (If you want them all on one page instead of hierarchically, adding [[:Category:All perennial sources deemed deprecated]] would be trivial.) There are also categories for [[:Category:Perennial sources deemed generally reliable|reliable]], [[:Category:Perennial sources deemed generally unreliable|unreliable]], [[:Category:Perennial sources deemed no consensus|no consensus]], etc. {{ec}} [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 05:04, 5 October 2025 (UTC)
:::: Not sure I see the benefit; compared to what? By fewer page loads, I assume you mean fewer clicks? Or least total page load time? If you start out with one click to get to the top of the table (which loads in 6–7 seconds), and then you Ctrl+F search for it, typing the source name to find it. In the Index + landing page approach, you start out with one click to get to the index (which loads in 0.5"), possibly another click if using the Compact ToC to get to the right letter (instant), and then one click to get to the landing page (~0.5"). In either approach, a redirect would take you in one click directly to the table row, or directly to the landing page; so they are equivalent by that method (except the landing page loads faster). An alternate method is to search for the source in the search box on the [[WP:RSPINDEX]] page, which gets you a Cirrus search result page with all sources that match your keywords all on one page.
:::: By sorting, I assume you mean sorting by table status (col. 2) or by last date (col. 4). Sorting requires you to go to the top of the table, click the sort arrow, and then find the row you were on again. The landing pages are categorized by status and last date, and category links are available at the bottom of the page, so I see no advantage to table column sorting. 
:::: Modularizing the rows will reduce PEIS, but what about load time? [[List of sauropodomorph type specimens]] is 546,564 bytes (very close to [[WP:RSPGIANT|One giant table]]), with a PEIS of 1,441,008/2,097,152 bytes, but load time is still around 6.4 seconds for that list article. That might be a first guess as to what would happen if you modularized the rows. {{ec}} [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 04:51, 5 October 2025 (UTC)

Since presumably any module invocation definition we came up with would, for user-friendliness reasons in creating new rows, also be invocable as a template by passing the module parameters through the template, we could mock up a template that invoked the (non-existent, or placeholder do-nothing) module, and see if it is possible, for example, to create a mockup that would just rebuild the row it was passed by echoing its params in wikitable format, with dummy wikitable header and footer so it would render as a table, with the embedded row in theory looking exactly like the real table row whose parts were passed. The point of the mockup would be to see what an actual invocation would look like in practice, as that is what users would be faced with when adding a new row. Or else, let users add rows the old way using table wikicode, so that the table would be a hybrid of several hundred template/module-built rows with much lower PEIS for 99% of the rows, followed by a handful of user-built rows at the tail end (well, mixed in, in alpha order) using wiki table syntax, which we would pass through the module later on, when space was needed or whenever we felt like. [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 23:53, 28 September 2025 (UTC)

Your {{tlc|RSP row}} idea works well for new rows in the table. The hard part, is what to do with the <s>497</s> 498 rows that are there now. You have to parse them before you can pass the pieces to the row builder. I think some proof of concept is needed for this part. First you need to identify the rows, then the fields in a row. It's pretty easy to split out the rows using [[PCRE]]s, but I'm not so sure about Scribunto regexes (Lua modules). I've been working on some Scribunto patterns for <code><nowiki>{{#invoke:String|match|...}}</nowiki></code> that can pick out the fields, and it is tricky and I haven't gotten too far yet. A hybrid approach might be better: use a PCRE offline to insert a tagged line between every row, that could then be an easy pattern for Scribunto patterns to pick up and split on, and from there, further patterns to grab the pieces. The output of that process, would be the inputs to your {{tlc|RSP row}}, which would be the easy, row-generating part. [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 07:26, 7 October 2025 (UTC)
:I'm not sure why we're even considering writing a bunch of Module invocations on-wiki to generate the text lol. Just use an offline PCRE or add instructions and have it be a manual team effort. [[User:Aaron Liu|<span class="skin-invert" style="color:#0645ad">Aaron Liu</span>]] ([[User talk:Aaron Liu#top|talk]]) 00:27, 8 October 2025 (UTC)
:: Because you raised the idea of a row-builder module, so now I am a bit confused. [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 00:31, 8 October 2025 (UTC)
:::It's parameters(everything non-boilerplate)→module→row, not existing table→module→row.{{pb}}On re-read I realize I may be misinterpreting "you have to parse them"; could you clarify? What I'm thinking is existing rows are added just like adding new rows. [[User:Aaron Liu|<span class="skin-invert" style="color:#0645ad">Aaron Liu</span>]] ([[User talk:Aaron Liu#top|talk]]) 00:39, 8 October 2025 (UTC)
::::How do you envision putting the existing rows into the new module?  Surely you don't want to convert them all by hand. [[User:WhatamIdoing|WhatamIdoing]] ([[User talk:WhatamIdoing|talk]]) 00:42, 8 October 2025 (UTC)
:::::That's what I thought Mathglot meant, too, but surely we don't want to write a Lua module of all things to automate that, nor a Wikitext stringing-together of [[Module:String]] as Mathglot seemed to be verring towards discussing. [[User:Aaron Liu|<span class="skin-invert" style="color:#0645ad">Aaron Liu</span>]] ([[User talk:Aaron Liu#top|talk]]) 00:44, 8 October 2025 (UTC)
:::::: Yes, how you envision adding existing rows to a row-builder-built table is exactly what I meant. Adding new rows (once you have the module) is trivial. And I didn't think we would want to use a module for the conversion as that would limit us to very weak regex, so I didn't understand how you planned to do that; I started using String because I thought that was what you were implying, so I wanted to see what was possible, and I right away ran into roadblocks.  Put another way, I don't understand this sentence: {{xt| What I'm thinking is existing rows are added just like adding new rows.}}. Huh? New rows you just pass the individual row items to a row-builder template/module using a dozen parameters, or whatever it takes (somewhat akin to the monster regex I have been using). For existing rows, you pass what? You would have to parse the existing row first to get the items to pass to the row-builder, right? Imho that is the hard part; a row builder is easy-peasy, once you have the items to pass it. Or have I completely missed your intent? [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 00:59, 8 October 2025 (UTC)
:::::::You've gotten my intent correctly as using a dozen parameters. What I don't understand is why you assume converting existing rows into module invocations must be done through a module/chained #invoke:String-s themselves. The row builder with a dozen parameters is on wiki, the PCRE conversion things to generate the row builder invocation can be done outside of wiki. [[User:Aaron Liu|<span class="skin-invert" style="color:#0645ad">Aaron Liu</span>]] ([[User talk:Aaron Liu#top|talk]]) 01:30, 8 October 2025 (UTC)
:::::::: Okay, so we are back on the same page, again. I didn't assume converting existing rows into module invocations must be done through a module, I heard you say, "row-builder module", assumed you meant building them using the current table (or rows from the current table) as input, and tried to investigate it a little by trying to do the parsing part in Scribunto regex (as that is what a Lua module would have to do), and didn't do very well. (I can get status, id, and source name.)
{{cot|bg=khaki|indent=14.2em|Lua-usable patterns for parsing some row fields:}}
For the record, if we ever need to look at Lua-accessible regexes for perennial source rows, here are some:
{{hatnote|Get status from row 2 of file #1:}}
<code><nowiki>{{#invoke:String|match|s={{WP:Reliable sources/Perennial sources/1}}|pattern={{!}}%- class="s%-([^"]+)" |plain=false |match=2}}</nowiki></code> ⟶ {{#invoke:String|match|s={{WP:Reliable sources/Perennial sources/1}}|pattern={{!}}%- class="s%-([^"]+)" |plain=false |match=2}} 

{{hatnote|Get the {{kbd|id}} attribute from the row-starter line of row 2 of file #1:}}
<code><nowiki>{{#invoke:String|match|s={{WP:Reliable sources/Perennial sources/1}}|pattern={{!}}%- class="s%-[^"]+" *id="([^"]+)" |plain=false |match=2}}</nowiki></code> ⟶ 
{{#invoke:String|match|s={{WP:Reliable sources/Perennial sources/1}}|pattern={{!}}%- class="s%-[^"]+" *id="([^"]+)" |plain=false |match=2}} 

{{hatnote|Get domain from row 2 of file #1 (note that it expands {{kbd|(US)}} into {{kbd|(United States)}}; seems like a bug):}}
<code><nowiki>{{#invoke:String|match|s={{WP:Reliable sources/Perennial sources/1}}|pattern={{!}}%- class="s%-[^"]+" *id="[^"]+" *
 *{{!}} *%[*([^{{!}}]+) |plain=false |match=2}}</nowiki></code> ⟶
{{#invoke:String|match|s={{WP:Reliable sources/Perennial sources/1}}|pattern={{!}}%- class="s%-[^"]+" *id="[^"]+" *
 *{{!}} *%[*([^{{!}}]+) |plain=false |match=2}}

{{hatnote|Beyond this, it gets very tricky dealing with optional elements, and especially embedded newlines.}}
{{cob}}
:::::::: Now that I know you were never advocating for that, I won't continue down that (very bumpy) path. [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 05:04, 8 October 2025 (UTC)

Scratchpad: just using this as a place to preserve some useful regexes. Start with row matcher:
* <code><nowiki>^(\|-(?s).*\n)(?=\|-)</nowiki></code> – match one wikicode row (including terminating newline) and place it in \1
[[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 23:05, 8 October 2025 (UTC)

In the [[#Implementation planning|§&nbsp;previous subsection]], {{u|Aaron Liu}} said,
: {{talk quote|I want to estimate how much PEIS savings porting the page to using a single module for generating each table row instead of our current assortment of templates would provide}}
Have you come up with an estimate? What's involved in creating a module like that? [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 10:09, 10 October 2025 (UTC)

==== Python demo ====

Here is my attempt at a version of the table that would use a module: [[User:Audiodude/RSP_demo]]. It uses the module I wrote here: [[Module:RSP/sandbox]]. The next step would be to write the Python script that parses the current wikitext and extract the values of each parameter from the existing rows. I couldn't figure out how to get the background color styles into my page, but I don't think it's because I'm missing any wiki markup in my output rows (but feel free to point out something I missed) Feedback welcome! [[User:Audiodude|audiodude]] ([[User talk:Audiodude|talk]]) 20:07, 11 October 2025 (UTC)
: {{u|Audiodude}}, bg color is done via class and a style page. See [[Wikipedia:Reliable sources/Perennial sources/styles.css]] and note {{kbd|.s-gr}} and several similar classes near the top. Then just add a class on the [[Help:Table#Row start|start-row delimiter line]] naming the correct class based on the status of the source; e.g., {{kbd|1={{!}}- class="s-gr"}} for a row about a '''g'''enerally '''r'''eliable source, and so on. For a short table with four classes you can copy from, see [[WP:Reliable sources/Perennial sources/X]]. : P.S., do you prefer pings, or are you subscribed, as I am; no pings needed here. [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 01:42, 12 October 2025 (UTC)
::I'm subscribed, but feel free to ping if urgent. [[User:Audiodude|audiodude]] ([[User talk:Audiodude|talk]]) 03:26, 12 October 2025 (UTC)
: Audiodude wrote,
:: {{talk quote|The next step would be to write the Python script that parses the current wikitext and extract the values of each parameter from the existing rows.}}
: That, in fact, is the key element (really the Holy Grail of this project) needed for building each of [[#Approach summary|three approaches being discussed]]. It's what I was using my so-called "monster regex" for, and it sounds like your approach with the py lib will be completely different and hopefully more robust, because my regex worked on the majority of rows, but I had to tweak it for some rows because of a lot of missing items and internal row variability. 
: It would be ideal if you could design your parser separately from the row builder part because as I said, te parser will be needed for several output format styles depending on which approach we are implementing, and rebuilding the row without templates is only one of them. So, for example, when you parse the table row pointed to by [[WP:BALLOTPEDIA]], in your row-builder approach (the one you have started on in your module), you will output a row that renders the same row style but without the templates in the wikicode; however in the  [[#Mg's central list plus multiple landing pages|§&nbsp;central list with landing pages]] approach, you would use exactly the same parser but output a project page instead that looks like [[Wikipedia:Reliable sources/Perennial sources/all/Ballotpedia]]. So the same parser would work and emit different output for multiple approaches, as long as it had different options on the replace side, which could maybe be a config file whose name we pass in a param to the builder. [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 02:09, 12 October 2025 (UTC)
::Right, I understand the idea of parsing the wikitext of the list into what we call an "intermediate representation", and that this could be used for many of the different proposed solutions. However, I felt the need to try and implement a module as a way of working with the rows and starting to understand what "fields" are related to/needed for a row. I guess we can revisit the module itself if we go further down that route. [[User:Audiodude|audiodude]] ([[User talk:Audiodude|talk]]) 03:25, 12 October 2025 (UTC)
::: Great. About identifying what fields are needed, here is the replacement string I used when I wanted a formatless, k=v output for the regex I was using: 
:::: {{kbd|1=id=\1; domain=\2; shortcut=\3; status=\4; last=\5; stale=\6; summary=\7; uses1=\8}}. 
::: Note that this list skips two fields: a) a set of one or more Rfc links, which were sometimes inline, and sometimes embedded in &lt;ref>...&lt;/ref> tags and would appeared as a footnote; and b) a set of one or more (non-rfc) discussion links. You can see five adjacent rows in the table that have both of these types, starting at [[WP:BTVA]]. (The first of the five, 'Behind the Voice Actors', has the discussion list embedded in ref tags.) I dealt with discussion links and rfcs in separate regexes after the monster parsed everything else. 
::: Of these fields, id, status, last, stale, and summary are unique; domain, shortcut, and uses can have multiple values. Afaik, id, last, and summary are mandatory; others are optional. 'Status' is a special case and is 'almost mandatory'; that is to say, almost all rows have a status (gr, gu, nc, b) but the original designer designed 'deprecated' as a binary, yes/no field, and apparently when deprecated=yes, they wipe out the status field. For my regex and follow-up, I consider 'deprecated=yes' as internally equivalent to 'status=d' (but no such status appears in any row). Another binary is 'blacklisted=yes'; blacklisted sources do have a status, 'b' for blacklisted. Uses can be derived from domain(s) (three links per domain) and doesn't need to be parsed from the row. Whether the row contains uses or not, if it contains domains, the builder should output uses for it. 
::: 'Stale' can also be derived; if {{kbd|1={{t|CURRENTYEAR}}}} – LAST >= 4 then stale=y else stale=n. And imho, it *should* be derived, as we currently depend on users editing the files to update its value when they think about it, as in {{lnc|Bri|7|202510081830|ns=Wikipedia}}, which is nuts. See section {{slink||Semi-automating template RSPLAST}} for more about this. [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 04:37, 12 October 2025 (UTC)
::::Okay here's my first shot at a parser: https://github.com/audiodude/wiki-reliable-sources-parser
::::You can see the parsed JSON output for [[Wikipedia:Reliable_sources/Perennial_sources/5|page 5]] here: https://github.com/audiodude/wiki-reliable-sources-parser/blob/main/page_5.json
::::It looks ''reasonably'' correct to me, from the dozen or so I've checked, but obviously more eyes on it would be helpful. I can render all the other pages pretty easily if that's helpful. Also, the thing I'm most likely to have messed up is what fields are needed. I didn't get a one to one mapping with what you mentioned, specifically I don't think I understand "uses" very well, besides that it's just a domain name (mashable.com). [[User:Audiodude|audiodude]] ([[User talk:Audiodude|talk]]) 05:48, 13 October 2025 (UTC)
:::::It was easy enough, the rest of the pages are here: https://github.com/audiodude/wiki-reliable-sources-parser/tree/main/data [[User:Audiodude|audiodude]] ([[User talk:Audiodude|talk]]) 06:04, 13 October 2025 (UTC)
:::::: At first blush, looks good; will take a look tomorrow. Thanks so much for your work on this; this gets us closer to a solution (whichever approach gets chosen). I don't think you need to worry about "uses"; it is completely derivable from domain; i.e., only the builder needs to worry about it, not the parser, so unless I'm missing something (but I don't think so) you can just ignore it. [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 06:59, 13 October 2025 (UTC)
:::::: Oh, one thing: can you modify {{kbd|discussion}} so it is an array of unlinked page names? I.e., for Mail on Sunday (2nd row in page 5), you would have:
<pre style=margin-left:11.2em>
"discussion": 
   [
     "WP:Reliable sources/Noticeboard/Archive 278#Does WP:Dailymail apply to the Mail on Sunday",
     "WP:Reliable sources/Noticeboard/Archive 311#Clarification: Does Daily Mail RfC apply to the Mail on Sunday"
   ],
</pre>
:::::: and the same thing for rfcs? If not, no worries; the builder side can easily do it. Thanks. [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 07:12, 13 October 2025 (UTC)
::::::: So, I couldn't resist trying a couple of things, but now I really have to get some sleep. But to stay in sync with you, I  copied the first two rows from your file 5 into [[Module:RSdata5/data]], with [[Module:RSPTest]] to access it, and wrapper template {{tlc|RSPTest}}, so now we can demo a simple access of your parsed data thus:
:::::::: {{tlx|RSPTest}} →
:::::::: <!-- {{RSPTest}} --> (commented out; see below; [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 04:42, 14 October 2025 (UTC))
::::::: And from that, it's only a matter of expanding it to grab the other fields, and the other rows, and generate the output format desired for each case. And now I really need to let this go for today, but great start, this will lead to a lot of progress. [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 10:11, 13 October 2025 (UTC)
::::::::Okay, I've changed the output format for the `discussion` field to just be a list of page names, is that what you requested? [https://github.com/audiodude/wiki-reliable-sources-parser/blob/main/page_5.json]. I don't know what you mean "same for rfcs". The `rsnl` template takes in the fields broken out in the objects listed, specifically the `notice_id` is required by the template for constructing the full rfc link. Are you asking for the link as rendered by that template? I can't do that in offline Python unfortunately. [[User:Audiodude|audiodude]] ([[User talk:Audiodude|talk]]) 00:51, 14 October 2025 (UTC)
::::::::: Thanks; good as is. [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 00:54, 14 October 2025 (UTC)
:::::::::This looks wonderful! I'd want the RSN discussions singled out (like how we currently have numbers for RSN discussions and letters for anything else) but thi is good enough already. [[User:Aaron Liu|<span class="skin-invert" style="color:#0645ad">Aaron Liu</span>]] ([[User talk:Aaron Liu#top|talk]]) 12:49, 14 October 2025 (UTC)
::::::::::I've made the change you requested. Now `discussion` maps to a dictionary that has the keys `rsn` and `other`. Take a look [https://github.com/audiodude/wiki-reliable-sources-parser/blob/main/data/page_4.json here] [[User:Audiodude|audiodude]] ([[User talk:Audiodude|talk]]) 16:10, 14 October 2025 (UTC)
:Okay and of course now I realize that I did this in a completely boneheaded way, where I just moved all of the existing templates wrapped in a module! Oops. I'm going to keep iterating on it now that I've got something working and try and replace all of the inner templates with function calls. [[User:Audiodude|audiodude]] ([[User talk:Audiodude|talk]]) 22:49, 11 October 2025 (UTC)

So, I imported the rest of the data into [[Module:RSdata5/data]] from {{u|Audiodude}}'s parsed [https://github.com/audiodude/wiki-reliable-sources-parser/blob/main/data/page_5.json subtable 5]. The row-builder <s>grabs only two fields from each row with no formatting, but it works.</s> <u>now emits a table with proper background shading per status for  each row, and four columns of data</u>. <small><small>updated by [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) at 08:45, 14 October 2025 (UTC) (UTC)</small></small>
{{cot|bg=khaki|indent=1.6em|1=Run template {{t|RSPTest}} on subtable [[Wikipedia:Reliable sources/Perennial sources/5|5 (M–N)]]}}
{{RSPTest}}
{{cob}}
Now it's just a matter of expanding the module into a true row-builder, by formatting the rest of the data, using wikitable delimiters so everything comes out in six columns. I could probably hack it out eventually, but I am a beginner at Lua and someone familiar with it could probably do it in very short order. [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 04:46, 14 October 2025 (UTC) <small><small>update: learning Lua, and making some progress with this now. [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 08:29, 14 October 2025 (UTC)</small></small>
: For the record: for the data conversion from JSON to Lua data module, I used: {{kbd|1=s!^([^":]+)"([^":]+)":(.*)$!\1\2 =\3!g}}, followed by another one to replace lone square brackets to curlies. [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 06:22, 14 October 2025 (UTC)
::Please please use a proper conversion from JSON to Lua, not regex! Either via a wiki Lua module that reads JSON natively, or an offline Lua script that reads the JSON and emits the Lua lists. [[User:Audiodude|audiodude]] ([[User talk:Audiodude|talk]]) 21:52, 14 October 2025 (UTC)
::: It turns out that there is a way to read JSON natively involving [[mw:Lua manual#mw.loadJsonData|mw.loadJsonData]], as I learned from Aidan, but by that time, my module was already using the Lua data version, so it's just using [[mw:Lua manual#mw.loadData|mw.loadData]] for the time being, and I don't feel like converting it to read JSON just for a demo. [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 20:14, 16 October 2025 (UTC)
: Note: I have made a request at [[WT:LUA]] for assistance from a Lua volunteer to help with the row-builder module. [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 07:03, 14 October 2025 (UTC)
::Let's pause for a moment and think about how we're using everyone's time and energy:
::There are three main options here.  Only one (1) of them is going to be approved and put into practice.  If we build all three of them, we'll be throwing two of them in the trash next month.  How much effort do you want to be throwing away when the RFC is over?  Maybe we shouldn't create the row-builder module until we know that's the one that the community is going to adopt. [[User:WhatamIdoing|WhatamIdoing]] ([[User talk:WhatamIdoing|talk]]) 18:31, 14 October 2025 (UTC)
::: Thanks for the motivation and concern about time in that comment. There have been claims made before about to what extent the row-builder approach would help, and I would like to see some hard data about that, and building a module mockup would help with that. I don't believe that following an rfc that chooses a different approach, an unused, mocked up approach is a wasted effort. In my case at least, I have been meaning to get started with Lua for ages, and working on [[Module:RSPTest]] is my first Lua module, so nothing is wasted in the learning process. (Wrt the [[WP:RSPDEMO]], nothing is really wasted there either, as it pushed my regex abilities as well.) Plus, whatever approach is not used will still be there down the road if we need them, not to mention serving as a model for how other projects might approach a looming PEIS issue in their project, as there is a rich history here now, as well as a pretty good toolkit that could be purloined. (Finding it here might be an issue, but then, it always is.) So, not too worried about time spent, at least on my part. 
::: If there is an underlying concern about these efforts pushing off the Rfc a bit, I understand. Personally, I am not too concerned about that, although I get that there is a desire to just get on with it. That's a tougher call, as at some point, there will be diminishing returns from continuing to work on the row-builder module, but from my PoV it was never about completing the module to production quality, but rather getting it to a point where we can measure how it does with PEIS, and thus give us a better estimate for projecting how it would affect PEIS in the future to see how it stacks up against the other approaches we will give as options in the Rfc. The module version currently in [[Module:RSPTest/sandbox]] may be close enough for that already, or almost. It doesn't contain the discussion links in column 3, but that shouldn't matter as those links may be numerous and long (e.g., [[WP:DAILYMAIL]]), but they do not use templates. Otoh, it doesn't yet have "uses" in column 6, which does use templates, and once that is in there, I think it will be quite usable as a predictor of future PEIS usage. We already know how to do "uses" without templates, because {{t|Infobox source reliability}} already does that. Adding {{u|Aidan9382}}, who has already improved the module considerably beyond my bumbling effort, just so {{they|Aidan9382}} can observe how it looks down here in the trenches, where these efforts are being used and avidly discussed. [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 19:53, 14 October 2025 (UTC)
::::How long do you think it will take to reach that better PEIS estimate?  A day, a week, a month? [[User:WhatamIdoing|WhatamIdoing]] ([[User talk:WhatamIdoing|talk]]) 20:06, 14 October 2025 (UTC)
::::: A day or two, I would say, after we get Uses in there. But we can draft an Rfc now with some blanks to be filled in later, as in, "Method Y should take us to ____% PEIS and allow ___ rows expansion, and should last approx. _____ unit time" so no need to wait, imho. [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 20:57, 14 October 2025 (UTC)
::::::Drafting the RFC question shouldn't take very long, so I feel like we can wait.  It's the end of Tuesday (for most editors), so that suggests that we might be able to start talking about the RFC details on Friday.  I think that's soon enough. [[User:WhatamIdoing|WhatamIdoing]] ([[User talk:WhatamIdoing|talk]]) 21:06, 14 October 2025 (UTC)
:::1. For the RfC we could just mock up the option with the existing module audiodude made that simply transcludes all the templates needed , and build the actual builder if the option passes.<br />2. For the rest of the year or so I won't have the time and energy to do a lot of stuff, but here's how I was planning to estimate this: subst absolutely everything on a sample of entries, transclude the resulting page and find out how much PEIS that takes up, and generalize that. It should be about the same as a module. (Though I'm expecting that we'll only call the RSPShortcut templatestyles sheet once throughout the entire page instead of once every entry.) [[User:Aaron Liu|<span class="skin-invert" style="color:#0645ad">Aaron Liu</span>]] ([[User talk:Aaron Liu#top|talk]]) 01:20, 15 October 2025 (UTC)
:::: I am not sure whether the method you mention in #2 is a valid proxy for a module or not; see [[Help:Template limits]], in particular {{slink|Help:Template limits|Nested transclusions|Non-rendered transclusions|nopage=yes}}. Maybe it is, I don't know; can you elaborate? I don't understand why the templatestyles directive affects PEIS, but apparently it does: PEIS of [[WP:SHORTCUT]] on its own page is 14,874 bytes; I added 20 more copies of the templatestyles line to the page, and in Preview mode PEIS rose to 18,234 or 168 bytes per inclusion of the 88-byte templatestyles line. Odd. [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 23:18, 16 October 2025 (UTC)
:::::i don't see any reason it wouldn't lol. Assuming we're #invoking the module directly, the only thing it adds to the PEIS besides the text returned is <syntaxhighlight inline lang="lua">		out = frame:preprocess("{{show begin}}") .. '<div class="center" style="width:auto;margin-left:auto;margin-right:auto;clear:both">' ..  out .. '</div></div></div>'</syntaxhighlight>, so the contents of [[TM:show begin]] which are cached and only added once because this invocation has no parameters. (If we instead use a wrapper template that sends all parameters to the module then that simply doubles + adds the wrapper template's length to PEIS used.) {{pb}}WP:SHORTCUT itself transcludes 14,874 bytes' worth. But when you transclude WP:SHORTCUT, the contents of WP:SHORTCUT itself are added to the PEIS. Since the templatestyles invocation is part of the template's content,  it is added to the PEIS.{{pb}}Or at least that's what I've been assuming for a year now. I dunno, I never learned anyaf this in Uni ("dedication to knowledge"... ha). [[User:Aaron Liu|<span class="skin-invert" style="color:#0645ad">Aaron Liu</span>]] ([[User talk:Aaron Liu#top|talk]]) 03:09, 17 October 2025 (UTC)



{{reflist-talk}}

==== Aidan's demos ====

I wanted to highlight here some very relevant work being done by [[User:Aidan9382]] on the "row-builder module approach".

First, I now understand the term ''row-builder module approach'' as describing a suite of related approaches that differ in conception and/or details of implementation, but which have these features as common elements: 
* a Wikipedia Module is involved;
* the result is a wikitable, which to a reader looks indistinguishable from the table we have now; 
* use of the module would replace all or most of the current usage of templates in the table in some fashion; 
* this results in a reduction in PEIS, which permits addition of more rows to the table and buys us some time before PEIS is exhausted again. 
Did I miss anything? Section {{slink||Python demo}} above describes one member of this suite; its design requires an initial external parsing step and importation of a JSON data structure which is parsed by a module to produce the rows; {{u|Audiodude}}, hope I have fairly summarized that.

This subsection highlights some experiments being done by Aidan using a different row-builder module design. It replaces template calls embedded in the existing table rows with module invocations to build pieces of the row, and does not require external parsing. Primary module code is at [[Module:Sandbox/Aidan9382/RSP]], and there is a seven-row RSP test table that goes along with it at [[User:Aidan9382/sandbox3]]; previous revs highlight different experiments.  Some discussion of these experiments has taken place at [[Module talk:RSPTest/sandbox#PEIS difference]]. Projections resulting from one experiment (in [https://en.wikipedia.org/w/index.php?oldid=1317116652 this rev]) indicated a PEIS savings of about 27% and a projection of room in the table for an additional 137–188 rows before we hit 99% again. (Aidan, please correct this summary as needed.) Adding {{u|WhatamIdoing}}. [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 18:35, 16 October 2025 (UTC)

:I was asked to create a Python parser as a fundamental step to ''any'' approach. My own module row builder demo was simply designed so I could understand the number and type of "fields" that are required, so that I could parse them from the current tables. My own module doesn't inherently require Python pre-parsing. However, it seems that the module created by @[[User:Aidan9382|Aidan9382]] requires "arguments" like the ones my module requires, which is what I'm referring to as "fields". I guess I assumed that no one wanted to recreate 600+ calls to a module by hand, and would prefer to generate them automatically based on the intermediate format provided by the Python script. [[User:Audiodude|audiodude]] ([[User talk:Audiodude|talk]]) 21:39, 16 October 2025 (UTC)
::Well, depending on the implementation used, the call replacement should be simple if we use the more basic module replacement method instead of a full row builder, and it'd also end up being more efficient for PEIS, so implementation difficulty specifically shouldn't be a major concern when deciding what to go with. [[User:Aidan9382|Aidan9382]] <sub>([[User talk:Aidan9382|talk]])</sub> 22:59, 16 October 2025 (UTC)

=== How should we word an rfc? ===
{{Further|#RFC drafting section}}

Probably we should start with what our list of options are. Referring to {{slink||Approach summary}}, it sounds like we have three; maybe four. I can easily see the rfc question itself being [[WP:RFCBRIEF|brief]] (a sentence to explain why we are having it (i.e., hitting PEIS limits) and a sentence to introduce the options), but we may need a details section after that, to explain what these options are, and what the implications are of each one. I am somewhat concerned with how we best arm participants with sufficient information to make an informed choice, without drowning them in so much detail that it is counter-productive. [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 18:33, 10 October 2025 (UTC)
: Adding {{ping|WhatamIdoing|Aaron Liu|SuperGrey|Gråbergs Gråa Sång}}; please ping more as needed. In case you missed it, we are down to 98.31% of PEIS capacity, so there is room to discuss this calmly. [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 18:52, 10 October 2025 (UTC)
::How much work do you want to do, to prepare the options?  We have two approaches that would keep a similar appearance and buy ~3 years ([[Wikipedia talk:Reliable sources/Perennial sources#Row-builder module approach|§ module-generated rows]] and [[Wikipedia talk:Reliable sources/Perennial sources#One giant table approach|§ One giant table approach]]) and two approaches that would mean bigger changes but solve the problem indefinitely ([[Wikipedia talk:Reliable sources/Perennial sources#WaId's central list, and click to longer explanation|§ central list, and click to longer explanation]] or [[Wikipedia talk:Reliable sources/Perennial sources#Mg's central list plus multiple landing pages|§ central list with landing pages]] and mocked up [[Wikipedia:RSPDEMO|demo]]). 
::Do you want to prepare all four first, or have people tell you which half they're most interested in, and then make a proposal for just those two? [[User:WhatamIdoing|WhatamIdoing]] ([[User talk:WhatamIdoing|talk]]) 19:41, 10 October 2025 (UTC)

<div style="border:thin solid gray;background-color:#ffffe0;margin-top:2em; padding:0 1em 1em 1em">
:<small>''{{gray|Copy of comment originally placed at {{slink||Approach summary}}:}}''</small>
: We have two main options with the RFC:  One is to ask for preferences on temporary vs permanent solutions, then sort out functional proposals for whichever is chosen and have another RFC.  The other is to develop all of the proposals first and propose them all at once in a single RFC. 
: I'm inclined to the first but will support whichever approach you and @[[User:Aaron Liu|Aaron Liu]] want to take, since you're the two that would have to make the functional proposals. [[User:WhatamIdoing|WhatamIdoing]] ([[User talk:WhatamIdoing|talk]]) 19:30, 10 October 2025 (UTC)
</div>
:: Hm, interesting. Am thinking about this; interested in others' views. [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 19:42, 10 October 2025 (UTC)
:: I do see the advantage in splitting it into two, with the first one being the choice between medium-term + eventual revisit three? years later, vs. long-term/permanent. What concerns me, though, is I wonder if there is an implication here that the medium-term is implementable more easily than a long-term one, which might influence the choice. The problem I see is that of the two medium-term solutions, only one is implementable easily: the giant table. The other medium-term solution is the modularized row-builder, but if that is chosen, what happens next, what is the migration path, and how long would that take? I can see a part I rfc possibly choosing the row-builder approach, and then having no clear idea of what comes next, and then we are kind of back to square one again. So even to present a two-step Rfc solution still requires some technical work ahead of time, imho, to fairly inform participants on what consensus for one option or another might mean. 
:: Wrt to the giant table, if that were chosen, it might paradoxically become a forever solution, rather than a three?-year one, but at a cost. Imho, choosing that option would likely make adding new rows to the table difficult for many editors; just pulling up a table that big in a preview window and finding the right place to insert something is fraught (it was for me), and inserting characters might cause echo delays. What that would mean, imho, is that new rows would be added only by the most hardy and determined or tecchie editors, the giant table would grow much more slowly than the table chunks used to, and you would buy a lot more than three years, maybe indefinite time, but at the cost of a basically moribund perennial sources project that basically gets stuck in 2025, with a few exceptions here and there. I'm not sure that's a good future for the project. As a test, I highly recommend you try to edit [[WP:RSPGIANT]], and add one row to it; pick a random new source name (real or fictional) ahead of time in your head, and then edit the file and try to add the new entry. (Feel free to publish, or not, as you wish.)
:: Or, do we simply acknowledge all this in Rfc #1, make it part of the explanation, and if users want that approach anyway, then so be it? [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 20:12, 10 October 2025 (UTC)
:::I think "simply acknowledge".  Maybe something like "We can do something that will preserve the appearance until the next time this happens (estimated to be three years), but the solutions either make it very difficult to edit the entries or require a lot of volunteer time to create the tools"? [[User:WhatamIdoing|WhatamIdoing]] ([[User talk:WhatamIdoing|talk]]) 20:32, 10 October 2025 (UTC)
:::: Maybe we could contextualize, "No solution is easy or it would have been done already; all options have their downside." [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 20:43, 10 October 2025 (UTC)
:::::That's the plain truth. [[User:WhatamIdoing|WhatamIdoing]] ([[User talk:WhatamIdoing|talk]]) 21:02, 10 October 2025 (UTC)

Is it on-topic in the Rfc to mention that we have a few emergency stopgap techniques in our toolbox, like converting RSPSTATUS, or WaId's replacement of the table with links to the eight subpages (see [[#Yikes, four bytes left|here]])? These all degrade the user experience somewhat, but preserve a functioning table in some form. Or is that irrelevant? [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 05:47, 11 October 2025 (UTC)

:I think we want editors to talk to us about their preferences for non-emergency work.  We may need to keep adding emergency stopgap techniques, but emergency stopgaps aren't solutions. [[User:WhatamIdoing|WhatamIdoing]] ([[User talk:WhatamIdoing|talk]]) 06:01, 11 October 2025 (UTC)
:: Agree; that makes sense. [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 18:51, 13 October 2025 (UTC)

I agree that we should have a split that groups the options that would result in one large table together and then the options that would result in a long list of links together. Instead of "less or more permanent", I'd call this grouping "keep large table or use long list of links". 
Is there still support for the "jump to entry in table" option now that the landing page one has been proposed? [[User:Aaron Liu|<span class="skin-invert" style="color:#0645ad">Aaron Liu</span>]] ([[User talk:Aaron Liu#top|talk]]) 03:21, 13 October 2025 (UTC)
: I'm fine with having separate Rfcs, if consensus goes that way, and I think I'm leaning that way anyway. Let's see who else weighs in. I would not label the second approach "long list of links" because that isn't the goal, or defining characteristic of that approach, anymore than the label "shortcut access" would be the right name for the table approach, implying that the shortcut to a table row is the goal; it isn't. In each case, they are just a navigation method to the data, which is a table row in one scheme, and a landing page in the other; that is the essential difference between the two approaches. Lists of links and redirect shortcuts are just ways to get to the data, not the goal. [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 05:00, 13 October 2025 (UTC)
::Aaron, your idea is basically asking people which appearance they want.  My idea is more like asking people if they want to risk having this problem again in the future.  I think that asking about the appearance is will prompt short-sighted responses, based on what present-me wants and not on what future-me might regret.  There are times when a short-term POV is the right answer, but I don't think that this is one of them. [[User:WhatamIdoing|WhatamIdoing]] ([[User talk:WhatamIdoing|talk]]) 17:05, 13 October 2025 (UTC)
:::Thing is, the two one-table approaches are not necessarily both short-sighted, making your grouping names slightly less than correct. As mentioned above, the one-large-table approach may end up practically permanent because of the sheer amount of space it has left. Something similar is possible but much less likely for the row-builder approach. "Both of these are not theoretically permanent" is a weaker link between options than "they'll look like this". [[User:Aaron Liu|<span class="skin-invert" style="color:#0645ad">Aaron Liu</span>]] ([[User talk:Aaron Liu#top|talk]]) 17:22, 13 October 2025 (UTC)
::::[[Wikipedia talk:Reliable sources/Perennial sources#c-Mathglot-20250930231300-Approach summary|This comment above]] estimates that "one giant table" has room for 150 additional rows, and then we'll be in the same place again.  150 rows is about three years, which is not "practically permanent".  Do you think that estimate is significantly wrong? [[User:WhatamIdoing|WhatamIdoing]] ([[User talk:WhatamIdoing|talk]]) 17:30, 13 October 2025 (UTC)
:::: The one giant table may be permanent, not because of how much space is left, but because it is so big that it is already tricky to edit, and imho this will stifle editors who might have wished to do so, and growth of the table will slow or stop; not the kind of permanent solution I would hope for. I'm not sure what you mean about the row-builder approach being "less likely"—do you mean it won't buy us much time if implemented, or it won't get implemented? Regarding the latter, there has been a flurry of activity lately thanks to {{u|Audiodude}} and we are closer than ever to implementing it; if you meant the former, what is your estimate and what do you base it on? If that calculation is driving what your preferences are, I think we should concretize that estimate. [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 18:21, 13 October 2025 (UTC)
:::::By "less likely", I mean it's less likely for the row-builder approach to turn out practically everlasting; TL;DR: the former. (Also I agree with you on the large table being hard to edit.) [[User:Aaron Liu|<span class="skin-invert" style="color:#0645ad">Aaron Liu</span>]] ([[User talk:Aaron Liu#top|talk]]) 12:59, 14 October 2025 (UTC)
 
::How about something like "separate list of sources from entries"? [[User:Aaron Liu|<span class="skin-invert" style="color:#0645ad">Aaron Liu</span>]] ([[User talk:Aaron Liu#top|talk]]) 17:24, 13 October 2025 (UTC)
::: Sounds like the same thing as before, with "list" being a way to avoid saying, "links". The distinction between approaches presentation-wise is whether each source gets one row of a table, or gets its own landing page. If you are keen to point out that  you have to have a list of landing pages to find them, or that it takes an extra click to do that, that's part of the pro's and con's of each approach, but not what defines them. The crucial difference presentation-wise, is in one you get rows (indissolubly glued together), and in the other you get pages (all entirely separate), but I'm not sure what the best way to say that is. 
::: But I'm with WaId here, regarding how to organize an initial Rfc, namely buys-us-time (giant table, row-builder) vs. permanent (landing pages). I understand you don't agree that giant table and row-builder should be grouped in that way, but I'd like to understand why not. [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 18:42, 13 October 2025 (UTC)
:::: Or, should we reassess the two-Rfc approach compared to going with just one, where we describe both how different approaches look, as well as how long they might last or how easy/difficult they might be to deal with, all rolled up together? Or is that TMI to deal with all at once? And do we agree that we are dealing with three options, giant table, row-builder, landing pages, or are there others? We need to agree on a path forward here. [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 19:05, 13 October 2025 (UTC)
:::::@[[User:Aaron Liu|Aaron Liu]] seems to question the earlier estimate of "one giant table" collapsing when ~150 rows are added.  Iff he's correct, then we have:
:::::* One giant table – could stay functional for 10+ years(?)
:::::* Row-builder – will need to be replaced in ~3 years
:::::* Separate pages – could stay functional for 10+ years
:::::Iff that's the case, then "two ways to make a table, but both of them will break in 3 years" is not accurate. [[User:WhatamIdoing|WhatamIdoing]] ([[User talk:WhatamIdoing|talk]]) 19:59, 13 October 2025 (UTC)
:::::: Aaron is correct. The original comment of ~150 rows applied to the row-builder module, not the giant table approach iirc, and then somewhere I mistakenly copied it to the giant table as well. I just ran a test now adding rows to [[WP:RSPGIANT]], and after successfully adding <s>600</s> <u>300</u> rows to it, it still works. PEIS is at 94.3%, it is 919,169 bytes long, CPU 8.97 seconds (Real time usage 9.469 seconds), columns still sort rapidly (in my browser environment), but syntax highlighting took too long in preview mode and was disabled (very minor issue). It is a viable alternative, and Aaron may be right about it lasting ten years. [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 22:30, 13 October 2025 (UTC) <small><small>updated by [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) at [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 19:50, 16 October 2025 (UTC)</small></small>
:::::::Well, that changes everything (for the RFC).  It should be three-way, and the options are:
:::::::* One giant table – will look about the same, likely to stay functional for about 10 years, and will be difficult to edit entries
:::::::* Row-builder – will look about the same, will need to be replaced in ~3 years, and will be about the same to edit entries
:::::::* Separate pages – will look different, will stay functional indefinitely, and will be easy to edit entries
:::::::Does that sound about right? [[User:WhatamIdoing|WhatamIdoing]] ([[User talk:WhatamIdoing|talk]]) 23:21, 13 October 2025 (UTC)
:::::::: So far, yes, but there has been some important work by {{u|Audiodude}} lately ([https://github.com/audiodude/wiki-reliable-sources-parser parser]; [https://github.com/audiodude/wiki-reliable-sources-parser/tree/main/data data], e.g.: [https://github.com/audiodude/wiki-reliable-sources-parser/blob/main/data/page_5.json page 5]; and this very dumb template of mine, {{t|RSPTest}}, that runs off two rows and two columns of his parsed page 5 file) that should make estimating the row-builder a lot more accurate and less hand-wavy, so I'd like to hear from {{them|Audiodude}} first. [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 00:28, 14 October 2025 (UTC)
::::::::: I've beefed up the module data file so that we now have all of subtable 5 parsed into Lua-readable data, and RSPTest dumps two fields from it for all 61 rows in the subtable. [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 06:37, 14 October 2025 (UTC)
::::::::::How did you convert the data into a Lua data structure? I hope you didn't do it manually, I can write a script to do that conversion and put the result (for all rows) in the repo. [[User:Audiodude|audiodude]] ([[User talk:Audiodude|talk]]) 15:58, 14 October 2025 (UTC)
::::::::::: By [[User talk:Mathglot/Regex#Json to Lua|PCRE regex]]. But if it isn't onerous to write a script to do it, that would save me having to run the regex seven more times, but that is no big deal if you have to spend much time on a script. Btw, such a script would be really great if doable here on-wiki, either in Lua or js, so that other editors would have access to it and could use it for their project. I looked everywhere for a JSON-to-Lua-data module here, but couldn't find one. Another option might be Wikimedia's [[wikitech:Portal:Toolforge|Toolforge platform]], but I am only a user, not a builder there, so can't help too much with that. [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 20:04, 14 October 2025 (UTC)
:::::::::::: {{u|Audiodude}}, good news: no need for my regex or your script; Lua can do it. Please see [[User:Aidan9382|Aidan]]'s comment at [[Module talk:RSPTest/sandbox#Some notes for the test data while implementing|Module talk:RSPTest/sandbox]]. [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 22:36, 14 October 2025 (UTC)
:::::::::::::Too late, see my comment below! [[User:Audiodude|audiodude]] ([[User talk:Audiodude|talk]]) 22:49, 14 October 2025 (UTC)
:::::::::::::Though I also created a [https://github.com/audiodude/wiki-reliable-sources-parser/blob/main/data/sources.json full JSON list] of all the sources together, which should be useful for loading into Lua. [[User:Audiodude|audiodude]] ([[User talk:Audiodude|talk]]) 23:07, 14 October 2025 (UTC)
::::::::::::I've added [https://github.com/audiodude/wiki-reliable-sources-parser/blob/main/convert.lua a script] to convert the JSON to a Lua table, and the [https://github.com/audiodude/wiki-reliable-sources-parser/blob/main/data/sources.lua corresponding table] from running the script on the new `sources.json` file that I created to store all of the rows. I don't know much about how Scribunto works with external modules, so it will be an extra step to make such a conversion available generally, but I'm sure that can be tackled later. [[User:Audiodude|audiodude]] ([[User talk:Audiodude|talk]]) 22:49, 14 October 2025 (UTC)
::::::::::::: Oops, sorry I didn't get here quick enough to save you the trouble, but I just learned of it myself. Agree with the "tackle later" as far as what method is best, we needn't be concerned about that now. One other thing to be clear on: the main goal with any of these module-based row builders for right now is getting a reasonably good estimate of how much a row-builder would affect PEIS, i.e., a) how much would it reduce it from the 99% it is now, if we used it right now, and b) to predict roughly how many rows we could add to the table, if we had the module to build it. The latter, in turn, implies how long such a solution would be valid before PEIS hits 99% again. That information is needed to start the Rfc. It is actually *not* a goal for right now to get a 100% perfect module that gets everything right, or even a data file that is 100% right; they both have to be good enough so that the PEIS reduction estimate is a valid one, but a module that perfectly duplicates the existing live table is not a requirement. So, some fields that imply template use in the current table (e.g., shortcut, status, last, uses, rfc (if the rfc links use the rsnl template–not all do), and others, but not discussions, even if there are 50 of them, because they are just plain wikicode, untemplated. So, once you think your module is developed enough to use it to fairly estimate PEIS reduction, you can call a truce. Ditto the version at [[Module:RSPTest]], and now also at {{u|Aidan9382}}'s [[Module:Sandbox/Aidan9382/RSP]], which I suspect will end up giving us the best estimate, but let's all stay in touch about all these efforts. [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 23:10, 14 October 2025 (UTC)
::::::::::::::Well this is as good a place as any to bring up the fact that, isn't any table that includes all of the rows going to bump into the article size limit, even if it avoids PEIS? Has this already been discussed? Is it being taken into consideration when weighing the alternatives? [[User:Audiodude|audiodude]] ([[User talk:Audiodude|talk]]) 23:16, 14 October 2025 (UTC)
::::::::::::::: That was the point of [[WP:RSPGIANT]]. The original Giant table was 498 rows (like the live table) and has significantly lower PEIS (can't recall exactly, might have been 65%), but was also already 477kb. The current version of the Giant table is a test to see what might happen in the future, has around <s>1100</s> <u>800</u> rows, and is still viable at 94% PEIS. It may hit other limits, but it hasn't hit them yet. Whether to go with a single table of 498 rows, not to mention future growth to <s>1100</s> <u>800</u>, is not a technical question, and should be decided by the community. [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 23:46, 14 October 2025 (UTC) <small><small>updated by [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) at [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 18:39, 16 October 2025 (UTC)</small></small>
::::::::::::::::The max page size is around two million bytes per [[Wikipedia:Article size#Technical issues]].
::::::::::::::::Well before that point we run into editing problems, especially in the 'heavier' editing environments (e.g., if you've turned on syntax highlighting).  [[User:WhatamIdoing|WhatamIdoing]] ([[User talk:WhatamIdoing|talk]]) 02:05, 15 October 2025 (UTC)
::::::::::::::::: Maybe that limit is restricted to articles. In Wikipedia space, [[Special:Permalink/1289466243|<!--WP:Arbitration_Committee_Elections_December_2018/Coordination/Mass_message-->this page rev.]] was 3.7M bytes. Needless to say, it is difficult to load. [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 19:39, 19 October 2025 (UTC)
::{{outdent|15}} The limit applies to all pages with the "wikitext" content model. That page is a mass-message delivery list. [[User:Aaron Liu|<span class="skin-invert" style="color:#0645ad">Aaron Liu</span>]] ([[User talk:Aaron Liu#top|talk]]) 19:51, 19 October 2025 (UTC)

{{u|WhatamIdoing}}, are you envisioning some kind of pro's-and-con's section, either in the top question, or perhaps a details/notes section? One thing I am thinking about, is whether it would be fair, when describing pros & cons of One giant table, to raise the topic of why the current table is transcluded from eight separate chunks. I presume that the reason had to do with editing, not viewing; i.e., making it easier for users to edit it by breaking it up. Either way, the One giant table would undo that, and I wonder if the history, or at least the reason it was broken up in the first place is worth mentioning. [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 00:15, 15 October 2025 (UTC)
:If there's a concern with partiality, we can simply add the procons to the nom's !vote instead. [[User:Aaron Liu|<span class="skin-invert" style="color:#0645ad">Aaron Liu</span>]] ([[User talk:Aaron Liu#top|talk]]) 01:22, 15 October 2025 (UTC)
:: No concerns about partiality. Is that related to the question of chunked tables somehow? [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 02:09, 15 October 2025 (UTC)
:::I think that we have to present some information about the advantages and disadvantages, as participants will neither have the necessary information (the situation is so far outside the normal editing experience) nor be able to look up the answers (there being no reliable sources about the consequences of how this page could/should be structured).
:::For example:  "If we choose this option, some editors may find the page too large to edit comfortably.  They may need to turn off tools such as [[Wikipedia:Syntax highlighting|syntax highlighting]] or ask others to make changes for them."
:::BTW, I made an edit to the table in [[WP:RSPGIANT]] just now, and it works [https://en.wikipedia.org/w/index.php?title=Wikipedia:Reliable_sources/Perennial_sources/One_giant_table&diff=prev&oldid=1316987552 in the visual editor] and in the 2017WTE with syntax highlighting enabled – for me.  But that is going to be partially device dependent, and it took >20 seconds to get my change saved. [[User:WhatamIdoing|WhatamIdoing]] ([[User talk:WhatamIdoing|talk]]) 17:26, 15 October 2025 (UTC)
:::I misread. Seemingly I have hallucinated someone here saying a procon section in the statement might unduely bias certain procons as larger than they actually are. I personally don't think that would happen, so let's pretend my reply was too a hallucination. [[User:Aaron Liu|<span class="skin-invert" style="color:#0645ad">Aaron Liu</span>]] ([[User talk:Aaron Liu#top|talk]]) 02:41, 16 October 2025 (UTC)
:Responding the actual question: You are entirely correct. I've linked this above but here goes:  [[Wikipedia talk:Reliable sources/Perennial sources/Archive 10#Page size]]. [[User:Aaron Liu|<span class="skin-invert" style="color:#0645ad">Aaron Liu</span>]] ([[User talk:Aaron Liu#top|talk]]) 02:43, 16 October 2025 (UTC)
:: Oh, right; thanks for linking that again; I *did* read it the first time, but forgot. Thanks! [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 17:34, 16 October 2025 (UTC)

Regarding what the rfc should say about the {{slink||Row-builder module approach}}: we have two, or maybe three flavors of that now, by {{u|Audiodude}}, {{u|Aidan9382}}, and I'm not sure {{u|Aaron Liu}} if your conception fits one of those or is uniquely different? (I had messed around with [[Module:RSPTest|a test module]], but I consider it a kind of hybrid of Audiodude's and Aidan's methods, and withdraw it in view of better ones.) I don't think we have to go into details in the rfc about differing row-builder approaches; it's enough that we are offering three very different options in the Rfc (i.e., [[#One giant table approach|§&nbsp;Giant table]], [[#Mg's central list plus multiple landing pages|§&nbsp;Landing pages]], [[#Row-builder module approach|§&nbsp;Row-builder]]) without going into suboptions of the row-builder approach. After explaining it briefly, if we just say something like, "the row-builder module approach will allow room for expansion of about N rows which might last for about X time", that should be enough for this option, I think. Iirc, all of the row-builder approaches come up with very roughly the same order of PEIS savings, even if the estimates differ somewhat, but I don't think we need to have a definitive estimate of each before starting the Rfc. If the row-builder module approach is chosen by the community, I think we can leave any decision on which implementation of it is best for later, based on technical considerations. Do you agree? If so, I think we are good to go to write an Rfc question. [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 18:06, 17 October 2025 (UTC)

:Sounds good to me as far as the RFC goes. To be clear, I'm not intent that any approach I build needs to be the one used, and even if the Python parser turns out not to be useful I was happy to build it. [[User:Audiodude|audiodude]] ([[User talk:Audiodude|talk]]) 18:39, 17 October 2025 (UTC)
:I think my conception fits with Audiodude's. I'd change the parameter names but the gist of it is the same. (Also, I think we should at least try the estimate I mentioned below.) [[User:Aaron Liu|<span class="skin-invert" style="color:#0645ad">Aaron Liu</span>]] ([[User talk:Aaron Liu#top|talk]]) 16:13, 19 October 2025 (UTC)

'''Question''', would reducing the number of entries via some systematic method make sense as an option?  Basically is the issue really with the PSN table vs that it seems editors are using this table to ask basic sourcing questions that should probably be held at RSN on a case by case basis.  It was one thing to use this table for sources that really are discussed every other month at RSN.  However, once we get to entries that might only have less than say 5 mentions at RSN why would we add them here even if they are obviously good/bad sources?  I know this is a bit of a fundamental RSP question but can such options be on the table here?  [[User:Springee|Springee]] ([[User talk:Springee|talk]]) 16:27, 19 October 2025 (UTC)
: {{u|Springee}}, if you know of cases where editors are using the table to ask questions about sourcing rather than summarize repeated, significant discussions about a source, can you list a few? If that is the case, then I would say those rows should be removed.  There is a banner at the top of the page that clearly states: "{{xt|Only sources that have been repeatedly raised for discussion are listed here}}". Section [[WP:RSPCRITERIA]] goes further, and describes the requirements for "significant" discussions, and as I understand it, no number of "mentions" would qualify for inclusion of a source here. If you know of cases like that, I think you should probably raise it in a new section on this page, or maybe boldly remove the rows.  [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 19:08, 19 October 2025 (UTC)
:Yes, that could be asked, but I suspect we will get a knee-jerk "Nooooo, we need all of them!", so I don't think that asking it is pointful.
:If you wanted to reduce the number of entries, I suspect that a more successful approach would be to find a particularly weak individual entry and propose its removal (as "shouldn't ever have been added"). [[User:WhatamIdoing|WhatamIdoing]] ([[User talk:WhatamIdoing|talk]]) 20:55, 19 October 2025 (UTC)

=== Barring new rows from the live table ===

P.S., I don't think we'll hit 100% PEIS again while we are discussing, but it might happen during an Rfc, or during implementation of whatever the consensus is, but here is a temporary solution: I have created [[Wikipedia:Reliable sources/Perennial sources/X]] which is an "overflow area" table, which we could request users at RSN to use, instead of adding new rows to the */1 to */8 chunks while the Rfc is open or while consensus solution is being developed. That would prevent the live table from breaking while we come up with something, at the cost of barring new rows from the live table, but actually, we are already there, so it isn't really much of a cost and allows user to keep adding new candidates somewhere, even if they won't go live right away. [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 20:26, 10 October 2025 (UTC)
:Support -- A good temporary solution. [[User:SuperGrey|'''<span style="color:#765CAE">Super</span><span style="color:#525252">Grey</span>''']] ([[User talk:SuperGrey|talk]]) 20:44, 10 October 2025 (UTC)
:Support implementing emergency procedure if necessary. [[User:CommunityNotesContributor|CNC]] ([[User talk:CommunityNotesContributor|talk]]) 17:28, 13 October 2025 (UTC)

We are pretty much de facto barred from adding new rows to the live table already, because it just squeezes us more and more with desperate measures required to rescue it, taking editor time away from achieving a more lasting solution. I propose that we recognize that we are in a situation where '''no more new rows may be added to the live table''' (meaning, blocking new rows from table chunks */1 through */8). We should at a minimum mention this at [[WP:RSN]], and add a warning advisory at the top of each of the eight table chunks requesting that no new rows be added (although they can tweak existing rows for LAST/staleness, new discussions on existing sources, etc.), and that they add their new row to [[Wikipedia:Reliable sources/Perennial sources/X]] instead. Any objections to implementing this? [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 21:25, 10 October 2025 (UTC)

:Support. [[User:SuperGrey|'''<span style="color:#765CAE">Super</span><span style="color:#525252">Grey</span>''']] ([[User talk:SuperGrey|talk]]) 22:12, 10 October 2025 (UTC)
:You could add a note at [[Wikipedia talk:Reliable sources/Noticeboard#RSP collapsed]]. [[User:WhatamIdoing|WhatamIdoing]] ([[User talk:WhatamIdoing|talk]]) 23:29, 10 October 2025 (UTC)
:: Done. [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 03:58, 11 October 2025 (UTC)

{{itrout|Minnow}} for implementing the notice through dedicated transclusion to every single subpage instead of to [[Wikipedia:Reliable sources/Perennial sources/Header]]. [[User:Aaron Liu|<span class="skin-invert" style="color:#0645ad">Aaron Liu</span>]] ([[User talk:Aaron Liu#top|talk]]) 03:24, 13 October 2025 (UTC)
: Could do, but then you would need special handling for [[Wikipedia:Reliable sources/Perennial sources/X]], either expanding the header and just including the expansion of it without the notice, or else adding a new exclusion param to a header template that has no conditionals or parameters at the moment. Either way works. But I like fish, so it's fine. [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 05:07, 13 October 2025 (UTC)
* Only just seen this topic, I wouldn't of [https://en.wikipedia.org/w/index.php?title=Wikipedia:Reliable_sources/Perennial_sources/6&action=history added] to P6 if I had known. Feel free to revert if needed. [[User:CommunityNotesContributor|CNC]] ([[User talk:CommunityNotesContributor|talk]]) 17:29, 13 October 2025 (UTC)
*: [[User:CommunityNotesContributor]], no worries, your edit had zero effect on [[WP:PEIS|PEIS]], the critical resource which is near capacity right now. And just to be clear: you may continue to add plain-text content to existing rows like RhythmOne ([[WP:ALLMUSIC]]), including more discussion links, longer or modified Summary, updated status, and so on. The only problematic type of edit is adding an entirely new row to the table. Thanks for the heads-up! You can actually help in one way: if you go back to the P6 page, is the banner at the top noticeable, and is the wording clear in meaning? If it isn't, we can change it. [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 19:21, 13 October 2025 (UTC)
*::Strange as I added a new row didn't I, ie a new entry? Looks clear enough though, have also added it to the group editnotice for good measure, so now appear on all /Perennial sources subpages. [https://en.wikipedia.org/w/index.php?title=Template:Editnotices/Group/Wikipedia:Reliable_sources/Perennial_sources&diff=prev&oldid=1316658326] [[User:CommunityNotesContributor|CNC]] ([[User talk:CommunityNotesContributor|talk]]) 19:57, 13 October 2025 (UTC)
*::: Maybe I'm confused, or didn't look far enough in the history.. Oh, I see, I thought we were talking about RhythmOne, but now I see your earlier addition of Popular Mechanics. Well, maybe it shouldn't have been added, but we are still okay on PEIS for the moment (just under 99%), so it can remain for now. For other new rows, though, please use the overflow table, [[Wikipedia:Reliable sources/Perennial sources/X|*/X]]. [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 01:03, 14 October 2025 (UTC)

Given the recent change to [[WP:RSPSHORTCUT]] reducing table PEIS to ~89%, do we want to "unfreeze" the subtable chunks, and remove the [[WP:RSPTableFull]] message? [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 22:20, 18 October 2025 (UTC)