Archive 10 Archive 11 Archive 12 Archive 13 Archive 14

Temporal range

Automatic taxobox/Archive 13
 
Fossil Orontium wolfei
Scientific classification  
Kingdom: Plantae
Clade: Tracheophytes
Clade: Angiosperms
Clade: Monocots
Order: Alismatales
Family: Araceae
Genus: Orontium
Species:
O. wolfei
Binomial name
Orontium wolfei
Bogner, Johnson, Kvaček & Upchurch

Would it be possible to have a line break inserted after "Temporal Range:" in the code? This would reduce the many instances of a actual range being presented on two lines like the example here.--Kevmin § 20:07, 25 December 2012 (UTC)

The user can just include a <br> in the text parameter. {{Fossilrange|lower Eocene|Middle Eocene|<br>[[Eocene|Lower Eocene - Middle Eocene]]}} works fine. Perhaps the documentation for {{Fossilrange}} should mention this. Peter Brown (talk) 22:47, 25 December 2012 (UTC)
Adding the Br code to the template would eliminate that need, and make the overall boxes more standardized, rather then having to run through hundreds of articles to add the code.--Kevmin § 02:41, 26 December 2012 (UTC)
There are hundreds of other articles where "Temporal Range:" and the associated text fit nicely on one line and splitting things up would lead to an awkward appearance. Look at Gerobatrachus, where the line is just:
Temporal range: Early Permian, 290 Ma
Editors have created hundreds of taxoboxes without the line break? Perhaps, in many cases, that is what they intended. The ability to create the break has been there right along. If they did not use the facility, it's not up to those maintaining the template to declare that they were all mistaken. Peter Brown (talk) 03:16, 26 December 2012 (UTC)
As a creator of at least 150 articles on fossil taxa, I can say that any bot for a time period that has a long name (eg Paleocene, Mississippian, Maastrichtian) or is from a longer time period, Carboniferous to Present, will have the split line display. Why should this NOT be fixed with a code patch to the automatic taxobox? I seriously doubt that a display like the box I posted (for an article I am writing now) is the way anyone is intending the temporal range to be displayed.--Kevmin § 05:10, 26 December 2012 (UTC)
Actually, I don't see what is wrong with the taxobox you posted here. If the line had split before the en-dash that would clearly be wrong, but why is it wrong to split the line after it? I don't think this should be automatically "fixed" because, for me at least, it isn't broken. Peter coxhead (talk) 15:33, 26 December 2012 (UTC)
Currently for me at least, the box displays as
"Temporal Range: Early Eocene - Middle
Eocene"
This is not a reasonable place for the break, and for longer names its at other positions in the display. If the display is changed so it shows as this it would solve a large portion of the randmoly placed breaks-
"Temporal Range:
Early Eocene - Middle Eocene"
This places the actual range all on one line with no change in taxobox size in a majority of cases.--Kevmin § 23:06, 26 December 2012 (UTC)
An alternative solution is CSS. {{Fossilrange|lower Eocene|Middle Eocene|<span style{{=}}"display: inline-block">[[Eocene|Lower Eocene - Middle Eocene]]</span>}} works fine, and it could be added to the template if consensus supports it. This is better than <br> because adding <br> to the template would add a line break to everything, even short lines that don't need one. The CSS only breaks after "Temporal range:" when necessary (where "necessary" means "there would be a line break anyway"). Gorobay (talk) 19:29, 26 December 2012 (UTC)

Automatic taxobox/Archive 13
 
Fossil Orontium wolfei
Scientific classification  
Kingdom: Plantae
Clade: Tracheophytes
Clade: Angiosperms
Clade: Monocots
Order: Alismatales
Family: Araceae
Genus: Orontium
Species:
O. wolfei
Binomial name
Orontium wolfei
Bogner, Johnson, Kvaček & Upchurch
Except in extraordinary circumstances, changes to templates should be so designed that they do not affect existing uses. Additional options are fine, but there is no way of surveying editors to see whether they agree to have the expansion of existing instances altered. There isn't even a suitable talk page on which to seek consensus on this sort of issue. That said, Kevmin is correct that there are a lot of taxoboxes with line breaks in inappropriate places. The documentation at {{Fossilrange}} should definitely be updated to say how to avoid this. Peter Brown (talk) 20:53, 26 December 2012 (UTC)
Ah, it doesn't break there for me. Can we define precisely where people consider a break inappropriate? Is it within a multiword period name? Controlling where breaks occur is a better approach than inserting a break as was first suggested. Peter coxhead (talk) 03:43, 27 December 2012 (UTC)

arbitrary editing break

Thats one of the reasons I suggested the line break addition. The current format means the line breaks at different places depending on teh monitor and display setup of the reader. A large portion of the odd braks could be avoided by moving the actual range data to the line below the "Temporal Range:" line. Doing that controls where the break appears in the majority of the templates and you dont have to try to figure where individual range entries are going to need a break. giving a display like the lower box.--Kevmin § 20:25, 30 December 2012 (UTC)
Right now, we have:
On the proposal, we would get:
The additional line break would be useful in some cases. In others, no. Why not let the editors make the decisions, with appropriate information as to what the options are? Perhaps additional tools should be made available to facilitate browser-independence.
Peter Brown (talk) 22:12, 30 December 2012 (UTC)
That structure is due to the fossil parameter being structured like this currently {{fossil range|275|275|[[Leonardian]] stage<br>([[Early Permian]])}}. The break was added by you on the 8th and prior to the break addition it was also displaying a bad break structure. If your manual break was removed it would have this structure
Other then the few examples like the one you made at Tetraceratops I don't know of active addition of breaks in the fossilrange structure. Simply removing your manual break and adding an automatic on to the template code is a much simpler solution. Why not implement, as I dont see it causing any problems.--Kevmin § 04:04, 31 December 2012 (UTC)
Any problems? There will be some problems. I can certainly change the Tetraceratops coding as you indicate, but have you really looked at the wikitext of enough infoboxes to know that the number of perfectionist editors like me, who will think about line breaks and tinker until things come out just right, is so miniscule?
In my opinion
is preferable to
in that the former keeps the taxon's temporal range information together on one line, apart from the taxon's name. Of course, I will defer to any consensus about the taxobox reached at Talk:Hindeodus. Similarly, the appropriate place to discuss changes to the Limusaurus taxobox would be at Talk:Limusaurus.
I have adjusted font size in the examples above, which I specified incorrectly.
Peter Brown (talk) 16:12, 31 December 2012 (UTC)

A look through the categories of two fossil groups Category:Ceratopsids and Category:Brachiopods show a high occurrence of bad line breaks int eh fossil range, and little to no effort to adjust the formatting of individual articles to account for this. Of the articles in category:Ceratopsids 20 have single line ranges, 14 have bad breaks, and one is not applicable. Category:Brachiopods is similar in ratio on single line vs bad breaks with 30 single line ranges and 28 bad breaks, however the category also hosts 25 fossil articles with no ranges at all and 4 articles that are recent genera/species or are not applicable. This shows that there is a significant problem, and there is very little to almost no effort to manually format to avoid the bad breaks.--Kevmin § 19:46, 3 January 2013 (UTC)

Based on the sample, then, single line ranges outnumber those with bad breaks. Is there some way to distinguish the former in the template coding so that they can be left alone? Peter Brown (talk) 20:44, 3 January 2013 (UTC)
They do not outnumber the bad breaks by much, with the overall distributions being very close to 50:50. --Kevmin § 20:51, 3 January 2013 (UTC)
I would oppose a change that increases the number of lines in the boxes of any substantial number of boxes. Half of the boxes with ranges is too many. Peter Brown (talk) 21:03, 3 January 2013 (UTC)
I still have the problem that you haven't defined precisely what you mean by "bad break". The normal way to fix line breaks in the wrong place in web pages is to insert non-breaking spaces, not to force breaks where they aren't needed. For example, "Temporal range: Leonardian stage (Early Permian)" could be output as "Temporal&nbsp;range: Leonardian&nbsp;stage (Early&nbsp;Permian)" if the objection is to breaks within compound geological period names. I don't object to a break between "stage" and "(Early" – do you? Peter coxhead (talk) 21:10, 3 January 2013 (UTC)
A bad break is a break that happens in the middle of geological names or in the middle of temporal ranges. For half of the boxes out there the box is already utilizing two lines and will no matter where nonbreaking spaces or the br code is placed simply due to the length the the information displayed. Another portion are not on two lines due to imprecise age data, "Cretaceous" as opposed to Turonian - Maastrichtian. I proposed the beak addition before the outputted data since half the boxes are using the two lines anyways, and the info doesnt have to be split up if id doesnt need to be.--Kevmin § 22:16, 3 January 2013 (UTC)
Doesn't that solve the problem, though? Lower&nbsp;Eocene&nbsp;-&nbsp;Middle&nbsp;Eocene gives you just what you want without forcing a break after "Temporal range:", as follows:
Peter Brown (talk) 23:07, 3 January 2013 (UTC)
So you would much rather force editors into complex manual coding of the temporal range, rather then add a single instance of br code to the box code that solves the problem without 4 instances of nonbreaking spaces in the output???--Kevmin § 23:11, 3 January 2013 (UTC)
Heavens, no! Can't the template add the instances of &nbsp;? I am very ignorant of template coding, but I know that they can be made to do all sorts of fancy things. It does, of course, have to be programmed so that it leaves a normal space before "(Early Permian)" and probably before numbers as in "269–252 Ma". I'm not prepared with detailed specifications, but this does seem a way of solving your problem while leaving Hindeodus and Limusaurus as they are. Peter Brown (talk) 23:29, 3 January 2013 (UTC)
The template can't add &nbsp;, but it can use CSS to do a similar thing. See my previous comment, above. Use the {{{PS}}} parameter for notes like "(Early Permian)" or "269–252 Ma". Gorobay (talk) 01:41, 4 January 2013 (UTC)
We should have paid more attention to you earlier! I don't understand your code but it works fine; let's go with it.
I don't understand the point of PS=, though; why not tack things on to the end of the "text to display" instead of using a different parameter? Peter Brown (talk) 03:37, 4 January 2013 (UTC)
My proposal is to edit {{Geological range}} to wrap {{{prefix}}}, {{{3}}}, and {{{PS}}} each in <span style="display: inline-block">...</span>. This will prefer line breaks between inline blocks to within inline blocks. The template just displays the contents of those three parameters in order. In order to get a preferred line break before "(Early Permian)", it must be in a separate inline block; that is why {{{PS}}} is necessary. So you put the first part ([[Leonardian]] stage) in {{{3}}} and the second part (([[Early Permian]])) in {{{PS}}}. Gorobay (talk) 13:02, 4 January 2013 (UTC)

The template could quite easily be altered to add the CSS to produce a "non-breaking span" of text. However, I don't think there's a consensus for preventing all breaks in the way that you Kevmin wants. I'm opposed to forced breaks: they are a bad idea since they only produce sensible layout when viewed with a limited range of page widths and font sizes. Peter coxhead (talk) 12:54, 4 January 2013 (UTC)

My proposed CSS does not prevent all breaks. It prefers breaks between {{{3}}} and {{{PS}}}, but if those parameters are too long it will still break within them. Gorobay (talk) 13:02, 4 January 2013 (UTC)
Perfect. Agree. Peter Brown (talk) 15:46, 4 January 2013 (UTC)
Illustrations: in my browser, Gorobay's use of "inline-block" yields:
with no break,
with one break, and
with two breaks. All I have changed between these is the text and the background color. Peter Brown (talk) 21:54, 4 January 2013 (UTC)
@Gorobay: apologies; careless wording on my part – the "you" above was supposed to be Kevmin. I've corrected my comment. Peter coxhead (talk) 22:44, 4 January 2013 (UTC)

Is there consensus to make this change to {{Geological range}}? Gorobay (talk) 23:06, 19 January 2013 (UTC)

No-one seems against your suggestion, so be WP:BOLD and do it! Peter coxhead (talk) 02:14, 20 January 2013 (UTC)

Deleting a genus?

The genus Drymonema appears as a child of the family Cyaneidae. This is incorrect. I have attempted to change it's parent but it still appears on the page.LieutenantLatvia (talk) 03:58, 17 May 2013 (UTC)

This is a perennial problem, in my experience, with relying on the automatic display of child taxa. The list of child taxa has to be generated by a tool which is external to Wikipedia. Sometimes this seems to stop running and the list doesn't get updated, which is what is happening just now. I have edited the taxobox at Cyaneidae to say "see text" instead of the incorrect genera list. Peter coxhead (talk) 21:59, 17 May 2013 (UTC)
(Sorry I took so long to respond) Thanks. I don't really like the taxobox, it's pretty annoying sometimes. LieutenantLatvia (talk) 22:44, 22 May 2013 (UTC)
We differ over the automatic taxobox, which I think is extremely useful in ensuring consistency. But I recommend explicitly listing child taxa; ideally I prefer to put "See text" here and then list and discuss in the text, since there are often differing views on which lower taxa are included in a higher taxon. Peter coxhead (talk) 10:23, 23 May 2013 (UTC)

Second conservation status

Like the other taxobox template, could we please add a second conservation status option, as seen in the article Sunda slow loris. I think it's important that we note not only a species IUCN status, but also their CITES status, particularly with how much illegal wildlife trade is going on. I tried adding a second status to the Gray mouse lemur article here and got this result. – Maky « talk » 00:29, 25 May 2013 (UTC)

I think this is an obviously good idea, but there are already problems with this template's consumption of resources. Ideally it would first be converted to Lua, as is happening with other templates. Peter coxhead (talk) 19:40, 25 May 2013 (UTC)
I don't know anything about Lua and the template conversions. I take it this is a big thing and not likely to happen anytime soon? – Maky « talk » 05:22, 26 May 2013 (UTC)
For what Lua is, see Lua (programming language). Heavily used templates are being converted from the "Wiki template language" to the much more efficient Lua. For example, Module:Citation and its associated pages have been converted already (as shown by the use of "Module:" rather than "Template:"). I believe there is an intention to work on converting the automatic taxobox system. This would allow a number of improvements to be made, which at present are held up. As it's coded now, the system has a history of running into problems with resource usage, making it somewhat problematic to add more features. Peter coxhead (talk) 21:13, 27 May 2013 (UTC)

Edit request on 27 July 2013

It looks as though the automatic taxobox is broken on many pages. Pages such as Finch and Sparrow have markup in the box when they should be in the html tag. Julian the Shadow | ( Talk | Contribs) 18:48, 27 July 2013 (UTC)

It looks fine to me; I've disabled the edit request for now. What browser are you using? — Mr. Stradivarius ♪ talk ♪ 05:07, 28 July 2013 (UTC)

Strange taxobox formatting when Neomura is at the top

Maybe this is a well-known problem and I'm strolling into a biological thicket here, but I have noticed that the link to Neomura is broken in the Ancestral taxa box of many Taxonomy templates, such as Template:Taxonomy/Eukaryota and Template:Taxonomy/Plantae. Instead of a link, it looks like two open brackets, then a newline, then "Neomura" (text only), then two closing brackets. I've tried to figure out how to fix it, but it's beyond me. Anyone up for trying to fix this one? At first glance, it looks to me like one fix will correct this problem in 300+ taxonomy templates.

I have also noticed that the problem templates all appear to be included in Category:Pages where expansion depth is exceeded. I don't know if that's a coincidence. – Jonesey95 (talk) 05:02, 11 August 2013 (UTC)

I doubt it's a coincidence - it looks very much like the fallback behaviour that MediaWiki uses when something has gone over the transclusion depth limit. (I haven't tracked down the exact template that has failed, though.) Probably the best way to fix it would be to rewrite the whole thing in Lua, but that would of course take quite a lot of work. — Mr. Stradivarius ♪ talk ♪ 05:27, 11 August 2013 (UTC)
There's long been a problem with the automatic taxobox system exceeding the expansion depth limit. User:Wikid77 fixed this to a large extent, but one fix was to hard code the top levels of the trees of life (in {{Taxobox/taxonomy/ex3}}). The behaviour of a taxon above those hard coded there may be a consequence. I'll leave a note on his talk page.
Is there a consensus to use the Neomura clade? Has this been discussed anywhere? The deep phylogeny of life is still very disputed. Peter coxhead (talk) 07:52, 11 August 2013 (UTC)
  • FIXED by hiding top line in {Taxonomy/Neomura}: I edited Template:Taxonomy/Neomura and fixed the broken wikilink by commenting out the top line, which had caused the extra newline (in the wikilink): "<!--... <noinclude>{{pp-template}}</noinclude> -->". That Template:Taxonomy/Neomura calls itself to display the "Ancestral taxa" which can be very confusing, because extra blank lines inside the template are the cause of newlines in other templates used by the template. Such convoluted processing is well-known to be confusing, and in formal software development, there would likely be coding standards (rules) to prohibit writing markup which invoked itself unless specifically required by the algorithm(s) and documented to alert others. The problem was not related to the expansion-depth limit, since the broken wikilink was also displayed when not exceeding the limit. I regret how all those Taxobox subtemplates are so confusing, and it would take weeks, or months, to properly document each template, each page, for other users to better understand the twisted connections. Also, I suspect most of the Taxobox templates cannot be rewritten in Lua script, for lack of dynamic module names, plus with Lua, a change to one taxon would require the reformatting of all pages which used any part of the Taxobox system, rather than just the fewer pages which used the specific taxon template. Long-term, I am still requesting the MediaWiki developers to increase the pitiful expansion-depth limit from the tiny 40/41 to 50, 80 or 200, along with fixing wp:edit conflicts, which are trivially easy to auto-merge in most cases (adjusting diff3.c for simple cases of weave merge). I regret that the world's other computer scientists had not helped to solve these problems years ago, for worldwide wiki technology, or perhaps they tried and were rejected. Overall, it is a sad case of a major online encyclopedia being limited by lack of computer technology understood 20-30 years ago. -Wikid77 (talk) 11:00, 11 August 2013 (UTC)
    Yes, that fixed the templates displaying this behavior. Some of them need a Null Edit to update their formatting. Nice work. – Jonesey95 (talk) 11:58, 11 August 2013 (UTC)
    Yes, well spotted Wikid. :) Interestingly enough, that means that this template has been broken since January 2011. Although as Wikid says, it's hard to work out how all the templates interact with each other, so it could be that the error was made visible by a more recent change to a different template. As to Lua, it is possible to have dynamic module names, with code such as this:
local moduleToUse
if someVariable == true then
    moduleToUse = require( 'Module:Module A' )
else
    moduleToUse = require( 'Module:Module B' )
end
So there's no reason that we couldn't have a main module with a system of submodules, like with the current taxobox templates. In addition, it would probably require less pages do get the desired result, as Lua modules (unlike templates) can have more than one function per page. — Mr. Stradivarius ♪ talk ♪ 12:59, 11 August 2013 (UTC)
One factor in the confusing coding of the automatic taxobox system (and it is indeed confusing) is that recursion isn't allowed in the wiki template language, so various tricks have been used to replace the obvious recursive algorithms which would normally be used to traverse trees.
Would it be possible to write Lua code which processes the existing "Taxonomy/TAXON" templates as data? This strikes me as the best medium term solution. Peter coxhead (talk) 11:58, 12 August 2013 (UTC)

Extracting data from Wikidata

Hello! In the basque version of this template we're now extracting some data from wikidata, as the authority, range map and image. This makes the taxobox even more automatic. -Theklan (talk) 12:58, 2 September 2013 (UTC)

Besides making it more difficult to edit, what are the advantages of having this data in a template rather than in the article itself? I can't imagine that the data would be used on any pages save the one specific to that taxon. Martin (Smith609 – Talk) 14:40, 2 September 2013 (UTC)
For example, if after IUCN3.1 we have another one (let's say IUCN3.2) and this data is changed automatically in Wikidata, all wikipedias with the automatic call will have it up to date. More: if when we make the article there's not a range map of this same species and let's say a guy from the japanese wikipedia makes one and Wikidata has it... them it will automatically appear. Another one: every day some photo of a species is uploaded, and sometimes there wasn't anyone before, so the image will be inserted automatically. And, of course, this are verified data, so you don't need to edit them. AND... if you want to edit it, you can supersed them easily: define image = and then your image will be the first one, not the Wikidata one. -Theklan (talk) 15:18, 2 September 2013 (UTC)
Images and range maps can largely be personal choices. I wouldn't want a template to automatically shuttle in those fields from wikidata when those sorts of things should be reviewed for mistakes. I'm okay with some automation where necessary and extremely helpful, but this would go too far in eliminating the usefulness of the watchlist and page watchers for new errors introduced this way (e.g. a misidentified species photo is entered into wikidata simply because the file was named a certain way but it clearly is a different species). Authorities, too, can have their pitfalls - how would the template recognize a page has been moved to a new name, e.g. a subspecies was elevated to species. Would this require a move of the wikidata page, too? What if not all wikipedias agree with the new interpretation and don't want the subspecies article reinterpreted as a species article? This is asking for a lot of cross-wiki collaboration that I just don't see happening. It's best to keep control of these functions local, in my opinion. Rkitko (talk) 20:02, 2 September 2013 (UTC)
I strongly agree. Taxoboxes embody subjective choices of classification. Even authorities, especially if interpreted to include some of the regularly used qualifiers, like "nom. superfl." or "auct.", incorporate opinions. The body of an article can and should explain different choices made by reliable sources, but taxoboxes get very confusing if they try to reflect multiple opinions, so we usually have to choose one. There's no a priori reason why all wikipedias should agree on the choice. Peter coxhead (talk) 21:17, 2 September 2013 (UTC)
Thanks; I especially like your last sentence there. To be fair, the large majority of authorities will be simple, clear, and without ambiguity, but robust implementation of such a plan should be able to account for such exceptions and I see no immediate solution to those except for the suggested parameter that would override the wikidata one, which is just adding layers of complexity for little gain. I see no reason and no benefit to automating any other parameters beyond what the automatic taxobox does. If anything, our effort should focused on drumming up support for this template and continuing to roll it out. If it's not widely used, what is its utility if only 5% (random number) of rosid articles use it and at the next major widely adopted classification shift you still have to make thousands of manual taxobox edits? (Speaking of... I still need to finish updating manual taxoboxes to APG III...) Rkitko (talk) 22:47, 2 September 2013 (UTC)
These are not verified data. Wikidata sources to various Wikipedias. It is useless, making no benefit to weighing down en.Wikipedia with unsourced information from foreign language Wikipedias that do not require reliable sources. -AfadsBad (talk) 23:41, 2 September 2013 (UTC)
Wikidata is as reviewed as en:wp. Nowadays all range maps and articles images have been extracted from this same Wikipedia, and in eu:wp, where our taskforce is smaller, we benefit from that work. You could do exactly the same with, let's say, french or german Wikipedias, where revision standards are VERY high. -Theklan (talk) 07:24, 3 September 2013 (UTC)
Don't get me wrong; I'm not criticizing other language Wikipedias. But there are different traditions and different choices, which are in their own ways legitimate, but are different. I've used translations from the German Wikipedia here, but quite a bit of work is needed to bring them up to our standards of inline referencing – they make much more use of lists of sources than we do. They also have a different convention for monotypic taxa. Compare Amborella with de:Amborella tricopoda, for example, to see both kinds of difference. Peter coxhead (talk) 08:57, 3 September 2013 (UTC)
That doesn't invalidate the topic I'm discussing here. You can use Wikidata for when there's not YET a range map, for example. And when this come to live, it will be added automatically. If you don't agree with that range map, you can create your own and put it, the wikidata one will disappear. Or even better, you can change it in Wikidata, so all Wikipedias will take advantage of it. -Theklan (talk) 13:21, 3 September 2013 (UTC)
Wikidata is not "as reviewed as en:wp." I went to Wikidata to start adding sources for botanical authorities to Wikidata items simultaneous with adding them here. However, I see that on Wikidata botanical taxa may have citations to other Wikipedias, for example, a plant family's authority may be cited to German Wikipedia, but German Wikipedia doesn't have a citation for the authority. This means that Wikidata makes it appear as if it has citations, when the citations are simple ties to uncited information in other language Wikipedias. They have no intention of changing this; I asked. While this is the case at Wikidata, we should not be automatically tying anything in en.wp to Wikidata items, and we should use extreme caution before getting information from Wikidata (as should the public and all other Wikipedias). If it ever becomes a real database with sources rather than a collection of circular references, this would be a good idea for some things, although not all. For now, not a chance. --AfadsBad (talk) 14:10, 3 September 2013 (UTC)

I think this should be closed. I don't see how the Basque Wikipedia can be extracting the authority, because Wikidata does not define a single taxon, rather a taxon is all such groups or clades that have been under that name. A taxon name applied to a clade by one authority is different from the same name applied to a different clade by a different authority. It is impossible to discern, from a Wikidata page, what taxon is meant. And, because the taxon name applies to various groups and clades, there are multiple parent taxa for a single taxon.

For these reasons, until Wikidata figures out what a taxon is, there is no way that data about taxa can be extracted from it automatically and used on en.Wikipedia. I suspect it should not be used on any language Wikipedia. --(AfadsBad (talk) 17:22, 11 September 2013 (UTC))

Indeed you can use the data from Wikidata to insert range map, image and IUCN3.1 status for all species. This data is extracted mainly from en:wp. So for eu:wp is very very very very useful, as we don't have your taskforce. -Theklan (talk) 21:39, 16 September 2013 (UTC)
Many of the "species" in Wikidata are based on severely outdated information automatically compiled from places like Swedish Wikipedia (which had a bot create several hundred thousand species articles based on the ITIS database). The statement that "Wikidata is as reviewed as en:wp" simply isn't true, at least not currently. I would hesitate to use them as a source for any taxonomic data until they having some sort of sourcing information to back it up (from somewhere other than ITIS). Kaldari (talk) 07:26, 17 September 2013 (UTC)
I entirely agree. Peter coxhead (talk) 10:34, 17 September 2013 (UTC)
Unfortunately the entire Wikidata is currently a disaster and extracting any information, authorities, for example, is problematic, because the data are entirely screwed up. For example, the taxon Alismataceae Vent. at Wikidata is cited to APG III (2009) for the authority, but APG III includes a new family circumscription. Wikidata then lists three possible parent taxa, Alismatales with five possible sources, including APG III, APG II (2003), and 1998, 1997, and 1981, Holobiae (1935), and Apocarpae (1862 to 1883). If the taxon in Wikidata is Alismataceae Vent. as circumscribed in APG III, then it is not the taxon with the parent taxa listed in various publications from 1862-2003. Alismataceae Vent., circumscribed by APG III, and its parent taxon is Alismatales, sourced only to APG III of the 7 sources listed. To extract data for this taxon would require a link or citation to the source of the data as Wikidata, and that would take you to a completely useless database. --(AfadsBad (talk) 08:22, 18 September 2013 (UTC))

How to add authority to automatic taxobox

I would like to know how to add an authority to an automatic taxobox without reading multiple wordy paragraphs describing and justifying anything else. I just want to add the authority, and I don't want to have to search for how to do it every time.

Can someone explain how to do it? Provide a link to just the instructions on how to do it? --(AfadsBad (talk) 04:50, 9 September 2013 (UTC))

And to a speciesbox? --(AfadsBad (talk) 05:03, 9 September 2013 (UTC))

Just add the line "| authority = Smith 1999" anywhere within the taxobox / speciesbox in the article that you are editing (where Smith 1999 is the authority). Martin (Smith609 – Talk) 08:58, 9 September 2013 (UTC)
But not, of course, the date for a plant... Peter coxhead (talk) 10:03, 9 September 2013 (UTC)
If an article is or family, genus, and species, what do I add? And I am trying to add citations to the authorities, also. --AfadsBad (talk) 12:17, 9 September 2013 (UTC)
See Aphyllanthes as an example. Peter coxhead (talk) 18:32, 9 September 2013 (UTC)

Two questions about display children

Hello! In basque Wikipedia we're using extensively this automatic taxobox, as it reduces the work. I've notices that if one taxos has lots of daughters, for example in a big genus, we can't see them all. I think there's a limit of about 20 or something, you can see it here. So is there any other way so we can show all of them?

And second question, is there any way we can have the child taxa generator bot working in the basque Wikipedia? -Theklan (talk) 15:54, 6 October 2013 (UTC)

Ghost in the machine?

Does anyone know why "help me!!!! call 911" etc. appeared in the taxobox as a result of this edit? PaleCloudedWhite (talk) 21:32, 8 October 2013 (UTC)

The template was vandalized. [1] --(AfadsBad (talk) 21:38, 8 October 2013 (UTC))
Thanks. PaleCloudedWhite (talk) 21:51, 8 October 2013 (UTC)

Sphaerotheca (frog)

How do I create the entry for "Sphaerotheca (frog)"? Micromesistius (talk) 17:59, 25 January 2014 (UTC)

False {{error}}s

Template:Taxonomy/ says "Deleting this placeholder template will raise false errors with Template:Taxobox, through Template:Taxobox/taxonomy cell."

But the inclusion of the line {Placeholder {{error|error message}}. in that template seems to me to itself generate false errors.

I would like to be able to check what transcludes template:error for errors that need human attention to correct them, but because of the fog of false error transclusions by articles using taxoboxes—I think Template:Taxonomy/ is the culprit—it is very difficult to find true error transclusions in article space. Can this template be fixed to only transclude {{error}} when there truly is an error? For more background on my research into this, see Template talk:Requested move#template:error. Thanks, Wbm1058 (talk) 23:39, 18 February 2014 (UTC)

It looks like this did the trick. I tried making a null edit to Amphibian after that change, and it was removed from Special:WhatLinksHere/Template:Error. — Mr. Stradivarius ♪ talk ♪ 05:29, 19 February 2014 (UTC)
Thankyou very much for that edit Mr. Stradivarius. That method of course not only eliminates the false positives, but any true positives that might be there as well. Ideally a technique can be devised that would still transclude the true positives, but that will need to be done by a template editor more familiar with the operation of the complex taxobox template system. We are down to about 125 mainspace {{error}} transclusions now, some of which are true errors that I've fixed, and I'm confident that the rest of these can be addressed as well. Wbm1058 (talk) 12:55, 22 February 2014 (UTC)

Removing italics

The automatic taxobox at bee is wrongly italicising the name of the taxon Anthophila. How do I ensure that the taxon name is displayed correctly, and not in italics? Thanks. Anaxial (talk) 12:50, 12 April 2014 (UTC)

See Template:Taxonomy/Anthophila—it's a series, which show up as italics, presumably because of Series_(botany). I have no idea why Anthophila is a series, or what it means for a non-plant taxon to be a series? ErikHaugen (talk | contribs) 05:22, 16 April 2014 (UTC)
I changed it to "unranked"; I'm not sure if that is the best solution though. ErikHaugen (talk | contribs) 05:29, 16 April 2014 (UTC)
I have marked it as a clade since this is a non-Linnean group name. There is a genus Anthophila in the family Choreutidae to deal as well. Shyamal (talk) 09:53, 16 April 2014 (UTC)

Get data from API

My goodness, I can not get data from this complex template. Don't know where to start and how? Alphama (talk) 08:11, 8 June 2014 (UTC)

Ok I found a way, before just get 1 query, now at least 5 queries. So much time. Alphama (talk) 08:34, 8 June 2014 (UTC)

diversity_ref

The diversity_ref param does not work with the automatic taxobox. I'm currently working on updating the diversity param on all extant ant genera, but without the ref param I'm not feeling that confident in migrating to the automatic taxobox. Would anyone mind adding it to the template? Examples: Automatic taxobox/Taxobox. jonkerztalk 19:12, 26 July 2014 (UTC)

Please add line 2 with the diversity_ref to Template:Automatic taxobox; it was copied from Template:Taxobox. Working demo: Template:Automatic_taxobox/testcases.
| diversity = {{{diversity|}}}
| diversity_ref = {{{diversity_ref|}}}
| diversity_link = {{{diversity_link|{{{diversity link|}}}}}}
Thanks, jonkerztalk 13:37, 18 August 2014 (UTC)
  Done (I allowed "diversity ref" as well, i.e. without the underline.) Peter coxhead (talk) 13:52, 18 August 2014 (UTC)
Thank you, Peter coxhead! It works like a charm. Could you make the same change to Template:Speciesbox as well? It has the same issue. jonkerztalk 13:57, 18 August 2014 (UTC)
Well, can you comment on this first, please. I'm not sure that you're always using the "diversity" parameter appropriately – for example at Poecilomyrma. My understanding is that where there are a few species then the genus taxobox can actually list them, using the "subdivision" parameters. This is what I would do there. Where the genus article lists the species but they aren't listed in the taxobox, then "See text" is commonly used, against a subdivision rank. I think "diversity" is really meant to provide a summary in cases where there are too many subtaxa to list in the article so there's a separate "List of ..." article. Peter coxhead (talk) 14:04, 18 August 2014 (UTC)

Then I have a couple of articles to fix :/ I prefer to list the species in a section and use diversity/diversity_ref as a place to add number of species and a reference for the species list. It leaves room for adding author citations and comments such as common name/distribution, and using the taxobox for the number of species/ref avoids short sentences such as "Dinoponera contains 8 species.[5]".

Is there any way to add number of species + a refernce to the taxobox? jonkerztalk 15:09, 18 August 2014 (UTC)

I guess there isn't any real difference for a genus taxobox between a heading Species followed by link "See text" and a heading Diversity followed by a link "N species", except that the latter has some redundancy – if someone adds more species to the list in the text, will they remember to update the taxobox?
It's probably not a good idea to have yet more options in taxoboxes! If you want to do it this way, stick to "Diversity", but I agree there should normally be a reference.
So for a species (i.e. {{Speciesbox}}) you want to be able to add the number of subspecies with a reference? Well, given that |diversity= is there, |diversity_ref= should be too, so I'll fix it. Peter coxhead (talk) 16:31, 18 August 2014 (UTC)
I agree, using the |diversity= param is not the best solution, but since this type of data will likely be moved to Wikidata at some point, updating all articles before that may not be worth the effort. If the community thinks it is, I'll do it. Thank you for taking care of the infobox parameters. Cheers, jonkerztalk 16:41, 18 August 2014 (UTC)
Well, I am utterly opposed to picking up this kind of information from Wikidata. The number of species in a genus is not "data", it's a taxonomic opinion. In a Wikipedia article we can provide different accounts, discuss reasons, add new dissenting views if they appear in reliable sources, etc. Wikidata can't do this. See Talk:Ophrys#Number of species for a somewhat extreme example. Re spiders, consider Meta. The taxobox says there are 39 species, but that depends on the source, and on whether you're a splitter or not. The Checklist of British Spiders, like the Wikipedia articles, separates out Metellina, but Roberts, for example, includes Metellina in Meta, upping the count. The World Spider Catalog has only 34 species of Meta. It's not even agreed as to what family Meta belongs to – reliable sources use Metidae. And so it goes. All our articles should do is to say something like "As of DATE, RELIABLE_SECONDARY_OR_TERTIARY_SOURCE accepts N species" with a reference – and often followed by "Whereas, " and the same pattern of information. Peter coxhead (talk) 19:32, 18 August 2014 (UTC)
Yes, of course it is opinion, but I'm talking about keeping the number of species per The Checklist of British Spiders and The World Spider Catalog, and possibly a field for "number of species per the consensus on Wikipedia that it is recommend that most Wikipedia-language editions should use with links to discussions and external resources". But I digress... Re "As of DATE, RELIABLE_SECONDARY...", this is why I prefer to have the ref in the taxobox, it is not exactly the same but it will give the reader the source and a date; many articles only have an undated external link to some website or even no source at all! jonkerztalk 19:48, 18 August 2014 (UTC)
On the inadequacies of many existing articles we can certainly agree. :-) Peter coxhead (talk) 20:14, 18 August 2014 (UTC)

Taxobox taxon in text?

Is it possible to automatically grab a taxon from an automatic taxobox and insert it in the text with some generalized markup saying which taxon to use?

'''''Species''''' is a species of [[moth]] of the [[<insert family here>]] family.
[[Category:<insert subfamily here>]]
{{<insert family here>-stub}}

Then if the taxonomy changes, the generalized markup would allow the taxa to automatically change in these parts of the text, saving thousands of individual edits of pages.

Dead dinosaurs

Shouldn't {{Taxonomy/Dinosauria}} be extinct=true? I thought birds were part of Aves, and there weren't any more dinosaurs. (I may be wrong — I'm no expert.) --h2g2bob (talk) 23:52, 25 January 2015 (UTC)

@H2g2bob: Sorry for the late reply. To answer your question, no the clade Dinosauria is not extinct as the class Aves is a member of the Theropod dinosaurs. Rkitko (talk) 18:04, 7 February 2015 (UTC)

Hovering over red pencil icon shows hovercard for e.

When you hover over the red pencil icon, it shows the hovercard for e. I'm not sure why this is, because clicking it doesn't take you to the article e, but could this be fixed anyway? Seen at Anopheles. User:GKFXtalk 17:21, 7 February 2015 (UTC)

Sure. I don't think there was a specific reason for just the "e" alt text other than it is commonly seen in navbox templates next to "v" (for view) and "d" (for discuss). Instead of e, should it say "Edit" or "Edit this classification"? If we make any changes here, we should do the same for {{Speciesbox}}, {{Subspeciesbox}}, {{Infraspeciesbox}}, {{Ichnobox}}, and {{Oobox}}. Rkitko (talk) 17:58, 7 February 2015 (UTC)
Sorry, I was unclear. I don't see "e" as alt text, I see the hover card for the article e, as described at https://m.mediawiki.org/wiki/Beta_Features/Hovercards. It looks like the link is in some way simultaneously a link to e and to the intended destination: the link to e should be replaced with alt text, which I think is what was intended. User:GKFXtalk 18:11, 7 February 2015 (UTC)
Oh, no, you were clear. I just misunderstood. I can't stand hover cards, so I must have disabled them at some point. All I see is alt text that says "e". The problem might be in {{Edit taxonomy}} that is called by this template. Or it could be in {{Taxobox/core}}. I had a go at the problem even though I'm not that familiar with template coding. Tell me what you see now at {{Automatic taxobox/sandbox}}. When I hover over the red pencil image in the upper right, all I see now is "Edit this classification" alt text. Rkitko (talk) 18:31, 7 February 2015 (UTC)
I'm on mobile now, so I can't test. I'll have a look later. Thanks for your help. User:GKFXtalk 18:43, 7 February 2015 (UTC)

Help correct "Pentecopterus" taxobox?

I'm *very new* with the "automatic taxobox" - I've tried but, so far, I've been unable to correct the "automatic taxobox" in the "Pentecopterus" article (details described below) - any help with this appreciated - in any case - Enjoy :) Drbogdan (talk) 13:53, 2 September 2015 (UTC)

Copied from "Talk:Pentecopterus":

Subject: Family: Megalograptidae - not Pterygotidae?

Seems the extinct family of eurypterids of "Pentecopterus" may not be the "Pterygotidae" family as currently presented - but may be the "Megalograptidae" family instead, according to the original published study[1] - if so, any help in correcting the article would be welcome - and appreciated - in any case - Enjoy! :) Drbogdan (talk) 13:30, 2 September 2015 (UTC)

References

  1. ^ Lamsdell, James C.; Briggs, Derek E. G.; Liu, Huaibao; Witzke, Brian J.; McKay, Robert M. (September 1, 2015). "The oldest described eurypterid: a giant Middle Ordovician (Darriwilian) megalograptid from the Winneshiek Lagerstätte of Iowa". BMC Evolutionary Biology. 15 (1): 169. Bibcode:2015BMCEE..15..169L. doi:10.1186/s12862-015-0443-9. PMC 4556007. PMID 26324341. "The new eurypterid species is described as Pentecopterus decorahensis gen. et sp. nov.. Phylogenetic analysis places Pentecopterus at the base of the Megalograptidae, united with the two genera previously assigned to this family..."
{{done}} - the problem seems to have been solved at the moment - checking to be sure all's ok would be welcome of course - iac - Enjoy! :) Drbogdan (talk) 14:48, 2 September 2015 (UTC)

Why are automatic taxoboxes broken on plant articles?

As far as I can tell, the automatic taxobox and speciesbox templates are broken only on plant articles, e.g. [2] and Levenhookia dubia. I've looked around but I don't see any edits that would cause this... Ideas? Rkitko (talk) 15:09, 26 July 2015 (UTC)

Ah, found it. It was this edit at Template:Taxonomy/Plantae. When the parent was updated from Eukaryata to Archaeplastida, the taxoboxes were showing odd code where the title and taxobox color should have been -- something like "colspan 2...". Is this part of the depth issue? The number of taxa steps between species and Eukaryata is just too long? Rkitko (talk) 15:22, 26 July 2015 (UTC)

Tarantula taxobox shows an error

For some reason, the tarantula (Theraphosidae) taxobox has the characters "familia hung cnughug" in place of "Family". Just "Familia" would be acceptable, though inconsistent, but I can't find any meaning for the other characters.

Sorry I can't be more help detecting the cause, but I thought I should at least report it. Syzygyczg (talk) 14:05, 5 August 2015 (UTC)

  Done It was caused by vandalism to Template:Taxonomy/Theraphosidae. If it happens again, you need to revert any such edits there. Peter coxhead (talk) 14:43, 5 August 2015 (UTC)

How to add reference to binomial name for speciesbox?

I converted the taxobox at Yellow-spotted lizard to a speciesbox but I couldn't figure out how to include the binomial name ref, so I ended up moving it into the article. Is there a better way to do this? Augurar (talk) 05:28, 17 October 2015 (UTC)

Well, actually the reference is really in support of the English name. The taxbox target is the name Lepidophyma flavimaculatum; what needs sourcing is that this species is the one called "yellow-spotted lizard". So I think the placement of the reference in the article is correct.
What does need sourcing in the taxobox is the authority: how do I know that "A. Duméril, 1851" is correct?
Of course the whole of the rest of the article needs sources. Peter coxhead (talk) 08:22, 17 October 2015 (UTC)

Removal of links to tool and bot no longer running

Prior to 2013, some parts of the automatic taxobox system used a tool, http://toolserver.org/~verisimilus/Bot/taxobot/, and a bot, Taxobot, to maintain information on the children of taxa that have taxonomy templates (i.e. taxa that have templates with names of the form "Template:Taxonomy/TAXON_NAME"). The tool and the bot haven't been running since 2013, so any information currently stored about child taxa is incomplete and often inconsistent. I have attempted to disable those parts of the system which link to child taxa data. "Attempted" because the automatic taxobox system is very complex, and hence tricky to modify.

If anyone notices any problems apparently due to these edits, please notify me a.s.a.p. Peter coxhead (talk) 18:49, 18 October 2015 (UTC)

 
Missing 'Genera' text
Hi Peter, I have temporarily reverted your edit as it caused the child taxa ranks ("Families") to disappear at https://en.wikipedia.org/wiki/Priapulidae. (I am agnostic as to whether or not the edit is a good idea, so please don't interpret this as a comment on your motivations.) Martin (Smith609 – Talk) 08:52, 22 October 2015 (UTC)
See below. Peter coxhead (talk) 17:45, 22 October 2015 (UTC)

display children parameter

The changes mean that |display children= no longer works. In many cases it displayed odd and inconsistent information. As an example, consider the class Bivalvia. The child taxa set up by Taxobot when it was running between Jan 2011 and Jan 2012 are: Anomalosdesmata, Cryptodonta, Euprotobranchia, Heterodonta, Palaeoheterodonta, Palaeotaxodonta, Paleoheterodonta and Pteriomorphia. These make no sense as a set of subclasses: "Paleoheterodonta" is an alternative spelling of "Palaeoheterodonta"; "Euprotobranchia" is a grade from an entirely different classification system with only four subclasses (one of which isn't present at all, but wouldn't fit if it were).

Subdivisions should be set up manually in a taxobox, whether automatic or not, and maintained there so they can be kept in step with the taxonomy used in the article. Peter coxhead (talk) 09:31, 19 October 2015 (UTC)

Surely it is better to correct the inconsistent spellings where they occur, so that articles use a consistent taxonomy? Martin (Smith609 – Talk) 08:49, 22 October 2015 (UTC)
Martin, this is only one small example of the problems that exist throughout the "display children" subsystem.
  • Because the tool and Taxobot haven't worked since 2013, most of the child data is hopelessly out of date.
  • More seriously, although the automated display of children was a clever idea, it simply doesn't work, for a number of reasons, and I wouldn't support fixing Taxobox and the tool.
    • Editors can't be (and shouldn't be) made to stick to one taxonomy where the literature isn't clear – and they don't. Suppose in one system Taxon A is divided into B, C and D, and in another system, A is divided into B, E, F and G, where B is the same in both systems but the others are different. It's perfectly possible (and happens, although usually only partially) to create templates for B, C, D, E, F and G all having A as the parent. Upwards the links work fine, but automatically displaying the children is wrong. To fix the Bivalvia problem is not just a case of deleting Template:Taxonomy/Paleoheterodonta while retaining Template:Taxonomy/Palaeoheterodonta, you must also decide which taxonomy to use, and delete the taxonomy templates of the inconsistent children – but this will mess up taxoboxes in articles using taxa only present in the other taxonomy. (Because only admins can do deletion, obsolete taxonomy templates won't be deleted by most editors.)
    • Since there's never been a consensus to only use automated taxoboxes in most areas of the tree of life, child taxa may or may not have automated taxoboxes employing the same system of classification. Those without will be left out of any generated list of child taxa. The subsystem works well for dinosaurs, for example, since these almost universally use automated taxoboxes based on a more-or-less single system of classification. Coverage of other areas I work in, such as plants and spiders, is very patchy.
    • An assumption made in the automatic display of children is that they will be at the same rank, a rank that can be determined from the rank of the parent. With modern cladistics-derived classifications, this is simply wrong. I've been working on spiders lately. Some clades correspond to previously used ranks, some don't. So phylogenetic trees have clades, superfamilies, families and even genera below nodes. Look at this tree which is probably the current consensus and could usefully be set up in the automatic taxobox system. There's no consistent rank hierarchy, and if |display children= is made available, it would not produce helpful output, nor would automatically supplying a value if |subdivision ranks= is omitted but |subdivision= is present.
So the answer at Priapulidae, as happens in the great majority of automated taxoboxes, is for editors to decide what child taxa, if any, they want displayed in the taxobox, and then insert them and the appropriate rank (including "Clades" or just "Subdivisions" if appropriate) manually. In this way the taxobox and the article can be kept in step. Peter coxhead (talk) 17:45, 22 October 2015 (UTC)
Here's an example of where automatic deduction of subdivision ranks is wrong. In this version of Xiphosura, an explicit list of the subdivisions is provided via |subdivision=. Since |subdivision_ranks= is absent, "Families" is provided automatically by {{Children rank}}. But the children given in the taxobox aren't families but suborders and infraorders. Peter coxhead (talk) 07:11, 23 October 2015 (UTC)

I've restored the removal of the automatic display of child taxa, since these are just too often out of date. However, as User:Smith609 found, my previous edit left cases where |subdivision= was present but |subdivision_ranks= absent without any section heading in the taxobox, which was clearly wrong. I'm currently investigating such cases to see what the best solution may be. If editors had checked the section heading when adding an automated taxobox, this part of the system is useful as a default, but it seems that quite often they didn't. Peter coxhead (talk) 07:44, 23 October 2015 (UTC)

subdivision_ranks parameter

I've been checking taxoboxes which have subdivision set but not subdivision_ranks. One problem I found was that there were quite a few taxoboxes with just |subdivision_ranks= . The version of {{Automatic taxobox}} then in effect only supplied a default value based on the rank of the target taxon if subdivision_ranks was absent, not if it had a blank value, so these taxoboxes ended up with no title for the subdivision section. (I'm surprised that editors hadn't noticed this.) I've now modified {{Automatic taxobox}} so that it generates a default value if subdivision_ranks is absent or has a blank value.

Omitting this parameter, or leaving it blank, should in my view be deprecated, since as noted above, the default value is not always correct. Peter coxhead (talk) 07:22, 24 October 2015 (UTC)

Rank displays as page name not taxon name

How can I stop Tocantinia (genus) from displaying the rank as Genus: Tocantinia (genus), in the taxobox, instead of Tocantinia? --Michael Goodyear (talk) 22:20, 23 February 2016 (UTC)

Don't worry, I figured it out by piping link=. It just seems to take a long time to take effect on the target page. --Michael Goodyear (talk) 22:43, 23 February 2016 (UTC)
A null edit to the page usually works, or else, if you haven't done it already, go to Special:Preferences#mw-prefsection-gadgets and under "Appearance" click the "Add purge option". Then under the "More" tab for each page you get "Purge" which purges the cache for the page and usually makes template changes update. It seems that when a change is made that affects a template, updates to all the pages that transclude it get added to a "to do" list and the server works through them as and when. If it's busy and there are a lot of updates, it can take days. Peter coxhead (talk) 08:17, 24 February 2016 (UTC)

Reptilia is paraphyletic

Reptilia is a paraphyletic group so should not be included in automatic taxoboxes. — Preceding unsigned comment added by How come why not (talkcontribs) 19:17, 14 May 2016 (UTC)

This page is for issues with the operation of the automatic taxobox template and its supporting templates. Questions about actual taxonomy are best asked at the relevant article, where there are likely to be editors with the appropriate knowledge.
Nothing prevents a taxonomist choosing to use a paraphyletic taxon, by the way, and although it seems to be a minority view at present, there are spirited defenses of doing so in the literature. Peter coxhead (talk) 08:37, 15 May 2016 (UTC)
The rank Reptilia, despite being paraphyletic, is currently considered a valid class. I did mark it as paraphyletic, though. עוד מישהו Od Mishehu 17:17, 13 July 2016 (UTC)
Reptilia has also been defined as a clade, either equivalent to Sauropsida or as a crown group (which nowadays would actually be equivalent to Diapsida). So by definition it can't be paraphyletic. Dinoguy2 (talk) 10:19, 14 July 2016 (UTC)
Well, by that definition it can't be paraphyletic, but by the traditional definition, it can. This is the problem with taxoboxes – they can only show one classification, and where there's no consensus, it's a problem. Peter coxhead (talk) 14:19, 14 July 2016 (UTC)
My point is that it doesn't really matter. If you're looking at the taxobox for Iguana, it doesn't matter if the listing for Reptilia is denoting a clade or a class or whatever. The point is there's no reason under either system to remove it. Dinoguy2 (talk) 15:27, 14 July 2016 (UTC)
I have no view about removing it or not; but you do have to say in the taxobox what it is, whether a paraphyletic rank or an unranked clade. Peter coxhead (talk) 18:01, 14 July 2016 (UTC)

Neoaves is not a superorder

Why does Neoaves display as a superorder in automatic taxoboxes that contain it? It's not a superorder, it's five: Gruae, Telluraves, Adeae, Otidae and Columbea. These should be shown as superorders instead. Gruae includes Gruimorphae and Opisthocomiformes, Telluraves includes Afroaves and Australoaves, Adeae includes Aequornithes and Eurypygimorphae, Otidae includes Otidimorphae and Cypselomorphae and Columbea includes Mirandornithes and Columbimorphae. Please correct this. --How come why not (talk) 19:42, 14 May 2016 (UTC)

See my response above. I would ask at Neoaves. Peter coxhead (talk) 08:31, 15 May 2016 (UTC)

Documentation for handling child taxa?

I may have missed it, but I'm not finding anything obvious in the documentation about how to display child taxa in an automatic taxobox. I know I could find an example to copy with a little effort, and (without bothering to expend that effort) I assume that the |diversity parameter is the place for child taxa. Still, it would be good to have this documented somewhere (i.e. Template:Automatic_taxobox/doc/new?). Plantdrew (talk) 03:28, 24 September 2016 (UTC)

@Plantdrew: I'm not quite sure what you mean. You use precisely the same parameters as in manual taxoboxes, and in practice there's the same substantial variation in use. There are two sets of parameters, the subdivision parameters and the diversity parameters.
The subdivision parameters are used either to display a list of taxa inside the taxobox or to link to a list in the article.
| subdivision_ranks = plural of rank name, e.g. "Families", "Genera"; a reference should be put after the rank name when a list is given
| subdivision = either a list of taxon names, or See text., ideally with a wikilink to the section
The diversity parameters are used (again exactly as in manual taxoboxes) to give numerical information, ideally with a wikilink and a reference:
| diversity = number of taxa at the next level or next few levels, e.g. "95 genera, 345 species"
| diversity_link = usually used to link to a list outside the article where one exists
| diversity_ref = reference
Anapidae is an example of the use of both sets of parameters, here with an internal wikilink rather than a list. Peter coxhead (talk) 08:35, 24 September 2016 (UTC)
Create an old-style taxobox in a sandbox, and then convert it as shown at Template:Automatic taxobox/doc/convert. For the many parameters available in the old system, see Template:Taxobox/doc. עוד מישהו Od Mishehu 11:14, 27 September 2016 (UTC)

Pygmy hippopotamus's genus

How do we handle a species where the genus is disputed between 2 different ones? I'm specificly asking about Pygmy hippopotamus, which is aparently disputed between Hexaprotodon (a otherwise extinct genus) and Choeropsis (which only contains the pygmy hippo). עוד מישהו Od Mishehu 13:48, 26 September 2016 (UTC)

Basically, you can't easily deal with variant taxonomies in one taxobox. Choose the best-supported and then discuss the alternative in the text. Peter coxhead (talk) 17:04, 27 September 2016 (UTC)

Typo link to Mammalia somewhere?

Special:WantedTemplates shows 1,273 links to Template:Taxonomy/ Mammalia (note red link and extra space).

This transclusion count shows 1382 transclusions of the misnamed template.

Here's a list of templates that transclude the "space" variant.

I'm guessing that someone made a typo somewhere, but I don't know where it is. Any clues? – Jonesey95 (talk) 18:25, 28 September 2016 (UTC)

Could it be that Template:Taxonomy/Mammalia contains spaces in link=Mammal | Mammalia? Gorobay (talk) 18:42, 28 September 2016 (UTC)
I think this is the problem. The text after |link= is picked up as a numbered rather than named parameter, and its value includes the space between | and Mammalia. I've edited Template:Taxonomy/Mammalia so we'll see if the problem disappears as the change filters through. Peter coxhead (talk) 01:10, 29 September 2016 (UTC)
That seems to have done the trick. A null edit on four of the templates that were calling the "space" template removed them from the list of transclusions of that template. – Jonesey95 (talk) 02:49, 29 September 2016 (UTC)
I fixed a few more on the WantedTemplates list. They mostly looked like errors by people who (understandably) didn't fill in the |link= parameter quite right. – Jonesey95 (talk) 04:46, 29 September 2016 (UTC)

More typos

There is a similar situation to the section above for Template:Taxonomy/''incertae sedis'' and others. See Special:WantedTemplates and scroll through to find Taxonomy templates.

I'll be happy to fix these if someone can point to where the error lies. – Jonesey95 (talk) 18:28, 28 September 2016 (UTC)

If my understanding of the "Mammalia problem" is correct (but the automated taxonomy system is very complex and hence hard to understand in full so I may be wrong), this is a more difficult problem to solve. When the article title is not the same as the taxon name, according to Template:Automatic taxobox/doc/taxonomy pages#link, the required syntax is |link=article title|taxon name. However, by default the system sets up all "incertae sedis" taxonomy templates to have |link=Incertae sedis|''incertae sedis'', implying that there's a taxon named "''incertae sedis''" and hence a template Template:Taxonomy/''incertae sedis''. Peter coxhead (talk) 01:42, 29 September 2016 (UTC)
That looks tricky. I'm going to have to give it some thought. There is probably a workaround. – Jonesey95 (talk) 04:47, 29 September 2016 (UTC)
Ok, given that the solution to the "Mammalia problem" was correct, the quick and dirty fix is to find out where the request for "Template:Taxonomy/taxon name" is generated, and then strip off the quote marks before generating the request. I think the right fix is to change all the taxonomy templates that have |link=Incertae sedis|''incertae sedis'' to |link=incertae sedis and then have "incertae sedis" automatically italicized in the underlying taxobox system just as names at genus level and below are automatically italicized. But this is a lot more work. Peter coxhead (talk) 13:34, 29 September 2016 (UTC)
It looks like we might be able to modify Template:Taxobox/italics to do this, but I would need to dig into the supporting templates a bit to understand the parameters and templates called there. It should not be a big change, but figuring out exactly how to make the change will be some work. – Jonesey95 (talk) 17:12, 29 September 2016 (UTC)
On second thought, it looks like with template editor rights, I can create a redirect, which appears to work just fine. Since the articles and templates were all working, as far as I can tell, creating a redirect to the existing template seems like the path of least risk. I did that. Let me know if it breaks anything. – Jonesey95 (talk) 17:18, 29 September 2016 (UTC)
Ah, good solution! I can't see any problems caused by it. (I will still try to find out where these attempts to access taxonomy templates from the link's taxon name originate.) Peter coxhead (talk) 19:26, 29 September 2016 (UTC)

Taxoboxes which link to their last taxon

{{Automatic taxobox|taxon=Vole}} One feature which I think would be useful for several articles, is to have the final taxon be a link. This would be for attricles which refer to relatively closely related animals which aren't a taxon, e.g Hawk, Vole, Jackal. The best way to handle these (and Vole is handled this way), is to have the taxobox end at the smallest taxon which includes all of them, have a small "in part" below (perhaps using the "autority" field), and possibly use the standard subtaxon fields to give more detail. Unfortunately, the way the automatic taxobox system is currently set up, there is npo way to make that last taxon link to the correvct article. Can a way to do this please be set up? עוד מישהו Od Mishehu 17:24, 4 October 2016 (UTC)

Basically you want a taxobox which doesn't have a "target taxon" since it ends with a group that isn't a valid taxon. How about the taxobox to the left for the Vole article? You need to assign a "rank name" to the group that ends the taxobox. You don't need "in part" because the taxobox says that "voles" are part of Arvicolinae. Peter coxhead (talk) 18:59, 4 October 2016 (UTC)
Apart from the fact that "Vole" is not a taxon (you would say the same about my comment on "authority" above), I've seen several taxonomy templates which were created with common names and doing this would tend to encorage that. I would like a solution which doesn't tyend to encourage use of common names for these templates. עוד מישהו Od Mishehu 09:08, 5 October 2016 (UTC)
I can't see how it could sensibly be made to work, since the automatic taxobox system depends on going upwards through "Template:Taxonomy/..." templates starting at the target taxon. If the final entry isn't treated as a taxon (i.e. doesn't have a taxonomy template), there's nowhere to start.
I do take your point about not encouraging taxonomy templates created at common names. The solution then, I think, is to accept that for these unusual cases, a manual taxobox has to be used. Peter coxhead (talk) 13:09, 5 October 2016 (UTC)
What I would like ios for some way that I would start from Arvicolinae, and the appropriate line in the taxobox would actually link to the page which the taxon points to. עוד מישהו Od Mishehu 14:45, 5 October 2016 (UTC)
Yes, I understand that, but it means that the last line in the taxobox won't be for the group/taxon which is the subject of the article, and this is not how taxoboxes are used. Readers accustomed to taxoboxes won't expect the last taxon to link to a different article. If you put |taxon=Arvicolinae in the automatic taxobox, the assumption is that this is the taxon the article is about. If you must use an automated taxobox for Vole, then I think that having a "taxon" labelled "voles" is the least bad solution. (Personally, I wouldn't have an article about "voles" given that the term is not used for a currently recognized taxon, but that's a different argument.) Peter coxhead (talk) 14:56, 5 October 2016 (UTC)
What I would like is to be able to use {{Automatic taxobox|taxon=Arvicolinae|lisk_to_last=yes}}, which would approximate the current taxobox on Vole. עוד מישהו Od Mishehu 17:01, 5 October 2016 (UTC)

We could use a Template:Hybridbox

I thik we need a {{hybridbox}} to deal with hybrid-related issues. To be specific:

עוד מישהו Od Mishehu 10:27, 9 October 2016 (UTC)

@Peter coxhead:I have a proposed version at User:Od Mishehu/sandbox1, but it still doesn't handle situation #3. I would like some help there. עוד מישהו Od Mishehu 20:31, 18 October 2016 (UTC)
I made a few edits to your draft, which, as you note, handles #1 and #2 fine. It's not obvious to me what a taxobox for #3 should look like. One possibility would be to have it like #1 and #2 with no genus line. Why do there need to be links to the genera if there are links to the species? The offspring doesn't belong to either parental genus – if it were a plant, it would be given a new nothogenus. To me, the taxobox at Cama (animal) is wrong. Peter coxhead (talk) 21:39, 18 October 2016 (UTC)
I think that the taxobox at Cama (animal), (like the one at Sheep–goat hybrid, the one at Beefalo) is correct. I would drop anything between genus and family, if that simplifies matters (unlike the box at Koolakamba), but I think the three Artiodactyl hybrids mentioned above are correct. עוד מישהו Od Mishehu 06:13, 19 October 2016 (UTC)
@Peter coxhead:The difference between genus and higher ranks is that the genus name is part iof the species name. It would be wring to say that a cama is a cross between a dromedarius and a glama - one would need to say Camelus dromedarius and Lama glama. And with family rank and higher, as far as I can tell there is no notable claim to what is now considered a cross-family hybrid (claims for a humanzee were made in the 1970s, before humans and chimps were considered to be part of the same family), although with lower ranks such hybrids exist even on the tribe level. עוד מישהו Od Mishehu 13:06, 23 October 2016 (UTC)
I haven't worked it through, but one answer seems to be to call the genus e.g. Camelus × Lama (which is equivalent to the case of a plant, where there would be a nothogenus name like × Camelolama), and then create a taxonomy template at this title e.g. "Template:Taxonomy/Camelus_×_Lama". Your hybrid box template will then work, I think. Peter coxhead (talk) 16:36, 23 October 2016 (UTC)
It would still require work that I don't know how tp handle - for one thing, in the genus row, we woould want each genus name to point to the article on that genus. And then we need to adjust the species line to place each genus with its individual species name. עוד מישהו Od Mishehu 21:11, 24 October 2016 (UTC)
Yes, on reflection, my idea wouldn't work well. I think this is a case where attempting to force inter-generic animal hybrids into the automated taxobox system (ATS) is a mistake. The deep underlying logic of the ATS is that there is a taxonomic tree, but for intergeneric hybrids, the taxonomy is a net at the genus level. I would accept that a manual taxobox is the best answer. There are few intergeneric animal hybrids, so it's not clear that a template would be worthwhile, anyway. Peter coxhead (talk) 07:48, 25 October 2016 (UTC)

Display problems

This is something that doesn't happen with the speciesbox - for some pages the taxobox is uncolored (e.g. Caenagnathidae should be display the color denoting animals, but instead only red frames are present). Just curious about why this issue is happening (is it because of too many nested clades?), and what can be done to solve it? Lythronaxargestes (talk) 21:35, 12 November 2016 (UTC)

As of right now, Caenagnathidae is o.k. (you may need a null edit or a purge to see it).
The automated taxobox system is constantly poised on the edge. There is an absolute limit on nesting templates of 40. Various clever, but fragile, tricks have been used to allow code with limited nesting to process quite deeply nested taxa/clades. However, there remain some taxa that can't be correctly processed, and don't get a taxobox colour. Where practicable, cutting out or skipping levels in the taxonomic hierarchy is one solution.
Another solution for really problematic cases is the introduction of |color_as=, to be used when no taxobox colour appears automatically. Thus |color_as=Animalia will give a taxobox the correct colour for an animal without having to search all the way up the hierarchy. Unfortunately, making any change risks reducing the depth of taxon nesting that can be handled, and earlier today I had implemented this new parameter in a way that had this effect, and some taxoboxes lost their correct colour. I have now corrected this, as far as I can tell.
Longer term, we need to find a more principled solution than the ad hoc fixes we're having to make at present. Peter coxhead (talk) 23:20, 12 November 2016 (UTC)
I believe I have now achieved this; see #Lua coding. Peter coxhead (talk) 11:21, 10 December 2016 (UTC)

Major rewrite of the colour setting system

All of the section below is now obsolete; see #Lua coding.

Old text

I have completely re-written the part of the automated taxobox system that sets the taxobox colour.

  • The main reason was to allow a taxon lower in the taxonomic hierarchy to over-ride a colour set higher up; this allows a default colour to be set when no lower level colour is set, e.g. setting the Eukaryota colour for eukaryotes with no other colour defined (as this version of Picozoa), while still allowing the lower level to set its own colour, e.g. setting the Animalia colour when Eukaryota is an ancestor. Previously, only one taxon in the taxonomic hierarchy was allowed to set a colour. The colour set at the lowest level in the taxonomic hierarchy is now used.
  • A secondary reason was to try to reduce the expansion depth of the templates that set the taxobox colour. This allows slightly deeper taxonomic hierarchies to be processed.

The re-written code is live in {{Automatic taxobox}}, and appears to be working well. Please leave a message below if you find any problems, but note that the system will still break if extra levels keep being added to the taxonomy templates – |color_as= can always be used to over-ride the automated system and thus fix some depth problems.

See #Progress below.

Templates defining taxobox colours

Two templates are used to define taxobox colours:

  • {{Taxobox colour}} – this is used by both manual and automatic taxoboxes; any changes or additions to taxobox colours must be made here. The automated system interrogates this template via {{Sets taxobox colour}} to decide whether a taxon sets a taxobox colour.
  • {{Autotaxobox colour}} – this is only used by automatic taxoboxes; it must be kept synchronized with {{Taxobox colour}}. (Template editors: see below for the technical reasons why two templates are needed at present.)

Incertae sedis taxa

Incertae sedis taxa are a problem: the incertae sedis colour should be used if, and only if, the only colour setting taxa found are incertae sedis ones – if there's a colour setting taxon above an incertae sedis taxon, its colour should be used instead. I found making this work impossible within the limits of the template language, so the incertae sedis colour must always be added to automated taxoboxes via |color_as=incertae sedis. This is not too much of a problem, as there are only 25 articles with this colour at present.

Technical problems

Attempting to process deep taxonomic hierarchies using a language that doesn't allow iteration or recursion and allows only 20 levels of templates to be nested in a transcluded template is, in my experience, incredibly difficult. It only just works – some articles reach the maximum allowed expansion depth of 40, so one more step of processing or one more taxonomy template is likely to cause the system to fail. Ideally there shouldn't be both {{Taxobox colour}} and {{Autotaxobox colour}}. The problem is that moving the switch statement to another template and then calling this inside both {{Taxobox colour}} and {{Autotaxobox colour}} adds a minimum of 2 to the expansion depth, and there simply isn't scope for it. The target is to get exactly the same expansion depth as now for {{Autotaxobox colour}} and {{Sets taxobox colour}}, but use the same switch statement that {{Taxobox colour}} uses. I'll continue to work on it; maybe someone else can manage it? Could more of the system be coded in Lua? Peter coxhead (talk) 22:49, 16 November 2016 (UTC)

Progess

I've now updated all the automated taxoboxes that use a taxon to set the colour:

They all seem to be working properly. Peter coxhead (talk) 17:12, 23 November 2016 (UTC)

Lua coding

In several places, the automated taxobox system needs code that traverses the taxonomic hierarchy encoded in the taxonomy templates (i.e. templates with names like "Template:Taxonomy/taxon_name). Up to now, this code has been written in the template language, and hence been subject to severe limits to avoid expansion depth overflow errors. A consequence was that taxonomic hierarchies had to be artificially curtailed in various ways to make the system work.

I have now re-written all the 'traversal code' in Lua – at Module:Autotaxobox. So far as I can tell from tests, it all works just as before, except that the expansion depth has shrunk dramatically. For example, Pteranodon used to be at the absolute limit of 40/40, but is now at 24/40.

However, the automated taxobox system is complex, and has many subparts, so if any problems appear, please leave a note below.

As of 10 December 2016, I haven't converted all of the automated taxobox templates to use the new Lua code; I'll complete this over the next few days. When this is finished, it should be possible to remove all the /skip templates and hardcoding that were inserted purely to reduce the depth of taxonomic hierarchies. Depths of at least 100 should then be ok. Peter coxhead (talk) 12:03, 10 December 2016 (UTC)

I understand that /skip templates will still be necessary in cases where a rank is repeated; e.g. Sarcopterygii/Reptilia/Aves are all treated at the rank of class in certain articles, but a bird species article should only display Aves for the class with Sarcopterygii and Reptilia skipped in the appropriate (bird-related) taxonomy templates. Plantdrew (talk) 15:22, 10 December 2016 (UTC)
Yes, exactly, and it's worth stressing this point. Currently /skip templates are used for two purposes: to shorten taxonomic hierarchies, and I'm hopeful that this need will go; and and to provide alternative taxonomies, a need that will remain. So there can be no blanket removal of /skip templates. Peter coxhead (talk) 16:32, 10 December 2016 (UTC)

Flagging anomalous ranks in taxonomic hierarchies

In a taxonomic hierarchy displayed in the table on the right of a "Template:Taxonomy/taxon" page, any 'Linnaean' ranks should be in the right sequence; for example on descending the hierarchy, there should not be a taxon at a rank that is the same as or higher than the rank of a taxon above.

It's slightly difficult to know what the correct sequence should be for some ranks. For example, in zoological nomenclature,"cohort" and "divisio" don't seem to be used consistently in different groups of organism. Also some of the newly coined ranks, such as "mirorder" and "parvorder", don't appear to be used in the same way in all sources.

I've implemented some experimental code that shades the cell holding a rank in red if it seems to be anomalous. Thus if you look at Template:Taxonomy/Ditrysia right now, the sequence Suborder – Cohort – Subcohort – Infraorder can't be correct. Wherever cohort group ranks (supercohort, cohort, subcohort, infracohort, etc.) go, they can't be nested inside order group ranks – they have to be either above or below this group of ranks. Division here probably shouldn't be flagged, since it's used so inconsistently, but at present I've followed the approach that says it should be between Class and Order, as in the table at Taxonomic rank#All ranks.

In a day or two, Category:Taxonomy templates showing anomalous ranks will show taxonomy templates whose hierarchies end with an anomalous rank. Its contents at present reflect an incorrect earlier attempt, that flags up too many templates, and these haven't yet disappeared from the category.

The real problems that need fixing are caused by the clash between approaches that place Linnaean ranks (when they use them at all) very high up the taxonomic hierarchy (e.g. the clade Reptilia being treated as a Class that includes all traditional reptiles and birds) and those that are follow tradition and place ranks much lower down (e.g. treating birds at the level of Class). Peter coxhead (talk) 16:07, 16 December 2016 (UTC)

Update and move of documentation

Please see WT:Automated taxobox system#Update and move. Peter coxhead (talk) 16:52, 13 January 2017 (UTC)

Taxonomy templates updated

Please see Wikipedia talk:Automated taxobox system#Taxonomy templates updated. Peter coxhead (talk) 23:00, 1 February 2017 (UTC)

How to get extinction daggers if year of extinction not known

I believe that the outputting of a dagger next to a species (or subspecies?) name, to denote extinction, is triggered by the presence of a value in the 'extinct' parameter. The documentation at Template:Taxobox#Conservation_status is very clear that this should only be used if "year of extinction is known". When present, the value of this parameter is also printed out in the conservation status box, so "yes" looks odd, as in this version of Saudi gazelle. I'm pretty sure I've created some boxes with an 'extinct=yes' parameter like that, mistaking it for the parameter of the same name in taxonomy templates. A 'documentation fix' like allowing some such value as '2008 (declared)' in the case of the Saudi gazelle is possible, or the template that formats the conservation status cell could be modified to treat a value of 'yes' as a blank. William Avery (talk) 22:00, 16 April 2017 (UTC)

@William Avery: As someone who writes articles on fossil taxa I can say that the documentation at Taxobox#Conservation_status is not totally accurate. All that needs to happen for the dagger to appear is |extinct=yes or |extinct=true to be placed onto the taxobox, see Andrena antoinei. It seems the documentation was worded to avoid possibly extinct taxa from being daggered when the actual fate of the species is not known.--Kevmin § 23:47, 16 April 2017 (UTC)
There seems to be some inconsistency in how 'extinct=yes' behaves. When 'status=EX' is present, the value in 'extinct' is displayed along with the dagger. When status is absent it just does the dagger. Andrena antoinei ought to be displaying a dagger with both the species and the binomial. There are three different cases where species level taxoboxes should display daggers; 1) entire genus is extinct 2) recently (post ~1500) extinct species in extant genus 3) palaeontologically extinct species in extant genus. For 1, the dagger should appear based on 'extinct=yes' in the genus level taxonomy template. For 2, the dagger should appear when 'status=EX' is present in the articles speciesbox. I don't think using 'extinct=yes' is ideal for 3, but it's the only thing that works at present. Plantdrew (talk) 01:31, 17 April 2017 (UTC)

There are different issues here to be sorted out, it seems to me.

  • The code that handles |status= in the taxobox is essentially the same for manual and automated taxoboxes. It's not something I've ever looked into, but clearly does need looking at. It shouldn't be treating a date and yes/true in the same way, I would think. (The issue is in Template:Taxobox/species – it displays whatever the value of the extinct is.)
  • Plantdrew's explanation re |extinct= in a taxonomy template is as per the documentation. Where the dagger should be displayed for a species is a similar issue to where the authority should be displayed, and goes back to the decision to show the species name twice, uniquely emphasizing a binomial by putting it in a box, unlike any other target taxon. Personally I would not put either the dagger or the authority in the binomial box.

Peter coxhead (talk) 07:14, 17 April 2017 (UTC)

Expanding on the first point, if |status=EX, the code of {{Taxobox/species}} outputs the value of |extinct= in the format "Extinct (value)" without any checks whatsoever, so |extinct=no outputs "Extinct (no)" (and {{Taxobox/core}} outputs a dagger). Since this code is used by all taxoboxes, I'm uneasy about altering it, although its behaviour seems quite wrong. Um... Peter coxhead (talk) 13:40, 17 April 2017 (UTC)