Template talk:Taxon list

This template is within the scope of WikiProject Tree of Life, a collaborative effort to improve the coverage of taxonomy and the phylogenetic tree of life on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.Tree of LifeWikipedia:WikiProject Tree of LifeTemplate:WikiProject Tree of Lifetaxonomic articles

Lists

This template is within the scope of WikiProject Lists, an attempt to structure and organize all list pages on Wikipedia. If you wish to help, please visit the project page, where you can join the project and/or contribute to the discussion.ListsWikipedia:WikiProject ListsTemplate:WikiProject ListsList articles

This is the talk page for the set of templates described at Template:Species list/doc

p.italicize() function

Moved from Module talk:TaxonList

– * Pppery * _{it has begun...} 20:50, 10 February 2020 (UTC)[reply]

The function uses gsub() to deitalicize connecting forms such as 'subsp.' or 'f.' in taxon names. A downside of this general function is that listing subspecies in abbreviated form (e.g. F. l. cafra for Felis libyca cafra) produces a surprising result with the species initial deitalicised. Would it be better to explicitly deitalicise the connecting forms? Or are there a lot of different connecting forms and variants in use? Jts1882 | talk 14:54, 20 December 2017 (UTC)[reply]

@Jts1882: good point. I hadn't thought of people using abbreviated genus and species names.

The ICN doesn't define the connecting terms that can be used. The usual ones are subspecies, varietas, subvarietas, forma and subforma, which can be abbreviated to subsp. (or ssp.), var., subvar., f. and subf. In principle, I suppose, there could be "supervarietas", etc. The code could look for any of this set and de-italicize them, although it seems a bit inefficient.

An alternative (better?) approach would be to look for four 'word' taxon names, and then de-italicize the third word. Can you see a problem with this? Peter coxhead (talk) 15:50, 20 December 2017 (UTC)[reply]

That would certainly work for subspecies and any use I can see wanting to use the taxon list for. There are obscure and rarely, if ever, used forms like Canis lupus (exfam.) dingo (for a feralized domesticate), but I doubt these are used in any taxon lists. The question has to be if the change would disrupt any existing uses in taxoboxes. Could there any cases where a connecting form would be second? I can't think of any, so I think your suggestion would work well. Jts1882 | talk 16:42, 20 December 2017 (UTC)[reply]

@Jts1882: I now realize that there could be cases where the connecting form would be second, since the "genus list" templates, like {{Genus list}} are redirects to the "species list" versions. So someone could use {{Genus list}} to show the subgenera or sections of a botanical genus, e.g. a list of the sections of Acer, which should appear as Acer sect. Acer, Acer sect. Cissifolia, etc. I'm not sure it's ever used for this, though. It needs a bit more thought! Peter coxhead (talk) 17:06, 20 December 2017 (UTC)[reply]

@Plantdrew: Jts1882 has pointed above that if {{Species list}} is used with an abbreviated species name/epithet, it de-italicizes incorrectly. Thus {{Species list|A. beta subsp. gamma||A. b. subsp. gamma||A. b. gamma|}} gives

A. beta subsp. gamma
A. b. subsp. gamma
A. b. gamma

The last two are wrong because of the way I've coded the Lua module – starting from the second 'word', it de-italicizes the first 'word' it finds that ends with a period/stop. At first I thought the answer was to de-italicize the third 'word' of a four 'word' taxon name, but then I realized that if {{Genus list}} was used to list the sections of a genus, the connecting term is the second word. At present {{Genus list|A. sect. beta|}} correctly gives

A. sect. beta

You almost certainly look at more taxoboxes than anyone else; have you ever seen botanical subgenera or sections listed using the "taxon list" templates? Do we need to worry about such cases? Peter coxhead (talk) 17:35, 20 December 2017 (UTC)[reply]

@Peter coxhead: I'm not aware of having seen any subgenera/sections using "taxon list" templates, but I don't usually pay close attention to the subdivision sections of taxoboxes. It's probably nothing to worry about at the moment; taxon list templates are used in a small fraction of articles, and a infrageneric ranks show up in very small fraction of articles. I think it's unlikely there's much of anything at the intersection of articles using taxon lists and articles mentioning infrageneric subdivisions.

The only thing I've found so far is Acadoparadoxides, but italics are manually specified there. I found that with this search; I've played around with some variants on the search (different infrageneric ranks, searching for use of "Linked species list" instead of "Species list") and haven't turned up anything else, but you might play with it further. Plantdrew (talk) 18:35, 20 December 2017 (UTC)[reply]

@Peter coxhead: On further investigation, I'm not sure whether it's worth making the templates sense and automatically deitalicize connectors. Many connectors were manually deitalicized already, and depending on the precise spacing format, the automatic sensing may override the deitalicization, leaving them in italics. Compare red-eared slider, where '' var. '' is unitalicized to Alnus glutinosa where ''var.'' results in italics. It appears that the majority of (attempted) manually deitalicized connectors are the product of your edits; see e.g. this search. Plantdrew (talk) 20:13, 20 December 2017 (UTC)[reply]

Another weird case of manual/automatic deitalic methods conflicting: Fraxinus texensis. Plantdrew (talk) 20:17, 20 December 2017 (UTC)[reply]

@Plantdrew: thanks for your work on this. It's clear to me now that attempting to de-italicize connecting terms is considerably more complicated than I thought! I've removed the code that does this; if it's ever put back, then there will have to be tests for manual de-italicization and attempts at manual spacing via HTML entities, at the least. Peter coxhead (talk) 07:16, 21 December 2017 (UTC)[reply]

One idea I had was to use the genus and species parameters to check for abbreviated forms in the first and second words in the list. Then these abbreviated genus and species terms can be excluded from the deitalicization. Jts1882 | talk 08:37, 21 December 2017 (UTC)[reply]

While attempting to reconcile the taxobox information in the Acadoparadoxides article with the information in the only reference, I found an example of a connecting form in the second position: Acadoparadoxides aff. sacheri (link). If the deitalicization of connecting forms is to be resurrected, I think the best way is to be explicit and use a list of approved forms. Jts1882 | talk 09:00, 21 December 2017 (UTC)[reply]

@Jts1882: yes, I now agree that this would be the best way – in addition to checks for manual de-italicization. At present, I think it's not worthwhile, since Plantdrew's searches show that (a) there aren't many uses of connecting terms (b) most of those that are in place are already manually italicized.

Good catch of yours! Peter coxhead (talk) 12:02, 21 December 2017 (UTC)[reply]

Issue with (genus) in redirect

Moved from Module talk:TaxonList

– * Pppery * _{it has begun...} 20:50, 10 February 2020 (UTC)[reply]

@Peter coxhead: I fixed a {{Linked species list}} error with this edit. I assume the issue must be with the italicizeTaxonName() function and the handling of parenthetic term in the redirect. The link is correct, but the displayed text is the page title surrounded by pumas. If Puma (genus) is used directly (not as redirect), Puma and genus are in italics and the parenthesis are normal text, i.e. Puma (genus). Jts1882 | talk 08:23, 4 September 2018 (UTC)[reply]

@Jts1882: An ingenious fix you implemented! I was (dimly) aware of this issue, but had then forgotten it. The problem is that subgenus names of the form "Puma (Puma)" are now handled automatically, so "Puma (genus)" looks like a subgenus name. Sigh...

So far as I know, the genus disambiguation terms always begin with a lower-case letter, whereas subgeneric names begin with an upper-case letter. So the code could be changed to de-italicize parenthesized words beginning with a lower-case letter and italicize those beginning with an upper-case letter. Can you see a problem with this approach?

On reflection, the particular problem you noted with {{Linked genus list}} can be fixed by using

{{Linked genus list|''[[Puma (genus){{!}}Puma]]'' | Jardine, 1834}} →

Puma Jardine, 1834

This is because any input starting with manual italics is completely ignored, including linking. However, this doesn't necessarily mean that the "lower-case fix" shouldn't be applied. Peter coxhead (talk) 09:16, 4 September 2018 (UTC)[reply]

@Peter coxhead: Ah, I didn't think of subgenus. I can't think of when the disambiguation term wasn't lower case and the genus has should always be, so I think that should work. A more general point might be to ask why the redirect part of the name is being passed to the italics function. Should the "taxonname" be split into link and name components, so that for parameter Puma_(genus){{!}}Puma only "Puma" is passed to the italics function? The italics function seems to be behaving correctly, but wasn't expecting input with a pipe. Jts1882 | talk 09:38, 4 September 2018 (UTC)[reply]

Well, it would work in the TaxonItalics module if the parameters to italicizeTaxonName were, say, (link, name, linked, abbreviated), with link defaulting to name if not supplied. But this wouldn't help in the TaxonList module, since it uses purely positional parameters, so there's no way of specifying an additional 'link' parameter to match a name | authority pair, and if you have to supply a pipe, you might as well supply the rest of the expected output.

When it's known that a link is available, then the answer is for anything that uses italicizeTaxonName not to specify |linked=yes, and then make up the wikilink via [[ link | italicizeTaxonName_result ]].

I guess the fundamental issue is whether one function, italicizeTaxonName, can successfully handle italicization in so many contexts: taxonomy templates, taxoboxes, taxonbars, taxon lists, ... I think there will always be special cases, which is why the function completely skips input with outer manual italics. Peter coxhead (talk) 09:54, 4 September 2018 (UTC)[reply]

Correction: to automate completely, presumably {{#invoke:TaxonItalics|main|Puma (genus)|linked=yes}} should output ''[[Puma (genus)|Puma]]'', i.e. contrary to what I wrote above, a lower-case parenthesized word should be stripped off completely in the link text, not left de-italicized. However, this implies that {{#invoke:TaxonItalics|main|Puma (genus)}} would output ''Puma'', not ''Puma'' (genus). I'm not sure that this is what is always wanted. Automating all the possible cases is even more tricky than I thought! Peter coxhead (talk) 10:24, 4 September 2018 (UTC)[reply]

I don't think the problem is with italicizeTaxonName. It expects a Taxonname, not a link-pipe-taxonname combination. The {{Linked genus list}} template shouldn't pass the combination. The problem arose from the change in the template to handle more complex forms using the new function. The old p.italicize() function handled it simply by putting italics around the whole parameter entry. There are plenty of choices and workarounds when setting up such lists, its only legacy pages where it is an issue. It turns out that it was my edit that changed the list to use the list template, when it only worked using the pipe trick, so you can blame me. Jts1882 | talk 10:56, 4 September 2018 (UTC)[reply]

Edit request

This edit request to Module:TaxonList/testcases has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

Change content model to Wikitext and redirect to Template:Taxon list/testcases; the current page is a soft redirect serving a purpose that could be better served by a hard redirect. * Pppery * _{it has begun...} 20:52, 10 February 2020 (UTC)[reply]

Can it just be deleted? It obviously isn't actually test cases. — xaosflux ^Talk 01:04, 11 February 2020 (UTC)[reply]

What's the reason for deleting this page, as opposed to redirecting it? The test cases for Module:TaxonList are at Template:Taxon list/testcases. A redirect causes no harm. (See also Wikipedia:Templates for discussion/Log/2019 February 10#Empty test cases, where I did nominate a bunch of test cases pages with no content for deletion) * Pppery * _{it has begun...} 01:11, 11 February 2020 (UTC)[reply]

Module:TaxonList/testcases basically has a comment that declares it does nothing, User:Peter coxhead is there a reason that page is useful? — xaosflux ^Talk 20:36, 11 February 2020 (UTC)[reply]

Whether it should be deleted or not, I don't think redirecting it across namespaces is the right move — Martin (MSGJ · talk) 21:03, 11 February 2020 (UTC)[reply]

@MSGJ: Why, exactly, do you think that? * Pppery * _{it has begun...} 23:21, 11 February 2020 (UTC)[reply]

Given that (apparently) there is opposition to cross-namespace redirects, Module:TaxonList/testcases is useful because it helps anyone editing the module to find its test cases. Peter coxhead (talk) 22:14, 11 February 2020 (UTC)[reply]

Collapsible?

Would it be possible to include an option that makes a list collapsible? This could be handy for long lists of synonyms that are not of interest for a casual reader. Micromesistius (talk) 14:07, 17 March 2020 (UTC)[reply]

Try {{Collapsible taxon list}}. — Jts1882 | talk 14:13, 17 March 2020 (UTC)[reply]

Bug with daggers and Linked lists

Hi, I think I've found a bug with this one. I shall demonstrate:

Species one Dave.
Species two Julie.
†Species three Sid.

This only seems to occur when using {{extinct}}, so using †

Species one Dave.
Species two Julie.
†Species three Sid.

works fine (but I don't like it). Thanks. YorkshireExpat (talk) 16:11, 22 March 2022 (UTC)[reply]

{{extinct}} now uses <abbr> whereas Module:TaxonList expects <span>. A simple change on lines 36-37 seems to work. I'll make the change tomorrow when I can check it properly, if not beaten to it. — Jts1882 | talk 20:44, 22 March 2022 (UTC)[reply]

Fixed by substituting tag abbr for span.

I tried to make a more general fix to make it immune to future changes in {{extinct}} by matching the beginning of the taxonName to the results of {{extinct}} returned by expandTemplate() but I couldn't get the match to work. — Jts1882 | talk 09:02, 23 March 2022 (UTC)[reply]

Looks good. Thanks! YorkshireExpat (talk) 17:26, 23 March 2022 (UTC)[reply]

plainlist

I have corrected one issue with the plainlist use here today by making it a class rather than a style in the module. What a typo! (Yes I have made this typo in just the past few days. :)

An issue remains: The class is being added to the <ul> element, when it is only defined in CSS for the <ul>'s container. Is the display today acceptable in all cases where it is used? I.e., can the use of plainlist be removed? Or should it be using a container? Its use in e.g. Almond as part of {{Speciesbox}} is one primary use (see Synonyms) where I think I would expect a plainlist. Is the module used in other places, such that the list output should be a normal list rather than a plainlist?

(I am here today for another reason entirely pertaining to reducing the surface area of plainlist for TemplateStyles support.) Izno (talk) 00:56, 8 December 2022 (UTC)[reply]

@Izno: by far the most usual style for lists of synonyms in taxoboxes is bulleted lists, either produced manually (e.g. Chrysanthemum, Acacia, Stegosaurus, Camellia, and thousands more) or by templates such as {{Species list}} (13455 transclusions). So editors create and expect a bulleted list of synonyms in a taxobox. Peter coxhead (talk) 17:28, 9 December 2022 (UTC)[reply]

In other words, plainlist should be removed? Izno (talk) 18:59, 9 December 2022 (UTC)[reply]

@Peter coxhead, gentle poke. Izno (talk) 22:35, 12 December 2022 (UTC)[reply]

@Izno: sorry, busy with other things. Yes, definitely in my view. Peter coxhead (talk) 09:29, 13 December 2022 (UTC)[reply]

Option to justify header?

Can an option be added to allow for the left justification of the header? – Elizabeth (Eewilson) (tag or ping me) (talk) 19:28, 30 October 2024 (UTC)[reply]

Am I missing something. I don't see a header for this template. Please provide an example. — Jts1882 | talk 07:59, 31 October 2024 (UTC)[reply]

Nope, it's me. I made the (incorrect) assumption that the parameter |header= which is available in {{Species list}}, was coming from this parent template. I will post the question on the talk page for that template. Thanks. – Elizabeth (Eewilson) (tag or ping me) (talk) 11:00, 31 October 2024 (UTC)[reply]

Ah, that talk page redirects to here. The code is in the template wrapper before the Lua module TaxonList is called. I believe that more than one of the templates provide a header parameter. It is centered. – Elizabeth (Eewilson) (tag or ping me) (talk) 11:08, 31 October 2024 (UTC)[reply]

@Eewilson: when I saw your post I wondered if that might be the issue, but Jts1882 replied first. Yes, |header= is part of {{Hidden}} which I added only to {{Species list}}, so it's available only in that template and the redirect {{Genus list}}. I was uneasy about adding it to all the taxon list templates via Module:TaxonList, because of what is said at MOS:DONTHIDE. I can see why a long list of synonyms in a species or genus taxobox can legitimately be hidden – synonyms shouldn't be either linked or in bold, so there's no reason for {{Linked species list}} or {{Bold species list}} to allow hiding. Do you want to hide any other lists of taxa? Why don't you want the header centred? Peter coxhead (talk) 14:13, 31 October 2024 (UTC)[reply]

If it is just a matter of {{Species list}}, and there's a good reason, then I would suggest adding something like |headerstyle=text-align:{{{headeralign|center}}}; to the call to {{Hidden}}, so that |hidden=yes|headeralign=left would achieve left alignment of the header. Peter coxhead (talk) 14:23, 31 October 2024 (UTC)[reply]

Thanks, Peter. I'm not interested in the header being available with any other of the related templates (actually have no opinion). It's a nice surprise that there is one for the Species list. I don't like it being forced centered because it's not consistent with Collapsible list or with just manually adding a bolded header. These are left justified. My personal opinion is it looks better left justified.

I suggested it as an option (a parameter for how to justify the header) because it is already implemented as centered. For backward compatibility, that could remain the default. But I would be just fine with it being outright changed to left justified. Really your choice on that. – Elizabeth (Eewilson) (tag or ping me) (talk) 14:29, 31 October 2024 (UTC)[reply]

Actually, I think that if I'd really noticed how it looked, I would have set it to left, so I too am "just fine with it being outright changed to left justified". As just one example, in the taxobox at Populus alba, it's odd for the word "List" to appear in the centre when the sub-box had the centred heading "Synonyms". Let's see if anyone else comments, but I'm inclined to change the template to put the "hide heading" left. Peter coxhead (talk) 14:41, 31 October 2024 (UTC)[reply]

ha ha. That's funny because I was just thinking if I pulled it up in an article that I didn't do and saw it centered, I would want to change it to left. So if it's not a big deal, and you can just change it to justified, I'd say do it. And then if anyone comes along and wants the option to center it, you could always make the option. – Elizabeth (Eewilson) (tag or ping me) (talk) 14:47, 31 October 2024 (UTC)[reply]

well, I'd like to ask first; see Template talk:Speciesbox#Subheading when hiding synonym lists with Species list template. Peter coxhead (talk) 14:55, 31 October 2024 (UTC)[reply]