Jump to content

Template talk:Taxonbar

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

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

Taxonbar for mobile

[edit]

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
Pterorana khare
  • 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)[reply]

Looks good! Whom can we ask about the potential policy issue? - UtherSRG (talk) 12:44, 25 April 2024 (UTC)[reply]
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
Pterorana khare
  • 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)[reply]

"nomenclatural type of" usage being frowned upon

[edit]

@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)[reply]

@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)[reply]
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)[reply]
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)[reply]
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)[reply]
No one answered this, but I think checking that monotypic genus has a taxonomic type (P427) 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 | talk  13:35, 3 May 2024 (UTC)[reply]
@Tom.Reding: This is my suggestion. —  Jts1882 | talk  14:23, 3 May 2024 (UTC)[reply]
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)[reply]
The taxonbar is looking for alternative treatments, so this might not be a problem. —  Jts1882 | talk  08:46, 1 May 2024 (UTC)[reply]
This is in regards to how to populate these tracking categories:
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. Jts1882 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 Peter coxhead'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 nomenclatural type of (Q116044186) to nomenclatural type (Q116538381)? Add a new property that is the inverse of taxonomic type (P427)? 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: |monotypic_parentN=x and |monotypic_childN=x 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 fromN field fills this role. For instance: {{Taxonbar|from1=Q123|from2=Q456|monotypic_parent1=1|monotypic_child1=2}} 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:
  1. 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.
  2. 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:
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)[reply]
The biggest hurdle is going from parent -> child in Wikidata. If taxonomic type (P427) 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)[reply]
taxonomic type (P427) 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)[reply]
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)[reply]
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)[reply]
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)[reply]
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 | talk  13:37, 3 May 2024 (UTC)[reply]
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)[reply]
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 taxonomic type (P427) 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)[reply]
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)[reply]
My test for the parent taxon would ensure the genus matches. —  Jts1882 | talk  14:53, 3 May 2024 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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 monotypic taxon (Q310890) 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)[reply]
monotypic taxon (Q310890) is not a property, so its functionality is different, and still useful, e.g. instance of (P31) -> monotypic taxon (Q310890). 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)[reply]
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)[reply]
Can you link to that/those discussion/s? There are 10,749 instance of (P31) -> monotypic taxon (Q310890), 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)[reply]
I was squashed for using monotypic taxon (Q310890) 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)[reply]
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 | talk  16:10, 3 May 2024 (UTC)[reply]
"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 parent taxon (P171) 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)[reply]
@Jts1882: what do you think?   ~ Tom.Reding (talk ⋅dgaf)  14:44, 9 May 2024 (UTC)[reply]
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 giraffe (Q15083)). 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 | talk  14:58, 9 May 2024 (UTC)[reply]

@Jts1882: 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 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)[reply]

@Peter coxhead: 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)[reply]
@UtherSRG: 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 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 Mexerion (Q6825725) 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)[reply]
[edit]

In some recent edits to Gerbe's vole‎, I moved the en-lang link from the synonym Wikidata item to the Wikidata item that matches the current best scientific name for this species. However, the vast majority of other language wikis are listed on that synonym. Doing this removes all of those language links from our article. I know this isn't a problem with the taxonbar itself, but I stumbled upon it when updating the taxonbar's fields. Where can I bring up this issue so that more knowledgeable folks than I can craft a solution (which may or may not involve taxonbar Module code)?

My thoughts on what I think should be the solution should be something similar to how the taxonbar decides which taxa to display: the sidebar should check up and down the Wikidata item's various possible synonym pointers to gather all the possible language links. (E.g. if the Wikidata item has a "basionym" field, it should include that item's language links in the list of links to display.) - UtherSRG (talk) 11:35, 15 August 2024 (UTC)[reply]

Gerbe's vole is a very unusual case. Microtus pyrenaicus/Arvicola pyrenaicus is listed as a nomen dubium in ITIS and MSW3, and IUCN has a note that says there is debate about whether pyrenaicus or gerbei is the appropriate name (the IUCN page gives MDD as the taxonomic source as of May 2022, and uses the spelling gerbii, so apparently MDD has changed in the last two years). pyrenaicus clearly has priority if it is not a nomen dubium.
This is definitely more of a Wikidata issue than a Taxonbar issue. Wikidata's procedure has been to have all of the inter-language links on a single item, and as far as I am aware, there has been no further discussion about how to handle things since Wikidata started allowing links to redirects.
The most typical case of interwiki links to different scientific names is when different Wikipedia editions treat the same species in different genera. Differences in how Wikipedia editions lump/split species aren't handled well by putting all the links on a single item, and I don't think that is actually common practice on Wikidata. Differences in what species epithet is used for what is clearly the same taxon isn't a common enough scenario for me to expect that Wikidata has a well-developed procedure for dealing with it.
I've linked the Wikidata item for Microtus gerbei to the redirect Microtus gerbei. That enables people reading non-English editions of Wikipedia to get to the English article. While English Wikipedia aren't always the best developed article in any language, they often are. I suspect more people who are reading a Wikipedia article are going to want to go from a non-English version to the English version than are going to want to go from a English version to a non-English version. Plantdrew (talk) 15:48, 15 August 2024 (UTC)[reply]
Gerbe's vole is not the issue. The issue is how to get the interwiki links from a synonym into the sideboard of the article. The genus Astur has been resurrected, and articles like Black sparrowhawk now no longer have interwiki links, including species and commons, on the sideboard, because the old Wikidata taxa item has them and it is not appropriate to move them to the new Wikidata item until each of those other-lang and sister sites are updated. And yes, I know it isn't a taxonbar issue. I stated that: I know this isn't a problem with the taxonbar itself, but that doesn't mean I won't find some of the right folks here to think about a solution, or be pointed to a better venue. Gerbe's vole wasn't the first occurrence, just where I first thought about raising the issue. Astur won't be the last it happens. While I agree that, in general, the en-lang article is the better written one, but that's not always the case, and Species and Commons Category are incomparable. At the very least, this should be addressed in some manner to get Species and CC info into the sideboard, and the solution should also provide an other-lang solution as well. - UtherSRG (talk) 12:09, 23 August 2024 (UTC)[reply]
@UtherSRG: as far as I know, the left-hand sidebar cannot be accessed or changed by editors, so you would have to raise an issue at the MediaWiki level. However, I doubt that it would make sense to make a change to collect language links to taxon synonyms. Maybe to all redirects, now that Wikidata allows connections to redirects. Peter coxhead (talk) 06:35, 24 August 2024 (UTC)[reply]
It should be possible to change the sidebar using a script, but this would be opt in only and not available to everyone.
A number of now Tachyspiza species will have the same problem (e.g. Levant sparrowhawk). Either MediaWiki change the requirement for a one-to-one relationship for sitelinks or Wikidata changes their taxonomy and allows more than one taxon name for a "taxon" such as the Levant sparrowhawk.  —  Jts1882 | talk  13:47, 24 August 2024 (UTC)[reply]
The Wikidata issue remains that described at user:Peter coxhead/Wikidata issues#Confusion between taxa and taxon names, namely that to set up sitelinks in the way UtherSRG wants requires modelling taxa rather than taxon names. I suspect that this is not possible within Wikidata while maintaining the required neutrality among different taxonomic opinions when these are adopted by different language wikis. Certainly no-one has yet shown how to do it.
If our article is connected on Wikidata to a redirect in another language wiki, it would be easy for the MediaWiki software to show a link to that redirect or even the target article, instead of ignoring redirects as now. This wouldn't entirely solve the problem because the other language wiki may not have a redirect to connect to via Wikidata, but it would help. Peter coxhead (talk) 20:36, 24 August 2024 (UTC)[reply]
The problem is that Wikidata items don’t completely correspond to taxa or taxon names, it’s more a hybrid. A taxon name can’t be used more than once for different treatments, which would be the case if each item dealt with a taxon. Yet taxon names don’t have child-parent relationships or distributions or conservation statuses.
What do you do when a bird like the Black-headed_bulbul is currently treated as three different scientific names by different: Brachypodius atriceps [Birdlife], Brachypodius melanocephalos [IOC], and 'Microtarsus melanocephalos [BOW/eBird]. The standard treatment has been to have different items on the taxon names with appropriate synonym statements, and these different items were picked up by the {{taxonbar}}. In this case (and two others) someone has merged the Wikidata items for the first two names (into Brachypodius atriceps (Q28873180) and made Brachypodius melanocephalos (Q98069319) a redirect) and gives the item two taxon names. This would be the way to treat the item as a taxon and solves the sitelink issue. However, it raises an error “This property should contain a single “best” value with the same set of qualifiers for these properties”, although we cannot choose a preferred name as the three are currently used by different authorities.
I’ve reversed the merge, as such treatment makes a mess of the taxonbar, which has been designed to work with the Wikidata treatments. Similar mergers were made for Grey-capped Woodpecker (Grey-capped Woodpecker (Q39277), merged with Grey-capped Woodpecker (Q26937878)) and Pale Blue Flycatcher ((Pale Blue Flycatcher (Q73925), merged with Niltava unicolor (Q15233019)).
Another problematic bird is the Blue-wattled Bulbul, which has two Wikidata items: one at the scientific name (wdq|Q98069651}} and one at the common name (Blue-wattled Bulbul (Q2927920)). The sitelinks are split between the two (15 to the common name and 6 to the scientific name). This should certainly be merged, but raises an issue about the Wikidata item titles. As Wikidata items can only have one preferred taxon name (which can only be used for one item), I think an item that is instance of taxon should always be labelled with the scientific name, with common names in the also known as section.  —  Jts1882 | talk  12:22, 26 August 2024 (UTC)[reply]

Misspelling of Panarctic as Panartic in Module:Taxonbar/conf

[edit]

"Panarctic" is misspelled as "Panartic".

{ 'Panartic', 'Panartic Flora', 2434 }, ---[[Panartic Flora]] DNE as of 3/2023

should be

{ 'Panarctic', 'Panarctic Flora', 2434 }, ---[[Panarctic Flora]] DNE as of 3/2023

– Elizabeth (Eewilson) (tag or ping me) (talk) 22:09, 13 November 2024 (UTC)[reply]

Fixed. - UtherSRG (talk) 00:09, 14 November 2024 (UTC)[reply]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Template_talk:Taxonbar&oldid=1257248925"