Template talk:Taxobox/Archive 31

Archive 25

←

Archive 29

Archive 30

Archive 31

Colors

I think our current system of coloring taxoboxes is overly complicated and should be simplified. We have four different yellows, three different greens, and three different blues, for example. If I see that a taxobox is yellow, am I realistically going to remember which shade of yellow means what and actually be able to recognize that shade of yellow and say "Ah, this mush be an Opisthokonta?" No, not in a million years. Color-coding infoboxes in only useful when there is a clear intensity scale, like for Infobox hurricane, or they are limited to 3 or 4 colors that folks can actually recognize and easily distinguish. Otherwise, it serves no purpose for the reader. I would like to propose that we simplify on the following scheme:

• Animalia - brown (as it is currently)
• Archaeplastida/Plantae/Viridiplantae - green (as it is currently)
• Fungi - yellow?
• everything else - light blue?

I don't really care about the specific colors. Mostly I just want to simplify it. Thoughts? Kaldari (talk) 18:30, 28 November 2017 (UTC)

Current scheme

Animalia	rgb(235,235,210)
Archaea	rgb(195,245,250)	also Nanoarchaeota (Nanarchaeota), Korarchaeota, Thaumarchaeota, Crenarchaeota and Euryarchaeota
Archaeplastida	rgb(180,250,180)	also Plantae and Viridiplantae
Bacteria	rgb(220,235,245)
Eukaryota	rgb(245,215,255)	For eukaryotes with no other colour defined, including Excavata, Amoebozoa and Opisthokonta
Fungi	rgb(145,250,250)
Ichnotaxa	rgb(230,222,214)
incertae sedis	rgb(250,240,230)
SAR	rgb(200,250,80)	also Harosa, Chromalveolata
Ootaxa	rgb(250,250,220)
Viruses	rgb(250,250,190)	also Viroids

I can see a case for some simplification, but this seems too much to me. Viruses, ichnotaxa, ootaxa, incertae sedis taxa shouldn't be lumped in with everything else. I would also want to separate Bacteria and Archaea. Peter coxhead (talk) 20:05, 28 November 2017 (UTC)

How about something like this:

Viruses
Bacteria
Archaea, etc.
Animalia
Fungi
Archaeplastida, etc.
other
Colours not produced by this template:
Ichnotaxa
Ootaxa

@Peter coxhead: ^ Would that be a good compromise? Kaldari (talk) 07:24, 29 November 2017 (UTC)

For me the problem is that the scheme above involves changing the colour of taxoboxes for some major groups, like Fungi and Archaea. I'd be happy to lump SAR, Excavata and Amoebozoa under Eukaryota, but I wouldn't go further.

If you really want to go ahead with this, you need to advertise an RfC at all the Wikiprojects under WP:TOL and assess reaction. It's not something a few editors should decide. Peter coxhead (talk) 07:59, 29 November 2017 (UTC)

@Peter coxhead: How about this then: We remove SAR, Excavata, and Amoebozoa (letting them roll up to Eukaryota), and we change incertae sedis to other (covering all other cases). Kaldari (talk) 01:09, 5 December 2017 (UTC)

From a glance at the template parameters report for Taxoboxes, it looks like the SAR color might show up in around 1300 articles. Excavata and Amoebozoa are about 130 each. Opisthokonta is around 40. Opisthokonta should roll up to Eukaryota. I'm inclined to retain a separate color for SAR but don't feel very strongly about that. Plantdrew (talk) 04:06, 5 December 2017 (UTC)

@Kaldari and Plantdrew: I'd be happy to roll up Excavata, Amoebozoa and Opisthokonta to Eukaryota, as a first step anyway. I guess this should be advertised more widely if we want to go ahead. Peter coxhead (talk) 08:08, 5 December 2017 (UTC)

Refined proposal

In order to simplify the color schemes used by this template, it is proposed that Excavata, Amoebozoa and Opisthokonta be rolled up into Eukaryota. This will affect approximately 300 articles. The new color scheme will be:

Viruses	rgb(250,250,190)	also Viroids
Bacteria	rgb(220,235,245)
Archaea	rgb(195,245,250)	also Nanoarchaeota (Nanarchaeota), Korarchaeota, Thaumarchaeota, Crenarchaeota and Euryarchaeota
Eukaryota	rgb(245,215,255)	For eukaryotes with no other colour defined, including Excavata, Amoebozoa and Opisthokonta
Animalia	rgb(235,235,210)
Fungi	rgb(145,250,250)
Archaeplastida	rgb(180,250,180)	also Plantae and Viridiplantae
SAR	rgb(200,250,80)	also Chromalveolata
incertae sedis	rgb(250,240,230)
Colours not produced by this template:
Ichnotaxa	rgb(215,240,210)
Ootaxa	rgb(250,250,220)

If you have an opinion on this, state it below. Kaldari (talk) 05:50, 8 December 2017 (UTC)

@Peter coxhead: I've advertised the proposal at several relevant WikiProjects: Tree of Life, Microbiology, Plants, and Animals. Kaldari (talk) 06:01, 8 December 2017 (UTC)

• Strong support for any of the proposals. I prefer the one that wraps SAR into eukaryotes, though I don't have strong feelings about this. I don't think having many colors is hugely helpful with navigation or readability (in fact I think their primary purpose is for the pleasure of those of us who look at a lot of TOL articles) though I'm very happy to be convinced otherwise. Does anyone have thoughts on why more colors are better? I'm not trying to be dense; it's really just not immediately clear to me. Ajpolino (talk) 07:12, 8 December 2017 (UTC)

I think the value of the colours is greatest to two sets of readers/editors: those who read and work on articles in one area of the tree of life, who can then easily identify "their" articles; and those who work on taxoboxes across many areas of the tree of life, who do learn the main colours. As one of the latter group, it's of value to me that incertae sedis taxa, ichnotaxa and ootaxa are distinguished, since they need quite differently set up taxoboxes and/or taxonomy templates. But I see no need to separate out "protists" into arbitrary groups, which are changing constantly anyway. Peter coxhead (talk) 08:56, 8 December 2017 (UTC)

• Support a change to reduce the groups that are distinguished to the three domains (archaea, bacteria, eukaryotes); then within the eukaryotes, animals, fungi and plants (including algae) should be separated out. Incertae sedis taxa, ichnotaxa and ootaxa should continue to be distinguished, since they need quite differently set up taxoboxes and/or taxonomy templates. However, I strongly oppose any change to the taxobox colours for groups that are retained, so I don't support Kaldari's first set of colours as above. Peter coxhead (talk) 08:56, 8 December 2017 (UTC)
• Support, without prejudice against alternatives, as long as the result is simpler and has a good rationale.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  09:15, 8 December 2017 (UTC)
• Neutral. On balance I prefer the existing scheme to the proposed one. I don't like the lumping of eukaryote groups because it is unnecessary (the colours are only useful to those who pay attention) and because it seems a retrograde step towards the traditional kingdoms. An exception would be Opisthokonta, which seems unnecessary when animals and fungi are removed. If starting from scratch I would use similar colours for related groups (as currently for SAR and archaeplastida) so would change colours for Amoebozoa, Fungi and Animalia (the shades would be useful to those who pay attention and ignored by those who don't). However, I think Peter Coxhead is right about not changing the colours for existing groups. Overall, I don't really see any compelling reason for the proposed change.   Jts1882 | talk  10:01, 8 December 2017 (UTC)
• Support extreme simplification: use one colour for everything, as they do on German Wikipedia ([[1]]). I think colour schemes add complexity (and opportunities for unproductive disagreements about classification) without providing much information. However, I recognize that we're unlikely to abandon the scheme that is already in place. So, I could Support a scheme that separates out the domains, and can also see some value in giving the traditional kingdoms (Fungi, Animals, Plants/archeplastid algae) their own colours, as Peter coxhead suggests. That leaves the "other eukaryotes" (protists, effectively) with their own catch-all colour, which has some historic validity, and corresponds reasonably well with the way the turf is divided up within the research community. If we keep an incertae sedis colour, I would reserve it for organisms whose domain is uncertain. Deuterostome  (Talk) 15:40, 8 December 2017 (UTC)
• Support. One comment: rgb(250,250,100) (currently used for Excavata) is quite a distinctive color. Archaea/fungi, Ootaxa/viruses and ichnotaxa/Archaeplastida use very similar colors. I understand there are constraints on colors that can be used (e.g. to comply with accessibility guidelines, text has to contrast strongly against a background color, and text can be black, blue, purple (or, in theory, red)). In order to come up with 14 different colors that have the required contrast ratio, some fairly similar colors had to be used. I think it's a shame to totally abandon the fairly distinctive yellow used for Excavata if we're going down to 11 colors. Maybe switch Archaea (~260 articles) to use rgb(250,250,100)?

• Dislike. Hi! I wonder what's with the new scheme. Why are Excavata and Amoebozoa being changed? Just asking, not really insulting. Plus, isn't it nice to keep the original? -Caehlla Caehlla (talk) 02:48, 20 December 2017 (UTC)

New version ready for testing

I updated the sandbox templates. The results can be seen at Template:Taxobox/testcases. (The only noticeable difference is for Fonticula, the last example.) Kaldari (talk) 18:52, 11 December 2017 (UTC)

This has now been implemented. Enjoy your new simplified color scheme! Kaldari (talk) 21:57, 14 December 2017 (UTC)

It's perhaps worth pointing out that it will take a considerable time (weeks in my experience) before the database updates fully, so editors should expect to see the taxobox colour change when a relevant page is edited or purged. Peter coxhead (talk) 07:22, 15 December 2017 (UTC)

Leading &nbsp; for all _ref parameters?

x-posted this @ Template talk:Speciesbox#Leading &nbsp; for all _ref parameters?.

I've noticed varying degrees of in/consistency of having or excluding a leading   for the 3 |*_ref= parameters. Do we want to:

1. force a leading nbsp,
2. remove them for all 3 |*_ref=, or
3. just try to maintain a consistent style (all/none) on each page?

The current documentation suggests #2.

If #1 is desired, I can rig the template so it forces 1 nbsp, without duplicating an existing one.

Since I'm going through all the {{IUCN}} transclusions, I'd like to know which format to standardize to.   ~ Tom.Reding (talk ⋅dgaf)  20:46, 6 January 2018 (UTC)

@Tom.Reding: Including a nbsp seems to be quite rare from what I'm finding; 505 Taxoboxes with a nbsp for synonyms_ref, so maybe a couple thousand instances across all 3 ref parameters and the entire family of taxobox templates. I don't see any reason to include them. Are there any cases where the reference is forced onto the next line? I tried making my browser window as narrow as possible and refs stayed on the same line. If I'm not missing some benefit of including them, remove them all. Plantdrew (talk) 02:54, 7 January 2018 (UTC)

@Tom.Reding and Plantdrew: I agree; remove them all. A space there produces visible output that is contrary to MOS:REFSPACE. Peter coxhead (talk) 07:24, 7 January 2018 (UTC)

Sounds good; thanks! Just wanted to make sure.

{{thinsp}} is an option, but that can be taken care of at the template level, if desired.   ~ Tom.Reding (talk ⋅dgaf)  12:46, 7 January 2018 (UTC)

Please mention used classification system in taxobox.

(Initially asked here.) I have a request on improving taxobox. On a taxobox for a taxa; it should be explicitely mentioned; which system of classification has been used. If a mixture of system has been done (although that is highly unrecommended). It is important because classification systems change; where not only the taxa fusion and splits; but ranks of the taxa sometimes changes; and although quite rarely; rank names too changed. So whenever publish a taxobox; please mention which system of classification is followed. Best if a taxobox contain 2 or 3 columns for the hierarchies according to separate classification systems. This not only improve correctness of the articles; but also will work as better reference and would help literature search. Thanks in advance, RIT RAJARSHI (talk) 19:32, 13 February 2018 (UTC)

What taxa are you specifically suggesting this for? Plants? Animals? All? (Most animals do not have a system to reference, and in the area that I write articles on there are often no references to any systems at all. I will say now that 2-3 columns is not feasible to usable as an option, it would not display well on most devices or many monitors.--Kevmin § 02:58, 14 February 2018 (UTC)

This has been discussed several times before, and the same conclusion reached. The purpose of taxoboxes is to aid in navigation and, like all infoboxes, to summarize the article. They are already in danger of being over-complex for this purpose. The immediate parent levels in the classification should be sourced in the article, e.g. via an opening sentence like "W x is a species of Y in the family Z.^[1]" Any well supported alternative classifications should be discussed, e.g. under a heading like "Taxonomy". Adding all this to the taxobox is infeasible. Peter coxhead (talk) 09:41, 14 February 2018 (UTC)

Template-protected edit request on 10 March 2018

The statuses for New Zealand Threat Classification System (NZTCS) needs updating, as there are now different Categories. Perhaps it needs a version the way that IUCN does, to not leave old pages in the lurch? Or perhaps that just means they need updating as well. Nessie (talk) 22:51, 10 March 2018 (UTC)

Not done: please make your requested changes to the template's sandbox first; see WP:TESTCASES. — Martin (MSGJ · talk) 20:47, 11 March 2018 (UTC)

I think you overestimate my abilities. I have no idea what to do there. I dont know what triple brackets do. I can't find any text mentioning new zealand. Nessie (talk) 02:38, 12 March 2018 (UTC)

@NessieVL: This does not require any changes to the template itself but rather to the images used by the template. You can find them at the Commons in Category:NZTSC Category diagrams. You'd have to upload new versions of those images. They see comparatively little use, though, with species such as the North Island robin or the New Zealand greater short-tailed bat using IUCN instead of NZTCS. As an extreme example, File:Status NZTCS EX.svg is used in only two articles. It may be easier to switch to IUCN completely. Huon (talk) 14:50, 24 March 2018 (UTC)

@Huon: I think @NessieVL: is making a valid point and request. I'll attempt to do as suggested by MSGJ, though I too am coming from a place of ignorance when it comes to attempting this. The very reason for the existence of the New Zealand Threat Classification System (NZTCS) is because of the short comings of the IUCN system for New Zealand species. At present the NZTCS template is using categories from 2002. These were changed in 2008. However this has not yet been reflected in the template. I believe that this is the main reason the template is not being used - it is over 10 years out of date. This and the fact that there are few New Zealand based editors. I've been in discussions concerning this issue with another New Zealand editor @Giantflightlessbirds:. He will hopefully be getting a Wikipedia in residence position at the Department of Conservation in the near future. This is one of the issues we are hoping to get fixed so that the template can be used in NZ species edit-a-thons. If others could give guidance on how to go about this (in doing so please assume that you are talking to someone who has very little dealings with the Wikipedia template editing and creation process) I (and I assume Nessie) would be very grateful. I hope it is as easy as working out how to upload the images as suggested, but I suspect it may require more expertise that I have at present.Ambrosia10 (talk) 23:02, 7 May 2018 (UTC)

If there are changes to the template itself required, beyond the changes to the images hosted at the Commons, please explain how, precisely, input and/or output of the template should be changed. Maybe give an example of an article that currently uses the template and tell how it should differ? Huon (talk) 00:38, 8 May 2018 (UTC)

Use of taxobox to generate article short descriptions

Refer to Wikipedia:Short description and Wikipedia:WikiProject Short descriptions for background, and Template talk:Disambiguation and Template talk:Infobox settlement for some background on possible ways forward.

Since the RfC on short descriptions from WikiData was closed with consensus to provide local Wikipedia short descriptions, eventually for all articles, there have been several applications of template driven short descriptions for similar groups of articles. Notably places are served by a default short description produced by Template:Infobox settlement, which, while not perfect, does do a reasonable job most of the time of disambiguating place articles with an infobox. Local short descriptions can be provided to override the default short description where this will work better, and where an editor is willing to do the additional work.

There are a large number of articles on taxonomic groups, and the taxobox could be an efficient way of adding short descriptions to a large number of articles very quickly and efficiently, in a way that will automatically update as the taxonomy is revised.

I open this suggestion for discussion as to how the data already available in taxoboxes can be combined to create useful short descriptions at various levels.

In the case of a species (or genus), for example a useful short description for Jasus lalandii might be: "Species of spiny lobster in the family Palinuridae", where species and Palinuridae are directly available from the taxobox, but the common name for Palinuridae, ie "spiny lobster" is more difficult to reach.

Families might be given as members of an order, as for Palinuridae: "A family of marine crustaceans in the order Decapoda". Here again, family and Decapoda are easy to extract. Crustaceans not so easy, though Crustacea is simple enough. Marine may be difficult.

At this stage this is brainstorming to see if it is reasonably practicable to automate most of the taxa. Doing it all manually is the default option, but not a very attractive one. Cneers, · · · Peter (Southwood) ^(talk): 11:02, 5 May 2018 (UTC)

Discussion

• The short descriptions in the visual editor for article linking are from Wikidata I suppose - not sure I see the reason why a different description is needed in other contexts. PS: I see that a key reason given is that Wikidata is prone to vandalism - I think given that Wikidata is being extensively seen as the future of search and other aspects of Wikipedia, it seems to me that the focus (esp. of anyone in development at WMF) should be to fix the problems of Wikidata. Shyamal (talk) 11:54, 5 May 2018 (UTC)

  Shyamal, There is already consensus by RfC that Wikidata is not to be used. This may possibly change if Wikidata ever gets content policies that are generally compatible with Wikipedia, and their counter-vandalism reaches an comparable level. These appear unlikely in the foreseeable future, and until then we need our own short descriptions. Please read the explanations linked above if you want the full story, it is too long to repeat here. Cheers, · · · Peter (Southwood) ^(talk): 04:05, 6 May 2018 (UTC)

There are several major problem with using WikiData for our taxonomy, which I'm happy to repeat. It does not insist on reliable sources as we do. It is strictly hierarchical in its taxonomy, whereas we have various ways, e.g by using manual taxoboxes or devices like skip templates in automated taxoboxes, to allow different and incompatible classifications for different groups, e.g. dinosaurs and extant birds. WikiData serves all the language wikipedias, but there are different systems in use in different countries (e.g. for spiders we use the World Spider Catalog throughout, but for theraphosids the German Wikipedia uses Schmidt). The underlying issue is that taxonomy is subjective and sometimes hotly disputed, and so is not easily represented in a single relational database. Peter coxhead (talk) 09:09, 6 May 2018 (UTC)

I do understand that Wikidata has become, without sufficient discussion, a name-centric system rather than being taxon-centric. The manual entering of summaries looks rather too redundant and from this blog-post, one gets the impression that the problem has been solved - https://blog.wikimedia.org/2018/04/20/why-it-took-a-long-time-to-build-that-tiny-link-preview-on-wikipedia/ Shyamal (talk) 10:06, 6 May 2018 (UTC)

• Yeah this was another I was looking at. We can add the common name to each taxon's template to be retrieved; the more we fill the more specific the descriptions can be; so for some it'll be just "plant" for ones we have more specific it can be "flowering plant" and so on. Galobtter (pingó mió) 11:37, 12 May 2018 (UTC)

Lint errors (misnested tags)

Something in Taxobox (also speciesbox, etc) is generating lint errors claiming misnested <small> tags in, well, tons of things. I THINK it's stemming from whatever code formats the various authority arguments. It's beyond my ability to dig farther than that. Assuming it's not on a task list somewhere, could someone take a look at it? pauli133 (talk) 16:53, 15 May 2018 (UTC)

@Pauli133: if it happens with automated taxoboxes too, it may not easy to find out where, since the system involves a lot of templates, plus Lua code. There's a map of the automated part of the system at Wikipedia:Automated taxobox system/map. I think all the lines in a taxobox that have authorities in them are displayed by Template:Taxobox/core, Template:Taxobox/showtaxon or Template:Taxonomy, but I can't see any mismatched tags in any of them. Peter coxhead (talk) 18:48, 15 May 2018 (UTC)

sister group

Please add

{{#if:{{{sister|}}}|
! colspan=2 style="text-align: center{{#if:{{{colour|}}}|{{;}} background-color{{COLON}} {{{colour}}} }}"  {{!}} [[Sister group|Sister]]{{{sister_ref|}}}
{{!}}-
{{!}} colspan=2 style="text-align: left" {{!}}
{{{sister}}}
{{!}}-
}}
{{#if:{{{extant_sister|}}}|
! colspan=2 style="text-align: center{{#if:{{{colour|}}}|{{;}} background-color{{COLON}} {{{colour}}} }}"  {{!}} [[Extant taxon|Extant]] [[Sister group|sister]]{{{extant_sister_ref|}}}
{{!}}-
{{!}} colspan=2 style="text-align: left" {{!}}
{{{extant_sister}}}
{{!}}-
}}
{{#if:{{{extinct_sister|}}}|
! colspan=2 style="text-align: center{{#if:{{{colour|}}}|{{;}} background-color{{COLON}} {{{colour}}} }}"  {{!}} [[Extinct]] [[Sister group|sister]]{{{extinct_sister_ref|}}}
{{!}}-
{{!}} colspan=2 style="text-align: left" {{!}}
{{{extinct_sister}}}
{{!}}-
}} 

before the synonyms item to Taxobox/core template and

| sister = {{{sister|}}}
| extant_sister = {{{extant_sister|}}}
| extinct_sister = {{{extinct_sister|}}}

in the Taxobox template. This SHOULD be the same as in the sandboxes, but I can't be fully sure.

This enables the specification of sisters in the taxoboxes, as done now provisionally as an example for the Zygnematales page (using the sandbox versions). The reason why this is important that the definition of a taxon is usually done by also defining which taxa are NOT in the group. I am also requesting to specify the closest extant and closest extinct sister separately, as they can be different.Jmv2009 (talk) 11:01, 12 August 2018 (UTC)

Template-protected edit request on 15 August 2018

See request above. Tried to reach consensus, but no response received. I just improved formatting. There is no expected breakage, just an additional feature (modeled after "synonyms") Jmv2009 (talk) 17:17, 15 August 2018 (UTC)

This needs more discussion. Firstly, taxoboxes are already over-complex for infoboxes. Secondly, taxoboxes are based on the nomenclature codes, by and large, so that taxa are defined by types, not sisters. Thirdly, all the taxobox templates, manual and automated, should be kept in step, so would need updating for any change in Taxobox/core. I suggest you start a discussion at WP:TOL, notifying descendant wikiprojects. I personally am not convinced this is a good idea at present. Why does it need to be in the taxobox, rather than just in the text? Peter coxhead (talk) 17:36, 15 August 2018 (UTC)

Not done: please establish a consensus for this alteration before using the {{edit template-protected}} template. $\color {blue}\chi$_chi (talk) 09:07, 16 August 2018 (UTC)

QUIETER and less redirection

(Edited) {Taxobox/core} (for which this is the talk page) currently "shouts" {COLON} instead of {colon}. [Template:COLON] is just a redirect to [Template:Colon]. So "Templates used in this preview" of every calling page lists both [Template:COLON] and [Template:Colon]. I caught up the sandbox and then did {COLON} → {colon} (16 places) and some other cleanup (updated links) there. -- A876 (talk) 21:52, 5 November 2018 (UTC)

@A876: firstly, you don't mean this template, but {{Taxobox/core}}. (The reason for the caps is that {{COLON}} was the original name of the template, but it was later moved to {{Colon}}.) Secondly, why use the template anyway? All it does is insert :, so simply replace {{COLON}} by the entity. I'll double check first in view of the very large number of transclusions. Peter coxhead (talk) 22:55, 5 November 2018 (UTC)

Eh, the kind of change I'd wait until another more substantive change, given the number of transclusions. --Izno (talk) 22:57, 5 November 2018 (UTC)

Yes, with 390,000 transclusions, the load on the servers doesn't seem justified by what would largely be a cosmetic change, although worthwhile as part of a larger update. Peter coxhead (talk) 10:06, 6 November 2018 (UTC)

Actually, I don't think that a ":" in the position where {{Colon}} occurs in {{Taxobox/core}} does get interpreted as wikitext indentation; the tests I've done so far seem to confirm this (the ";" at the same point does have to be {{;}}, <nowiki>;</nowiki> or &#59;, but {{Colon}} can be replaced by :, I think). Peter coxhead (talk) 10:28, 6 November 2018 (UTC)

Cleaner is better. It would be great to go further and replace {{colon}} with : or even : (and other marks too) in {Taxobox/core} – but only if doesn't implode the universe. The Ancients used multiple {{!}}, {{;}}, and {{colon}} there (instead of !, ;, and :), but they didn't tell us whether they did it for readability (among all the { {{ {{{³³), or whether it is mandatory for correct functioning. I know {COLON} → {colon} at least "can't break it".

(Edited) The server cost would be the [automatic, silent] propagation of the edit to the cached expansions of the 390,171 dependent pages. A tiny server savings would occur whenever someone edits one of the 390,171 dependent pages (one fewer transclusion to trace each time); eventually a net savings? There might be a specific benefit when editing a page that directly transcludes {Taxobox/core}, but only 7 are reported ({Taxobox}, {Automatic taxobox}, ... .) (Disappointingly, I cannot get a definitive count of direct transclusions; transclusion reports mix all levels of transclusion.) Cosmetic is nice. - A876 (talk) 18:12, 6 November 2018 (UTC)

@A876: {{!}} and {{;}} or HTML entities are needed because in the context in which they occur | and ; are interpreted incorrectly during template expansion, whereas in my tests : is ok. Propagating a purely cosmetic edit to the cached expansions of 390,000+ dependent pages isn't a good idea. Peter coxhead (talk) 21:41, 6 November 2018 (UTC)

• I agree that : works better than {colon} in almost every way, so I updated the .../sandbox version.

• I'd keep {{!}}. It no longer invokes a template; it is a "magic word" that the parser directly replaces with |. So "Templates used in this preview" never lists "Template:!". Changing to | would give zero benefit; worse, it would reduce clarity.

• I'd keep {{;}}. Changing to &#59; would have a tiny benefit, but at the expense of reduced clarity. (And maybe someday they'll make another "magic word" of it.)

• I also updated some moved links (bypassed redirects). Before clicking, these are all piped links, so the change is only visible if someone looks at the hover-help. After clicking, the change is only visible in that they arrive on a page without the "(Redirected from Oldtitle)" notice. So yes, the whole impact is cosmetic (including the "good example" aspect). Though probably carbon-neutral – I re-did the server-cost estimate in my (edited) previous reply above. So try it soon, someday, or never; it's all good. - A876 (talk) 19:09, 7 November 2018 (UTC)

Subterclass adding request

Hello, I would like to request Taxobox to support subterclass. Previous discussion is at Wikipedia_talk:WikiProject_Gastropods#Subterclass. Thanks, --Snek01 (talk) 12:43, 21 November 2018 (UTC)

I don't think a consensus was established there yet. How precisely is it ordered relative to other "classis" ranks? Is it absolutely clear that different reliable secondary sources use "subterclassis" in a consistent way? Peter coxhead (talk) 16:40, 22 November 2018 (UTC)

Hello Peter, I do not know answers to your questions. It is really necessary to answer these questions? Yes, it would be nice to know those answers, but it is not necessary for now, because this rank will not interfere with other ranks and we can improve those details in the future. Also consider, that there is not possible to use any modern taxonomy of gastropods on Wikipedia. We can not use either Bouchet et al., 2017. We can not use its updated version from WoRMS (it is irony, that also Bouchet wrote it on WoRMS). The only reason we can not use neither of them is that it is not supported by taxoboxes. Also consider, that all replies at WikiProject Gastropods talk are not from WikiProject members, but from people, who know nothing about taxonomy of gastropods, but instead of that, they need to comment everything. Also consider, that you can not expect more comments from project members there, because it is trivial that boxes needs this improvement and because people are sick from discussions about boxes. It is vicious circle. People do not edit articles about gastropods, because Wikipedia does not support taxonomy of them. And Wikipedia does not support taxonomy of them, because people do not edit them. The only other possibility is taxobox supporting cohorts, subcohorts and grade sensu Bouchet et al., 2017. Is it a real problem to add few rows of code into the template when you know you can improve 30000 articles? If you hesitate which of those taxonomies taxobox should support, then you can support both. You will see what people will use. --Snek01 (talk) 14:19, 26 November 2018 (UTC)

@Snek01: well, it's not as easy to add extra ranks as you imply. We keep the manual and automated taxoboxes in synch, so changes have to be made in both systems. We must know exactly where in the system of ranks any new ranks go. I need to look at Bouchet et al. (2017). Peter coxhead (talk) 14:28, 26 November 2018 (UTC)

There is only one thing that we do not know: if is the subterclass above or bellow parvclass. User:Plantdrew wrote: "Parvclass and subterclass are clearly not the same." I have no idea how he was able to make such summary, but I trust him. I would bet that there has never been established relationship between these two ranks. But I believe that taxoboxes in Wikipedia can overcome it easily. And I believe that Wikipedia editors will be able to implement it quickly. We are delayed one year already. This only pitiful thing should not completely block updating taxonomy of the third largest group of animals! --Snek01 (talk) 16:16, 26 November 2018 (UTC)

The automated taxobox system has supported subterclassis since 11 Sept 2018. As an illustration, I have set up Aiteng ater to use {{Speciesbox}}. Click on the red pencil icon to see the complete taxonomic hierarchy. If you want more ranks to show in the taxobox between family and Euthyneura (which I've left as "clade" – this was the first taxonomy template up the hierarchy that already existed) then you need to add |display_parents= with some appropriate number as the value. The manual taxobox that was in the previous version of the article is an abomination; it completely distorts the proper layout of a taxobox and shows a ridiculous number of minor ranks. Taxoboxes aren't supposed to show the entire taxonomy, just enough to locate the taxon and navigate to the next level above. Peter coxhead (talk) 19:43, 26 November 2018 (UTC)

Peter, when I was talking about people who know nothing about taxonomy of gastropods, I was talking also about you. Your edits are not useful and it is very stressful to see them. For example there is a consensus on Wikiproject gastropods to use and view ALL ranks between superfamily and class. Yes, you can call it abomination, but it is the only thing you can do, because you should respect the consensus. Peter, you know this for very long time Wikipedia_talk:WikiProject_Gastropods/Archive_5#Is_Super_family_a_major_rank?. So I officially call to User:Peter coxhead to STOP distructing articles about gastropods. Thank you, --Snek01 (talk) 22:47, 26 November 2018 (UTC)

Could you be so kind and could you not driving me angry and could you make your proposals to the talk page, please? --Snek01 (talk) 22:58, 26 November 2018 (UTC)

Peter wrote "We keep the manual and automated taxoboxes in synch" and five hours later he has shown that one of taxoboxes support something for months because of him directly! I have no idea how to explain that he is continuously providing such disinformations. So its time to play fair and add support to the Taxobox too. --Snek01 (talk) 23:15, 26 November 2018 (UTC)

Let's simmer down here a notch, @Snek01:. Let's just discuss civilly here. Is there a way to find out the relation between parvclass and subterclass? (posted by NessieVL)

There might not be one. They seem to be alternatives used by different taxonomists for the rank below Infraclass. So until someone publishes a taxonomy using both the choice of which is higher is arbitrary.   Jts1882 | talk  09:26, 27 November 2018 (UTC)

@Snek01: It seems to me that you don't understand how taxoboxes work. As I explained before, "support" has two parts. Full support requires knowing the exact ordering of the ranks. The automated taxobox system can partially support any rank without knowing the ordering because the |parent= parameter in taxonomy templates specifies the hierarchy. The manual taxobox system cannot because any new rank parameter must be put in exactly the right place. If we don't know the exact place for a rank, we can't add it. It's as simple as that.

If you don't like my demonstration at Aiteng ater, just revert it and ignore it. The purpose was simply to demonstrate to you what is possible. You can show more ranks in a taxobox, as I pointed out, by adding |display_parents= with the appropriate number.

(I would also point out that consensus at a Wikiproject cannot over-ride site-wide consensus as to the purpose of an infobox, but that's not the issue here; the abomination is squashing multiple ranks into a single line of a taxobox.)

Peter coxhead (talk) 01:12, 27 November 2018 (UTC)

Regarding the abomination of gastropod taxoboxes (a description I agree with), between class and superfamily, manual taxoboxes support |unranked_subclassis=, |unranked_infraclassis=, |unranked_magnordo=, |unranked_superordo=, |unranked_ordo=, |unranked_subordo=, |unranked_infraordo=, |unranked_parvordo=, |unranked_zoosectio=, |unranked_zoosubsectio=, and |unranked_superfamilia=. That's 11 unranked "ranks" between class and superfamily, which is more than enough to support Bouchet 2005's system without shoving all of Bouchet's clades into a single line. Plantdrew (talk) 02:15, 27 November 2018 (UTC)

I've made a few changes to the taxobox in Aiteng ater (|display_parents=6 to show superfamily and subterclass) and the associated mollusc taxonomy templates. I set the ranks for Heterobranchia (subclass) and Euthyneura infraclass following Bouchet et al (2017) and WoRMS. However I then noticed that Bouchet ranks Tectipleura as cohort and WoRMS (and MolluscaBase) uses subterclass, even though it cites Bouchet. I left the taxonomy template unchanged at subterclass. Apart from that discrepancy, I think the taxobox follows the taxonomy of Bouchet and WoRMS. I think this is what User:Snek01 wanted.   Jts1882 | talk  08:27, 27 November 2018 (UTC)

@Jts1882: thanks. I wasn't sure about changing the ranks in existing taxonomy templates. I personally don't see the point of displaying so many ranks in the taxobox, but the point is, as I told Snek01, that it can easily be done.

Yeah! That is correct. Jts1882, Thank you. Now we can consider that the Speciesbox has functionality for taxonomy of gastropods. --Snek01 (talk) 13:16, 27 November 2018 (UTC)

@Snek01: so why didn't you add the |display_parents= parameter yourself, as I suggested, instead of complaining about me? Peter coxhead (talk) 13:36, 27 November 2018 (UTC)

Could it be possible to make the same functionality for Taxobox too? BE BOLD and implement it into the Taxobox, please. We need just this:

| infraclassis = something
| subterclassis = something
| superordo = something

Use ranks in this order: infraclassis, parvclassis, subterclassis, superordo. Thanks in advance, --Snek01 (talk) 13:16, 27 November 2018 (UTC)

Yes, it's possible to do this, but first we need more input and a consensus on the ordering of the ranks and why Plantdrew's suggestion of using the existing "unranked" parameters isn't adequate. Peter coxhead (talk) 13:45, 27 November 2018 (UTC)

Numerical rank for subterclass in the autotaxobox system

@Jts1882 and Plantdrew: equating "cohort" and "subterclass" seems problematic to me, because between the cohort group of ranks and the class group of ranks there can be legion group ranks and (zoological) division group ranks, at least in some areas of the tree of life. I would like to assign "subterclass" a number as per the table at Wikipedia:Automated taxobox system/taxonomy templates#rank, because this enables the automated taxobox system to check for a bad rank hierarchy being created (which does happen regularly). So long as the legion and division group ranks aren't used in conjunction with subterclass, using 1395 will place it just above cohort. Parvclass could be given the same number, provided both aren't used in the same hierarchy. Thoughts? Peter coxhead (talk) 13:07, 27 November 2018 (UTC)

Just below infraclass is the correct place for "subterclass" and "parvclass" as they are two alternatives for the next lower rank. They are clearly a rank above legion, cohort, division (zool) or section that get variously get placed between the class and order ranks. If I understand correctly, the numbers are just for internal reference and can be changed when needed. So you could set the two at 1395 and 1394 (arbitrary order). If someone ever published a taxonomy with both, then they could be switched later if necessary. Or is it better to make it impossible to use both until there is a need?   Jts1882 | talk  13:59, 27 November 2018 (UTC)

Yes, the numbers are just arbitrary. For orders, there are sources for the ordering of the prefixes (downwards) "sub", "infra", "parv", "micro" and "nano", and I've consistently given ranks with these prefixes numerical values −2, −3, −4, −5 and −6 respectively below the unprefixed rank (I can't remember now why I didn't start at −1). So given that class = 1400, parvclass should be 1400 − 4 = 1396. The next class-group rank down, microclass, does produce some Google Scholar hits in a taxonomic context, e.g. this paper mentions "Microclass Collembola". I haven't found "nanoclass". So, on reflection, perhaps for now both "parvclass" and "subterclass" should be at 1396, and we'll see if that ever produces any problems. I'll wait to see if there are any more comments. Peter coxhead (talk) 15:01, 27 November 2018 (UTC)

@Jts1882: ok, I've now added "parvclass" and "subterclass" at 1396. Let's see if that works as more taxonomy templates using these ranks get created. (By the way, I think it should be "parvoclassis" and hence "parvoclass", by the standard Latin combination rules, but sources omit the "o", so we have to.) Peter coxhead (talk) 16:11, 28 November 2018 (UTC)

Adding subterclass to {{Taxobox/core}}

As will be clear from earlier discussions, I am deeply reluctant to keep adding yet more rank parameters to {{Taxobox/core}} and the manual taxobox templates that drive it. In my view, it's already over-complex, making both use and maintenance difficult. My understanding is that it was designed when it was assumed that taxoboxes would almost always display only the principal Linnaean ranks, but has grown piecemeal to the state it is in now. I think that deep taxonomic hierarchies are handled much better by the autotaxobox system. However, I will of course abide by the consensus, and any editor with template editing powers can add |subterclass=. What is wrong with using an automated taxobox or using the existing unranked parameters if a manual taxobox is deemed essential for some reason? Peter coxhead (talk) 15:01, 27 November 2018 (UTC)

Are you joking? After those all discussions above you are writing that Taxobox is over-complex? When I requested the one rank, I expected the reply like this: "Thank you very much for your valuable and useful suggestion especially when you are only one from the Wikiproject who is still willing to talk to us. We will do our best to fulfill needs of the Wikiproject Gastropods to attract more editors. We are happy that taxonomy of gastropods switched from unranked clades to Linnean ranks as it was a wish of numerous people for very long time. That was very clever to the Wikiproject Gastropods that they did wait nearly a year to not request adding cohorts, subcohorts and grades, but they just need only one Linnean rank. When you will need anything, just let us know, no problem." I am sad, that I must beat you up with arguments and to kick you up to do anything. But it is no problem, as I edit only gastropods articles, this is the only possible way forward. This doesn't hurt my karma. I hope that it does not hurt yours. --Snek01 (talk) 15:45, 28 November 2018 (UTC)

@Snek01: with assistance from Jts1882 I have shown you that it's perfectly possible to include all the currently required ranks with an automated taxobox, and this was the preferred approach to taxoboxes in a recent discussion at WikiProject Tree of Life, so please address the first part of my question above: What is wrong with using an automated taxobox? Peter coxhead (talk) 15:57, 28 November 2018 (UTC)

Let me cite per Wikipedia_talk:WikiProject_Tree_of_Life/Archive_41#Request_for_comments:_Should_the_automatic_taxobox_system_be_the_current_recommended_practice? words by User:Jts1882: "A lot of the arguments against the automatic taxobox seem to fall on the fact that it is not universally implemented." --Snek01 (talk) 16:46, 28 November 2018 (UTC)

Sure. Then let's implement it for gastropods. Peter coxhead (talk) 16:57, 28 November 2018 (UTC)

(edit conflict) Is there any problem with the automatic taxobox in Aiteng ater with the changes I made to the taxonomy templates? If that delivers what is needed, especially the display of subterclass and superfamily, I'm willing to set up the higher level taxonomy templates following WoRMS.   Jts1882 | talk  15:59, 28 November 2018 (UTC)

Very good. Thanks, that is kind of you. Yes, I am really happy to hear that you wanna join and help. But this is not a question we can resolve here. How about to find other volunteers at Wikipedia:WikiProject Gastropods to do it with COOPERATION with them as well as with cooperation with me? I think, that I will have slightly different proposal there; not completely different, but slightly different. I alone can not approve or disapprove this question from malacological and from technical view. I will count on you. Could you be so kind, and could we wait for resolving this discussion at this talkpage and then lets move to the Wikiproject, please? --Snek01 (talk) 16:46, 28 November 2018 (UTC)

@Jts1882: can I just make a plea that |refs= is completed in the taxonomy templates. I regularly have to fix broken taxonomy templates, and having a reference to check what should be there is really helpful. Peter coxhead (talk) 17:45, 28 November 2018 (UTC)

Yes, I intend to. I know I often forget when making changes in a hurry, but this should be a more systematic effort and they will largely use WoRMS. As the WoRMS pages show the parent, is the parent reference necessary or could an ibid be useful to indicate the reference has both?   Jts1882 | talk  17:52, 28 November 2018 (UTC)

Although it's a bit tedious, it is useful to complete all the |refs=, because you don't see the child refs if you happen to be editing in the middle of the classification hierarchy, so "ibid" isn't helpful. Also if something changes lower down, the refs there may no longer be relevant higher up. (I have to confess that I too don't always follow my own advice!) Peter coxhead (talk) 18:34, 28 November 2018 (UTC)

So if I'm editing the taxonomy template for Heterobranchia (link), then the same reference should be entered for Ref and Parent Ref?   Jts1882 | talk  20:07, 28 November 2018 (UTC)

{{Taxonomy/Heterobranchia}}, and all the other txonomy templates, only has the |ref= parameter. To adjust the parent's reference, you need to go to {{Taxonomy/Gastropoda}}. --Nessie (talk) 20:15, 28 November 2018 (UTC)

(EDIT CONFLICT) Parent reference is inherited from the parent taxonomy template. So Template:Taxonomy/Gastropoda should have a link to the WoRMS record for Gastropoda, which will then be displayed in the Heterobranchia template.

In my opinion, it would be better to use a printed reference when an appropriate one exists (e.g. Bouchet 2017 for gastropods). Databases may be changed without warning, leading to a disconnect between what the taxonomy template says and what the database says. If a particular publication with a wide consensus is cited (such as Bouchet 2005 or APGIII), it will be more obvious to people with some familiarity with the state-of-the-art taxonomy for a particular group that reference is outdated at the point when a newer version is published. I do recognize that it's harder to verify with a printed publication than a database; even when the publication is freely available electronically, it usually requires downloading a massive PDF rather than a quick query of a database. And in the particular case of gastropods/Bouchet 2017, WoRMS uses subterclass, but Bouchet does not, so it may be better to stick with WoRMS rather than adding taxobox support for even more ranks. Plantdrew (talk) 20:20, 28 November 2018 (UTC)

Yes, this is thing I can agree with. This is exactly one of reasons why this request on this talkpage was added. I like the last sentence. Plantdrew clearly described why WoRMS should be used with caution. Plantdrew also described why adding subterclass to the Taxobox is the best of all available solutions we know so far. Thank you for your support. I will certainly use these Plantdrew's words in the Wikipoject Gastropods discussions, which will naturally emerge. This discussion is only about adding support of subterclass to Taxobox. Everything else is completely off-topic. This is not right place where these off-topic themes should be solved and resolved. This discussion is not about which taxonomy we will be using and it is not about which technical ways we will be using. Could we conclude this discussion and this request to successful final? --Snek01 (talk) 23:39, 28 November 2018 (UTC)

@Snek01: as far as I can see, we have reached a "successful final". Taxoboxes support subterclass, as per WoRMS, via the automated taxobox system, as has been demonstrated in several articles. A start has been made on setting up the necessary taxonomy templates. Which classification system should be used is, as you say, not a matter to be discussed here (and certainly not one that interests me). Peter coxhead (talk) 15:13, 29 November 2018 (UTC)

NO, NO, NO, NO, NO, NO. Peter, you did understand no single sentence I wrote here. --Snek01 (talk) 14:24, 30 November 2018 (UTC)

@Snek01: sorry, but it's you that don't understand – I'm aware that English is not your native language. Please read the last sentence of Plantdrew's comment again. It absolutely does not say what you put in bold above. Taxoboxes now support subterclass via the automated taxobox system; no-one, including you, has put forward arguments as to why this isn't satisfactory. I see no point in continuing this thread if you are not going to engage in rational discussion. Peter coxhead (talk) 14:40, 30 November 2018 (UTC)

Well, you are right. Plantdrew only explained that using subterclass is the best of all available solutions we know so far. That is right, that I did not put arguments why this isn't satisfactory. But I do not want functionality of subterclass in the Taxobox template for myself only. I want this functionality to be available for all editors. When you want to hear arguments, they are all arguments against the automatic taxobox that have ever been written anywhere on Wikipedia. Those are also my arguments, all of them. You already asked to this question above and you receive the answer and you replied "Sure. Then let's implement it for gastropods." --Snek01 (talk) 17:19, 30 November 2018 (UTC)

When @Plantdrew: wrote: "... it may be better to stick with WoRMS rather than adding taxobox support for even more ranks" he was not talking about subterclass. Words "even more ranks" means "cohorts, subcohorrts and grades". Those "more ranks" in Plantdrew's sentences does not mean subterclass. --Snek01 (talk) 17:28, 30 November 2018 (UTC)

I didn't say subterclass support was the best solution. It is a simpler solution than adding cohorts, subcohorts and grades (or legions). And it's a solution that has been partially implemented. I don't have a firm opinion on the best solution. Plantdrew (talk) 18:21, 30 November 2018 (UTC)

Thanks for input. This is the exact interpretation I had always in my mind. --Snek01 (talk) 18:29, 30 November 2018 (UTC)

Template-protected edit request on 20 December 2018

The classification status only works with automatic taxobox. This is because it is nested in the edit link if statement, so doesn't work with taxobox.

Existing code:

{{#if:{{{edit link|}}}|{{edit taxonomy|{{{parent|}}} | {{{edit link}}} }}{{#if: {{{classification_status|}}} | <br/>({{{classification_status}}}) | }} }}

Suggested change:

{{#if:{{{edit link|}}}|{{edit taxonomy|{{{parent|}}} | {{{edit link}}} }} }}{{#if: {{{classification_status|}}} | <br/>({{{classification_status}}}) | }}

  Jts1882 | talk  07:36, 20 December 2018 (UTC)

 Done See e.g. Haptista (although I don't think this is how the parameter should be used). Peter coxhead (talk) 07:48, 20 December 2018 (UTC)

It gets undue prominence. Perhaps it would look better if unbolded and wrapped in the <small> tag.   Jts1882 | talk  07:58, 20 December 2018 (UTC)

(For the record, the incorrect nesting of {{..}} which caused classification status to disappear was actually introduced by me on 7 November 2017, as a side-effect of putting the status on a new line. As an old LISP programmer, even having written a book on it, you'd think I could cope with brackets!) Yes, I agree it's too prominent. I've made it not bold (see Haptista again). I'm a bit reluctant to make it smaller because it appears on a coloured background, where smaller text can cause visibility problems for some people. Peter coxhead (talk) 09:56, 20 December 2018 (UTC)

Change needed for classification status

In section "Classification status" (first mention of parameter "classification_status"), it refers by wikilink to Veratalpa as an example of disputed classification status in a taxobox. The taxobox for that article does not contain the parameter.

Could someone perhaps replace this with an article with a taxobox that contains the classification_status parameter? Is it possible to search for all articles with this parameter where classification_status=disputed? That would, possibly, remove the need to revise this doc in the future.

Thanks, Prime Lemur (talk) 02:56, 20 December 2018 (UTC)

Taxoboxes with parameter classification status are listed here. However, it isn't displaying in the taxobox. Odd that, it looks like the parameter is passed to the taxobox/core and the core still handles it. Update I converted one example to automatic taxoboxhis, where it is working (see in Tomistominae). The problem is in the core as listed in the change requested below.   Jts1882 | talk  07:19, 20 December 2018 (UTC)

 Done Veratalpa replaced by Baranophrys. Peter coxhead (talk) 10:02, 20 December 2018 (UTC)

Thank you both for sorting this out! Its the second time in a couple of weeks you've assisted me, Peter ... cheers. And thanks for pointing me at WMFLabs for the template parm search, Jts1882. --cut: posting related but off-topic question on Peter's talk page-- — Preceding unsigned comment added by Prime Lemur (talk • contribs) 12:16, 20 December 2018 (UTC)

Tracking category for classification_status?

Just an idea, and maybe it's already a thing and I just didn't find it. I was wondering if we could have a tracking category for taxoboxes that use the |classification_status= parameter. I think it would help keep track of articles that may have barriers to converting to automated taxoboxes, but I can see it being useful for articles with autoboxes as well. The variable used for the parameter should not matter, as they all basically mean there is some sort of problem or dispute with the classification of the taxon. I'm thinking this would not be too hard to implement, but I'm barely a script kiddie so what do I know. Currently there are about 23 articles using the parameter, but I see the number growing as editors work on upgrading taxoboxes, especially those at the bottom of the barrel. What do ya'll think? --Nessie (talk) 15:42, 13 February 2019 (UTC)

Looks this stopped working during the update to the lua version of {{automatic taxobox}}. Line 133 has two spurious "{" characters in the classification status parameter, which I think must be the cause of the error.   Jts1882 | talk  15:58, 13 February 2019 (UTC)

classification_status = args['{classification_status'] or args['{classification status'] or '', 

I've made a formal "Template-protected edit request". This classification status parameter should help me get the formal qualifications for template editor.   Jts1882 | talk  16:07, 13 February 2019 (UTC)

So now the change is made in the module abd the parameter is displaying in taxoboxes properly, but what about a category? --Nessie (talk) 16:46, 13 February 2019 (UTC)

Basionym?

How do I list a plant's basionym? Please ping responses. –MJL ‐Talk‐^☖ 18:33, 28 December 2019 (UTC)

@MJL: There isn't a parameter for this. I suppose you could put "(basionym)" after the appropriate name/authority combination in the list of synonyms in the taxobox. (For example, after the second synonym at Aleuritopteris grevilleoides.) However, there's no consensus to put this information in taxoboxes, which many think are cluttered enough already. The basionym should, of course, be mentioned in a Taxonomy section. Peter coxhead (talk) 21:57, 28 December 2019 (UTC)

@Peter coxhead: [Thank you for the ping] Okay, so I don't really edit much in this topic space besides just translating articles into Scots. I don't really know what Taxonomy really means... I'll just ask then if Asteriscus aquaticus works? –MJL ‐Talk‐^☖ 22:50, 28 December 2019 (UTC)

@MJL: yes, that's fine. (Two small points: don't link synonyms, since by definition they should not lead to separate articles; the convention here – not my choice! – is to use lower-case for English names.) Peter coxhead (talk) 09:36, 29 December 2019 (UTC)

@Peter coxhead: Oh, I was just copying this article. I thought it was weird to link redirects like that, but I just went with it. Thank you for all the help and advice! :D –MJL ‐Talk‐^☖ 16:06, 29 December 2019 (UTC)

@MJL: actually I find redirects wikilinked all over the place. Another pointless use of wikilinks is when the English name and the scientific name are both wikilinked, yet one redirects to the other, so you get something like "rosemary (Salvia rosmarinus)". Peter coxhead (talk) 16:52, 29 December 2019 (UTC)

The most prolific creator of plant synonym redirects used wikilinks to create them and usually didn't remove the links after creating the redirects. I try to remove synonym redirect links when I'm switching manual taxoboxes to automatic. Plantdrew (talk) 18:41, 29 December 2019 (UTC)

I wonder, is there a case for some sort of linked symbol for the basionym, akin to the use of the † template for extinct forms? Aleuritopteris grevilleoides ^BN.   Jts1882 | talk  15:32, 29 December 2019 (UTC)

@Jts1882: I suspect that those who will want to know the basionym will be able to work it out from the authorities in the case of plants and from the dates in the case of animals. But it's an idea. Peter coxhead (talk) 16:54, 29 December 2019 (UTC)

It can't be worked when there's a replacement name involved, but that's not very common.Plantdrew (talk) 18:32, 29 December 2019 (UTC)

Ranks in virus classification

The instruction not to use higher ranks than orders for viruses should be changed as the International Committee on Taxonomy of Viruses now uses higher ranks. Lophotrochozoa (talk) 11:05, 26 April 2020 (UTC)

Well spotted. For viruses, {{Taxobox}} should not be used at all; always use {{Virusbox}}. The parameters exist for historical reasons. I have changed the documentation. Peter coxhead (talk) 18:55, 28 April 2020 (UTC)

Common names

I wonder why there is only provision for one common name. Including them in the Taxobox would make it easier to find them for users, but also easier to incorporate in structured data like wikidata. --Macrakis (talk) 17:28, 29 May 2020 (UTC)

|name= is the name for the taxobox caption if the default based on other parameters is unsuitable. It can be the common name or scientific name, but has to be a unique value. Listing common names (say as with synonyms) would be a new feature. —  Jts1882 | talk  20:01, 29 May 2020 (UTC)

Yes, I'm just wondering if there's some reason we don't already have that. I wouldn't want to change the template without benefiting from past discussion of things like this (which might be elsewhere in the MOS or whatever). --Macrakis (talk) 20:38, 29 May 2020 (UTC)

Binomial authority not displaying at Acidisoma

There's possibly a template issue there. Either in the taxobox itself, or in the article. I'm not a botanist, so I'll leave it to others to fix. Headbomb {t · c · p · b} 17:24, 9 July 2020 (UTC)

 Done (Not a species taxobox, so there is no "binomial authority".) Peter coxhead (talk) 20:07, 9 July 2020 (UTC)

Queensland Nature Conservation Act 1992

In August 2020, the Queensland Government introduced new wildlife classes under the CAM (Common Assessment Method) to improve the alignment between Queensland and IUCN wildlife classes and criteria so that the list of threatened species for Queensland is similar to that under the Australian Government Environment Protection and Biodiversity Conservation Act 1999. This template (or perhaps some other template?) needs to be edited to reflect that fact. Gderrin (talk) 22:04, 9 September 2020 (UTC)

What specific changes need to be made? A quick look at the linked source suggests they have added EX (extinct) and CR (critically endangered) to those handled by the template. —  Jts1882 | talk  07:03, 10 September 2020 (UTC)

Thanks Jts1882. I created the article Prostanthera mulliganensis and added the conservation status CR (QLDNCA) but it shows as Invalid status. EX (extinct), CR (critically endangered) and VU (vulnerable) have been added. Any help much appreciated. Gderrin (talk) 07:56, 10 September 2020 (UTC)

 Done Add CR and EX statuses. —  Jts1882 | talk  08:36, 10 September 2020 (UTC)

References

Correction to Template:Taxobox/core made

I'm always very reluctant to change this vital template, but I found an error that has been there since 2011, although the parameter that would have revealed it (|type_oogenus=) doesn't seem to be used. I can't see that the correction can cause any problems, but I'm noting it here just in case. Peter coxhead (talk) 08:30, 7 October 2020 (UTC)

Template-protected edit request on 6 January 2022

In each section of {{#if:{{{extinct|}}}|{{#ifeq:{{{extinct}}}|yes||{{#ifeq:{{{extinct}}}|true|| ({{{extinct}}})}}}}}}, please add the letter y as an excluded string. Animal lover 666 (talk) 16:47, 6 January 2022 (UTC) Animal lover 666 (talk) 16:47, 6 January 2022 (UTC)

 Done. P.I. Ellsworth - ed. ^put'r there 19:02, 6 January 2022 (UTC)

@Animal lover 666 and Paine Ellsworth: I was just working on a simplified version of such in the sandbox which I have now applied with this edit. —Uzume (talk) 19:08, 6 January 2022 (UTC)

"Two great minds"? I was thinking as I made the edits about how that could be so much simplified with the switch function. Excellent work, Uzume! P.I. Ellsworth - ed. ^put'r there 19:29, 6 January 2022 (UTC)

Just to note that |extinct= in {{Speciesbox}} has two functions:

1. It's passed to {{Taxobox/species}}, where if the status is "EX" and extinct is not absent, blank, "yes", "true", or (now) "y", it puts the value of extinct in parentheses after the word "Extinct" (e.g. "c. 1875" at Broad-faced potoroo).
2. If not absent or blank, it ensures that † is put before the species name when the genus is not extinct.

This means that in neither case does a plausible but incorrect use, like |extinct=no, behave as might be expected. Perhaps it should. Peter coxhead (talk) 12:01, 7 January 2022 (UTC)

@Peter coxhead: Yes, I seriously considered moving to something like:

{{yesno|{{{extinct|}}}|yes=|def= ({{{extinct}}})}}

Which would effectively map extinct case-insensitive forms of absent, whitespace-blank, Yes, y, true, on, 1, No, n, false, off, 0 and ¬ all to empty string but anything else would yield  ({{{extinct}}}). I choose not to because that was well beyond the request and I was not sure that sort of behavior was expected.

It should perhaps also be noted that {{Taxonomy/}} templates in the WP:TX system also have an extinct field with similar usage (i.e., the † dagger, etc). A significant portion of that system is handled by Module:Autotaxobox (which {{Speciesbox}} uses) where extinct values are handled as absent or whitespace-blank, no and false imply "no" and yes and true imply "yes". This makes me wonder if it should be converted to use Module:Yesno or the above request should have been denied (based on the fact that "y" should not be handled such). —Uzume (talk) 15:28, 7 January 2022 (UTC)

@Uzume: because the taxobox system has been built up over a long time now, and by different editors, there are inconsistencies in the way that parameters are used. For clarity, I'll repeat the three distinct uses of |extinct=:

1. In taxonomy templates, it defines whether that taxon is extinct or not. The documentation here says that only "yes" and "true" mean "extinct"; all other values or the absence of a value mean "not extinct".
2. In a {{Speciesbox}}, the taxonomic hierarchy is almost always picked up from the genus. So if the genus is not extinct, but the species is, |extinct= must be set. Its use is explained here. Any nonblank value, including a date or free form text, means "extinct".
3. If status EX is set in a taxobox, manual or automatic (including {{Speciesbox}}), a nonblank value of extinct can be used to contain information about the extinction, usually in the form of a date, which is then displayed in the taxobox. Values of "yes", "y" and "true" suppress the display.

So it's messy, because uses (2) and (3) involve the same parameter, but have different meanings. It would have been better if the date information about the extinction had been conveyed in a different parameter; then uses (1) and (2) could have used the Yesno approach. As it is, only (1) could. Peter coxhead (talk) 16:16, 7 January 2022 (UTC)

Separate the parameters? Leave |extinct= to display the extinction symbol and a new parameter (|extinction_date=?) to display dates? I'll populate a new parameter if it is created; looks like there are only ~200 instances of dates in |extinct= across all taxobox templates. Plantdrew (talk) 16:43, 7 January 2022 (UTC)

That seems a good solution as the current situation is confusing. I get 169 cases with speciesbox, 66 with subspeciesbox, 7 results with automatic taxobox, and 1 result with taxobox.

I'd also keep the options limited to yes and true, consistent with the taxonomy templates. —  Jts1882 | talk  17:13, 7 January 2022 (UTC)

I agree it's a good solution, although it will need very careful implementation, starting with {{Taxobox/core}}, which I personally am always reluctant to touch. If the parameters are separated, then the taxonomy template and the 'Speciesbox' use can be given the logic of {{yesno|def=|...}}, which will allow "y". I'll investigate further. Peter coxhead (talk) 17:35, 7 January 2022 (UTC)

(The Taxobox example, Pied raven, had a bad taxobox: it needed a line below the subspecies line for the morph, where † is added manually. Peter coxhead (talk) 17:46, 7 January 2022 (UTC))

I like the idea of introducing a new parameter for the extinction date and deprecating the older one that supports only "yes" or "true". We could add tracking and a warning during edit, if the old parameter is used while still supporting its deprecated usage. —Uzume (talk) 18:35, 7 January 2022 (UTC)

@Peter coxhead: So if I understand things, usage 1 and 2 are technically distinct, however, 3 effectively merges the two usages somewhat (and thus the messiness). In trying to keep things aligned what do you suggest? Should this change be added to the documentation at Template:Speciesbox#Extinct species or should the use of "y" be removed (effectively reverting/denying this request)? —Uzume (talk) 18:26, 7 January 2022 (UTC)

It seems to me the concept of extinction, as an event, could always be represented by some sort of date (although we probably need some sort of inexact dating system that support BCE dates) or the the lack thereof. It would be nice to convert them all to such but we would have to handle the existing "yes" and "true" values as "extinct since unknown". It would also be nice to represent them as periods of time until now (like {{start date and age}} does). For example, it would be cool if the Infobox on Tyrannosaurus could somewhere render something like "extinct for 68–66 Ma" based on the value at Template:Taxonomy/Tyrannosaurus (or higher up in the taxonomy like Template:Taxonomy/Tyrannosauroidea) —Uzume (talk) 18:26, 7 January 2022 (UTC)

(edit conflict) It may also be worth considering just removing extinction dates from the taxobox and only having them in the article text (and disabling taxobox support for dates). There's usually some nuance to extinction dates that isn't handled well by an unreferenced date. Rarely there is a single individual surviving in captivity/cultivation well after the species went extinct in the wild. In most cases, dates might be; IUCN publishes status as EX, an extensive search found no individuals, last confirmed sighting, range of years after last sighting, most recent isotype date of subfossil remains, etc. Plantdrew (talk) 18:40, 7 January 2022 (UTC)

@Plantdrew: So effectively there are multiple different kinds of extinction events. I think any such dates should be referenced. —Uzume (talk) 18:45, 7 January 2022 (UTC)

My understanding is that extinction dates should only be given for recent extinctions when there is some accurate verified date, as used by the IUCN, which means from 1500AD onwards. —  Jts1882 | talk  20:21, 7 January 2022 (UTC)

Exactly. @Uzume: the extinction date information is only shown when the taxon has a conservation status of EX, i.e. it's a relatively recent extinction. So the dates should always be referenced by the reference for the EX status (e.g. the IUCN). Extinction date information and conservation status don't apply to long extinct taxa like Tyrannosaurus for which the temporal range is used.

In practice, there are a few taxoboxes with extinction dates prior to 1500. I think the only such cases are taxa from the last settled large landmasses; Madagascar, New Zealand, Hawaii and the Greater Antilles. There are certainly species from Hawaii and New Zealand that went extinct after 1500 but before European contact. 1500 is an arbitrary date that makes some sense globally, but little sense for New Zealand in particular. It's not at all clear how the IUCN arrived at the date 1620 for (Madagascan) Palaeopropithecus given what they say about it. Plantdrew (talk) 20:56, 7 January 2022 (UTC)

I agree with Plantdrew that the extinction date should be removed from the taxobox; a referenced status of EX is enough there. The details should be put in the text. This can easily be implemented by changing {{Taxobox/species}} so that it doesn't handle |extinct=. Then, later, taxoboxes that have |extinct= with values other than "yes" or "true" can be fixed. This is the approach I favour.

What do others think of this proposal? Peter coxhead (talk) 20:34, 7 January 2022 (UTC)

I'm in favor, obviously. Template:Taxobox#Conservation status need updating no matter what; doesn't mention use of extinct=yes to display the extinction symbol, or not including pre-1500 dates (and suggests only using single years, which may be unreasonably precise (e.g. Palaeopropithecus); and in practice there are taxoboxes that have a range of years (which is actually as precise as possible)). Plantdrew (talk) 21:07, 7 January 2022 (UTC)

@Plantdrew: I revised Template:Taxobox#Conservation status. (A perennial issue is that although Template:Taxobox/doc is primarily for {{Taxobox}}, the documentation for the automated taxobox templates refers to it for explanations of common parameters.) Peter coxhead (talk) 07:19, 8 January 2022 (UTC)

@Peter coxhead: In order to help establish a consensus, I too agree with the removal of the extinction date from taxobox. In the big picture of things I would also like to see WP:TX moved off of English Wikipedia and made multilingual (perhaps at Wikidata, Commons Tabular Data or Wikispecies) but I am sure that is beyond this discussion. —Uzume (talk) 16:45, 8 January 2022 (UTC)

@Uzume: definitely beyond this discussion and agreed to be a bad idea whenever it has been discussed. Peter coxhead (talk) 18:03, 8 January 2022 (UTC)

To clarify {{Taxobox/species}}, I'm in the process of changing the name of its parameter extinct to extinction_date. This will entail changing {{Taxobox/core}} to use {{Taxobox/species}} with the new parameter name. I won't make any more changes unless and until there is a wider discussion, so the change will only affect the internal working of taxoboxes and no article taxoboxes will be affected. Peter coxhead (talk) 18:19, 8 January 2022 (UTC)

Limited data

Why does the taxoboxes have limited data? For example, they do not include mass, life span, the type of diet, lengths, gestation period, and so on. --NGC 54 (talk | contribs) 16:56, 18 January 2022 (UTC)

Because (a) it's a taxobox, i.e. an information box about the taxonomy of the taxon that is the subject of the article (b) taxoboxes are used for everything from viruses to mammals, so there would be few if any items that would be common to all of them. Peter coxhead (talk) 18:07, 18 January 2022 (UTC)

Does the question derive from an [understandable] assumption that an infobox—a compressed, definitive, labelled and portable data set—ought to appear at the top right* of any article space. *below lede on mobile ~ cygnis insignis 18:23, 18 January 2022 (UTC)

Transition to templatestyles

Hi, I saw this template and related templates use a data table for layout, which could confuse screen reader users (MOS:LTAB), and inline style attributes for background-color, requiring coordination across multiple lines of multiple templates. I'm trying for a templatestyles implementation, with an accessible complementary region, where the output looks like <div role="complementary" aria-label="Taxonomy" class="infobox taxobox taxobox-animalia biota"> ... <div class="taxobox-header">, instead of <table class="infobox taxobox biota"> ... <th colspan=2 style="text-align:... background-color:...">. Relevant new pages created at Template:Taxobox/styles.css and Template:Taxobox/palette (forked from Template:Taxobox colour), and edits to Template:Taxobox/core/sandbox (diff and testcases). Not ready to go live, though. Still more wrinkles to iron out (e.g. width on mobile), and maybe some other editors can flag some problems too? Matt Fitzpatrick (talk) 00:28, 25 January 2022 (UTC)

@Matt Fitzpatrick: thanks for bringing this up. this is a bit beyond me, but I imagine the answer is going to get complicated, but I’ll leave that to @Jts1882 and Peter coxhead: who know the most about these templates. --awkwafaba (📥) 03:24, 25 January 2022 (UTC)

@Matt Fitzpatrick: you need to make sure that all the taxobox templates that drive {{Taxobox/core}} work properly; if you're not aware of it, see the list in the box at Wikipedia:Automated taxobox system/intro. You need to pick up the colours to be used from {{Taxobox colour}} and not bypass it as you appear to be doing, since it's used in other places in the automated taxobox system. Peter coxhead (talk) 07:17, 25 January 2022 (UTC)

@Matt Fitzpatrick: for example, I don't understand the edit comment in this edit. {{Taxobox/core}} is driven by all the automated taxobox templates, some (like {{Automatic taxobox}}) implemented in Lua, not just {{Taxobox}}. Look at {{Speciesbox}}, for example: it passes |colour= to {{Taxobox/core}}. I strongly advise you not to change any of the parameters to {{Taxobox/core}}, since this will require all the user-facing taxobox templates to be changed. Peter coxhead (talk) 07:40, 25 January 2022 (UTC)

It looks like |palette= contains a CSS class setting the colour for the headings, one for each group set by {{taxobox/palette}} as defined in {{taxobox colour}}. That class is then added to the table declaration to set the colour for all section headings. The parameter |palette= is passed by {{taxobox}} instead of |colour=, which is no longer required to set the background colour style for each heading (now handled by the class). Other taxoboxes that pass |colour= will still set the colour with a style element on each heading. This appears to work in principle, but as you say below will need to be checked on all the taxobox entry templates. —  Jts1882 | talk  09:27, 25 January 2022 (UTC)

@Jts1882 and Matt Fitzpatrick: if I have understood correctly, it's a very bad idea to have {{Taxobox}} use |palette= to set the colour, while all the other (automated) taxobox templates still use |colour=. The logical approach is to make no changes to {{Taxobox}} or any of the 10 or so other taxobox templates, leaving the parameter as colour, and only change the way that {{Taxobox/core}} implements the required colour. Having different taxoboxes using different methods will be a maintenance headache. Peter coxhead (talk) 09:53, 25 January 2022 (UTC)

@Matt Fitzpatrick: and, of course, you need to test any changes to {{Taxobox/core}} in sandbox versions of every one of the taxobox templates. Changing {{Taxobox/core}} is very, very tricky to get right in my experience. Peter coxhead (talk) 07:46, 25 January 2022 (UTC)

A few other issues that need to be considered, along with a few questions:

• The newline introduced with parser bug T18700 is currently removed by the empty <nowiki/> tag. If I remember correctly, placing templatestyles immediately before the table does the same thing, but this needs checking.
• Why change the header cells to ordinary row cells and add the taxobox-heading class? Why not just apply the colour classes to header rows.
• Is the wrapping div element around the taxobox table necessary? Why not apply the attributes role="complementary" and aria-label="Taxonomy" to the table, as done for role="presentation"? This might also interplay with T18700.
• The minimum width is no longer set by min-width:15em; and is replaced by width: 220px;. Does this change the behaviour of the taxobox?
• Why change the small size to 88% instead of 85% (which is also the size set by the {{small}} template)?

—  Jts1882 | talk  10:14, 25 January 2022 (UTC)

Wikilink from "Trinomial name"

The code of the template uses an explicit value of |regnum= to choose a wikilink for the subheading "Trinomial name" when this appears. However, when an automated taxobox is used, e.g. {{Subspeciesbox}} or {{Infraspeciesbox}}, no such parameter is passed because the classification hierarchy is created by the automated taxobox system. The default when there was no value of |regnum= was previously to wikilink to Trinomen, which was changed on 26 May 2022 to redirect to Trinomial nomenclature#In zoology. This was wrong when the organism wasn't an animal, so I've changed it to just Trinomial nomenclature which works for both animals and plants. Revert if this has any side-effects I haven't foreseen. Peter coxhead (talk) 06:08, 29 May 2022 (UTC)

Template-protected edit request on 8 June 2022 - Spacing

Within the line | ex = [[file:Status iucn2.3 EX.svg|frameless|link=|alt=]]<br />[[Extinction|Extinct]] {{#switch:{{{extinction_date|}}}|y|yes|true|=|&nbsp;({{{extinction_date}}})}} {{#ifeq: {{NAMESPACEE}} | {{ns: 0}} | [[Category:IUCN Red List extinct species]] | }}, could the space between the switch statement and the [[Extinction|Extinct]] bit be removed? That space essentially nullifies the nbsp in the switch statement result and it causes a double space to occur, which looks confusing (As seen in White swamphen). Thanks. Aidan9382 _(talk) 06:27, 8 June 2022 (UTC)

 Done I looked three times, and I'm pretty sure this can't break anything, but if it has, another template editor is welcome to revert this change. – Jonesey95 (talk) 10:59, 8 June 2022 (UTC)

Template-protected edit request on 17 June 2022

Change

| type_strain = {{{type_strain|{{{type strain|}}}}}}

to

| type_strain = {{{type_strain|{{{type strain|}}}}}}
| type_strain_ref = {{{type_strain_ref|{{{type_strain_ref|}}}}}}

To name a new bacterial species, the type strain must be deposited in at least two culture collections on different continents. Each culture collection gives the type strain a unique designation. So a type strain usually has multiple strain names. For example, the type strain of E. coli is called ATCC 11775 by the American Type Culture Collection (ATCC), DSM 30083 by the German Collection of Microorganisms and Cell Cultures (DSMZ), JCM 1649 by the Japan Collection of Microorganisms (JCM), and LMG 2092 by the Belgian Coordinated Collections of Microorganisms (BCCM). Lists of type strains can be found at resources like LPSN and BacDive. Adding a type_strain_ref field to the taxobox would simplify adding references. This change should also be made to the {{Speciesbox}} and {{Subspeciesbox}} templates.

Also, if possible, please change the type_strain field so that it is NOT centered. This will make it possible to use bulleted lists for the type strains. Ninjatacoshell (talk) 01:55, 17 June 2022 (UTC)

It's actually at Template:Taxobox/core that the change needs to be made. (It's used by all the taxobox templates.) Adding the ref parameter is straightforward. The issue with changing the centering is the effect when there's a single entry. You could always just put "See text" with an appropriate section wikilink if there's a long list of type strains. Is the list at Vibrio alginolyticus useful in the taxobox, for example?

That's a little funny since I'm the one that created the Vibrio alginolyticus taxobox. Using <br> is an okay work-around, but I would like to see what it would look like as a bulleted list. Could we sandbox it, first? When there is just one entry for the type strain, a single bullet point would still suffice. When there are many entries for the type strain, I would probably use {{hidden}} (see, for example, the list of synonyms at Astragalus) since the casual reader isn't going to be interested in a long string of strain designations in the main text. Ninjatacoshell (talk) 03:21, 18 June 2022 (UTC)

I note that we use "Synonyms" as the row label in a taxobox even if there is only one; so should it be "Type strains"? Peter coxhead (talk) 06:38, 17 June 2022 (UTC)

It should stay as "Type strain". In the literature "type strain" is used even when multiple designations are listed. They are all the same strain. Ninjatacoshell (talk) 03:21, 18 June 2022 (UTC)

Ok, understood. I don't have time to make the change to add |type_strain_ref= right now (changing Template:Taxobox/core needs care as it has such a high use, and the templates that drive it that could use this parameter would also need changing). Maybe Jts1882 might look at it sooner. Peter coxhead (talk) 06:30, 19 June 2022 (UTC)

Taxobox examples

Biota infobox Scientific classification Domain: Bacteria Phylum: Pseudomonadota Class: Gammaproteobacteria Order: Vibrionales Family: Vibrionaceae Genus: Vibrio Species: V. alginolyticus Binomial name Vibrio alginolyticus (Miyamoto et al. 1961) Sakazaki 1968 Type strain ATCC 17749 CAIM 516 CCUG 4989 CCUG 13445 CCUG 16315 CIP 103336 CIP 75.3 DSM 2171 LMG 4409 NBRC 15630 NCCB 71013 NCCB 77003 NCTC 12160 Synonyms Oceanomonas alginolytica Miyamoto et al. 1961 Beneckea alginolytica (Miyamoto et al. 1961) Baumann et al. 1971 Pseudomonas creosotensis O'Neill et al. 1961 Taxobox/sandbox Scientific classification Domain: Bacteria Phylum: Pseudomonadota Class: Gammaproteobacteria Order: Vibrionales Family: Vibrionaceae Genus: Vibrio Species: V. alginolyticus Binomial name Vibrio alginolyticus (Miyamoto et al. 1961) Sakazaki 1968 Type strain ATCC 17749 CAIM 516 CCUG 4989 CCUG 13445 CCUG 16315 CIP 103336 CIP 75.3 DSM 2171 LMG 4409 NBRC 15630 NCCB 71013 NCCB 77003 NCTC 12160 Synonyms Oceanomonas alginolytica Miyamoto et al. 1961 Beneckea alginolytica (Miyamoto et al. 1961) Baumann et al. 1971 Pseudomonas creosotensis O'Neill et al. 1961 Taxobox Scientific classification Domain: Bacteria Phylum: Pseudomonadota Class: Gammaproteobacteria Order: Vibrionales Family: Vibrionaceae Genus: Vibrio Species: V. alginolyticus Binomial name Vibrio alginolyticus (Miyamoto et al. 1961) Sakazaki 1968 Type strain ATCC 17749 CAIM 516 CCUG 4989 CCUG 13445 CCUG 16315 CIP 103336 CIP 75.3 DSM 2171 LMG 4409 NBRC 15630 NCCB 71013 NCCB 77003 NCTC 12160 Synonyms Oceanomonas alginolytica Miyamoto et al. 1961 Beneckea alginolytica (Miyamoto et al. 1961) Baumann et al. 1971 Pseudomonas creosotensis O'Neill et al. 1961

The prototype module allows adding references to section header, as in the example to the right. Is this what is wanted? I've used a div element to left align the type strains.

I've added a simple test example to test {{taxobox/sandbox}}. It's isn't adding the reference yet. —  Jts1882 | talk  13:41, 19 June 2022 (UTC)

I've added the change to {{taxobox/core/sandbox}} with this edit. Is this the desired taxobox? Please feel free to edit the example. —  Jts1882 | talk  13:51, 19 June 2022 (UTC)

References

Yes. That's exactly what I wanted for the type_strain_ref parameter. As for the other request, now that I can see the list of type strain designations with or without bullet points, I find that I prefer to keep it the way it is (centered). So I withdraw the request for changing the type_strain parameters. Ninjatacoshell (talk) 03:35, 20 June 2022 (UTC)

@Jts1882: Just so we're clear, please proceed to add the type_strain_ref parameter. The way you implemented it in the sandbox looks great. Ninjatacoshell (talk) 07:25, 22 June 2022 (UTC)

Update made to {{taxobox/core}} to add strain reference to header, with edits to {{taxobox}}, {{speciesbox}}, {{subspeciesbox}} and Module:Automated taxobox to pass the parameter. —  Jts1882 | talk  12:59, 23 June 2022 (UTC)

@Jts1882: Looks great! However, during preview there is a warning: Preview warning: unknown parameter "type_strain_ref". Despite the warning, the reference shows up correctly. See, for example, this automatic taxobox I recently created using the type_strain_ref parameter: Lawsonella clevelandensis. Ninjatacoshell (talk) 17:53, 23 June 2022 (UTC)

@Ninjatacoshell and Jts1882: the warning is because the new parameter needs to be added to the parameter check list in {{Speciesbox}}. Now done, and the warning should not appear. Peter coxhead (talk) 06:09, 24 June 2022 (UTC)

Great! Thanks for your help! Ninjatacoshell (talk) 20:15, 24 June 2022 (UTC)

Type strain wikilink

@Ninjatacoshell: at present Type strain redirects to Type (biology), but this says nothing at all about type strains, or the International Code of Nomenclature of Prokaryotes which replaces the Bacteriological Code, so the link in the taxobox is not really helpful to readers. Since you seem to know about this subject, could you add something to International Code of Nomenclature of Prokaryotes? Then the redirect can be revised. Peter coxhead (talk) 07:59, 20 June 2022 (UTC)

@Peter coxhead: Done. Ninjatacoshell (talk) 08:08, 21 June 2022 (UTC)

@Ninjatacoshell: great, much better. Thanks! Peter coxhead (talk) 08:51, 21 June 2022 (UTC)

Spaced parameters

@Peter coxhead and Jts1882:, I've replaced all instances of spaced parameters (e.g. |image caption=) with underscored parameters (e.g. |image_caption=. I think support for spaced parameters should now be disabled and Module:Check for unknown parameters be added to Taxobox so any future instances of spaced parameters show up in an error tracking category. I'm posting here because some articles with Taxobox still had spaced parameters until today. Articles with the automatic taxobox templates haven't really had any instances of spaced parameters for several years now (although there is a trickle of a couple new instances a month), but as far as I'm aware, spaced parameters are still supported in automatic taxoboxes and don't show up in an error tracking category. Plantdrew (talk) 01:01, 8 September 2022 (UTC)

@Plantdrew and Jts1882: I agree with getting rid of spaced parameters. Peter coxhead (talk) 06:13, 11 September 2022 (UTC)

I've always thought they were weird, so happy to see them go. —  Jts1882 | talk  06:30, 11 September 2022 (UTC)

Species image tracking

I note that very few species have images in their taxoboxes.

We've had great success with adding geographical coordinates to articles, helped by an extensive system of tracking categories for articles without coordinate and a small army of dedicated geocoders, to the point where we have reached a tipping point to where contributors of new articles about geolocatable entities now add coordinates by default.

There is an opportunity to something very similar here for species images, using Template:Taxobox/core. I propose to modify it to detect if images are completely missing (that is to say none of image, image2, image_upright, image2_upright), and to add a category "$ORDER taxobox without images", where $ORDER is taken from the taxonomic hierarchy.

Obviously the main problem is the lack of suitably licensed and labelled images, but if we had these tracking categories, they might be a useful motivator to people to add images where available, or (even better) for curators of suitable images to release them under a license that would allow them to be mass-contributed to the encylopedia (and Commons) using bot edits. — The Anome (talk) 12:34, 26 September 2022 (UTC)

...and speaking of which, I've just noticed that the National History Museum are currently digitising their specimen collection under CC-BY-4.0! See here for just one example. And it looks like other organizations are doing the same, and some have been uploaded to Commons already, see here and also here. — The Anome (talk) 12:52, 26 September 2022 (UTC)

@The Anome:, I'm not sure if it is possible to extract $ORDER via taxobox core. WikiProject banners have |needs image=, which is used to track articles missing images (but it's not necessarily set correctly; many articles that don't have images don't have a |needs image=, and there are some articles where an image has been added, but the WikiProject banner on the talk page hasn't been updated (there is a tool to check for articles that have images but are flagged as neeeding images). TemplateData can also be used to find articles missing images; if a parameter is flagged as required in TemplateData, the TemplateData error report can show all articles that don't have a value for that parameter).

What is really needed is a tool/report that matches up articles lacking images with categories on Commons that contain images. However, commons images of species may be misidentified. I'm reluctant to add images from commons for organisms I'm not familiar with. Images of specimens from natural history collections should be correctly identified. — Preceding unsigned comment added by Plantdrew (talk • contribs)

Something like using the the Commons batch-uploader to upload images from well-curated authoritative sources like natural history museums, and linking them to the relevant items on Wikidata seems certainly seems like a good idea to me. A relatively small VPS should be capable of doing this day and night, indefinitely. — The Anome (talk) 20:01, 26 September 2022 (UTC)

It would be possible to have a Lua function to get the Order (or something else if no order) from the taxonomy templates (albeit with a lot of overhead) and set a category if the image parameters are absent. Order will produce a lot of categories. It might be suitable for plants, vertebrates and arthropods, but a higher taxon might be needed for other group. It could also flag if an image was on Wikidata or if a commons page was linked on Wikidata, which might be used to set different categories. —  Jts1882 | talk  14:42, 27 September 2022 (UTC)

@The Anome: there's a Lua function in Module:Autotaxobox which will find the order for a genus, if it exists in the taxonomic hierarchy. Thus

• {{#invoke:Autotaxobox|find |Felis |ordo}} → Carnivora
• {{#invoke:Autotaxobox|find |Bellis |ordo}} → Asterales

However, I'm doubtful of the value of categories for taxa without images by order. Thus for spiders, PetScan found 4,462 stub articles with no images. Some of the higher taxa may possibly have lower ranked members with images in Commons, but most of the species will not. For groups like spiders, there just aren't useful accurately identified copyright free images available. Peter coxhead (talk) 06:02, 1 October 2022 (UTC)

@Peter coxhead: I think you might be right, and crowdsourcing these images would probably result in lots of not-quite-right images being added, which would defeat the whole endeavour by filling the entries up with junk; unlike geocoordinates, there's no way for non-experts to verify these images. Using bots to do the work based on properly curated image datasets from museums seems like the way to go.

Perhaps there should just be be a single hidden tracking category for "Taxoboxes without images" to help bot operators find these articles (perhaps with an auxliary category "Taxoboxes without images with images on Commons"), and leave it at that? Or is even that too much of an invitation for misguided enthusiasts? It would be a pity to be forced to resort to using title matching and article source scraping to find these. — The Anome (talk) 09:09, 2 October 2022 (UTC)

@The Anome: if the category isn't broken down somehow, it will be far too large to be useful. A search for hastemplate:Taxobox/core -insource:/\| *image *\=/ (i.e. has a taxobox but appears not to have an image parameter) gives about 111,000 results. I think the existing categories by Wikiproject, like Category:Wikipedia requested images of spiders, are sufficient. Peter coxhead (talk) 18:48, 2 October 2022 (UTC)

@Peter coxhead: I was thinking in terms of something like Category:All articles needing coordinates; at ~100k entries, its useless for people, but it's very useful for bots which automatically track and process articles, and it also enables the use of tools like Wikipedia:PetScan for finer-grained queries. — The Anome (talk) 22:26, 2 October 2022 (UTC)

@The Anome: Category:Wikipedia requested images of biota (and its many subcategories) works in PetScan. Peter coxhead (talk) 11:29, 4 October 2022 (UTC)

@Peter coxhead: I'm convinced; the existing category tree is the way top go. You quoted a search string "hastemplate:Taxobox/core -insource:/\| *image *\=/" above; can you tell me which tool you used to perform that search? — The Anome (talk) 09:34, 6 October 2022 (UTC)

@The Anome:, that's a Wikipedia search. You can copy and paste it into the "Search Wikipedia" box on the top of any page. But it's not a very useful search for anything other than an estimate of the sheer number of articles without an image. There are a lot of articles that have |image= with no value specified. That search only turn up articles that don't contain |image= at all. Template Data for Speciesbox shows ~260,000 articles, of which ~105,000 have an image specified. That means are 155,000 articles with Speciesbox that don't have an image. Modifying Peter's search with Speciesbox instead of Taxobox/core gives ~60,000 articles; that means there ~95,000 articles with Speciesbox and |image= with no value specified. It should be possible to get a list of the ~105,000 Speciesbox articles that don't have an image, but I don't know an efficient way to do it (if |image= is "required" rather than "suggested" in Template Data, the Template Data report will show articles that are missing the required parameter, but only in batches of 100 results per page). Plantdrew (talk) 16:06, 6 October 2022 (UTC)

Yes, it's just a way of demonstrating the very large number of articles without an image. (The regular expression could be modified to include |image= with only whitespace up to the end of the line, i.e. empty values, but the counts would only show a very large number again.) Peter coxhead (talk) 16:15, 6 October 2022 (UTC)

Edit request 24 November 2022

Not sure if this is the right place to ask, but NatureServe conservation templates, such as this one here, should read "Unranked, not "Unrankable". NatureServe has an "unranked" status, they do not have an "unrankable", because that implies ranking to be impossible, which is absurd. - Sumanuil. _{(talk to me)} 04:30, 24 November 2022 (UTC)

That article version shows a status of "GU", which corresponds to "Unrankable" on this page. A status of "GNR" appears to mean "Unranked". If you still think it is absurd, I recommend contacting the folks at NatureServe. – Jonesey95 (talk) 05:57, 24 November 2022 (UTC)

Yes, when the status cannot be determined "due to lack of information or due to substantially conflicting information about status or trends", NS then considers the status to be "unrankable". So this is not a WP convention. P.I. Ellsworth , ed. ^put'r there 06:07, 24 November 2022 (UTC)

Ok, but it is kind of strange. And the example I gave is listed as "Unranked", but when I tried to change it to GNR, I got an "Invalid status" error. - Sumanuil. _{(talk to me)} 08:20, 24 November 2022 (UTC)

GNR is correct according to this page, so yes that's strange. P.I. Ellsworth , ed. ^put'r there 08:38, 24 November 2022 (UTC)

The GNR status was not implemented in the template for some reason (perhaps it is newer), but it is now. I haven't changed the taxobox. Technically it should have GNR for the species article, but that provides no useful information, while T3 status for the two subspecies tells us something important. —  Jts1882 | talk  09:01, 24 November 2022 (UTC)

Taxoboxes for forma specialis taxa

Please see WT:Automated taxobox system#Forma specialis taxa for a question about taxoboxes in articles about forma specialis (f.sp.) fungus taxa. Peter coxhead (talk) 17:30, 24 May 2023 (UTC)

Categories for ESA

Hi, changing the U.S. Endangered Species Act status parameter does not automatically change the article's category: Category:ESA endangered species, Category:ESA threatened species, etc. (not sure if there are categories for delisted or declared extinct). Could these please be added? 108.18.207.147 (talk) 20:17, 29 April 2023 (UTC)

I've added those categories through the taxobox. Those categories are relatively new (2018) and have never been handled by the taxobox. There aren't equivalent categories for Delisted and Extinct, so I haven't added those. As pages like Pleurobema marshalli have the category set manually (or did until I removed it), there will be duplication of the category setting, but I don't think this causes any issues. Perhaps a bot will pick it up. —  Jts1882 | talk  07:18, 30 April 2023 (UTC)

Follow up comments. These categories should be set on pages that can be picked up by the following searches:

• hastemplate:speciesbox insource:/status2*_system *= *ESA/ insource:/status2* *= *L*E/ 198 results
• hastemplate:speciesbox insource:/status2*_system *= *ESA/ insource:/status2* *= *L*T/ 53 results

An issue that arises here is when ESA statuses should be set in the taxoboxes. Should it only be for endemic US species? What is the point of the "DELISTED" status for the Red kangaroo? I think such entries should be removed from the taxobox. —  Jts1882 | talk  07:43, 30 April 2023 (UTC)

Yes, "DELISTED" should definitely be removed. In general, proliferation of conservation statuses should be avoided. Peter coxhead (talk) 17:31, 24 May 2023 (UTC)

IUCN Redlist - now also Green Status

Pygmy hog
Conservation status
Endangered (IUCN 3.1)
Critically Depleted (IUCN Green)
Scientific classification
Domain:	Eukaryota
Kingdom:	Animalia
Phylum:	Chordata
Class:	Mammalia
Order:	Artiodactyla
Family:	Suidae
Genus:	Porcula Hodgson, 1847
Species:	P. salvania
Binomial name
Porcula salvania Hodgson, 1847

The IUCN now includes a Green Status on some of their listings. Maybe only the Endangered ones? I don't know. Anyway, I saw it at IUCN's pygmy hog listing. We may want to incorporate this. - UtherSRG (talk) 11:31, 14 June 2023 (UTC)

That's new to me. As far as I can tell it's about conservation efforts, so presumably they only do it on endangered/threatened ones. It might be a while before they get a Fully Recovered status.

It's possible to include it using the existing system by adding |status2_system=IUCN Green and |status2=Critically Depleted (see taxobox to right). If someone created a set of graphics it could be handled as a recognised system. —  Jts1882 | talk  12:33, 14 June 2023 (UTC)

References

Rank of infrakingdom

Is there a way the rank "infraregnum" could be added? It is necessary to showcase some disputed taxa like the Apusozoa (infrakingdom Diacentrida, subkingdom Sarcomastigota, kingdom Protozoa). Thanks in advance. —Snoteleks 🦠 23:14, 28 August 2023 (UTC)

Taxobox/Archive 31
Scientific classification
Domain:	Eukaryota
Clade:	Diaphoretickes
Subkingdom:	SAR
Infrakingdom:	Halvaria

@Snoteleks: It is already available in {{automatic taxobox}} (e.g. see Halvaria and right). For consistency, it probably should be added to {{taxobox}} as well, although we try and avoid making changes there unless absolutely necessary. Do you need it specifically with a manual taxobox? I think it preferable to make any new taxoboxes with {{automatic taxobox}} so let me know if there is something you need and don't know how to implement. —  Jts1882 | talk  17:16, 30 August 2023 (UTC)

Apusozoa uses {{paraphyletic group}}, which is a variant of the manual taxobox. - UtherSRG (talk) 17:19, 30 August 2023 (UTC)

@Jts1882 Yes, like Uther said, I need it specifically with a manual taxobox for a taxon that is abandoned, and therefore I didn't want to implement the taxon into the automatic taxobox system. —Snoteleks 🦠 17:24, 30 August 2023 (UTC)

{{paraphyletic group}} uses the prototype taxobox module (see Module:Biota infobox), which can take manual taxonomy parameters or use the automated system (by setting |auto=). I'm surprised that auto wasn't the default as it probably should be. I've updated the module to allow infraregnum with the manual taxonomy parameters (although this won't work with the {{taxobox}} template). —  Jts1882 | talk  17:34, 30 August 2023 (UTC)

Apusozoa (obsolete paraphyletic group)
Apusomonas sp.
Scientific classification
Domain:	Eukaryota
Clade:	Obazoa
Phylum:	Apusozoa Cavalier-Smith 1997 emend. 2013
Groups included
Apusomonadida Breviatea
Cladistically included but traditionally excluded taxa
Opisthokonta

@Snoteleks and UtherSRG:It turns out that Apusozoa is the only example of {{paraphyletic group}} using the manual taxobox parameters. All the others have |auto=yes or |auto=virus. I think {{paraphyletic group}} should be changed to use |auto=yes by default and require |auto=no to use the manual taxon parameters if absolutely necessary. I don't think it is necessary and think it would be better to use an automated taxobox. This makes it easier to review the taxonomies used on Wikipedia.

I'd also question the use of infrakingdom Diacentrida and subkingdom Sarcomastigota for Apusozoa. Neither have articles and it's a different classification to that used in the phylogenetic tree in the article. It makes more sense to place Apusoozoa within Obazoa than in the two paraphyletic Cavalier-Smith taxa, although that could be mentioned as an alternative in the text. —  Jts1882 | talk  12:21, 31 August 2023 (UTC)

Oh, I wasn't aware para could use auto. Cool beans. As for the classification, I have no skin in the game; I was only helping to explain the OP's request. - UtherSRG (talk) 12:27, 31 August 2023 (UTC)

@Jts1882 I understand that, but at the same time, Apusozoa is an abandoned taxon whose only usage is within Cavalier-Smith's hierarchical classification, not the current cladistic classification of eukaryotes. If we apply this rule that every abandoned taxon should be added into the automated taxobox system, we would end up with a lot of outdated para- or polyphyletic taxa whose only parent is Eukaryota or something nearly as big, because its parent taxa are also abandoned. Which doesn't make sense to me. I don't think the disputed taxa should intermingle with the automated taxoboxes.

Would the creation of articles for Diacentrida and Sarcomastigota be a good solution of this? —Snoteleks 🦠 13:39, 31 August 2023 (UTC)

@Snoteleks:, why not put it in Category:Obsolete eukaryote taxa, and remove the taxobox? This is what's done for some other Cavalier-Smith taxa, e.g. Archezoa and Cabozoa.Plantdrew (talk) 16:27, 31 August 2023 (UTC)

If it is deserving of an article, then I think it should have a taxobox. The taxobox has more information than just the taxonomy and the taxonomy is still relevent if the taxon is no longer used. The question is which deserve articles. I've seen enough independent coverage of Apusozoa to warrant an article, but Diacentrida and Sarcomastigota are little used by others. That is why I think a taxobox reflecting the taxonomy shown in the phylogenetic tree would be better. Just adding |auto=yes to the existing taxobox gives a suitable taxobox. I've added it here (see right) with a few tweaks. —  Jts1882 | talk  16:41, 31 August 2023 (UTC)

Okay, I guess that's the more useful outcome. I'll do that instead.—Snoteleks (Talk) 17:24, 31 August 2023 (UTC)

I just noticed, what about Heliozoa? The (non-automatic) taxobox clearly shows Actinopoda and Sarcodina as parent taxa even though those are also obsolete. Where should we draw the line? I think maybe polyphyletic ones such as Heliozoa could retain a non-automatic taxobox, while paraphyletic ones that still "fit" in the Tree of Life (such as Apusozoa, Eolouka, crustaceans, etc.) can be transferred into the automatic system. Does that sound good? —Snoteleks (Talk) 17:29, 31 August 2023 (UTC)

This discussion has expanded beyond the technical taxobox issue and would be better continued at the WP:PROTISTA project page. I've copied the last part of this discussion into a new topic on Obsolete and paraphyletic taxa and added a reply there. —  Jts1882 | talk  09:19, 2 September 2023 (UTC)

Connected taxoboxes

In the article stub about Cytherellidae the taxobox says it belongs to the order Platycopida, which is correct. And the taxobox in the article stub about Punciidae says that too belongs to the order Platycopida, which is wrong. It belongs to the order Palaeocopida. But when I change the info in the taxobox to correct it, the taxobox describing Cytherellidae changes too, from Platycopida to Palaeocopida. And vice versa. The two taxoboxes are connected, so when you edit it in one of the mentioned articles, the same thing happens in the other. Is there a way to separate them? Hipporoo (talk) 00:28, 30 October 2023 (UTC)

@Hipporoo: Fixed. I'm not sure what you tried to changed or where, but you needed to change the taxonomy template for Punciidae. I changed the parent taxon in Template:Taxonomy/Punciidae to Puncioidea, which was already set up correctly as part of Palaeocopida. For more on the use of the automated taxobox system see WP:Automated taxobox system. —  Jts1882 | talk  07:15, 30 October 2023 (UTC)

Deprecated vs. discouraged, and should all empty discouraged parameters be removed?

There are many parameters listed as "deprecated" under Template:Taxobox#Template parameters, but they appear in the template code and in the documentation, albeit with heavily caveated use cases. They are:

• |image_width=
• |image_caption_align=
• |range_map_width=
• |alliance=
• |variety=
• |color_as=

plus their numerical counterparts, |image2_width=, etc.

It would be more accurate to change these to "discouraged", since the only parameter that's actually deprecated, from what I can tell, is |image_size=, since it has been removed from the immediate (i.e. non-nested) template code and from the documentation.

Related question: should all empty discouraged parameters be removed? I've been removing empty |image_width= (only) since at least 2020.   ~ Tom.Reding (talk ⋅dgaf)  14:36, 1 December 2023 (UTC)

@Tom.Reding: "deprecated" is one of three qualifiers for parameters allowed by TemplateData. The others are "required" and "suggested". I've long thought there should be another qualifier for "should not normally be used, but necessary in exceptional cases" (I'm not sure how to name it in a concise way). |color_as= is an instance of "should not normally be used, but necessary in exceptional cases". I suppose |image_caption_align= may be as well, but I have never come across it being used in my time on Wikipedia.

Variety is correctly deprecated; |varietas= should be used instead of |variety= Most of the parameter names for ranks are Latin not English (regnum/classis/ordo/familia, not kingdom/class/order/family with phylum/genus/species being the same in Latin and English).

|alliance= is also English, but isn't used anywhere. I'm pretty sure I set it to "deprecated" as work-around when trying to find articles that used it and update them to recent classifications that didn't use that rank (the TemplateData Error Report will show articles using a particular parameter/value when a template has few transclusions. When a template has many transclusions (over 50k, I think) the option to see which articles use a particular parameter is disabled unless that parameter is marked as deprecated).

The "_width" parameters are correctly deprecated. "_upright" parameters should be used instead, although I would say the "_upright" parameters also fall into "should not normally be used, but necessary in exceptional cases" (the only reason to over-ride the default image display size is when an image has an extreme aspect ratio (tall/narrow or short/wide) that makes it display very large/small).

Any of the parameters you've listed should be removed when empty. Almost all the "_width" parameters should be removed even when non-empty (but the image should be checked to see if it does have an extreme aspect ratio that would merit using an "_upright" parameter instead). Plantdrew (talk) 21:05, 1 December 2023 (UTC)

@Plantdrew: I didn't realize that about TemplateData. Looking through the archives, I found a relevant discussion 5 years ago at #Add support for more sophisticated "required" options, which predicts the need for a "deprecated unless" parameter (oh, you're in that discussion too!), but to submit a bug request on Phabricator. I thought there'd be a much simpler solution to this, so if/when I get around to it, I'll look through phab tickets to see if something like this actually made it there, and go from there.

I think I'll stick with removing these empty parameters for now, and look for the special cases you mention after.   ~ Tom.Reding (talk ⋅dgaf)  22:11, 1 December 2023 (UTC)

@Tom.Reding:, |color= meets your stricter definition of deprecated; it's been removed from the template code, and I just removed it from the documentation. It should definitely be removed when empty. It could be removed when non-empty, as it does not do anything. I have been slowly working through the articles with "color = lightgrey" (the only value specified now) and converting them to automatic taxoboxes. I wouldn't mind at all if you got rid of all non-empty instance |color= now, but it is something I intend to eventually achieve myself if nobody else does it. "image_width=220px" is another bugbear of mine (220 is already the default), that I'm inclined to address with automatic taxoboxes, but wouldn't mind of you went ahead and got rid of it while leaving manual taxoboxes in place. Plantdrew (talk) 02:40, 2 December 2023 (UTC)

In my long template-editor experience, it is best to remove from the documentation entirely any parameters that should no longer be used at all. The fact that they still might work, until all instances of the parameter in use have been removed/replaced, is immaterial. That they still function (at least for now) will be apparent in the source code, but if they are included in the documentation, then people will use them anew, no matter what the documentation says.  — SMcCandlish ☏ ¢ 😼  07:29, 2 December 2023 (UTC)

I agree about parameters that should not be used at all. However, the limited classification available in TemplateData does cause some problems. There are some parameters, like |color_as=, that are needed only in exceptional cases, so are "deprecated", but need to be supported indefinitely.

The image_width parameters are a different matter. I would like to remove them altogether. However, right now this tool reports 3,136 uses of |image_width= (plus some for other image width parameters), which ideally would be checked first. On the other hand, these parameters don't exist in the automated taxobox templates, like {{Speciesbox}} and {{Automatic taxobox}}, so perhaps just removing them from the manual taxobox template would be ok. Peter coxhead (talk) 16:52, 2 December 2023 (UTC)

Right. I meant just for the ones that are "dead" parameters to remove them from the docs and replace or remove them, as needed, from "the wild". For stuff with occasional use, it would need to remain in the docs, just really clearly documented as to what unusual cases to use them for.  — SMcCandlish ☏ ¢ 😼  10:33, 3 December 2023 (UTC)

I'd be fine with removing support for |image_width= from the code. None of the instances of 100px actually have an image. The remaining values range from 200px to 250px which isn't really a big enough difference from the default 220px to "fix" images with extreme aspect ratios. 234px/235px is used in fungus articles with {{Mycomorphbox}} to make the taxobox display at the same width as the mycomorphbox. If different widths in taxobox and mycomorphbox is even a problem in the first place, a better solution for that would be to make mycomorphboxes display at the same width as a taxobox with a 220px image. Plantdrew (talk) 16:36, 3 December 2023 (UTC)

It would be best to have a bot remove all the instances of |image_width= first, to avoid all the pages showing up in the taxobox error-tracking categories. Peter coxhead (talk) 14:05, 5 December 2023 (UTC)

COSEWIC DD

@Jts1882, Spacepotato, and Pengo: COSEWIC's website says DD is a valid status. We should update our graphics and taxobox to handle it. Please? :) Ijust fixed Arctic wolf to correctly list COSEWIC (when it was listing a full link) and the DD turned into "invalid". - UtherSRG (talk) 17:17, 23 January 2024 (UTC)

I've added support for DD to the taxobox, but left it without an image. This would have to be created especially and is more than just adding a colour to the blank image template. —  Jts1882 | talk  17:38, 23 January 2024 (UTC)

Understood, and thanks! - UtherSRG (talk) 18:01, 23 January 2024 (UTC)

I'd recommend using a blank COSEWIC with "Data Deficient" below:

Data Deficient

which would match Wikipedia's IUCN DD graphic, e.g. see Allen's spotted bat

If you're wondering why it's like that for IUCN's, I deliberately left out "DD" and "NE" from the image. I'm no graphic designer, but when I made it I wanted to keep it simple and easy to glance, so I chose not to include a separate circle for IUCN's "DD" status because it would stop the circles being in order of threat status, and would make the graphic more confusing (it would be like replacing a fuel gauge with a bunch of indicator lights). Having no filled circle communicates "We don't know", and having no graphic at all communicates "Not evaluated". I should mention that when IUCN made their own graphic they did include NE and DD though (and put Extinct on the right side, making it feel like every species is in an inevitable march towards extinction). —Pengo 23:52, 23 January 2024 (UTC)

I'd have a go at fixing it but I don't want to mess up 75,000 articles today, and I have no idea how this template works any more. I'm in awe that it continues to exist. —Pengo 00:05, 24 January 2024 (UTC)

I've followed your suggestion. The template where it is set is {{taxobox/species}}, not one of the most intuitively named templates. —  Jts1882 | talk  07:02, 24 January 2024 (UTC)

Y'all are the best! Much thanks! - UtherSRG (talk) 12:02, 24 January 2024 (UTC)

TemplateStyles tag generates empty paragraph

@Jdlrobson: Blue petrel has an empty paragraph containing a style tag at the top because of this edit adding a TemplateStyles tag to {{taxobox/core}} on an empty line before the table. One way to prevent the creation of a paragraph would be to put the style tag after the |} like this. — Eru·tuon 14:15, 18 April 2024 (UTC)