Template talk:Taxon list


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

p.italicize function
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 &#124; talk 14:54, 20 December 2017 (UTC)
 * 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)
 * 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 &#124; talk 16:42, 20 December 2017 (UTC)
 * 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)

has pointed above that if Species list is used with an abbreviated species name/epithet, it de-italicizes incorrectly. Thus gives

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 correctly gives

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)


 * 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)

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)

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


 * 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)


 * 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 &#124; talk 08:37, 21 December 2017 (UTC)


 * 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 &#124; talk 09:00, 21 December 2017 (UTC)
 * 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 '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)

Issue with (genus) in redirect
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 &#124; talk 08:23, 4 September 2018 (UTC)


 * 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
 * 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)
 * 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  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 &#124; talk 09:38, 4 September 2018 (UTC)
 * Well, it would work in the TaxonItalics module if the parameters to  were, say, , with   defaulting to   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   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  not to specify yes, and then make up the wikilink via.
 * I guess the fundamental issue is whether one function,, 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)
 * Correction : to automate completely, presumably  should output , 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   would output  , not  . 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)
 * I don't think the problem is with . 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 &#124; talk 10:56, 4 September 2018 (UTC)
 * Correction : to automate completely, presumably  should output , 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   would output  , not  . 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)
 * I don't think the problem is with . 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 &#124; talk 10:56, 4 September 2018 (UTC)

Edit 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)
 * Can it just be deleted? It obviously isn't actually test cases. — xaosflux  Talk 01:04, 11 February 2020 (UTC)
 * 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 Templates for discussion/Log/2019 February 10, 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)
 * 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)
 * Whether it should be deleted or not, I don't think redirecting it across namespaces is the right move &mdash; Martin (MSGJ · talk) 21:03, 11 February 2020 (UTC)
 * Why, exactly, do you think that? * Pppery * it has begun... 23:21, 11 February 2020 (UTC)

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)

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)
 * Try Collapsible taxon list. —  Jts1882 &#124; talk 14:13, 17 March 2020 (UTC)

Bug with daggers and Linked lists
Hi, I think I've found a bug with this one. I shall demonstrate:

This only seems to occur when using extinct, so using &dagger;

works fine (but I don't like it). Thanks. YorkshireExpat (talk) 16:11, 22 March 2022 (UTC)
 * extinct now uses  whereas Module:TaxonList expects  . 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 &#124; talk 20:44, 22 March 2022 (UTC)
 * 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 &#124; talk 09:02, 23 March 2022 (UTC)
 * Looks good. Thanks! YorkshireExpat (talk) 17:26, 23 March 2022 (UTC)

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 &lt;ul> element, when it is only defined in CSS for the &lt;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)
 * 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)
 * In other words,  should be removed? Izno (talk) 18:59, 9 December 2022 (UTC)
 * @Peter coxhead, gentle poke. Izno (talk) 22:35, 12 December 2022 (UTC)
 * sorry, busy with other things. Yes, definitely in my view. Peter coxhead (talk) 09:29, 13 December 2022 (UTC)