Template talk:Taxonbar

{{Taxonbar}} (edit talk history links # /subpages /doc /doc edit /sbox /sbox diff /test)

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}}

Taxon identifiers
Pterorana	Wikidata: Q11847339 Wikispecies: Pterorana ASW: Pterorana CoL: 642TW EoL: 103550 GBIF: 2426818 iNaturalist: 26276 IRMNG: 1289159 ITIS: 661533 NCBI: 685169
Pterorana khare	Wikidata: Q593398 Wikispecies: Pterorana khare AmphibiaWeb: 5068 AoI: 328 ARKive: pterorana-khare ASW: Pterorana-khare CoL: 4Q356 EoL: 1039191 GBIF: 2426819 iNaturalist: 26277 IRMNG: 11425915 ITIS: 665203 IUCN: 58488 NCBI: 877586 Observation.org: 205301 Open Tree of Life: 3618409 uBio: 4801185

• 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}}

Taxon identifiers

Pterorana

• Wikidata: Q11847339
• Wikispecies: Pterorana
• ASW: Pterorana
• CoL: 642TW
• EoL: 103550
• GBIF: 2426818
• iNaturalist: 26276
• IRMNG: 1289159
• ITIS: 661533
• NCBI: 685169

Pterorana khare

• Wikidata: Q593398
• Wikispecies: Pterorana khare
• AmphibiaWeb: 5068
• AoI: 328
• ARKive: pterorana-khare
• ASW: Pterorana-khare
• CoL: 4Q356
• EoL: 1039191
• GBIF: 2426819
• iNaturalist: 26277
• IRMNG: 11425915
• ITIS: 665203
• IUCN: 58488
• NCBI: 877586
• Observation.org: 205301
• Open Tree of Life: 3618409
• uBio: 4801185

• 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)

"nomenclatural type of" usage being frowned upon

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

@UtherSRG:, while I'm not sure exactly what a inverse property label item (Q65932995) 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 natural product of taxon (P1582) and this taxon is source of (P1672); 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 taxonomic type (P427). 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.

monotypic taxon (Q310890) 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 Jts1882 (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 Tom.Reding implemented this. Looking at the code, it retrieves taxonomic type (P427) for monotypic genera and checks whether it is monotypic taxon (Q310890) or monotypic fossil taxon (Q47487597), in which case it is accepted. I don't see a use of nomenclatural type of (Q116044186) or nomenclatural type (Q116538381) so I'm confused about what the issue is about. —  Jts1882 | 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 taxonomic type (P427) examples include a type specimen. Perhaps check that the item is a taxon name and has the monotypic genus as its parent. —  Jts1882 | talk  08:46, 1 May 2024 (UTC)

Going back to Plantdrew's post above, I agree that we should not be using monotypic taxon (Q310890) 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 | talk  08:46, 1 May 2024 (UTC)