Template talk:Taxobox

Why are we wrapping the infobox inside a div?

It seems this template and Template:Automatic taxobox wrap the infobox element inside a div. This is inconsistent with how other infoboxes behave and makes it harder to locate infoboxes in a page with user scripts and in MediaWiki's code. Is this intentional or can these be removed? Jdlrobson (talk) 21:16, 26 April 2017 (UTC)

It looks like the div tag was added in 2010 by Smith609.[1] Edit summary was "Enclose in <div> tags to avoid unnecessary whitespace". Should be safe to remove. The whitespace around Infoboxes is normally controlled by the .infobox CSS class on the table. Kaldari (talk) 21:45, 26 April 2017 (UTC)

@Jdlrobson: I went ahead and removed the div tags. Kaldari (talk) 21:26, 27 April 2017 (UTC)

@Kaldari: There's {{Speciesbox}}, {{Subspeciesbox}}, {{Infraspeciesbox}}, {{Ichnobox}} and {{Oobox}} that are also part of the taxobox system, and may need to have a div remhttps://en.wikipedia.org/w/index.php?title=Template_talk:Taxobox&action=edit&section=4oved as well (Speciesbox is the only one of these that is used on more than a couple hundred pages). Plantdrew (talk) 21:47, 27 April 2017 (UTC)

I've undone these changes for now. My tests suggest they cause extra blank lines to appear above a taxobox under some circumstances. For example

{{italic title}}
{{taxobox
...
}}

has a blank line above it in the cases I looked at with the change in place. Please test the changes in a sandbox, checking for cases with templates added above a taxobox. Peter coxhead (talk) 21:52, 27 April 2017 (UTC)

@Peter coxhead: Sorry I jumped the gun. I'll try it out in the sandbox and report back. Kaldari (talk) 23:12, 27 April 2017 (UTC)

@Kaldari: I can't see why the sensible change you made would cause the problem I noted; all I know is that on a couple of pages the extra blank line disappeared after my reversion. Peter coxhead (talk) 12:41, 28 April 2017 (UTC)

@Peter coxhead: It looks like this may be uncovering a bug in the MediaWiki Parser: https://phabricator.wikimedia.org/T164121. Kaldari (talk) 22:05, 28 April 2017 (UTC)

@Kaldari: interesting, and puzzling. If you look at the generated HTML for your two test pages, the immediate cause is clear: User:Kaldari/sandbox2 produces HTML with <p><br /></p> just before the infobox table tag. If you remove the line break in the wikitext to give {{italictitle}}{{User:Kaldari/Taxobox|name = ''Aculepeira carbonarioides''}} the generated <p><br /></p>in the HTML goes away.

On reflection, plus some more tests, the issue for me is why User:Kaldari/sandbox3 doesn't produce a blank line rather than why User:Kaldari/sandbox2 does. For example, if you put two occurrences of {{italictitle}} on separate lines in User:Kaldari/sandbox3, then the extra blank line appears. Weird!

On the basis of Smith609's 2010 edit summary ("Enclose in <div> tags to avoid unnecessary whitespace"), it seems likely that this behaviour goes back a long way. Peter coxhead (talk) 09:16, 29 April 2017 (UTC)

Yes, see also this discussion (doesn't explain why the code behaves the way it does, but does explain why div was added). Plantdrew (talk) 15:44, 29 April 2017 (UTC)

@Kaldari: I think there may be other places where this bug shows up. For example, {{Clade}} now works by invoking a Lua module which generates wikitext for a table, so it's a two-step process. An extra blank line appears above the generated cladogram, and the resulting HTML shows the same odd <p><br /></p>. {{Cladex}} still works by directly generating wikitext, so it's a one-step process. No extra blank line appears above the generated cladogram. I hope you get some response to your bug report. Peter coxhead (talk) 16:35, 1 May 2017 (UTC)

Update: wrapping {{Clade}}'s generated table in a div (as at {{Clade/sandbox}}) has precisely the same effect, namely it stops the extra blank line above being created, since <p><br /></p> is not generated. This does seem to be some strange bug: when a transcluded template directly produces the wikitext for a table, all is ok. But if it transcludes another template to produce the wikitext for a table, an empty paragraph is produced above the table, unless it's wrapped in a div. Peter coxhead (talk) 17:05, 1 May 2017 (UTC)

@Peter coxhead: It looks like this has been an issue since at least 2008, so I'm not going to hold my breathe on a fix. See T18700. All the other infoboxes seem to work around this bug by using actual table HTML tags rather than Wikitext table markup. Perhaps we should do the same for the Taxobox templates. Kaldari (talk) 17:21, 1 May 2017 (UTC)

@Kaldari: rewriting to use HTML would be a huge task, since many of the rows in the generated table are produced by subtemplates of {{Taxobox/core}} and use wikitext, including the code that generates automated taxoboxes, both in the template language and in Module:Autotaxobox. So I think that sticking with div's is the best solution unless and until someone has time to tackle this task. Peter coxhead (talk) 08:57, 2 May 2017 (UTC)

@Peter coxhead: I think I have a work-around solution in the sandbox. Let me know if that works for you. Kaldari (talk) 18:26, 2 May 2017 (UTC)

@Kaldari: yes, the work-around works in all the tests I've tried. It should presumably also be applied to all the automated taxobox templates that use {{taxobox/core}}. Peter coxhead (talk) 19:08, 2 May 2017 (UTC)

@Jdlrobson: It looks like we can't remove the div tags due to a 9 year old parser bug. We may be able to re-write the templates to work around the bug, however. Kaldari (talk) 17:23, 1 May 2017 (UTC)

@Kaldari: Can we document the template using a HTML comment to point to this bug? This would have been very helpful to know from the start. Jdlrobson (talk) 22:31, 2 May 2017 (UTC)

@Jdlrobson: That's the plan. Kaldari (talk) 22:54, 2 May 2017 (UTC)

@Kaldari: This problem seems to be making it difficult for us to identify problematic articles (it accounts for over 70% of all the problematic pages we log). All pages that use it on mobile are being sub-optimally rendered. Is there no other way we could fix this? Maybe adding 'infobox-container' class to the container would help us handle it better? Jdlrobson (talk) 21:30, 27 June 2017 (UTC)

Alternative work-around applied to automated taxoboxes

I've applied the "nowiki" work-around in place of the "div" work-around to all 7 automated taxoboxes. See Wikipedia talk:Automated taxobox system#Fix for extra blank line before a taxobox. If any problems are noticed, please comment there. Peter coxhead (talk) 10:22, 4 May 2017 (UTC)

@Jdlrobson and Peter coxhead: Since there were no complaints about the change to the automated taxoboxes, I made the change to the main taxobox templates as well. If there are any problems, feel free to revert. Kaldari (talk) 22:27, 27 June 2017 (UTC)

Conservation status

Is there a good reason that the IUCN conservation status is over-capitalised in the Taxobox? E.g. I see "Least Concern" when the LC parameter is used, yet IUCN and Wikipedia itself does not capitalise "Concern", i.e. "species of "least concern"..." Shouldn't the taxobox render e.g. LC as "Least concern"? The Rambling Man (talk) 08:11, 16 May 2017 (UTC)

That's bothered me for a while too.  SchreiberBike | ⌨  15:50, 16 May 2017 (UTC)

I suspect it's a trivial change, one that I could even implement myself, but I was hoping for some input from those who regularly maintain the template to ascertain if there's a good reason for the over-capitalisation before making the change. The Rambling Man (talk) 18:44, 16 May 2017 (UTC)

Personally I prefer the capitals, since "Least Concern" does not mean just "least concern" – it's a status rating. However, I agree that changing to sentence case in place of title case is in line with the English Wikipedia's general avoidance of capitals at all costs. To change it, you need to edit Template:Taxobox/species. Peter coxhead (talk) 19:38, 16 May 2017 (UTC)

But it's wikilinked to IUCN's status levels, so there's no ambiguity, it's not going to be misconstrued. What is a problem is the inconsistency in the taxobox and the text in the articles (the thousands and thousands of them) which use the terminology correctly. The Rambling Man (talk) 19:42, 16 May 2017 (UTC)

IUCN capitalizes the status ratings in running text, see e.g. the justification section here, where it says "the species is evaluated as Least Concern". That level of capitalization is at odds with general Wikipedia practice, but at least it is consistent with the source. Plantdrew (talk) 20:46, 16 May 2017 (UTC)

If you write "this species does not reach the thresholds for vulnerable" or "the species is evaluated as least concern" in line with the link Plantdrew gave above, it's both unclear and ungrammatical ("vulnerable" is an adjective where a noun is expected; it should be "of least concern" to be correct without the capitals). It does not mean, for example, that the species isn't vulnerable to various threats, rather that it doesn't reach the thresholds to be classified as having the IUCN status Vulnerable. It's a poor argument to say that because articles have de-capitalized in running text contrary to the source and potentially causing a lack of clarity, therefore the taxobox must too. Peter coxhead (talk) 08:21, 17 May 2017 (UTC)

No, it's not a "poor argument", it won't cause a lack of clarity because it's wikilinked (but, as in the case with every single Taxobox on Wikipedia, it's a redirect, another piece of poor template coding). It's a shame that there seems to be such inconsistency within Wikipedia. Maybe we need to change all the "least concern" to "Least Concern" then, because one way or another the previous arguments should apply. The Rambling Man (talk) 08:53, 17 May 2017 (UTC)

Well, I would, as I think is clear, be happy with capitalizing in running text.

Why is it poor template coding to link to a redirect? See WP:NOTBROKEN. Peter coxhead (talk) 08:58, 18 May 2017 (UTC)

Holotype parameter?

Hey, just throwing out a possibly crazy idea, but would it be useful for the box to have holotype as a parameter? Like for Luzon broad-toothed rat (Abditomys latidens (Sanborn, 1952)), one could write its holotype is at the Field Museum of Natural History, specimen FMNH 62347. Would this be useful? Umimmak (talk) 03:37, 15 June 2017 (UTC)

That's data better left to Wikispecies, in my opinion. But taxobox does already support |type_species= and |type_genus=. It doesn't make a lot of sense to me to support types that are names based on specimens (for ranks above species), but not support types that are actually specimens (for species). However, I'm more inclined to resolve this inconsistency by removing support for higher rank types than by adding support for species types. Plantdrew (talk) 05:34, 15 June 2017 (UTC)

I think we have to keep returning to the purpose of any infobox in a Wikipedia article: "to summarize (and not supplant) key facts that appear in the article (an article should remain complete with its summary infobox ignored). The less information it contains, the more effectively it serves that purpose, allowing readers to identify key facts at a glance." A secondary purpose for taxa is navigation: to allow readers to easily move up the taxonomic hierarchy. I too am doubtful as the value of putting the type species or type genus in a taxobox, and I see no added value in adding the type (which for plants in particular is a complex issue in itself – Type (biology) doesn't cover the ICN very well). Peter coxhead (talk) 06:30, 15 June 2017 (UTC)

I agree with the previous dissenting opinions, and want to remind editors that Wikipedia is by and large for the general public, not for taxonomists. Arcane facts of interest only to specialists do not warrant highlighting in a prominent infobox. Leave it to Wikispecies. Do we need a "taxonomy-cruft" essay? --Animalparty! (talk) 18:50, 15 June 2017 (UTC)

I think it would be useful, though it might be difficult to get a wider consensus. Trying to display more and more minor ranks and clades is another issue I think needs discouraging. Peter coxhead (talk) 20:36, 15 June 2017 (UTC)

virus taxobox

Hello. The virus taxobox uses "virus_group =". That apparently follows the Baltimore classification scheme, yet his scheme labels them CLASSES, not groups. I recognize that I'm a newbie, but can somebody please change the template to "Baltimore_class =" rather than "virus_group ="? It's a no-brainer, and I'm astonished that it hasn't been changed before now. Thanks, Viroguy (talk) 03:40, 9 July 2017 (UTC)

Sorry, but it's far from a "no-brainer". Many if not most sources that use this approach call them "Groups" – see also Baltimore classification and the sources therein. "Class" is a bad word to use because it has a precise rank-based meaning in other nomenclature codes. The virus nomenclature code doesn't recognize ranks above Order. Such a major change would require a wide consensus. Peter coxhead (talk) 07:51, 9 July 2017 (UTC)

@Peter coxhead:I beg to differ, but I have another possible solution. Reading further into the template description, I may have a different suggestion to remove this confusion. In the "Complete blank template" section, immediately below "virus_group" there is "unranked_superdomain". Immediately below that is "unranked_superdomain_authority" and then there are many dozens of such pairs of "whatever" and "whatever_authority". Why is there no "virus_group_authority"? Can that be added? If that were added, could Baltimore classification be the value for "virus_group_authority"? Thanks, Viroguy (talk) 14:31, 9 July 2017 (UTC)

@Viroguy: well, this parameter could certainly be added. However, see Template:Taxobox#Authorities – the authority would only be expected when the virus group is the target of the taxobox, i.e. in articles about the groups.

One way of connecting the term "group" to the Baltimore classification, which seems a very good idea to me, would be to wikilink the "Group" label in every virus taxobox to Baltimore classification. What do you think?

Unfortunately it seems that WP:WikiProject Viruses is mainly inactive at present, but I'll flag up this discussion on its talk page. I should stress that I have no particular interest in viruses; I'm replying here because of the work I do to maintain the code that generates taxoboxes. Peter coxhead (talk) 05:24, 10 July 2017 (UTC)

Making the word "group" into a wikilink to the Baltimore clasification page would be a great solution, IMHO. Can that be done automatically by changing the template, which I am clearly not experiencd enough to do, or can I do it somehow manually at each article I'm interested in? i'm going to try to do it on an article I'm working on. Thanks, Viroguy (talk) 18:56, 10 July 2017 (UTC)

I'm sorry for making newbie mistakes. I've been editing Marseilleviridae. I've seen in the taxobox a link to dsDNA. Since I know what double-stranded DNA is, i never bothered to follow the link. When I tried to look at the Marseilleviridae page markup to find the taxobox code, I discovered that the dsDNA link is added magically by the template. So, I decided to go back to the Marseilleviridae page and follow the dsDNA link, and found that it dosn't link to a discussion of double stranded DNA but rather the appropriate section of DNA virus. So, now, the suggestion I have is to change the template so that instead of an entry of "i" in "virus_group =" producing "Group I (dsDNA)" in the box, with a link from dsDNA to the DNA virus page, the entire "Group I (dsDNA)" text should be a link to the appropriate section of the DNA virus page. If this was confusing to a newbie (although admitedly ageing) former virologist, I have to believe it is confusing to general readers. Thanks, Viroguy (talk) 19:19, 10 July 2017 (UTC)

@Viroguy: well, virus taxonomy certainly confuses me (but admittedly I'm ageing too). I do think it makes sense to wikilink the whole of the value of the "Group:" line in a virus taxobox. I'm also unconvinced of the need to put the parenthesized text in a smaller font. At present, the values that appear in response to setting |virus_group= to i through vii are:

• Group I (dsDNA)
• Group II (ssDNA)
• Group III (dsRNA)
• Group IV ((+)ssRNA)
• Group V ((−)ssRNA)
• Group VI (ssRNA-RT)
• Group VII (dsDNA-RT)

So how about the possible values being:

• Group I (dsDNA)
• Group II (ssDNA)
• Group III (dsRNA)
• Group IV ((+)ssRNA)
• Group V ((−)ssRNA)
• Group VI (ssRNA-RT)
• Group VII (dsDNA-RT)

Do we really need the extra parentheses around + and − for Groups IV and V? I won't make any changes until there's been time for comment by others. Peter coxhead (talk) 20:23, 10 July 2017 (UTC)

I'll start anew at the left side. If I was going to remove parenthess it would be ALL of them EXCEPT those around the (+) and (-). However, in a small sample size, 2/3 of the medline references with ssRNA in the title and either + or - before that lacked parentheses. (2/3 really is misleading. It was literally 2 of the 3 didn't have parentheses!) Since both Negative-sense single-stranded RNA virus and Positive-sense single-stranded RNA virus use parentheses, I think we should use (+) and (-), but eliminate all other parentheses. And, i hope to never again nead to spel parentheses. I also agree with not having the smaller font size. Thanks, Viroguy (talk) 20:49, 10 July 2017 (UTC)

After my beauty nap (which doesn't work, as my wife would attest) I wonder if replacing the () with i.e. would work? That is, Group III i.e. dsRNA, Group IV i.e. (+)ssRNA etc. Viroguy (talk) 00:09, 11 July 2017 (UTC)

Template-protected edit request on 20 July 2017

Should we add a parameter “infraregnum”? 66.82.144.144 (talk) 15:27, 20 July 2017 (UTC)