Jump to content

Template talk:Taxonbar/Archive 8

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 5Archive 6Archive 7Archive 8Archive 9

Synonyms: check for Taxobox agreement

Some taxon names change. People tend to be good at updating the lead section and the Taxobox right next to it, but they often forget about the Taxonbar at the bottom. I just caught one such issue at pea: Special:Diff/1194118472 and I think I've come across several more in the past.

What if we get Taxonbar to check whether the scientific name in the Taxobox matches any of the taxon names in the Wikidata entries?

  • First use mw:Extension:Labeled Section Transclusion to obtain the HTML of the lead section, which should include the expanded Taxobox: local html = frame:preprocess('{{#section:{{FULLPAGENAME}}}}')
  • Grab the name from the HTML. Which is a bit of a pickle, because HTML isn't the easiest thing to parse without a well-vetted library. Maybe we should talk to the Taxobox people and have them leave us some easier-to-read hidden text.
    1. For species and subspecies pages, there's a big section called "binomial/trinomial name" in the Taxobox. span class="binomial", span class="trinomial" are obvious in the HTML.
    2. For other ranks, the process is more involved: you gotta read the "Scientific classification" section of the Taxobox and grab the text from the last line of the table. Not very fun to write code for.
    3. {{Hybridbox}} is on the species rank, but also requires going through the "Scientific classification" section, since there is no binomial/trinomial. Here the genus is probably abbreviated, so some expansion will be needed to produce a possible match of the Wikidata taxon name. Or just ignore anything with a "×" for now.
  • Compare the name to all the taxon names in the Wikidata entries. If it isn't there, tag on a tracking category.

--Artoria2e5 🌉 09:17, 7 January 2024 (UTC)

This would be a useful check. It means the page is associated with the wrong Wikidata item, which Pea still is (links to Pisum sativum (Q25237) rather than Lathyrus oleraceus (Q109902416)). However, I think the overhead of doing this is likely to be too high. Section transclusions load the whole page, iirc, so could introduce errors on large pages.
As a technical point, it would probably be easier to get the names from the taxobox parameters in the page wikisource (|taxon= or |genus=+|species=) than parsing the HTML. —  Jts1882 | talk  10:40, 7 January 2024 (UTC)
From Wikidata's perspective, pea is not associated with the wrong item. It's associated with the item that has ALL the interwiki links, and that's how Wikidata wants it. 8 languages use Pisum sativum as the title of their article linked to Q25237, 1 language (Italian) use Lathyrus oleraceus and dozens of languages use a vernacular name as the title. I haven't looked at all the taxoboxes of the articles with vernacular name titles, but I doubt very many have L. oleraceus (I did look at the GA in German and the FA in French, and both are using P. sativum in the taxobox). Wikidata definitely doesn't want English and Italian to be linked to one item and every other language linked to a different item. However, dozens of interwiki links (mostly) between vernacular name titles is not a typical case.
What can we do on the English Wikipedia end? Make the taxonbar |from1= match the taxobox name and the check for discrepancies? I've generally been to the opposite when adding from parameters; I make from1 the item with the interwiki links and use from2 and higher for any other names (including the taxobox name if that's not where the interwiki links are). Plantdrew (talk) 16:33, 7 January 2024 (UTC)
I guess this is another example of the problems with the Wikidata structure where items have multiple incompatible identities. The wikidata item is an instance of taxon with taxon name Pisum sativum which should be the label name (with pea as other name) and is clearly the wrong item for English Wikipedia article on Lathyrus oleraceus. If the item was really on the taxon, then it could have multiple taxon names. The Wikidata item should link to the redirect at Pisum sativum and then all would work from the Wikidata end as the English Wikipedia article would be properly linked. Linking to the wrong item to get the best result for interwiki links just seems the wrong solution. —  Jts1882 | talk  16:50, 7 January 2024 (UTC)
The Italian article is on Lathyrus oleraceus (as is newiki). What is the point of having a Wikidat item on Lathyrus oleraceus if the interwiki links don't use it? —  Jts1882 | talk  16:59, 7 January 2024 (UTC)

Cleanup of Category:Taxonbars on possible non-taxon pages

@Jts1882 and Tom.Reding: My next task is to cleanup some of this category. I ran into one issue that I think needs a taxonbar adjustment. Castanea sativa (Q22699) has a dual instance of to fruit and taxon. Fruit was the preferred and taxon was not. This was placing it in this category. Swapping the priority removed it. I think the preference was correct, but that the taxonbar should check any instance of, not just the preferred. Thoughts? - UtherSRG (talk) 15:24, 7 February 2024 (UTC)

@UtherSRG: relaxing the instance-of preferred-ness would probably lower the the # of pages caught (currently ~500), but it would also make it harder to find these mis-preferred pages, so it's a trade-off. If Category:Taxonbars on possible non-taxon pages (418) were very big, and/or filled with many false positives, I'd be inclined to relax it though.   ~ Tom.Reding (talk ⋅dgaf)  15:54, 7 February 2024 (UTC)
So, my edit of the Wikidata was the better option then? I wonder if we could split off catching this kind of error into another category, maybe Category:Taxonbars with non-preferred taxon instances? (Oy, please change that!) - UtherSRG (talk) 16:06, 7 February 2024 (UTC)
User:Scyrme made an effort to clear the category in May/June 2023; there are some threads in the talk page archives here about some issues they encountered. I expect much of what remains in the category will be difficult to address. Of course, there are pages that have entered the category more recently, including Castanea sativa. Edits were made to Wikidata on 17 October 2023 that added fruit to Castanea sativa (Q22699). Fruit belongs on chestnut (Q773987), not the item for the taxon. Changes may need to be made to Wikidata rather than here. Cutbow (Q5196725) has "subclass of hybrid", but should probably be "instance of hybrid". Plantdrew (talk) 17:39, 7 February 2024 (UTC)
So I removed the fruit statements from the Wikidata item for C. sativa, but that's now causing a value type constraint for the statement "has fruit type glans". I'm not sure how fruit type are supposed to be model on Wikidata (and the Wikidata item for glans says it is different from acorn; I consider acorns to be the archetype of a glans). Plantdrew (talk) 17:51, 7 February 2024 (UTC)
~500 articles in the category says to me that it should be worked, even if just to get some better refinement of the problems. Of course the larger Category:Taxonbars desynced from Wikidata should also have some eyes on it.... - UtherSRG (talk) 17:49, 7 February 2024 (UTC)
I removed it and added it to chestnut (Q773987) as a subclass, similar in fashion to acorn. - UtherSRG (talk) 18:07, 7 February 2024 (UTC)

@Jts1882, Tom.Reding, and Plantdrew: I haven't yet checked for the archived threads from back when Scyrme worked this, but I've started to formulate some thoughts. There are definitely a few distinct classes of errors for this category. I'll attempt to name and characterize them below. Perhaps this will help with making more specific categories? Also, I'll outline what solution steps we (I) should take for these classes. And please come up with better category names than I did! XD - UtherSRG (talk) 19:10, 9 February 2024 (UTC)

Is there anything we can do with redirects? en.wiki redirects for disease causing pathogens probably aren't linked very much from Wikidata items for the pathogenic taxa, but that could be fixed. Maybe a new rcat template, {{R from pathogen}}? Plantdrew (talk) 22:09, 9 February 2024 (UTC)
Is this in relation to something I wrote here? I'm not following you. - UtherSRG (talk) 00:13, 10 February 2024 (UTC)
The disease articles on en.wiki are linked to Wikidata items about diseases, with redirects on en.wiki from the pathogens that cause the diseases. Wikidata has items for pathogenic taxa, and the disease articles on en.wiki have taxonbars that use the Wikidata item for the pathogen. The disease articles show up in this tracking category because the linked Wikidata item is not a taxon. I'm wondering if it would be possible to make the tracking category traverse redirects somehow so that disease articles with pathogen redirects don't get included in the tracking category (crocodile is a similar situation with the en.wiki article linked to a non-taxon item on Wikidata, but with a taxon redirect). Plantdrew (talk) 00:54, 10 February 2024 (UTC)
Ah, ok. Like I said, I didn't look close at the virus/disease issues. You are suggesting adding a new rcat. I see that the Crocodylidae redirect has an "R from sci name" rcat on it. So even if your suggestion is the right way to go, it looks like we need some taxonbar coding for this, eh? - UtherSRG (talk) 01:41, 10 February 2024 (UTC)
I have no idea exactly how to get diseases out of the tracking category. The code for the tracking category needs to look for something on either en.wiki or Wikidata in order to exclude diseases. That something might Wikidata property linking the taxon and disease or an en.wiki "property" of the taxon redirect (i.e., an rcat). I guess a Wikidata property would be the better way to go, but Wikidata isn't consistent in how it links diseases and taxa. Some animal diseases have "has cause->taxon", some have "has cause->infection of->taxon" and some have both of those (classical swine fever (Q19000581). Most of the plant diseases I looked at don't have have any property linking to the taxon that causes it. Plantdrew (talk) 02:32, 10 February 2024 (UTC)

Viruses and diseases (V&D)

I'm not sure yet how to characterize these in a formal way, but these look to make up the vast majority (~90%) of the category. I may need to split this into V and D classes... I've been ignoring these for now, but there may be an easy diagnosis for them. If so, splitting them out will be the best way of splitting this category, as I think all the remaining classes are (mostly) easily fixed otherwise. Perhaps checking to see if the article is using {{virusbox}}? If splitting these out specifically isn't possilbe, then splitting some of the others I suggest will be good.

Hybrids (H)

Looks like hybrids in the category are subclass of (P279) hybrid (Q42621) instead of instance of (P31) hybrid (Q42621), which is what the taxonbar checks for. An example is mule (Q41692), and I chose option 1 from the list below to fix it. If the subclass is present, perhaps these can be shunted to Category:Taxonbars for hybrids that are not instances?

Possible solutions:

  1. Replace subclass of (P279) hybrid (Q42621) with instance of (P31) hybrid (Q42621)
  2. Add instance of (P31) hybrid (Q42621) without removing subclass of (P279) hybrid (Q42621)
  3. Alternatively, update taxonbar code to accept either.

Missing instance of (P31) (M)

Mostly for these I just fill in the missing taxonomy info from the existing article, looking up some IDs in the relevant databases so that the taxonbar has some use. While this category is built from QIDs that don't have the correct instance of (P31), perhaps we can push the ones that are missing this property entirely to Category:Taxonbars without instance property?

Paraphyletics (P)

Often times a paraphyletic group has a taxonbar for one or more of the taxons in the group. This is an article issue as opposed to a taxonbar code or Wikidata issue. Best we can do is remove the taxon QID(s) and replace with a QID for the paraphyletic group, if one exists. This can also be a sub-class of M if the paraphyletic QID doesn't have a valid instance of (P31) (should be paraphyletic group (Q58051350)). In which case, I add it. Bandicoot fell into this class. I think we should handle things like Acacia sensu lato in the same way. I don't see a good way for the code to automatically detect this class.

Redirects (R)

Crocodile is the prime example of this class. There is crocodile (Q2535664) for the common term and Crocodile (Q43169) for the taxonomic entity. The Wikpedia article for the latter redirects to the article for the former. Even with everything set up appropriately between Wikipedia and Wikidata, this article remains in the category. Is there something else I should do? Is there some change to the taxonbar code that would be appropriate here, or can we shunt these to Category:Taxonbars with linked redirects?

Non-formal taxa (N)

Articulata hypothesis is the prime example here. I think the right solution is to add something like instance of (P31) Candidatus (Q857968) to the QID. Do we have something similar to that for non-bacterialogials? Maybe we need one? Or should we just remove the taxobox and taxonbar? Or is there a way to suppress the category? (I note that I yeeted the taxonbar from Eocyte hypothesis, which falls in this class. Now it's in Category:Taxobox articles possibly missing a taxonbar‎, which is an improvement, but not much of one.)

Further discussion

  • A few thoughts:
New parameters could be created to suppress taxonbar categories, e.g. an option |category=suppress to deleted the whole category table so a page isn't added to any taxonbar category. Alternatively, a parameter could suppress individual categories, e.g. |category_suppress=4 for the possible non-taxon category.
Those taxobox categories are handled by Module:Taxonbar/candidate, which has whitelists and blacklists that could be added to.
For pages like Articulata hypothesis, a wikidata item for invalid taxon or historical taxon or taxon hypotheses could be created as a subclass of taxon (see list of subclasses for taxon and added to the whitelist.
—  Jts1882 | talk  09:50, 10 February 2024 (UTC)
I don't like suppression as a final answer, as it doesn't really solve anything; I posited it as a last resort. I do know about the whitelist; it's why I suggest possibly adding a new QID for the N-class types. I know we already have unavailable combination (Q17487588), which I suppose could be hijacked; do we really need multiple different ways to say something isn't a valid and useable taxon? Rename it to be "unavailable taxon name"? Meh. I don't like it even as I'm proposing it. So yeah, I'll start with "taxon hypothesis" ("hypothetical taxon"?) as a subclass of both hypothesis (Q41719) and taxon (Q16521) and we can add it to the whitelist. If a hypothesis becomes reality, it can be upgraded from "taxon hypothesis" to "taxon" easily. That should take care of class N errors: change their QIDs from "hypothesis" to "taxon hypothesis". (We may need "invalid taxon" or "historical taxon" for other purposes, but they'd have different parentage.... and I note that there are already some specific nomenclatural terms we want to be mindful of, some of which fall into the description of "invalid taxon" or "historical taxon".) BTW: That subclasses of taxon query returns a bunch of crap... including a ton of things that aren't subclasses of taxon. What's up with that? Oh wait... now I see... it's returning all the descendants on the subclass tree, not just direct descendants. - UtherSRG (talk) 13:57, 10 February 2024 (UTC)
taxon hypothesis (Q124477390) - UtherSRG (talk) 13:59, 10 February 2024 (UTC)
I couldn't work out how to limit the query to one level. It's the + that causes the whole tree. This query gets the first level of subclasses, although still has some questionable stuff. I think obsolete taxon (Q110533142) would have been suitable for Articulata hypothesis. —  Jts1882 | talk  15:27, 10 February 2024 (UTC)
"Obsolete" implies that it was once modern and/or valid but is no longer. That's not what I think we want to imply about things like Articulata hypothesis. Some may be failed hypotheses, and so they would be obsolete, but some may become standard theory. I'm going to start solving the N-class errors by changing their "instance of" to "taxon hypothesis". @Tom.Reding: Can you please update the whitelist? - UtherSRG (talk) 21:48, 10 February 2024 (UTC)
 Done   ~ Tom.Reding (talk ⋅dgaf)  11:09, 11 February 2024 (UTC)

Adding Observation.org taxon ID

I would like to request the addition of the Observation.org taxon id https://www.wikidata.org/wiki/Property:P6105. It will link to the species information on Observation.org. Disclosure: I work for Observation.org. Dyve (talk) 15:02, 11 February 2024 (UTC)

Template-protected edit request on 18 February 2024

Add Observation.org taxon id https://www.wikidata.org/wiki/Property:P6105.

It will link to the species information on Observation.org.

Reason: Observation.org is an online platform/database that records, validates and shares biodiversity information (230M+ records, strong userbase especially in Europe, almost 20 years old, 3rd largest open data provider on GBIF). The Observation.org taxon ID is well populated on Wikidata.

Disclosure/COI: I work for Observation.org. Dyve (talk) 11:44, 18 February 2024 (UTC)

 Done. Example at Betula pendula. —  Jts1882 | talk  16:31, 18 February 2024 (UTC)

Template-protected edit request on 19 February 2024

Change

{ 'Euring', 'Euring', 3459 }, ---[[Euring number]] DNE as of 3/2023

to

{ 'EURING', '[[European Union for Bird Ringing|EURING]]', 3459 },

with reasons

- EURING is spelled in all caps (ref: https://euring.org) - a record for the European Union for Bird Ringing (EURING) has now been established, ref: European Union for Bird Ringing Dyve (talk) 12:18, 19 February 2024 (UTC)

 Done   ~ Tom.Reding (talk ⋅dgaf)  13:42, 19 February 2024 (UTC)

Format change

@Jts1882 and Tom.Reding: Currently, when there are 2 or more QIDs, or if the single QID automatically pulls in a synonym, the taxonbar heading is "Taxon identifiers" and the taxa are listed to the left of their IDs. When there is a single QID that doesn't pull in a synonym, the heading is the same and there is no taxa listed to the left, just the list of IDs. I propose that for the single no synonym format, the heading is changed to "Taxon identifiers for <taxon>", where <taxon> gets filled in the way the multiple taxa format pulls in the taxa. This would make it easier to eyeball when the included QID matches the article's taxon, without having to click into the QID itself. I'm open to other ways of displaying the taxon, such as making the single no synonym format the same as the multiple taxa format, but I figured there's a reason for the difference in format to begin with. - UtherSRG (talk) 14:36, 7 March 2024 (UTC)

@UtherSRG: can you give examples for each case?   ~ Tom.Reding (talk ⋅dgaf)  14:40, 7 March 2024 (UTC)
Yes. Bathymophila micans now currently has the multiple format. Look back one edit and you can see the single format. - UtherSRG (talk) 14:44, 7 March 2024 (UTC)
I mispoke: The single no synonym has "Taxon identifiers" to the left instead of as a heading. - UtherSRG (talk) 14:42, 7 March 2024 (UTC)
It might be better to always have "Taxon identifiers" as a header and the taxon name to the left. I don't think saving the space for the header on single entries is needed. —  Jts1882 | talk  15:04, 7 March 2024 (UTC)
I'm good with that. - UtherSRG (talk) 15:12, 7 March 2024 (UTC)
What about showing the taxon name and the header for 1-item taxonbars if and only if the Wikidata label doesn't match Wikipedia's title? If Wikidata = Wikipedia, then there would be no change from current behavior.
But I'm good with always-show-headings-and-taxons too.   ~ Tom.Reding (talk ⋅dgaf)  19:54, 7 March 2024 (UTC)
When the taxonbar shows "Taxon identifiers for <taxon>", <taxon> is the taxon name property (P225), not the Wikidata label. Wikipedia titles may be vernacular names or have disambiguation that leads to them not matching P225 (titles may not match the labels either, e.g. Wikidata labels for birds are mostly vernacular names capitalized in the IOC format).
I don't see any reason to show <taxon> only when it doesn't match the Wikipedia title, as there will always be a large number of cases where it doesn't match (vernacular names and disambiguation) but nothing is wrong with the QID. Plantdrew (talk) 21:38, 7 March 2024 (UTC)
My thoughts exactly. - UtherSRG (talk) 01:42, 8 March 2024 (UTC)
@Jts1882: I'm not very familiar with the navbox module, and my 0th order solution didn't work in the sandbox. If you or anyone else want to try, please go ahead.   ~ Tom.Reding (talk ⋅dgaf)  15:04, 8 March 2024 (UTC)
I'll have a proper look later, but a quick look suggests changing line 628 from if rowCount > 1 then to if rowCount >= 1 then does the trick, although it leaves redundant code. —  Jts1882 | talk  16:01, 8 March 2024 (UTC)
I thought so too at first, but then there will be a dangling conditional that will never be checked for (elseif parentArgs['noTitle'..firstRow]). I figured it safest to only change the last 'else' catch-all for the rowCount == 1 case.   ~ Tom.Reding (talk ⋅dgaf)  16:23, 8 March 2024 (UTC)
Turns out that elseif is pretty important... Looks to be working now!   ~ Tom.Reding (talk ⋅dgaf)  16:36, 8 March 2024 (UTC)
Looks like it is still doing one format for single-no-synonym, and another for multiple. - UtherSRG (talk) 17:02, 8 March 2024 (UTC)
 Now live   ~ Tom.Reding (talk ⋅dgaf)  20:46, 8 March 2024 (UTC)
Ah! So it is! Many thanks! This will help with fixing the desync'd. - UtherSRG (talk) 22:44, 8 March 2024 (UTC)
What's up with this example from {{Taxonbar/testcases3}}?
Taxonbar: {{Taxonbar|for=Citrullus lanatus var. lanatus|from=Q29401270}}
I don't understand what's going on, although changing |from= to |from2= fixes it.
Is parameter |for= used in articles or just for testing? —  Jts1882 | talk  11:13, 9 March 2024 (UTC)
I think just for testing/demos. - UtherSRG (talk) 12:11, 9 March 2024 (UTC)
@Jts1882: that's a legacy testcase from Template:Taxonbar/testcases originally added in 2017, before |from= and when |for= was being used (either purposefully or accidentally, idr).   ~ Tom.Reding (talk ⋅dgaf)  20:08, 12 March 2024 (UTC)

Updating Wikidata so synonyms appear automatically in taxonbar

What's the right way to do this? I know I've seen taxonbars automatically pull one or more additional IDs from Wikidata; I've just been manually adding |from#= to the taxonbar but I'd like to upgrade my taxon-fu... - UtherSRG (talk) 12:04, 6 February 2024 (UTC)

It does, or should, automatically add the basionym and original combination. After getting the |from= parameters,the code in Module:Taxonbar has the following blocks:
  • --Append basionym to arg list, if not already provided (lines 330-350)
  • --Append original combination to arg list, if not already provided (lines 352-372)
  • --Append monotypic genus/species to arg list of monotypic species/genus, if not already provided
  • --Setup navbox
I'm reluctant to touch the main loops, but if there is another wikidata synonym you want to add, adding an additional synonym block modelled on the basionym block should be possible. Is there a particular example you have in mind? —  Jts1882 | talk  13:51, 6 February 2024 (UTC)
I meant on the Wikidata side, not the taxonbar side. Ok. I think basionym is the tag I'm looking for over there. Thanks! - UtherSRG (talk) 13:56, 6 February 2024 (UTC)
Oops, misread that. The code blocks look for has basionym (P566) and original combination (P1403). —  Jts1882 | talk  14:05, 6 February 2024 (UTC)
I should be able to cut this list down to a small handful in just a few days with this info, right? ;) - UtherSRG (talk) 14:11, 6 February 2024 (UTC)
Does it also grab taxonomic type (P427) for monotypics? - UtherSRG (talk) 14:12, 6 February 2024 (UTC)
Just tested and it does not. What's the right way to get monotypics to show? (Testing with Aaata (Q15732490).) - UtherSRG (talk) 14:14, 6 February 2024 (UTC)
Looks like there is a TODO block (lines 423-429) for that. It has detected an instance of monotypic taxon with rank = genus. It has the comment "is monotypic genus; add species (no way to easily find these (yet?))", but the taxonomic type would do it, at least for Aaata (Q15732490). —  Jts1882 | talk  14:37, 6 February 2024 (UTC)
Yeah, I added the taxo-type to Aaata. Ok. Do you have bandwidth to complete the TODO? - UtherSRG (talk) 14:40, 6 February 2024 (UTC)
Possibly, but Tom.Reding is on top of this sort of thing. —  Jts1882 | talk 
It should probably also pull from taxon synonym (P1420), but it's not even pulling from has basionym (P566) (testing with Abarema zolleriana (Q52626871)). - UtherSRG (talk) 14:58, 6 February 2024 (UTC)
@UtherSRG: has basionym (P566) are only pulled from a page's linked wikidata item, in this case Abarema zollerana (Q4663507) (no basionym available), and not Abarema zolleriana (Q52626871) (basionym available).   ~ Tom.Reding (talk ⋅dgaf)  15:23, 6 February 2024 (UTC)
Abarema zolleriana (Q52626871) has a has basionym (P566) of Pithecellobium zollerianum (Q39105392) and a taxon synonym (P1420) of Abarema zollerana (Q4663507). We get neither in the taxonbar automatically. I think we should get both, or at the very least the taxon synonym (P1420). Or are we specifically limiting this for some reason? - UtherSRG (talk) 15:42, 6 February 2024 (UTC)
Oh wait... linked data item. Yes, ok. I changed the linked item and the basionym comes through now. Ok. Whew! :) So yeah, how about the P1420? - UtherSRG (talk) 15:56, 6 February 2024 (UTC)
@UtherSRG: for taxon synonym (P1420), see the Template:Taxonbar#Module editing — to-don't list :)   ~ Tom.Reding (talk ⋅dgaf)  16:08, 6 February 2024 (UTC)
Specifically denied. Alrighty then. What about the TODO block for lines 423-429 to grab monotypics? - UtherSRG (talk) 16:11, 6 February 2024 (UTC)
 Done! Thanks Jts1882 & UtherSRG! I've been waiting 6 years to add that functionality! I wonder why taxonomic type (P427) took so long to discover...   ~ Tom.Reding (talk ⋅dgaf)  17:48, 6 February 2024 (UTC)
Faboo! :) Just tested on Aaata. Mostly a success! :) Aaata is monotypic, and now its only species automatically shows up. However, the species has an original combination, and that does not show up automatically. Should it? Could it? Would you? Could you? - UtherSRG (talk) 17:55, 6 February 2024 (UTC)
@UtherSRG: we don't add has basionym (P566) nor original combination (P1403) from non-wikidata-linked items, presumably because that would inflate the taxonbar size. It can be done, of course, if there's broad consensus to do so.   ~ Tom.Reding (talk ⋅dgaf)  18:10, 6 February 2024 (UTC)
Right, but if the article were Aaata finchi, they would be added, but because the genus is monotypic, they aren't added. I understand there must be a cut-off at some point, but I think for a monotypic it make sense. I would certainly say "no" to pulling in all synonyms automagically, but the original combination (or basionym) for a monotypic's type seems the right boundary to set. - UtherSRG (talk) 18:33, 6 February 2024 (UTC)

@UtherSRG: I don't think it's necessary, nor advantageous, to remove the now-automatically-added monotype. We use |from= as a hedge against random wikidata bots accidentally (usually) unlinking or changing wikidata's links to the wikipedia page. |from2= serves the same purpose now with the monotypic species/genera.   ~ Tom.Reding (talk ⋅dgaf)  18:21, 6 February 2024 (UTC)

Fair enough. Will auto-added IDs be caught in a cleanup category so we can manually add them? - UtherSRG (talk) 18:35, 6 February 2024 (UTC)
@UtherSRG: thank you! All pages in Category:Taxonbars with automatically added monotypic species (0) / Category:Taxonbars with automatically added monotypic genera (0) should also belong to Category:Taxonbars with multiple manual Wikidata items (18,984) once they have their monotype added to (typically) |from2=. This isn't a perfect filter though, since there can be a "random" ID in |from2= or |fromX= (it doesn't matter which |fromX= the monotype is in), so I'm thinking of creating something like Category:Taxonbars of monotypic taxa missing from2. What do you think about extending what we've done here to monotypic families? How high in rank should we go? Should the check always be from parent to child? Category:Taxonbars with automatically added monotypic genera (0) might have to be repurposed to mean families with automatically added monotypic genera, as opposed to its current (empty) usage, or continue to use it as an error tracking cat (it had many pages in it when it was first made)? Will probably let this stew here for a bit here for more input.   ~ Tom.Reding (talk ⋅dgaf)  19:16, 6 February 2024 (UTC)
As I said in a recent edit summary: "It's froms all the way down!" :) Yes, I think we should extend the concept. And now I fully understand why species articles in monotypic genera are moved to the genus name. Yes, we should only check from parent to child, and multi-monotypics (what a concept!) should be moved to the highest rank in the monotypic chain. (I think my recent edit was to a genus with one species that is the only genus in the family... so that should be at the family name but is currently at the genus name...) - UtherSRG (talk) 19:21, 6 February 2024 (UTC)
Is it a given that in chains of monotypic taxa, the article should be at the highest-ranked monotypic taxon? I remember a move request some time ago where the genus name was determined (via google n-gram search or something) to be more commonly used/well known than the family name, so the taxon was placed at the genus. Esculenta (talk) 18:15, 7 February 2024 (UTC)
Ugh. We might have to make a MOS for this. Barring that, we might have to search both up and down the tree. But you are correct, community discussions can overrule formal logic. ;) - UtherSRG (talk) 18:17, 7 February 2024 (UTC)
WP:MONOTYPICFLORA and WP:MONOTYPICFAUNA both say that monotypic families should be covered in an article using the genus title. Of the pages in the category tree Category:Monogeneric families, 1116 are redirects and 98 are articles. Plantdrew (talk) 22:04, 8 February 2024 (UTC)
The community has spoken! XD Ok, we will have to search both up and down. - UtherSRG (talk) 23:53, 8 February 2024 (UTC)

@UtherSRG: what I gather from what Jts1882 said there, Aptenoperissus here (Aptenoperissus is a genus of extinct wasp with eight described species, placed into the monotypic family Aptenoperissidae), and the description for monotypic fossil taxon (Q47487597) (extinct taxonomic group which contains only one immediately subordinate taxon), is that the family should be tagged as mono, but not the genus. My comment there was made assuming all mentioned ranks were mono, but that isn't the case.   ~ Tom.Reding (talk ⋅dgaf)  19:52, 29 February 2024 (UTC)

Yup. Got it. Now... how can I find all the places (and it's a bunch) where I did it wrong. This was the only family/genus pair, but I have a bunch of genus/species pairs where I did the same thing. - UtherSRG (talk) 03:12, 1 March 2024 (UTC)
Search your user contributions on Wikidata for "monotypic" or "monotypic taxon" (76 and 49 matches, respectively, in last 500 edits). —  Jts1882 | talk  09:20, 1 March 2024 (UTC)
I know how to look at my contributions, but when I put anything into the tag bar, I don't get anything back. I can do a simple ctrl-f search, but all that does is highlight the word in my contributions. Is there a search function that will get me only the contributions that have the word "monotypic" in them? - UtherSRG (talk) 11:54, 1 March 2024 (UTC)

@Jts1882 and Tom.Reding: Ok, I remember why I thought both parent of child should be using one of the monotypic QID's... Category:Taxonbars of monotypic genera missing species explicitly says that they should. It lists four possible changes to make to depopulate an item from the category. I propose removing the genus's taxonomic type (P427) Wikidata item is not specified as an instance of (P31) monotypic taxon (Q310890) nor monotypic fossil taxon (Q47487597), and should be labeled as such from the category, and whatever code in the taxonbar checks the child item modified so that it doesn't have to have to be a monotypic QID. I started this part of the conversation on the category's talk, but Tom rightly suggested I bring the conversation here. He also said we should just get rid of the whole category altogether. I think the concept of the category is good, but I'm not sure how to properly implement it. I suppose, check that the child is listed as "subject has role" "nomenclatural type of" the parent? - UtherSRG (talk) 23:06, 12 March 2024 (UTC)

A type species does not need to be an accepted name; it may be a synonym of another species in the genus it typifies (this is true for at least the ICNafp, but I believe is true for all codes); Psilurus and Oxyrhachis are two monotypic examples. That seems really bizarre and unintuitive when it comes to a monotypic genus, but makes more sense if you consider possibilities in polytypic genera (a taxonomist with local pride describes a new polytypic genus designating a type species that is endemic to where they live; taxonomists living elsewhere consider the "endemic" to be a subspecies at best). It would be worth including a synonymous type in the taxonbar for a monotypic genus, but I guess that wouldn't solve the problem here.
Also, it isn't wrong (as far as the codes are concerned) to present a type species in its original combination. Dissochondrus lists the type species as Setaria biflora; Ixophorus lists the type species as Urochloa uniseta. Tropicos is inconsistent with Dissochondrus (type Dissochondrus bifidus) and Ixophorus] (type Urochloa uniseta), and I'm pretty shocked to have discovered that just now. I've known Wikipedia wasn't consistent in presenting type species as either original/current combinations, but hadn't considered that taxonomic databases might not be. Plantdrew (talk) 02:17, 13 March 2024 (UTC)
Apologies, that was a digression. But I don't think Wikidata has a sufficiently consistently populated properties revolving around monotypy or typification to make editing Wikidata the preferred way to resolve tracking categories related to a template (this one, Taxonbar) on English Wikipedia. If somebody (is that you, UtherSRG?) wants to work on consistently populating Wikidata properties resolving around monotypy or typification, go for it. But if a template tracking category is creating a "problem" on English Wikipedia that editors here are tempted to devote a lot of effort towards resolving (with the actual problem being tiny in the grand scheme of things), we could just drop the tracking category. Plantdrew (talk) 02:27, 13 March 2024 (UTC)
Taxonbar relies (almost?) entirely upon Wikidata, and it populates some categories to call out potential problems in both Wikipedia articles (related to taxoboxes and taxonbars) and Wikidata. I've been using some of those categories to direct my efforts. One category's description (the one I call out) led me to doing the wrong thing on Wikidata. I'm trying to find a path forward where the category can remain useful, while not leading me or others into doing something incorrect. - UtherSRG (talk) 10:46, 13 March 2024 (UTC)
Looking at the code that sets Category:Taxonbars with automatically added monotypic genera and Category:Taxonbars of monotypic species missing genera (lines 389-425), it checks an item is an instance of monotypic taxon (Q310890) or monotypic fossil taxon (Q47487597) then gets taxon rank (P105). If that is a species it gets the parent taxon (P171) and if a genus checks if it is monotypic, in which case it adds the new item for the taxonbar and the former category. If not it adds the second category. At least this is how I read the code.
My question is why is this check only done if the species is monotypic? If the species has several infraspecies, the check for monotypic genus parent would be just as useful. Could this be where the confusion came from matching monotypic species with monotypic genus? —  Jts1882 | talk  15:11, 13 March 2024 (UTC)
That may be where the wording on the category comes from. It's wrong. For "monotypic genera missing species" I think it should be:
  • Is this ID a monotypic? - if no, move on. If yes, then
    • Is this ID a genus? - if no, move on. If yes, then
      • Does this ID's taxonomic type have this ID as the nomenclatural type of? - if no, add the category
      • Does this ID's taxonomic type have this ID as its parent? - if no, add the category
The Category:Taxonbars of monotypic species missing genera should probably be removed - this category doesn't make sense. - UtherSRG (talk) 15:33, 13 March 2024 (UTC)
That all said... I wonder if we should care if the ID is a genus. Perhaps we should only care that it is a monotypic and change the cat to Category:Taxonbars of monotypic taxa missing child taxa or something similar. - UtherSRG (talk) 15:36, 13 March 2024 (UTC)

Fossilworks

Fossilworks appears to be dead. (The same id normally works for the Paleobiology database.) I suggest that Fossilworks is removed from the list of taxon identifiers picked up by the taxonbar template. Peter coxhead (talk) 17:57, 30 March 2024 (UTC)

Monster Iestyn started a discussion in the Paleobiology project talk page (Wikipedia_talk:WikiProject_Palaeontology#Fossilworks_and_Paleobiology_Database_(PBDB),_revisited) and at Wikidata (Wikiproject Taxonomy on Wikidata).
Fossilworks has gone down before but it does seem that it's no longer updated on a regular basis (despite the claim of a daily synch with the Paleobiology database).
PBDB doesn't have many entries on wikidata, so we could consider using the wikidata identifiers for Fossilworks to link to PBDB (via the module) or Wikidata may make appropriate changes at their end. —  Jts1882 | talk  18:25, 30 March 2024 (UTC)
Nothing seems to be happening over at Wikidata, so I wonder if we can make a fix here? Peter coxhead (talk) 14:32, 31 March 2024 (UTC)
What logic do we use? We want to use the Fossilworks ID with the PBDB link. It's easy to substitute the link for the fossilworks item, as I've done with this edit in the sandbox. And this edit changes the database displayed to "Fossilworks/PBDB" (this text is just for testing and can be done in Module:Taxonbar/conf). You can check the results in {{taxonbar/testcases}}. However, we also want to prevent duplicates when both fossilworks and PBDB have identifiers. —  Jts1882 | talk  16:52, 31 March 2024 (UTC)
This plus preventing duplicates definitely seems the way forward to me. Peter coxhead (talk) 06:54, 1 April 2024 (UTC)
Done in sandbox. Fossilworks has been moved in /conf file until just after PaleobioDB and linked to PaleoDB instead of Fossilworks (currently there are duplicates in live version). In the sandbox version the two entries are compared and the fossilworks one deleted if the same. Strangely the testcases uses lion, which has two entries in PBDB, and the fossilworks and PaleobioDB wikidata items return different ones. These are both displayed. Should one be deleted as the records are identical? —  Jts1882 | talk  07:53, 1 April 2024 (UTC)
Now live. In {{taxonbar/testcases}}, Canis lupus picks up PaleobioDB identifier from fossilworks entry on Wikidata, Bornean orangtang and Puma have duplicate deleted, and lion shows both values as different. —  Jts1882 | talk  08:17, 1 April 2024 (UTC)

'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.[1]

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 | 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 | talk  10:53, 11 April 2024 (UTC)
I'm trying in Module:Taxonbar/exists/sandbox, but I'm unable to match <!-- for some reason... Can anyone help? See line 17 & 20 there, and Template:Taxonbar/exists/testcases/true#True.   ~ Tom.Reding (talk ⋅dgaf)  14:06, 16 April 2024 (UTC)
Don't you need braces and spaces to check before: local v_cmt_before = '%<%!%-%-%s*%{%{'..v? —  Jts1882 | talk  14:28, 16 April 2024 (UTC)
@Jts1882: not for the current testcase, which has <!--{{Taxonbar}}--> for simplicity, and braces don't need escaping in Lua (since generalized finite quantifiers {n,m} don't exist in this implementation). Regardless, I found the problem. I was using .baseText for the pagename, 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)
@William Avery and Jts1882:  Done! 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)
@Tom.Reding: I think line 10 needs deleting. —  Jts1882 | talk  11:14, 18 April 2024 (UTC)
 Oops   ~ 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#Automatic links to species, commons, data. Taxonbar uses Navbox and for some reason this is disabled on mobile. Anything using class="navbox" 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: {{Taxonbar/sandbox|from=Q11847339|from2=Q593398|format=pseudo-taxonbar}}
Pterorana
Amphidiaceae
  • Standard taxonbar for comparison: {{Taxonbar|from=Q11847339|from2=Q593398}}


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 | 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 T124168. 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 <div> 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 display:grid which I've implemented using templatestyles.
  • Mobile compatible taxonbar (using grid and divs): {{Taxonbar/sandbox|from=Q11847339|from2=Q593398|format=grid-taxonbar}}
Pterorana
Amphidiaceae
  • Standard taxonbar for comparison: {{Taxonbar|from=Q11847339|from2=Q593398}}
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 | talk  16:57, 25 April 2024 (UTC)
Retrieved from "https://wiki.riteme.site/w/index.php?title=Template_talk:Taxonbar/Archive_8&oldid=1257415291"