This template is within the scope of WikiProject Tree of Life, a collaborative effort to improve the coverage of taxonomy and the phylogenetictree 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
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
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 | talk14: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 | talk16: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]
@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 | talk08: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 | talk09: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.
@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 | talk08: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)) →
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 | talk09: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 | talk10:56, 4 September 2018 (UTC)[reply]
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]
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 | talk09:02, 23 March 2022 (UTC)[reply]
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?