Template talk:Taxonbar/Archive 6

This is an archive of past discussions about Template:Taxonbar. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

Archive 1

←

Archive 4

Removing Wikispecies as a taxon identifier

This was discussed last year, but didn't reach any consensus. I still feel strongly that links to Wikispecies don't belong in this template for the following reasons:

This template is for database identifiers, not just links to any site that has the taxon. It is analogous to the {{Authority control}} template used for people (which doesn't allow adding links to any sister projects).
It is redundant with templates like {{Sister project links}} and {{Wikispecies}} (which unlike this template show up on mobile).

The main objection that was raised last time is that not enough taxon articles are using the sister project templates. This is circular logic though. As long as we keep linking to Wikispecies from this template, people aren't going to add the proper sister project templates instead, because they are redundant. Kaldari (talk) 01:13, 29 April 2020 (UTC)

Would an option be for the template to output the sister project template rather than place the information in the taxonbar? Potential problems are duplication of the {{Wikispecies}} template and mobile view handling, which would work if the taxonbar just isn't displayed, but not if the template isn't processed. — Jts1882 | talk 08:16, 18 May 2020 (UTC)

I'm afraid that would cause duplication of the {{Wikispecies}} template on articles that had both (as you mention). Kaldari (talk) 06:22, 30 June 2020 (UTC)

One solution would be for {{taxonbar}} to check the page for {{Wikispecies}} and only output it if not called independently. This would add substantial overhead, though, so is probably not a good solution and might not solve the mobile problem.

While I can see the logic of exclusion, from a practical point of view I like wikispecies in the taxonbar. It's where I go when I want extra taxonomic information. — Jts1882 | talk 07:15, 30 June 2020 (UTC)

I never add the wikispecies template to an article I create, and often remove it from taxon articles that I edit substantially. It's redundant to the entry in the taxonbar, which is a better place for all links to relevant taxonomic information, not just those with distinct taxon ids – it's a taxonbar, not a taxonIDbar. I've not yet had anyone object to my edits. However, there doesn't seem to be a consensus either way, so we have to live with variation between articles based on editor preference. Peter coxhead (talk) 09:12, 30 June 2020 (UTC)

Actually it is a taxonIDbar. The header of the template says "Taxon identifiers", not "Taxon at other websites". Also, the description of the template says "This metadata template links Wikipedia articles to various biological and taxonomic databases. Taxonbar displays these links as short strings, indicating the unique identifier each database has assigned the taxon for catalogue purposes." Furthermore, the template was originally based on {{Authority control}}, which also is for identifiers and doesn't link to sister projects. Fixing this shouldn't be controversial. All we need to do is use the existing templates as they were intended to be used. Kaldari (talk) 23:23, 12 August 2020 (UTC)

I also regularly remove the standalone Wikispecies template. (Aside from being duplicative of the sidebar and taxonbar, it's really just not adding very useful information not already in the article for most cases.) —Hyperik ⌜talk⌟ 00:07, 13 August 2020 (UTC)

"This metadata template links Wikipedia articles to various biological and taxonomic databases." Isn't Wikispecies a taxonomic database that uses the taxon name as the unique identifier? That description seems to support inclusion. Even if the original intent was that Wikimedia sister projects should have been excluded, at this point in time I think it would be disruptive to remove it. — Jts1882 | talk 07:14, 13 August 2020 (UTC)

No, Wikispecies is not a taxonomic database, it's a wiki. And it doesn't have persistent database IDs. Page names on Wikispecies can be changed for any number of reasons including a species changing names or even for disambiguation. There is no intention to "exclude sister projects". For example, including Wikidata makes total sense and is in line with the scope of the template, as a Wikidata Q-id is a persistent unique identifier that can always be used to reference that taxon from another database. You may be under the mistaken idea that this template and {{Authority control}} are simply for collecting external links, but that isn't correct. Kaldari (talk) 20:50, 19 August 2020 (UTC)

Just how persistent do IDs need to be? Several bird databases included in taxonbars use text strings based on vernacular names for their IDs (if they can even be called IDs). Bird vernacular names can change; when a species level split occurs, the vernacular name that was used for the broader species concept is usually deprecated by the entities that define "official" vernacular names for birds. Plantdrew (talk) 21:35, 19 August 2020 (UTC)

Firstly, the heading "Taxon identifiers" is inaccurate. Some of the IDs are taxon identifiers – for example, the World Spider Catalog ID for a species will lead to the same taxon even if it changes its name, which can make it inconsistent, given that the taxonbar may well have another row for the old name. Many (most?) IDs are taxon name identifiers – for example, IPNI is concerned with names, not taxa, and databases like Plants of the World Online that use IPNI identifiers keep them leading to the name, whether or not it is currently accepted. Look at Syrmatium cytisoides for example; the four rows in the taxonbar relate to names; there is only one taxon. So, contrary to what I wrote above and what Kaldari wrote, it's mainly a "taxonnamebar".

Secondly, Wikispecies is very poorly maintained compared to the English Wikipedia, and in areas where taxonomy is changing (most!), its entries can be very out of date and so misleading. It's not a taxonomic database, just another wiki, and I see no reason to treat it any differently. I never add the species template when I create an article. Peter coxhead (talk) 12:43, 20 August 2020 (UTC)

Hmm. Under the status quo there are potentially three ways to get to Wikispecies from a en.wiki taxon article:

Interwiki sidebar; uses Wikidata for link, not shown in mobile view
Taxonbar; uses Wikidata for link, not shown in mobile view
Sister project link templates; rely on title matching or manual specification for link, few articles actually have a sister project link templates, but shown in mobile view

My preference would be to have Wikispecies added to the interwiki side bar in mobile view. I'm not a fan of sister project link templates, but I've devil's-advocated them for mobile visibility. However, devil's-advocating again, taxonbar may be the only way to get to Wikispecies when the en.wiki article and Wikispecies page are linked to different Wikidata items. The only way to get from Clinopodium ascendens to species:Clinopodium menthifolium subsp. ascendens is via an additional taxonbar |from= I just added. If taxonbar doesn't display Wikispecies, I would have to add a sister project link template, which I'm not inclined to do (my motivation for adding the from parameter was to show a bunch of non-Wikispecies databases, but I don't think it's a negative to be able to see how Wikispecies treats it).

In my estimate, taxonbars linking multiple Wikidata items with additional from parameters account for far more of the only links to Wikispecies than sister project link templates with manually specified links. Relying on SPL templates for Wikispecies links is not a good argument for removing Wikispecies from taxonbar. Plantdrew (talk) 02:48, 23 August 2020 (UTC)

This is a good argument (which I had not thought of or seen before) for not using the Wikispecies template, but for linking via the taxonbar. Accessing multiple synonyms via the taxonbar is important, especially since Wikidata foolishly insists on 1:1 links. Peter coxhead (talk) 09:19, 23 August 2020 (UTC)

Deprecated values from wikidata

Is there any reason the Taxonbar displays values for identifiers from Wikidata that are given deprecated rank? For instance, on Adoxini (Q4033416) (a synonym of the tribe Bromiini (Q30233914)) I've modified both its values for Fossilworks taxon ID (P842) and iNaturalist taxon ID (P3151) to have deprecated rank, because they are now obsolete and/or redirect to the corresponding ones for Bromiini. Yet these deprecated identifiers still display on the English Wikipedia page Bromiini (since I have made its taxonbar display identifiers for both Bromiini and its synonym Adoxini).

Similarly, on Bromiini (Q30233914) itself, a while back I ranked its first Fossilworks taxon ID (P842) value as deprecated and added a new up-to-date value with preferred rank (the old value is actually a redirect to the new value), but again, the Wikipedia page displays the first value as if it was still valid. So the Taxonbar does not even give priority to normal/preferred rank values over deprecated values. Can this be changed? Monster Iestyn (talk) 02:10, 12 October 2020 (UTC)

The taxonbar serves to point to external sources with information of relevance to the article. The presence of more than one Wikidata ID means there is some difference of opinion in different sources or they retain something useful (e.g. why the name is invalid). The taxonbar neutrally displays what is on Wikidata. Your examples raise some different issues.

The iNaturalist link on Adoxini does provide additional useful information on why the name swap and why the taxon is no longer used. I'm not convinced marking the iNaturalist ID as deprecated is correct, as it is a valid ID to get current information on an invalid taxon name.
The fossilworks ids all link to the same page so are less useful, but still link to the relevant information on alternative names.
For Bromiini, the fact that the taxonbar selects the first value is more of a issue, although as it links to the same page it is still providing the correct information (the value of the fossilworks ID is not too important per se)

I think some handling for multiple entries is probably warranted (for #3), but the others need further discussion. — Jts1882 | talk 09:02, 12 October 2020 (UTC)

It's worth repeating that the Wikidata items are for names not taxa. If there is any useful information about the name in the database linked via an ID, then it is of some value in the taxonbar. If the database supports the claim that the name/rank/whatever is obsolete or incorrect, then this is useful information. Peter coxhead (talk) 10:09, 12 October 2020 (UTC)

Okay then, thank you for that explanation. To be honest I am still getting used to how Wikidata works so I'm not entirely sure what values should be deprecated or not still. I do think the taxonbar for Bromiini should ideally use the most up-to-date value for Fossilworks at the very least. Monster Iestyn (talk) 14:50, 12 October 2020 (UTC)

@Monster Iestyn: I absolutely agree about including the most up-to-date vslues. If the wrong IDs are attached to the Wikidata item for the taxon nsme, then just correct them over there.

Not to be rude, but ~~this~~ [now below] does seem unrelated to the issues I brought up about deprecated rank values from wikidata. Split this discussion for clarity maybe? Monster Iestyn (talk) 15:45, 14 October 2020 (UTC)

Done Peter coxhead (talk) 16:01, 14 October 2020 (UTC)

Order of names in taxonbar

There is an issue about the order in which synonymous names are shown in the taxonbar. I've tried to work this out from the code, but failed. Sometimes trial-and-error changing of the numbers attached to the from parameters can produce a better order – article title first, etc. Peter coxhead (talk) 19:56, 12 October 2020 (UTC)

@Peter coxhead: do you have a working example of that synonym work-around? Should be fixable, but I'm not sure how complicated it may be or if any negative side-effects. ~ Tom.Reding (talk ⋅dgaf) 20:06, 12 October 2020 (UTC)

My apologies about the watchlist blowup this morning btw, there was a list mis-save on my end. ~ Tom.Reding (talk ⋅dgaf) 20:10, 12 October 2020 (UTC)

@Tom.Reding: look at Vachellia tortilis. We want the name accepted by the article and hence the page title to come first. The way to do this is to start the taxonbar parameters with the Wikidata item for this name at |from2=. It has to be from2 not from1. I suspect that all the articles that have {{taxonbar from2=...}} are workarounds. (I can't remember now from whom I learnt this trick.) If you change the code, either the change mustn't affect all these cases or they all need changing. In all cases, the page title, where this is the scientific name, should come first. Maybe it would be enough to preserve the order of the parameters, regardless of the number attached. Peter coxhead (talk) 20:45, 12 October 2020 (UTC)

@Peter coxhead: ok, just trying to wrap my brain around this (my RAM needs refreshing after hiatus). I think this behavior stems from |from1='s original purpose, and that it's actually working as intended, i.e. to be the current WD link to the page so as to identify future potential desyncs. I could go back to the inception discussions to tease out more nuance, but they were all littered with comments by people who failed (mostly willfully or feigningly after dozens of clear examples) to understand its purpose. Anyway, what I think are the relevant points & observations:

Vachellia tortilis is currently, and somewhat confusingly, linked to Acacia caquilitis (Q1337058), which appears 2nd, as desired.
{{Taxonbar|from2=Q14933877|from1=Q1337058|from3=Q14933879}} &
{{Taxonbar|from1=Q1337058|from2=Q14933877|from3=Q14933879}}
both resolve to identical taxonbars, with Vachellia tortilis (Q14933877) at the top, as desired.
I think this behavior is intentional, to put the QID at the top whose WD page name matches WP's page name, regardless of QID & regardless of from#, as long as the WP-WD link is in |from1=.
1. However, the WP-WD link is currently only considered desynced IIF the QID can't be found in any of the |from#= parameters. There is no tracking category for if/when Vachellia tortilis gets "correctly" (hypothetically) linked to, Mimosa tortilis (Q14933879), and |from1=Q1337058 is mistakenly not updated to |from1=Q14933879.
{{Taxonbar|from2=Q1337058|from1=Q14933877|from3=Q14933879}} &
{{Taxonbar|from1=Q14933877|from2=Q1337058|from3=Q14933879}}
both result with Acacia caquilitis (Q1337058) on top, as undesired, and impossible to find without visual inspection (i.e. no tracking cat).

I would argue that the "correct" taxonbar form is either form represented in item #2 above, which is what's currently at Vachellia tortilis. Were the module recoded for item #3 to produce the output of #2 would be "incorrect" based on the original intent of |from1=, but ultimately up to the visual discretion of the editor, as no maintenance categories would be thrown either way (recoded or not). Do you think there should be a maintenance category thrown for item #3s? ~ Tom.Reding (talk ⋅dgaf) 23:58, 12 October 2020 (UTC)

@Tom.Reding: I don't accept that it's right for the order shown in the taxonbar to pay any attention to which Wikidata item the article is connected to. Because of the well known failure of Wikidata to model taxa and taxon articles correctly (which I have explained in detail at User:Peter coxhead/Wikidata issues), it's essentially arbitrary which synonym in Wikidata links to the article where names have changed recently.

Usually it's whichever synonym currently has the majority use in wikis and hence has the most links. Since there are many fewer editors at most language wikis than here, this is typically not the currently accepted name.
Sometimes the smaller number of up-to-date wikis will be at the currently accepted name, the rest at an older synonym, so that the articles aren't connected.
Sometimes someone will have moved all the links to the currently accepted name, even though few wikis use it. I used to do this at Wikidata, but then saw that a Wikidata editor had undone my move, so I don't do it now unless there are other major wikis using the name (e.g. es, de, or fr). (Some language wikis, like vi, which have scraped taxon articles from databases, typically have separate articles at each synonym, so shouldn't be counted in determining usage.)

I don't know any editor here who wants an older synonym to come first in the taxonbar when we have carefully moved an article to the recently accepted name. The point of putting |from2= first is to demonstrate that this is the order that we want to be used but can't achieve by using |from1=. Why would we want the order in which the synonyms are shown in our taxonbar to change just because links are moved at Wikidata? Peter coxhead (talk) 06:30, 13 October 2020 (UTC)

I've also tried and failed to work out what determines the order in the taxonbar. I would have thought the whole point of |from1=, |from2=, etc. is to allow editors to determine the order rather than an algorithm based of the vagaries of Wikidata. It is counter-intuitive that |from1= doesn't mean that name appears first. Why have numbered parameter names if they don't set the order?

If I understood Tom's explanation above, Vachellia tortilis gives the correct order because the page names match. So what would happen if Vachellia tortilis was moved to a common name and remained linked to Acacia caquilitis (Q1337058) without editing the Wikidata item? Would it fail to match, would the redirect allow the match, or would the WD-WP link need updating? — Jts1882 | talk 09:37, 13 October 2020 (UTC)

@Jts1882: that was not the original intent of |from2+= parameters, and taxon ordering was added after functionality expanded, which isn't to say that the focus can't/shouldn't be made on ordering.

@Peter coxhead: all good points; can start sandboxing in the near future. ~ Tom.Reding (talk ⋅dgaf) 14:35, 13 October 2020 (UTC)

@Peter coxhead & Jts1882:

done. ~ Tom.Reding (talk ⋅dgaf) 15:14, 14 October 2020 (UTC)

@Tom.Reding: thanks! (A search for hastemplate:Taxonbar insource:"taxonbar from2=" suggests there are about 130 taxonbars starting with |from2=. They need manual checking to be sure it was intended as a work-around. I'll work through them, but assistance is welcome!) Peter coxhead (talk) 16:01, 14 October 2020 (UTC)

The current list of 80:

80 from2's needing checking (strikeout if checked)

~ Tom.Reding (talk ⋅dgaf) 21:33, 14 October 2020 (UTC)

All of the original 130-odd that had |from2= first have now been fixed by several editors. A high proportion were those I'd originally set up this way – deliberately so that they could be found by a search. There may, of course, be others where editors didn't use this parameter order, but still meant the |from2= taxon name to come first. Peter coxhead (talk) 21:14, 15 October 2020 (UTC)

@Peter coxhead: I could setup a temporary tracking category for |from2= WD pagenames that match WP. ~ Tom.Reding (talk ⋅dgaf) 21:24, 15 October 2020 (UTC)

@Tom.Reding: that seems a good idea to me. I wouldn't expect too many, but at least we would know. Thanks. Peter coxhead (talk) 05:52, 16 October 2020 (UTC)

@Peter coxhead & Jts1882: Category:Taxonbars with from2 matching article title (518) (currently @ 1,045) has been created & populated via null editing all 6,661 pages in Category:Taxonbars using multiple manual Wikidata items (0). I've saved the starting list of 1,045 pages in case we want to revisit them. ~ Tom.Reding (talk ⋅dgaf) 17:06, 16 October 2020 (UTC)

Note: this list includes automatically added basionyms & original combinations if there is no actual |from2=. This wasn't intentional, but it seems helpful to have. ~ Tom.Reding (talk ⋅dgaf) 17:37, 16 October 2020 (UTC)

As a result, I'm expanding forced population to include Category:Taxonbars with automatically added basionyms‎ (15,434), Category:Taxonbars with automatically added original combinations (13,736), & Category:Taxonbars with automatically added monotypic genera (0). These ~16,300 articles will take a little less than 3 hours to fully update. ~ Tom.Reding (talk ⋅dgaf) 17:47, 16 October 2020 (UTC)

@Tom.Reding: the list of 1,045 pages is more than I expected. Obviously many more editors than I realized were using |from2= as a work-around. I think that where there are explicit |from2= and |from=/|from1= parameters, they should be swapped by some automated task. Peter coxhead (talk) 18:03, 16 October 2020 (UTC)

Sigh... This page, which I've just found, shows why actually automation is a problem; the content of the page had been updated, but the page hadn't been moved. So the taxonbar order was correct; it's the page title that was wrong. Peter coxhead (talk) 18:38, 16 October 2020 (UTC)

More: Cnidoscolus stimulosus

Then there are strange cases like the taxonbar at Galax... Peter coxhead (talk) 18:47, 16 October 2020 (UTC)

A beautiful illustration of why we can't use Wikidata without checking. There are two names, Galax L. which is a rejected name in favour of the conserved name Galax Sims. The two Wikidata items were hopelessly confused between the two, with most of the database IDs, etc. for Galax Sims attached to an item said to be Galax L.. I think I've now managed to sort out Galax (Q14565066) and Galax L. (1753) (Q85939379). Peter coxhead (talk) 06:50, 17 October 2020 (UTC)

I looked at the intersection of Category:Taxonbars with from2 matching article title and Category:Plants (depth 10) with PetScan. It looks to me that the cases that PetScan finds at an intersection like Taxonbars with from2 matching article title|0 ∩ Monotypic plant genera|8 are straightforward, and the swap could be automated (when the database has updated to take account of those I've done with AutoEd). The others aren't always straightforward. Peter coxhead (talk) 19:10, 16 October 2020 (UTC)

Done 175 found in that intersection & all had their |from1/2= swapped. ~ Tom.Reding (talk ⋅dgaf) 22:22, 16 October 2020 (UTC)

@Tom.Reding: great! There were two odd cases left, which I fixed: Galax referred to above, which was a Wikidata muddle, and Hybanthopsis, where the taxonbar had a bad format (extraneous ')'). So on to non-plant articles! Peter coxhead (talk) 06:53, 17 October 2020 (UTC)

A little while after this, I created Category:Taxonbars with from2 matching article title & QID (237) to mutually exclude the simplest cases from Category:Taxonbars with from2 matching article title (518), which cut its size down from ~750 to ~350. Posting it here for continuity. ~ Tom.Reding (talk ⋅dgaf) 13:41, 1 November 2020 (UTC)

Why hide the redlinks?

Module:Taxonbar/conf currently opts to not link any databases that do not have a page on en.wikipedia. This makes the output of {{Taxonbar databases}} quite odd, as Navboxes are supposed to have links, red or blue. As for the taxonbar itself, I personally believe WP:REDYES still applies. --Artoria 2e5 🌉 09:27, 27 December 2020 (UTC)

@Artoria2e5: I agree with you about {{Taxonbar databases}}, but I don't understand your remark about "the taxonbar itself". Peter coxhead (talk) 09:33, 27 December 2020 (UTC)

The {{Taxonbar databases}} template uses Module:Taxonbar databases, which gets the identifiers with or without links from Module:Taxonbar/conf, where the links are set. An option is to add a line to add links to any that are not already linked, something along the lines of If value not of form /[[.*]]/ then value = [[ .. value .. ]]. This would leave {{Taxonbar}} unchanged. — Jts1882 | talk 09:50, 27 December 2020 (UTC)

I'm ok with redlinking databases in {{Taxonbar}} if the page can pass WP:REDYES. ~ Tom.Reding (talk ⋅dgaf) 21:17, 27 December 2020 (UTC)

Making Taxonbar mobile-friendly and serve half of all Wikipedia readers

I am a huge fan of Taxonbar and I've been using it extensively when creating new stubs about missing taxa. It recently occurred to me that the template is not displayed on the mobile frontend and mobile apps. This means that roughly half of all readers of English Wikipedia can't see this template. That's a shame: this template provides arguably the most valuable set of external links for species stubs, specifically when other content is not available, and I'd like to figure out how to make it work. User:Jon (WMF) suggested that a possible fix would be to update the template styling and remove the navbox class, while also making use of Template Styles. Does that sound possible? @Tom.Reding: curious about your thoughts.--DarTar (talk) 17:12, 18 November 2020 (UTC)

@DarTar: indeed, visibility in mobile view would definitely be a big positive. This has been brought up before over a year ago, see Template talk:Taxonbar/Archive 5#Not shown in mobile view. If navboxes in general aren't shown in mobile, then it would be best to modify {{navbar}} in whatever way would facilitate that, especially if it's as simple as changing the nav header. ~ Tom.Reding (talk ⋅dgaf) 17:26, 18 November 2020 (UTC)

Here's how we can do this.

1) Make sure the table has the existing class navbox and a new class taxonbar. Untie it from {{navbar}} if that is possible and makes life easier. e.g. a fork called {{navbar-mobile-friendly}}

2) Create the page Template:Taxonbar/styles.css or Template:navbar/styles.css if that makes more sense.

3) Enable Extension:TemplateStyles on the template. We do this on a variety of important template, for example the main page. It importantly allows the use of CSS media queries to style differently on mobile and desktop. e.g. if we decide to make the change in Taxonbar

<templatestyles src="Template:Taxonbar/styles.css" />

4) Write the new styles. I have template editing rights so would happily volunteer time (@User:Jdlrobson) to do this step to make sure it looks nice on mobile.

5) Once I'm done with 4, I'll let you know and you can then safely remove the navbox class from the master template. It should now look the same and work on mobile.

Let me know if you are interested!

Jon (WMF) (talk) 18:49, 18 November 2020 (UTC)

@Jon (WMF): instead of forking {{Navbar}}, it would probably be better to add a parameter to {{Navbar}} that activates the necessary changes. I don't know what those adjustments are, though, so this discussion is probably best moved there for those familiar with that module (and hopefully familiar with the mobile-friendliness requirements) to discuss.

Jdlrobson has created Template:navbar/styles.css, which I think is the better of the 2 options. If we have to fork, we can hopefully do so at the style.css level via Template:Taxonbar/styles.css, and leave Template:navbar/styles.css as a default for {{Navbar}}. ~ Tom.Reding (talk ⋅dgaf) 13:54, 23 November 2020 (UTC)

Hey User:Tom.Reding. I've made a minimal proposed change to get these rendering on mobile here: patch. What do you think? Here's an example of it in action Montezuma_oropendola (make sure you view on the mobile site). If that looks good, feel free to patch Module:Taxonbar for all pages to show these on mobile. If not I'll go back to the drawing board :) Jdlrobson (talk) 23:25, 25 November 2020 (UTC)

@Jdlrobson: 2 issues (1 major, 1 minor). Mobile link for reference: m.Montezuma oropendola. The major issue is that there is no separator between each database-ID pair, so it just looks like a runon alphanumeric mishmash. Regular Taxonbar passes Navbar an ordered list separated by asterisk (*), which is ultimately interpreted as a bold middot (·) as a separator. This should be the goal of the mobile display. If that can't be done for some reason, then we can try to identify another separator character to use on mobile only. The minor issue is the very large mobile Taxonbar border at the top & bottom (the sides are nice & tight).

@Izno: are your recent edits to {{Navbar}} somewhat related to getting all navbars to display on mobile? If not, perhaps this discussion can offer some ideas and/or solutions? ~ Tom.Reding (talk ⋅dgaf) 12:06, 4 December 2020 (UTC)

I think coincidental. I am not sure what issues there are with navbar that would necessitate a fork. --Izno (talk) 12:18, 4 December 2020 (UTC)

And by Taxonbar passes Navbar I would guess you mean Taxonbar passes Nav~~bar~~box. --Izno (talk) 12:21, 4 December 2020 (UTC)

Hmmmm, yes. I'll leave it as an exercise to the reader to replace all my navbars with navboxes.. ~ Tom.Reding (talk ⋅dgaf) 12:46, 4 December 2020 (UTC)

The dots are easily fixed. I completely missed them. They're too small for my eyes to notice. They just need to be added to the stylesheet.

I'm not forking the template now in case that wasn't clear. This still uses all the underlying templates but I am not signing up to fix all navboxes ;) Jdlrobson (talk) 15:36, 4 December 2020 (UTC)

(Fixed) Jdlrobson (talk) 16:00, 4 December 2020 (UTC)

@Jdlrobson: that looks great! Unfortunately, I have no idea how to enable/incorporate this in the template. If you could do it @ Template:Taxonbar/sandbox and/or Module:Taxonbar/sandbox first for testing that would be ideal. ~ Tom.Reding (talk ⋅dgaf) 16:54, 4 December 2020 (UTC)

Oh wait, I'll check Montezuma oropendola first. ~ Tom.Reding (talk ⋅dgaf) 16:56, 4 December 2020 (UTC)

Previewing {{User:Jdlrobson/TaxonbarV2|from=Q934975}}{{Taxonbar|from=Q934975}} on Montezuma oropendola, I'd expect to see 2 exactly similar taxonbars, but the mobile-enabled one is different. Is it a matter of tweaking the style.css to make them match, or is there a more elegant solution that uses the new style.css on mobile only? ~ Tom.Reding (talk ⋅dgaf) 17:04, 4 December 2020 (UTC)

This is the only change needed: https://wiki.riteme.site/w/index.php?title=Module%3ATaxonbarMobilePatched&type=revision&diff=990687027&oldid=985419392 Jdlrobson (talk) 18:53, 4 December 2020 (UTC)

Note mobile has a different visual appearance to desktop so differences are expected. Edits can be made to Template:Taxonbar/styles.css to target different skins if necessary e.g. body.skin-minerva Jdlrobson (talk) 18:54, 4 December 2020 (UTC)

Has that solution been tested with a navbox stacked on top of taxonbar? There was concern that the current selectors would not function correctly. --Izno (talk) 22:24, 4 December 2020 (UTC)

This is in Module:Taxonbar/sandbox if you want to apply the change or verify it further. @Tom.Reding Jdlrobson (talk) 23:19, 8 December 2020 (UTC)

@Tom.Reding:. Any updates here? It doesn't seem like my sandbox changes got applied but you've applied some of your own since? Jdlrobson (talk) 00:51, 27 January 2021 (UTC)

@Jdlrobson: I was hoping that {{Cetacea}}{{Taxonbar|from=Q934975}}{{Cetacea}}{{Taxonbar/sandbox|from=Q934975}}{{Cetacea}} on Montezuma oropendola would render 2 identical taxonbars, but there are several discrepancies in the sandbox version:

"Taxon identifiers" is wrapped,
there is a trailing " • " that should be removed, and
as Izno mentioned above, there is extra whitespace above & below when there is an adjacent navbar ({{Cetacea}} used here as as arbitrary stand-in).

If these issues are resolved, I think it'll be ready for prime-time. ~ Tom.Reding (talk ⋅dgaf) 14:11, 27 January 2021 (UTC)

Btw, I documented the issue I mentioned on a relevant task at phab:T200206#6705367. Given the relative limited use right now you could fix it pretty easily with the CSS that Krinkle mentioned (though I might rather suggest .navbox + link + .authority-control), but it's not a general solution as I noted (what is happening with this template isn't particularly general either so I'm not bothered by that for now). --Izno (talk) 22:11, 29 January 2021 (UTC)

Fungi taxonbars

Is there a reason why the basionyms of fungi fail to be displayed in taxonbars. See for example Amauroderma rude and Badhamia utricularis both of whose wikidata entries include a basionym statement. MargaretRDonald (talk) 20:11, 2 February 2021 (UTC)

On the other hand, I see Byssonectria fusispora with its basionym in the taxonbar??? MargaretRDonald (talk) 20:41, 2 February 2021 (UTC)

@MargaretRDonald: According to Template:Taxonbar#Basionyms, basionyms should be automatically appended. With the two articles you cited, the problem seems to be that the basionym includes only one identifier, Australian Fungi ID, which per the below section is not included in the taxonbar currently. The taxonbar will not display without any identifiers. — The Earwig ^talk 20:46, 2 February 2021 (UTC)

@The Earwig: Thanks for the explanation. MargaretRDonald (talk) 21:53, 2 February 2021 (UTC)

Error in Taxon Identifiers table

I believe there is an error in the Taxon Identifiers table on https://wiki.riteme.site/wiki/Template:Taxonbar but I can't figure out how to edit it. Specifically, the link for eunis (P6177).

The linked text "European Nature Information System" needs to point to https://wiki.riteme.site/wiki/European_Nature_Information_System (for which the website is https://eunis.eea.europa.eu/)

but when clicked, instead takes you to https://wiki.riteme.site/wiki/European_University_Information_Systems_Organization (for which the website is https://www.eunis.org/) Michael pirrello (talk) 22:49, 3 February 2021 (UTC)

Michael pirrello, thank you for reporting. There was a problem with how the items were associated in Wikidata. It should be fixed now. — The Earwig ⟨talk⟩ 23:24, 3 February 2021 (UTC)

Including AusFungi and AusLichen (two new taxon identifiers)

I am hoping that both the taxon identifiers, AusFungi and AusLichen, will be included in the taxonbar. Lichens and fungi peculiar to Australasia will frequently have very few identifiers and it would be useful to have these additional links in articles. MargaretRDonald (talk) 20:18, 2 February 2021 (UTC)

What should AusFungi and AusLichen link to? It seems both are part of the National Species List and Australian Biological Resources Study Checklist (ABRSL). There is also AusMoss (no wikidata item) and Australian Plant Name Index (APNI, APNI ID (P5984)). An article for the latter exists and perhaps a related/sister databases section could be added (along with appropriate redirects). As they all use the same website, it seems odd that they weren't all included under one identifier system (even if fungi aren't plants). — Jts1882 | talk 07:40, 3 February 2021 (UTC)

@MargaretRDonald: I didn't ping you earlier. Are there suitable links for AusFungi and AusLichen or should they just be unlinked? — Jts1882 | talk 11:01, 7 February 2021 (UTC)

@Jts1882: I think they should be linked.... So a new article needs to be made. MargaretRDonald (talk) 11:15, 7 February 2021 (UTC)

@Jts1882: The page Australian online fauna & flora databases would be suitable for links for AusFungi and AusLichen. MargaretRDonald (talk) 05:22, 11 February 2021 (UTC)

@MargaretRDonald:. Added. I've checked the fungi one, but neither lichen examples on Wikidata have English Wikipedia articles, so could you check it is working. — Jts1882 | talk 08:46, 11 February 2021 (UTC)

@Jts1882: All working well. Thanks, MargaretRDonald (talk) 21:03, 11 February 2021 (UTC)

ATRF

@Jts1882: I note that ATRF which gives the Australian Tropical Rainforest ids does not itself link to a wikipedia page. See e.g. Abrus precatorius. I think it should link to Australian online fauna & flora databases. MargaretRDonald (talk) 21:59, 2 March 2021 (UTC)

Request edit from fr to en

Recently User:Drmies created Global Invasive Species Database here on en:. So there's no need to link to [[:fr:Global Invasive Species Database]] anymore. Invasive Spices (talk) 17:46, 26 April 2021 (UTC)

It ain't much but it's something. Drmies (talk) 17:50, 26 April 2021 (UTC)
Done, along with Australian Tropical Rainforest Plants. ~ Tom.Reding (talk ⋅dgaf) 18:17, 26 April 2021 (UTC)

Preview warning and hatnotes moving to templatestyles

Page watchers may be interested in MediaWiki talk:Common.css § Preview warning and hatnotes moving to TemplateStyles Izno (talk) 00:22, 29 April 2021 (UTC)

{Taxonbar databases}

FYI there is a discussion @ Wikipedia:Templates for discussion/Log/2021 April 24#Template:Authority control files that will likely affect the existence of {{Taxonbar databases}} (shown below). ~ Tom.Reding (talk ⋅dgaf) 18:24, 26 April 2021 (UTC) {{Taxonbar databases}}

Now @ WP:Templates for discussion/Log/2021 May 2#Template:Taxonbar databases. ~ Tom.Reding (talk ⋅dgaf) 19:35, 2 May 2021 (UTC)

Linking problems for the ID FoA2

This help request has been answered. If you need more help, you can ask another question on your talk page, contact the responding user(s) directly on their user talk page, or consider visiting the Teahouse.

The entry in wikidata for Trichocline spathulata for FOA2 links correctly to FoA2 Trichocline spathulata. However the link in the taxonbar is not linking correctly. MargaretRDonald (talk) 02:12, 15 July 2021 (UTC)

The reason is that in the generated URL the taxonbar maps "Trichocline spathulata" into "Trichocline+spathulata" instead of "Trichocline%20spathulata". There's an explicit statement in Module:Taxonbar that makes this mapping, which I presume must have worked in the past. I'd rather leave this to Tom.Reding to fix, as he will know the history. Peter coxhead (talk) 06:23, 15 July 2021 (UTC)

Updated ~ Tom.Reding (talk ⋅dgaf) 11:13, 15 July 2021 (UTC)

Thanks, @Tom.Reding: MargaretRDonald (talk) 21:24, 15 July 2021 (UTC)

Linking problems for the ID NSWFlora

(Sorry @Tom.Reding:.) I am hoping you can help with this one too.
Wikidata entry for Myriocephalus pluriflorus gives the ID as Myriocephalus~pluriflorus. but takes one to the Wayback machine as do the links in the property talk for the ID and the taxonbar at Myriocephalus pluriflorus. All of this used to work. I am hoping that this can be sorted soon. MargaretRDonald (talk) 21:24, 15 July 2021 (UTC)

Done: the problem was @ NSW Flora ID (P3130)'s formatter URL (P1630). Dhx1 changed around all of the preferred ranks, so I demoted archive.org & promoted https://plantnet.rbgsyd.nsw.gov.au. ~ Tom.Reding (talk ⋅dgaf) 10:23, 16 July 2021 (UTC)

@Tom.Reding: I found the problem that led me to think that plantnet.rbgsyd.nsw.gov.au was dead/offline.

dig @1.1.1.1 plantnet.rbgsyd.nsw.gov.au

(via CloudFlare DNS) returns no domain name however

dig @8.8.8.8 plantnet.rbgsyd.nsw.gov.au

(via Google DNS) returns 141.243.20.114 and therefore allows a browser to establish a connection to the website. It appears that the NSW environment department load balancers may be blocking DNS queries from CloudFlare. --Dhx1 (talk) 12:23, 16 July 2021 (UTC)

Thanks so much, @Tom.Reding: This had been a problem for quite a while. MargaretRDonald (talk) 14:17, 16 July 2021 (UTC)

Monotypic taxa

I've been trying to cut Category:Taxonbars desynced from Wikidata down to size. It will never be empty, but pages get moved to new scientific names without the taxonbar being updated, and so on. I was wondering whether just having genus and species in the taxonbar of pages for monotypic taxa was the right thing to do. Is the existing functionality to automatically add a parent in this module deprecated?

I had a peep at the module code, and I also notice Category:Taxonbars with automatically added monotypic genera is sparsely populated. It only seems to work if you set the species record in Wikidata to be an instance of 'monotypic taxon', which is counter-intuitive for a biologist (though I see how it's convenient from the programming angle). Following links in this page's archive, it seems the functionality was frustrated at d:Wikidata:Property proposal/child monotypic taxon.

Anyway, if I'm right, I wonder if it is worth having a note on Category:Taxonbars with automatically added monotypic genera, so nobody else goes down the same rabbithole I did. William Avery (talk) 19:13, 17 August 2021 (UTC)

@William Avery: yep, d:Wikidata:Property proposal/child monotypic taxon pretty much sums it up. To continue with the example there, one might be able to Luamatically find Mendosoma lineatum (Q3077073) from Mendosoma (Q2788054)'s WD page if there's an API call for 'What links here', then search for the (hopefully) 1, and only, item matching ^Mendosoma [a-z]+$ (unfortunately, there's also Mendosoma allporti (Q106414921) in this case, which might be why it lost its monotypic taxon (Q310890)). ~ Tom.Reding (talk ⋅dgaf) 20:26, 17 August 2021 (UTC)

@Pigsonthewing: in d:Wikidata:Property proposal/child monotypic taxon you said this could be determined programatically, but never responded how. Is above how it could be done ('What links here'), or is there another way? ~ Tom.Reding (talk ⋅dgaf) 20:32, 17 August 2021 (UTC)

Of course, I can't speak for anyone else, but finding records with the parent taxon attribute set to the given value is a simple thing in SPARQL, so it's a surprise to me that the facility isn't in the lua API, nor in the web API, as far as I can see. William Avery (talk) 21:02, 17 August 2021 (UTC)

Problem if no Wikidata item

Eleodes carbonaria is showing "Lua error in Module:Taxonbar at line 600: attempt to index local 'currentItem' (a nil value)." Presumably that is because the new article has no Wikidata item. I haven't examined the logic but people here might consider whether replacing currentItem in line 600 with (currentItem or {}) would be useful. Alternatively, insert an if to give a more helpful error message if currentItem is nil. Johnuniq (talk) 22:41, 3 October 2021 (UTC)

There is a Wikidata item (two actually). The problem seems to stem from a round-robin move.

It's partly my fault. The article was created at the current title. In trying to track the missing taxonomic authority, I came across the spelling "Eleodes carbonarius". The Wikidata item for that spelling had more taxon IDs than the "E. carbonaria" spelling, so I assumed the -us spelling was correct. I moved the article to the -us spelling, added {{R from misspelling}} to the -a spelling. On further investigation, I discovered that the databases with taxon IDs on the Wikidata item for the -us spelling actually used the -a spelling. I edited the Wikidata items so that taxon IDs were associated with the item that used the spelling found in the relevant database. Since I'd made a subsequent edit after moving the Wikipedia articles I made a technical move request to reverse my move. As part of the move I'd requested, d:Q49622115 had the link to en.wiki automatically removed.

I'm puzzled by what actually happened (in terms of the logistics of the round-robin move), and why an error is being displayed. I haven't noticed other round-robin moves resulting in removal of an en.wiki link on Wikidata. Perhaps there is a difference in whether a round-robin move is performed by going to a title in Draft space (versus e.g. appending an extra character to the title that ends up being deleted)? Maybe the mover had a tool enabled that deleted en.wiki links on Wikidata that most round-robin movers don't have enabled? Adding a taxonbar to an en.wiki page that isn't (yet) linked from Wikidata doesn't normally produce an error. I have seen some taxonbar error message after a page move before, but these can be resolved with a null edit, which isn't working in this case. If I swap the values given in the taxonbar |from1= and |from2=, the error message goes away (in preview mode; I haven't committed the edit in case it helps with further investigation).

Bottom line, a round-robin move should NOT result in a Wikidata->en.wiki link being deleted. That situation needs to be fixed. Dealing with the error message from taxonbars is secondary. Plantdrew (talk) 01:25, 4 October 2021 (UTC)

Fixed the module; a rare find! ~ Tom.Reding (talk ⋅dgaf) 03:15, 4 October 2021 (UTC)

Taxonbar no longer working correctly for the Reptile Database links

Simoselaps anomalus has an RD id in Simoselaps anomalus (Q3484662). However the link in the taxonbar is currently failing to include the genus and the taxonbar fails to link correctly to species in the reptile database. This problem currently affects most reptiles, so it would be good if it could be fixed soon. MargaretRDonald (talk) 22:35, 7 October 2021 (UTC) Sorry to ping you, @Tom.Reding:, but I am not sure who to ping. MargaretRDonald (talk) 22:37, 7 October 2021 (UTC)

The formatter URL for the Reptile Database ID has recently been changed, with link rot cited as the reason. It added a link through "https://wikidata-externalid-url.toolforge.org/" which wasn't working properly. I removed that and the links work again, but the it's now the same formatter that was marked as deprecated. Perhaps @Lockal: can explain what the revision was supposed to do. — Jts1882 | talk 08:46, 8 October 2021 (UTC)

@Jts1882: the issue of original URL formatted is discussed in [1]. @Succu: correctly mentioned that it never worked. External identifiers in Wikidata should be URL-encoded before substitution into URL-formatter (related to T160281). As I see, there are a lot of hacks around line 94 for various properties, but in the end, all you need to safely get rid of all hacks is to

mw.uri.encode( value, "PATH" ) all values before substitution.
if there are multiple URL formatters, select one based on language of work or name qualifier.

--Lockal (talk) 10:49, 8 October 2021 (UTC)

@Lockal: Thank-you for that answer and suggested solution. I've restored your edit at Wikidata and added the mw.uri.encode( value, "PATH" ) at line 94 and its seems to do the trick. Tom.Reding raised the issue almost three years ago and I added comments about the issue a year ago and six months ago. Now we know who to ping for such questions. Thank you. — Jts1882 | talk 12:49, 8 October 2021 (UTC)

@Jts1882:, could you also copy these changes, please? It does not unbreak anything, just a code cleanup. --Lockal (talk) 13:49, 8 October 2021 (UTC)

Done — Jts1882 | talk 08:37, 9 October 2021 (UTC)

The link to the reptile database in the taxonbar at Simoselaps anomalus works, but the link in the Wikidata item Simoselaps anomalus (Q3484662) does not. So the taxonbar code is fixing an error in Wikidata, which presumably won't work if Wikidata is fixed. Peter coxhead (talk) 18:18, 8 October 2021 (UTC)

@Peter coxhead: I think this is a caching issue. It was still using the Wikidata change I made yesterday even though I reverted it. Lockal's version is now working for me after I deleted the Wikidata entry and undid the change. Is there an easier way of doing a null edit on Wikidata? — Jts1882 | talk 08:37, 9 October 2021 (UTC)

@Jts1882: ah, yes, working ok for me now too. No, I don't know how to achieve the effect of a null edit on Wikidata. Peter coxhead (talk) 08:40, 9 October 2021 (UTC)

Bad FEIS URL because of percent encoding

See for instance Pinus strobus. Slashes in the ID plants/tree/pinstr are replaced with %2F, yielding the URL https://www.fs.fed.us/database/feis/plants%2Ftree%2Fpinstr/all.html; this should be https://www.fs.fed.us/database/feis/plants/tree/pinstr/all.html. The ID never needs percent encoding because it's always ASCII alphabetic characters and slashes. — Eru·tuon 19:27, 15 October 2021 (UTC)

Extinct taxon (Q98961713) not handled

A new subclass of taxon, d:Q98961713, was introduced about a year ago, and isn't handled by the module.

There are currently 122 articles in Category:Taxonbars on possible non-taxon pages that are affected, as shown by this Petscan Query William Avery (talk) 15:12, 5 September 2021 (UTC)

Done - added to whitelist. ~ Tom.Reding (talk ⋅dgaf) 19:27, 11 September 2021 (UTC)

@William Avery: (and anyone else): I went through all 1145 pages left in Category:Taxonbars on possible non-taxon pages (377), and found these unique instance of (P31).

Do you see any that could be added to the whitelist?
What do you think about using some/all of these as a starting point for a blacklist, that could populate Category:Taxonbars on non-taxon pages?

All 119 unique 'instance of's on possible non-taxon pages

~ Tom.Reding (talk ⋅dgaf) 20:07, 12 September 2021 (UTC)

Some significant culling was done (not by me), taking Category:Taxonbars on possible non-taxon pages from 1145 down to 578 (current population: 377). The updated list of remaining unique instance of (P31) is:

All 89 unique 'instance of's on possible non-taxon pages

~ Tom.Reding (talk ⋅dgaf) 11:36, 7 October 2021 (UTC)

I feel a bit guilty about not finding time to give an an opinion on this, but on the plus side, it was me what hacked back the Category:Taxonbars on possible non-taxon pages. William Avery (talk) 10:48, 1 November 2021 (UTC)

A limit on synonyms?

So @Gderrin: and I were talking about synonyms in Taxonbars. I am under the impression that that is one of the purposes for the Taxonbar. There is even a mechanism for automatically including the basionym. However, there may be cases where a taxon has an unusual amount of synonyms, and that the synonyms actually have QIDs on WikiData, and furthermore actually have identifiers for those items. I have not come across such taxa, but have other folks had issues with “too many synonyms”? Is this a problem? --awkwafaba (📥) 03:09, 27 October 2021 (UTC)

I'm going to post rather a wall of text. Long story short: only a basionym/protonym will appear automatically: most of the others were added by me attempting to fix things, but the pushback has been noted.

On the one hand, I think that one thing worse than seeing too many synonyms might be the existence of synonyms one can't see. The extra information is quite handy on stub articles created by bots and the like, when a proper literature search hasn't been done in creating the article text. An incidental related issue is that when the Wikipedia article uses a scientific name different from the name on the Wikidata item, the user is not alerted to the fact that they are seeing a taxonbar of ids for a different name. Using both QIDs solves that.

But, OTOH, the appearance of effectively little-used synonyms that nevertheless have an id in every plant taxonomy database, resulting in a huge bank of numbers at the foot of the page, is pretty distracting. I see how this applies to the better quality articles that are produced by @Gderrin:.

A couple of months ago, I attempted to address issues that were putting pages into Category:Taxonbars desynced from Wikidata, which is treated as an error category under Category:Taxonbar cleanup. I added numerous Wikibase QIDs for synonyms to taxonbars in order to remove them from that category. This had the consequence of what we might term "taxonbar inflation".

I know that in the case of many lepidoptera the Wikipedia articles are currently at somewhat outdated names, and keen editors on Wikidata keep that site more up to date. Even if I were inclined to move the lepidoptera articles around on Wikipedia, I certainly don't have time to keep the text and the taxonomy templates abreast of what is on Wikidata. I therefore think the expanded templates are reasonable on those articles. In the case of the plant articles, I suspect the Wikipedia articles are attached to out-of-date names on Wikidata, and rather than adding a new QID to the taxonbar, cleanup should involve moving all the Wikipedia article links to the item specified in the taxonbar on enwiki. I believe I heard mention of a Wikidata editing gadget to shift all the article links from one item to another at once. I have no idea what pushback there may be on Wikidata if I start doing that, but rest assured that my intention is to move on, so that any annoyance will be to a different set of colleagues. :-) William Avery (talk) 12:19, 1 November 2021 (UTC)

@William Avery: in taxoboxes, there's |display_parents= to limit the display of minor ranks above a taxon. I wonder if something similar would work for taxonbars. Say |max_display=N, when at most the first N lines would be displayed and the rest would be hidden with some kind of expand button. We could then discuss what the default for N would be if not specified. Just an idea. I think that having all the synonyms available is very useful and should not be abandoned, but having to choose between displaying all the entries or none isn't optimal. Peter coxhead (talk) 13:29, 1 November 2021 (UTC)

The thought of offering more control of the taxonbar display did cross my mind, but I thought it would introduce too much complication. Nothing as elegant as what you suggest occurred to me. William Avery (talk) 14:53, 1 November 2021 (UTC)

I think the lists of synonyms are very useful. They usually occur where the taxonomy is, or has been until recently, in flux. I'd be against removing this information. They are placed at the end of the article so aren't disruptive to the reader. However, the suggestion for an option to collapse longer lists in some way is a good one. — Jts1882 | talk 15:37, 1 November 2021 (UTC)

The Taxonbar already autocollapses when it gets to a certain size. I’m not sure how big; the code is opaque to me. --awkwafaba (📥) 01:36, 2 November 2021 (UTC)