Wikipedia talk:WikiProject Tree of Life

WikiProject Tree of Life

Main pageTalkArticle templateTaxonomic resourcesTaxoboxesParticipantsArticle requests

Is it too much original research when the etymology of a taxon is completely obvious but unstated?

Within the king crabs, there is a subfamily Hapalogastrinae and a genus Hapalogaster. Their etymology in their original 1850 descriptions are unstated, but these are extremely clearly derived from the two Ancient Greek words ἁπαλός (hapalós) and γαστήρ (gastḗr) (together meaning "soft-bellied"). This is especially evident because the main defining aspect separating them from the rest of the lithodids is that the abdomen folded against their cephalothorax (basically functioning as their belly) is not calcified and therefore soft. Do Wikipedians generally consider this to be original research, or would this be something more along the lines of WP:TRANSCRIPTION? TheTechnician27 (Talk page) 01:16, 12 November 2024 (UTC)

In my interpretation on this, if you were directly asked Is this THE ACTUAL etymology that the describing author intended? we have to say no, as they never stated it. We have to word any etymology section as neutral and with backing sources, thus if we say the etymology is ἁπαλός (hapalós) and γαστήρ (gastḗr) (together meaning "soft-bellied")" we need to avoid any implication that it was the original authors indent. This is what happens when verifiability runs into older names combined with a crufty need for providing a name translation for all names.

Also as a personal note I truly detest the "(together meaning xxxx") structure used by kids books, rarely do you ever see any describing author use that formatting, and its not actually what its means, its what a very poor English spit-take of the name would be. I only ever discuss the root words/names and what they as single words translate to. We never go around talking about the new three-horned face fossils that were found or the disjunct distribution of "rounded Ypresian ant", "Bartletts Ypresian ant" with "eastern Ypresian ant". We shouldn't continue to normalize a low quality source practice.--Kevmin § 01:39, 12 November 2024 (UTC)

Interesting question! Unless a source discusses the etymology, yes, I would consider it original research and not transcription. I often come across secondary sources that posit theories on the etymology of a name when the original description fails to provide any, and adding this to an article is fully acceptable, but in my opinion etymology information in articles must reference a source that discusses the taxon in question. Ethmostigmus 🌿 (talk | contribs) 01:51, 12 November 2024 (UTC)

It is best practice to only record an etymology if one is clearly stated by a reliable source, and we should beware of creating a folk etymology for a scientific name. That said, I think it can be permissible if the etymology is clearly implied in context; 19th-century authors could generally assume their readership knew Greek and Latin, so they'd say things like "owing to its long tail, I propose to name this species Examplesaurus longicaudus" and leave the actual translation as an exercise for the reader. Does the original description of Hapalogaster clearly imply that it is named for having a soft belly? Ornithopsis (talk) 03:34, 12 November 2024 (UTC)

@Ornithopsis: Unfortunately no, but your example makes a lot of sense. The original description of Hapalogastrinae (subtribe Hapalogastrica -> family Hapalogastridae -> subfamily Hapalogastrinae) exclusively talks about its abdomen, but it unfortunately doesn't directly imply an etymology. JF Brandt, 174 years later, some amateur naturalist is very disappointed in you. TheTechnician27 (Talk page) 01:40, 13 November 2024 (UTC)

You shouldn't be stating the etymology as fact, but in my opinion it's fine to state the meanings of those words as "related facts" and let the reader draw conclusions if they want to. For example:

Myzobdella is a genus of leech. [...] In Greek, μυζω means "I suck" and βδελλα, leech.

But others might complain.

Also, I hate it when taxon authors don't provide etymology, especially, when the etymology is weird or obscure. On the other hand, I also don't like it when they call the species viridis or gigantea or something and just call it day.Cremastra ‹ u — c › 01:33, 28 November 2024 (UTC)

And sometimes a source will speculate for us.[1] Donald Albury 16:57, 28 November 2024 (UTC)

I think the point that Ornithopsis makes is very sound: in the past, etymologies weren't provided when the meaning would have been clear to someone who knew Latin and Greek. I endorse Cremastra's example: state the meaning of the components (with a source of course) and leave it to the reader to join the dots. (Botanists have it a bit easier in this respect, because Stearn's Botanical Latin has long lists of Latin and Greek components, and examples of combinations.) Peter coxhead (talk) 17:20, 28 November 2024 (UTC)

I agree. I have read (and cited) entire academic articles written in Latin (the abstract is often in the vernacular, often not English). Latin scholarly articles are surprisingly easy to read, written in a Latin that favours academic terms with close loanword cognates in many languages, and avoiding elaborate syntax, like the Simple English Wikipedia does. They are much easier to read than Latin texts written by native speakers like Julius Caesar.

Per WP:NONENG and WP:TRANSCRIPTION, sources need not be in English, and it is not WP:Original research to translate information (it's just another way of paraphrasing what the source says). I once wrote an article where almost none of the sources were in English, software package listings excepted. If you are confident that you understand the language, you can write a translation. Frankly, scientific names are assembled out of components, and the meaning of the compound in natural language is pretty much irrelevant, so translating the components is better anyway. I'd favour linking both of them to Wiktionary, alongside a (cited) discussion of the characteristic softbelliedness of the crabs, as you did in your first post. HLHJ (talk) 03:55, 30 November 2024 (UTC)

There's a name for doing this in linguistics: Wiktionary:surface analysis. It is contrasted with diachronic etymology, where you look historically to find out how the word originally formed. HLHJ (talk) 03:13, 2 December 2024 (UTC)

Category:Endangered species by reason they are threatened has been nominated for discussion

Category:Endangered species by reason they are threatened has been nominated for possible deletion, merging, or renaming. A discussion is taking place to decide whether it complies with the categorization guidelines. If you would like to participate in the discussion, you are invited to add your comments at the category's entry on the categories for discussion page. Thank you.

About 70 subcategories, the oldest from 2015, are also being proposed for deletion.

These categories are used for extinct species as well as living ones.

There is debate about whether it is possible to list some threats to a species without oversimplification and omissions amounting to misinformation; comments from anyone with an interest in threatened species or extinction would be particularly welcome. HLHJ (talk) 04:47, 17 November 2024 (UTC)

Automated taxonavigation in Commons

Is there any way that we could replicate the automatic taxobox system for the taxonavigations in Wikimedia Commons? It takes excruciatingly long to update the taxonavigation box for every taxon. — Snoteleks (talk) 22:56, 22 November 2024 (UTC)

In principle, yes. Commons could have its own equivalent of our taxonomy templates, and use these to construct taxonavigation boxes, or Commons could use our taxonomy templates. However, that would be a decision to be made over at Commons, not here. (A major problem would be that individual language Wikipedias don't agree on taxonomy, which is why taxonavigation boxes can be inconsistent.) Peter coxhead (talk) 08:27, 23 November 2024 (UTC)

I don't think that the issue is that they don't agree on taxonomy, I believe that the English Wikipedia just happens to be better maintained sourced. If there were automatic taxonavigations boxes at Commons, they would just try to represent the most recent literature and consensus, just like automatic taxoboxes. (Also, Wikidata also gives the same taxonomy for all languages). I don't really know who I should ask about this topic at Commons, though, since I couldn't find anything similar to the ToL WikiProject. — Snoteleks (talk) 10:21, 23 November 2024 (UTC)

Wikidata also gives the same taxonomy for all languages – Wikidata allows multiple values for the parent of a taxon, so doesn't represent a single taxonomy. Wikidata gives the same taxonomies (plural) for all languages. Look at Lemnaceae (Q14293890) – a taxon we don't recognize in the English Wikipedia. For us, the parent of Lemna (Q161207) is Lemnoideae, not Lemnaceae. The equivalent for Commons would be multiple taxonavigation templates. Peter coxhead (talk) 10:33, 23 November 2024 (UTC)

That just means that either Wikidata or English Wikipedia is not accurate and needs to be updated. I do not see that as differing opinions. — Snoteleks (talk) 21:21, 23 November 2024 (UTC)

@Snoteleks: within limits, taxonomy has a subjective component. The rank at which to recognize a group can certainly be a matter of opinion. Some sources, such as PoWO, are known 'lumpers'; regional floras and specialists are more likely to be 'splitters'. If you want to see an extreme example, see Blechnum. We chose to go with PPG I, others could perfectly legitimately choose to go with PoWO. Neither approach is "accurate" or "inaccurate". Peter coxhead (talk) 22:27, 23 November 2024 (UTC)

The scientific consensus is one thing, and at Wikipedia we try to follow it because it is backed by credible sources. The databases (such as PoWO) are a completely different thing, they are subjective because they are maintained by specific individuals who usually don't keep the data completely up to date with the literature. Moreover, databases are based off of the scientific literature, not the other way around. This means that the taxonomy based on the former is by definition accurate, while the taxonomy based on the latter is inaccurate. — Snoteleks (talk) 23:29, 23 November 2024 (UTC)

@Snoteleks: two quick points: don't assume there is always a consensus; we are supposed to use secondary or tertiary sources, not primary ones – we mustn't try to judge consensus from the literature. Anyway, no more from me on this subject. Peter coxhead (talk) 15:45, 24 November 2024 (UTC)

@Snoteleks: Commons does actually have its own TOL WikiProject, but I don't think it's active anymore. (Nor has it been for a few years now I think.) Monster Iestyn (talk) 18:07, 23 November 2024 (UTC)

A reminder that ping doesn't work without a signature (four tildes). Donald Albury 20:43, 24 November 2024 (UTC)

@Donald Albury: That wasn't the issue actually, I used the reply tool that's now built in and automatically adds my signature. What actually happened is that a previous edit not by me changed the wikitext of my ping from @[[User:Snoteleks|Snoteleks]] to @[[User:|Snoteleks]] and so breaking it, probably unintentionally? Monster Iestyn (talk) 22:49, 24 November 2024 (UTC)

I'm not sure I understand what you are asking. Commons has Commons:Template:Taxonavigation, which produces the top navigation bar using manually entered parameters, and Commons:Template:Wikidata infobox, which produces the "taxobox" using wikidata. If you want Taxonavigation to automatically fill in the taxa, perhaps you should ask at Commons:Template:Wikidata infobox. They already have code for automating the taxonomy in the taxobox, so someone might be willing to modify that for Commons:Template:Taxonavigation.  —  Jts1882 | talk  12:27, 23 November 2024 (UTC)

Just to note that if you use Commons:Template:Wikidata infobox on a taxon which has multiple parent values set in Wikidata, the template uses the first one. So if there were a Wikidata infobox on Commons with |qid=14293890 (Lemnaceae), it would (currently) show the parent as Arales, as this is the first listed parent. Peter coxhead (talk) 13:46, 23 November 2024 (UTC)

In that particular case there is a preferred parent, which the infobox should be able to select (yet doesn't). But in most cases where there are many they are all left as normal (neither deprecated or preferred). In some cases they include immediate parents and others that skip straight to a higher rank. Unfortunately, as the statements are usually in order they are added, old relationships will be selected over the new ones. There is no solution, as Wikidata is set up, as even if people tried to set preferred values, different wikipedia might want different systems (e.g. POWO v World Ferns).  —  Jts1882 | talk  17:05, 23 November 2024 (UTC)

Sadly we regularly come to the conclusion that nothing can be done because of the way that Wikidata is set up. Peter coxhead (talk) 15:45, 24 November 2024 (UTC)

Discussion about Taxonbar on Wikispecies

I have started a discussion on Wikispecies regarding the Taxonbar template. In the past (in 2020) it was banned for use on Wikispecies mainly due to problems with its design with respect to what Wikispecies actually does as opposed for example Wikipedia. I have made some suggestions that are more in keeping with the function of Wikispecies in the hope we may be able to get it approved for use and would appreciate any feedback from people here who may be interested in this. Thanks. Scott Thomson (Faendalimas) ^talk 15:08, 24 November 2024 (UTC)

Taxobox images and image_alt parameters

While working on other ToL matters, I became aware that in various taxon articles with one or more images in the (manual or automatic) taxobox, these images either entirely lack a |image_alt= parameter, or have it left blank. (Going to be honest: I'm fairly sure I've been guilty of that myself as well!)

To get a rough idea of the scale of these absent/blank image_alt parameters, I spot-checked various articles transcluding the three main taxobox templates—{{Speciesbox}}, {{Automatic taxobox}} and {{Taxobox}}—until I found 20 of each with at least one image using the |image= parameter or a numbered equivalent.

Out of these sixty articles, only seven consistently provided image_alt parameters, and another two did so partially.

Assuming these results are roughly representative of taxon articles as a whole, ~88% of taxon articles with infobox images lack alt text for some or all of these. That is, well, not good, considering that per the MOS and Accessibility guidelines, such images should have one. (I wrote up a quick summary of these guidelines within the context of taxoboxes, which can be found here, if anyone prefers that).

I intend to add this missing alt text where I come across it, but the presumed scale of the issue combined with the size of ToL means I cannot feasibly do it alone. Anyone else willing to help, whether that's by looking for articles with missing alt text or "just" checking whether there's alt text for infobox images on articles you're already working on anyway, would be much appreciated. AddWittyNameHere 09:23, 30 November 2024 (UTC)

We could use |image_caption= to populate |image_alt= when it is absent. Not all taxobox images have captions, but when they do that would be useful. And in the absence of the either, we could put the file name. While sometimes confusing, this would usually be better than nothing. So in {{speciesbox}}, we could change:

• Current (line 79): | image_alt = {{{image alt|{{{image_alt|}}} }}}
• Using caption: | image_alt = {{{image alt|{{{image_alt|{{{image caption|{{{image_caption|}}} }}} }}} }}}
• And using file name: | image_alt = {{{image alt|{{{image_alt|{{{image caption|{{{image_caption|{{{image|}}} }}} }}} }}} }}}

Is there a downside I'm missing? This wouldn't be a substitute for encouraging use of |image_alt=.  —  Jts1882 | talk  10:10, 30 November 2024 (UTC)

On reflection, an obvious downside is wikitext in the caption. This could be stripped with a simple function, but does make the change less trivial.  —  Jts1882 | talk  10:13, 30 November 2024 (UTC)

If stripping the wikitext from the caption is possible, it could be a decent if flawed stop-gap measure in those cases where captions are present and alt text is not. (Which, based on my sampling, would be over half of cases with missing image_alt). I do imagine, though, that the same text getting read out twice by a screen reader, once as alt text and again as caption, might also be rather frustrating (if probably still an improvement over no alt text). Would there be a way for the template to automatically detect if a caption is present, and if so, populate image_alt with "refer to caption"? I could see that being a better solution, if feasible.

As for using the file name, my understanding is that one of the reasons for using alt text is because screen readers will otherwise default to reading out the file name, which is considered unwanted and potentially confusing. Not sure that actively populating image_alt with the file name is an improvement when the behavior is likely to remain identical but with additional steps behind the screens.

(That said, that's based on what little of the technical side of templates and alt text I understand, and I could be wrong there. As far as technical downsides go, I'm not the one to ask, really. I can use templates and follow the documentation of parameters, but creating/editing them beyond the most basic level is beyond me, I'm afraid.)

AddWittyNameHere 11:08, 30 November 2024 (UTC)

(edit conflict) [I hadn't read your addition when I posted the following]

On reading MOS:ALT, it seems repeating the caption is discouraged. Instead, adding |image_alt=refer to caption might be more appropriate when there is a caption and no alt text provided. Also it says screen readers will read the file name which can be confusing and is one reason alt text is required  —  Jts1882 | talk  11:17, 30 November 2024 (UTC)

Seems we had practically-identical thoughts at the same time, then. AddWittyNameHere 11:20, 30 November 2024 (UTC)

Something like this might do:

• | image_alt = {{{image alt|{{{image_alt|{{#if:{{{image caption|{{{image_caption}}} }}}|refer to caption| }} }}} }}}

The syntax of the #if statement needs checking. It could be added to {{taxobox/core}} but that tends to need more checking  —  Jts1882 | talk  11:28, 30 November 2024 (UTC)

Okay! Not sure how to best go about checking it, so I'll leave that to you and/or others with actual syntax and syntax checking knowledge. Still, it sounds like it should be feasible then, just checking whether this is the correct syntax to do it? If so, that's good news and would significantly reduce the scale of the problem for the moment. (Would still be good if those image_alts eventually get populated by actual manual alt text, of course, but certainly of lower priority than stuff that has neither caption nor alt text)

I should probably also look into how to get a list of all articles that use a taxobox of some kind, have a non-blank image parameter, and lack an accompanying image_alt or image_caption parameter and/or have a blank one. Guess I'll do that after I get some much-needed sleep, though. AddWittyNameHere 11:43, 30 November 2024 (UTC)

I did a test with {{speciesbox}} in the edit preview and it looks like it worked. It's probably best to put it in a utility template, say {{taxobox/alt_text}}, so it can be added in several places, as {{taxobox/core}} handles six images (2 images and 4 range maps).

My searches suggest the number of taxoboxes with |image_alt= is only a few percent, assuming this search is what I intended it to be. About 1500 uses of |image_alt= in about 140,000 speciesboxes with images and 40,000 with captions.  —  Jts1882 | talk  11:54, 30 November 2024 (UTC)

Would it work as-is in several places? I'd think that as currently written, if added to one of those other places, it'd end up looking for whether the first image--not the one it actually applies to--has a caption, since the caption parameter names aren't the exact same for image2 and the range maps. Could be wrong though, definitely am not a syntax expert. AddWittyNameHere 12:13, 30 November 2024 (UTC)

1624 Speciesboxes have |image_alt= in the Template Parameters report. Plantdrew (talk) 16:36, 30 November 2024 (UTC)

Okay, thank you! Seems fairly close to what Jts1882's search indicated, then. Might be worth eventually figuring out where the difference is, but for now, using Jts1882's search except slapping a - in front of the portion used to look for image alt should get me the majority of speciesboxes with images but without |image_alt=, I think. Can always look for a more exact search to catch the stragglers if we ever get the bulk dealt with, but not super worried over missing a couple hundred or getting a hundred or so show up that do have alt text on a six-digit total... AddWittyNameHere 22:45, 30 November 2024 (UTC)

Notes

Notice of relevant discussion

I've added a query to Talk:Eponym about possibly splitting the page for a specific page about eponyms in taxonomy, and am alerting this group so interested editors who don't have this page on their watchlist can be aware. Esculenta (talk) 15:31, 1 December 2024 (UTC)

RFC Notability (species) re monotypic taxa

After some discussion at Wikipedia talk:Notability (species) § Monotypic taxons regarding adding something in the recently-accepted notability guideline for species, a request for comments on an addition to the guideline has been posted at Wikipedia talk:Notability (species) § RFC monotypic genera. – Elizabeth (Eewilson) (tag or ping me) (talk) 21:38, 8 December 2024 (UTC)

PetScan question

I'd like to perform PetScan searches using the "categories" of the WikiProject quality/importance table. For example, sorting by size the lichen task force articles that are "stub" & "mid"-importance. Is such a thing possible with PetScan (or any other tools)? If it is, what do I enter in the "Categories" box? Esculenta (talk) 17:13, 13 December 2024 (UTC)

@Esculenta: I don't think you can do exactly what you want. Go to PetScan and put "Stub-Class Lichen task force articles" and "Mid-importance Lichen task force articles", without the quotes, on separate lines in the Categories box, with Combination set to Intersection. Then move to the "Page properties" tab and tick the "Talk" box – this is important because by default PetScan only finds articles in mainspace; without this box ticked you get 0 returned. Then click "Do it!". I got 684 results. BUT this won't tell you the size of the articles, only the size of the talk pages. The problem is that the class/importance categories are on the talk pages, not the articles. Peter coxhead (talk) 19:17, 13 December 2024 (UTC)

Link to the search described above Peter coxhead (talk) 19:19, 13 December 2024 (UTC)

Thanks for trying; looks like I'll have to write a script to get these results. Esculenta (talk) 19:30, 13 December 2024 (UTC)

Yeah, PetScan can be used to search talk page categories, but then you only get properties (e.g. size in bytes) of the talk pages, not of the articles themselves. I guess you could do it in multiple steps; Petscan the talk pages you're interested in, copy those results into a text editor, and do a find/replace to turn the links to the talk pages into links to articles. Then copy the text with the links to the articles onto a Wikipedia page (a sandbox of yours) and do a Petscan for "Linked from" with your sandbox page as the page they are linked from. Plantdrew (talk) 19:37, 13 December 2024 (UTC)

Subgenera in article titles?

Hi all, just wondering if we have any existing guidelines on the use subgenera names in the titles of species articles - that is to say, should we include the subgenus a species is placed in (when applicable) in the title of its article? I had a look at Wikipedia:Naming conventions (fauna) and Wikipedia:Naming conventions (flora) but didn't see anything relevant. It certainly doesn't seem to be a widespread practice, but I do believe I've seen articles titled in the "Genus (Subgenus) species" format before and was curious if there's any consensus about it. Cheers, Ethmostigmus 🌿 (talk | contribs) 04:52, 25 December 2024 (UTC)

It's unnecessary in the title, which would be covered by the general article naming guidelines The binomial species name is concise and unambiguous. It would be harmless of add something to the naming convention guidelines, but doesn't seem an issue that needs dealing with when there are few articles so named.

This search finds over 600 such titles, but they are nearly all redirects. According to the stub articles Mispila (Dryusa) coomani and Mispila (Mispila) coomani are different beetles. Can this be correct? Another beetle example is Cadmus (Brachycaulus) colossus, where the subgenus is included in the title and not the taxobox.  —  Jts1882 | talk  08:14, 25 December 2024 (UTC)

Well, that's an interesting little mess! The names Mispila (Mispila) coomani and Mispila (Dryusa) coomani cannot coexist as valid names, regardless of subgeneric classification. It appears that M. (M.) coomani was moved to that title from Mispila coomani to disambiguate it from M. (D.) coomani, presumably because the mover did not realise that these names cannot both be valid. M. (D.) coomani appears to be a synonym of Souvanna signata (recombined in this recent paper, recognised by Lamiinae of the World), while M. (M.) coomani appears to represent the "real" M. coomani (see Lamiinae of the World). I'm heading to bed now, but if no one else fixes those two pages before I wake up, I'll make the necessary changes tomorrow. I certainly agree that it's not necessary in the title, and can see how encouraging the use of subgenera in article names might lead to problems like this when editors aren't taxonomically savvy. I do think there would be some benefit to discouraging the use of subgenera in article names in the naming conventions to avoid further issues of this nature, but as you say, not exactly a high priority issue. Ethmostigmus 🌿 (talk | contribs) 13:22, 25 December 2024 (UTC)

I've fixed Mispila (Mispila) coomani (now a redirect to Mispila coomani) and Mispila (Dryusa) coomani (now a redirect to Souvanna signata) - cheers for bringing that to my attention. Ethmostigmus 🌿 (talk | contribs) 02:13, 26 December 2024 (UTC)

And YorkshireExpat has moved Cadmus (Brachycaulus) colossus to the binomial so there are no more non-redirect titles, assuming my search picked them all. However, that might not be the case as the search timed out, but I could work out one that didn't.  —  Jts1882 | talk  11:25, 26 December 2024 (UTC)

Found another: Nephus (Scymnobius) sordidus. In 2019, Dyanega moved page Nephus sordidus to Scymnobius sordidus because it's "not in Nephus any more". Then in 2022, Spiderbean moved page Scymnobius sordidus to Nephus (Scymnobius) sordidus with edit summary "corrected genus name". It's not clear from the references which is best supported. Any move will need to be made over a redirect.  —  Jts1882 | talk  16:59, 26 December 2024 (UTC)

Two recent papers back Dyaneda's move to Scymnobius sordidus: doi:10.1649/0010-065X-78.4.467 and doi:10.21829/azm.2024.4012632. —  Jts1882 | talk  17:38, 26 December 2024 (UTC)

Scymnobius is a valid genus, not a subgenus. None of the species in it should be placed in Nephus at this point. As for the topic of this thread, including subgenera in article titles is a very, very bad idea: (1) readers searching for the binomial will not find the expanded-title article unless there is also a redirect - and if there is a redirect, it should be the primary target, since that's what more readers will enter in searches (2) existing direct links will get turned into redirects (3) subgeneric placements change more often than generic placements, meaning article titles including subgenera will be more prone to change, and necessitate a llonger list of redirects to track the history. Subgenera, if they appear at all, should be kept exclusively in the taxobox. Dyanega (talk) 18:29, 26 December 2024 (UTC)