Wikipedia talk:Automated taxobox system

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by GTBacchus (talk | contribs) at 17:37, 29 May 2020 (→‎Not sure where to request fix: re). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

WikiProject iconTree of Life Project‑class
WikiProject iconThis page is within the scope of WikiProject Tree of Life, a collaborative effort to improve the coverage of taxonomy and the phylogenetic tree of life on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
ProjectThis page does not require a rating on Wikipedia's content assessment scale.


This talk page can be used to discuss issues with the automated taxobox system that are common to the entire system, not just one of its templates. Discussions of this nature prior to 2017 can be found at Template talk:Automatic taxobox

Those familiar with the system prior to mid-2016 are advised to read Notes for "old hands".

Collapse functionality?

I noticed on Sarcocystis that the subdivision field is really huge. It covers about half of the page. Can't we implement an optional 'collapsed' functionality to the 'Species' part? With a show/hide button? Cheers, Manifestation (talk) 15:24, 27 March 2020 (UTC)[reply]

MOS:DONTHIDE. – Jonesey95 (talk) 15:31, 27 March 2020 (UTC)[reply]
Manifestation, you can repeat the content in the text and say "see text" in the speciesbox. If the content is repeated in the text, you could keep it in the speciesbox with Template:Collapsed infobox section begin. Or you could even create List of Sarcocystis species Enwebb (talk) 15:50, 27 March 2020 (UTC)[reply]
@Jonesey95: That's nonsense. I can think of several instances in which you might collapse chunks of content to make the article more viewer friendly.
@Enwebb: Ok thanks. I have tried Template:Collapsed infobox section begin, see here. The results are... reasonable. But can't the functionality be a default part of the box? List of Sarcocystis species might not pass the notability threshold, since only four Sarcocystis species have their own article. Cheers, Manifestation (talk) 16:08, 27 March 2020 (UTC)[reply]
I would oppose collapsed text being a default part of the infobox, per MOS. If you have an objection to the current text at MOS:DONTHIDE, which is a community guideline, please take it up on the talk page for the Manual of Style, Wikipedia talk:Manual of Style. – Jonesey95 (talk) 16:46, 27 March 2020 (UTC)[reply]
I too would strongly oppose collapsible text, per MOS:DONTHIDE. There's no reason whatsoever to have a hidden list in the taxobox. Reasonable length species lists, say up to 50, can be put in the text with a wikilink from the taxobox, longer ones can have their own list article. Since species are inherently notable, I've never seen any sustained objection to a separate list article. Peter coxhead (talk) 17:32, 27 March 2020 (UTC)[reply]
I also don't recommend the collapsible text, but the original point is valid, it's far too large for an infobox. I think the species should be moved to the body of the text (it can be in columns to save space) and just have that section of the infobox deleted. Mattximus (talk) —Preceding undated comment added at 17:48, 27 March 2020‎ (UTC)[reply]
Ok, fine. How is this? - Manifestation (talk) 18:51, 27 March 2020 (UTC)[reply]
Much better. There is some advice in the Template Data (used in Visual Editor) not to add long lists of subdivisions to a taxobox. But there are other documentation pages that don't have that advice. Plantdrew (talk) 22:25, 27 March 2020 (UTC)[reply]
  • Picking up on the "don't have collapsed content in boxes" bit - I have several times added pre-collapsed synonym lists to taxoboxes when the number of entries hits a dozen or more. Seems to be a reasonably common practice, and I can't remember ever seeing a synonyms list present in the main body instead. What's the take on this? --Elmidae (talk · contribs) 16:55, 17 April 2020 (UTC)[reply]
I also routinely collapse large synonym lists in taxoboxes. Loopy30 (talk) 22:38, 17 April 2020 (UTC)[reply]

Automatic cladogram

Since we already have taxa in correct order with Template:Automatic taxobox, can we use this info to create something like {{Automatic cladogram}}? The idea is you put two parameters, name and depth and it would automatically draw a cladogram for you. For example: {{Automatic cladogram|Dinosauria|2}} would create a cladogram with Dinosaur as parent and two taxon ranks below.  Dinosaur (talk) 🌴🦕🦖 -- 20:34, 15 April 2020 (UTC)[reply]

That sounds like a good idea. Of course, this wouldn't be used for taxa with volatile classification schemes or chronospecies, like belemnite which has 4 cladograms, or Homo floresiensis where the cladogram uses the |label= parameter to denote direct ancestry   User:Dunkleosteus77 |push to talk  01:56, 16 April 2020 (UTC)[reply]
I don't think any classifications are stable enough that this would be beneficial. The automatic taxobox templates are themselves changed all the time, and they don't reflect one simple classification scheme, so a resulting cladogram would be a hodgepodge of different schemes, therefore WP:synth. FunkMonk (talk) 05:41, 16 April 2020 (UTC)[reply]

This won't work for the reason that FunkMonk gave. There used to be code that would automatically generate the child taxa of a given taxon from the taxonomy templates. However, it had to be removed because of the way taxonomy templates are used. In summary, taxonomy templates encode a particular upwards classification used in a given case; they cannot be used downwards because multiple inconsistent upwards classifications may end at the same taxon.
Let me explain in more detail. Some taxa are represented by more than one taxonomy template ("variants"). This enables the system to encode different classifications for the same taxon. The best known example is in fact in dinosaurs. The 'dinosaur' system and the 'bird' system are different. If you go to Template:Taxonomy/Aves, you'll see that the parent is "Ornithurae/skip", which works its way up to "Sauropsida", leaving gaps. This is what bird editors want. If you go to Template:Taxonomy/Ornithurae, you'll see a much fuller hierarchy, but it also works its way up to "Sauropsida". If you try to generate a cladogram downwards from "Sauropsida", you need first to find all taxa whose taxonomy templates have |parent=Sauropsida. Ignoring a sandbox version, there are five, which would give you the start of the cladogram as:

Sauropsida

Reptilia

Archosauria (via Archosauria/skip)

Avemetatarsalia (via Avemetatarsalia/skip)

Lisboasaurus (a genus)

incertae sedis

Going down from Reptilia, you would eventually find Archosauria and below it Avemetatarsalia. You'd also find Avemetatarsalia going directly down from Archosauria. I can give many other examples. Taxonomy templates do not encode a tree, but a network.
It has been suggested that to get a cladogram, you just ignore the variants and follow the main taxonomy templates (i.e. those without "/qualifier"), but this doesn't work either, because which version has a qualifier is largely historical: the first created version will be the plain one, later ones will be variants, but the later ones may be the most up-to-date. Peter coxhead (talk) 05:59, 16 April 2020 (UTC)[reply]

In short the taxonomy templates work upwards so, even if the other issues on variable taxonomy were resolved, are only suitable for a cladogram showing an article taxon as a terminal. If you want a cladogram with the article as the root the taxonomy templates don't have the relevant information in a form accessible from a template or module. Hypothetically there two ways it could be done.
  1. If the |subdivisions= parameters were well-formed and had the child branches, it would be possible to extract this information with Lua in a module using the child taxa in |subdivisions= and then reiteratively getting subsequent child taxa using title objects to get the |subdivisions= content from the taxoboxes in the pages for the child taxa. Given the variety of formats in the |subdivisions= this is impractical and editing the pages to generate a standard format in |subdivisions= would be more effort than constructing a cladogram from scratch.
  2. The taxonomy template information can be extracted in a downwards direction using Javascript to access the API. I already have a script that does that and can generate a list of the taxonomy. This could be used to generate a draft cladogram using the {{clade}} template, but it would likely need editing anyway, as it couldn't handle alternative taxonomies. And any method using Javascript can only be a tool or an added extra; it can't be used for the standard page output.
But that is all hypothetical. I agree with the above that getting automated cladograms from the taxonomy templates is impractical at best. I think any effort to systematize the cladograms would be better used to generate a series of standard accepted and/or consensus cladograms in templates and then reuse those in articles. —  Jts1882 | talk  10:15, 16 April 2020 (UTC)[reply]
@Jts1882 About the javascript method, what is your opinion if the code is modified so that if it finds A is the parent of B and C, and B is the parent of C then it would change its former A-C line to A-B-C? This would fix the problem that Peter coxhead raised. I agree with FunkMonk this method would be synthetic, have little scientific value and the resulting cladograms should not be included (or included but with a warning) in articles. A situation where this could be useful is when someone with limited expertise in an area just wants to have some quick general idea about where a particular taxon stands. Offical cladograms are usually small, only cover some branches, he cannot "zoom out" to see the bigger picture. If time allows it, could you modify your code to make it a gadget Jts1882?  Dinosaur (talk) 🌴🦕🦖 -- 02:58, 17 April 2020 (UTC)[reply]
@Khủng Long: just to be clear, it's not only that the taxonomic "tree" reduces to a net, it's also that incompatible classifications are encoded in the taxonomy templates. Compare upwards from Template:Taxonomy/Embryophytes/Plantae (used by every single flowering plant taxobox), which treats Plantae as a kingdom, and Template:Taxonomy/Embryophytes (used mainly in taxoboxes for "algae"), which does not include any kingdoms, replacing Plantae by Archaeplastida and Viridiplantae – roughly, Plantae sensu lato and Plantae sensu stricto respectively.
(It's sometimes thought that Wikidata could be used instead, but this makes even more explicit the fact that there are variant taxonomies, since a taxon item can have multiple parents: see, for example, Lemnaceae (Q14293890).) Peter coxhead (talk) 06:26, 17 April 2020 (UTC)[reply]
Even if this kind of template is technically feasible, I don't see any reason to use it and I don't think it's a good idea to use it anyways. Most cladograms currently in use on articles are based on the results of specific papers, not some well-resolved consensus which can be summarized easily in one universal cladogram. If this system is used, it would generate cladograms which have never appeared in the literature and therefore would not be congruent with our policies on sourcing our information and not generating original research. In addition, the automatic taxobox template does not make use of unnamed clades, while cladograms need to, a disconnect which would create artificial and unsourced polytomies in any cladogram derived from the taxobox. Fanboyphilosopher (talk) 02:32, 23 April 2020 (UTC)[reply]
Exactly right. Peter coxhead (talk) 06:30, 23 April 2020 (UTC)[reply]

Not sure where to request fix

The page Phlaeothripidae uses an automatic taxobox which appeare to be somehow malfunctioning. If I'm not signed in, the page doesn't load properly, and the preview text that accompanies the Google hit (Google search here), itself contains taxobox error message copy:

Phlaeothripidae is a family of thrips with hundreds of genera.
They are the only family of the suborder Tubulifera, and are
themselves ordered into two subfamilies, the Idolothripinae
with 80 genera, and the Phlaeothripinae with almost 400.

Family: Phlaeothripidae; Uzel, 1895
Missing taxonomy template (fix): Tubulifera
Phlaeothripidae - Wikipedia

I am not familiar enough with Automatic taxboxes to fix it myself, or even to diagnose the problem, and I'm too busy remodeling a garage to learn about it right now. I'm guessing it's an easy fix for someone who just knows how the system works, so I chose to report it here. If you read this far, thanks. :) -GTBacchus(talk) 19:26, 28 May 2020 (UTC)[reply]

Is it just the Google snippet that's the problem? The taxobox in the article looks fine to me, even when not logged in, but I do see the error in the Google snippet. I guess Google just happened to take a snapshot of the page at an inopportune time. 19:44, 28 May 2020 (UTC)
The taxobox and google search seem in order for me. Is it still a problem for you? Sometimes there are strange caching issues. —  Jts1882 | talk  19:48, 28 May 2020 (UTC)[reply]
I think that the parent of Phlaeothripidae was changed before the parent's taxonomy template was set up, so there was a transient error in the taxobox, which got picked up by Google and also got cached. Experience shows that you need at least a null edit to force a full refresh of the hierarchy of taxonomy templates. Peter coxhead (talk) 21:45, 28 May 2020 (UTC)[reply]
Previously, the taxobox appeared normal, but other parts of the page were broken, like all the links along the top right corner of the page, and all the links on the left side of the page, were smashed together in groups. It just looked like broken HTML somewhere in the mix, but I could still read the article. Now, that's not happening, and only the Google snippet is being weird, but I'll try clearing my browser cache or something. -GTBacchus(talk) 17:37, 29 May 2020 (UTC)[reply]