Template talk:Section sizes

Bot proposal
There is a bot proposal to add this template to talk pages. If this is something you would like to have happen, community support for the bot is required. See Wikipedia%3AVillage_pump_%28proposals%29%23Bot_to_add_%7B%7BSection_sizes%7D%7D_to_talk_pages to give support (or not) for the bot. -- Green  C  15:52, 4 January 2019 (UTC)

Requested move 21 April 2019

 * The following is a closed discussion of a requested move. Please do not modify it. Subsequent comments should be made in a new section on the talk page. Editors desiring to contest the closing decision should consider a move review after discussing it on the closer's talk page. No further edits should be made to this section. 

The result of the move request was: Moved. (closed by non-admin page mover)  SITH   (talk)   23:24, 27 April 2019 (UTC)

– Module and template should have the same name. * Pppery * has returned 00:49, 21 April 2019 (UTC)
 * Module:Section size → Module:Section sizes
 * Support per nom. --Gonnym (talk) 10:28, 21 April 2019 (UTC)


 * The above discussion is preserved as an archive of a requested move. Please do not modify it. Subsequent comments should be made in a new section on this talk page or in a move review. No further edits should be made to this section.

Proposal for optional cumulative size column
First of all, this module is great, thanks so much for it. I'd like to propose an extension of functionality that would provide an optional third column, with cumulative roll-up values. I can imagine a simple, and a more-complete version of this, let me start with the simple one. In the third column, for each H2 section, provide the sum of all the values in subsections below it (plus any text unique to it, before the first H3 subsection). This will be very handy for long articles with lots of subsections. The resulting column three will have values in cells that correspond to H2 sections, and the remaining cells will be blank. (Ideally, this value should be in the row where the H2 header is, but if it's easier to add a new row, "Section SectionName totals" after the last section and stick it there, that would be acceptable. In that case, gray it out, or background the row with light gray or something, to set it apart.) In the more complete version, provide the totals for lower values as well, so that you'd have values in the H3 subsection cells corresponding to the sum of all subsections below it, and so on.

All of this should be optional, defaulting to no column three, so it's backward compatible. Here's how I imagine it might look (as called from the template): This would generate a third column, and provide cumulative figures for content under the H2 sections, and the H3 sections. (Articles in principle shouldn't have H1 sections, but I've seen them on some WikiProject pages, and a robust program should test for that case and at least not bomb; either rejecting the value, or processing it anyway and providing the correct figures.)

Here's an example of a real-world article, where these values would be really helpful: Military history of France during World War II. I'm trying to figure out about how to split and merge that article, and the cume figures would help me out a lot. (It would also make a great test page for the sandbox version. )

Thanks, Mathglot (talk) 03:30, 16 July 2020 (UTC)


 * Great idea! This would be very useful. --Ita140188 (talk) 04:54, 6 October 2020 (UTC)


 * I agree that accumulative values for subsections would be very useful. &middot; &middot; &middot; Peter Southwood (talk): 17:34, 12 November 2020 (UTC)


 * I have modified the code and included a cumulative size column. You can check an example below. The modified code is at Module:Sandbox/Ita140188/Section sizes. Let me know what you think. --Ita140188 (talk) 11:48, 11 December 2020 (UTC)
 * Pinging interested users: . --Ita140188 (talk) 11:52, 11 December 2020 (UTC)


 * I modified the example with the page suggested above, and collapsible for readability --Ita140188 (talk) 13:57, 11 December 2020 (UTC)


 * Seems to do what it says on the box. Should work for my needs. Nice. (Have not checked every detail, but what I looked at looks fine) &middot; &middot; &middot; Peter Southwood (talk): 12:47, 11 December 2020 (UTC)


 * , That looks good! Can we lighten (or blank) leaf-nodes in the cume column, in order to make the actual cume figures stand out more? SOmething like this:


 * P.S. This is a tiny change, but still my first-ever attempt at Lua coding, so please look it over carefully. Mathglot (talk) 19:52, 11 December 2020 (UTC)
 * So, that seems to have worked, but two further tweaks targeting just the style of top level section cume figures (i.e., only the H2's) did not work :-( . Can you look at my code (here, lines 171-173) and tell me why not? Thanks! Mathglot (talk) 20:20, 11 December 2020 (UTC)
 * [ec], in principle I like the change, but the grey is almost illegible to me, and there may be more than one level of cumulative size, when there are level 4 or 5 subsections. &middot; &middot; &middot; Peter Southwood (talk): 20:24, 11 December 2020 (UTC)
 * Illegible is kind of the point; I was actually going for blanking it (which would be just as easy). What I'm trying to figure out additionally, and could not so far, is how to bold (or background-color) *just* the cume figures for the top level sections. So, we'd end up with (let's say) boldface for just the H2 sections (there are only ten of them, in that 196-section article), all the leafs (bottom-level sections not containing other sections) would be either blanked in the cume column, or very faded, and all the other cume figures (non-leafs) would be standard-weight typeface. That was my idea, and I think would make it easier to interpret the cume column. My example does the first half of it, but not the second. I could mock up a small example, if my explanation isn't clear. Mathglot (talk) 20:32, 11 December 2020 (UTC)
 * I blanked the non-leafs (the values are actually still there, but match the background, so not visible). Mathglot (talk) 20:49, 11 December 2020 (UTC)
 * In principle I would be ok with changing font style depending on the depth of section level. However, as mentioned, we should have a different style for each level, which seems clumsy. On the other hand, I am definitely against blanking. There is no reason to remove information that may be useful to some. Keeping even the last level allows to compare to other levels when sorting. --Ita140188 (talk) 02:45, 12 December 2020 (UTC)
 * Actually, I was going to recommend you remove the sorting, as sorting a hierarchy destroys it and becomes meaningless and makes them incomparable. Unless you want to do "clever sorting" which really only sorts the H2's, and preserves the hierarchy underneath; that would be nice. Why are you against blanking? What do you learn from seeing the identical value in columns 2 and 3? Printing duplicate values merely clutters the third column, and makes it harder to find the actual summary figures. Mathglot (talk) 03:01, 12 December 2020 (UTC)
 * I am trying to look at how I would use this table. Knowing how it would be used would suggest how it should be displayed.
 * To see the most effective ways to split an excessively long article. (Cumulative count very useful, comparative sizes useful, so sorting potentially useful)
 * To see which sections might be split into smaller sections or subsections within the existing article to reduce walls of text, or combined, to reduce unnecessary fragmentation and toc complexity. (cumulative count not so useful)
 * Other uses? &middot; &middot; &middot; Peter Southwood (talk): 04:40, 12 December 2020 (UTC)
 * Possibly display as a set of columns with only the cumulative values for a specific level in each. Something like :
 * col 1: the headers, indented as usual to indicate level
 * col 2: level 2 cumulative coumts
 * col 3: level 3 cumulative counts, if there are any.
 * col 4: level 4 cc, etc. recursively
 * would sorting still be meaningful with this? &middot; &middot; &middot; Peter Southwood (talk): 05:03, 12 December 2020 (UTC)
 * another column for local count. could be col 0, col 1.1, or col n+1 &middot; &middot; &middot; Peter Southwood (talk): 05:13, 12 December 2020 (UTC)

I might use it for judging article splits, but also to judge the overall section organization of the article to see if it's organized properly, and to check not only for article splits, but section splits (or merges), section moves, verifying or adjusting the WP:DUE WEIGHTiness of sections with respect to each other, and with respect to the number of sources available for each of the subtopics, and also to compare it with foreign articles on the same article topic to see how they section their articles, how it compares to ours, and again whether the weight of individual subtopics seem right.

I don't see a need for multiple columns for different levels, but that said, a mockup is worth a thousand words. I've only literally just started with Lua, and though it sounds like a really fun challenge, that might be a stretch for me at this point, or even if I could manage it, it would take too much time away from my never-ending backlog of things on my queue, here, so I'll probably have to demur on that one.

I bet if I sleep on it, I'll come up with more use cases for the section size list. Oh,, I did want to ask you: don't you find the second one, with the sparse third column much easier to read than the other one? I find the top one with every cell in the column filled in, makes it hard to find which cells are actually subtotals, which sort of defeats the purpose of having it. Mathglot (talk) 08:02, 12 December 2020 (UTC)


 * Listed at: Wikipedia talk:WikiProject Templates Mathglot (talk) 08:30, 12 December 2020 (UTC)
 * Listed at: Village pump (proposals) Mathglot (talk) 08:30, 12 December 2020 (UTC)


 * Mathglot@undefined, either of the currently working versions is an improvement, and I can easily live with either, considering it is not a thing I would use every day. I take your point on the extra work of going for perfect when we have good enough, and agree that the sparse final column is easier to read. Better blank/invisible than illegible but visible. The data is anyway there in the previous column, and there is no need to duplicate it. My proposal with multiple columns is just taking that philosophy a step further and making it more obvious which are subtotals of what. Also there is no great rush, and putting the current improvements into service might bring out further useful suggestions. I would leave the sorting option in for now. See if it is useful in practice. Cheers, &middot; &middot; &middot; Peter Southwood (talk): 09:14, 12 December 2020 (UTC)


 * I propose a compromise solution: have the cumulative count of main sections in bold, keep a normal font for subsections that have further subsubsections, and leave subsections without any sub-subsection blank. All this while keeping the table sortable (which is very useful for long articles in my opinion). What do you think? I will try to prepare an example soon. --Ita140188 (talk) 09:22, 12 December 2020 (UTC)


 * [ec] I think it would cover most cases well and the remainder well enough. &middot; &middot; &middot; Peter Southwood (talk): 09:52, 12 December 2020 (UTC)


 * That sounds good to me (except for the sort part; but I can always just not click the header ). The only other thing I'd mention, is whether we need to maintain backwards compatibility in order to retain a 2-column table with no cumulative totals, unless requested by a new param. I've listed the discussion, so we may get some more input on that point.
 * Oh,, can you help me figure out why my boldface change didn't work? I couldn't figure out what was wrong with my edit that failed to bold the cume totals for level 2--can you have a look at rev. 993658293 lines 171-172 of Module:Sandbox/Mathglot/Section sizes, and see if you can see what's wrong with it? Feel free to reinstate that version, if you want to play with it. Thanks, Mathglot (talk) 09:46, 12 December 2020 (UTC)
 * Fixed --Ita140188 (talk) 10:30, 12 December 2020 (UTC)
 * In what cases might retaining a 2 col table with no cumulative totals be preferable?
 * How much additional work and complexity would retaining 2 col no cumulative totals require?
 * Personal opinion: would not matter to me at all. &middot; &middot; &middot; Peter Southwood (talk): 15:28, 12 December 2020 (UTC)
 * , you may be right; I suppose it's just a general philosophy wrt programming, in that you don't "fix" something that isn't broke, and those that are happy with it the old way, won't say anything here, until we change something in the way they're used to seeing in, and will then squawk, "There was nothing wrong with it before!" (Although this isn't respected as much as it used to be.) Who knows, maybe an extra column will screw up on mobile devices with narrower viewports; you never know.  I guess it's just my general principles of wanting to add an enhancement, without upsetting existing users. (I think it's possible to test for mobile platform, and we could skip the additional column in that case, if that were advisable.) Mathglot (talk) 21:04, 12 December 2020 (UTC)
 * So, I checked it out using WP:Mobile view sidebar, and sure enough, it's not optimal. It's not a disaster, i.e., there aren't horrible folded lines making inscrutable row content; it's just that the third column is mostly clipped. But having it as an optional param when invoking the template (or if not optional, suppressed for mobile) would be an improvement. If added, imho this code should go in the template code, not the module code. Mathglot (talk) 01:42, 13 December 2020 (UTC)


 * I updated my version of the module with the new proposal. Let me know what you think. --Ita140188 (talk) 13:02, 13 December 2020 (UTC)


 * , it looks great! One tiny quibble: because the column header 'Cumulative' is longer than the data values in the column, the values end up with lots of leading white space, which doesn't matter on a wide device, but cume values are not visible in some mobile devices (i.e., mine ). I copied your version 993958501‎ and shortened the header (see diff between our two versions). See what you think (check also on a narrow mobile device, if possible). And thanks so much for all your work on this! (I still don't understand some of the Lua errors I got during some of my tweaks; is there a board somewhere, where new Lua editors can get help?) Thanks, Mathglot (talk) 21:36, 13 December 2020 (UTC)
 * , One further observation: In articles with list defined references, the references section can easily be the largest, sometimes by quite a margin. I am not convinced that using the red colour code for that section is the best use of a limited resource. What do you think? &middot; &middot; &middot; Peter Southwood (talk): 15:42, 15 December 2020 (UTC)
 * Considering that list defined references are quite rare (at least in my experience), I think it's not worth it to change the code for this case. Also, by sorting the table it is easy to check which section is the next largest. --Ita140188 (talk) 15:49, 15 December 2020 (UTC)
 * I find them fairly common, though I have never done a comparison. Does the count include refs defined in the section or other wikicode? Just rendered text? &middot; &middot; &middot; Peter Southwood (talk): 15:58, 15 December 2020 (UTC)
 * It counts the source (any wikicode) size (in bytes). It's equivalent to the text you would see when you open the section in "Edit source". Can you cite an example of an article using list defined refs just to understand how it would look like with the new module? (by the way, this problem would also apply to the current module) --Ita140188 (talk) 16:21, 15 December 2020 (UTC)

Deciding on consensus
More comments would be good, especially regarding the question of making the new functionality the default, or making it subject to a parameter but if nothing is forthcoming in several days, shall we just move the latest version to live? Mathglot (talk) 01:14, 14 December 2020 (UTC)


 * I support making the new version live. Maybe after testing on some edge cases. For example, in my version there is a maximum depth of sections allowed, and it would not manage higher sections (those with 1 "="), which however I think should not be used in any case. If proved to work well, it only adds functionality and I think most people would find it very useful. For those who don't, it probably does not make much difference. --Ita140188 (talk) 03:22, 14 December 2020 (UTC)
 * I just checked (User:Ita140188/sandbox2). Level 1 sections (which should not be used) are ignored. Sections higher than 6 are actually ignored by Wikipedia anyway (the extra "=" become part of the section title), so they are not a problem. --Ita140188 (talk) 03:27, 14 December 2020 (UTC)
 * If no-one objects within a week, I suggest go live. If that does not draw fire within a few days it will probably be no problem longer term. It will probably never be noticed by most. I am keen to start using it. Cheers, &middot; &middot; &middot; Peter Southwood (talk): 16:49, 15 December 2020 (UTC)
 * I did a WP:BOLD move and updated the module. If there are any problems we can always revert. --Ita140188 (talk) 01:30, 17 December 2020 (UTC)
 * That seems fine; let's all keep this on our watchlists, just in case. And thanks, all. One last question for Ita: is there a board or project page somewhere for new Lua users to ask questions? This was my first experience with it; I clearly have a long way to go, but other o-o languages make it seem not that strange, so I probably just need to get used to it. Mathglot (talk) 23:20, 18 December 2020 (UTC)
 * I am not sure, I also just started programming in Lua. I have learnt by trial and error by myself. My only previous experience was an update to the chart module that was rejected: Module:Sandbox/Ita140188/chart2. In any case, if you have some problems maybe I can help (at least I can try!). --Ita140188 (talk) 11:24, 20 December 2020 (UTC)

Prose size
Hello, just found this great tool. From what I understand (please correct if wrong), it is measuring the total byte size within each section. Would it be possible for it to also assess the prose size too, similarly to what Prosesize does for the whole page? Best, CMD (talk) 09:27, 25 January 2021 (UTC)


 * You are correct, the tool measure the total byte size (source code) of each section. I am not sure how easy it would be to incorporate the prose size calculation, it seems that the JS code should be rewritten in Lua. It may be worth it if enough users think it would be useful. --Ita140188 (talk) 10:38, 25 January 2021 (UTC)
 * @Ita140188 second vote here! There's discussion here about section sizes Wikipedia_talk:Article_size, and the limits have been changed from kb to words so should prove useful, Tom B (talk) 18:20, 28 November 2023 (UTC)
 * Agreeing with the above, a word count tool per section would be incredibly valuable. —Femke 🐦 (talk) 16:14, 24 April 2024 (UTC)

Red formatting?
Just came over from Talk:COVID-19 pandemic in Australia after seeing this template; it would have saved me so much time when showing PEIS results! The documentation seems to be lacking; I see that some numbers are formatted in red, which I presume to be past a size of concern. When does the formatting occur? — Tenryuu 🐲 ( 💬 • 📝 ) 14:45, 11 June 2021 (UTC)
 * From Module:Section sizes:
 * This module creates a wikitable that lists each section in a page along with that section's size in bytes. Each section is wikilinked to its target in the page; subsections are indented; largest section's byte-count is highlighted in red.
 * —Trappist the monk (talk) 14:48, 11 June 2021 (UTC)
 * Many thanks, ! Would there be any objection to me adding this information to the template's documentation? — Tenryuu 🐲 ( 💬 • 📝 ) 14:52, 11 June 2021 (UTC)
 * I cannot image why anyone would object to any improvements to template documentation.
 * —Trappist the monk (talk) 15:29, 11 June 2021 (UTC)

Section headers with embedded anchors
There may be a problem parsing section names that have permitted embedded anchors (guessing ~l.95 or l.105). The only example I have for sure is section LGBT, which contains the following code:

The manifestation of the problem that I see, is in the invocation of section sizes at Talk:LGBT, where the section header "Criticism of the term" is not wikilinked, and also has some code-cruft in it.

See also MOS:SECTIONSTYLE for additional examples of permissible embedded items inside section headers; not sure if the code presently handles these or not. Mathglot (talk) 03:44, 25 July 2021 (UTC)


 * Hitting the same issue at Talk:Rebreather_diving. Not a crisis, just thought I would mention it. &middot; &middot; &middot; Peter Southwood (talk): 16:03, 14 December 2021 (UTC)
 * @Mathglot, @Pbsouthwood: Fixed this issue (Special:Diff/1135136755). However, the fix removes anything anywhere between < & >, and there might be use cases where actual content is added inside < & >, so let me know if it is a huge issue that affects the module's usability. I asked for assistance at WP:VPT too, in case anyone can help. &#8212;CX Zoom[he/him] (let's talk • {C•X}) 21:30, 22 January 2023 (UTC)
 * The issue with Talk:LGBT is fixed, thanks very much for this update. Mathglot (talk) 22:15, 22 January 2023 (UTC)

There is a related issue at articles with section headers with embedded anchors via templates Anchor or Vanchor. Guessing we need a new sub remove_anchor that does something similar to the existing one for &lt; .. &gt;. Live example at Talk:Glossary of French criminal law. Included here for the record, but definitely *not* a huge issue; occurs rarely, afaict. Mathglot (talk) 23:03, 6 February 2023 (UTC)


 * @Mathglot: I couldn't understand what is the happening here. It looks working as intended? &#8212;CX Zoom[he/him] (let's talk • {C•X}) 10:35, 8 February 2023 (UTC)
 * Things changed since I wrote that. Sorry for wasting your time, it is indeed working as intended now, because someone went through the glossary after I posted above, and removed twenty section headers, including the ones causing the problems. When I get back to that article, I will replace the section headers again, and I'll ping you at that point. Or if you are able to point the tool at a copy of the article in a sandbox, try it with revision 1137940642‎. Thanks for checking. Mathglot (talk) 18:23, 8 February 2023 (UTC)

Should work transparently in Draft or Main space
The template should work, regardless whether it sits in Draft space or in Main space. For the time being, I am using this workaround on the Talk page of Draft articles:

which worked fine at Draft talk:List of scandals in Brazil, and now works seamlessly in Main. (And yes, I'll fix it after a while.) Mathglot (talk) 20:25, 2 March 2023 (UTC)


 * I agree, no idea why this hadn't been done before. In fact, this should work anywhere, including project pages and discussion boards. So, I changed BASEPAGENAME to SUBJECTPAGENAME. Cheers! &#8212;CX Zoom[he/him] (let's talk • {C•X}) 18:04, 3 March 2023 (UTC)

Purpose and design questions
What is the purpose of of adding section size to random articles? Who made this template, why is it not counting actual prose size and who decides the color coding? Peter Isotalo 07:24, 21 September 2023 (UTC)


 * The purpose is to have an overview of how large the sections are. This can help in reorganizing articles, for example. For the prose size, there was a proposal Template_talk:Section_sizes but since this seems to be quite complex to do, and there was no other evidence of support, it has not been implemented. As for who made the template and who decided the colors, you can check the template history and this talk page. You can add here your suggestions if you have any. --Ita140188 (talk) 07:54, 21 September 2023 (UTC)


 * I think two things are pretty essential:
 * The go-to standard for article size discussions has been prose size for I don't know how long now. All guidelines are written in terms of prose size. I personally think that section size is a far more relevant measurement than total article size, but if it's not expressed as readable prose, this template can be very difficult to interpret properly.
 * Don't apply any color markings. We have a some rough guidelines regarding total article size but nothing about how large sections should be. I'm guessing there's a de facto 2-4 paragraph limit that most of us try to adhere to, but total prose size can still vary quite a lot within that that 2-4 paragraph span. A paragraph is not automatically worse the more words it contains. I could just as well argue that stubby 1-2 sentence paragraphs are just as bad. Also, an L2 heading with just text content directly under it shouldn't be counted the same as an L2 with an extensive structure of L3 or L4 headings.


 * I am all for recommendations on section size, but only if it's done through appropriate guidelines, like WP:SIZE or the likes. Until there's some sort of consensus about this, I don't think it's appropriate that this template should be added to articles only be involved editors.
 * Peter Isotalo 13:34, 21 September 2023 (UTC)
 * This template is not trying to set any limits or guidelines for sections sizes. Also, the colors are just shades of red depending on the relative size of sections in the article to make the table more legible (not based on some absolute number and not giving any "judgment"). As for prose size, I agree it would be nicer, but somebody needs to put the work to make it happen. I briefly looked into it and thought it would take quite a long time to implement in a robust way. I don't have time now, but if you do please go ahead. Ita140188 (talk) 15:16, 21 September 2023 (UTC)
 * Red is not a neutral color for this purpose and is one of the reasons I reverted the addition of the template to talk:galley. You should keep in mind that there's a context of disagreement on article size withing the project. The WP:SIZE limitations are interpreted somewhat differently as is, and the figures themselves are based on 20 year old consensus guesstimates without any kind of basis in research on Wikipedia reader behavior.
 * Peter Isotalo 15:49, 21 September 2023 (UTC)
 * You are free to propose a more "neutral" color. Maybe blue? As for the disagreement on the optimal size and relative debate, again, this template has nothing to do with it as it does not imply any limit or judgement on what the optimal size of sections should be. Ita140188 (talk) 17:25, 21 September 2023 (UTC)

Error
Why in Village pump (proposals), we have this error: Wikipedia:Village pump (proposals) is a redirect, as this page is not a redirect or other means. Just a random Wikipedian (talk) 10:19, 29 September 2023 (UTC)
 * Because has the plain text   (3×).  The module should probably not be looking for that text and should instead rely on the title object property.
 * —Trappist the monk (talk) 12:16, 29 September 2023 (UTC)
 * How about to do that (#isredirect thing?) Just a random Wikipedian (talk) 13:10, 30 September 2023 (UTC)

Script error at Talk:Food security
This template causes an error, at Talk:Food security. I added a test case to the test cases page. I have not done any troubleshooting. – Jonesey95 (talk) 20:48, 9 May 2024 (UTC)
 * This was caused by a series of "=" in a commented section, creating no-title "sections". I suggest a fix to ignore "sections" with empty title, which are likely just a string of repeating "=". A more complex solution would be to ignore comments, but this would need a way to check for it which would likely add more failure modes. --Ita140188 (talk) 09:18, 14 May 2024 (UTC)

Error
Please fix error on Talk:Puerto Rico caused by this template &mdash; Martin (MSGJ · talk) 10:48, 13 June 2024 (UTC)
 * Done. --Ita140188 (talk) 20:30, 13 June 2024 (UTC)

VPT is not a redirext
At WT:VPT, expanding the "Section sizes in Wikipedia:Village pump (technical)" box reveals a red error message " error: Wikipedia:Village pump (technical) is a redirect ", which is not true - try following Village pump (technical): it's a direct link. I've traced false error as far as the call  but no further, as Module:Section sizes is in Lua. -- Red rose64 &#x1f339; (talk) 19:19, 29 June 2024 (UTC)
 * The error occurs because of this code (permalink) in Module:Section sizes and because the specified string occurs in this post (permalink) at WP:VPT.
 * Unless someone beats me to it, I'll fix the code later today.
 * —Trappist the monk (talk) 19:38, 29 June 2024 (UTC)
 * So it's my fault... -- Red rose64 &#x1f339; (talk) 20:42, 29 June 2024 (UTC)
 * Your words, not mine.
 * Fixed.
 * —Trappist the monk (talk) 22:09, 29 June 2024 (UTC)
 * Fixed.
 * —Trappist the monk (talk) 22:09, 29 June 2024 (UTC)

A parameter for individual revisions?
This could be useful for comparing and contrasting different revisions' section sizes. PBZE (talk) 21:07, 18 July 2024 (UTC)
 * Not possible. Scributo cannot get the content from pages in the Special: namespace (Special:Permalink/oldid).
 * —Trappist the monk (talk) 14:15, 19 July 2024 (UTC)