Template talk:Taxobox/Archive 14

Archive 10

←

Archive 12

Archive 13

Archive 14

Archive 15

Archive 16

→

Archive 20

Proposal to add featured picture stars to taxoboxes

There is a proposal at the Village Pump[1] to add featured picture stars to featured pictures in article space (below the featured picture, in its caption box, or image caption box in the case of taxoboxes with featured pictures.

The discussion includes asking the question whether they should be added to all featured pictures in articles including in taxoboxes, added just to featured pictures in caption boxes only and not to featured pictures in taxoboxes, or not added at all. Currently to find out if an image is a featured picture the user has to click on the image and its file page indicates with a star in the upper right hand corner that it is a featured picture.

To join the discussion and express your opinion go to the Village Pump. --IP69.226.103.13 (talk) 08:32, 19 November 2009 (UTC)

Introducing flexibility for disputed taxa

Homo floresiensis
Scientific classification
Kingdom:	Animalia
Genus:	Homo
Species:	Homo floresiensis
Binomial name
Homo floresiensis

Archonta
Scientific classification
Kingdom:	Animalia
Superorder:	Archonta
Orders
Primates Dermoptera Scandentia Chiroptera

Oryzomys anoblepas
Scientific classification
Kingdom:	Animalia
Genus:	Oryzomys
Species:	Oryzomys anoblepas
Binomial name
Oryzomys anoblepas

Banksia
Scientific classification
Kingdom:	Plantae
Genus:	Banksia

In a discussion at Talk:Homo floresiensis#Taxobox, some users brought up the suggestion to change the taxobox to introduce a new feature that would change the "Scientific classification" heading to something else when the classification is disputed, as at H. floresiensis. I added a sample here of what this would look like. This would allow us to include the valuable information the taxobox gives, which is valuable whether or not the species is valid, while not giving the impression that we are considering something valid (i.e., taking sides in a debate) that may not be valid.

I think there are two other situations where a similar change in the taxobox would be helpful. One is for obsolete taxa, such as Archonta, where a taxobox is still helpful in showing what the earlier classification looked like, and the other is where we simply don't know what the classification should be, as in the case of Oryzomys anoblepas. I feel this is distinct from a disputed taxon such as H. floresiensis, because in cases like this there is simply no research that has established a classification, which is something different from a disputed classification, in which there are two sides that have different views of what the classification should be. I added similar options to the taxobox sandbox, also illustrated to the right here.

The precise wording is of course open to change. Hesperian proposed "Putative scientific classification", which I don't quite like, because I don't think "putative" has the meaning we want to have here.[2][3] Ucucha 03:33, 24 November 2009 (UTC)

This is pretty cool if it means I can write "scientific classification sensu A.S.George" or "sensu APG-II" etc., where it would be helpful to state what circumscription/arrangement we are following. Hesperian 04:23, 24 November 2009 (UTC)

Why not? I now set the sandbox so that the |classification= parameter now accepts every value.

I do think we should be careful with that, though; I don't think we want to have every taxobox say the classification is sensu so-and-so when that classification is completely uncontroversial. A better solution might be to add the possibility to add an inline cite to "Scientific classification", similar to the one we have for conservation status. Ucucha 04:36, 24 November 2009 (UTC)

I agree. If there are multiple classifications and no consensus on which should be used, then any taxobox will be problematic and sensu won't fix that. If there is a single, broadly accepted classification, sensu is redundant. I can only see it being useful when

1. There is a classification with broad enough consensus that it is reasonable for us to follow it in our taxobox; but there are also enough dissenters that it is worth making clear who we are following.
2. If a new classification is published, and this invalidates a large number of taxoboxes, then providing a sensu that makes it clear we are using an outdated classification is a quick fix.

Hesperian 04:43, 24 November 2009 (UTC)

Agree with using this lightly. Even in cases where the classification changed recently (e.g. Cronquist to APG in plants), I'd be reluctant to use this feature routinely (a taxobox incorporates classifications from more than one source, for one thing). I guess I have no argument with most of the examples which opened this section, though, and a |classification= parameter which takes free text as its argument seems like the simplest way to implement it. Kingdon (talk) 15:25, 24 November 2009 (UTC)

I like Kingdon's term "I agree with this lightly". First, I'm in favor of just about anything that adds a little bit of flexibility to some of these rigid parameters. I'd also like to see an ability to add more intermediate unranked clades for many groups. My only general concern about this is the way it paints the whole classification in a broad brush. Like Kingdon says, the classification is probably an amalgam of different sources. Whoever assigned a skink species to a genus probably said nothing about whether lizards should be treated as Class Reptilia, Class Diapsida, or Class Sauropsida. The "disputed" parameter for H. floresiensis pertains only to the validity of the species; no one disagrees that it's in the genus Homo and all other ranks above that. Likewise, what's uncertain" about Oryzomys anoblepas is its genus, the rest is correct. Any way we can make it clear that there's no dispute as to which genus H. floresiensis is in or that we're not uncertain about the placement of Oryzomys anoblepas in Kingdom Animalia? Even if not, I support this proposal as a step in the right direction. --Aranae (talk) 16:02, 24 November 2009 (UTC)

I agree that it's important to avoid rigidity in the taxobox and I see your point that the classification doesn't derive from one single source, but I think we should also avoid putting too much detail in the taxobox. It should give a concise overview of the classification, and detailed information should be given in the text. I think the "disputed" and similar tags should serve as a note to the reader that parts of the classification given should be taken with a grain of salt, and the text should make clear exactly what is being disputed. Ucucha 18:47, 24 November 2009 (UTC)

We all seem to be in agreement that this change is a positive one, and since it only introduces flexibility and does not affect existing taxoboxes, I am going ahead to request that it be added. {{editprotected}} Please do this edit to {{Taxobox}}. Ucucha 13:39, 27 November 2009 (UTC)

I don't like the parameter name classification. Can we change it to, say, classification_status? Hesperian 13:56, 27 November 2009 (UTC)

Yes, that's better. Ucucha 13:59, 27 November 2009 (UTC)

Done. I don't have much time ATM, so I'll leave the documentation for later / someone else. Hesperian 22:57, 27 November 2009 (UTC)

I'm working on that right now. Ucucha 23:03, 27 November 2009 (UTC)

I added some text about it; perhaps some more examples (for example, including sensu) may be in order. Ucucha 23:11, 27 November 2009 (UTC)

Further style work

Current style In a forest near Rambouillet, France Scientific classification Kingdom: Fungi Phylum: Basidiomycota Class: Agaricomycetes Order: Boletales Family: Boletaceae Genus: Boletus Species: B. edulis Binomial name Boletus edulis Bull.

Proposed style In a forest near Rambouillet, France Scientific classification Kingdom: Fungi Phylum: Basidiomycota Class: Agaricomycetes Order: Boletales Family: Boletaceae Genus: Boletus Species: B. edulis Binomial name Boletus edulis Bull.

Hey folks,

So I think it's time we started to move towards making this a real {{infobox}}. I've updated the sandbox to use styling which is closer to that expected of modern infobox templates: I've made concessions to the current taxobox styling with regard to font size and width for now so as not to do too much at once. As usual, comparisons are available on the test cases page. Chris Cunningham (not at work) - talk 12:29, 27 November 2009 (UTC)

The changes in general form and font size are, to me, aesthetical improvements. In the testcases, there seem to be two things where your changes produce something concretely different:

1. Ranks in the scientific classification are now bolded and no longer have a colon.
2. The fossil range no longer has the same background color as the name.

I like neither of these changes, really, for what it's worth. Ucucha 13:39, 27 November 2009 (UTC)

I must agree regarding those two specific changes. In particular, I think the use of bolding is best served to highlight the taxon name, and over-use of it would just be distracting. I do like that the text is more compact than it was before. -- Yzx (talk) 18:19, 27 November 2009 (UTC)

The bolding of the key in the key-value pairs is deliberate, and matches that of the vast majority of the encyclopedia's infobox templates. It is in fact one of the main reasons I'd like to move to a more standard format. Using a <th> element for these keys rather than a <td> with a colon also imparts additional semantic value, which helps automated tools incuding screen readers for the blind to make sense of the data. As for the colour band behind the fossil range, that's fairly trivial to resolve, but again on the majority of the encyclopedia's infoboxes it is only the title which is given a colour band (and even then not always). Again, the main rationale for these changes is not aesthetic, but rather to impart more information through the markup, to present our infobox templates consistently to our readers and to simplify the code. In the current sandbox the deviations from the standard {{infobox}} layout are purely for the sake of not doing too much at once. Chris Cunningham (not at work) - talk 19:02, 27 November 2009 (UTC)

Semantics are useless where they cannot be made to bow properly to css presentation. As-is, uncontrolled bolding in these extra <TH>s basically makes the semantic value of bolding of the useful name null. If you want to impose header cells there, then you're going to have to manually de-bold them first, because users won't accept it otherwise. Also, you got to keep the small-size authority for species and type species. Circéus (talk) 19:44, 27 November 2009 (UTC)

Why, then, do users accept this bolding in practically every other infobox on the enyclopedia? Chris Cunningham (not at work) - talk 19:20, 28 November 2009 (UTC)

Not every infobox is the same. For most infoboxes, the information in the left column is essential for understanding the right column. In the taxobox, that is not as true, because it is mainly the hierarchy that matters and the ranks, which are in the left column, are fairly arbitrary. Ucucha 19:30, 28 November 2009 (UTC)

Also, we use bolding for a specific purpose in the taxobox, which is to highlight the binomial name (and sometimes also genus, etc, if it's monotypic). This is not a concern in most other infoboxes. -- Yzx (talk) 20:01, 28 November 2009 (UTC)

The question should therefore be, wouldn't it be better to use a different styling to highlight the binamial name et cetera? The template currently doesn't even use a key to indicate why things are being highlighted, which is another important accessibility issue. Chris Cunningham (not at work) - talk 14:38, 29 November 2009 (UTC)

The bolding is used to highlight alternatives for the article title (sorry for the clumsy phrasing), as is established practice in the article lead. I don't see why we should explain that specifically in the taxobox, as the convention is the same. I agree with Yzx here. Ucucha 20:47, 29 November 2009 (UTC)

The bolding of the current taxon seems hard to do a different way (it matches the bolding of the current page name in articles, and also in navboxes, for example Template:Eukaryota_classification). I'm not sure I have a strong opinion one way or the other about bolding the ranks. It seems a bit pointless (in the sense that the ranks aren't especially important, compared with something like Last Test at Sourav Ganguly), but I'm not sure it is all that harmful in terms of letting the current taxon stand out (the two are in different columns, after all). Whatever we do about bolding, I like dropping the colons. Kingdon (talk) 18:37, 30 November 2009 (UTC)

To extend on the Ganguly example, most WP:TOL participants would probably argue that information under "Scientific classification" is more akin to the years under "Domestic team information". The infobox, in fact, has fairly little information overall, so it puts what most infobox places in a left column as a header. This also explains what goes on in {{Infobox cricketer biography}}: imagine an extra row above the classification with "rank" and "name". That would be useless in this infobox! Compare {{Infobox church}} where structure goes the other way around (e.g. St George's Church, Worthing). Ultimately, I believe trying to argue based on what other infoboxes do is mildly pointless, and continuity is a good thing. I do not mind the use of <th> per se, but they should not add (what I believe is) unwarranted bolding. Circéus (talk) 19:27, 30 November 2009 (UTC)

It should, in the end, be trivial to make the actual styling of the th element un-bold if that's what we really want. However, I'd really rather that we took the time to seriously consider why this template deviates from the {{infobox}} norms (which, after all, were originally derived from this template!) - consistency is important to me, and for years this template retained various bits of cruft for no real reason, so while there seems to be momentum for evolution I'd like to get as much dialogue as possible going. If people could ping the various WikiProjects or editors who might most be interested in this that would be great. Chris Cunningham (not at work) - talk 22:40, 30 November 2009 (UTC)

Didn't we just give a number of reasons why this template is different from at least some others? I quite agree with Circeus that the ranks are similar to the non-bolded years in infoboxes as at Sourav Ganguly. Ucucha 22:52, 30 November 2009 (UTC)

Chris, assuming you're familiar with relational databases (you seem like the kind of guy who would be): I don't think of the above taxobox as presenting a single (kingdom, phylum, class, order, family, genus, species) tuple. I think of it as presenting a sequence of (rank, name) tuples. To put it another way, (Genus, Boletus) is not a key-value pair; it is the value of a key-value pair for which the (implicit) key is the tuple (name, rank). It follows that "Genus" is not a key; it should not be in bold; and it should not be wrapped in <th>. Hesperian 23:37, 30 November 2009 (UTC)

P.S. Oh, I see Circeus seems to be making much the same point when he says "imagine an extra row above the classification with 'rank' and 'name'." Hesperian 23:42, 30 November 2009 (UTC)

I agree with Hesperian's analysis, and wonder whether that imaginary row (which would of course consist of <th>s) shouldn't exist, since not all of our readers understand what the columns mean.--Curtis Clark (talk) 02:38, 1 December 2009 (UTC)

I feel that the link to Biological classification above the list is sufficient, and providing column headers would be of almost no value and just add clutter. Balfa (talk) 14:01, 1 December 2009 (UTC)

Almost no value to sighted readers familiar with the taxobox layout. For other readers it may be greatly beneficial. Thanks to Hesperian for a very clear technical analysis. I also forgot to say, in my reply to Circeus above, that it should be apparent that other widely reployed infoboxes like {{infobox cricketer biography}} and {{infobox football biography 2}} (the latter developed specifically to improve the accessibility of football bio infoboxes) do use this additional set of header for precisely this reason. Chris Cunningham (not at work) - talk 14:31, 1 December 2009 (UTC)

I must agree with Ucacha's statement a few paragraphs ago. When I visit other language wikis, I find the standard infobox layout harder on the eyes...but that's a lame reason to object...don't let my vote stop you. Change is good sometimes, and perhaps it's time for some. Bob the Wikipedian ^{(talk • contribs)} 08:00, 1 December 2009 (UTC)

Another revision

I've updated the sandbox to reflect the discussion above. Chris Cunningham (not at work) - talk 14:34, 1 December 2009 (UTC)

"Name" and "Rank" should be switched (e.g., "Phylum" is a rank).--Curtis Clark (talk) 14:45, 1 December 2009 (UTC)

(ec) :I think it's an improvement. One more point, is there a reason for the increase in size for the taxonomic authority? --Aranae (talk) 14:47, 1 December 2009 (UTC)

I agree. Should we link "rank" to Taxonomic rank? Ucucha 14:52, 1 December 2009 (UTC)

I am opposed to the current implementation of "rank" and "name" for the following reasons: (1) There is now still the same issue of having bolding in the taxobox for two different purposes. (2) "Name" now appears in two different places in the taxobox as labels for slightly different things, and (3) I find this unnecessary. The original classification made perfect sense when read horizontally: "Scientific classification, Kingdom Animalia, Phylum Chordata..." If anything adding "rank" and "name" makes it less comprehensible, and I don't see how this would be of benefit to unsighted readers. -- Yzx (talk) 18:53, 1 December 2009 (UTC)

Tables are supposed to be accompanied by a legend which identifies the contents of each field. Failure to do so is negligent, as table cells are not guaranteed to be read in a run-on style. The rationale that particular fields are bolded in the infobox because they would be bolded in the lede has no basis in the MoS; on the other hand, bolding in tables has always denoted headers. Chris Cunningham (not at work) - talk 21:35, 1 December 2009 (UTC)

My point remains, why is the addition of extra headers necessary/beneficial? The classification section doesn't need any headers beyond "Scientific classification", as it only presents a single set of information. Semantically the two columns can be replaced with a single column containing "Kingdom Animalia, Phylum Chordata, ..." and I see no evidence that this has ever been ambiguous enough to require more headers. As for the bolding, this is the way that the taxobox has worked without incident for years, and it works well for the information we are presenting. The fact that it's not proscribed by the MoS is irrelevant, as the MoS never makes any demand to being universally applied (and in fact specifically states that there will be exceptions), and the case has already been made that the taxobox differs from other infoboxes in several respects. -- Yzx (talk) 18:22, 2 December 2009 (UTC)

If data is being presented in a tabulated format, it needs a key to identify it. That's basic Web accessibility. The limitations of both {{infobox}} and the wikitable syntax mean that we can't get perfect semantics for this data, but we should certainly try do do as much as possible. Whether it has "worked without incident for years" is a matter of opinion: Wikipedia "worked without incident for years" without such things as proper support for alt text or any clear guidelines on infobox accessibility, but we're finally making inroads there. Best practices are, obviously, good things to follow precisely because they were arrived at after significant discussion. If exceptions are to be made, then there should be strong justification for them in each case; the current sandbox already contains some concessions to the better-argued exceptions. Chris Cunningham (not at work) - talk 10:16, 3 December 2009 (UTC)

I believe the column headers make it more confusing, less intuitive, and more cluttered. I like most of the other changes, though. Balfa (talk) 19:07, 2 December 2009 (UTC)

I don't like it either.

I have never heard, and still don't buy, the argument that taxa should be bold in the taxobox per WP:LEAD. The scientific name should be in the lead, where it is accessible to people who have difficulty reading infoboxes, and it should be bolded there. Nonetheless I do prefer the taxobox to boldface the taxon/taxa covered by the article... yet unbolding it would not be that big a deal, in my opinion.

My problem with the "Name, Rank" header is simply that it looks horrendous.

Hesperian 23:38, 2 December 2009 (UTC)

Any suggestions for how to make it look less "horrendous"? This is the layout used across similar instances of this sort of thing in other infoboxes. Chris Cunningham (not at work) - talk 10:16, 3 December 2009 (UTC)

I guess you're not looking for "omit the (name, rank) header" as an answer; so no, I have no idea. Hesperian 11:23, 3 December 2009 (UTC)

I think accessibility here is a red herring. First, table heads can have any style. Bold is the most common browser default, but they can be italic, small, small-cap, line-under, boxed, or even unemphasized. Except that some of the common screen readers would ignore it, they could even be made invisible in the visual display.

Second, data tables don't always have to have headers. If they are small, and the meaning is apparent when linearized, headers may not be necessary. Certainly, to a screen reader user who knows about the taxonomic hierarchy, the meaning is apparent. Whether the meaning is apparent to any user unfamiliar with the taxonomic hierarchy is arguable.

Third, one could make a case (not a good one in my estimation, but nevertheless) that it is a layout table, not a data table: a linear presentation of "Kingdom, Animalia; Phylum, Chordata; Class, Mammalia..." would be (arguably) as comprehensible.

@Hesperian, you were the one who made the convincing argument about the data structure; the headers are the crop that you reap :-). I could go either way, but if they are kept, I'd suggest restyling them.--Curtis Clark (talk) 14:56, 3 December 2009 (UTC)

Not at all. A wise man once said "data tables don't always have to have headers." Hesperian 23:18, 3 December 2009 (UTC)

(Re: Chris Cunningham) I don't find alt text an apt comparison, because (1) supporters of alt text had argued convincingly that there was an accessibility issue for unsighted users, and therefore a benefit to adding them, neither of which I have seen evidence for here, and (2) alt text is invisible, so there was essentially no cost to implementing it, whereas I and others have already stated that we find the extra headers visually and/or semantically detrimental. -- Yzx (talk) 19:14, 3 December 2009 (UTC)

I'm entirely unconvinced that the headers could be detrimental, but the rest of the arguments are convincing enough that I've removed the headers from the sandbox for now. Chris Cunningham (not at work) - talk 09:14, 4 December 2009 (UTC)

Other issues

I think there are two other issues here for which we should consider whether we want them:

1. No coloring for fossil range in the proposed change (Template:Taxobox/testcases#Amphibian).
2. Increase in font size for taxonomic authority.

Regarding the second, I think it's important to have some visual distinction between name and authority everywhere in the taxobox for those who're not familiar with the conventions regarding authorities. In the |synonyms= field, we usually use "small" tags for that; I think the general authority should be consistent with that. Ucucha 14:52, 1 December 2009 (UTC)

Unfortunately, <small> (aside from being deprecated in HTML5) leads to unpredictable results in infobox templates due to the layers of nested CSS involved. For what it's worth I'm in favour of consistency here: one problem is that in the current code these authority references are sometimes given in text smaller than 80%, which is eye-strain territory for most people at healthy head-to-monitor distances. The smallest we should be going with any text is to the size of the standard WP image caption. Chris Cunningham (not at work) - talk 15:39, 1 December 2009 (UTC)

Exactly where do the unpredictable results occur? In the current taxobox, I've never had problems with the <small> tags.

Should we perhaps use the {{small}} template for authorities? Ucucha 21:54, 2 December 2009 (UTC)

Have a look at the last few sandbox revisions: using <small> results in significantly smaller small text. {{small}} would result in cleaner code, but you'd still have the problem with absurdly small text. Chris Cunningham (not at work) - talk 10:20, 3 December 2009 (UTC)

How about small caps? Older browsers don't render that, but they'd do ordinary text instead. Also, the author is already distinguished semantically from the name: it's neither strong nor emphasized.--Curtis Clark (talk) 15:00, 3 December 2009 (UTC)

I'm against small caps because those add a level of emphasis that I don't think is warranted for authorities, which I doubt most readers even pay attention to; I like the smaller text because it makes the authority distinct from the prose while still being subtle. I believe the priority should be for internal text style/size consistency for all the places an authority is used in an article, which not only includes "synonyms" but also lists of species in higher-ranked articles. -- Yzx (talk) 19:28, 3 December 2009 (UTC)

Have a poke about in the sandbox if you want to try getting all the text consistent. I'd rather avoid small text altogether, but keeping the small text consistent is definitely important if it's being kept. FWIW I'd very much like to avoid small caps as well. Chris Cunningham (not at work) - talk 09:10, 4 December 2009 (UTC)

Type species link

{{editprotected}} The section header for the type species currently links to biological type. It would be preferable for it to link to the appropriate article, type species. Could an admin please carry out that change in the template? Ucucha 21:49, 2 December 2009 (UTC)

Done. Also type genus and type strain, the latter being a more specific redirect than biological type, both of which redirect to type (biology). Hesperian 23:26, 2 December 2009 (UTC)

Thanks! Ucucha 23:35, 2 December 2009 (UTC)

Proposal to remove genus2 and genus2_authority parameters

Back in early 2006, someone added the parameters "genus2" and "genus2_authority". The reason they gave for doing this was for use in common name articles such as Night heron which span more than one genus. If you visit the article Night heron you'll see these two parameters are no longer used, as "Night heron" is now understood to include 3 genera. This brings me to my point. If a common name refers to a group of genera, the editor should use the "subdivision" parameter, not "genera", "genera2", "genera3", etc. To see the correct way to do this, take a look at Rorqual, which does indeed include 2 genera, but does not use the "genera2" parameters. If it's OK with everyone else, I would like to remove these two parameters from the template. I would, of course, find all the articles which currently use the parameters and migrate them to "subdivision" before deleting "genus2" and "genus2_authority". Kaldari (talk) 05:42, 16 December 2009 (UTC)

I agree. If they are multiple genera comprising a single taxon, then use subdivision. If they are multiple genera not comprising a single taxon, then we shouldn't be using a taxobox, and probably the article should be a disambiguation page.

How do you propose to find all the articles that need migrating? One option is to temporarily make the taxobox categorise into Category:Taxoboxes with genus2 parameter. Then, once you've emptied that category, we remove both the categorisation and the support for genus2. How does that sound? Hesperian 05:57, 16 December 2009 (UTC)

My thoughts exactly. Kaldari (talk) 16:11, 16 December 2009 (UTC)

I've fixed all the affected articles: Flagtail pipefish, Rattlesnakes, and Opah. Unless anyone has any last-minute objections, I'll go ahead and remove the parameters from the template. Kaldari (talk) 21:29, 21 December 2009 (UTC)

I've removed the parameters from the template and deleted the temporary category. Kaldari (talk) 03:19, 22 December 2009 (UTC)