Template talk:Taxonbar

'Exists' module misses cases where the taxonbar is commented out
I happened to notice that a page with the taxonbar commented out didn't appear in Category:Taxobox articles missing a taxonbar. Looking at Module:Taxonbar/exists and Module:Template redirect regex, I can see why not. I don't think there's any obvious fix, but this search finds pages where taxonbars have been commented out. Of course, those pages may also have taxonbars that are not commented out.

I have uncommented many examples.
 * William Avery (talk) 07:42, 11 April 2024 (UTC)
 * The regex in Module:Taxonbar/exists could be modified to check for the comment, but that might be tricky. A simpler change would be to add a second search. If a taxonbar is found it check to see if it's preceded by a comment (similar to your search). It might be better to have a category for commented out taxonbars. —  Jts1882 &#124; talk 10:34, 11 April 2024 (UTC)
 * I assume examples like Violet-crowned_hummingbird were commented out because the taxonbar scientific name didn't match the article scientific name. This bird was moved from Amazilia violiceps to Leucolia violiceps by Birdlife/IUCN and to Ramosomyia violiceps by ebird/BOW. It needed changes on Wikidata to work properly. It would be useful to have such cases flagged. —  Jts1882 &#124; talk 10:53, 11 April 2024 (UTC)
 * I'm trying in Module:Taxonbar/exists/sandbox, but I'm unable to match  for simplicity, and braces don't need escaping in Lua (since generalized finite quantifiers   don't exist in this implementation). Regardless, I found the problem. I was using   for the , so the regex was running on Template:Taxonbar/exists/testcases instead of the intended Template:Taxonbar/exists/testcases/true... Shouldn't be a problem to implement now...!   ~ Tom.Reding (talk ⋅dgaf)  14:33, 17 April 2024 (UTC)
 * ✅! Pages with commented taxonbars should now be processed as if it doesn't exist, and be categorized accordingly.  ~ Tom.Reding (talk ⋅dgaf)  14:54, 17 April 2024 (UTC)
 * I fiddled about with Mesembrinella aeneiventris to see if it would go into a maintenance category, but I had no luck. William Avery (talk) 09:04, 18 April 2024 (UTC)
 * I think line 10 needs deleting. —  Jts1882 &#124; talk 11:14, 18 April 2024 (UTC)
 * ✅  ~ Tom.Reding (talk ⋅dgaf)  11:19, 18 April 2024 (UTC)
 * I'm starting to see some of the articles with commented out taxonbars showing up in the missing category now, which I've then been able to update appropriately. Good job! - UtherSRG (talk) 14:25, 18 April 2024 (UTC)

Taxonbar for mobile
This topic has come upon a number of occasions, most recently at WT:Automated_taxobox_system. Taxonbar uses Navbox and for some reason this is disabled on mobile. Anything using  is removed server side, although the templatestyles are still on the page.

Last year I did some experiments on alternative outputs for taxonbar information, bypassing Navbox, and also using taxonbar to output sitelinks. I've restored these options to Module:Taxonbar/sandbox and placed the examples in User:Jts1882/taxonbar. I was trying to work out what works on mobile and what doesn't and surprisingly all the collapsible options worked. More surprisingly the taxonbars worked (I've since seen the taxonbar documentation and testcases show taxonbars on mobile). Navbox is only blocked in mainspace, not template of user space.

Anyway, the reason for this topic is I've created prototype output in Navbox style that works on mobile:


 * Mobile compatible taxonbar:


 * Standard taxonbar for comparison:

To test on mobile you can copy the code above and preview it on the Indian_flying_frog page.

I'm uncertain if this should be implemented. There is a reason Navbox is blocked and this might be considered an attempt to bypass a Wikipedia policy. My suspicion is that big nested Navboxes are the problem and a small simple table like the taxonbar doesn't cause the same issues. —  Jts1882 &#124; talk 12:25, 25 April 2024 (UTC)


 * Looks good! Whom can we ask about the potential policy issue? - UtherSRG (talk) 12:44, 25 April 2024 (UTC)
 * Not sure.
 * I've done a little research and found . The main objections are that they use large nested HTML tables, which supposedly don't show so well on mobile, and have large download sizes. My mobile version about uses one table with two columns, so probably isn't the type of Navbox that led to prohibition.
 * A better solution is to make a  based output. A problem here is aligning the left hand column without using a fixed width and getting the floating elements right. I found a neater method using   which I've implemented using templatestyles.
 * Mobile compatible taxonbar (using grid and divs):


 * Standard taxonbar for comparison:


 * A problem here is backward compatibility. Grid is supported by all browsers, but I don't know for how long. Wikipedia wants everything to remain compatible with the abacus, except for Vector-2022 which is allowed to break everything.
 * Anyway, I think I've seen enough to think we can convert the taxonbar to a non-navbox solution which can be seen on mobile. —  Jts1882 &#124; talk 16:57, 25 April 2024 (UTC)

"nomenclatural type of" usage being frowned upon
(or anyone...) I'm being told on my WD talk that our use of is incorrect. I'm not sure whether they are saying we should be using or do something else. Can y'all jump in and help straighten this out? - UtherSRG (talk) 16:44, 30 April 2024 (UTC)


 * , while I'm not sure exactly what a is or how it is to be used, I notice that it is a Wikidata item (Q), not a Wikidata property (P). An inverse relationship that I understand better is  and ; those are both properties. d:User:ChristianKl/Out of scope use of labels shows 196 instances of " nomenclatural type of", and there are 200 pages linked to the item; one is your talk page, one is ChristianKL's Out of scope page, and one . That leaves one taxon page that isn't on the Out of scope page (and is presumably "in scope"?) but I don't know what it is. Of the instances of Q116044186 I've looked at, I haven't found any that weren't added by you.


 * I'm not sure what you are trying to accomplish. If it's in support of allowing taxonbars to automatically pick up multiple Wikidata items related to monotypy, there is still the problem I mentioned in a now-archived thread of monotypic genera where the type species is a synonym of the only accepted species. That is a rare situation, but it does happen.


 * is problematic; whether a taxon is monotypic or not may vary between different taxonomic viewpoints. Wikidata is supposed to represent different taxonomic viewpoints equally.


 * I'm not sure that it is really feasible to have taxonbars pick up multiple Wikidata items related to monotypy. Plantdrew (talk) 19:18, 30 April 2024 (UTC)
 * The work I did was in support of existing taxonbar coding, so as to help categorize usage properly, so yes, to determine if the QIDs being provided to the taxonbar are a monotypic pairing. I did so under advisement from (IIRC) when I asked about working to solve some of the issues at Category:Taxonbar cleanup and Category:Taxobox cleanup. If what I'm doing is not the correct solution, what is? And the taxonbar will need its code changed to accomodate. - UtherSRG (talk) 23:57, 30 April 2024 (UTC)
 * Iirc, I suggested we could use the type species to get the child species for a monotypic genus and implemented this. Looking at the code, it retrieves  for monotypic genera and checks whether it is  or, in which case it is accepted. I don't see a use of  or  so I'm confused about what the issue is about. —  Jts1882 &#124; talk 06:51, 1 May 2024 (UTC)
 * I don't think checking a putative type species for monotypy is the correct approach to test validity. The type doesn't need to be monotypic. I'm not sure what to check for as the examples include a type specimen. Perhaps check that the item is a taxon name and has the monotypic genus as its parent. —  Jts1882 &#124; talk 08:46, 1 May 2024 (UTC)
 * No one answered this, but I think checking that monotypic genus has a   that is a taxon name and has a parent matching the monotypic genus will pick up some species of monotypic genera. It won't when there are new combinations. —  Jts1882 &#124; talk 13:35, 3 May 2024 (UTC)
 * This is my suggestion. —  Jts1882 &#124; talk 14:23, 3 May 2024 (UTC)


 * Going back to 's post above, I agree that we should not be using to determine whether a taxon is monotypic or not, because of Wikidata's neutrality on taxonomic views. Lumpers, like PoWO for ferns, will have many fewer monotypic taxa than splitters. We have to decide one way or the other for the article title and taxobox, but Wikidata does not and should not. Peter coxhead (talk) 07:07, 1 May 2024 (UTC)
 * The taxonbar is looking for alternative treatments, so this might not be a problem. —  Jts1882 &#124; talk 08:46, 1 May 2024 (UTC)
 * This is in regards to how to populate these tracking categories:
 * Category:Taxonbars of monotypic genera missing species‎ (4,022 P)
 * Category:Taxonbars of monotypic species missing genera‎ (empty)
 * Category:Taxonbars with automatically added monotypic genera (empty)
 * Category:Taxonbars with automatically added monotypic species‎ (empty)
 * But perhaps we don't have the right tracking categories. I've been assuming we do, as this was set up for a reason, but I don't know that we do. Given the lopsidedness of the population of the categories, probably we don't. you are correct in your assessment that we aren't using the "nomenclatural" fields on WD... but our discussion was that we needed a method to note both sides of the parent-child monotypic relationship, but then it didn't get implemented, IIRC, even though I'd already been updating WD with it. I don't recall which archived talk page had the discussion, but the past is the past and we should look to the future.
 * If we don't want to track monotypy, then let's just delete these four categories, remove the code that populates them, and I'll undo the ~200 uses of "nomenclatural type of" on WD that I added.
 * Assuming, then, that we do want to track "something" about monotypy, what do we do? We need a way to detect a monotypy, and we need to determine if the QIDs we have on hand align with that monotypy. On one hand, we have one or more QIDs listed in the taxonbar. Does the information on Wikidata for these QIDs indicate we have a monotypy, and does the collection of QIDs in the taxonbar include both the parent and child of the monotypy? On the otherhand, we currently have no way to indicate on the taxonbar that we have a monotypy a priori. This may be something we want to address.
 * To address 's issue directly, while you are correct from an article and taxobox perspective, I don't think that's an issue from a taxonbar point of view. We have to pick a single taxonomy for the article and taxobox, but the taxonbar can list multiple combinations and thus be neutral on taxonomic views. This allows us to fully utilize the array of taxonomies recorded at Wikidata.
 * Be that as it may, let's continue with the assumption and the given existing tracking categories, and determine the right algorithm to populate them, and what WD fields/properties to use to do this, that doesn't rock the boat on WD's side.
 * Loop over the QID collection
 * If the QID (parent) indicates it is monotypic (monotypic taxon or monotypic fossil taxon) (and if we haven't checked this QID already from the child->parent relationship)
 * If the parent's taxonomic type (child) indicates it is the parent's type (how? subject has role -> nomenclatural type -> parent? Something else/new?)
 * We have a confirmed monotypy parent->child
 * If child is not in our current collection, add category "missing child" (or be bold and add the child to our collection and add category "automatically added child") [A]
 * If QID (child) indicates it is the type of some parent (see how? above) (and if we haven't checked this QID already from the parent->child relationship)
 * If the parent indicates is is monotypic (monotypic taxon or monotypic fossil taxon)
 * We have a confirmed monotypy child<-parent
 * If parent is not in our current collection, add category "missing parent" (or be bold and add the child to our collection and add category "automatically added parent") [B]
 * On the "how" question, if "nomenclatural type of" is not the right way, what can we use? Change it from to ? Add a new property that is the inverse of ? Something else? I think we need input from someone familiar with the expectations on the WD side like d:User:ChristianKl (and I've let them know we are having this discussion and asked them to take a look here).
 * If we do want to a priori indicate we have a monotypy, I suggest adding new fields to the taxonbar in some manner like this:  and   where N is a number (we may have multiple monotypic taxa in one article, so N number of parent/child relationships) and x indicates which   field fills this role. For instance:   would indicate from1 & from2 form a monotypy, with from1 being the parent and from2 being the child.
 * Given the above, I would suggest some the following as well:
 * The algorithm above, when detecting a monotypy exists on WD, but we have no a priori indication, add (new) category "missing monotypy fields for monotypic pairing". [C] This may be in addition to a missing parent/child, if we are missing a QID in the taxonbar.
 * The algorithm above, when not detecting a monotypy on WD, but we do have an a priori indication, add (new) category "monotypy needs additional Wikidata item".
 * Finally, that set of categories I started with? I'm now sure it's not the best set and that we can do better. I don't think we care specifically about monotypic genera, but that we care about monotypic taxa in general. (Yes, pun intended with "specifically" and "in general".) Why would we want to track monotypic genera, and not other monotypic taxa? If we use the various changes I suggest in this post, I think the following is a better set of tracking categories:
 * Category:Taxonbars of monotypic parent missing child‎ or Category:Taxonbars with automatically added monotypic child (one or the other from [A])
 * Category:Taxonbars of monotypic child missing parent‎ or Category:Taxonbars with automatically added child of monotypic taxon (one or the other from [B])
 * Category:Taxonbars missing monotypy fields (from [C])
 * Category:Taxonbars pages requiring monotypic Wikidata item (from [D])
 * Looking at Category:Taxonbar cleanup and how the subcategories are sorted, I would say [A] and [B] would be "T" types, [C] is "M" type, and [D] is "E" type. I also think we need to review the remaining subcategories of Category:Taxonbar cleanup with regard to whether or not we need them, and if they are properly sorted, but that's a topic for another discussion. - UtherSRG (talk) 12:09, 1 May 2024 (UTC)
 * The biggest hurdle is going from parent -> child in Wikidata. If is not appropriate for this purpose, then we should try to resurrect d:Wikidata:Property proposal/child monotypic taxon from 6 years ago. There's obviously a need for it, or something like it. If that can't/won't be done, then we should probably abandon this effort for finding/tracking monotypes. I think it's in the best interests of Wikidata and all the Wikipedias that such a property exists, and it would be silly/lazy to not have it.   ~ Tom.Reding (talk ⋅dgaf)  14:24, 1 May 2024 (UTC)
 * is not appropriate for this purpose. For Psilurus, the type is Psilurus nardoides, which is a synonym of the only accepted species, Psilurus incurvus. Another issue is that as per the ICZN: "Recommendation 67B. Citation of type species. The name of a type species should be cited by its original binomen" (botanists also do this). The ICZN gives the example of Astacus marinus as the type of Homarus, which is what the Wikipedia article shows. But Wikipedia is inconsistent in following that practice. I haven't paid enough attention to Wikidata's type species statements to know if Wikidata is consistent, but I suspect it is not. The type being a synonym is an uncommon situation. The type being an original binomen is more common. Plantdrew (talk) 16:33, 1 May 2024 (UTC)
 * Hrm. This is a very good point. Couple that with Tom's point above regarding the previous attempt at a "child monotypic taxon" property, and I think we need to start with a fresh new pair of properties, though resurrecting the proposal and adding a "parent monotypic taxon" property might be possible. Hrm.... - UtherSRG (talk) 16:52, 1 May 2024 (UTC)
 * This isn't the first time I've raised an issue, we have a bunch of discussion, and then nothing happens, and I move on to other work because things were left hanging. I don't want to repeat that. So... are we going to do anything here? - UtherSRG (talk) 13:09, 3 May 2024 (UTC)
 * If we don't want to move forward with finding a way to track monotypy, then let's remove that tracking from the taxonbar and remove those four categories. - UtherSRG (talk) 13:11, 3 May 2024 (UTC)
 * I've bumped a suggestion I made earlier which got ignore (or dismissed as rubbish). Think that could pick up some species of monotypic genera. —  Jts1882 &#124; talk 13:37, 3 May 2024 (UTC)
 * Plantdrew nixed that, because the taxonomic type of a species may not belong to the genus, if the species is being moved from one genus to the new genus. (Though I'm betting more often than not the new combination is used in the P427 field when it should not be.) - UtherSRG (talk) 14:22, 3 May 2024 (UTC)
 * Which suggestion is that, and how does it compare to the potential "child monotypic taxon" + "parent monotypic taxon" Wikidata properties? I admit I haven't been completely following all the discussions...  ~ Tom.Reding (talk ⋅dgaf)
 * (You used three tildes... so manually replying) He replied quite a bit above to suggest using P427 in a different manner. checking that monotypic genus has a that is a taxon name and has a parent matching the monotypic genus will pick up some species of monotypic genera. It won't when there are new combinations. - UtherSRG (talk) 14:23, 3 May 2024 (UTC)
 * Yes, it will pick up some, but not sufficient to pick up all. This should only pick up monotypys where a newly described species and its genus are described at the same time, not when a new genus is described from an old species. We need a solution for both kinds. - UtherSRG (talk) 14:25, 3 May 2024 (UTC)
 * My test for the parent taxon would ensure the genus matches. —  Jts1882 &#124; talk 14:53, 3 May 2024 (UTC)
 * Are we all in agreement then that d:Wikidata:Property proposal/child monotypic taxon should be resubmitted, along with a to-be-drafted d:Wikidata:Property proposal/parent monotypic taxon? I'd like to see a strong show of support here before they're re/submitted.  ~ Tom.Reding (talk ⋅dgaf)  14:29, 3 May 2024 (UTC)
 * For taxa that are both a child and a parent in a monotypy (so for example a family that has a single species), would both of these properties be used? - UtherSRG (talk) 14:31, 3 May 2024 (UTC)
 * Yes, the genus would/should have both, which would make it very easy to go up/down the monotype line.  ~ Tom.Reding (talk ⋅dgaf)  14:39, 3 May 2024 (UTC)
 * Cool. Then yes, I'm in support of resubmitting and having the parent property drafted. They should be submitted together so that they can be discussed as a pair. I think we could then argue that both and the fossil equivalent can be mothballed as no longer relevant and all uses replaced with just plain "taxon". UtherSRG (talk) 14:45, 3 May 2024 (UTC)
 * is not a property, so its functionality is different, and still useful, e.g. -> . Its description would be amended to allow it to be used on parents or children, as opposed to only on parents.   ~ Tom.Reding (talk ⋅dgaf)  15:02, 3 May 2024 (UTC)
 * I was using it in this manner and was harshly squashed for doing do. They will not accept that. - UtherSRG (talk) 16:06, 3 May 2024 (UTC)
 * Can you link to that/those discussion/s? There are 10,749 ->, so unless you placed most of those, that's definitely one of the valid use-cases. Regardless, this is something to discuss after the proposals.   ~ Tom.Reding (talk ⋅dgaf)  15:08, 4 May 2024 (UTC)
 * I was squashed for using on species of monotypic parents, first on the talk of an item, then at their AN board. - UtherSRG (talk) 17:23, 4 May 2024 (UTC)
 * Let me state what I understand is being proposed. The child monotypic taxon property would be added to monotypic taxon items and specify the single child taxon (i.e. it is a "child taxon of monotypic taxon property"). The parent monotypic taxon property would be added to the single child taxon item to indicate that the parent is monotypic. Perhaps it should be designed to be a qualifier of parent taxon, i.e. an "is monotypic property". Alternatively a parent taxon could be qualified with instance of (P31) with monotypic taxon (Q310890) using existing properties (if this is allowed). —  Jts1882 &#124; talk 16:10, 3 May 2024 (UTC)
 * "Parent monotypic taxon" & "child monotypic taxon" properties in this case mean "has parent monotypic taxon" & "has child monotypic taxon" (as opposed to "IS parent/child monotypic taxon"), in keeping with the existing property usage.
 * I'll use Uther's example since that covers all permutations, where a monotypic family has a singular species. The family item would have the "child monotypic taxon" property pointing to the genus. The genus would have "parent monotypic taxon" pointing back to the family, and have "child monotypic taxon" pointing to the species. And the species would have "parent monotypic taxon" pointing back to the genus.  ~ Tom.Reding (talk ⋅dgaf)  15:08, 4 May 2024 (UTC)
 * what do you think?  ~ Tom.Reding (talk ⋅dgaf)  14:44, 9 May 2024 (UTC)
 * Worth a shot. While a child taxon property would be a valuable addition, that is impossible while Wikdata items are a hybrids of taxon and taxon name. The same item is often used for different circumscriptions of the taxon name with different sets of children (e.g. see ). However, monotypic taxa don't suffer from the same problem; if the taxon is monotypic the child taxon is fixed (even if the name can change). And a corresponding property for the child-parent relationship also makes sense, although allowing instance of monotypic taxon as a qualifier on parent taxon is an alternative. —  Jts1882 &#124; talk 14:58, 9 May 2024 (UTC)

I remain concerned over Wikidata's neutrality on taxonomy. Just to take an example I've been working on recently, according to some sources Chrysogonum is monotypic with one species, Chrysogonum virginianum, as [//en.wikipedia.org/w/index.php?title=Chrysogonum&oldid=1190693011 this version of the article said]. But other sources have 1 to 3 North American species and in the case of PoWO another 4 Madagascan species. The Wikidata item should allow the taxon name to be declared both monotypic according to given sources and non-monotypic according to others, just as it allows a taxon name to have multiple parent taxa. Peter coxhead (talk) 10:24, 10 May 2024 (UTC)
 * If the "monotypic X taxon" property had both a subfield of "references" (ie support for this taxonomy) and a subfield of "refuted by" (ie support for a non-monotypic taxonomy), would that allay your concerns? (We can quibble over names for the subfields, but the concept is what I'm hoping will align with you.) - UtherSRG (talk) 13:04, 10 May 2024 (UTC):An alternative to that is to add a third property to our proposal: "child taxon". For taxa that are the parents in a monotypy, they would use "monotypic child taxon". For taxa that are the parents in a polytypy, they would use "child taxon" with multiple children. For taxa that are listed sometimes as a monotypic parent, and sometimes as a polytypic parent, they would use both. (Likewise, child taxa would use "parent taxon" if they have sibling taxa, "monotypic parent taxon" if they have no sibling taxa, and both if they are listed in conflicting mono- and polytypic taxonomies.) - UtherSRG (talk) 13:10, 10 May 2024 (UTC)
 * It would definitely need a subfield of references (as there are for other properties); the negative isn't needed because it's implicit in the reference for any alternative. But the issue then is whether it's possible to use the information over here, in taxonbars, etc., because it would be necessary to know which alternative we are following. (It's parallel to the objection that arises when from time to time it is proposed that we use Wikidata instead of taxonomy templates. Taxonomy templates have to form trees; Wikidata taxon instances don't.)
 * It's also worth noting that trying to track monotypy raises maintenance issues. In my experience here, monotypic genera regularly become nonmonotypic. E.g. Mexerion which I noticed earlier is said in [//en.wikipedia.org/w/index.php?title=Mexerion&oldid=1084840041 this version] to be monotypic, but according to Tropicos Nesom added another species in 2023. So given that Mexerion stolonatum is a valid taxon name, it needs a taxon item in Wikidata, which would require a change to  if this listed child taxa. I'm not sure if a bot could deal with this because of the complexity of multiple views:
 * Global Compositae Checklist 2014, World Flora on Line right now: Mexerion is monotypic
 * PoWO right now: Mexerion has 2 spp.
 * Tropicos right now: Mexerion has 3 spp. (based on Nesom (2023))
 * Peter coxhead (talk) 07:02, 11 May 2024 (UTC)