Template talk:Speciesbox/Archive 3

Archive 1

Archive 2

Archive 3

Archive 4

automatic range map

Why range map is not taken automatically from wikidata P181 property? Assafn (talk) 16:07, 27 November 2019 (UTC)

@Assafn: nothing is taken automatically from Wikidata, and that is intentional and unlikely to change anytime soon. However, it would be useful if a query could be constructed that would find cases where a Wikidata item had P181 and a Speciesbox on en.wiki lacked a range map. Plantdrew (talk) 16:26, 27 November 2019 (UTC)

Sorry, I'm not familiar with how Speciesbot works. A newbie question: why it's call automatic template if nothing retrieve automatically and what is the purpose of linking taxon to wikidata if the data is not populated here? Assafn (talk) 20:10, 27 November 2019 (UTC)

@Assafn: Its automatic in that it uses the parent templates on en.wiki to generate the taxonomy sections of the info box, where-as the manual taxoboxes need all the information input on the article itself. en.wiki has decided not to use wikidata due to the high degree of inaccuracy in that data, much of which is not vetted or severely out of date, coming from smaller wikis that do not have the editing community to stay on top of changes in taxonomy.--Kevmin § 00:02, 28 November 2019 (UTC)

Ok, I see it now. You created local templates for each taxon rank and use it in Speciesbox? It looks like a lot of effort and it's a shame this effort is not channeled to a common resource such wikidata. Can you please redirect me to the discussion where it was decided not to use wikidata? I want to understand the reasons? Assafn (talk) 08:05, 28 November 2019 (UTC)

@Assafn: Wikidata is completely useless for a self-consistent taxonomy, as has been discussed repeatedly. It takes no position on what taxonomy is correct, and attempts to replicate multiple sources. Hence it includes many, many synonyms as separate "instances of taxon" and also alternative approaches – in a taxon item, there can rightly be multiple parents (look at Lemnaceae (Q14293890) for example). Different language wikis have adopted different taxonomic systems for their article titles and taxoboxes, and Wikidata just picks up all their articles, however inconsistent. As just one example, that I've been working on recently, the family Aspleniaceae has two very different uses. In PPG I, it is one of the families in the order Aspleniineae. In the system used in this new book, Christenhusz, Maarten M.J.; Fay, Michael; Byng, James W. (2018), The Global Flora: Special Edition: GLOVAP Nomenclature Part 1, Plant Gateway Ltd., ISBN 978-0-9929993-6-0, the family is very, very much broader, and replaces the whole of the suborder Aspleniinae, which doesn't exist in its system. Both systems are in current use; wikis need to choose which to use for article titles and taxoboxes – they can't use both (although they should always discuss alternatives in articles).

The constantly raised idea of using Wikidata for taxonomy is based on a total fallacy, namely that there is an objective system of classification "out there" which everyone uses. There isn't. Classification is opinion, not data. Peter coxhead (talk) 09:42, 28 November 2019 (UTC)

I concur with the above replies, but will also add that work on the English Wikipedia's current system of taxonomy templates started in 2010, whilst Wikidata launched in 2012. So there was no discussion that discarded the option of using Wikidata. William Avery (talk) 11:47, 28 November 2019 (UTC)

@William Avery: not at the start, no, but the issue of using Wikidata now has been raised and discussed a number of times. We probably need some kind of "essay" page somewhere, explaining why (a) it isn't a good idea (b) it wouldn't work even if it were a good idea because of the way that "instances of taxon" are set up in Wikidata. Peter coxhead (talk) 14:22, 28 November 2019 (UTC)

@Peter coxhead:Probably discussions I haven't seen, or maybe I have forgotten. As you point out, taxonomy is a matter of opinion, and I do remember seeing that there was big pushback against importing any external taxonomic hierarchy into the automated system, which would have replaced the one arrived at by the various wikiprojects. That idea turned editors against the whole concept of an automated system for a while, I think. A gradual approach (with everything controlled on this wiki) seems to have largely dispelled such fears. It's not easy for someone arriving now to appreciate how much work editors like yourself had to put in to get it off the ground at all. William Avery (talk) 15:00, 28 November 2019 (UTC)

@William Avery: on reflection, some of the discussion was at Wikidata where we were being criticized for not using it.

You remind me of another issue: the automated taxobox system is set up so that different areas of the ToL (in particular different WikiProjects) can use different systems, in line with reliable sources, and this is crucial to the acceptance of the system. Thus birds and dinosaurs use incompatible ranks as per sources in their fields. Wikidata has no concept of attaching a particular piece of a classification to a system. Although we haven't got it quite right yet, the ability to have "qualified" taxonomy templates is a vital feature, so that, e.g., Template:Taxonomy/Spermatophytes/Plantae treats seed plants as in Kingdom Plantae and Template:Taxonomy/Spermatophyta treats them in a purely clade-based system.

Some history. The real credit should go to the editor, Smith609, who had the brilliant and subversive idea of using templates, primarily intended to allow repeated use of "boiler plate text", to hold a database of taxonomic relationships. It was subversive since the Wikimedia gurus did their best to prevent any use of templates that involved repetition (recursion being absolutely forbidden) because of concerns over processing time. Until the advent of Lua, there was in effect an arms race between the Wikimedia software team and editors here, who had to find ever more ingenious and convoluted ways of getting round the imposed limits (Wikid77 should be honorably mentioned in this respect). By contrast, converting the system to a sensible programming language (i.e. Lua) was relatively straightforward. Peter coxhead (talk) 16:58, 28 November 2019 (UTC)

WikiSpecies and Commons have been using conceptually similar systems to display the taxonomic hierarchy since long before 2010 (similar in that there is a template for each taxon that contains name, rank and parent taxon)Plantdrew (talk) 20:43, 28 November 2019 (UTC)

I don't think they are "conceptually similar". The innovation in the taxonomy templates is that they act as data that can be manipulated by other templates or, now, by Lua code. This allows things like deciding what to display via the rank of the taxon or by |always_display= or by setting |display_parents= in the taxobox template. By contrast, Wikispecies templates are just nested text to display. They always display in full in exactly the same way. If you look at the source of species:Template:Strigiformes, for example, it has "Ordo: " as literal text. It does exactly what templates were primarily designed to do: substitute the text in the template at the point it's invoked. If it was ever decided to display ranks in English or any other language, every single template would have to be changed. By contrast, |rank=ordo in Template:Taxonomy/Strigiformes is treated as data; it's the processing code, not the taxonomy template, that displays it as "Order", and this could be changed to anything we wanted without having to change any of the taxonomy templates. As another example, Wikispecies has the same expansion depth problems that automated taxoboxes here used to have; see species:Category:Pages where expansion depth is exceeded. But these problems can't be fixed by switching to Lua, because of the way the templates are constructed: each includes its parent template rather than a data value pointing to its parent. No, I stick to my view that Smith609 introduced a clever, indeed brilliant, innovation. Peter coxhead (talk) 23:07, 28 November 2019 (UTC)

I completely understand the statement that classification is not an objective system but you face the same problem here, who decide which classification to use in the English pages? What I'm tying to say is that if you solved it here it's possible to solve it elsewhere in the same way. But lets say from political aspect that it'll be much harder to get an agreement of proper classification in wikidata, what about other non disputable data, such taxon name and authority? this is a regulated information and doesn't depends on opinion. ultimately the wiki projects are all about Wisdom of the crowd so I think the right spirit is to join forces and not creating many silo wikis. Assafn (talk) 22:48, 28 November 2019 (UTC)

@Assafn: sorry, but you are missing two key points:

1. There's no proper classification to get agreement on. There's no single authority dictating taxonomy. There are legitimately different taxonomic traditions in different countries, for example. There are different taxonomic traditions in different groups of organisms; as noted above, birds are classified in different ways by ornithologists and dinosaur specialists.
2. The design of Wikidata prevents it being used to store and extract a coherent classification.

I'm not quite sure what you mean by non disputable data, such taxon name and authority, since the whole point is that taxon names are highly disputable. If you mean the authority for a taxon name, then we could pull this fron Wikidata as a default if Wikidata stored it correctly. But it doesn't. It doesn't indicate a transfer of genus for a species nor, for botanical names, the transferer. Thus the authority for Didymochlaena truncatula is "(Sw.) J.Sm." Didymochlaena truncatula (Q5274269) just has "John Smith", with no indication of the original author.

Peter coxhead (talk) 23:37, 28 November 2019 (UTC)

I'll add that it is very common for those studying fossils to use a different system to those studying extant organisms. Fossils tend to squeeze the living organisms into a less prominent place. The dinosaur-bird dichotomy is just an extreme example. The automated taxonomy system allows different projects to use different systems, something that would be very difficult to do in Wikidata.

However, using Wikidata for range maps, conservation status or fossil range doesn't have the same drawbacks. Checking Wikidata when there is no value and either using it automatically, adding a warning prompt, or adding a category (e.g. Taxoboxes with potential Wikidata range maps) might be worth considering.

The idea of an essay on Wikidata and the automated taxonomy system is a good idea. This topic keeps coming up and Peter coxhead must have written the materal several times over various talk pages. It would be useful to have it in one place.   Jts1882 | talk  08:21, 29 November 2019 (UTC)

@Jts1882: my objection is to automating the use of Wikidata for such uses, because of the difficulty in knowing whether the taxon is actually the same as opposed to having the same name. (The same applies to images of organisms: these are often mis-identified in Commons or under obsolete names (particularly old illustrations), and are then recorded in Wikidata without any checking.) It would be useful, as Plantdrew noted above for range maps, to be able to easily find cases where a Wikidata item had such information but the taxobox didn't, so it could be investigated.

Ok, I'll put constructing an essay on my to-do list (actually a stack), but make no promises as to when it will be reached! Peter coxhead (talk) 08:39, 29 November 2019 (UTC)

@Peter coxhead: Let me try to clarify what I mean.

1a. As you mention above classification is a matter of opinion so how do you decide when classification system to use when you create wiki templates? Does editor can prefer one method while the other different. If you solved that problem already you can use the same method on wikikata.

Here WikiProjects reach a consensus on what to use as article titles or in taxoboxes. For these we need an accepted taxonomy. But Wikidata should not have an accepted taxonomy. Wikidata's task is to hold data, not accept one view over another. Peter coxhead (talk) 18:42, 29 November 2019 (UTC)

@Peter coxhead: indeed wikidata task is to hold data and there is no problem to keep all known classifications tree and synonyms in the same place. What I'm trying to say without a success is that today every wiki project has it's own consensus on what is a valid classification system but this is a decision issue and not data issue. I don't want to get into implementation but I guess there are several approach to solve it. i.e. add a qualifier for each taxon instance in a way that different wiki could have different classification system. that it two wiki could have different parents but for example could share the same genus level so that genus information will have single source. Assafn (talk) 09:38, 30 November 2019 (UTC)

1b. Now lets say two solved issue 1a (You have two or more classification options and you choose one) getting the authority should be trivial since it's regulated by International Commission such ICZN, ICBN etc... so there is only one true authority to the selected taxon.

(Again, you need to use terminology with care. The ICZN, ICNafp, etc. regulate taxon names, not taxa.) Sure, so if you can persuade the editors at Wikidata to set up data structures so that the authorities are correctly represented for each Code, remembering the Codes differ, we might be able to use them. Peter coxhead (talk) 18:42, 29 November 2019 (UTC)

@Peter coxhead: I'm not sure what does it mean by regulating taxon names, not taxa? For example I'm talking on the case->Opinion system here it is all regulated and with International consensus so there is no reason not to use this data independently in all wikis. This is related to a1. Lets say several wikis decided to follow the same system (I guess some smaller wiki will align with English wiki due to lack of resources). If someone from that wiki will fix the taxon according to a case it'll automatically be fixed also in English wiki. Assafn (talk) 09:38, 30 November 2019 (UTC)

@Assafn: I'll reply at your talk page, because it's off the topic here. Peter coxhead (talk) 09:59, 30 November 2019 (UTC)

2 I'm still not sure why it is not suitable, I read here that it is full of mistakes but no one is expected that automatic mechanism will work without maintenance if you will channel the time you are putting into local templates to maintain wikidata it'll probably be more accurate and less time consuming (larger community) than the local system. Assafn (talk) 14:23, 29 November 2019 (UTC)

I don't know how to explain it differently. Wikidata taxon name items can, rightly, have multiple parents. So they do not join together to form a hierarchical classification. It's not because there are errors, it's because the design is intended for a different purpose, namely neutrally representing all known classification data. It's nothing to do with channeling time into Wikidata. Peter coxhead (talk) 18:42, 29 November 2019 (UTC)

I don't think Wikidata is a larger community than en.wiki. The core taxonomy community there is basically 2-3 people. There are 42 people listed at d:Wikidata:WikiProject_Taxonomy/Participants; 9 of those are names I recognize as being most active on en.wiki, at least 4 are most active on Wikispecies. There are a couple from commons, several from Wikipedias in various languages, and some that don't really do any work on Wikimedia projects (but are interested in biodiversity informatics in a broad sense). Wikidata's taxonomy group does bring together editors working in different language Wikipedias who might not interact otherwise, but there isn't a large community of editors working on taxonomy items within Wikidata.

Getting back to range maps specifically, d:Q1051396 has a range map that is incompatible with English Wikipedia's article on Petroica australis. English Wikipedia recognizes two species, one from the North Island of New Zealand, one from the South Island. The map at Wikidata applies to a species concept that recognizes a single species occuring on both islands. We don't want to automatically display that map on English Wikipedia. If the idea is that by displaying the map to more people, it is more likely that Wikidata will get an updated map, then you're talking about leveraging a larger community (en.wiki readers/editors) to improve data from a smaller community (Wikidata). Plantdrew (talk) 19:14, 29 November 2019 (UTC)

Just to finish off this thread, I did write an essay at User:Peter coxhead/Wikidata issues. Peter coxhead (talk) 09:16, 13 September 2020 (UTC)

Any chance of an Image3?

I think it'd help at Acavus haemastoma, and other cases with a limited number of subspecies that would reasonably fit in an infobox. It's on the upper limit, but I think it's just within sensible - and more sensible than having only two of three distinct varieties in an infobox. Adam Cuerden ^(talk)_{Has about 7.5% of all FPs} 03:38, 14 September 2020 (UTC)

You could use the range map parameters as in this edit. I think it is also possible to use a template such as {{Multiple image}} to add more than one image to an |image= parameter. —  Jts1882 | talk  06:01, 14 September 2020 (UTC)

A version using {{Multiple image}} can be seen in this edit. —  Jts1882 | talk  06:15, 14 September 2020 (UTC)

I think that'll do nicely. No need to add it to the template if the work-around is good enough for the rare cases where it's valid. Adam Cuerden ^(talk)_{Has about 7.5% of all FPs} 07:06, 14 September 2020 (UTC)

Taxobox name and italicization

When {{Speciesbox}} is used to create a taxobox, generating a taxobox name and italicizing both it and the page title are supposed to be done automatically. The logic behind this process is convoluted, for a number of reasons:

• the taxon can be specified either by |taxon= or by |genus=+|species=
• either the genus or the species (both??) can be preceded by a spaced × which has to be treated as part of the following word, just as if it were unspaced (thus the genus of "× Reyllopia conollyana" is "× Reyllopia" just as the genus of "×Reyllopia conollyana" is "×Reyllopia")
• the genus can be disambiguated in order to access the correct taxonomy template (thus the article at Alsophila dealbata has |genus=Alsophila (plant)), but neither the taxobox name nor the page title will contain the disambiguation
• the genus can be qualified in order to access the correct taxonomy template (thus the article at Homo rudolfensis has |genus=Homo/?), but the page title doesn't the qualifier in it, nor should the taxobox name.

I had been aware for some time (after Plantdrew alerted me) that there were a few cases with the wrong italicization. I made some fixes (e.g. to handle nothogenera correctly), but it's exceedingly difficult to write complex logic in the template language (those who know it might like to try to understand the logic in this version). So recently I've converted the subtemplate to use Lua; Lua code is much easier to read (and the ability to create variables to hold intermediate results avoids repetition).

There will always be a very few cases that are so odd that it's not worth trying to automate them and there are manual overrides for such cases (see e.g. Halictus? savenyei).

I've tested my code as thoroughly as I can (see Template:Speciesbox/name/testcases). I didn't get one case (qualified genus names) quite right until this morning. Please let me know here if you come across any issues. (You may need to purge the page to apply the template updates.) Peter coxhead (talk) 10:26, 5 October 2020 (UTC)

Question

At present, the page title is automatically italicized only if, ignoring any disambiguation, it is identical to the taxon name (the binomial for a species, but the same applies to other rank values in {{Automatic taxobox}}). One situation in which I think this might cause an issue is when × is present.

• If the page title has a spaced × but the taxon name doesn't, then the page title isn't italicized. So if the taxonomy template is at "Template:Taxonomy/×genus" but the page is at "× genus species", italicization fails. We've never agreed, I think, on whether to insist on spaced or unspaced ×. (It's ok if the space is present as   or  .)
• You can't use {{hybrid}} in a parameter value. Thus you can't write |genus={{hybrid}} Reyllopia because {{hybrid}} generates HTML that isn't in the page title.

Is it worth trying to fix either of these two cases? I think not, but I'm open to being persuaded otherwise. Peter coxhead (talk) 10:43, 5 October 2020 (UTC)

Small text

Per MOS:SMALL, reduced font size should not be used in infoboxes. Just checking that there has been no discussion to make an exception for Speciesbox. Sagittaria guayanensis is an example. MB 16:23, 8 October 2020 (UTC)

My understanding is that this guideline is for {{infoboxes}} that already use small text so as to avoid doubly small text. As far as I can tell small tags in speciesbox lists generate 85% text which is the minimum size that MOS:SMALL is aiming for. —  Jts1882 | talk  17:00, 8 October 2020 (UTC)

OK, I wasn't sure if the main text was 100% or not. Thanks. MB 18:17, 8 October 2020 (UTC)

@MB: if it's written up anywhere I can't find it, but it's a well established convention that the authority for a scientific name is formatted as small text. This helps to distinguish the name from this rather specialized ancillary information. Peter coxhead (talk) 19:16, 8 October 2020 (UTC)

MOS:SMALL is for anything that uses reduced font size such as infoboxes, navboxes, and reference sections. But if Speciesbox doesn't, then there is no issue. Peter coxhead, it sounds like this "established convention" would be good to document. Can you suggest an appropriate place? (at a higher level than here as it would apply to other templates). There is nothing in Category:Wikipedia Manual of Style (science). Probably a sentence in Wikipedia:Manual of Style/Text formatting#Scientific names? MB 02:46, 11 October 2020 (UTC)

@MB: yes, this would be a good place, but it seems very odd to me that it isn't written down elsewhere. The code to display a taxobox was started on 30 May 2004. The version by the end of the day had the authority in small font, and it's been like this ever since, i.e. for over 16 years. (Most authorities in taxobox are currently displayed by Template:Taxonomy, which uses style="font-size: 85%;".) Peter coxhead (talk) 07:49, 11 October 2020 (UTC)

Actually it's not such a good place, because it's under "use of italics", but it will do for now. SMcCandlish has a draft with a lot more detail on how to handle organisms at MOS:ORGANISMS. It's not an accepted guideline yet, but will be soon, I hope. Peter coxhead (talk) 08:33, 11 October 2020 (UTC)

The arrow in articles like Neanderthal

I'm not really sure which parmeter refers to the row of geological periods at the top of the infoboxes in articles like Neanderthal, but is it just me or is the arrow like unbelievably small? I didn't even know it was there for a while. Aza24 (talk) 03:28, 12 November 2020 (UTC)

@Aza24: The bar is to indicate the temporal range that a taxon lived for before extinction or the present. See for example the bar on Asaphus, which had a much longer run before extinction.--Kevmin § 22:56, 13 November 2020 (UTC)

Basionym parameter

Whats the opinion of having a basionym parameter for the species box? Working in fossil taxa articles I find many instances where species have been punted several times after the original description, and I wouldn't mind a box parameter for calling out the original name. As examples, Metasequoia occidentalis was first described as Taxodium occidentale J.S. Newberry 1863, and not formally moved to Metasequoia until 1951. Similarly Cephalotes alveolatus was first described as Zacryptocerus alveolatus by Vierbergen & Scheven, 1995 and later punted into Cephalotes less then 4 years later by De Andrade & Baroni Urbani in 1999.--Kevmin § 23:05, 13 November 2020 (UTC)

@Peter coxhead: would this be a pain to code and implement?--Kevmin § 17:44, 21 November 2020 (UTC)

I take the general position that a very good case has to be made to add new parameters to the taxobox templates. I know from the average number of taxoboxes I correct most days that many editors find them too complex already.

The simplest approach is to put "(basionym)" after the relevant entry in the list of synonyms. Neither of the articles you linked to above has a proper list of synonyms, including authorities, but if this were fixed, then it would be straightforward for the plant article. However, "basionym" is an ICNafp term. It's not used in the ICZN, because this attaches the authorship to the specific name, not the combination. So Cephalotes alveolatus doesn't have a basionym. Peter coxhead (talk) 20:30, 21 November 2020 (UTC)

Capitalization of parameters

To me the documentation seems to suggest you could use e.g. image_caption or Image_caption but this seems not to be the case. (Only image_caption works.) Please fix template or doc. --Palosirkka (talk) 10:16, 26 October 2020 (UTC)

I assume you are referring to the TemplateData. The bolded term in the first column is the name of the parameter and the second column shows the parameter aliases that can be used. Looking at {{cite web}}, perhaps the first column shouldn't have underscores. —  Jts1882 | talk  10:38, 26 October 2020 (UTC)

Do we need the first column at all? Or perhaps the header line should be changed? --Palosirkka (talk) 11:00, 26 October 2020 (UTC)

@Palosirkka: the display is down to the way the Wikimedia software handles the templatedata tag, and is way, way above the level of this template!

@Jts1882: well, if we were starting now, perhaps |image-caption= would be preferred to |image_caption=, and I suppose hyphenated forms could be added as yet another alternative (sigh), but I think most editors are used to the underscore (and editors like Plantdrew regularly replace the spaced form by the underscore form, so it's there as an example in most taxoboxes). Peter coxhead (talk) 11:59, 26 October 2020 (UTC)

Looking through a bunch of high use templates, infoboxes are standardized on separating words in a parameter with underscores, and citation templates use hyphens. There are some other styles out there, but I didn't find any that used spaces. Plantdrew (talk) 18:50, 26 October 2020 (UTC)

Definitely not spaces! Peter coxhead (talk) 19:38, 26 October 2020 (UTC)

It seems this is where the hyphen convention for citation templates was established: Help_talk:Citation_Style_1/Archive_5#RFC:_Citation_Style_1_parameter_naming_convention. Plantdrew (talk) 01:18, 8 December 2020 (UTC)

This issue just came up again at Wikipedia talk:WikiProject_Birds#Caption for range map doesn't appear.. TemplateData needs to get fixed. Plantdrew (talk) 21:41, 22 December 2020 (UTC)

Resolved. TemplateData shows the capitalized parameter when "label (en)" isn't filled in. I've just added labels for Speciesbox and will do their other templates in the taxobox family shortly. Plantdrew (talk) 22:29, 22 December 2020 (UTC)

@Plantdrew: looks like I botched the edit-summary-ping, but fyi I made a similar edit after yours, but kept the label's sentence case, per TemplateData standards. I also changed some labels slightly to further separate the first 2 columns, and add a little bit of user friendliness, like Image alt text instead of Image alt, Conservation status instead of Status, Range map image instead of Range map, etc. Feel free to tailor.   ~ Tom.Reding (talk ⋅dgaf)  23:37, 22 December 2020 (UTC)

Image_width parameter

|image_width= is deprecated everywhere, in favour of scaling to the user's preferred width using "upright" parameters. It has been removed from {{Automatic taxobox}}, for example. I actually thought it had been removed here too, but not so – an oversight, at least on my part.

I propose to ensure that no uses of the parameter exist, and then remove it. Use |upright= instead. Peter coxhead (talk) 14:26, 23 December 2020 (UTC)

There are no instances of |image_width= in Speciesboxes right now. It's one of the parameters I check for every couple of weeks (and it shows up in the monthly TemplateData report). New instances will keep cropping up as manual taxoboxes are converted to automatic (there are ~14,000 instances in manual taxoboxes with a value and another ~6,000 with the parameter present with no value). For the most part, I'm not interested in doing parameter cleanup in manual taxoboxes; it's better to convert to automatic taxoboxes and cleanup parameters in the process. Plantdrew (talk) 17:06, 23 December 2020 (UTC)

Actually there were a few earlier today, which I fixed (more than half actually had no values). There were also some instances of |range_map_width=, which I've also fixed (again, the majority were unused). So I've now removed the parameters from the template and will fix the documentation accordingly. Peter coxhead (talk) 17:12, 23 December 2020 (UTC)

Ranks between species and genus

I'm currently trying to tidy up minor issues relating to Speciesbox before attempting to convert it to use the same Lua module as {{Automatic taxobox}}. I have made several small fixes recently.

One issue I'm not sure about is ranks between species and genus.

The documentation at Template:Speciesbox#Parent taxon is not the genus explains how to use |parent= to link to the taxonomy template for a rank between the species that is the target of the taxobox and its genus.

There is one alternative provided in the template parameters. For a subgenus (and only a subgenus), you can instead use |subgenus=subgenus_name. This doesn't link to a taxonomy template, but instead simply inserts the subgenus into the taxobox. For a zoological name example, see this version of Sepia acuminata. For a botanical name example, see this version of Cyclamen rohlfsianum.

This alternative is not provided for any other rank, which means that for ranks like botanical sections, subsections, series and subseries, there has to be a taxonomy template. Officially the ICZN only allows subgenus between genus and species, but in some areas, e.g. Diptera and Lepidoptera, extra 'ranks' are often used: see e.g. the manual taxobox at this version of Drosophila melanogaster.

There seem to be three ways forward:

1. Accept that subgenera are a special case – they are the only official ranks common to zoological and botanical names – and leave the situation as it is.
2. Add other ranks between species and genus as parameters to Speciesbox so that taxonomy templates can be avoided. There would then be the question of which ranks to add.
3. Remove the special case of subgenera (there are 442 uses at present according to the template parameter report.

I personally prefer (1), but would also accept (3). (2) will be difficult to implement, because there are so many possible 'ranks' and because of knock-on effects, such as determining the meaning of |parent_authority= when multiple ranks exist between species and genus.

Comments, please. Peter coxhead (talk) 10:11, 8 October 2020 (UTC)

I oppose option #2. The whole point of the taxonomy template system is to remove all the rank parameters and have one place where a taxonomic change can be made. In principle, I favour option #3 to keep things simple, but can see #1 as the more pragmatic. —  Jts1882 | talk  15:30, 8 October 2020 (UTC)

My preference for #1 is indeed pragmatic, based on the work required to fix the 442 uses (creating taxonomy templates, altering article taxoboxes). If there were volunteers to do the work, I would favour #3. Peter coxhead (talk) 16:09, 8 October 2020 (UTC)

Perhaps deprecated the parameter but leaving the functionality for now. It's not clear how many need new templates, as some e.g. Template:Taxonomy/Odatria already exist, even though |subgenus=Odatria is used at Short-tailed monitor (it also has a parent |parent=Varanus which seems to be is ignored). There also might be a few large subgenera that would make the fixing easier, e.g. 15 subgenus Banksia). —  Jts1882 | talk  16:53, 8 October 2020 (UTC)

I think you're right that there's less work than I thought. I changed Short-tailed monitor to use the subgenus taxonomy template. (Actually, |parent=Varanus was used as the entry to the taxonomic hierarchy with |genus=Varanus as the genus name. |genus= is only used as the entry point when |parent= is absent.)

Using |parent= also makes formatting more consistent, because it's in the taxonomy template. So I agree with deprecation. Peter coxhead (talk) 19:42, 8 October 2020 (UTC)

The one thing I like about |subgenus= is that it allows the option of whether or not to link to the subgenus (which often doesn't have an article and may not be likely to have one anytime soon). However, I think #3 is best. Doing the work for option #3 is on my to-do list, but hasn't been a high priority (I did a run a couple years back where I converted all instances of |subgenus= to |parent=, but more have cropped up as additional manual taxoboxes have been converted to automatic). I had edited Short-tailed monitor, but somebody subsequently changed it back. I'd been leaving |genus= in place, even though I know it doesn't do anything when |parent= is present; I thought there is/was? a tracking category that pulled up instances of |species= without |genus= and vice versa (I also find it satisfying to have identical numbers for species/genus in the Template Data Error Report, but it's not really that important).

Usually, presence of any infrageneric classification scares me off from changing manual taxoboxes to automatic. I had started doing automatic taxoboxes for Sorbus species, but reverted myself when I found that the subgenera given in Wikipedia were different than those given in GRIN (one of the few botanical databases that (sometimes) has information on infrageneric classification). Making sure the infrageneric classification is correct requires a substantial amount of research. Some Carex and Tillandsia species articles have a subgenus/section, but many don't, and I haven't found a recent global classification assigning all species to subgenera. There seems to be a good recent infrageneric classification of Quercus, but the meat of it is a table that is very complicated to read. I'm nowhere near ready to deal with articles that have species complex/group parameters (but in principle, I think they should use |parent= and taxonomy templates). Plantdrew (talk) 19:46, 9 October 2020 (UTC)

I agree entirely that a serious problem with infrageneric classifications is that secondary sources (for plants anyway) don't support them, and primary sources are often old or disagree (or both). There is an argument that where an article contains a subgeneric classification which is linked to from many species articles (as is the case for Ficus at §Selected species), or where there are articles on the infragenera, the taxobox should be consistent, but I do agree about not normally adding such ranks to taxoboxes.

I'd been leaving |genus= in place, even though I know it doesn't do anything when |parent= is present; I thought there is/was? a tracking category that pulled up instances of |species= without |genus= and vice versa – this isn't quite right. If |genus= is absent, it will be picked up from the page title and the article will show up at Category:Speciesboxes with incorrect parameters specifying the taxon‎, which I fix most days. Either |genus= or |taxon= are always needed to supply the genus name. If the values of |parent= and |genus= are the same, then remove |parent=. Peter coxhead (talk) 08:22, 10 October 2020 (UTC)

It's not just a problem with plants. I was looking to remove |subgenus= from some frog and bird taxoboxes and ran into the sources issue. For Pristomantis, the secondary sources (APW6 and Amphibiaweb) don't use subgenus or species group. The subgenera were covered in a 2008 taxonomic revision (a hybrid of primary and secondary source by my reckoning), but a later revision only uses species groups. The subgenus should probably be removed, but I don't want mix fixing taxobox issues with editing content, which should involve checking for consistency across the genus (560 species). A more general point is should speciesboxes include infrageneric ranks if the genus article doesn't discuss them?

Another issue is variation in how the subgenus is displayed, with plain Subgenus (e.g. Nannomys in Baoule's_mouse), Genus (Subgenus) (e.g. Pristimantis (Pristimantis) in Pristimantis actinolaimus) or Genus subg. Subgenus (in various plant taxoboxes). The plain genus is more consistent with the rest of the ranks. Is there any particular reason why subgenus is handled differently? A minor issue is that some instances of |subgenus= contain a reference, but that can be moved to the template. —  Jts1882 | talk  09:40, 10 October 2020 (UTC)

Is there any particular reason why subgenus is handled differently? Yes. The nomenclature codes differ. The ICNafp mandates the use of a connecting term with an infrageneric name, so the "subg." is required for names regulated by this Code. The ICZN officially allows only the rank of subgenus between species and genus (from Art. 10.4: "A uninominal name proposed for a genus-group division of a genus, even if proposed for a secondary (or further) subdivision, is deemed to be a subgeneric name even if the division is denoted by a term such as "section" or "division"). So a connecting term would not be required, and isn't provided for in the ICZN. Since the subgenus name is uninomi(n)al, the plain subgenus as per Nannomys is correct. Parentheses are only mandated when a species or subspecies name is used (from Art. 6.1: "The scientific name of a subgenus, when used with a binomen or trinomen, must be interpolated in parentheses between the generic name and the specific name"). So if you want to show that Baoule's mouse is in the subgenus Nannomys, you must write the binomi(n)al as Mus (Nannomys) baoulei. As far as I can tell, there's nothing in the ICZN about writing the subgenus as Mus (Nannomys), although this style is certainly in use, and we agreed on it in the titles of taxonomy templates, because subgeneric names only have to be unique within a genus (or so I understand). Peter coxhead (talk) 16:51, 10 October 2020 (UTC)

subgeneric names only have to be unique within a genus (or so I understand). No, per Principle of Coordination, publishing a subgenus name also establishes that name at the rank of genus, with potential for homonymy. Plantdrew (talk) 17:39, 10 October 2020 (UTC)

Ah, thanks – I'm less familiar with the ICZN than the ICNafp. So there is never a real need to use the "Genus (Subgenus)" format for a subgenus? Peter coxhead (talk) 19:25, 10 October 2020 (UTC)

So, while we can refer to subgenus Nannomys, we have to use subgenus Banksia subg. Isostylis for plants. Seems rather redundant. Well, at least it makes the names of the taxonomy templates easier. The nominate subgenus needs disambiguation, e.g. Mus (Mus). —  Jts1882 | talk  08:25, 11 October 2020 (UTC)

@Jts1882: I think that in running text it's ok to write just "subgenus Isostylis" where the context genus is clear. Botanists certainly do, although ICNafp purists may disagree. But the formal name, which is what should appear in the taxobox, does have the genus and the connecting term.

Good point about the nominate subgenus. This does justify, I think, the consistent use of the format "Template:Taxonomy/GENUS (SUBGENUS)" for taxonomy templates for zoological subgenera (and indeed "Template:Taxonomy/GENUS subg. SUBGENUS" for botanical subgenera).

Earlier you wrote A more general point is should speciesboxes include infrageneric ranks if the genus article doesn't discuss them? I think the answer is "yes, if there's an article", because a primary purpose of taxoboxes is to provide navigation, and the subgenus article should contain discussion with sources. If there's no article (or redirect to a section of an article) for the subgenus, and it's not mentioned with a source in the species article, then I would answer "no". But that's just my opinion. Peter coxhead (talk) 08:53, 11 October 2020 (UTC)

OK, I've now got the number of instances of |subgenus= in Speciesboxes down to a single one, Sarcophaga pernix. There's quite a mess with that taxon; uncertainty about the appropriate species epithet, and it appears that subgenus given in the taxobox should actually be treated as the genus.

I'm sure more instance of |subgenus= will crop up as manual taxoboxes with that parameter are converted to Speciesbox, but finding them and change |subgenus= to |parent= shouldn't be too daunting. @Peter coxhead:, if you want to disable functionality of |subgenus= in Speciesbox, I think you can go ahead and do so now. Plantdrew (talk) 17:51, 15 January 2021 (UTC)

@Plantdrew: ok, I first removed |subgenus= at Sarcophaga pernix; it was misleading as you noted because it linked to an article that says that Ravinia is a genus. Then I removed the parameter from Speciesbox (after checking via the sandbox version that this didn't seem to cause any problems).

Revert the change to Speciesbox if it does cause problems. Peter coxhead (talk) 10:20, 21 January 2021 (UTC)

Is it possible to show ranks that don't have "always_display" set?

I am unable to figure out how to show intermediate ranks that are not marked with "always_display". The speciesbox on the article Bicellum is pretty devoid of information, the box should ideally show Eukaryota→Holozoa→Bicellum. – Thjarkur (talk) 09:06, 2 May 2021 (UTC)

You can use |display_parents=1,2,... to specify the number of parent taxa displayed. This is usually used to show the tribe ranks and subspecies or, if needed, additional ranks above family. In your case, I've set |display_parents=6 to show the taxa up to Eukaryote. —  Jts1882 | talk  10:08, 2 May 2021 (UTC)

Great, thanks. Have added a mention of this to the docs. – Thjarkur (talk) 10:33, 2 May 2021 (UTC)

@Þjarkur: good idea. I think the issue is that way back this template was treated as a kind of sub-template of {{Automatic taxobox}}, so information about common parameters wasn't repeated from that template's documentation, and it really should be. Peter coxhead (talk) 15:30, 2 May 2021 (UTC)

Simplification of template

In the Template:Speciesbox/sandbox, I've created a version of this template using Module:Template wrapper, which doesn't require explicitly copying all of the parameters through to Template:Taxobox/core. This tidies up the template and make future maintenance easier (because updates to Taxobox will just automatically carry over). There should be no change to the behavior of the template: all test cases work the same.

What do other editors think? Should we copy this to the main template? — hike395 (talk) 12:57, 26 May 2021 (UTC)

@Hike395: Sorry, I left a message on your talk page before I saw this post. Now moved here.

Your revisions don't didn't work with the spaced versions of some parameters, e.g. |parent authority=. The live version allows underline and space versions of two word parameters, mapping them to the underline version.

The live version allows all the two-word parameters to be used with underline or with space, so the great majority of parameters are not simply passed on, but mapped to the underline version.

In general, I think it's a bad idea not to explicitly pass on parameters. {{Taxobox/core}} services all the automated taxobox templates and the manual {{Taxobox}} template, with some very significant differences in the parameters that are passed to it from the different templates. A change made to Taxobox/core to support one of these templates is quite likely not be relevant to Speciesbox. It's much better, in my view, to document fully inside Speciesbox precisely which parameters are passed on. (Longer term, the plan is to convert Speciesbox to Lua, expanding Module:Automated taxobox, which currently supports other automated taxobox templates.) Peter coxhead (talk) 18:32, 27 May 2021 (UTC)

It was an error not to include any spaced parameter names in the test cases; now added at Template:Speciesbox/moretestcases#Spaced parameter names. Peter coxhead (talk) 18:49, 27 May 2021 (UTC)

@Peter coxhead: It would be tedious, but easy, to include a mapping from spaced parameter names to underscored ones in the sandbox version, using |_alias-map=. But I can see from the monthly parameter report and from subsequent edits [1], [2], [3], [4], [5] that Plantdrew (and perhaps other editors) have done a spectacular job in keeping the usage of this template very clean. As far as I can tell, there are no articles that use the parameter named with blanks in them. Perhaps it is time to deprecate those and simplify the template?

A deeper issue is that you seem to be objecting to the auto-pass-through property of Module:Template wrapper. Certainly, if editors don't want this behavior, then we can abandon the whole idea. I just thought it made the template easier to understand and maintain. — hike395 (talk) 01:36, 28 May 2021 (UTC)

@Hike395: when a back-end template services a single front-end template, then auto-pass-through is fine. But here, partly for historical reasons to do with the way the taxobox templates developed, {{Taxobox/core}} services multiple and notably different front-end templates. For example, {{Automatic taxobox}} passes on the parameters |type_species= and |type_species_authority= ({{Oobox}} and {{Ichnobox}} pass on the equivalent oo- and ichno- versions), whereas Speciesbox must not pass on any of these. Because it's more specialised, Speciesbox passes on notably fewer parameters to {{Taxobox/core}} than the other taxobox templates that use it, so auto-pass-through could easily lead to passing on incorrect parameters.

The working of the complete taxobox system is convoluted and hard to understand, even for those of use who wrote parts of it. A general software engineering principle is that for ease of maintenance, code should be self-documenting, as far as possible (or at least so I taught!). Explicitly listing all the parameters that Speciesbox passes on to Taxobox/core makes it absolutely clear what is happening and which parameters are handled. Auto-pass-through hides some of this. Peter coxhead (talk) 06:16, 28 May 2021 (UTC)

There are articles with manual {{Taxobox}} using spaced parameter names. I'm not making any effort at the moment to standardize parameter names in manual taxoboxes, and I wouldn't suggest that other editors spend their time doing so. I would suggest that other editors spend time converting manual taxoboxes to automatic ones, and I'm happy to cleanup spaced parameter names that slip through other editors work. I don't really understand the technical issues here; if the proposed sandbox edit breaks spaced parameters in manual taxoboxes, I'm against it. Spaced parameters should be deprecated in documentation, but breaking them in implemention is premature.

I'd praised Template_talk:Infobox_mountain/Archive_4#Parameter_use_stats for being very clean in the monthly parameter report. @Hike395:, you'd attributed that (at least in part) to Module:Check for unknown parameters, which I gather would be useful for taxoboxes templates. Plantdrew (talk) 03:54, 28 May 2021 (UTC)

There's recently been quite a spat over whether to more actively deprecate the non-hyphenated parameters in citation templates; the RfC resulted in a decision to keep the existing situation (which allows, e.g. |accessdate= and |access-date=). Removing all the spaced multi-word parameters would certainly make maintainers' work slightly easier, and I wouldn't be against it, but it would need agreement in a well supported RfC across all the tree of life WikiProjects. Peter coxhead (talk) 06:16, 28 May 2021 (UTC)

@Peter coxhead and Plantdrew: My suggestion about deprecating blank parameter names was limited to uses in {{Speciesbox}} only. However, it seems that there isn't consensus to use auto-pass-through, so I'll withdraw my proposal and revert the sandbox. Thanks for considering it! — hike395 (talk) 11:35, 28 May 2021 (UTC)

Checking for unknown parameters

Per Plantdrew, I added a check for unknown parameters for {{Speciesbox}} in the sandbox version. Any article with an unknown parameter to {{Speciesbox}} would be placed into Category:Pages using speciesbox with unknown parameters, which will be a hidden category. What do editors think? Should I promote this to main? — hike395 (talk) 17:43, 28 May 2021 (UTC)

Obviously I'm in favor. Plantdrew (talk) 18:54, 28 May 2021 (UTC)

Peter coxhead also expressed support on my Talk page, so I'll move to main. Please ping me here if anyone see any issues. — hike395 (talk) 07:46, 31 May 2021 (UTC)

|parent= was missing from the list of known parameters. I've added it, but it will take time for articles that use it that have been put into Category:Pages using speciesbox with unknown parameters to clear. Peter coxhead (talk) 08:38, 31 May 2021 (UTC)

Almost all of the entries in this category right now that I have looked at seem to be there because of this parameter, so it's not worth doing much checking until they clear.

Thanks for catching that! I just used AWB to perform null (or minor) edits, so the category is now clear. — hike395 (talk) 09:28, 31 May 2021 (UTC)

Hike395, looks like your change is causing many articles to render with "The named reference SOMETHING was invoked but never defined" errors. One recent example is Ascalista letourneuxi. This article has a blank "species=" parameter, and synonyms_ref={{r|worms}}. Why does the template extend the visiblity of the reference when the reference isn't used (because the parameter it is referencing isn't supplied)? How mnay articles will be affected by this problem? Here are three more examples: Euphorbia baioensis, Eucithara rufolineata, and Buccinaria okinawa. -- Mikeblas (talk) 18:48, 4 June 2021 (UTC)

@Mikeblas: the errors have nothing to do with Speciesbox. They are reference errors which will always show up when <ref name=X/> or the equivalent is present anywhere in an article but the reference with the name X is not defined. Peter coxhead (talk) 20:10, 4 June 2021 (UTC)

@Peter coxhead: of course, that's not true. The errors weren't apparent until the recent changes to {{Speciesbox}}. You can use the sandbox to work an older version and demonstrate that fact to yourself. This issue seems to affect several dozen articles, so I'm wondering what the plan will be to remedy the problem. -- Mikeblas (talk) 16:28, 5 June 2021 (UTC)

@Mikeblas: I will investigate and report back. — hike395 (talk) 17:38, 5 June 2021 (UTC)

@Mikeblas: I'm confused by this, in two ways:

1. Those errors seem correct to me: shouldn't undefined reference warnings show up in the reflist? I'm not entirely sure why you want to turn those errors off.
2. I'm puzzled about how the previous version of the template suppressed those errors. You seem to be asking to restore the prior behavior, and I have no idea how that behavior came about. My edit simply checked for bad parameters by invoking Module:Check for unknown parameters. As far as I can tell, this module is not supposed to affect the rendered output. So I don't know how to fix this. — hike395 (talk) 17:56, 5 June 2021 (UTC)

Later: many of these reference errors seemed to be introduced in the conversion of {{taxobox}} to {{speciesbox}}, e.g. [6]. Shouldn't we leave the error messages in so that Plantdrew or other editors can clean them up? — hike395 (talk) 18:15, 5 June 2021 (UTC)

Oh, I think I see what you're saying --- that the reference is not instantiated anywhere, so that it shouldn't generated a warning message. Somehow checking for the parameter is causing the reference to be instantiated, and then generates the error message. Interesting -- I would have thought this problem with Module:Check for unknown parameters would have shown up by now. This is very tricky -- let me think about this. — hike395 (talk) 18:20, 5 June 2021 (UTC)

|synonyms_ref= doesn't display if there are no values in |synonyms= (and this applies to other taxobox _ref parameters). I guess however this was processed previously, "doesn't display" also meant "wasn't checked for reference errors", and with the current code, these parameters are checked for errors. I can go through Category:Pages with broken reference names and clear out all the taxa. But I think display the error message shouldn't be suppressed. There's a flood of taxon pages in the error category now because suddenly, but that's only because the errors have been in place for years without being detected. I can clean those up, and there should be a trickle of new ones going forward.

I think there's a ticket out there pertaining to flagging template parameters as being "dependent" on each other; e.g., if there's a _ref parameter but no values being referenced, it should be an error (this would be broader than the behavior here; an undefined reference throws an error, but it would also throw an error with a defined reference that supports nothing). It would also apply to an image_caption being present without an image (I've come across some cases where an image was deleted, but the caption remained, then a new image was added with the caption that pertained to the old image). Plantdrew (talk) 18:48, 5 June 2021 (UTC)

OK, I think I've removed all the undefined references being called in speciesboxes. Plantdrew (talk) 20:03, 5 June 2021 (UTC)

Wow, Plantdrew! You're awesome at cleanup!

Given that this is some very tricky interaction between Lua and the Wikiparser, and given that we want to clean up these kind of errors, and given that Plantdrew has cleaned up all existing errors, I'll leave the template as-is. — hike395 (talk) 00:10, 6 June 2021 (UTC)

@Hike395: as far as I can understand Module:Check for unknown parameters, it seems that it has to process the values of parameters to some degree, in order to handle un-named positional ones which aren't of the form |NAME=VALUE, but appear just as |VALUE. Perhaps this is what triggers the parser to "notice" the undefined reference. Anyway, I agree that it's actually good to get these error messages.

@Plantdrew: I have thought about the "parameter dependency" issues, e.g. |subdivision_ref= or |subdivision_ranks= without |subdivision=. They would be relatively easy to check in {{Automatic taxobox}} because it's implemented in Lua in Module:Automated taxobox, but tedious to do in {{Speciesbox}} at present which is still in template code. My intention is to re-implement Speciesbox inside Module:Automated taxobox at some point, but it's a complex and potentially risky change, so I've only got as far as an offline draft. Peter coxhead (talk) 06:29, 6 June 2021 (UTC)

Thanks for the cleanups, @Plantdrew: ! -- Mikeblas (talk) 14:02, 6 June 2021 (UTC)

Proposed removal of parameters

binomial2 to binomial4

Template:Speciesbox has large chunks of logic mostly unchanged since 2011, including the set of parameters |binomialN=, |binomialN_authority=, |range_mapN=, |range_mapN_upright= [these were updated from |range_mapN_width=], |range_mapN_alt= and |range_mapN_caption=, where N = 2 to 4.

I've never really understood how |binomial2= to |binomial4= were meant to be used in Speciesbox; I wasn't seriously editing when taxoboxes were first constructed. (Maybe Plantdrew knows?) They are there now (I believe) because Speciesbox was originally copied from {{Automatic taxobox}} as it was then, but the parameter report shows they are not used. When I converted Automatic taxobox to Lua, I omitted |binomial2= to |binomial4= and the corresponding authority parameters, as they weren't used.

I believe that the range map parameters were originally meant to be used in conjunction with the corresponding binomial parameters, i.e. |range_mapN= should show the range of |binomialN=, but when they are used now, it's not like this – it's to show ranges in different parts of the world. So they are now no longer connected.

I propose to remove |binomialN= and |binomialN_authority=, but not the range map parameters. Comments? Peter coxhead (talk) 08:25, 6 June 2021 (UTC)

I think this dates to a time when there was lot less coverage of species articles. A taxobox for a small genus could list the binomials of the species, each with a range map. I still think this could be useful in {{Automatic taxobox}}, but {{Speciesbox}} would never need to show more than one binomial. Multiple range maps are still useful. So I support your proposal to remove the extra binomial parameters and all the trinomial parameters (below). —  Jts1882 | talk  09:19, 6 June 2021 (UTC)

 Done As there were no objections, I have made this change. Peter coxhead (talk) 06:01, 8 June 2021 (UTC)

trinomial

Speciesbox currently supports |trinomial= and |trinomial_authority=. Again, the parameter report shows they are not used. They should never be used, because {{Subspeciesbox}} or {{Infraspeciesbox}} should be used for zoological or botanical infraspecific taxa respectively. I propose to remove them. Comments? Peter coxhead (talk) 08:25, 6 June 2021 (UTC)

 Done As there were no objections, I have made this change. Peter coxhead (talk) 06:01, 8 June 2021 (UTC)

Type locality

When editing the taxonomy section of articles on bird species I normally include the type locality, often without using the technical term but by specifying the origin of the specimen described in the protologue. What are your views on adding the type locality to the Speciesbox template?

I apologise if this subject has already been discussed. - Aa77zz (talk) 08:35, 28 June 2021 (UTC)

My personal view is that taxoboxes already have a lot of information in them, so I'm not in favour of adding the type locality. It's not of the same taxonomic importance as other information in the taxobox, in my view. Peter coxhead (talk) 09:30, 28 June 2021 (UTC)

For bird species I note that although Peters specifies the localities, H&M4 does not. - Aa77zz (talk) 09:46, 28 June 2021 (UTC)

Error check for parent parameter calling genus or higher rank?

Would it be feasible to implement an error check for cases where |parent= is calling a taxonomy template with a rank of genus or higher? I came across a case today where an editor who wasn't familiar with taxoboxes had Toumeyella parvicornis calling Myzolecaniinae as |parent=; this resulted in the genus not be displayed in the speciesbox. iNaturalist has a feature which encourages users to create Wikipedia articles when iNaturalist has a page but Wikipedia doesn't. The tool includes an unnecessary |parent=. I've asked a couple time on iNaturalist forums to have parent removed, but it hasn't happened. Meanwhile, editors coming from iNaturalist are regularly creating articles with |parent= as the genus (which doesn't mess anything up, but isn't necessary). Plantdrew (talk) 02:13, 23 August 2021 (UTC)

@Plantdrew: I had a quick look. One problem is that I've long meant to convert Speciesbox to Lua (as is the case for {{Automatic taxobox}}, for example), but have never got round to it ("if it ain't broke, don't fix it", and it's a heavily used template should the conversion cause any problems). It's much, much easier to implement such checks in Lua. One problem is that a correct value of |parent= may not yet have a taxonomy template from which to determine the rank. The other might be determining whether the rank is higher than genus, because of the different uses of ranks like "series" (often used as the parent in plant Speciesboxes) in different parts of the tree of life. (Thus "series" is not checked in taxonomy templates; see Wikipedia:Automated taxobox system/taxonomy templates#rank.)

But I'll continue to think about it. As a minimum, maybe try to force genus always to be displayed. Peter coxhead (talk) 10:01, 23 August 2021 (UTC)

@Plantdrew: it may be easier than I first thought. There's a function "find" in Module:Autotaxobox which finds the value of a rank above a specified taxon given that it has a taxonomy template:

• {{#invoke:Autotaxobox|find |Sorbus subg. Sorbus |genus}} → Sorbus
• {{#invoke:Autotaxobox|find |Myzolecaniinae |genus}} →

So if this function returns "rank not found" for the genus when given the value of |parent= then the parent is either at or above the rank of genus or doesn't have a taxonomy template.

Perhaps this could put the article into a category like "Speciesboxes with apparently incorrect parent parameter". Thoughts? Peter coxhead (talk) 17:55, 23 August 2021 (UTC)

Actually, regularly searching for hastemplate:Speciesbox insource:parent -genus may be enough. Just now this found Tragopogon pratensis with |parent=Cichorieae, and Hyla surinamensis with |parent=Hylinae. I didn't fix either. Peter coxhead (talk) 18:07, 23 August 2021 (UTC)

Thanks, if cases can be found with a regular search, that's good enough for me. Plantdrew (talk) 02:13, 24 August 2021 (UTC)

Both articles, Tragopogon pratensis and Hyla surinamensis, now fixed. Annoyingly, I actually created the error at the former! Peter coxhead (talk) 06:56, 24 August 2021 (UTC)

Update on 5 October 2021

The template has been updated so that by default it handles × in a page title differently. The change will only show up visually to editors who have certain font families applied to page titles (h1 elements), namely font families that show italicized and unitalicized × differently. Apple's version of Times is one such example. I've tested as far as I can, but if any odd errors show up that apparently weren't there before, please let me know. Peter coxhead (talk) 09:22, 5 October 2021 (UTC)

How do you handle a plant and insect having the same genus?

Hi, how do you handle a plant and insect having the same genus? Someone has submitted Draft:Eugenia (fly) to AfC (needs work) but {{Speciesbox|genus = Eugenia}} gives the plant and I'm unsure how to use the automated taxobox system to differentiate? Cheers KylieTastic (talk) 10:49, 17 December 2021 (UTC)

@KylieTastic: You need to create a taxonomy template with the disambiguated name, which I've done at {{taxonomy/Eugenia (fly)}}. You also want to to use {{automatic taxobox}} rather than {{speciesbox}} for a genus containing more than one species. —  Jts1882 | talk  11:06, 17 December 2021 (UTC)

Thanks Jts1882 much appreciated. Cheers KylieTastic (talk) 11:18, 17 December 2021 (UTC)