Module talk:columns

Split by line endings

Instead of requiring each list item to be a separate parameter, couldn't it split the text by line endings? I think that would make it a bit easier. —CodeCat 13:14, 25 January 2014 (UTC)

It could, but what if you wanted to preserve line endings for indentation purposes (*, **, etc)? That's why I changed it to parameters. I could add a function for switching between defining the list through template parameters or through newlines. DTLHS (talk) 17:40, 25 January 2014 (UTC)

You could just add the * in the parameters too. That way you could also make nested lists, while at the same time making sure that the module doesn't cut them in half (as long as it's made to understand them). —CodeCat 17:45, 25 January 2014 (UTC)

I am happy either way. I add the pipe symbol by a macro in Word to create the tens or hundreds of separate parameters. Splitting by line endings will probably be more convenient for regular users. --Vahag (talk) 19:45, 26 January 2014 (UTC)

Broken sort with Ancient Greek

Sort is broken with Ancient Greek: see κρατέω for an example. ObsequiousNewt (ἔβαζα|ἐτλέλεσα) 20:33, 6 July 2014 (UTC)

Okay, so after some digging I've found that Scribunto appears to somehow override the > operator so that it'll interpret á/ä/ą/etc. as "a" (instead of sorting them by Unicode value as usual); however letters with Ancient Greek diacritics (ἀ/ᾳ/ἁ/ᾶ) are treated as an empty string. I don't know how to fix this, or even where the relevant code might be. If anyone could solve this problem, or even point me in the right direction, that would be great. ObsequiousNewt (ἔβαζα|ἐτλέλεσα) 17:28, 7 September 2014 (UTC)

Problem with {{syn2}}

@CodeCat, DTLHS, Erutuon: according to the documentation, if the parameter |lang= is "left undefined, the entry calling the template will have to provide it". I updated {{syn2}}, which calls this module, by adding |lang={{{lang|en}}} so that it is unnecessary to manually specify the value of |lang= if it is English. However, if |lang= is omitted entirely the template works as expected, but if |lang=en is added the error message "Lua error in Module:parameters at line 108: The parameter "lang" is not used by this template" appears. What did I do wrong? — SGconlaw (talk) 18:00, 14 December 2017 (UTC)

The logic in the module is that if the |lang= parameter is provided on the template page in the {{#invoke:columns}} invocation (frame.args), then the same parameter cannot be provided when the template is used (frame:getParent().args). I think the problem will be fixed if you do not provide a default language code on the template page: thus, |lang={{{lang|}}}. However, a mechanism to change this logic (or a parameter to provide a default language code) could be added if it is really desirable for there to be a default language code. — Eru·tuon 20:41, 14 December 2017 (UTC)

Well, I was just trying to get the template to work according to the documentation which says that if |lang= is not specified then the template defaults to English. However, without adding |lang= to the template, omitting it generates an error stating that |lang= must be specified. — SGconlaw (talk) 02:27, 15 December 2017 (UTC)

Strange. Perhaps that was the behavior in a previous revision of the module or template. — Eru·tuon 02:50, 15 December 2017 (UTC)

I had a look at {{syn3}} and {{syn4}}. So, from what I can tell, if {{lang}} is omitted entirely, the template does not link to any language section of an entry page. If one wishes to link to, say, the English section, then |lang=en must be explicitly specified. Is this correct? — SGconlaw (talk) 02:57, 15 December 2017 (UTC)

However, I've just realized that @Rua has deleted {{syn2}} and {{ant2}} with the message "No longer needed"; not quite sure why. — SGconlaw (talk) 02:29, 15 December 2017 (UTC)

Broken sort with Gothic

Gothic is being sorted very strangely. At 𐍅𐌰𐌽𐌳𐌾𐌰𐌽 (wandjan) I wrote:

{{der3|lang=got
|𐌰𐍄𐍅𐌰𐌽𐌳𐌾𐌰𐌽
|𐌰𐍆𐍅𐌰𐌽𐌳𐌾𐌰𐌽
|𐌱𐌹𐍅𐌰𐌽𐌳𐌾𐌰𐌽
|𐌲𐌰𐍅𐌰𐌽𐌳𐌾𐌰𐌽
|𐌹𐌽𐍅𐌰𐌽𐌳𐌾𐌰𐌽
|𐌿𐍃𐍅𐌰𐌽𐌳𐌾𐌰𐌽
}}

with the words already in alphabetical order. It surfaces as:

• 𐌰𐍄𐍅𐌰𐌽𐌳𐌾𐌰𐌽 (atwandjan)
• 𐌰𐍆𐍅𐌰𐌽𐌳𐌾𐌰𐌽 (afwandjan)
• 𐌱𐌹𐍅𐌰𐌽𐌳𐌾𐌰𐌽 (biwandjan)
• 𐌲𐌰𐍅𐌰𐌽𐌳𐌾𐌰𐌽 (gawandjan)
• 𐌹𐌽𐍅𐌰𐌽𐌳𐌾𐌰𐌽 (inwandjan)
• 𐌿𐍃𐍅𐌰𐌽𐌳𐌾𐌰𐌽 (uswandjan)

with the alphabetical order all messed up. The two words that start with 𐌰 (a) aren't even next to each other, let alone in alphabetical order. And the word starting with 𐌱 (b) appears after the word starting with 𐌹 (i) instead of before the word starting with 𐌲 (g).

@Erutuon, Wyang: Any ideas? —Mahāgaja (formerly Angr) · talk 14:16, 25 April 2018 (UTC)

For some reason Lua thinks the character "𐍄" (66372) is greater than the character "𐍆" (66374). Therefore the comparison fails on line 80. I'm guessing we'll have to use mw.ustring.codepoint and iterate over all characters instead of just comparing the strings with <. In the mean time you can use {{der3-u}} which will not apply any automatic sorting. DTLHS (talk) 16:35, 25 April 2018 (UTC)

Is that all? Because if that were all, I'd expect 𐌰𐍆𐍅𐌰𐌽𐌳𐌾𐌰𐌽 >> 𐌰𐍄𐍅𐌰𐌽𐌳𐌾𐌰𐌽 >> 𐌱𐌹𐍅𐌰𐌽𐌳𐌾𐌰𐌽, and then the rest correct, but what is actually generated is just bizarre. Or does that one error mean that the whole thing breaks down after that point? —Mahāgaja (formerly Angr) · talk 16:43, 25 April 2018 (UTC)

No that's not all. Looking at all the characters in Gothic, if the original list is { [1] = 𐌰,[2] = 𐌱,[3] = 𐌲,[4] = 𐌳,[5] = 𐌴,[6] = 𐌵,[7] = 𐌶,[8] = 𐌷,[9] = 𐌸,[10] = 𐌹,[11] = 𐌺,[12] = 𐌻,[13] = 𐌼,[14] = 𐌽,[15] = 𐌾,[16] = 𐌿,[17] = 𐍀,[18] = 𐍁,[19] = 𐍂,[20] = 𐍃,[21] = 𐍄,[22] = 𐍅,[23] = 𐍆,[24] = 𐍇,[25] = 𐍈,[26] = 𐍉,[27] = 𐍊,}, (Unicode order) that will be sorted to { [1] = 𐌰,[2] = 𐍁,[3] = 𐍂,[4] = 𐍀,[5] = 𐌿,[6] = 𐌾,[7] = 𐍃,[8] = 𐍅,[9] = 𐍈,[10] = 𐍄,[11] = 𐍇,[12] = 𐍆,[13] = 𐍉,[14] = 𐌽,[15] = 𐌻,[16] = 𐌳,[17] = 𐌴,[18] = 𐌲,[19] = 𐌱,[20] = 𐌼,[21] = 𐌵,[22] = 𐌷,[23] = 𐌺,[24] = 𐌶,[25] = 𐌹,[26] = 𐌸,[27] = 𐍊,}. DTLHS (talk) 16:53, 25 April 2018 (UTC)

We could replace the comparison function with this:

local function comp(item1, item2)
	local l1 = mw.ustring.len(item1)
	local l2 = mw.ustring.len(item2)
	for i=1,math.min(l1,l2) do
		local b1 = mw.ustring.codepoint(item1, i, i)
		local b2 = mw.ustring.codepoint(item2, i, i)
		if b1 ~= b2 then
			return b1 < b2
		end
	end
	return l1 < l2
end

I don't know how much of a performance loss this would be. DTLHS (talk) 17:09, 25 April 2018 (UTC)

Oy vey. It's probably easier to just use {{der3-u}}. Gothic isn't a language that's going to be needing collapsible tables of columns very often anyway. —Mahāgaja (formerly Angr) · talk 17:36, 25 April 2018 (UTC)

This is very strange. I tested the Lua < operator (which is being used to sort the words in the template) with these Gothic words and it returns false no matter which order the words are in: that is, Gothic word number 1 is always both less than and greater than Gothic word number 2. (The > or <= operators also give the same result, true or false, for both orderings.) So, the sorting function is giving the Gothic words a random order.

When I try a version of the same program in my off-wiki Lua interpreters (versions 5.3.4 and 5.1.5), it works correctly (meaning, each word is either greater or less than another). So there seems to be a bug in how Scribunto implements the comparison operators. It seems to only affect codepoints in the Supplementary Multilingual Plane. I tried characters from the Linear B block, at the beginning of the SMP, and it has the bug, but Arabic Presentation Forms, a few blocks below the SMP, doesn't.

Maybe the comparison function is implemented by parsing the string into a series of codepoints stored in 16-bit unsigned integers (range 0-0xFFFF), and since the SMP has codepoints outside of this range, the operation fails and instead of crashing, either true or false is returned. (Or maybe this has something to do with UCS-2.) Maybe they assumed that no wiki will ever need to use comparison operators on the SMP? Anyway, I suppose a bug report needs to be filed about this.

In the meantime, there may be an inexpensive way to detect characters in the SMP and only use the verbose comparison function if it's needed to avoid the bug. — Eru·tuon 19:55, 25 April 2018 (UTC)

Oh duh. I guess codepoints in the SMP are being truncated to 0xFFFF. So, Gothic codepoint 1 is 0xFFFF and Gothic codepoint 2 is also 0xFFFF; 0xFFFF < 0xFFFF is false, and reversing the order, 0xFFFF < 0xFFFF is also false, and so is 0xFFFF > 0xFFFF. But 0xFFFF <= 0xFFFF and 0xFFFF >= 0xFFFF are true. — Eru·tuon 20:26, 25 April 2018 (UTC)

So basically what it's trying to do is sort aaaaaaaaa, aaaaaaaaa, aaaaaaaaa, aaaaaaaaa, aaaaaaaaa, and aaaaaaaaa? —Mahāgaja (formerly Angr) · talk 20:29, 25 April 2018 (UTC)

@Mahagaja: Yeah, in effect. Every SMP character is treated as the same character. I'm writing about this on Phabricator now. — Eru·tuon 21:34, 25 April 2018 (UTC)

Phabricator link: phab:T193096. — Eru·tuon 22:33, 25 April 2018 (UTC)

@Erutuon Your SMP detection finds characters such as –, and items such as {{l|eo|hispana lingvo|t=Spanish language}} in the lists. DTLHS (talk) 19:31, 26 April 2018 (UTC)

@DTLHS: Whoops. It's off by a power of 16. (It searches for characters U+1000 and above rather than U+10000 and above.) — Eru·tuon 19:35, 26 April 2018 (UTC)

Okay, so the problem is in a C function used by our server's Lua interpreter, and it may not be fixed anytime soon. The workaround is to search for an SMP non-BMP character in the list of words, and if one is found, use the compare function that DTLHS posted. — Eru·tuon 19:46, 26 April 2018 (UTC)

@Erutuon: Thanks for finding a workaround! I hope the actual problem gets solved someday. —Mahāgaja (formerly Angr) · talk 07:13, 27 April 2018 (UTC)

Broken sort in Latin script

Apparently the sort keys remove not only punctuation, but also spaces, which is incorrect. For example, the vassal derived terms sort vassal state after vassalship whereas it should be between envassal and vassalage. Can this be fixed promptly? Urhixidur (talk) 12:08, 3 August 2018 (UTC)

@Urhixidur: Makes sense to me. I've made the change, though I'm still interested in the reasoning for removing spaces. — Eru·tuon 18:23, 3 August 2018 (UTC)

now supports <tr:...>, <q:...>, etc.

@Mahagaja I added the support to {{col3}} etc. for inline transliteration, qualifiers and similar. You can see an example in User:Benwing2/test-col. Benwing2 (talk) 00:56, 2 May 2021 (UTC)

notr

Can I have "notr=all" for suppress all (manual/automatic) transcription/tranliteration at once, for saving memory? And perhaps "notr=some" can still be overridden by a term? I have hundreds of terms (rhymes) to use with it but it runs out of memory. Segmentation does not help when they display on the same page. --Octahedron80 (talk) 05:18, 5 October 2021 (UTC)

False prefixes

@Benwing2 Hi - γίνομαι (gínomai) is throwing an error at the bottom of the page due to some (admittedly weird) formatting, as the template thinks Compounds: is a prefix. Not sure there's a straightforward way to solve this without having an override param (awkward) or loading every lang prefix (expensive). Theknightwho (talk) 08:48, 9 April 2023 (UTC)

@Theknightwho I will solve this by restricting the allowed format of the language codes, see my recent post in WT:BP about getting rid of such codes. For the moment it just means those weird codes won't be supported as language prefixes, which isn't the end of the world. Have to go to sleep now, will get to this tomorrow morning if that's OK. Benwing2 (talk) 08:51, 9 April 2023 (UTC)

@Benwing2 Of course! Get some rest. Theknightwho (talk) 08:58, 9 April 2023 (UTC)

<alt:> is not working with w: prefix

• 말을 말하다 (mar-eul mal-hada)
• 말을 말하다 (mar-eul mal-hada)

{{der2|ko
|w:ko:말<alt:말-을 말-하다>
|말<alt:말-을 말-하다>
}}

<alt:> is reflected in the transliteration, but is not ultimately shown.

@Benwing2, Theknightwho —Fish bowl (talk) 05:16, 3 May 2024 (UTC)

@Theknightwho This is caused by this line: Module:links#L-462. Can you take a look? Before this line runs, `data.term` looks like [[w:ko:말|말]] and `data.alt` looks like 말-을 말-하다. After the line, `data.term` looks like w:ko:말 (the brackets are stripped) and `data.alt` looks like 말 (the actual alt value has been replaced with the value from the brackets). I think in this case it should honor the existing `data.alt` if it is specified. Benwing2 (talk) 06:24, 3 May 2024 (UTC)

"display list raw if < 5 items"

@Benwing2 if this behavior is undesired, can it be disabled? For example, if someone wants {{col|en|n=3|a|b|c}} to work literally as instructed. (and if not, can you suggest a different template to use?)

Also, on collapsing tables, the documentation mentions However, there is a setting in Preferences to change this and make all tables be fully displayed by default. Could you please clarify? I cannot find this setting. Vuccala (talk) 02:37, 9 January 2025 (UTC)

@Vuccala There isn't currently a param to control whether the list displays in a single column if there are fewer than 5 items. I think the solution, at least for the moment, since this code is very new, is to see if we can figure out some display method that is generally accepted, before we add extra params that will lead to inconsistent results per editor preference. We can revisit this in a few days if we haven't figured out a good compromise. As for making tables fully displayed by default, I think this is actually not a setting in Preferences but in the left or right rail toolbar (in Vector 2010 it's on the left side under Visibility; not sure where it is in Vector 2022). There's a "show derived terms" and "show other boxes" that I have clicked on, and it seems this setting is remembered. Benwing2 (talk) 03:02, 9 January 2025 (UTC)

Thanks. The auto-expand option in Vector (2022) I found in the top-right menu Tools → Visibility → Show other lists Vuccala (talk) 15:03, 11 January 2025 (UTC)

@Benwing2 I don't understand why the template behaves this way. You'd think that putting a list inside a column template signals that you would like columns. Is there a way to force columns as of now? —Caoimhin ceallach (talk) 11:27, 6 June 2025 (UTC)

@Caoimhin ceallach There isn't such a setting and I don't want to expose one because if we leave this up to editor preference, it will lead to inconsistent and chaotic results. However, as you can see above, someone else also brought up this same issue; at the time I implemented this, there appeared to be a consensus for doing it the way it is currently done, but maybe that consensus was illusory. I suggest you open a Beer parlour discussion about changing this and see if there is consensus to do so. If the consensus is that we should display in columns regardless of the number of items, or reduce the cutoff point, or whatever, I will implement it. Benwing2 (talk) 04:50, 8 June 2025 (UTC)

RFD discussion: December 2022–January 2025

The following discussion has been moved from Wiktionary:Requests for deletion (permalink).

This discussion is no longer live and is left here as an archive. Please do not modify this conversation, but feel free to discuss its conclusions.

---

remove lesser-used column templates

I propose to remove the following column templates, after orphaning them by bot:

• Template:des-top, Template:des-bottom
• Template:desc-top, Template:desc-bottom
• Template:hyp-top, Template:hyp-top3, Template:hyp-bottom
• Template:derived terms
• Template:co-bottom
• Template:User:Donnanz/der3-u
• Template:hcol, Template:hcol2, Template:hcol3, Template:hcol4, Template:topx, Template:topx+, Template:exp-topx, (Template:hrow is used too much to deprecate right now, maybe later)

@Saltmarsh, Useigor, Surjection, Donnanz, Theknightwho We have far too many column templates with overlapping functionality, each with their own bugs and limitations. People keep "helpfully" creating more of them, for unclear reasons but seemingly to try to "fix" the "bugs" in the existing templates. IMO we only really need two sets: (1) {{col}} and related templates, which take the items inside the template, (2) templates where the items go outside, such as in {{top2}}, {{rel-top}}, {{der-top}}, etc. etc. I have pinged some of the creators of the existing templates that I propose to delete. Several other creators are no longer active. Benwing2 (talk) 06:34, 23 December 2022 (UTC)

@Benwing2 Mea culpa — looking back I see that I was guilty of "helpfulness". Why did I create the first-named above, I don't remember (it was 2008). It must have seemed like a good idea at the time — was it ever used? Trim away! — Saltmarsh^🢃 06:50, 23 December 2022 (UTC)

Fully supportive of this endeavour! It will be very exciting to get rid of unnecessary templates and minimise the terrible confusion that currently exists in this space. I would suggest to leave {{nav-bottom}} out of this list though, as it is currently being used as a collapsible box template, rather than a column template. (Why don't we have something like Category:Collapsible box templates, incidentally?) This, that and the other (talk) 09:16, 23 December 2022 (UTC)

For some context, I created {{nav-top}} and {{nav-bottom}} less as a column template and more as a collapse box template that also has column functionality (although I don't think any transclusion currently uses that feature). If it is removed, there should be some kind of alternative that it is replaced with. — SURJECTION ^{/ T / C / L /} 09:18, 23 December 2022 (UTC)

If I remember correctly, Template:User:Donnanz/der3-u was created to deal with false automatic alphabetical sorting of Scandinavian characters, the sorting was manual. I haven't used it for some years. DonnanZ (talk) 11:13, 23 December 2022 (UTC)

@Surjection, This, that and the other I see, it looks like there are actually four potential sets of templates: items inside vs. items outside and collapsing vs. non-collapsing, and {{nav-top}} and {{nav-bottom}} are actually generalizations of the items-outside collapsing variants. I would maybe suggest giving them different or shorter names, maybe {{col-top}} or {{ctop}} where 'col' or 'c' = collapsing; at least for me, the nav- prefix isn't self-explanatory of what it does. (Update: there already is a {{col-top}}. Blah.) BTW for reference I've attached a table of all the templates currently in CAT:Column templates, along with their aliases and their usage count. Note that the canonical names are boldfaced, and their usage count includes the usage count of their aliases.

Aliased template	Canonical template	#Uses	Disposition
Template:bl	Template:bl	344	Replace with a blank line; I don't see the point of a template. [some discussion of this below]
Template:bottom	Template:bottom	19656	Keep.
Template:co-top	Template:co-top	357	Replace with {{ctop2|Collocations}} and delete.
Template:co-bottom	Template:co-bottom	356	Replace with {{cbottom}} and delete.
Template:col	Template:col	177	Move |1= to |n= so it can be omitted in the future to get auto-width behavior.
Template:col-auto	Template:col-auto	1714	This template is questionable, see discussion in Wiktionary:Grease pit/2022/December#col-auto.
Template:collapse	Template:collapse	487	Replace with {{ctop}}, add {{cbottom}} and delete.
Template:collapse-bottom	Template:collapse-bottom	30	Delete in favor of {{nav-bottom}}/{{box-bottom}}/{{cbottom}} (whatever name is chosen).
Template:collapse-top	Template:collapse-top	30	Delete in favor of {{nav-top}}/{{box-top}}/{{ctop}} (whatever name is chosen).
Template:col-bottom	Template:col-bottom	1807	Keep for now?
Template:col-top	Template:col-top	1848	Keep for now?
Template:col-u	Template:col-u	34	Replace with {{col|sort=0}} and delete.
Template:col1	Template:col1	259	Keep.
Template:col1-u	Template:col1-u	25	Replace with {{col1|sort=0}} and delete.
Template:col2	Template:col2	16251	Keep.
Template:rel2	Template:col2	3244	Keep.
Template:der2	Template:col2	9124	Keep.
Template:col2-u	Template:col2-u	279	Replace with {{col2|sort=0}} and delete.
Template:col3	Template:col3	64916	Keep.
Template:rel3	Template:col3	6669	Keep.
Template:der3	Template:col3	21969	Keep.
Template:col3-u	Template:col3-u	458	Replace with {{col3|sort=0}} and delete.
Template:col4	Template:col4	27323	Keep.
Template:rel4	Template:col4	4491	Keep.
Template:der4	Template:col4	10766	Keep.
Template:col4-u	Template:col4-u	258	Replace with {{col4|sort=0}} and delete.
Template:col5	Template:col5	452	Keep.
Template:col5-u	Template:col5-u	44	Replace with {{col5|sort=0}} and delete.
Template:der-bottom	Template:der-bottom	7247	Keep.
Template:der-top	Template:der-top	5960	Rename to {{der-top2}} for consistency with {{top2}}, unless the header is overridden, in which case replace with {{ctop2}}.
Template:der-top3	Template:der-top3	1457	Keep unless the header is overridden, in which case replace with {{ctop3}}.
Template:der-top4	Template:der-top4	277	Keep unless the header is overridden, in which case replace with {{ctop4}}.
Template:der-top5	Template:der-top5	25	Keep unless the header is overridden, in which case replace with {{ctop5}}.
Template:derived terms	Template:derived terms	169	Replace with {{col-auto|title=Derived terms}} or with {{col|n=N|title=Derived terms}} where N is the value that the algorithm for this template auto-selects; then delete.
Template:des-bottom	Template:des-bottom	293	Replace with {{cbottom}} and delete.
Template:des-top	Template:des-top	295	Replace with {{ctop2|Descendants}} and delete.
Template:desc-bottom	Template:desc-bottom	400	Replace with {{cbottom}} and delete.
Template:desc-top	Template:desc-top	400	Replace with {{ctop2|Descendants}} and delete.
Template:exp-topx	Template:exp-topx	11	Replace with something and delete.
Template:hcol	Template:hcol	239	Replace with {{top2}}, add {{bottom}} at the bottom and delete.
Template:hcol2	Template:hcol2	10	Replace with {{top2}}, add {{bottom}} at the bottom and delete.
Template:hcol3	Template:hcol3	13	Replace with {{top3}}, add {{bottom}} at the bottom and delete.
Template:hcol4	Template:hcol4	8	Replace with {{top4}}, add {{bottom}} at the bottom and delete.
Template:acol4	Template:hcol4	5	Done Replace with {{top4}}, add {{bottom}} at the bottom and delete.
Template:hrow	Template:hrow	2961	This is almost exclusively used for Proto-Slavic descendants. We could make a special-purpose template for this use, replace and delete.
Template:hyp-bottom	Template:hyp-bottom	44	Replace with {{cbottom}} and delete.
Template:hyp-top	Template:hyp-top	25	Replace with {{ctop2|Hypernyms and hyponyms}} and delete.
Template:hyp-top3	Template:hyp-top3	24	Replace with {{ctop3|Hypernyms and hyponyms}} and delete.
Template:nav-bottom	Template:nav-bottom	6	Rename to {{cbottom}}.
Template:nav-top	Template:nav-top	6	Rename to {{ctop}} and rename |columns= to |n=.
Template:rel-bottom	Template:rel-bottom	4654	Keep.
Template:rel-top	Template:rel-top	3463	Rename to {{rel-top2}} for consistency with {{top2}}, unless the header is overridden, in which case replace with {{ctop2}}.
Template:rel-top3	Template:rel-top3	937	Keep unless the header is overridden, in which case replace with {{ctop3}}.
Template:rel-top4	Template:rel-top4	394	Keep unless the header is overridden, in which case replace with {{ctop4}}.
Template:rel-top5	Template:rel-top5	29	Keep unless the header is overridden, in which case replace with {{ctop5}}.
Template:rhyme list begin	Template:rhyme list begin	6641	Keep.
Template:rhyme list end	Template:rhyme list end	6639	Keep.
Template:Show-head	Template:Show-head	16	Replace with {{ctop}} and delete.
Template:Show-tail	Template:Show-tail	15	Replace with {{cbottom}} and delete.
Template:templatetable	Template:templatetable	12	Inline code and delete.
Template:th-alt	Template:th-alt	696	Replace with {{col3}} and delete.
Template:top2	Template:top2	10596	Keep.
Template:top3	Template:top3	6277	Keep.
Template:top4	Template:top4	3265	Keep.
Template:top5	Template:top5	279	Keep.
Template:topx	Template:topx	31	Replace with something and delete.
Template:trans-bottom	Template:trans-bottom	123345	Keep.
Template:trans-mid	Template:trans-mid	121580	Orphan and delete after pushing new version to production.
Template:trans-top	Template:trans-top	122641	Keep.
Template:trans-top-also	Template:trans-top-also	1770	Keep.
Template:trans-top-see	Template:trans-top-also	380	Replace with {{trans-top-also}} and delete.
Template:User:Donnanz/der3-u	Template:User:Donnanz/der3-u	399	Replace with {{der3}} and delete.
Template:vi-der	Template:vi-der	2230	Why do we need this? Figure out how to obsolete it.
Template:zh-der	Template:zh-der	38175	Keep. Replace with {{col3}} and deprecate.
Template:zh-der/fast	Template:zh-der/fast	34	A failed experiment; replace with {{zh-der}}{{col3}} and delete.
Template:zh-syn-list	Template:zh-der	1938	Done Replace with {{zh-der}}{{col3}} and deprecate.
Template:zh-ant-list	Template:zh-der	48	Done Replace with {{zh-der}}{{col3}} and delete.

Benwing2 (talk) 03:35, 24 December 2022 (UTC)

Update: I added a column labeled "Disposition" containing what I think should be done with the template. I think there should only be three sets of templates: (1) auto-collapsing with items inside the template: {{col}}, {{col2}}, etc.; (2) auto-collapsing with items outside the template: {{ctop}}, {{ctop2}}, etc.; (3) non-collapsing with items outside the template: {{top2}}, etc.. Thoughts? Benwing2 (talk) 06:09, 24 December 2022 (UTC)

Very comprehensive, and very sensible. I endorse the entire list.

To me {{col-top}} says "column", not "collapsible". Perhaps {{box-top}}? This, that and the other (talk) 11:05, 24 December 2022 (UTC)

Seems sensible. Thanks! — Sgconlaw (talk) 11:29, 24 December 2022 (UTC)

@This, that and the other {{box-top}} makes sense to me. Benwing2 (talk) 19:11, 24 December 2022 (UTC)

I support consolidating a lot of these. I do want to note that I have long seen {{rel-top}} used (and have subsequently myself used it, e.g. in blunket and Iroquois) purely to collapse prose, e.g. details and less-important info in a long etymology, without necessarily needing the contents to be divided into columns, though it seems like at some points in its history the template has divided info into columns (I can recall when the ety info in Iroquois used to show up in two columns, although it did not originally, and presently does not again). That is a situation we still need a template for, to collapse info into an expandable box without dividing it into columns, but I'm by no means wedded to {{rel-top}} being that template: it's just what I saw people use for that purpose, but it's not an intuitive name for that use-case. The superficially more intuitively named col-top (collapsible-box-top? no) is apparently short for column- instead. We have T:collapse-top, which should work, although it's currently presented as if it's intended to be used to list translations (which are displayed in columns). (Update, I changed that.) Anyway, as long as there is still a template for "collapsing, with items outside the template, not divided into columns", I support consolidating the proliferation of column templates. I wonder if there's a way to find cases where people have used "column templates" purely for their collapsing functionality, to convert to T:collapse-top: perhaps we look for cases where they're used in the ===Etymology===, ===References=== or ===Further reading=== section, and/or where the contents includes a line of characters longer than some number N, to catch things like

This is a long string of prose someone felt should be collapsed, able to be expanded by interested parties but otherwise out of the way.

as opposed to

• item in a list
• another list-item

- -sche (discuss) 01:38, 25 December 2022 (UTC)

@-sche Thanks for your comments. Yes, I am also suggesting using 'col' or 'c' to stand for 'collapse' but it seems confusable with 'column' as you note. I didn't know about {{collapse-top}}; it seems there are ever more column templates I'm finding. The current {{nav-top}}, which I'm proposing to rename to {{ctop}} or {{box-top}}, should work as well as {{collapse-top}}, and the two should be merged. As for uses of {{rel-top}} for collapsing functionality, this appears to work because the items are raw paragraphs rather than list items, and we should be able to check for this by looking for * or # at the beginning of the lines. Benwing2 (talk) 03:52, 25 December 2022 (UTC)

Box-top sounds fine, or frankly we could just keep the very plainly named T:collapse-top (at least as a redirect). Maybe we should avoid using col- or c- for either columns or collapsing, given the ambiguity. - -sche (discuss) 20:19, 26 December 2022 (UTC)

Having thought about this some more, I am not sure if it is a good idea to delete {{bl}}. In certain cases, chiefly complex nested lists of descendants, it can be valuable to have the ability to break the CSS columns manually. It feels neater to me to do that with a template than with a pure blank line in the wikitext, which is more fragile. This, that and the other (talk) 10:28, 26 December 2022 (UTC)

Yeah, a blank line seems liable to be removed as an error / stray whitespace, whereas {{bl}} is at least clearly intentional. If there are cases where we need to insert blank lines, I suppose it's reasonable to have a template for it. - -sche (discuss) 20:19, 26 December 2022 (UTC)

(No objection to deleting the redirect from T:topspan, though, which seems little-used and unintuitively-named.) - -sche (discuss) 04:40, 27 December 2022 (UTC)

Regarding hrow, it also seems to be used in Irish pronunciation sections, and could of course be deployed to other proto-languages besides Slavic, but ... is it better than just using the templates like desc-top and top2 that we use to list descendants (etc) in other entries? Is there some advantage hrow has over those other templates, that we'd need to keep it? The proposal above to make a special-purpose template to replace hrow with just seems like pointless busywork to me; if hrow's functionality is needed, just keep or rename hrow. Or if hrow's functionality is not needed, why not just deprecate it altogether in favour of desc-top, top2, etc? - -sche (discuss) 20:33, 26 December 2022 (UTC)

@-sche Thanks again for your comments. As for {{hrow}}, it seems to force items to get laid out horizontally, which {{top3}} doesn't do, so it may be necessary to keep. Your other comments make a lot of sense and I will update the disposition column accordingly. I have a question about {{trans-top-see}} vs. {{trans-top-also}}. The latter is older and you created the former as a redirect; I would like to eliminate one, do you think {{trans-top-see}} is a better name? It has "see also" functionality so it's not obvious which name is better. Benwing2 (talk) 05:03, 27 December 2022 (UTC)

I will let -sche respond for himself, but I note that we have {{trans-see}}, {{prefixsee}}, {{seeCites}} (the name of which I can never remember), etc, so "see" would seem best. As a tangent, I have a fuzzy memory that {{also}} used to be called {{see}} too, but then it was noticed that the code see was assigned to the language Seneca, so the template had to be moved (this was in the pre-Lua days where each language code got its own template). Now {{see}} is something else. This, that and the other (talk) 06:50, 27 December 2022 (UTC)

I probably created the redirect because redirects are cheap and I could never remember what the canonical template was called. Neither name seems immediately better or worse than the other, although TTO makes a good point that -see would be consistent with other sees. (Is there a need to delete the redirect from whichever name we don't lemmatize, though? If it's just a redirect and not a separate redundant template, then it's not dulicating any template code and won't fall out of sync. OTOH I admit this one is of lower importance to keep, since typing Template:trans-top- into the search bar will bring up the right template.) - -sche (discuss) 17:05, 27 December 2022 (UTC)

(Notifying Atitarev, Tooironic, Fish bowl, Justinrleung, Mar vin kaiser, RcAlex36, The dog2, Frigoris, 沈澄心, 恨国党非蠢即坏, Michael Ly, Wpi31, ND381): Apologies for the wide ping. I'd like to get rid of the aliases for {{zh-der}} (namely {{zh-list}}, {{zh-syn-list}} and {{zh-ant-list}}). Is this OK for the Chinese editors, and if so is {{zh-der}} the correct name or should it be {{zh-list}}? Benwing2 (talk) 05:05, 27 December 2022 (UTC)

@Benwing2: I'm not sure about {{zh-list}}, but {{zh-syn-list}} and {{zh-ant-list}} need to stay because the templates {{zh-syn-saurus}} and {{zh-ant-saurus}} depend on these two, respectively. — justin(r)leung _{{ (t...) | c=› }} 06:37, 27 December 2022 (UTC)

@Justinrleung Not sure I understand. {{zh-syn-saurus}} and {{zh-ant-saurus}} do not actually depend on either {{zh-syn-list}} and {{zh-ant-list}}, but instead refer to {{zh-list}} in the module (Module:zh/templates), and since {{zh-list}} is just an alias for {{zh-der}}, it's trivial to change the module code to refer to {{zh-der}} instead. Benwing2 (talk) 06:53, 27 December 2022 (UTC)

@Benwing2: Line 179 in the the current version of the module is where the dependence on those two templates is. It's not very ideal that it's trying to extract things from the wikitext, but that's how it's currently set up. — justin(r)leung _{{ (t...) | c=› }} 07:04, 27 December 2022 (UTC)

@Justinrleung I see, why can't we just change the code to look for {{zh-der}} (or even more safely, look for {{zh-der}} inside of a =Synonyms= or =Antonyms= section, as appropriate)? Benwing2 (talk) 07:24, 27 December 2022 (UTC)

@Benwing2: If that's doable, then sure, I don't have any objections. It would seem to be inappropriate to have the one template be called "der", though, if it's used more widely than for derived terms/compounds. — justin(r)leung _{{ (t...) | c=› }} 07:37, 27 December 2022 (UTC)

@Justinrleung It seems to be called {{zh-der}} because it defaults to displaying "Derived terms from PAGENAME" -- but only when there are more than 72 entries and not on Thesaurus pages. All this Chinese-specific code is really terrible IMO. Maybe {{zh-list}} or {{zh-col}} is a better name (note that {{zh-der}} claims to work like {{der3}}, which is a redirect to {{col3}}). Benwing2 (talk) 08:07, 27 December 2022 (UTC)

@Benwing2: I agree that the Chinese-specific code is quite unsatisfactory. {{zh-col}} sounds good as a replacement, but it would probably be best to make it mirror {{col3}} behaviour, at least in the title. (Other than the 72-entry threshold, there is also a |fold= parameter that collapses the list.) — justin(r)leung _{{ (t...) | c=› }} 16:50, 27 December 2022 (UTC)j

Could we please also add Template:User:Donnanz/der4-u? Theknightwho (talk) 19:09, 30 March 2023 (UTC)

Also {{txg-der}}, which (as the largest contributor to Tangut) I think can be fully replaced by {{col-auto}}. Theknightwho (talk) 23:35, 30 March 2023 (UTC)

 Support deletion of redundant templates and redirects, and keeping the number of column temlates to a sane minimum. Taylor 49 (talk) 14:34, 4 April 2023 (UTC)

• In the new column template regime, will there be any template that alphabetizes, ignoring templates like the list family and {{vern}} and {{taxlink}}. DCDuring (talk) 13:57, 17 April 2023 (UTC)

@DCDuring That's not really possible with nested templates because the outer template sees the expansion of the inner template rather than the template itself. The best solution I think is a specialized column template that supports the equivalent of {{vern}} and {{taxlink}} using inline modifiers. Benwing2 (talk) 14:39, 17 April 2023 (UTC)

Or just something that, 1., doesn't alphabetize at all, 2., doesn't have a required lang parameter, 3., allows specification of the number of columns, and, 4., allows a title. Collapsability and auto-balancing would also be very helpful. DCDuring (talk) 15:31, 17 April 2023 (UTC)

I've responded to the thread about this on the BP, but just putting it here that this isn't necessary, as column templates already take the formatting used by {{vern}} and {{taxlink}} into account when sorting (among others). There's a function in Module:utilities called get_plaintext which is called by Module:collation that finds the text which is actually visible on the page, and it's that which is used for sorting purposes. Previously, sorting was done in a much cruder way, which is why we had problems with this. Theknightwho (talk) 19:10, 5 May 2023 (UTC)

In the interests of making progress, here is an inventory of the remaining templates. I have removed the translation templates (not really in scope for this discussion) and grouped into the three classes identified by Benwing on 24 December 2022:

Aliased template	Canonical template	#Uses	Disposition	Progress (Jan 2025)
1. auto-collapsing (first 3 rows always visible) with items inside the template
Template:col	Template:col	177	Move |1= to |n= so it can be omitted in the future to get auto-width behavior.	Converted into auto-width template.
Template:col-auto	Template:col-auto	1714	This template is questionable, see discussion in Wiktionary:Grease pit/2022/December#col-auto.	Deprecated.
Template:col-u	Template:col-u	34	Replace with {{col|sort=0}} and delete.	Deleted.
Template:col1	Template:col1	259	Keep.	Kept.
Template:col1-u	Template:col1-u	25	Replace with {{col1|sort=0}} and delete.	Deleted.
Template:col2	Template:col2	16251	Keep.	Kept.
Template:rel2	Template:col2	3244	Keep.	Deprecated.
Template:der2	Template:col2	9124	Keep.	Deprecated.
Template:col2-u	Template:col2-u	279	Replace with {{col2|sort=0}} and delete.	Deleted.
Template:col3	Template:col3	64916	Keep.	Kept.
Template:rel3	Template:col3	6669	Keep.	Deprecated.
Template:der3	Template:col3	21969	Keep.	Deprecated.
Template:User:Donnanz/der3-u	Template:User:Donnanz/der3-u	399	Replace with {{der3}} and delete.	No longer used. We need to delete Module:columns/old or move to Donnanz's user space as soon as we remove the 20 or so uses coming from {{zh-der/fast}}.
Template:col3-u	Template:col3-u	458	Replace with {{col3|sort=0}} and delete.	Deleted.
Template:col4	Template:col4	27323	Keep.
Template:rel4	Template:col4	4491	Keep.	Deprecated.
Template:der4	Template:col4	10766	Keep.	Deprecated.
Template:col4-u	Template:col4-u	258	Replace with {{col4|sort=0}} and delete.	Deleted.
Template:col5	Template:col5	452	Keep.	Kept.
Template:col5-u	Template:col5-u	44	Replace with {{col5|sort=0}} and delete.	Deleted.
Template:col6	Template:col6	?	(recently added)	Probably convert to {{col5}} or {{col|n=6}} and delete.
Template:col6-u	Template:col6-u	?	(recently added)	Deleted.
Template:th-alt	Template:th-alt	696	Replace with {{col3}}{{alt}} and delete.
Template:th-der	Template:th-der	1860	Replace with {{col3}} and deprecate.	Deleted.
Template:th-rel	Template:th-rel	486	Replace with {{col3}} and delete.	Deleted.
Template:th-syn-list	Template:th-syn-list	858	Replace with {{col3}} and delete.	Deleted.
2. auto-collapsing (into a NavFrame) with items outside the template
Template:box-top	Template:box-top	16	Replace with {{ctop}} and delete. However, many of the uses require auditing.	Kept as primary collapsed-box non-columnal template.
Template:box-bottom	Template:box-bottom	15	Replace with {{cbottom}} and delete.	Kept as primary collapsed-box non-columnal template.
Template:Show-head	Template:box-top	16	Replace and delete.	Deleted.
Template:Show-tail	Template:box-bottom	15	Replace and delete.	Deleted.
Template:co-top	Template:co-top	357	Replace with {{ctop2|Collocations}} and delete.	Deleted.
Template:co-bottom	Template:co-bottom	356	Replace with {{cbottom}} and delete.	Deleted.
Template:cog-top	Template:cog-top	?	(recently added)	Deleted.
Template:cog-bottom	Template:cog-bottom	?	(recently added)	Deleted.
Template:collapse	Template:collapse	487	Replace with {{ctop}}, add {{cbottom}} and delete.
Template:collapse-top	Template:collapse-top	30	Delete in favor of {{nav-top}}/{{box-top}}/{{ctop}} (whatever name is chosen).	Deleted.
Template:collapse-bottom	Template:collapse-bottom	30	Delete in favor of {{nav-bottom}}/{{box-bottom}}/{{cbottom}} (whatever name is chosen).	Deleted.
Template:der-top	Template:der-top	5960	Rename to {{der-top2}} for consistency with {{top2}}, unless the header is overridden, in which case replace with {{ctop2}}. This, that and the other (talk) adds: If the template contains a simple list of {{l}} templates or bare wikilinks, and the header is not overridden, it should be auto-converted to {{der2}}. Same goes for {{der-top3}}, {{rel-top}} etc.	Deprecated.
Template:der-top3	Template:der-top3	1457	Keep unless the header is overridden, in which case replace with {{ctop3}}.	Deleted.
Template:der-top4	Template:der-top4	277	Keep unless the header is overridden, in which case replace with {{ctop4}}.	Deleted.
Template:der-top5	Template:der-top5	25	Keep unless the header is overridden, in which case replace with {{ctop5}}.	Deleted.
Template:der-bottom	Template:der-bottom	7247	Keep.	Deprecated.
Template:des-top	Template:des-top	295	Replace with {{ctop2|Descendants}} and delete.	Deleted.
Template:des-bottom	Template:des-bottom	293	Replace with {{cbottom}} and delete.	Deleted.
Template:desc-top	Template:desc-top	400	Replace with {{ctop2|Descendants}} and delete.	Deleted.
Template:desc-bottom	Template:desc-bottom	400	Replace with {{cbottom}} and delete.	Deleted.
Template:hyp-top	Template:hyp-top	25	Replace with {{ctop2|Hypernyms and hyponyms}} and delete.	Deleted.
Template:hyp-top3	Template:hyp-top3	24	Replace with {{ctop3|Hypernyms and hyponyms}} and delete.	Deleted.
Template:hyp-bottom	Template:hyp-bottom	44	Replace with {{cbottom}} and delete.	Deleted.
Template:nav-top	Template:nav-top	6	Rename to {{ctop}} and rename |columns= to |n=.	Deleted.
Template:nav-bottom	Template:nav-bottom	6	Rename to {{cbottom}}.	Deleted.
Template:rel-top	Template:rel-top	3463	Rename to {{rel-top2}} for consistency with {{top2}}, unless the header is overridden, in which case replace with {{ctop2}}. This, that and the other (talk) adds: If the template contains a simple list of {{l}} templates or bare wikilinks, and the header is not overridden, it should be auto-converted to {{rel2}}. Same goes for {{rel-top3}}, {{der-top}} etc.	Deprecated.
Template:rel-top1	Template:rel-top1	5	Keep unless the header is overridden, in which case replace with {{ctop}}.	Deleted.
Template:rel-top3	Template:rel-top3	937	Keep unless the header is overridden, in which case replace with {{ctop3}}.	Deleted.
Template:rel-top4	Template:rel-top4	394	Keep unless the header is overridden, in which case replace with {{ctop4}}.	Deleted.
Template:rel-top5	Template:rel-top5	29	Keep unless the header is overridden, in which case replace with {{ctop5}}.	Deleted.
Template:rel-bottom	Template:rel-bottom	4654	Keep.	Deprecated.
3. non-collapsing (purely creates a columnar arrangement) with items outside the template
Template:top2	Template:top2	10596	Keep.	Kept.
Template:top3	Template:top3	6277	Keep.	Kept.
Template:top4	Template:top4	3265	Keep.	Kept.
Template:top5	Template:top5	279	Keep.	Kept.
Template:bottom	Template:bottom	19656	Keep.	Kept.
Template:hcol	Template:hcol	239	Replace with {{top2}}, add {{bottom}} at the bottom and delete.	Deleted.
Template:hcol2	Template:hcol2	10	Replace with {{top2}}, add {{bottom}} at the bottom and delete.	Deleted.
Template:hcol3	Template:hcol3	13	Replace with {{top3}}, add {{bottom}} at the bottom and delete.	Deleted.
Template:hcol4	Template:hcol4	8	Replace with {{top4}}, add {{bottom}} at the bottom and delete.	Deleted.
Template:col-top	Template:col-top	1848	{{col-top|N}} is equivalent to {{topN}}. Keep for now?	Existing uses converted to {{topN}} and repurposed as a general replacement for {{der-topN}}, {{rel-topN}}, etc.
Template:col-bottom	Template:col-bottom	1807	Keep for now?	Existing uses converted to {{bottom}} and repurposed as a general replacement for {{der-bottom}}, {{rel-bottom}}, etc.
Template:rhyme list begin	Template:rhyme list begin	6641	Keep. This, that and the other (talk) adds: This is identical to {{top3}} (or the "topX" template corresponding to the chosen number of columns) except it that has a different CSS class. Not sure if it is really necessary to keep this separate.	Has to be kept as it interacts with a gadget that adds a rhyme-adder box. But should be renamed.
Template:rhyme list end	Template:rhyme list end	6639	Keep.	See comment in previous line.
Other templates needing special attention
Template:derived terms	Template:derived terms	169	See separate discussion below: #Template:derived terms
Template:templatetable	Template:templatetable	12	Inline code and delete. This, that and the other (talk) says: Rename and keep. It is used on relatively few pages, but on those pages it is used heavily.
Template:hrow	Template:hrow	2961	This is almost exclusively used for Proto-Slavic descendants. We could make a special-purpose template for this use, replace and delete. This, that and the other (talk) adds: This template has a lot of potential for complex descendants lists. I say keep, perhaps rename.
Template:topx	Template:topx	31	Replace with {{hrow}} and delete.
Template:exp-topx	Template:exp-topx	11	Replace with {{hrow}} and delete.
Template:vi-der	Template:vi-der	2230	Why do we need this? Figure out how to obsolete it.
Template:zh-der	Template:zh-der	38175	Replace with {{col3}} and deprecate.	Largely deprecated.
Template:zh-der/fast	Template:zh-der/fast	34	A failed experiment; replace with {{col3}} and delete.

Eventually I would love to see further tidying as per my comments at User:This, that and the other/column templates, but the actions set out in the table above are conservative and will result in little change to the actual display of entries. This, that and the other (talk) 01:43, 19 August 2023 (UTC)

@This, that and the other Regarding your comment on keeping {{hrow}}, I would much prefer if we actually created a dedicated template for descendant lists. This would solve many of the issues we're currently having with formatting by ensuring that descendant sections are consistent. Theknightwho (talk) 02:07, 19 August 2023 (UTC)

Thanks! I'll review this at some point soon and see if there's further progress I can make. Benwing2 (talk) 03:00, 19 August 2023 (UTC)

@This, that and the other I don't really have a horse in this race other than this, which I would like to add as feedback: I really like how {{col-auto}} removes the need to think about the number of columns and would like for it to be preserved, or at the very least for it to be replaced with another list template with similar automatic column-balancing features. Anyway, I welcome any effort to cut out dead wood and reduce bloat. — Mnemosientje (t · c) 16:00, 22 August 2023 (UTC)

I am going to replace "th-alt" with "alt" instead, better option than "col3". --Octahedron80 (talk) 13:32, 29 November 2023 (UTC)

restarting this

@This, that and the other I am thinking of restarting this process in 2025. I would like to get your thoughts. Looking through the above table I made reference to {{ctop2}} and such. I'd like instead to have them named {{col-top2}} etc., which I think would be clearer, and repurpose {{col-top}} as the generic equivalent of this. Although there seem to be around 1800 uses of {{col-top}}, many of these (perhaps the majority) are inside of Egyptian inflection templates rather than directly in Wikicode. The uses could be transitioned to {{topN}} and {{col-top}} repurposed. I would actually like to make {{col-top}} be of style 1 (auto-collapsing with first 3 rows visible); is that technically feasible? I think this is more user-friendly than having a completely hidden list, and it would complement {{box-top}} for displaying a NavBox. (We could add |hide=1 to use a NavBox if people want this functionality.) We could also create {{box}} (currently unused) as the equivalent of {{box-top}}/{{box-bottom}} where the text of the box is a parameter to the template, if that is technically feasible. Once we have {{col-top}}, we can convert things like {{hyp-top}}, {{desc-top}} and the like to use it; I would create a set of title abbreviations to make it easy to use {{col-top}} with a customized title without having to type the entire thing. The syntax could be like this for {{col-top}}:

• {{col-top|3|Descendants}}

or equivalently

• {{col-top|3|~des}}

or equivalently

• {{col-top3|~des}}

(although {{col-top3|~des}} saves only one character over {{col-top|3|~des}} so it might not be worth having). Thoughts? Note that yesterday I changed {{col}} so it subsumes the functionality of {{col-auto}} (although I would like to make the {{col}} algorithm smarter, so it computes the approximate maximum width assuming one "width element" per Latin/Greek/Cyrillic character displayed, two "width elements" per CJK character displayed, etc.; this isn't perfect but it's better than simply increasing the # of columns as the # of items increases). Benwing2 (talk) 08:21, 31 December 2024 (UTC)

@Benwing2 my thoughts:

• Style 3 templates could easily enough be made collapsible in the manner of style 1. However, as the content of the template can be fairly arbitrary, with items of varying heights (Burmese at cherry#Descendants), nested lists etc, it would only be possible to limit the display to a particular fixed height, as opposed to any number of "rows" or items. I don't think this is too much of a problem - any visual discordance could be eased using a subtle fade-out effect across the bottom:
  • some
  • items
  • Tall item
  • items
  • some
  • items
  • some
  • items
  • some
  • items
  • some
  • items
  • some
  • items
  (and then the [show more] link floats beneath the center as it does on style-1 boxes)
• There is some value in retaining a column template that doesn't have any collapsibility built in (consider uses in appendixes, Wiktionary pages, user pages, or even the existing use in the Egyptian template). Perhaps we could somehow disallow direct use of this template in entries.
• I agree that there could very well be a smarter algorithm for an auto-column template. Editors should not be determining the number of columns, because readers come to Wiktionary with all sorts of screen sizes - wide and narrow. Instead the required column width should be the determining factor, and it would be especially nice if this can be determined automatically. I proposed something similar in User:This, that and the other/column templates#Proposed state and #Template:derived terms on this page – admittedly the idea of forgoing the columnar list for <=6 elements was perhaps excessive, but I still think we shouldn't show a columnar list when each column will only contain a single element. At an absolute minimum the blue box shouldn't be shown if there is only one entry!
• Are you aware of Module:term list? We should either make use of it or delete it, to avoid any duplication.

This, that and the other (talk) 03:45, 2 January 2025 (UTC)

@Benwing2 on second thoughts the fade-out effect could be considered a bit corny; maybe something like this?

• some
• items
• Tall item
• items
• some
• items
• some
• items
• some
• items
• some
• items
• some
• items

show more ▼

This, that and the other (talk) 03:56, 2 January 2025 (UTC)

@This, that and the other Thanks for your thoughts. I think I wasn't clear enough in that I think we should keep around some templates that implement style 3 (non-collapsing) but convert style 2 templates (where the text is completely hidden by default) that are just lists to style 1 (partially hidden by default). My proposal was to repurpose {{col-top}} and {{col-bottom}}, which currently implement column-based style 3, for use as generic collapsing column-based templates with the text outside the templates, ala {{der-top}}, {{rel-top}} etc. These templates currently implement style 2; ideally the new {{col-top}} would be made to behave like style 1 rather than style 2, but if that's not feasible, then for now we can keep them as style 2. (To repeat; I want to make {{col-top}} do something different from what it currently does, after converting all current uses of {{col-top}} to use {{top2}}, {{top3}}, etc.) This would leave {{top2}}, {{top3}}, etc. for non-collapsing column-based lists. If we think we need a template that works like {{top2}}, {{top3}}, etc. but takes the # of columns as a parameter, we can call it {{topn}} since {{top}} is already taken for use with topic categories (although IMO it should be repurposed as there are lots of other aliases of {{top}}). In response to your comments:

1. I do think the fade-out might be a bit corny, and your lower-down suggestion is better.
2. See my comment above about maintaining non-collapsing templates.
3. I will take a look at your links in more detail. My thought for a smarter algorithm was to assume a max width of say 120 chars on desktop screens (but significantly less on mobile screens), and then try to pick the max number of columns, up to say 5, where all the items will fit nicely, assuming essentially fixed-width characters but Asian characters would be double-width. Obviously it would be better if this can be done automatically in CSS and adjust to the user's actual screen size but I dunno if this is possible.
4. I looked at Module:term list and IMO it should be deleted as it seems to be a piece of crap.

Thoughts? Benwing2 (talk) 04:26, 2 January 2025 (UTC)

I should add, once we have the new {{col-top}} we can transition existing {{foo-top}} templates to either directly use {{col2}}, etc. if they're simple lists, or use {{col-top}}/{{col-bottom}} if the content is too weird. Then we can get rid of all the existing {{foo-top}} templates other than {{col-top}}, similarly to how we've eliminated the former style-1 templates {{rel2}}, {{der3}}, {{hyp4}} etc. or made them redirects. Benwing2 (talk) 04:29, 2 January 2025 (UTC)

BTW I think it's time to get rid of the redirects {{rel2}}, {{rel3}}, {{rel4}}, {{der2}}, {{der3}} and {{der4}}, per suggestion of @Theknightwho. They have been redirects for nearly 6 years (since Mar 2019) and don't serve any purpose, yet people are still using them in place of {{col2}}, etc. I am actually doing a run to orphan {{rel2}}, which is probably the least used of the 6, but I'll pause before any other renames to get your thoughts. Benwing2 (talk) 07:28, 2 January 2025 (UTC)

Also I agree with the idea of making lists with less than a certain number of items simply display as lists. I'm not sure where the cutoff should be; 5 or less becomes a simple list? Benwing2 (talk) 09:03, 2 January 2025 (UTC)

@Benwing2 ah, I see! That makes more sense. After I posted my reply and thought more about some of the ways style-3 templates are used, I wondered whether there was a case for keeping them as is. But yes, we are both on the same page, the differentiation between styles 1 and 2 is very confusing and needs to be tidied up.

Some responses, in no particular order:

• I see absolutely no value in the relN/derN redirects (well, other than historical preservation of course). Ongoing use of these templates is probably because editors believe they actually do something different (of course, if they were style 2 templates they would display a different heading, but style 1 templates don't have or need this feature).
• Mobile readers should not see lists presented as columns. (Note, my term "mobile readers" != mobile view, which includes tablets, who do see columns.) But I'm not sure if mobile (however we define it) needs to be special cased if the column width is defined instead of the number of columns. Most lists will end up as a single column on a narrow mobile phone screen without any extra effort.
• Rather than trying to programmatically define a number of columns, wouldn't it be better to programmatically determine the most appropriate column width and set that in inline CSS? A simple algorithm could be: for Latin text, find the maximum number of characters (or the 90th percentile?) of the entries in the list, multiply by 1.5, add 4 for the bullet, and use this value as the CSS width in ch units - up to a maximum possible column width (maybe 50ch?). For CJK there is an equivalent CSS unit ic, for which no 1.5 multiplier would be needed. For other scripts I'm not sure what the best approach would be. (And in any case, none of this is possible for style 2 templates, which don't know anything about their own content.)
• Miscellaneous note, only partly relevant: something is screwed with the CSS of {{box-top}}. See WT:Todo/Lists/Entries with missing headword lines/description - the spacing is all over the shop.

This, that and the other (talk) 10:57, 2 January 2025 (UTC)

Hmm and yes, despite what I said before, perhaps there is value in cramming in more columns when there are lots of entries (cherry#Derived terms)... which then has list length as an input to any width-determining algorithm... This, that and the other (talk) 10:59, 2 January 2025 (UTC)

@This, that and the other Thanks! I think you are right about setting the column width (or total width?) and letting the CSS do the rest. Ideally we could simply tell it to use the whole screen (possibly up to a sensible maximum, in case the user has a huge virtual desktop which goes past their actual screen) and fit however many columns can fit there; but if the screen is too small, enforce a minimum total width so you end up with horizontal scrolling rather than wrapping every 5 chars or whatever. But maybe this is currently impossible in CSS. As for {{box-top}}, someone will have to look into this, maybe @Surjection, who I think created {{box-top}}/{{nav-top}}? Benwing2 (talk) 11:04, 2 January 2025 (UTC)

Caused by Special:Diff/81569868, @Ioaxxere — SURJECTION ^{/ T / C / L /} 11:09, 2 January 2025 (UTC)

@Benwing2 I am assuming the boxes would still span the width of the screen just as they do today. Since Vector 2022 is now the default, we don't really have to worry about boxes awkwardly sprawling all the way across a giant wide monitor. (Anyone who sees such a thing has actively chosen that experience for themselves.)

What I'm suggesting is that the module generates a CSS style attribute specifying the width of the columns, leaving it to the user's browser to do the math to work out how many columns can fit within the available width. Other possible approaches would be to simply predefine the column width in global CSS (this is how {{trans-top}} works) and allow users to manually override the column width using a template parameter (offering an override may be necessary even if an automatic width-calculating solution is implemented).

If there are (say) <5 or <4 elements or whatever, we just display a flat list.

@Ioaxxere this CSS is very messy, NavContent has to work with {{trans-top}}, {{der-top}} and {{box-top}}... I'm scratching my head over how to fix this. We can get rid of the special rules for <p> elements in NavContent if we change NavContent to use display: flow-root, but that requires JS changes... This, that and the other (talk) 11:38, 2 January 2025 (UTC)

I completely agree that if there are, say, five or fewer items they should just be displayed as an ordinary list without columns. It’s really weird when editors use these column templates for as few as one or two items. — Sgconlaw (talk) 11:52, 2 January 2025 (UTC)

@Sgconlaw Ideally there would be one template, and you just put in however many items you need. How it displays should then be determined accordingly. Theknightwho (talk) 13:17, 3 January 2025 (UTC)

@Sgconlaw: (also @Benwing2), I completely disagree here. I think it's way more space-efficient and neat for lists with, say, 3 items to be placed on 3 columns than to have them make up a list. MedK1 (talk) 12:52, 8 January 2025 (UTC)

@This, that and the other: Currently we're using the column-count, but it seems like we should switch over to using the columns attribute which lets you also specify the width to allow the number of columns to dynamically change across screen sizes. As for the NavFrame thing, I changed it because otherwise {{rel-top}} (e.g. at apple) looks like crap. I'm not sure exactly what we should do but avoiding complex layouts inside a NavFrame seems like a good idea. I was able to hack a fix for your project page ([1]) by just adding an additional div in between which stops the selectors from matching. Ioaxxere (talk) 05:09, 3 January 2025 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ @This, that and the other I have obsoleted {{der2}}, {{der3}}, {{der4}}, {{rel2}}, {{rel3}} and {{rel4}}; replaced all uses of {{col-top}}/{{col-bottom}} with {{topN}}/{{bottom}}, and rewritten {{col-top}}/{{col-bottom}} as described above. For reference, {{col-top}} supports title shortcuts that should obsolete having more specific variants. The following is the shortcut list from the documentation:

Shortcut	Expansion
alt	Alternative forms
ant	Antonyms
co or col	Collocations
cog	Cognates
com	Compounds
cot	Coordinate terms
der	Derived terms
des or desc	Descendants
dia	Dialects
id	Idioms
hyp	Hypernyms and hyponyms
prov	Proverbs
ref	References
rel	Related terms
see	See also
syn	Synonyms
tr or trans	Translations

(The current syntax is {{col-top|2|rel}} or similar. Maybe we should have {{col-top2}}, {{col-top3}} and {{col-top4}} as well, since people seem used to them and they save a character.)

I am planning on obsoleting some of the {{foo-top}} templates using {{col-top}}, starting with {{co-top}}, {{hyp-top}} and {{desc-top}} as well as all uses of {{rel-top}} and {{der-top}} that have a title specified. BTW the following are the top 20 titles/non-titles specified for {{der-top*}}:

3995 {{der-top
1028 {{der-top3|Compounds
 935 {{der-top|Compounds
 822 {{der-top3
 160 {{der-top4
  97 {{der-top|Idioms
  66 {{der-top4|Compounds
  39 {{der-top|Synonyms
  26 {{der-top|Proverbs
  16 {{der-top|See also
  16 {{der-top|Derived terms
  15 {{der-top|Descendants
  14 {{der-top3|Idioms
  13 {{der-top|Cognates
  12 {{der-top|
   8 {{der-top|Prefixed verbs
   6 {{der-top|Nouns
   6 {{der-top|Coordinate terms
   5 {{der-top|verbs with prefixes
   5 {{der-top|Hyponyms

This adds up to 7,284 uses out of 7,932; almost all of the remainder have an explicit title. The same top 20 for {{rel-top*}}:

 765 {{rel-top
 344 {{rel-top|cognates
 336 {{rel-top|Cognates
 314 {{rel-top|click to expand
 200 {{rel-top4
 187 {{rel-top3
 162 {{rel-top|dialectal pronunciations
  90 {{rel-top|Derived terms
  59 {{rel-top|Cognates:
  50 {{rel-top|dialects
  42 {{rel-top|Dialects
  38 {{rel-top|list of cognates
  34 {{rel-top|Korean words of interest
  32 {{rel-top|
  30 {{rel-top|Related terms
  27 {{rel-top|European words of interest
  26 {{rel-top|Eurasian words of interest
  23 {{rel-top|Refs
  21 {{rel-top|Alternative forms
  17 {{rel-top|Family tree

This represents 2,797 of 6,013 uses. The reason why the tail is so much longer here is that there are a ton of uses that say terms derived from FOO or terms inherited from FOO or verbs related to FOO or prefixed forms of FOO where we should consider truncating the FOO as it's usually the pagename.

As for computing a column width, sure, but why can't CSS work that out for itself? But assuming it can't, I'm onboard with your solution. I also am planning on implementing the idea that if there are <= 5 (or 4?) items in a {{col}} invocation, they are just displayed as a plain list. Also @Sgconlaw, Theknightwho, Vininn126, Ioaxxere for thoughts. Benwing2 (talk) 05:17, 3 January 2025 (UTC)

Also, IMO we should convert as many uses of {{foo-top}} and {{topN}} as possible to style 1 with {{col}}. I may tackle that afterwards; I need to write a script to handle that. (I think User:JeffDoozan already has a script for exactly this purpose but I don't know if they will respond to the ping. If so, can you point me to or send me your source code? It might help make it easier for me.) Benwing2 (talk) 05:20, 3 January 2025 (UTC)

Thanks for working on simplifying all of this, Benwing2. My code for converting various lists/templates to {{col}} is here and tests are here. It's probably easiest to look at the tests to get an idea of how it works. It imports an external function nest_aware_resplit() and constants ALL_LANGS / ALL_LANG_IDS plus a package enwiktionary_sectionparser, but you probably won't need the constants or the package unless you want to limit it to editing specific languages or sections. I'm happy to answer any questions about the code and I can also adjust and run the script myself if that's easier. JeffDoozan (talk) 13:42, 3 January 2025 (UTC)

I'm for massive simplification here. We really don't need that many templates with similar functions. Vininn126 (talk) 14:08, 3 January 2025 (UTC)

@Benwing2 it's exciting to see progress on this!

In CSS you either have to specify the column count or column width. There's no "auto" mode (the relevant CSS properties do have an auto keyword but it doesn't do anything useful). So we need to roll our own logic on this front.

By the way, on the mobile site, {{col-top}} is missing its bullets and doesn't display in columns at all, even in tablet view. I'm happy to look into this when I'm on a computer later, but just noting it for now. This, that and the other (talk) 02:30, 4 January 2025 (UTC)

@This, that and the other Thanks, please do look into it. I tried to copy exactly the Wikicode of {{der-top}}, just modifying the title. Benwing2 (talk) 03:38, 4 January 2025 (UTC)

@This, that and the other The issue is not related to {{col-top}} as it occurs in {{der-top}} and other column templates. It must be one of the changes recently done to MediaWiki:Gadget-Site.css. Looking through those changes I found an apparent stray character which I removed in [2]; perhaps this will fix it. Benwing2 (talk) 04:03, 4 January 2025 (UTC)

That didn't do it unfortunately. But in other news, {{desc-top}}/{{desc-bottom}}, {{hyp-top}}/{{hyp-top3}}/{{hyp-bottom}}, {{co-top}}/{{co-bottom}}, and recently-created {{cog-top}}/{{cog-bottom}} are all gone. Benwing2 (talk) 05:08, 4 January 2025 (UTC)

@Benwing2 I fixed the mobile CSS issue: Special:Diff/82803712/83453845.

Anyway, hopefully those preset headings won't be required for too much longer as style 2 templates get converted to style 1. This, that and the other (talk) 09:15, 4 January 2025 (UTC)

@This, that and the other Thank you! I am currently converting the remaining {{rel-top}}/{{der-top}}/etc. to {{col-top}}. I wrote a script to convert style 2 templates to style 1 when possible, and with minimal work it should be fixable to work on style 3 templates as well. The only thing is that not all style 2 uses can be converted to style 1 with {{col}}, e.g. those involving descendants, cognates and collocations. I am vaguely thinking of making {{col-top}} display in style 1 when the second param (box title) is omitted; I think that should be possible to implement, and it should allow most remaining style 2 uses to get converted to style 1. The alternative is to create another template for style 1 with the items outside the start/end templates, but I don't know what a good name for it would be. Benwing2 (talk) 10:07, 4 January 2025 (UTC)

@Benwing2 consider the situation at creep#Derived terms 2 - the "title" is used to provide a gloss for a set of derived terms. I'm not totally sure that I like the way we currently present titles in style 1, using the {{sense}} template that co-opts the style used elsewhere for qualifiers and labels for a sense gloss. But there is certainly no need for these to be style 2 templates, even though they do have a title. This might create a difficulty with the idea of automatically switching style 2 to style 1.

Can you share some examples of entries with style 2 templates that you think wouldn't work as style 1? That would help me to picture what you're referring to. This, that and the other (talk) 11:01, 4 January 2025 (UTC)

@Benwing2 regarding situations such as at apple#Etymology, this shouldn't even use a column template, as it just contains simple text. Perhaps we need to separate style 2 into:

• style 2a - auto-collapsing (NavFrame-based) box where the only content between the -top and -bottom templates is a bulleted list, intended to be displayed in columns
• style 2b - auto-collapsing (NavFrame-based) box with other content between the -top and -bottom templates, not intended to be displayed in columns

Style 2a can mostly (or all?) be converted to style 1. Style 2b should be migrated to a template such as {{box-top}} that doesn't include the blue background intended for term lists. This, that and the other (talk) 11:21, 4 January 2025 (UTC)

@This, that and the other In my conversion script I've been using {{q}} followed a colon for titles, to mimic the current use of {{sense}}, but not displaying any title when it would be the same as the section header. Not sure if there's a better way to do this. Benwing2 (talk) 20:24, 4 January 2025 (UTC)

@Benwing2 shouldn't you be using the |title= parameter of {{col}} for this? This, that and the other (talk) 22:09, 4 January 2025 (UTC)

@This, that and the other Yes, I should; I didn't even realize this param existed. I will update my script accordingly. Benwing2 (talk) 22:12, 4 January 2025 (UTC)

BTW there may be call for a param on {{col-top}} to turn off the blue background. In particular, when I converted {{egy-conj-table}} from the old {{col-top}} to {{top2}} (used for footnotes), it gained a blue background, which doesn't look quite right. Benwing2 (talk) 22:15, 4 January 2025 (UTC)

In regards to uses of style-2 templates that can't be converted to style-1:

• some uses have non-bulleted lines such as headings;
• some uses have nested list items, which I can add support for, e.g. by prefixing the term with > for a single extra indent, >> for two indents, etc. ({{derived terms}} uses * for this purpose, but that conflicts with its use for indicating reconstructed terms);
• some have complex raw formatting such as this: * [[必要メモリ]] (''hitsuyō memori''): (''computing'') required memory size; this could be fixed, but might have to be done manually;
• some have pure raw text that shouldn't be made into a link, such as lists of English collocations that are completely unformatted;
• some uses of {{col-top}} are used to surround e.g. a long discussion section in Etymology that consists of a mix of raw text and lists of cognates; perhaps that should be converted to use {{box-top}}, but would have to be done by hand.

One thing I could do is add support in {{col}} for forcing a raw line, e.g. by prefixing the line with !; that should allow all lines that my script can't parse to be dumped directly into {{col}}. I dunno what you think of this. Benwing2 (talk) 22:30, 4 January 2025 (UTC)

@This, that and the other All the {{der-top*}} and {{rel-top*}} templates have been converted to {{col-top}}/{{col-bottom}}, and all are deleted except for {{der-top}}, {{rel-top}}, {{der-bottom}} and {{rel-bottom}}, which had enough uses that I kept them as deprecated. I updated the chart above with current progress; we should probably actually redo the chart as it is becoming out of date. BTW {{col6}} and {{col6-u}} were recently added; I think they should be deleted as it seems questionable to hard-code this many columns. Ping @MedK1 as the creator of {{col6}}. {{col6-u}} was created by User:Hans-Friedrich Tamke, who has been wrongly converting {{colN}} to {{colN-u}} for no clear reason and was recently blocked for a week for their tendency to make bad formatting-related changes and not respond to talk page messages (except sometimes in a dismissive tone). Most of the {{colN-u}} templates should be converted to {{colN}}, although they may have to be audited by hand to see which ones genuinely should stay unsorted. Benwing2 (talk) 23:55, 4 January 2025 (UTC)

I created col6 mostly so I could use them for the lists in my userpage and save up screen space. Since then, it appears that quite a few standard pages are using it as well.

If we do go ahead with deleting the col6 template, how would I get 6 columns in a case where col-auto would give me less than that?

I skimmed along the discussion so far, and it seems like the new way to handle these is by using the col template and then an n= parameter with the number of columns on it? So I'd be doing col|n=6 instead of col6, is that it?

I'm fine with that, but then I'm left wondering: why not do the same with col1, col2, col3, col4 and col5? MedK1 (talk) 00:21, 5 January 2025 (UTC)

Yes, I would recommend {{col|n=6}}. You are right that a lot of the uses of {{col1}}, {{col2}}, {{col3}}, {{col4}}, {{col5}} etc. should just be converted to plain {{col}} (and usually without the |n= parameter); that will probably happen but it will need some discussion. Benwing2 (talk) 00:29, 5 January 2025 (UTC)

@MedK1: if it's just in your user space, you could create a copy in your userspace and use the proper wikilinking inside the {{| to link to it (i.e, {{User:MedK1/col6|). Unlike modules, templates can be anywhere, but the system interprets lack of a namespace as "Template:" when wikilinking to them. See also my use of a subpage-local template in WT:Todo/Impossible translations. Chuck Entz (talk) 01:28, 5 January 2025 (UTC)

There were about 60 uses of {{col5-u}}, and all but a few should have used {{col5}}, which I have converted. The only ones remaining are a few ones using the special CJK link templates where I'm not sure whether sorting is bad (see 紋, 乗, 撰, 穀 and 述 for Japanese; and 撰, 穀 and 述 for Korean; the fact that all three Korean pages are in the Japanese page list as well suggests that someone fond of {{col5-u}} was just using it indiscriminately); and the single pages 오대양 (with a list of oceans, possibly in a fixed order) and mestize, where the list of coordinate terms is possibly intentionally unsorted as it lists e.g. mestizo before mestiza and similarly for other gendered terms. And none of the {{col6-u}} uses were necessary so I converted them all to {{col5}}. Benwing2 (talk) 00:22, 5 January 2025 (UTC)

I audited the {{col4-u}} uses; most could be converted to {{col4}}. Some clearly want the order unsorted and some I'm unsure, so I'm flagging them for further audit: 戦, 仲, 鶴, 電子, 男性, 薬師, 蛇/derived terms (for Japanese); tôi (for Vietnamese); 巴林 (for Chinese); -ч (for Mongolian); -ος (for Modern Greek; a big YUCK on the current state of Modern Greek templates); thirrore (for Albanian noun cases). Benwing2 (talk) 00:53, 5 January 2025 (UTC)

@Theknightwho Since you know some Japanese and understand how sorting works, can you take a look at some of the Japanese pages I mention just above as having {{col4-u}} or {{col5-u}} where I'm not sure whether it's needed? I'd like to know whether the lack of sorting is intentional and needed, or whether we can take it out. Thanks! Benwing2 (talk) 00:55, 5 January 2025 (UTC)

@Benwing2 It is intentional - the problem is that there's no mechanism to sort by reading yet, so Japanese needs to use unsorted column templates for now. Theknightwho (talk) 01:03, 5 January 2025 (UTC)

@Theknightwho OK, that is good to know because I have a script to convert {{col-top}}/{{col-bottom}} to {{col}} and I will need to make the uses of {{ja-r}} etc. unsorted. What about Chinese ({{zh-l}}) and Korean ({{ko-l}})? Is it the same thing? Benwing2 (talk) 01:07, 5 January 2025 (UTC)

And Vietnamese with {{vi-l}}? Benwing2 (talk) 01:08, 5 January 2025 (UTC)

@Benwing2 did you see my message above about style 2a and style 2b? It would be good to get a list of templates that contain apparent non-list content so they can be manually audited and converted to {{box-top}} where required.

For invocations with complex syntax, we may be better off leaving them alone for now and using a "style-3-but-collapsible" template once it is created. As you may recall, I am generally averse to adding bespoke syntax where it's not needed.

As for nested lists, we can use an asterisk followed by a space as the syntax; I don't think this should clash with reconstructed terms, which wouldn't include the space. This, that and the other (talk) 01:50, 5 January 2025 (UTC)

@This, that and the other I did see your message, and I left you a message up above enumerating a bunch of cases that use style 2 that can't be automatically be converted to style 1. If you want a full list of pages that can't be converted and their reasons, that will take a bit longer to generate as my script doesn't (yet) do that. Can you explain the difference between style 1 and "style-3-but-collapsible"? Also I'm fine using asterisk + space, as long as it's made clear in the documentation that the space is needed. BTW I am going to add to {{col}} the ability to have multiple comma-separated terms on a single line, as long as the comma is not followed by a space and does not occur inside of a link. I already have the code written for this (parse_inline_modifiers in Module:parse utilities), and it's used in all form-of templates currently. The reason for doing this is that there are quite a lot of existing lists using {{col-top}} and also {{col}} that have multiple items in a single entry, and I would rather support them properly than force people to put {{l}} templates inside of {{col}} items. Benwing2 (talk) 02:10, 5 January 2025 (UTC)

@Benwing2 thanks! Sorry, this conversation is rather confusing. Yes I saw that message. Useful to know. I think a list of non-convertible entries will be useful ultimately, but not necessary for the time being.

Style 1 has the items inside the template, and achieves collapsibility by actually hiding individual <li> elements within the list (so that collapsing and uncollapsing a style 1 list sometimes produces strange effects with nested lists, and the logic also struggles to deal with lists where some items wrap across two or more lines). On the other hand, "style 3 but collapsible" would be a style 3 list with items outside the template (for now) using the CSS-based collapsibility I showcased above, where collapsibility is achieved by simply fixing the template's height, truncating the template at that point when collapsed. This, that and the other (talk) 03:08, 5 January 2025 (UTC)

@This, that and the other I see, thank you. Can you design an appropriate collapsible style 3 template? It might even make sense to make {{top2}} et al. be collapsing by default and require a flag to turn it off. Benwing2 (talk) 03:40, 5 January 2025 (UTC)

@Benwing2 initial draft at {{topN-collapsible}}. Still a bit buggy. I'm not wedded to that name - can be moved later. This, that and the other (talk) 08:42, 5 January 2025 (UTC)

The bugs I know about are fixed now. I put the template in use at apple#Descendants as a test. This, that and the other (talk) 11:04, 5 January 2025 (UTC)

Template:hcol vs. Template:top4 etc.

@This, that and the other I've been experimenting with {{hcol}} and {{top4}}/{{top5}}, and {{hcol}} seems to have better behavior in various ways, even without the issue of whether you have to specify {{bottom}} (which makes {{hcol}} slightly more convenient but seems to limit its applicability somewhat). See User:Benwing2/test-hcol for a head-to-head comparison.

1. {{topN}} always takes up the entire screen width, which seems pointless on very wide screens like I have, whereas {{hcol}} uses only as much width as needed.
2. {{topN}} on mobile is always a single column regardless of width, but {{hcol}} on mobile shows up as up to 4 columns, and only goes down to 1 column when I resize the width below a certain point.
3. Both templates auto-reduce the number of columns as you shrink the width (which is good), but at a certain narrowness {{hcol}} also seems to imposes a minimum width below which you get fewer columns (maybe only one), while {{topN}} continues to reduce the width until you get extremely narrow columns that are essentially unreadable, before it finally shrinks the number of columns.

Can we adopt these improvements from {{hcol}} into {{topN}}? Especially (1) and (2) seem big wins. If possible, I assume they can be made to apply to {{col-top}} and {{col}} as well (maybe automatically if they use the same CSS class). Benwing2 (talk) 07:30, 5 January 2025 (UTC)

@Benwing2

1. Personally I'd prefer a template that spans the whole width of the page. Otherwise, where multiple derived terms boxes, *nyms boxes, etc. sit one beneath the other, it will look janky. But it's easy enough to make a template occupy only the required width if desired. (Keep in mind that readers now see the width-limited Vector 2022 by default - did you say you personally chose to stay on classic Vector?)
2. On screens narrower than 640px, {{hcol}} reverts back to one column (and loses the blue background - this is probably incorrect behaviour). On wider screens, it imposes a fixed column count as requested by the user.
3. You say that both templates "auto-reduce the number of columns as you shrink the width", but I don't see this behaviour. With {{top4}} I see this, while {{hcol}} simply reverts to one column below 640px, as described above. This is in Microsoft Edge 131 on Windows. Perhaps behaviour is different on other browsers.

This, that and the other (talk) 08:22, 5 January 2025 (UTC)

@This, that and the other Thanks. My test file is User:Benwing2/test-hcol and I'm running on Chrome 131.0.6778.205 on Mac OS. The test file has 5 columns; for some reason, both tables shrink to 4 columns as you shrink the width, then it stays at 4 columns until you get below 640px, at which point hcol shrinks to one column (and no blue background, you are right). Just above the 640px point, hcol seems to do a better job with the space than top5 does; see [3]. More specifically, at around 800-900px, the hcol column width stops shrinking until you get to 640px, while top5 continues to shrink. This BTW is on Vector 2010; I am not using Vector 2022. Also have you thought of joining Discord? These sorts of conversations are easier on Discord, and also you can easily post screen shots and videos without having to resort to sites like imgur.com. Benwing2 (talk) 20:33, 5 January 2025 (UTC)

BTW I got rid of all uses of {{hcol*}}, {{collapse-top}} and {{collapse-bottom}}, but kept copies of {{hcol}}, {{collapse-top}} and {{collapse-bottom}} in my userspace; in the former case because there may be something worth salvaging from {{hcol}} per our previous discussion, and similarly for the latter two templates, which allow customization that {{box-top}} doesn't allow. (Not that this is necessarily a good idea; in most cases the customization of background color and such is actually a bad idea because it makes the template fail to work correctly in dark mode. But maybe, for example, the alignment or table class is worth making customizable in rare cases.) Benwing2 (talk) 05:00, 6 January 2025 (UTC)

One more thing; I am planning on renaming:

• {{collapse}} -> {{box}};
• {{rhyme list begin}} -> {{rhyme-top}};
• {{rhyme list end}} -> {{rhyme-end}} {{rhyme-bottom}}.

What do you think? IMO {{box}}/{{collapse}} seems useful as the "content inside the template" equivalent of {{box-top}} and {{box-bottom}}, just as we have {{col}} as the approximate "content inside" equivalent of {{col-top}} and {{col-bottom}}. As for {{rhyme list begin}}, it interacts with the Rhyme adder gadget MediaWiki:Gadget-RhymesAdder.js, and it doesn't work if you replace {{rhyme list begin}} with {{top3}}. So either we need to keep {{rhyme list begin}} in some form, possibly renamed; or change the Rhyme adder gadget to work with {{top3}} and such; or change {{top3}} to include the CSS class rhymes-list-begin in it. Thoughts? Benwing2 (talk) 06:27, 6 January 2025 (UTC)

Should be {{rhyme-bottom}} for consistency, no? Ultimateria (talk) 18:24, 6 January 2025 (UTC)

@Ultimateria Yes, thanks, that's what I meant :) Benwing2 (talk) 20:32, 6 January 2025 (UTC)

@Benwing2 Yes!! This sort of consistent naming scheme is what has been missing from the entire set of templates all along.

I think it's best to keep a separate template for the rhymes namespace to allow for any future styling changes. Also if you start using {{top3}}, people will come along and say "hmm, well why don't I use {{top2}} or {{top4}} here, because I have an especially narrow/wide screen", and then you get inconsistency. I'm on board with renaming the existing template to {{rhyme-top}} as you propose.

I suspect we can now delete {{derived terms}} as well, although I haven't carefully re-read that discussion. The only "interesting" features of that template that ought to be re-implemented in {{col}} are (a) duplicate entry removal and (b) some kind of improved handling when there are very few items - both of which issues can be demonstrated with {{col|en|test|test}} ⇒

• test

This, that and the other (talk) 23:32, 6 January 2025 (UTC)

@This, that and the other {{derived terms}} also has support for nested items, although the support (and in general everything about Module:term list) is rather janky (I think it only supports one level of nesting; I'm not sure the sorting works correctly in the presence of nested items; and in the presence of nesting, it turns everything into a collapsed box). I am in the process of implementing support for arbitrary levels of nesting in {{col}}, using the format you proposed (one or more asterisks + space indicates nesting). I am not sure if there are special considerations for the CSS that needs to be specified in the presence of nested items; maybe it needs to use your style-3 collapsible implementation? In general is there a reason we can't use that implementation everywhere? I have also already implemented support for multiple comma-separated subitems in a single item, since (as I mentioned before) this shows up quite a lot in the existing {{topN}} and {{col-top}}/{{col-bottom}} lists. Benwing2 (talk) 23:46, 6 January 2025 (UTC)

Interestingly, the substing code in Module:columns removes duplicates but not the regular code path; it should be easy enough to implement though. Benwing2 (talk) 23:49, 6 January 2025 (UTC)

@Benwing2 hmm, I wonder if that was done for Lua memory-related reasons. But that seems to be a non-issue nowadays.

I have to say I have wondered why the somewhat dodgy style 1 collapsibility implementation was coded in such a strange and fragile way. I found the relevant discussion at Wiktionary:Beer_parlour/2018/November#Discussion,_part_2. The idea of cutting the box off at a certain height was rejected because it would sometimes cut through the text of individual list elements. However, for Latin-script entries at least, this should be able to be mitigated by using the CSS lh units of measurement, which automatically adapts to the line height of the user's chosen skin. (These units are not accepted by MediaWiki's CSS sanitiser so can't be used in the current implementation of {{topN-collapsible}} that uses TemplateStyles, but global site CSS is not subject to sanitisation, so this won't be an issue if/when the CSS is moved there.) Derived terms spanning multiple lines could still be truncated between lines, but I think this is acceptable - the current behaviour is already dodgy, and the occurrence of this issue can be mitigated by choosing a sensible column width.

Before swapping to the new implementation, I should check that breakage on obsolete browser versions doesn't lead to the collapsible boxes being stuck closed, unable to be viewed. This, that and the other (talk) 00:40, 7 January 2025 (UTC)

@This, that and the other OK sounds good to me! Benwing2 (talk) 00:46, 7 January 2025 (UTC)

@Benwing2 On old browsers that don't support ResizeObserver the show/hide button is always visible, even if the box has only one or two rows of elements. While this could be worked around, I think it is an acceptable tradeoff, given that (a) 95.7% of global users use a compatible browser and (b) there is no loss of visible information for the other 4.3%.

I've also implemented a "buffer zone" so that the show/hide button will only show if there is more than 20 pixels difference between the collapsed and uncollapsed states, preventing the silly situation where clicking "show more" only reveals a few extra pixels of height.

My test page is User:This, that and the other/apple test.

I think the style-3-collapsible logic as seen in {{topN-collapsible}} should be good to go now. What is your intention? Shall I put the CSS in MediaWiki:Gadget-Site.css? This, that and the other (talk) 03:55, 7 January 2025 (UTC)

@This, that and the other Yes, please do. I think we should probably use it in place of the style-1 CSS, what do you think? Benwing2 (talk) 04:12, 7 January 2025 (UTC)

I wonder if we should also make style-3 noncollapsible templates switch to style-3 collapsible by default instead, and provide new templates to do non-collapsing style-3 (e.g. {{nctop2}}, {{nctop3}} etc. where nc = non-collapsing; or {{ftop2}}, {{ftop3}} where f=fixed; or something). What do you think? Benwing2 (talk) 04:16, 7 January 2025 (UTC)

@Benwing2 okay, I'll working on placing the necessary CSS in Site.css, and replacing the style 1 logic with this logic. We can see if anyone comes after us with angry pitchforks.

FYI, I created {{start-new-col}} to replace the use of {{bl}} with {{topx}} (or namely {{exp-topx}}, which I just removed from its sole use and deleted}}. Shouldn't be needed very often, but it's there. This, that and the other (talk) 05:03, 7 January 2025 (UTC)

Thanks! Benwing2 (talk) 05:11, 7 January 2025 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘

@Benwing2 all done. So now the template landscape looks like this:

Template	How items are passed in	Comment
Style 1. auto-collapsing (first 3 rows always visible)
Template:col	Items passed in as parameters	Move |1= to |n= so it can be omitted in the future to get auto-width behavior.
Template:col1	Items passed in as parameters	Kept.
Template:col2	Items passed in as parameters	Kept.
Template:col3	Items passed in as parameters	Kept.
Template:col4	Items passed in as parameters	Keep.
Template:col5	Items passed in as parameters	Kept.
Template:col6	Items passed in as parameters	Probably convert to {{col5}} or {{col|n=6}} and delete.
Template:th-alt	Items passed in as parameters	Replace with {{col3}}{{alt}} and delete.
Template:topN-collapsible	Items placed between top/bottom templates	Needs a better name!!
Template:bottomN-collapsible	Items placed between top/bottom templates	Needs a better name!!
Style 2a. auto-collapsing (into a NavFrame) for a term list
Template:col-top	Items placed between top/bottom templates	Convert to style 1 or 2b as appropriate
Template:col-bottom	Items placed between top/bottom templates	Convert to style 1 or 2b as appropriate
Style 2b. auto-collapsing (into a NavFrame) for textual content
Template:box-top	Items (content) placed between top/bottom templates
Template:box-bottom	Items (content) placed between top/bottom templates
Template:box	Items (content) passed in as a parameter	Implemented simply as {{box-top}} + content + {{box-bottom}}.
Style 3. non-collapsing (purely creates a columnar arrangement)
Template:top2	Items placed between top/bottom templates
Template:top3	Items placed between top/bottom templates
Template:top4	Items placed between top/bottom templates
Template:top5	Items placed between top/bottom templates
Template:bottom	Items placed between top/bottom templates
Template:rhyme-top	Items placed between top/bottom templates
Template:rhyme-bottom	Items placed between top/bottom templates
Other templates needing special attention
Template:derived terms	Items passed in as parameters	Delete
Template:hrow	Items placed after the template	This seems useful, and fulfils a need not met by any of the other templates. Keep as is?
Template:topx	Items placed after the template	Should be possible to replace with {{hrow}} and delete? Investigate.
Template:vi-der		Why do we need this? Figure out how to obsolete it.
Template:zh-der		Largely deprecated.
Template:zh-der/fast		A failed experiment; replace with {{col3}} and delete.

Plus the modules Module:term list and Module:columns/old need to go as well. This, that and the other (talk) 06:31, 7 January 2025 (UTC)

@Benwing2 I can see I omitted to reply to this comment. Surely this could be achieved by a parameter, without requiring a whole separate template. When the parameter is passed in, the outer <div> can simply be a plain <div> with no CSSS classes.

Note that I did not make any change to Style 3 templates for the time being. These templates seem to mainly be used in descendants sections, and there is no widespread practice of collapsing descendants lists – yes, this is probably only because the infrastructure doesn't exist to do it, but still... I suggest that, to start with, we change any existing style 2 templates that appear in descendants sections to {{topN-collapsible}}, and seek community feedback after having done so. This, that and the other (talk) 06:45, 7 January 2025 (UTC)

@This, that and the other Thanks for redoing the table and the changes to style 1! I agree about having a parameter to turn off collapsing in {{top2}} and such. I am still working on changes to Module:columns and improvements to my script to convert {{top*}} and {{col-top}} to {{col}}. After doing the conversion I'll need to do some manual auditing because a few of the tables that use {{top*}} or {{col-top}} are intentionally unsorted and need a |sort=0 parameter. Benwing2 (talk) 07:35, 7 January 2025 (UTC)

@This, that and the other Apparently the bullets on the left side of style 1 tables are cut off on mobile; can you take a look? Benwing2 (talk) 20:22, 7 January 2025 (UTC)

Also, I have pushed my changes to Module:columns, which now:

1. supports indented terms at arbitrary indents, and sorts in such a way that items indented under a given item are tethered to that item and sorting of each sublist is independent;
2. supports multiple items in a given row, separated by a comma not followed by a space;
3. displays a simple list if the total number of items is <= 4;
4. turns off sorting for now for Japanese-script languages per discussion with User:Theknightwho, since it doesn't work properly.

The only thing not yet implemented is deduplication, which shouldn't be hard. I am going to run my script pretty soon to convert uses of {{col-top}} and {{top*}} to {{col}}. Benwing2 (talk) 04:12, 8 January 2025 (UTC)

@Benwing2, This, that and the other: regarding the handling of duplicate entries, I’d like to suggest that the module highlight (for example, I’ve seen the use of green text which is struck out in other templates) rather than hide them so that editors can spot and remove them. — Sgconlaw (talk) 05:16, 8 January 2025 (UTC)

@Sgconlaw I have to ask - why? In my experience, duplicate entries are virtually never errors requiring fixing (other than removing the duplicate). It is almost always a case of someone adding a (valid) term to the list without noticing that it was already present. This, that and the other (talk) 05:33, 8 January 2025 (UTC)

@This, that and the other: isn’t it useful to be able to discover and remove these duplicate terms? Anyway, it’s not a biggie to me. Ensuring that module can automatically sort entries (including those using wikitext markup, {{l}}, {{vern}}, etc.) is more important. — Sgconlaw (talk) 05:46, 8 January 2025 (UTC)

@Sgconlaw In my tests, the module does correctly sort entries with markup in them; it uses a function that strips markup when computing the sort key. Benwing2 (talk) 05:54, 8 January 2025 (UTC)

@Sgconlaw @This, that and the other I implemented deduplication. It works on the rendered text rather than the Wiki source. In the presence of nested indented items, it can actually deduplicate entire subtrees; see User:Benwing2/test-col for an example with guinea pigs. If we want to implement the cross-out idea rather than just removing the duplicates, that's easy enough to do. Benwing2 (talk) 06:25, 8 January 2025 (UTC)

@This, that and the other The script to convert {{col-top}} (not yet {{top*}}) is running. Many of the rejected cases should be converted to {{box-top}} or {{box}}, but need manual checking. Benwing2 (talk) 06:48, 8 January 2025 (UTC)

@Benwing2 re cut off bullets, we have 3 CSS classes that seem to do more or less the same thing: .derivedterms, .term-list and .columns-bg. The issue arises because certain CSS rules are applied to some of these classes but not others. Do you have any opinions on these classes? I'm inclined to unify and/or rename them to the greatest extent possible without disturbing functionality. This, that and the other (talk) 05:29, 8 January 2025 (UTC)

@This, that and the other Please do unify them. I have pushed all my changes so you won't be conflicting with anything in flight. Benwing2 (talk) 05:31, 8 January 2025 (UTC)

BTW I would recommend a name that clearly suggests its purpose, which none of these really do. Benwing2 (talk) 05:32, 8 January 2025 (UTC)

@Benwing2 I'm inclined to keep term-list as is. The class is only used from JavaScript to - well - identify the element that contains the actual term list within a template, so the name makes enough sense to me. The background colour was applied from columns-bg - this name seems to make sense too. Since you think these names are inferior, can you suggest better ones?

I will kill off derivedterms and replace it with either or both of the other two classes as required. This, that and the other (talk) 07:20, 8 January 2025 (UTC)

OK, I didn't realize their purposes. columns-bg seems fine; maybe term-list should be term-list-javascript or something that makes it obvious that it's used by JavaScript, otherwise people will go looking in MediaWiki:Gadget-Site.css and not find anything and will be confused. However, at the end of the day feel free to choose whatever names make the most sense to you. Benwing2 (talk) 07:42, 8 January 2025 (UTC)

Noting for posterity that derivedterms has been largely killed off.

I also took the liberty to add proper, modern collapsibility to {{prefixsee}} and friends. This, that and the other (talk) 11:31, 8 January 2025 (UTC)

This is good for consistency, but it isn't really properly implemented: the lists are now "double collapsible" and the title looks like it's one of the entries in the list.

Stujul (talk) 11:48, 8 January 2025 (UTC)

@Stujul I left the title in on purpose - it makes it clear that the list is being generated automatically from the category. The title is at a different indentation level from the remaining list items. Hardly perfect, but I figured it was good enough to start with.

I agree that the collapsibility triangle should be suppressed. Will look into doing that.

And I'm very much open to ideas on how to improve the appearance of this template. This, that and the other (talk) 12:13, 8 January 2025 (UTC)

Of course the title should stay, it's just in a weird position. It should sit on top of the box, not inside of it, to make it distinct from the items in the list. You mention {{rootsee}} below. There, the title is much more easily distinguished from the rest of the list.

Stujul (talk) 11:05, 9 January 2025 (UTC)

@Stujul @Trooper57 how now? This, that and the other (talk) 11:56, 9 January 2025 (UTC)

This looks a lot better, thanks! I am thinking that maybe that triangle should be removed, since it doesn't really serve a purpose anymore. What do you think?

Stujul (talk) 12:07, 9 January 2025 (UTC)

Looks better now, thanks. Just think it made more sense when it was fully collapsible like in {{rootsee}}, instead of showing the first 9 terms. Not really a big deal. Trooper57 (talk) 15:02, 9 January 2025 (UTC)

Commenting to say I am not a fan of having bare lists unless a certain number of items is present - I prefer a consistent look. Vininn126 (talk) 10:03, 8 January 2025 (UTC)

@This, that and the other @Sgconlaw Someone else also complained (@Stujul). Is there some other solution that will work? I understand the desire for a consistent look but at the same time having one item in a huge table seems kind of silly. Benwing2 (talk) 10:44, 8 January 2025 (UTC)

Also TTO can you look into the remaining uses of {{topx}}? There are only a few and they are mostly in Greek entries like Βιέννη, where IMO they look awful and would be better structured in some other fashion. Benwing2 (talk) 10:47, 8 January 2025 (UTC)

My main complaint is the removal of the blue background. It looks a bit silly when it is present in one list, but not the other, such as in the Related terms section of Polish absolut.

Stujul (talk) 10:55, 8 January 2025 (UTC)

I suppose that's my biggest complaint as well. I think the background also helps it stand out, which I find useful as well as aesthetically pleasing. Vininn126 (talk) 10:59, 8 January 2025 (UTC)

Yes, I have to say I was also coming around to this realisation too. Ideally we would lose the blue background only when there are no blue-backgrounded boxes "nearby" in the entry, but that's obviously impossible to automate.

@Benwing2 Perhaps we can reinstate the blue background (.columns-bg) unconditionally, but suppress the columnar display (.ul-column-count) if there are fewer items than the number of columns (not sure if this should be less-than-or-equal-to or strictly-less-than)? This, that and the other (talk) 11:22, 8 January 2025 (UTC)

Sounds good to me. Can you go ahead and do it? I'm about to go to sleep. BTW see https://imgur.com/uNVUzdH; in the presence of a float-right image, the show more line at the bottom of the screen is a different width from the rest of the table. Benwing2 (talk) 11:26, 8 January 2025 (UTC)

@Benwing2 will do! Sleep well! This, that and the other (talk) 11:28, 8 January 2025 (UTC)

@Stujul sigh, floating elements always ruin your day. This can probably be fixed, but it is very tedious so I won't attempt it just yet. This, that and the other (talk) 11:30, 8 January 2025 (UTC)

@Benwing2, This, that and the other: regarding whether a short list (five or fewer items?) should be displayed as a plain list, maybe we need to put this to a vote if there isn’t a clear consensus here. — Sgconlaw (talk) 00:29, 9 January 2025 (UTC)

@Benwing2 there appears to be a bug that's visible at salu#Swedish: when the *  prefix is combined with <...> tagging, the prefix is incorrectly interpreted as the reconstruction star. This, that and the other (talk) 00:21, 9 January 2025 (UTC)

@This, that and the other The issue was actually that some of the elements had a NBSP instead of regular space following the *. I fixed the code so it will recognize any type of Unicode space after the asterisk as indicating an indent. Benwing2 (talk) 01:02, 9 January 2025 (UTC)

@This, that and the other A couple of things:

1. I am converting uses of {{top2}}/{{bottom}} and I came across what seemed a good example of multiple indentation. See the documentation for {{col}} and look at the bottom for the Bulgarian example. Unfortunately it looks weird because one of the sublists (beginning with водо-) is very large and Chrome (at least) isn't breaking it across sublists. Is there a way to force such lists to break across sublists, either through some CSS setting or by changing the HTML in some fashion? Ideally this could be done automatically by the code if it sees a sublist more than a particular size, or we could add a parameter to {{col}} to enable it. I suppose you could always put something like водо- (1) and водо- (2) under separate headings, but that seems a bit hacky.
2. We have a complaint from User:Trooper57 about the new {{prefixsee}}/{{suffixsee}}; see [4].

Benwing2 (talk) 09:32, 9 January 2025 (UTC)

@Benwing2 it may be possible to make use of the CSS property utilised by {{start-new-col}}. If I replace the line for the word for "waterfall" with |* {{start-new-col}} {{l|bg|водопа́д|t=waterfall}}, I see some improvement in the visual layout. But the result is a bit confusing for the reader. What is really needed is to break the водо- (vodo-) nested list into two, perhaps using "водо- (continued)" at the top of the second nested list for clearer visual guidance. As for automating this, all I can think of is a heuristic like this: if a single nested list takes up more than ((100/n) + f)% of the list, where n is the number of columns and f is some relatively generous fudge factor (10?), split the nested list into chunks such that no chunk is longer than (100/n)% of the list. But can you be bothered? It seems like an edge case and it might be sufficient to allow people to do it manually.

@Trooper57 what's your complaint? I actually put some effort this morning into making {{prefixsee}} look the way it does, partly responding to Stujul's comment above. Compare with {{rootsee}}, which is un-upgraded, retaining its non-standard collapsibility and lacking bullets. If you have any suggestions on where would be better to put the "title" category link, or any other improvements, I'm all ears - noting that the HTML structure of CategoryTree imposes various limitations on what's possible. This, that and the other (talk) 10:45, 9 January 2025 (UTC)

@This, that and the other Thanks for the response. I replaced that example with another one I found which is similar but doesn't look quite so bad. You are probably right that it's not worth the effort to optimize for this. Benwing2 (talk) 10:55, 9 January 2025 (UTC)

Well, I spoke too soon. Bulgarian sorting was broken (and a whole lot of other languages still are). I fixed Bulgarian and that example (for бог) now looks terrible with 4 columns; I had to reduce it to 2 to get a reasonable result. So I suspect this isn't as edge-casy as you may think. Benwing2 (talk) 11:03, 9 January 2025 (UTC)

@Benwing2 вода (voda) really needs to use a two-column list anyway, because the items are so wide. On Vector 2022 with default settings, having more than two columns on that entry looks silly (check in your incognito window). This, that and the other (talk) 11:08, 9 January 2025 (UTC)

@This, that and the other Blah, I detest Vector 2022 for its hugely wasteful setup. I really don't know what the MediaWiki UI people were thinking, and their response to my complaint about this was highly dismissive. Anyway it seems I will need to implement the computation of column width; any ideas for the best way to do this? Benwing2 (talk) 11:14, 9 January 2025 (UTC)

@Benwing2 yes, I think so. I will get back to you tomorrow with some thoughts on this. This, that and the other (talk) 11:37, 9 January 2025 (UTC)

@Benwing2 a start: User:This, that and the other/column templates#Auto-width. It will be difficult - if possible at all - to get this "right", but there is a starting point. This, that and the other (talk) 09:28, 10 January 2025 (UTC)

If this gets too difficult we can always fall back to letting the editor set a pre-defined column width (narrow, normal, wide). This is at least a step up from letting them choose the number of columns. This, that and the other (talk) 09:31, 10 January 2025 (UTC)

@This, that and the other Thank you! Looks good; I will take a deeper look soon. It's not hard to get the raw text from formatted HTML in Lua, and there's even a function get_plaintext() in Module:utilities to do it. Benwing2 (talk) 10:37, 10 January 2025 (UTC)

@This, that and the other. My main complaint was with the title "terms prefixed with X" being inside the table and not at the top, but this has been changed already. Also, I kinda prefered when the table collapsed all the way to the top, but I'm fine with the new look if the goal is to make it consistent with {{col}}'s gang. Trooper57 (talk) 15:14, 9 January 2025 (UTC)

Associated changes

@Benwing2, This, that and the other: I've noticed that the parameter |title= in the column templates strips formatting. This doesn't seem to be desirable behaviour as that parameter is often used to display titles like "Terms derived from walk (noun)", where the lemma walk needs to be unitalicized since the title itself is italicized. Should we change this? — Sgconlaw (talk) 22:57, 12 January 2025 (UTC)

I'm not sure why that's happening; it must be a side-effect of how the CSS is being implemented. @This, that and the other can you comment? Benwing2 (talk) 23:06, 12 January 2025 (UTC)

@Benwing2 @Sgconlaw This is no new issue: you can see it in this archived version from 2020, even though the wikitext at the time had italics. I have to wonder why term list headers don't use the ib-content style, which already has style rules to solve this issue: {{sense|test ''text''}} → (test text):. Anyway this may be moot, since there is discussion at BP about overhauling the appearance of term list headers. If that doesn't go anywhere then I can look at fixing this. This, that and the other (talk) 00:29, 13 January 2025 (UTC)

@This, that and the other I don't think this issue will go away as it's occurring in the current Module:columns implementation. Can we just switch the CSS to ib-content? Benwing2 (talk) 00:51, 13 January 2025 (UTC)

@Benwing2 well my point is if we switch to the "Interim B" style, that text is not italicised, so the problem goes away. Anyway it doesn't look like there is anything requiring us to keep the dedicated term-list-header styles. Literally no-one overrode them in their personal CSS, despite the discussion. I'll just get rid of them. This, that and the other (talk) 01:23, 13 January 2025 (UTC)

I see. Thanks. IMO if no one objects, in a little while you should go ahead and switch to "Interim B", since (IMO) it's a clear improvement. Benwing2 (talk) 01:35, 13 January 2025 (UTC)

Thanks! — Sgconlaw (talk) 04:05, 13 January 2025 (UTC)

About to push new code; some existing bugs

@This, that and the other I have written the new topic-list code and added a bunch of stuff to my sandbox Module:User:Benwing2/columns to support it, including such things as horizontal lists. I'm about to deploy it, with the new title code you wrote and incorporating all the changes made to the production Module:columns in the meantime, but I notice something weird in some of the examples in User:Benwing2/test-col. See in particular this screenshot: [5] Once I click on "show less", a horizontal scroll bar appears, which is undesirable: [6] This is occurring in the production code and I haven't pushed my new code, so it's not related to it. My new code doesn't yet include the more intelligent column-width code you wrote in JavaScript, but if the lack of this code is the issue, I will go ahead and port it. Benwing2 (talk) 04:02, 22 January 2025 (UTC)

@Benwing2 thanks for the ping. I noticed this at some point too. We are requesting 2 columns, but for some reason 3 columns are rendered, with the third column falling outside the box. I suspect this is a browser bug connected with the Japanese ruby (as I have only seen it in Japanese boxes where ruby is present). Lending credence to this theory is that the behaviour is only seen in Blink-based browsers; Firefox renders your test page properly. The problem seems to go away if I give the final <li> tag a large bottom margin (e.g. margin-bottom: 1em) - perhaps that is a workaround we could apply for Japanese only? This, that and the other (talk) 06:13, 22 January 2025 (UTC)

This sounds good to me. Note that I just pushed the new code. I will implement your hack fix; will it cause any issues to have such a large margin? Benwing2 (talk) 08:26, 22 January 2025 (UTC)

@Benwing2 well, the margin will be visible, but you'll hardly notice it if there is ruby, because the spacing will already be weird in that case. This, that and the other (talk) 09:09, 22 January 2025 (UTC)

OK, sounds good. Benwing2 (talk) Benwing2 (talk) 09:12, 22 January 2025 (UTC)

@This, that and the other See also [7], which occurs at 目#Coordinate_terms. Is this the same issue? Benwing2 (talk) 04:19, 23 January 2025 (UTC)

@Benwing2 looks like a bug in the Lua; that item is missing a <li> element and is sitting outside the <ul> for some reason. This, that and the other (talk) 04:28, 23 January 2025 (UTC)

FYI I reported the bug in the Chromium issue tracker: https://issues.chromium.org/issues/391504025 This, that and the other (talk) 11:38, 23 January 2025 (UTC)

Thank you! And someone already replied. A hell of a lot better than https://phabricator.wikimedia.org/T384134 that I posted 5 days ago, with no response so far. Benwing2 (talk) 20:58, 23 January 2025 (UTC)

@Benwing2 Just noting that the Chromium bug [8] has been fixed and will presumably go out in the next versions of Chrome etc. This, that and the other (talk) 00:51, 29 January 2026 (UTC)

RFM discussion: December 2024–January 2025

See Template talk:cola#RFM discussion: December 2024–January 2025.

Language code now specifies place

@Benwing2: According the documentation, “You can prefix an individual term with a one or more language codes […] followed by a colon […]. This can be used if the term is not in the language specified in |1=.” This was used in translingual entries, or in “See also” sections (when linking to an entry of a different language), but now, e.g., en: and fr: add (England) and (France) instead of (English) and (French), respectively. I do not know when this changed but, e.g., en: and fr: in {{af}}, etc. still add the language instead of the place. J3133 (talk) 06:07, 21 March 2025 (UTC)

@J3133 This was a recent change which I've reverted. I don't have a test page to test it on, please let me know whether anything broke in the process. Benwing2 (talk) 06:36, 21 March 2025 (UTC)

{{col}} not hiding “hidden” lines on some devices

The col template on English wiktionary does not behave properly when collapsed on an iPhone screen

I do not know if the problem is in the template itself or in the CSS. Here is an example of a case where I see the problem.

• When the {{col}} is collapsed, the elements which should be hidden are not hidden. They overlap with the text below the {{col}} box, making everything difficult to read.
• When viewing, for example, talk, in the “Derived Terms” section
• This is not a problem for other types of collapsing boxes, such as {{trans-top|conversation}}
• ios 26.2, iPhone (but not on iPad)
• User preferences:
  • Vector (2022)
  • Enable responsive mode (enabled)
  • Enable limited width mode (enabled)
  • Text: Small
  • Color: Light

SV Resolution (talk) 16:50, 3 January 2026 (UTC)

I'm seeing the same thing and I was going to ask about it then saw this, so…yeah it needs to be fixed >_<

Lucy LostWord (creator of "Wonderful Video Game") (talk) 18:56, 13 January 2026 (UTC)

@Lucy LostWord @SV Resolution: Fixed. Special:Diff/89172583. — Fenakhay ^{(حيطي · مساهماتي)} 19:08, 13 January 2026 (UTC)

It's still doing the thing for me. Even I don't know what the problem is.

Lucy LostWord (creator of "Wonderful Video Game") (talk) 19:11, 13 January 2026 (UTC)

You were still using a cached version of MediaWiki:Gadget-Site.css (it is cached for 5-10 minutes). Try again now. — Fenakhay ^{(حيطي · مساهماتي)} 19:38, 13 January 2026 (UTC)

Working now! Thanks.

Lucy LostWord (creator of "Wonderful Video Game") (talk) 19:39, 13 January 2026 (UTC)

May have broken something? Nothing happens when I tap "show more" on the template after it was fixed, it just doesn't show more.

Lucy LostWord (creator of "Wonderful Video Game") (talk) 11:18, 14 January 2026 (UTC)

Never mind, it is working now.

Lucy LostWord (creator of "Wonderful Video Game") (talk) 12:56, 14 January 2026 (UTC)

Brava! Thanks for fixing the CSS! SV Resolution (talk) 01:09, 15 January 2026 (UTC)

"Show more" does not show more.

Hello! I'm on mobile, and when the little columns have the "show more" and I tap it, it doesn't show more. Does anyone know why it is doing this? This started happening right after the module got fixed when the full lists kept clipping.

Lucy LostWord (creator of "Wonderful Video Game") (talk) 21:57, 26 January 2026 (UTC)

Never mind? It seems to be working now?

Lucy LostWord (creator of "Wonderful Video Game") (talk) 22:02, 26 January 2026 (UTC)

Ok, what's going on?! Sometimes it works, sometimes it doesn't!

Lucy LostWord (creator of "Wonderful Video Game") (talk) 22:06, 26 January 2026 (UTC)

For some reason I can't click any links below column. Click a random spot would take me to an entry inside the hidden column. Haidit (talk) 09:53, 31 January 2026 (UTC)

Yeah. It's really acting up.

Lucy LostWord (creator of "Wonderful Video Game") (talk) 16:43, 31 January 2026 (UTC)

Please add a function to switch bullet styles

I wanted to change the regular circle bullet style to the numbered one, but turns out it's not possible at the moment. If someone will add that function, the CSS bullet styles would be fine. Abyterus (talk) 13:54, 3 April 2026 (UTC)

Not-so-collapsed

At least on mobile, collapsed tables seem to be more visual than functional; links still are clickable, despite being collapsed. To reproduce, here are two scenarios:

1. On the documentation for this module, tap on the left side below the first table while it is collapsed, right around {{#invoke. This opens x.
2. On distinguish under related terms, tap between distinct and distinction. This opens distinguishment.

Oklopfer (talk) 06:58, 16 April 2026 (UTC)