Jump to content

Template talk:Section sizes

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

Bot proposal

[edit]

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:Village_pump_(proposals)#Bot_to_add_{{Section_sizes}}_to_talk_pages to give support (or not) for the bot. -- GreenC 15:52, 4 January 2019 (UTC)[reply]

Requested move 21 April 2019

[edit]
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)[reply]



– Module and template should have the same name. * Pppery * has returned 00:49, 21 April 2019 (UTC)[reply]


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

[edit]

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, (please Reply to icon mention me on reply; thanks!) Mathglot (talk) 03:30, 16 July 2020 (UTC)[reply]

@Mathglot: Great idea! This would be very useful. --Ita140188 (talk) 04:54, 6 October 2020 (UTC)[reply]
I agree that accumulative values for subsections would be very useful. · · · Peter Southwood (talk): 17:34, 12 November 2020 (UTC)[reply]
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)[reply]
Pinging interested users: Mathglot Pbsouthwood. --Ita140188 (talk) 11:52, 11 December 2020 (UTC)[reply]
I modified the example with the page suggested above, and collapsible for readability --Ita140188 (talk) 13:57, 11 December 2020 (UTC)[reply]
  • @Ita140188 and Pbsouthwood:, 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:
Section sizes in Military history of France during World War II (modified)
Section size for Military history of France during World War II (185 sections)
Section name Byte count Cume
_LEAD_ 5,040 5,040
Military forces 9,886 9,886
Free French Forces (1940–1945) 906 13,466
De Gaulle's appeals on the BBC (June 1940) 1,298 1,298
French SAS (1942–1945) 1,017 1,017
Composition (1940–1945) 835 835
French Expeditionary Corps (1943–1944) 540 2,434
Free French Forces and Army of Africa (August 1, 1943) 1,894 1,894
Far East French Expeditionary Forces (1943–1945) 1,496 2,110
Gaurs and CLI commandos (1943–1945) 614 614
Allied munitions (1942–1945) 58 2,798
British support 749 749
US support 1,991 1,991
Units and commands on 8 May 1945 2,068 2,068
Vichy France (1940–1944) 32 11,956
Armistice Army (1940–1944) 1,081 1,081
French State Navy (1940–1944) 115 115
French State Air Force (1940–1944) 139 139
Legion of French Volunteers 35 1,962
French Legion of Fighters 510 510
Legion of French Volunteers against Bolshevism 1,147 1,147
Tricolore Legion (1941–1942) 270 270
French Milice (1943–44) 1,567 1,567
Vichy French Paramilitary Forces (1940–1944) 905 4,822
French Youth Workings (1940–1944) 2,475 2,475
Reserve Mobile Group (1941–1944) 550 550
French Gestapo (1941–1944) 892 892
French SS (1942–1945) 374 1,302
8th Sturmbrigade SS Frankreich (1943–44) 299 299
33rd Waffen Grenadier Division of the SS Charlemagne (1943–1945) 629 629
The African Phalange (1942–43) 601 601
North-African Legion (1944) 335 335
French Resistance (1940–1945) 234 1,395
Resistance groups (1940–1945) 1,161 1,161
French colonial empire (1940–1945) 156 7,995
Struggle for the colonies 2,119 2,119
Army of Africa (1942–1943) 1,784 1,784
Operation Torch aftermath 403 403
Axis retaliations (1942–1943) 545 545
Free French colonies 277 277
Vichy French colonies 464 464
Allied angary (1940) 442 1,823
Operation Catapult and Lend-Lease 787 787
British capture 594 594
Axis requisition (1940–1945) 424 424
Theatres of World War II 30 138,178
European 58 76,207
Phoney War (1939) 1,299 1,299
Battle of Belgium (10–28 May 1940) 617 617
Battle of the Netherlands (10–14 May 1940) 206 206
Battle of France (10 May – 25 June 1940) 78 30,092
Prelude 4,294 4,294
Campaign in the Low Countries and northern France 3,261 3,261
German breakthrough 5,794 5,794
Allied reaction 4,469 4,469
Channel attacks, battle of Dunkirk, and the Weygand Plan (17–28 May) 6,398 6,398
Allied evacuations (26 May – 25 June) 1,386 1,386
British retreat, French defeat (5–10 June 1940) 1,498 1,498
Italy's declaration of war, French-Italian air battles, UK ends French support (10–11 June 1940) 2,039 2,039
French-German negotiations, Pétain's appeal (16–17 June) 875 875
Italian invasion of France (20–22 June) 89 89
French–German and French–Italian armistices (22 June 1940) 775 2,239
Nazi occupation, Vichy France, and Armistice Army 689 689
Formation of Free France and the French Resistance 775 775
Free French airmen in RAF (June 1940–1945) 463 3,490
Free French pilots in the battle of Britain (10 July – 31 October 1940) 2,313 2,313
All-Free French RAF Squadrons (1941–1945) 648 648
Battle of Dieppe (19 August 1942) 66 66
French on the Eastern front (1941–1945) 51 6,348
Legion of French Volunteers Against Bolshevism (1941–1943) 2,123 2,123
Vichy French Sturmbataillon Charlemagne last defenders of Berlin (April–May 1945) 480 480
Free French Normandie-Niemen (1942–1945) 3,694 3,694
Maquis du Limousin (June 1942 – August 1944) 84 84
Italian campaign (1943–1944) 213 4,141
French Expeditionary Corps 566 566
Bernhardt Line (1 December 1943 – 15 January 1944) 481 481
Battle of Monte Cassino (17 January – 18 May 1944) 517 517
Operation Diadem (May 1944) 1,704 1,704
Operation Brassard (17–18 June 1944) 660 660
France maquis warfare (January–July 1944) 53 886
Battle of Vercors (January–July) 312 312
Battle of Glières (30 January – 26 March) 85 85
Battle of Mont Mouchet (20 May – 22 June) 87 87
Battle of Saint-Marcel (18 June) 76 76
Battle of Mont Gargan (18–24 July) 273 273
Campaign of France (1944–1945) 549 23,154
French SAS Brittany airborne landings (5–18 June 1944) 70 1,859
Operation Samwest (5–9 June) 1,552 1,552
Operation Dingson (5–18 June) 172 172
Operation Cooney (7 June) 65 65
Free French contribution to the Normandy naval landings (June 1944) 81 5,267
French contribution on D-Day 644 644
The first to touch the ground of France 1,585 1,585
Free French naval operations (3–16 June) 2,084 2,084
All-Free French air force operations 873 873
Leclerc's 2nd Armoured Division (August 1944 – January 1945) 416 3,391
Battle for Normandy (July 1944) 859 859
Liberation of Paris (24–25 August 1944) 1,075 1,075
Lorraine Campaign, Liberation of Strasbourg (1944 – January 1945) 1,041 1,041
Liberation of southern France (June–August 1944) 62 11,295
Operation Jedburgh (June) 595 595
Battle for Provence (August) 6,197 6,197
Operation Romeo (15 August 1944) 286 286
Liberation of Toulon and Marseilles 4,155 4,155
Liberation of north-eastern France (September 1944 – March 1945) 793 793
Western Allied invasion of Germany (1945) 95 2,084
First French Army in west Germany (March–April 1945) 597 597
Normandie-Niemen air raids over Königsberg (April 1945) 705 705
Free French Division Leclerc at Berchtesgaden (4 May 1945) 376 376
French Army of Africa's 7e RCA at Württemberg (1945) 311 311
Campaign of the Netherlands (1945) 44 941
French SAS Operation Amherst (7–8 April 1945) 897 897
Liberation of Belgium 31 479
Battle of the Bulge (1944–1945) 448 448
English Channel and North Sea 37 4,921
"British treachery" over Free French navy (3 July – 31 August 1940) 4,884 4,884
Atlantic 480 2,069
Battle of the Atlantic 305 305
Last battle of the battleship Bismarck (26–27 May 1941) 269 269
Free French rescue of British Convoy HG-75 (24 October 1941) 883 883
Laconia incident (12 September 1942) 132 132
Mediterranean, Middle East, and African 287 6,972
Naval battle of the Mediterranean (1940–1945) 801 801
Naval battle of Mers El Kébir (3 July 1940) 2,004 2,004
Sabotage operation in Greece (12–13 June 1942) 1,799 1,799
Scuttling of the French fleet in Toulon (27 November 1942) 333 333
Allied invasion of Sicily (9 July – 17 August 1943) 1,064 1,064
Liberation of Corsica (September–October 1943) 684 684
African 15 31,800
West African campaign 33 11,080
Battle of Dakar (23–25 September 1940) 4,612 4,612
Battle of Gabon (8–10 November 1940) 6,435 6,435
East African Campaign 2,233 2,957
Eithrea–Ethiopia campaign (1941) 460 724
Battle of Keren (3 February – 1 April 1941) 264 264
North African campaign and Desert War 883 17,748
North African Free French Air Force (July 1940 – 1945) 1,114 1,114
French Morocco-Algeria campaign (1942) 52 6,670
Coup of Casablanca (7 November) 588 588
Allied invasion of French Morocco 99 99
Naval battle of Casablanca (8–16 November) 96 96
Battle of Port Lyautey (8–12 November) 4,717 4,717
Coup of Algiers 1,050 1,050
Allied invasion of Oran 68 68
French Tunisia campaign (1942–1943) 840 1,402
Run for Tunis (10 November – 25 December 1942) 85 85
Battle of the Kasserine Pass (19–25 February 1943) 106 106
Battle of Medenine (6 March 1943) 75 75
Operation Pugilist (16–27 March 1943) 296 296
Libya campaign 26 7,338
Battle of Kufra (31 January – 1 March 1941) 5,051 5,051
Battle of Gazala (26 May – 21 June 1942) 82 82
Battle of Bir Hakeim (26 May – 11 June 1942) 2,179 2,179
Egypt campaign 26 341
Italian invasion of British Egypt (9–16 September 1940) 108 108
Operation Compass (8 December 1940 – 9 February 1941) 96 96
Second Battle of El Alamein (23 October – 5 November 1942) 111 111
Middle East 49 3,660
French Syria–Lebanon Campaign (1941) 596 2,715
Battle of the Litani River (9 June) 83 83
Battle of Jezzine (13 June) 73 73
Battle of Kissoué (15–17 June) 1,583 1,583
Battle of Damascus (18–21 June) 82 82
Battle of Merdjayoun (19–24 June) 77 77
Battle of Palmyra (1 July) 72 72
Battle of Deir ez-Zor (3 July) 80 80
Battle of Damour (5–9 July) 69 69
Syrian Crisis (May–June 1945) 896 896
Indian Ocean 20 6,347
Allies invade French Madagascar (5 May – 8 November 1942) 4,339 4,339
Battle for La Réunion (22 November 1942) 1,988 1,988
South-East Asian 24 6,172
Vietnam–Laos–Cambodia campaign 46 5,930
Japan invades French Indochina (September 1940) 229 229
Limited Allied support to French Indochina (1943–1945) 1,688 1,688
SOE's French Indochina Section (1943–1945) 3,843 3,843
Japanese coup d'état in French Indochina (9 March – 26 August 1945) 124 124
Thailand campaign 27 218
Thai invasion of French Indochina (October 1940 – 9 May 1941) 100 100
Naval battle of Koh Chang (16–17 January 1941) 91 91
See also 359 359
Notes 24 24
Footnotes 849 849
Further reading 2,475 4,016
Primary sources 1,541 1,541
Total 193,164 193,164
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)[reply]
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)[reply]
[ec] Mathglot, 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. · · · Peter Southwood (talk): 20:24, 11 December 2020 (UTC)[reply]
@Pbsouthwood: 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)[reply]
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)[reply]
In principle I would be ok with changing font style depending on the depth of section level. However, as Pbsouthwood 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)[reply]
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)[reply]
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.
  1. To see the most effective ways to split an excessively long article. (Cumulative count very useful, comparative sizes useful, so sorting potentially useful)
  2. 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)
  3. Other uses? · · · Peter Southwood (talk): 04:40, 12 December 2020 (UTC)[reply]
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? · · · Peter Southwood (talk): 05:03, 12 December 2020 (UTC)[reply]
another column for local count. could be col 0, col 1.1, or col n+1 · · · Peter Southwood (talk): 05:13, 12 December 2020 (UTC)[reply]

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, @Pbsouthwood:, 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)[reply]

Mathglot@, 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, · · · Peter Southwood (talk): 09:14, 12 December 2020 (UTC)[reply]
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)[reply]
[ec] Ita140188 I think it would cover most cases well and the remainder well enough. · · · Peter Southwood (talk): 09:52, 12 December 2020 (UTC)[reply]
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, Ita140188, 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)[reply]
Fixed --Ita140188 (talk) 10:30, 12 December 2020 (UTC)[reply]
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. · · · Peter Southwood (talk): 15:28, 12 December 2020 (UTC)[reply]
@Pbsouthwood:, 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)[reply]
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)[reply]
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)[reply]
@Ita140188:, 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)[reply]
@Ita140188 and Mathglot:, 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? · · · Peter Southwood (talk): 15:42, 15 December 2020 (UTC)[reply]
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)[reply]
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? · · · Peter Southwood (talk): 15:58, 15 December 2020 (UTC)[reply]
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)[reply]

Deciding on consensus

[edit]

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)[reply]

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)[reply]
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)[reply]
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, · · · Peter Southwood (talk): 16:49, 15 December 2020 (UTC)[reply]
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)[reply]
@Ita140188 and Pbsouthwood: 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)[reply]
@Mathglot: 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)[reply]

Prose size

[edit]

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 Wikipedia:Prosesize does for the whole page? Best, CMD (talk) 09:27, 25 January 2021 (UTC)[reply]

@Chipmunkdavis: 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)[reply]
@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)[reply]
Agreeing with the above, a word count tool per section would be incredibly valuable. —Femke 🐦 (talk) 16:14, 24 April 2024 (UTC)[reply]

Red formatting?

[edit]

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)[reply]

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)[reply]
Many thanks, Trappist the monk! Would there be any objection to me adding this information to the template's documentation? —Tenryuu 🐲 ( 💬 • 📝 ) 14:52, 11 June 2021 (UTC)[reply]
I cannot image why anyone would object to any improvements to template documentation.
Trappist the monk (talk) 15:29, 11 June 2021 (UTC)[reply]

Section headers with embedded anchors

[edit]

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#Criticism of the term, which contains the following code:

== <span class="anchor" id="Criticism"></span> Criticism of the term ==

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)[reply]

Hitting the same issue at Talk:Rebreather_diving. Not a crisis, just thought I would mention it. · · · Peter Southwood (talk): 16:03, 14 December 2021 (UTC)[reply]
@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. CX Zoom[he/him] (let's talk • {CX}) 21:30, 22 January 2023 (UTC)[reply]
The issue with Talk:LGBT is fixed, thanks very much for this update. Mathglot (talk) 22:15, 22 January 2023 (UTC)[reply]

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 < .. >. 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)[reply]

@Mathglot: I couldn't understand what is the happening here. It looks working as intended? CX Zoom[he/him] (let's talk • {CX}) 10:35, 8 February 2023 (UTC)[reply]
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)[reply]

Should work transparently in Draft or Main space

[edit]

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:

{{section sizes|{{#ifeq:{{NAMESPACE}}|{{ns:Draft talk}}|Draft:|}}Name_of_the_Article}}

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)[reply]

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! CX Zoom[he/him] (let's talk • {CX}) 18:04, 3 March 2023 (UTC)[reply]

Purpose and design questions

[edit]

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)[reply]

@Peter Isotalo: 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#Prose_size 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)[reply]
@Ita140188: 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)[reply]
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)[reply]
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)[reply]
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)[reply]

Error

[edit]

Why in Wikipedia: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)[reply]

Because Wikipedia:Village pump (proposals) § Proposal: extend ACPERM to IP editors overwriting redirects has the plain text #redirect (3×). The module should probably not be looking for that text and should instead rely on the title object property isRedirect.
Trappist the monk (talk) 12:16, 29 September 2023 (UTC)[reply]
How about to do that (#isredirect thing?) Just a random Wikipedian(talk) 13:10, 30 September 2023 (UTC)[reply]

Script error at Talk:Food security

[edit]

This template causes an error, Lua error in Module:Section_sizes at line 156: attempt to perform arithmetic on field '?' (a nil value). 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)[reply]

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)[reply]

Error

[edit]

Please fix error on Talk:Puerto Rico caused by this template — Martin (MSGJ · talk) 10:48, 13 June 2024 (UTC)[reply]

Done. --Ita140188 (talk) 20:30, 13 June 2024 (UTC)[reply]

VPT is not a redirext

[edit]

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 Wikipedia:Village pump (technical): it's a direct link. I've traced false error as far as the call {{#invoke:section sizes|size|Wikipedia:Village pump (technical)}} but no further, as Module:Section sizes is in Lua. --Redrose64 🌹 (talk) 19:19, 29 June 2024 (UTC)[reply]

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)[reply]
So it's my fault... --Redrose64 🌹 (talk) 20:42, 29 June 2024 (UTC)[reply]
Your words, not mine.
Fixed.
Trappist the monk (talk) 22:09, 29 June 2024 (UTC)[reply]

A parameter for individual revisions?

[edit]

This could be useful for comparing and contrasting different revisions' section sizes. PBZE (talk) 21:07, 18 July 2024 (UTC)[reply]

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)[reply]

i18n enhancement request

[edit]

I just exported this module to fr-wiki (fr:Module:Taille des sections) and it's working fine with its accompanying template, but it was a bit annoying running all around the template hunting for bits of English that need to be translated into French. It would be a very nice enhancement to drive the module off a config file (or files) where each config section or file was named after the WP code (usually, but not always, the same as ISO-639 code), and when running, the module would know what language space it was in, and would automatically pull the right code to display the right words for "Section sizes", "Total", "Bytes", and so on. There are not a lot of words, so the config would be pretty small, but save a lot of work.

If we kept all the configs here as "i18n register of record", then even non-Module writers could simply copy the Module code and the config to xx-wiki, and it would just work. If there wasn't a config for their language, it would be pretty obvious how to contribute one by analogy of the existing one(s), which they should create here, and then copy it. (Which also allows testing and demoing of "foreign" versions.) No big hurry on this, but if and when this becomes available, I would probably export the module to ca, de, es, it, nl, and pt, but it's just a bit too much work having to edit the module itself each time. Thanks, Mathglot (talk) 02:30, 16 August 2024 (UTC)[reply]

I have added a table of translatable static text to the top of Module:Section sizes; see lines 9–20 (permalink). I can see no reason why we need to keep ca, de, es, it, nl, pt, ... language data that will not be used on en or fr or any other language wikis.
The current version of fr:Module:Taille des sections is not working correctly. The module should be fetching the content of fr:MediaWiki:Vector-toc-beginning to use as the section name for the article lead. Here that name is '(top)', at fr.wiki it is 'Début'. I'll be investigating this oddity. As a workaround, specify Début in i18n_t.top.
Also, at fr:Discussion:Kriegsschuldfrage, several section names are broken. This is likely caused by use of templates in section headers (=== Traitement de la ''{{lang|de|Kriegsschuldfrage}}'' === at fr:Kriegsschuldfrage#Traitement de la Kriegsschuldfrage for example). There may not be a solution to this because there is no way that Module:Section sizes can know about all possible templates that can appear in section headings and so extract the correct information. It might be possible to preprocess headings that have templates and then remove all wiki, html, and html-like markup. Don't know how good a solution that is. At en.wiki, templates in section headings are discouraged; see MOS:SECTIONHEAD. An alternative would be to replace the section name with an unlinked error message (section size might still be added to the output table).
Trappist the monk (talk) 14:52, 16 August 2024 (UTC)[reply]
The no-lede-section-name-at-fr.wiki issue is resolved following discussion at WP:VPT.
Trappist the monk (talk) 18:13, 16 August 2024 (UTC)[reply]
And I think that I have fixed the broken section links issue.
You should be able to replace fr:Module:Taille des sections with a copy of Module:Section sizes, adjust the contents of i18n_t, ????, profit!1.
Trappist the monk (talk) 19:15, 16 August 2024 (UTC)[reply]
Oh, outstanding on all counts; great idea to have a top section that can be altered, that saves a separate config. Thanks for the headers, too. Much appreciated! Mathglot (talk) 20:37, 16 August 2024 (UTC)[reply]

Issue with dark mode

[edit]

For some reason, this template is not compatible with dark mode. The article sections are in black text, and the background is dark in dark mode, which makes it difficult to read. Please fix. Cranloa12n / talk / contribs / 02:31, 16 August 2024 (UTC)[reply]

It's funny because in the dark mode I use (which is the one developed years ago by volunteers instead of the WMF) the template looks fine. I cannot access the new dark mode as I am not using the new default skin (and not planning to) Ita140188 (talk) 13:49, 16 August 2024 (UTC)[reply]
It is usually easy to access the new dark mode. Open a different web browser where you are not logged in to Wikipedia, then copy and paste the URL for the page you want to see. Click the "Dark" radio button on the right side of the page. It works great for testing. I can replicate the OP's description above. – Jonesey95 (talk) 17:31, 16 August 2024 (UTC)[reply]
It appears that the problem is an improper interaction between the {{collapse top}} / {{collapse bottom}} templates and a contained wikitable (Module:Section sizes creates a wikitable). See this version of my sandbox. View it with vector 2022 and dark mode.
Trappist the monk (talk) 22:40, 16 August 2024 (UTC)[reply]

Wacky section headers

[edit]

I'm not suggesting the module handle this (please don't encourage them!), but check out the top two sections in the section sizes listed at fr:Discussion:Plan Becquey. This is due to the section headers on the article page having footnotes embedded in the section header. I haven't checked guidelines at fr-wiki about this, but I've never seen this before and it's hard to believe it's legit, even there. Just mentioning it here for the record. If anyone else sees wacky section headers wherever, please drop a link. It might be the germ for a doc page section of what is not handled. Thanks, Mathglot (talk) 06:11, 17 August 2024 (UTC)[reply]

Presumably you refer to the effects of this edit, specifically, the three references showing at the bottom of the page. If so, they are indeed due to the use of refs in section headings, and English Wikipedia prohibits this, see MOS:HEAD, fifth bullet. I don't know if French Wikipedia has such a rule - Pintoch, do you know if there is? --Redrose64 🌹 (talk) 08:53, 17 August 2024 (UTC)[reply]
@Mathglot: Aha, I've found fr:Aide:Note#Recommandation concernant les titres de section. --Redrose64 🌹 (talk) 09:04, 17 August 2024 (UTC)[reply]
Actually, I mean the effects of this edit. The one you linked merely exposed it. Mathglot (talk) 09:19, 17 August 2024 (UTC)[reply]
Ah, well done! Mathglot (talk) 09:20, 17 August 2024 (UTC)[reply]
I have hacked on fr:Module:Taille des sections so that it attempts to construct a readable (but unlinked) section name in the face of extraneous markup. There is a new message that it omits which needs translation. I added Template:Section sizes § Messaging (which likely could due with sensible copy editing). The message has a help link that points to the template.
Trappist the monk (talk) 14:42, 18 August 2024 (UTC)[reply]
Trappist, I've added the new translations to the fr module, and your change seems to work fine in use at fr:Talk:Plan Becquey. Will you import your version from fr back to Module:Section sizes, so that future changes for any other issue here can continue to be exported back to fr, or other language wikis without losing your beneficial code change ? (Here's a tip for anyone dealing with creating proper wikilinks to cross language namespaces: you don't have to remember that "Template" is "Modèle" in French, "Plantilla" in Spanish, and "Predefinição" in Portuguese, when you are creating a wikilink to a foreign template; you can just use the English namespace name with the local pagename, and it will work. For example: fr:Modèle:Taille des sections and fr:Template:Taille des sections both work, and go to the same page. Ditto with all other namespaces: just use English.) Thanks, Mathglot (talk) 08:23, 19 August 2024 (UTC)[reply]
Error messaging reworked to include fatal errors which will need translation at fr.wiki. en.wiki is up to date.
Trappist the monk (talk) 15:31, 19 August 2024 (UTC)[reply]
Hi, Trappist. I updated the error messages at fr-wiki. I also added a new section of test cases at Template:Section sizes/testcases; can you please look at test 2e for the 'markup removed; cannot link' case? I was only able to find one squirrely section header, at Talavera FS#pavilion_information[5] that produces it. (You might be able to find more bogus section headers, by tweaking this slow search. It will time out, but should return at least that one page, if you run it when there's not too much demand.) It looks like the sandbox version can link the malformed section header, even though the live version cannot; anyway, they are different, and not sure which result you were going for. Thanks, Mathglot (talk) 05:11, 20 August 2024 (UTC)[reply]
The live version is working as it should. When there is a reference in a heading MediaWiki adds the superscripted reference number to the heading (see the TOC at Talavera FS (permalink)). The bracketed reference number ([5]) is not available to Module:Section sizes so it cannot link to the article's section heading. Even were it possible to include the bracketed reference number, the number assigned is unlikely to be the same as is used in the article because those numbers are dependent on the number of, and position among, the references in the page being rendered. The sandbox in your 2e testcase links only to the article so it does not do what a reader expects from a link in the Section sizes table; it does not link to the named section.
Try this search (times out). You can also try searching on the plain text of the error message in the talk namespace. The latter search is faster, doesn't time out, but, for now, returns fewer results than former because all article talk pages that call {{section sizes}} haven't yet been through the job queue to be refreshed; that can take awhile. Ultimately the error message search will return more results because ref tags aren't the only markup that will be removed.
Trappist the monk (talk) 13:43, 20 August 2024 (UTC)[reply]
Thanks. I've updated the #Messaging section to lead with the fatals, followed by the advisory message and the explanation about invalid markup. Also, your advanced search link is better—thanks for that; I've also added it to the /testcases page in hidden text, and in the edit summary.
Two other points: first, thanks to your updated search, I've discovered numerous pages that are tagged for invalid markup, due to permitted embedded anchors in the heading. One example is from the {{section sizes}} template at Talk:Catholic Church, which has three such sections, for example in section Catholic Church § Contraception (as: ===={{anchor|Sex and contraception|contraception}}Contraception====). That section uses the older, less-preferred anchor template syntax; preferred is with <span id=...> as shown at MOS:SECTIONANCHOR, although the majority appear to use the template. Numerous additional {{anchor}} examples in subsections of SARS-CoV-2 Omicron variant § Subvariants. These embedded anchors should not interfere with linking the sections from the Module, as the {{section link}}s in this paragraph make clear.
Finally, given the usefulness of the invalid markup case, I think it would be very helpful to tag it with a category when you discover it, as few users will discover that advanced search. We could just add the Talk page to hidden tracking Category:Wikipedia articles with invalid markup in a section heading. (No longer red; I had to create it, because I previously ran into trouble creating a redlinked cat; if we decide not to use it, I will just tag it for {{db-g7}}.) What do you think? Mathglot (talk) 22:34, 20 August 2024 (UTC)[reply]
Yeah, I've seen the {{anchor}} issue. When I discovered it, I looked at its companion at fr.wiki; they render differently:
at en.wiki: <span class="anchor" id="Anchor name"></span>
at fr.wiki: <span id="Anchor name"></span>
For the latter, the module cannot know with certainty that the span is an anchor. For the former, it is obvious because of the class="anchor" attribute. Yeah, it can make an assumption that an empty <span id="..."></span> with an id="..." attribute and nothing else except for an explicit class="anchor" attribute, is an anchor. I was undecided about that so I elected to do nothing special for section anchors.
It occurs to me that we could require the different language anchor template name (fr: Ancre, de: Anker, es: Ancla, etc) from which the module would construct a skeleton template to preprocess to get a model of what an anchor in that language's section heading would look like:
{{Ancre|...}}<span id="..."></span>
The module could then know what to look for in the event that some wikis (en.wiki) are different from others. I'll think about this.
Yeah, we can add a name-space specific category emission. Use of {{section sizes}} outside of talk name space is allowed so those uses with markup issues should probably not be categorized.
Trappist the monk (talk) 23:26, 20 August 2024 (UTC)[reply]
As far as the module knowing what to look for, rather than program it, may I suggest we simply list it? You seem to be a whiz with Lua, but still, coding something to construct an anchor matching widget that would work in the general case—all 300+ Wikipedias, or at least, the 159 that have an {{Anchor}} equivalent—seems like it would be a pain, and also unnecessary. There are only eight wikidata links now for Module:Section sizes, and it would be pretty easy to enumerate the form of {{anchor}} in each of them (I still like the config file idea), or to list the regex-match expression for the local version, or whatever string would save having to code a general case for it when we could just list whatever it is you would need. Here are Anchor templates for every wiki that has a Module:Section sizes (8): ar=ar:قالب:علامة موقع, bn=bn:টেমপ্লেট:নোঙর, en=en:Template:Anchor, fr=fr:Modèle:Ancre, ja=ja:Template:Anchors, ru=ru:Шаблон:Якорь, vi=vi:Bản mẫu:Anchor, and zh=zh:Template:Anchor; (keeping in mind the prefix simplification, i.e., ru:Шаблон:Якорь and ru:Template:Якорь are identical).
And if we implement the category (and I hope we do), the cat name should also be in the i18n_t section, and if it's blank, don't categorize, so that different languages can categorize, or not, depending on the value. Mathglot (talk) 02:25, 21 August 2024 (UTC)[reply]
Category:Pages with Template:Section sizes errors created and populated by the module. I preferred this name because the errors emitted by the module are only detected and annotated by the module. When i18n_t['error category'] omitted, set to nil, or commented out, the module does not emit a category wikilink. Errors outside of the Talk namespace are not categorized.
The module looks for and removes anchor markup that has one of the two following forms:
<span class="anchor" id="Foo"> – ar, bn, en, ja, zh wikis
<span id="Foo"> – fr, ja, ru, vi wikis; ja.wiki has two anchor templates ja:Template:anchors and ja:Template:visible anchor
i18n_t is tweaked so that where the template name is required, the module fetches it from the parent frame (category name and help links).
Trappist the monk (talk) 22:12, 21 August 2024 (UTC)[reply]
I'm running into a problem with some long section names with embedded templates on the French side. I updated fr:Module:Taille des sections as a copy of current rev. 1241560383‎ plus i18n translations, and it's producing 'markup removed' errors on certain section headings there (in French: 'balisage supprimé ; lien imposible'). The French page fr:Talk:Rafael Nadal has twelve sections with this error . All of these sections have embedded templates for ordinal numbers, such as fr:Template:1re which produces '1re over there, and 1st here (I imported/translated it), and other templates like fr:Template:2e and fr:Template:3e (not imported), which generate the French equivalent of 2nd and 3rd. (Another commonality in all of those sections is an embedded colon with a blank space fore and aft –  : , but I do not suspect that as a cause.)
I extracted those twelve section headings from fr:Rafael Nadal and copied them to User:Mathglot/sandbox/Section sizes testpage along with some lorem ipsum boilerplate, and when I target it with {{Section sizes}} here, the errors are reproduced at en-wiki as well, but only for six (not all twelve ) of the same section headings. (You will see "1st" in some of the section headings on the test page, because I copied the French template over for that one, but redlinks for "Template:2e", "Template:3e", and all the other oridinals, as I didn't import any of those.)
So there is something going on that triggers the 'markup removed' error twelve times on the French side for fr:Talk:Rafael Nadal, but only six times on our side for the testpage. (For what it's worth, I set the category to 'nil' on the French side, but I doubt that is relevant to this.) Mathglot (talk) 03:14, 22 August 2024 (UTC)[reply]
At fr.wiki:
{{1re|place}}<abbr class="abbr" title="Première">1<sup>re</sup></abbr>&nbsp;place1re place
and at en.wiki:
{{1re|place}}1<sup>st</sup> → 1st
Both get an error message because the module removes the html markup after the template has been preprocessed.
At fr.wiki:
{{2e|place}}<abbr class="abbr" title="Deuxième">2<sup>e</sup></abbr>&nbsp;place2e place
but at en.wiki:
{{2e|place}}[[:Template:2e]]Template:2e
The error message is only displayed at fr.wiki because the module removed the html markup after the template was preprocessed. At en.wiki the template redlink is not removed after preprocessing so no html markup to remove. This is a case that I had not considered.
I have tweaked the module so that it looks for [[:Template:<whatever>]] (or [[:Modèle:<whatever>]] at fr.wiki) and replaces those wikilinks with [...]. Twelve errors now at your test page.
Trappist the monk (talk) 14:01, 22 August 2024 (UTC)[reply]

Graphical representation of the ratio of lead size to article size

[edit]

It is currently possible to generate a graphical comparison of the relative size of the lead across articles using a template. Here is an example, showing the lead size as a percent of article size in seven Featured articles taken from the 'Ca' page of Category:Wikipedia_featured_articles:

Example: graphical representation of ratio of lead size to article size for seven Featured articles:

The Cabinet of Dr. Caligari = 3.2%
Caesar cipher = 6.4%
Caroline Island = 4.0%
Casablanca (film) = 9.9%
Castle = 5.2%
Chagas disease = 12.1% Cerro Blanco (volcano) = 4.2%

This is not the intended use of the template, and is an undocumented feature I just discovered. Using it this way requires some squirrely use of five rarely used configuration parameters. It does work, as seen in the example, but is very inconvenient currently. (That could be mitigated slightly, by careful documentation, but even then would be annoyingly difficult and error-prone.)

But the good news is that if there is interest in the functionality, the identical output could be generated without any of the inconvenience, by adding one new parameter to the template, which would replace the five squirrely config params which could be derived from it. (Or, a new template could be spun off, but they would be pretty similar).

If there is any interest in this feature, please let me know here, or at Template talk:Article length bar. Thanks, Mathglot (talk) 08:54, 2 September 2024 (UTC)[reply]

I should add, that there is nothing special about the lead section per se, and any section could be compared. As presently constituted, the template could also handle two different sections in the bar, with different colors for each. Mathglot (talk) 09:06, 2 September 2024 (UTC)[reply]
I'm not sure what it is you were asking for. What does {{albar}} have to do with {{section sizes}}?
Trappist the monk (talk) 00:48, 3 September 2024 (UTC)[reply]
Sorry I wasn't clear. I was asking for one, possibly two new external function points in Module:Section sizes, so that I could use them to create a new template where I might code: {{section length|lead|ArticleName}} and get, for example,
{{section length|lead|1919 New Year Honours}} ⟶ 1751     (length of lead of 1919 New Year Honours)
{{section length|Knight Bachelor|1919 New Year Honours}} ⟶ 2982     (length of section § Knight Bachelor )
{{section length|​|1919 New Year Honours}} ⟶ 327806     (length of whole article; this is just {{PAGESIZE}} )
This would permit a very useful extension to {{albar}} where the lead (or even multiple sections) could be compared graphically. The collapsed graphic at this discussion shows the length of the lead section as a proportion of article size, but the lead length and percentage figures were derived manually, so it is costly in time to produce examples like that, which make it impractical in the RW. With the new feature request, it would all of a sudden become possible to generate them programmatically via template and module (and reduce error risk in manual calculations), and make graphical representations like that possible for general use.
But it's not just for that; it would facilitate non-graphical Talk page comments where someone just wanted to say, "the lead of France is X kb, but it is Y for Germany, and Z for Italy", as User:Chipmunkdavis mentioned here. Mathglot (talk) 01:43, 5 September 2024 (UTC)[reply]
This:
{{#invoke:section sizes|section_size_get|1919 New Year Honours|_lead}} → 1,751 – length of lead of 1919 New Year Honours
{{#invoke:section sizes|section_size_get|1919 New Year Honours|Knight Bachelor}} → 2,982 – length of named section: § Knight Bachelor
{{#invoke:section sizes|section_size_get|1919 New Year Honours|_total}} → 327,824 – length of whole article
And, because it's free: _max
{{#invoke:section sizes|section_size_get|1919 New Year Honours|_max}} → 92,803 – length of longest section: § Military Cross (MC)
Keywords use leading underscores for the avoidance of confusion caused by similar (identical) section names.
I rearranged parameter order to put the (initially empty) parameter at the end. I then changed my mind about using the lack of something to mean something and added _total but kept the new parameter order. Section name comparisons are case insensitive.
Trappist the monk (talk) 23:14, 5 September 2024 (UTC)[reply]
There has been no further discussion on this topic, so it appears that this functionality is no longer needed. That being the case, I will shortly delete the supporting code from Module:Section sizes as unnecessary clutter.
Trappist the monk (talk) 00:52, 20 September 2024 (UTC)[reply]
Yes it is needed, please don't delete it. I neglected to subscribe, and didn't see the updates here. I will add calls using the new parameters shortly. Thanks for adding this! Mathglot (talk) 05:36, 20 September 2024 (UTC)[reply]
Okay, this is now implemented with template {{section length}} (which maybe could be shortened, as I've seen templates that appear to have no parameters in the template code, but they seem to get passed automagically).
There is one issue: Consider this template call and its equivalent invocation, and compare them to the size of World War II § Background in the Talk page banner for that article:
{{section length|World War II|Background}} → 50
{{#invoke:section sizes|section_size_get|World War II|Background}} ⟶ 50
Note that the intro to § Background is indeed a brief 50 bytes, but the whole section is 8,862. If there could be a way to grab either value by some additional parameter, that would be helpful. If not, I think the total length of the section including all subsections is probably the more useful statistic, especially when comparing different articles which may both have a History section, or Family life, or Demographics, or whatever.
What about something like this?
{{#invoke:section sizes|section_size_get|World War II|Background|_intro}} ⟶ 50
{{#invoke:section sizes|section_size_get|World War II|Background|_all}} ⟶ 8862
{{#invoke:section sizes|section_size_get|World War II|Background}} ⟶ 8862
That's just a suggestion, and if you feel like looking into it and come up with a different solution, I'm fine with whatever is easiest/makes most sense. Thanks again for your work on this, it will be invaluable for the graphic display project I'm working on, and I suspect will have a lot of use cases that I haven't dreamed of yet. Mathglot (talk) 06:41, 20 September 2024 (UTC)[reply]
I can see another use case, involving Talk page discussions about the proper size of the lead in an article, by way of comparisons with other, similar articles that is now easy to do, as in this imaginary Talk page post at Talk:Belgium:

Consider the relative size of the lead in France (7.51%%), Germany (6.39%%), Italy (8.25%%), and Belgium (14.31%%)...

This would have been too tedious to attempt previously, but is now very easy. All of these country articles have sections on #History, #Geography, #Economy, and #Demography, but it isn't possible to compare them yet, which is one reason why the _all value would be nice to have. Mathglot (talk) 08:11, 20 September 2024 (UTC)[reply]
Implemented:
{{#invoke:section sizes|section_size_get|World War II|Background}} → 50
{{#invoke:section sizes|section_size_get|World War II|Background|_all}} → 8,872
{{#invoke:section sizes|section_size_get|World War II|Course of the war}} → 149
{{#invoke:section sizes|section_size_get|World War II|Course of the war|_all}} → 87,100
Not exhaustively tested. Should the output be commafied?
Trappist the monk (talk) 11:48, 20 September 2024 (UTC)[reply]
Excellent! No commas by default, please, that would mess up arithmetic calculations such as percent calculation, which would require an extra step via formatnum. (Also, I believe the latter will also supply the best, region-based punctuation, whether it be cmmma, dot, or maybe even space. If there's already some Lua library that does what formatnum does and it's easy to provide it on an opt-in basis, that would make usage of the template easier for some people. So in that case maybe something like: {{#invoke:section sizes|section_size_get|World War II|Course of the war|_all|_sep}} (for separator or maybe _div or _punct?) would yield "87,149" or "87.149" depending on region, and we'd add the corresponding param to the template.
I'm trying to predict what would make it easiest for the greatest number of future users, and that's my best guess, but if most users use the bare template for value presentation only (i.e. without calculations), maybe default should be commafied, and the feature should be opt-out, so in that case, the module would have |_nosep= or |_nopunct= and the template would echo that. What do you think? Otherwise, it can be done under formatnum control in the template. Mathglot (talk) 17:31, 20 September 2024 (UTC)[reply]
Defaults to commafied; |_nosep=yes to uncommafy:
  • {{#invoke:section sizes|section_size_get|World War II|Background|_all}} → 8,872
  • {{#invoke:section sizes|section_size_get|World War II|Background|_all|_nosep=yes}} → 8872
  • {{#invoke:section sizes|section_size_get|World War II|_total|_nosep=no}} → 255,263
  • {{#invoke:section sizes|section_size_get|World War II|_total|_nosep=yes}} → 255263
  • {{#invoke:section sizes|section_size_get|World War II|_max|_nosep=}} → 62,792
  • {{#invoke:section sizes|section_size_get|World War II|_max|_nosep=yes}} → 62792
Trappist the monk (talk) 00:50, 21 September 2024 (UTC)[reply]
Looks good. I think we have covered all the issues I am aware of, and I wanted to thank you for your work on this. This will have immediate benefits for the project I am working on, and I cam convinced it will have additional benefits over time as more editors become aware of the possibilities. Have a great weekend! Mathglot (talk) 01:05, 21 September 2024 (UTC)[reply]

Here is an illustration of use of the new feature that I thought you might be interested in. See Wikipedia:WikiProject Countries/Common section size. Mathglot (talk) 10:47, 21 September 2024 (UTC)[reply]

Wouldn't it be better to have the module return the percentage? In {{slen}} you call the module three times to get the percentage; once to see if you can (error message suppression?) and then two more times to do the percentage calculation. All of the required numbers are available to the module when it returns whatever it is instructed to return. So you might write:
{{#if: {{{pct|}}} | {{#invoke:section sizes|section_size_get|{{{1|<noinclude>France</noinclude>}}}|{{{2|_lead}}}|_pct=yes}} |...
or maybe just:
{{#invoke:section sizes|section_size_get|{{{1|<noinclude>France</noinclude>}}}|{{{2|_lead}}}|_nosep={{{nosep|}}}|_pct={{{pct|}}}}}
|_nosep= would be ignored when |_pct= set
Trappist the monk (talk) 12:37, 21 September 2024 (UTC)[reply]
And just because I could:
  • {{#invoke:section sizes|section_size_get|World War II|_total}} → 255,263
  • {{#invoke:section sizes|section_size_get|World War II|Background|_nosep=yes}} → 50
  • {{#invoke:section sizes|section_size_get|World War II|Background|_pct=yes}} → 0.02%
  • {{#invoke:section sizes|section_size_get|World War II|Background|_all|_nosep=yes}} → 8872
  • {{#invoke:section sizes|section_size_get|World War II|Background|_all|_nosep=yes|_pct=yes}} → 3.48%
Trappist the monk (talk) 13:42, 21 September 2024 (UTC)[reply]
Yes, much better, wow, this is great! Thanks! I'll make the downstream adjustments to the template to simplify. Better and better... Mathglot (talk) 18:27, 21 September 2024 (UTC)[reply]
The template has been adjusted to use section_size_get now. Mathglot (talk) 02:37, 23 September 2024 (UTC)[reply]

Module doc update

[edit]

Hi Trappist. I took my best shot at extending the § Usage section of the doc page to take into account your recent enhancements. Can you please check it for completeness and correctness, and adjust as needed? Thanks. Mathglot (talk) 01:44, 22 September 2024 (UTC)[reply]

You meant Module:Section sizes § Usage and not Template:Section sizes § Usage, right?
You know, I do suck at writing documentation but I have had a go at it.
While I was doing that it occured to me to rename section_size_get()section_size_get(). The whole module is really about size so for consistency, I renamed the function. It still works under the old name but that name should someday go away.
Trappist the monk (talk) 20:03, 22 September 2024 (UTC)[reply]
I am the only one using {{Section length}}, and the template is the only one using the new entry point of the Module under either name. I will update the template to use the new name, and then ping you when I have gotten rid of all the old name usages.
One more thought, while we are on naming: since the module is named "Section sizes", just calling the second entry point get() would be unambiguous, or at worst, size_get(), as a reminder of what it is getting. So if you want to shorten it further, be my guest. There would be a slight advantage for direct users of the module, who would have to code fewer characters. Also, it is kind of in the spirit of MOS:NOBACKREF, which only applies to section heading naming, but I think its ghost kind of applies here, too, or at least, it could . Mathglot (talk) 01:15, 23 September 2024 (UTC)[reply]
The template is updated now to use the new entry point name. Any remaining cases using the old name are mostly here in discussions on this page, and other ones don't matter. Afaic, you can remove the old entry point name if you want. If that causes any stragglers I missed to barf, I'll fix them. Mathglot (talk) 02:37, 23 September 2024 (UTC)[reply]
Module updated to get rid of section_length_get export; all instances of section_length_get on this page replaced with section_size_get so that we don't contribute to Category:Pages with script errors.
Trappist the monk (talk) 14:02, 23 September 2024 (UTC)[reply]
I see no reason to rename the section_size_get() function to something else. This name is not clearly descriptive and not overly long (and double-click, copy pasta is your friend).
Trappist the monk (talk) 14:02, 23 September 2024 (UTC)[reply]

Param interaction

[edit]

I think there might be an interaction between param _pct and param 2 = _lead:

These first three return values as expected, when param 2 section name is any section except the lead:

  • {{#invoke:Section sizes|section_size_get| World War II | Background}} ⟶ 50     (expect 50)
  • {{#invoke:Section sizes|section_size_get| World War II | Background |_all}} ⟶ 8,872     (expect 8,862)
  • {{#invoke:Section sizes|section_size_get| World War II | Background |_pct=yes}} ⟶ 0.02%     (expect 0.02%)

Compare with these, especially the last one, when param 2 = _lead :

  • {{#invoke:Section sizes|section_size_get| World War II | _total }} ⟶ 255,263     (expect 255,239)
  • {{#invoke:Section sizes|section_size_get| World War II | _lead }} ⟶ 12,034     (expect 11,984)
  • {{#invoke:Section sizes|section_size_get| World War II | _lead |_all}} ⟶ 12,034     (expect 11,984; no lead subsections)
  • {{#invoke:Section sizes|section_size_get| World War II | _lead |_pct=yes}} ⟶ 4.71%     (expect 4.7%) Mismatch

Unless I'm invoking it wrong, it looks like param |_pct=yes is disabled when param |2=_lead. Mathglot (talk) 07:10, 22 September 2024 (UTC)[reply]

Fixed:
  • {{#invoke:Section sizes|section_size_get| World War II | _lead |_pct=yes}} ⟶ 4.71%
  • {{#invoke:Section sizes|section_size_get| World War II | _lead | _all |_pct=yes}} ⟶ 4.71%
  • {{#invoke:Section sizes|section_size_get| World War II | _max |_pct=yes}} ⟶ 24.60%
  • {{#invoke:Section sizes|section_size_get| World War II | _total |_pct=yes}} ⟶ 100.00% (but why?)
Trappist the monk (talk) 11:44, 22 September 2024 (UTC)[reply]
I was fiddling around and noticed this:
  • {{#invoke:Section sizes|section_size_get| France | _lead }} ⟶ 20,930
  • {{#invoke:Section sizes|section_size_get| France | _max }} ⟶ 20,930
So I went to Talk:France to look at the Section sizes wikitable and scrolled down the 'Byte count' column looking for the reddest tally which was 'Economy' (14,189 bytes). Does not match. Looked like a bug until I realized that the lead really is the largest section but its 'Byte count' and 'Section total' cells weren't being colored. I have fixed that.
Trappist the monk (talk) 15:01, 22 September 2024 (UTC)[reply]
Well somewhere along the line I broke section_size_get(); it was skipping the first section after the lead so all of the keyword values were off by that size. Fixed now.
Trappist the monk (talk) 17:08, 22 September 2024 (UTC)[reply]
Thanks, and I will make the backlogged simplifying change to the template, based on your earlier introduction of _pct to the module, and change the entry point name to 'section_size_get' (and am happy to change it again to 'get' or whatever, if we go that route). Mathglot (talk) 01:19, 23 September 2024 (UTC)[reply]
The template is much simplified now, it also uses the new entry point. All test cases pass. Mathglot (talk) 02:37, 23 September 2024 (UTC)[reply]

Script error

[edit]

Script error on Talk:List of 2000s films based on actual events — Martin (MSGJ · talk) 21:03, 10 November 2024 (UTC)[reply]

And a different type of error on Talk:National Basketball Association — Martin (MSGJ · talk) 21:04, 10 November 2024 (UTC)[reply]
@MSGJ: I don't see any problem. What is the specific error, where exactly does it occur? --Redrose64 🌹 (talk) 21:44, 10 November 2024 (UTC)[reply]