Template talk:Taxobox/Archive 10

Categories

Some admins doing category work had noticed that there were alot of user pages turning up in animal related categories, and we tracked it down to this template being used on user subpages for drafting or testing purposes. I've edited the template to only apply categories when the template is being used in mainspace. --bainer (talk) 10:19, 5 May 2007 (UTC)

NCBI Taxonomy ID numbers

I noticed that NCBI assigns a unique Taxonomy ID number for each species, and uses that number in linking. Would it be appropriate to have an optional line in the Taxobox template for that number? NCBI Taxonomy --Bejnar 06:05, 13 May 2007 (UTC)

Nope. Put it in the external links or references, as all other such IDs are done. --unsigned by UtherSRG 12:55, 13 May 2007

What other like-kind IDs are there? --71.37.150.61 22:32, 13 May 2007 (UTC)

The IUCN redlist has an ID number, CephBase has an ID number, FishBase has an ID number, etc., etc. - UtherSRG (talk) 16:35, 14 May 2007 (UTC)

I notice that the Infobox Dogbreed includes the FCI number. --Bejnar 16:22, 14 May 2007 (UTC)

So? Just because it works for that box, doesn't mean it is right for this box. - UtherSRG (talk) 16:35, 14 May 2007 (UTC)

How many taxa have been assigned IDs by NCBI? —Pengo 14:46, 14 May 2007 (UTC)

So far, there are approx 250,000 taxa that have been assigned IDs by NCBI in the database, growing at the rate of 2900 new taxa a month Wheeler, David L. (2007) "Database resources of the National Center for Biotechnology Information" Nucleic Acids Research 35: . For example, Rotylenchulus reniformis is NCBI Taxonomy ID: 239373.--Bejnar 16:22, 14 May 2007 (UTC)

Data deficient and Image

Hello, I've created an image Image:Status_none_DD.svg for italian wikipedia. (Example)

For insert it in en.wiki you can change the 18° line:

 |DD|dd=Data deficient

in

 |DD|dd=[[Image:Status none DD.svg|200px]]<br>Data deficient

I hope that it can be useful ;-) -- :it:Brodo(msg)

Form

Could somebody replace first line with: class="infobox" style="clear: right; float: right; margin-right: 0.5em; text-align: center;padding:2.5px"; |- style="text-align:center;", please. It looks much better. For example: sl:Ptiči.--WailingWailer 11:50, 20 May 2007 (UTC)

I agree; though I won't make the change without more consensus due to the high usage of this template. Anyone else want to weight in? --MZMcBride 17:50, 5 June 2007 (UTC)

It seems better to me. Much neater. Although in some articles (e.g. Eukaryote, Antilope) taxoboxes are built line by line so those should be taken care of too. --Eleassar ^{my talk} 20:59, 5 June 2007 (UTC)

Is there any reason the multiple templates used for those types of pages can't be merged into one? --MZMcBride 21:17, 5 June 2007 (UTC)

Yes, in some cases (like Eukaryote) there is such a reason. Even when there is not, there are quite many of such articles with multiple templates [1], which I'm not volunteering to update. --Eleassar ^{my talk} 07:11, 6 June 2007 (UTC)

No. The infobox class clashes with some of the colors used for the taxobox. It has been discussed over and over and shot down every time. - UtherSRG (talk) 22:00, 5 June 2007 (UTC)

No, you're just closed minded to any changes to the taxobox. Usually someone disagrees with it (the colours clash with a gray border?), the idea loses steam, and it's forgotten about. The current taxobox looks like shit. —Pengo 23:59, 5 June 2007 (UTC)

It would help a lot if UtherSRG demonstrated this in a sandbox (or provided some other link). --Eleassar ^{my talk} 07:14, 6 June 2007 (UTC)

It's been demonstrated before either on this talk (search the archives) or the talk on WP:TOL (again, search the archives). - UtherSRG (talk) 10:57, 6 June 2007 (UTC)

I looked through the WP:TOL archives and the only thing I could find was your opposition to infobox standardisation in archive 15. However, there I didn't see any real reason the CSS class couldn't be used. This page does not have an archive (though it probably should) and I've only seen comments that are relatively old. Once again, I don't see any legitimate opposition. The infobox CSS class is used extensively throughout Wikipedia, and there seems to be consensus for the change. Unless there is a legitimate objection, I'll go ahead and fulfill the editprotected request by the end of the day. Cheers. --MZMcBride 16:39, 6 June 2007 (UTC)

I've put test code in my sandbox. Examples seen using the code are available here. Please feel free to check the code and make any corrections. Cheers. --MZMcBride 18:43, 6 June 2007 (UTC)

If no one has any better objections than "search the archives" then I'm updating the taxobox to this. The new format is a huge improvement. —Pengo 23:57, 6 June 2007 (UTC)

Adding my support for the change. Mgiganteus1 00:00, 7 June 2007 (UTC)

Sigh. Looks like the end of an era. I'll even be the one who does the edit... - UtherSRG (talk) 00:07, 7 June 2007 (UTC)

Hurrah! —Pengo 00:16, 7 June 2007 (UTC)

'Species' microformat

{{edit protected}}

A microformat for species is currently under development; there is a draft ("straw man") specification. It is recognised by the Operator extension for Firefox (using an add-in user script). I would like to apply it to this taxobox, to see what editors here think of it. It should have no impact on editors not looking for the microformat. The following changes would be required:

• Apply class="biota" to the whole infobox.
• Apply class="vernacular" in a span around {{{name}}}
• Apply class="domain" in a span around {{{domain}}}
• Apply class="kingdom" in a span around {{{regnum}}}

• Ditto for: subkingdom / subregnum; superphylum / superphylum; phylum / phylum; ; subphylum / subphylum; taxoclass / classis; subclass / subclassis; infraclass / infraclassis' superorder / superordo; order / ordo; suborder / subordo; infraorder / infraordo; parvorder / parvordo; superfamily / superfamilia; family / familia; subfamily / subfamilia; genus / genus; binominal / binomial; variety / variety

Thank you.

I should also be interested in comments on the "straw man" proposal, especially the ranks and their names (which may change before the final specification is issued), though those those might be better made on the microformats wiki page.

See also: microformats on Wikipedia.

Andy Mabbett 12:26, 6 June 2007 (UTC)

Where a taxon doesn't have a common name, the {{{name}}} parameter is typically passed the scientific name, so I don't think class="vernacular" would be quite right. Hesperian 12:33, 6 June 2007 (UTC)

Thanks; I've struck that one out, for now. Andy Mabbett 12:55, 6 June 2007 (UTC)

With the exception noted by Hesperian, I'm in agreement that this should be done. - UtherSRG (talk) 12:54, 6 June 2007 (UTC)

I've put test code in my sandbox. Examples seen using the code are available here. Please feel free to check the code and make any corrections. Cheers. --MZMcBride 18:43, 6 June 2007 (UTC)

Thank you, but I wasn't clear enough, so you applied class="kingdom" to every property; in the above list "order / ordo", for example, means "Apply class="order" in a span around {{{ordo}}}". Andy Mabbett 20:12, 6 June 2007 (UTC)

Well that makes a lot more sense. : - ) I made the changes. --MZMcBride 20:33, 6 June 2007 (UTC)

Thank you. I just need to resolve what I think is a bug with species in the latest operator beta, which I'm also testing, before I can test your page, but it looks OK. Andy Mabbett 20:37, 6 June 2007 (UTC)

Done. Cheers. --MZMcBride 00:38, 7 June 2007 (UTC)

Many thanks. It's ~2am here; I'll look at the results and add documentation tomorrow! Andy Mabbett 00:53, 7 June 2007 (UTC)

{{edit protected}}

Sorry about this; class="binominal" should be class="binomial" (no "n"). Andy Mabbett 12:54, 8 June 2007 (UTC)

Y Done. --ais523 13:00, 8 June 2007 (UTC)

Thank you. Andy Mabbett 13:27, 8 June 2007 (UTC)

Microformat testing

Operator can read the microformat, but says that it's invalid; I think the problem is with the extension, and have reported the matter to its developer.

I've also added a note about the microformat to the template documentation page, inviting further comment. I'll be happy to relay comments, made here, back to the microformat community, and Operator's developer.

Andy Mabbett 09:00, 7 June 2007 (UTC)

::The bug is with the labelling used for display in Operator, and a fix is in hand. Andy Mabbett 19:21, 7 June 2007 (UTC)

Update

Mike Kaply has kindly fixed the bug, and Operator is now detecting the microformat in all pages with taxoboxes :-)

Since both the microformat and the related Operator script are still in development, there isn't much you can do with them yet, but the "actions" view allows a search on WikiSpecies, and the "data format" view with "debug" enabled allows one to see the data parsed.

What needs doing next is to firm up the microformat spec: What should all the parameters be called; which ranks should be used; how do we handle the edge cases, like hybrids, cultivars, morphs, etc? While canonical discussion should be on the microformats wiki, I'm happy to report back to there, any discussion here. After all, I think the expertise and a good spread of test cases, are here.

Any thoughts?

Andy Mabbett 15:02, 9 June 2007 (UTC)

One.... I have Operator 0.8a.... but it doesn't ship with biota. Where can I get the biota microformat? - UtherSRG (talk) 15:53, 9 June 2007 (UTC)

You need the "species" user script, from http://www.kaply.com/weblog/operator-user-scripts/ - existing users should note that that was updated as few hours ago. After installing it (overwriting the previous version, if any), restart FireFox. NOte that there are user scripts for other microformats, too. Andy Mabbett 19:33, 9 June 2007 (UTC)

Ok, I go that, added the user script to operator and restarted Firefox, but still nothing. - UtherSRG (talk) 22:12, 9 June 2007 (UTC)

Did you go into "Data Formats" and add "Species"; and into "Actions" and add "WikiSpecies"? You'll need another restart after that. Andy Mabbett 22:23, 9 June 2007 (UTC)

Ah. Incomplete instructions. ;) No I didn't. Ok. - UtherSRG (talk) 22:26, 9 June 2007 (UTC)

Ok., Works now. Doesn't do anything, as you said it wouldn't, but it works. :D - UtherSRG (talk) 22:31, 9 June 2007 (UTC)

Required updates

There's no urgency, but in order to make use of a species microformat, we're going to need to make a couple of tweaks to the template. I'm mentioning this now, so there's plenty of opportunity to consider the possible solutions.

Vernacular

Firstly, we need a way to wrap a span around a vernacular name, but not around the binominal if that's substituted when no vernacular is entered. Something like this pseudocode:

If vernacular exists, display [Name: <span class="vernacular">{{{vernacular}}}</span>]
Else display [Name: {{{binominal}}}]

Alternatively, we could have two properties, "vernacular" and "other display name", but the conversion would be a headache.

Specific epithet

Secondly, the "species" parameter is currently entered as:

species = E. robustus

and the binomial as:

binomial = Eschrichtius robustus

We need a way to have the specific epithet (in this case "robustus") as a separate entity, so that it can be wrapped in a span. This might be achieved by, say, entering:

genus = Eschrichtius

specific = robustus

and having the template code construct the binomial (and/ or "species"). A bot could possibly do the initial conversion; after that there would actually be less work for new editors to do (we could also have the emboldening/ italicising in the template code).

Unfortunately, there's no way for templates to extract the first letter of a word, so I don't see how this could work. Verisimilus T 17:04, 26 June 2007 (UTC)

But the auto-formatting (bold/italics) should be doable; I'd appreciate that. It still must be done manually in monotypic taxa (i.e., where more than one taxonomic level is treated in an article), but anyone who has the wits for discussing monotypy should have the wits to do that. The auto-formatting, OTOH, would be a boon for non-professionals (I see the occasional stub with taxobox where italicization and/or bolding is not correct). Dysmorodrepanis 17:40, 26 June 2007 (UTC)

Perhaps not, Verisimilus, but the binomial could be generated from the two components.

Authority

Lastly, authority is currently entred as:

binomial_authority = (DeKay, 1842)

and it would be handy to have these entered as:

binomial_authority = DeKay

binomial_authority_year = 1842

so that they can be individually wrapped, and then recombined into one line (with parentheses if desired) by the template.

This would be easily done; however, I'm not sure how useful it is. It means another line of code needs to be inserted, and I don't see how having the two separate is of any utility. Verisimilus T 17:04, 26 June 2007 (UTC)

The usefulness is being able to process or extract each of the two parts separately, for the microformat or any other purpose. Andy Mabbett 18:36, 26 June 2007 (UTC)

Any alternative suggestions, or other comments? Andy Mabbett 19:37, 7 June 2007 (UTC)

Anyone? Andy Mabbett 09:00, 21 June 2007 (UTC)

I'm not sure what you mean with regard to vernacular names... As far as I can tell the {{{name}}} attribute is always entered directly; it doesn't default to anything within the template. I suppose the template could auto-detect whether name=binomial, something like:

{{#ifeq:{{{name}}}|{{{binomial}}}|{{{name}}}|<span class="vernacular">{{{name}}}</span>}}

...but that might end up incorrectly labeling some scientific names as "vernacular" just because of a mismatch (perhaps due to capitalization, spelling, stray punctuation marks, incomplete updates, etc.). And it wouldn't work at all above the species level... Regarding the rest, it seems reasonable (I've always thought the current way of entering species and binomial name was a bit odd). A bot would definitely be needed, though. -- Visviva 12:46, 21 June 2007 (UTC)

Thank you. This refers to the comment by Hesperian, time-stamped "12:33, 6 June 2007 (UTC)", and the line ("Apply class="vernacular" in a span around {{{name}}}") which, as a result, I struck out from my original edit-protected request, above. Andy Mabbett 17:19, 26 June 2007 (UTC)

Perhaps a better option would be to have a display parameter, to determine which value is used for the "name", and in which the user could enter "binomial" , or "vernacular", or "page"; and which would default to the lowest completed rank if no value is entered? Andy Mabbett 17:25, 26 June 2007 (UTC)

I'm not really sure what you mean by "with parentheses if desired" when you don't have an input option for whether or not parentheses are required. I'm assuming there's a reason why "binomial_authority = DeKay, binomial_authority_year = 1842, parentheses = yes" is somehow preferable to "binomial authority = (DeKay, 1842)"? --Aranae 18:53, 26 June 2007 (UTC)

I meant that there could be a common standard for either using parentheses, or not (or do they convey some meaning)? The advantage of separate entry for each property is as mentioned above. Andy Mabbett 18:56, 26 June 2007 (UTC)

They do convey meaning. Parentheses mean that the authority did not originally designate a species to the genus that it is currently placed in. I was much relieved when we converted over from the older taxobox format to this newer version. There used to be an entirely separate line for an authority with parentheses and one without. Now it's great because we can just add () manually. --Aranae 19:53, 26 June 2007 (UTC)

Well, I've learned something today. In that case, the "authority" section of the microformat draft needs more work, and so we can omit it from what we're doing here, at least until that's resolved. Please feel free to contribute your comments, and examples, on the microformat wiki, as linked above. Andy Mabbett 20:22, 26 June 2007 (UTC)

Arbitary break 1

Right. Having read the full discussion (and worked out what a microformat is), I'm now feeling a little closer to grasping what's required. Please do correct any of the points I've misunderstood...

1. Having each part of the taxobox entered under a different parameter name allows machines to interpret the taxobox and allows it to be used in ways that are otherwise impossible
2. At the moment, there's no option called vernacular
3. The vernacular would replace the binomial, if set, and be put in a span so the software could recognise it.

As I see it, the point for discussion is:

• Should we sacrifice ease of human editing for ease of computer reading?

To avoid having to sacrifice either, the best solution strikes me as changing the format, and training a bot to change anything entered the simpler way into the new format. But I'd be very wary of adding more complexity otherwise; I already find it quite a large task to add an infobox to an article and I think adding yet more parameters may discourage me, and probably others, from adding them so freely. Verisimilus T 19:06, 26 June 2007 (UTC)

You're almost there... ;-)

Using your numbering:

1. Yes. In the case of microformats, it enables us to wrap each value in a specific HTML class, so that machines may interpret...
2. Correct. "name" may be vernacular, or taxonomic. It's unstructured data, and we should instead know what type of data it is.
3. We need to know whether "name" is vernacular, or taxonomic, in order to know which HTML class to wrap around it; and so that we don't accidentally describe something of one type, as being of the other.

I don't think we need to sacrifice any ease of editing. And please don't think of parsable data as being "just" for machines; such data is processed by humans using those machines, just as you edit this page with a machine. Please do try the Operator extension in Firefox, if that's available to you, as described above. One day, we may be able to generate Taxoboxes using something like your cite-o-matic, by inputting a binomial or LSID number, and looking the rest up on-line. Andy Mabbett 19:42, 26 June 2007 (UTC)

Okay, now I'm with you. I shall have to have a play with this "Operator"... In terms of ease of editing, my concern is that I presently create taxoboxes by remembering the names of the parameters, and more names makes the task harder, especially when they are unfamiliar words. In my view, Wikipedia's primary resource is its editors, and we should make their lives as easy as possible (although microformats in journal articles would make things much easier for a lot of people, and I'm sure the same's true here!)

Shall have to sleep on it, shall hopefully return with an idea of how best to implement it (although I imagine we're almost there...) Verisimilus T 21:36, 26 June 2007 (UTC)

Incidentally, there is an ongoing proposal for a 'citation' microformat. Andy Mabbett 21:42, 26 June 2007 (UTC)

Has someone been mucking about with the taxobox?

I only ask because two taxoboxes on my watchlist, American Goldfinch and and New Zealand Snipe, have been altered today because the long text below an illustration was no longer breaking [2] and [3]. Says one of the editors doing this...Break up caption that was causing ridiculously wide infobox (in IE7, anyway. When I looked at the old versions in IE it did indeed become ridiculously wide. Sabine's Sunbird talk 04:25, 7 June 2007 (UTC)

My guess is that it has to do with removing the width CSS entity. The infobox should probably be set to width:23em. Cheers. --MZMcBride 05:02, 7 June 2007 (UTC)

I had noticed similar things going on in my watchlist (i.e. Stylidium debile). I like the new look, but can we get a quick resolution to this issue? Thanks! --Rkitko ^(talk) 05:08, 7 June 2007 (UTC)

Yeah, this needs to be fixed. Whoever did this, please undo it. Firsfron of Ronchester 06:05, 7 June 2007 (UTC)

I have to say I dislike the colored background. The solid-color bars don't reach the edges, so it ends up looking discolored when it used to blend nicely with the while page background. This looks especilly bad on animal pages, which use pink, since the new background seems to be a faint pink itself. Illustrations with white backgrounds also look bad without a border, when again, the transparent taxobozes allowed them to blend with the white of the page and appear to fill the image screen. Overall... blech. Dinoguy2 06:21, 7 June 2007 (UTC)

width:200px; should be reinstated into template. diff of today's edits. –Pomte 07:03, 7 June 2007 (UTC)

Hmm... shouldn't this be as simple as finding the edit that screwed things up on the template history & reverting it? It'd be pretty obvious as it would affect the caption break... My 2 cents... Spawn Man 07:52, 7 June 2007 (UTC)

I've put the width:200px; back into the infobox, and wrapping now seems to work, at least on the article I looked at, Stylidium debile.-gadfium 08:50, 7 June 2007 (UTC)

The entire taxobox is shifted some pixels to the left... looks quite ugly as section break lines now extend to the box's right (e.g. Arctiidae) Dysmorodrepanis 16:28, 7 June 2007 (UTC)

Actually, I liked the lighter background to the systematics section. It made for easier reading in long, complex taxoboxes. Dysmorodrepanis 16:30, 7 June 2007 (UTC)

The template was switched to use the "infobox" class to put it in-line with the vast majority of templates used throughout Wikipedia. It's more easily readable for users with sight problems and it furthers the projects goals with respect to access. Also, as a quick note to those able to ediit the template, 37,000+ transclusions have to be updated even for the smallest edit / revert. Cheers. --MZMcBride 18:05, 7 June 2007 (UTC)

KK, but it's still shifted some 4 pixels left from the right margin of the article text ?cell/field?. Dysmorodrepanis 22:09, 7 June 2007 (UTC)

Usage statistics

Resolved

 – 37140 articles currently use this template. —Pengo 09:09, 10 June 2007 (UTC)

Can someone please tell me how many articles call this template; or better still, how to find that out for myself? Thank you. Andy Mabbett 09:50, 7 June 2007 (UTC)

The link you want is http://en.wikipedia.org/w/index.php?title=Special:Whatlinkshere/Template:Taxobox&limit=500&from=0 , but good luck counting how many pages of 500 articles use this template.... - UtherSRG (talk) 11:19, 7 June 2007 (UTC)

Although the whatlinkshere page only offers links up to 500, the backend accepts limits up to 5000, if you manually edit the url. So try http://en.wikipedia.org/w/index.php?title=Special:Whatlinkshere/Template:Taxobox&limit=5000&from=0 . Hesperian 11:33, 7 June 2007 (UTC)

Ya learn something new everyday. Too bad this was all I'm going to learn today. ;) Now if only we didn't have to use such tricks to count the pages.... - UtherSRG (talk) 11:50, 7 June 2007 (UTC)

Well, if you're an AWB user you could use the whattranscludeshere feature to load a session, then look at the count. Heck, I'll do it for you, it will only take a minute or two... 37140 articles. Hesperian 11:57, 7 June 2007 (UTC)

Thank you, all. Andy Mabbett 12:10, 7 June 2007 (UTC)

Template update

I see you guys trying to update Taxobox. How do you do thtat? Do you have a "template sandbox" where you make the changes to a copy of the template to see how it is going to look and after they are OK then you apply them to the actual template OR do you edit the actual template without the precaution? -- Boris 22:46, 9 June 2007 (UTC)

We try to edit in a sandbox, as it's easy to make mistakes. There's no universal sandbox for the taxobox, and instead people make their own. Details are at Template:Taxobox#Making_changes. —Pengo 09:06, 10 June 2007 (UTC)

Remove highlight from top heading

Since we've changed the style of the taxobox I've realised that the first line should have a plain (white) background. Can we remove the coloured highlight from the name field of the taxobox? The name is conceptually at a higher heading level than its "subheadings" such as "Scientific classification" and "Binomial name" etc, and the pink/green background should be reserved only for those "second level" headings. It would also look better when there was no photo. Does anyone disagree with this? —Pengo 08:25, 10 June 2007 (UTC)

On second thoughts, it looks awful unless the images are given their own pink/green subheading: like this. Which doesn't look great either. So forget it. I still prefer the format for taxoboxes without images, but I don't think taking images out of taxoboxes would be so popular —Pengo 09:01, 10 June 2007 (UTC)

Latin terms

I'd like to ask if some of the fields of this infobox are always latin terms, namely the binomial nomenclature or the different ranks of Scientific classification. That's because non-English words should be tagged using the {{lang}} template, in this case {{lang|la|...}} for (la for Latin). See Template talk:lang. This will be an easy change. Best regards, —surueña 07:47, 11 June 2007 (UTC)

No; scientific names (not "latin names", please!) often include words from other languages, or made up words. As I have suggested elsewhere, there is a need for a language code for such terms. Incidentally, I've also recently documented how the draft 'Species' microformat can help translation agents to know which words not to translate (such as "major" in Parus major). Andy Mabbett 09:40, 11 June 2007 (UTC)

I see... You are completely aware of the advantages of language tags, and that's a good thing. Yes, probably using microformats is the best solution until another approach is standarized. But I'm mainly concerned about accessibility issues, so in my opinion the microformat used should not only be focused in automatic translations but also in screen readers. Best regards, —surueña 13:59, 11 June 2007 (UTC)

I agree with your point about screen readers (I'm an accessibility advocate, too); and screen readers could indeed recognise microformatted content. However, that's a side issue for microformats, which are about marking up existing data so that it can be sued as metadata by parsers and user agents of any type. Cheers, Andy Mabbett 14:20, 11 June 2007 (UTC)

Of course it's a side issue, but what I want to say is that, in addition, the scientific terms also need some kind of "pronuntiation microformat". A screen reader cannot infer from the 'translation metadata' how to "render" those words, and thus it would be useless wrt accessibility. I'm not an expert about microformats, please, am I missing something? Best regards, —surueña 07:52, 12 June 2007 (UTC)

I think you have a point, but this would be better discussed on the microformats mailing list. Andy Mabbett 14:48, 12 June 2007 (UTC)

OK. And keep your great job at enabling semantic content in the web! —surueña 15:28, 12 June 2007 (UTC)

Thank you! Please consider joining the Microformats on Wikipedia project, and see discussion at What Wikipedia is not. Andy Mabbett 16:15, 12 June 2007 (UTC)

Offset from margin

{{editprotected}} The taxoboxes are still offset a few pixels (4 or so) from the right margin. Compare for example Sierra Madre Sparrow with Akkadian language. Somebody please correct that. Dysmorodrepanis 14:13, 11 June 2007 (UTC)

Done. Cheers. --MZMcBride 22:07, 12 June 2007 (UTC)

Nesting

Has any thought been given to applying the Wikispecies solution to taxoboxes, i.e. nesting classification templates? This would mean that when the affiliation of a taxon is changed, all relevant taxoboxes could be updated with a single edit. On the other hand, it might be regarded as imposing undue server load (although if that isn't a problem for Wikispecies, perhaps it wouldn't be a problem here either). The logistics might be a little complicated; I'm just curious if anyone has been exploring this possibility. -- Visviva 07:58, 12 June 2007 (UTC)

The problem I see with this is that this is exactly one of the things that causes problems with the accuracy of Wikispecies. These days, we're dealing with an increasing number of taxa the exact phylogenetic placement of which needs more data... Wikispecies all too often suggests accuracy when in the real-world science, there is none. Dysmorodrepanis 13:38, 12 June 2007 (UTC)

But it would be possible to include "incertae sedis" or where possible a link to a description of the controversy/lacuna/problem in the template for the relevant taxon -- and such a qualification would then be automatically transmitted to any downstream articles/templates using that template. The problem with the current situation is that when such problems arise, it is a Royal Pain to indicate them separately in every relevant taxobox, just as it is also a Royal Pain to reflect updates in the canonical taxonomy. -- Visviva 13:51, 12 June 2007 (UTC)

True, but this is possible right now too, and it would be more efficient (not to mention scientifically accurate) than to bloat the taxobox to include all vagarities of nomenclature. (Three examples: Bearded Reedling, Tapaculo and Stitchbird) But yes, it is indeed a pain. I'm not sure though whether such an automatized approach won't break more thing than it'll fix, because each of the 3 examples would probably require different treatment: one is incertae sedis, one is non-monophyletic, one is an unnamed recent split. Dysmorodrepanis 17:40, 12 June 2007 (UTC)

Unranked

A point for discussion: the present system of unranked clades doesn't reflect what these things are. The major point (and usefulness) is that an indefinite number of taxa can be set up hierarchically. That includes several unranked taxa between any two named ranks. For example, it is impossible to do a good taxobox for any given theropod with a known phylogeny - the systematics presented in the article can simply not be mapped onto the taxobox template. Unranked and ranked taxa need to be separated; it just doesn't make sense otherwise. IONO whether this is possible, but simply placing the output of "unranked =" where it stands in the sequence, and if multiple unranked clades are needed using "unranked1 =" "unranked2 =" might do the job. Dysmorodrepanis 17:40, 12 June 2007 (UTC)

It would be feasible to put a free-text field after every rank; would that be adequate? Otherwise I don't see anything that would work without making the code massively hairier than it is now. -- Visviva 12:54, 21 June 2007 (UTC)

I don't think that would do it. The way rank-free taxa work, there would need to be a theoretically infinite number of rank-free inserts after any ranked taxon... Dysmorodrepanis 15:18, 21 June 2007 (UTC)

type species

Could we include a type species space for articles about genera? Bendž|Ť 20:24, 17 June 2007 (UTC)

It's already there. - UtherSRG (talk) 02:42, 18 June 2007 (UTC)

But I don't think it should be used as often as it is. I have seen it used corractly maybe 1 time out of 20... the intuitive way to cite type species is formally totally off in most cases: why the type species of Homarus is correctly cited as Astacus marinus Fabricius, 1775 is a bit hard to understand, stupid ICZN! It is better to just denote the type species in a species list like here: Palaeeudyptes. That way, you won't have to browse the nth edition of Systema Naturae of whatnot. Dysmorodrepanis 07:22, 18 June 2007 (UTC)

Some documentation on these issues would be very helpful, I think, since most editors who use the taxobox are (like me) sincere amateurs, who want to do things correctly but often fail to understand the complexities involved. Wikipedia:Taxonomy, perhaps? I'd write it if I could. ;-) -- Visviva 11:27, 26 June 2007 (UTC)

Dys - neither of those taxoboxes use a type species. Check out Eulemur for how it is used properly. - UtherSRG (talk) 23:53, 26 June 2007 (UTC)

I had been wondering if piping might be an acceptable solution. :-) -- Visviva 00:37, 27 June 2007 (UTC)

Piping from where? The correct name for a lot of taxa is not found anywhere on WP expect in the most complete synonymies. Dysmorodrepanis 11:37, 4 July 2007 (UTC)

Presumably based on information found in a reliable source off-wiki, in the form [[Current taxon name found in reliable source|original taxon name found in reliable source]], ideally with a footnote attached... Or perhaps I'm not understanding your question. -- Visviva 12:34, 4 July 2007 (UTC)

Yes I know. Homarus example is given in ICZN. Palaeeudyptes is example for alternative approach not using param. Eulemur is a good example indeed, but Homarus would be even more bizarre (as in such extreme cases, even the species name would not be valid anymore today. See ICZN Recommendation 67B). This is a problem most common in taxa descrived in the late 18th century, but it has hitherto prevented me from using the param in fossil birds, where it is a problem for lots of taxa described in the 20th century. It's simply too time-consuming (and might be considered OR by some) to find out the correct citation as per Recommendation 67B, so usually I prefer annotating the type species like in Palaeeudyptes.

What the ICZN example does not discuss is the use of technically valid but suppressed names: is it legit to cite the type species of Archaeopteryx as Pterodactylus crassipes Meyer, 1857? Because that was the first valid name ever attached to a specimen of Archie, though it is not deemed valid anymore today. Also illustrates the problem: seeing P. crassipes as type species of Archie would make anyone except experts go WTF?!. The point is that a currently valid taxon is by and large the least correct input for the param - yet it is the most intuitive one. Dysmorodrepanis 11:37, 4 July 2007 (UTC)

Species microformat update

A new user script for the 'Species' microformat has been released; adding extra search options and improving the search facility for ranks other than binomials. See above for background information. Andy Mabbett 08:58, 21 June 2007 (UTC)

There's a new beta version of Operator (0.8b). One of the improvements is an optional icon in the location bar, when a page with a microformat is visited. Andy Mabbett 10:23, 4 July 2007 (UTC)

Default value for name

{{editprotected}}

Could {{{name}}} be replaced with {{{name|{{PAGENAME}}}}} so that it only has to be specified when you need a different name? (I've always liked to keep the size of templates in articles to a minimum as huge templates make editing the text more difficult and daunting). Thanks. Verisimilus T 10:32, 26 June 2007 (UTC)

Done; seems straightforward and meritorious. -- Visviva 11:28, 26 June 2007 (UTC)

Thanks for your prompt action! Verisimilus T 12:56, 26 June 2007 (UTC)

Please have a look at the updates required for species microformat, above, in this context - I'd be grateful for suggestions! Andy Mabbett 15:58, 26 June 2007 (UTC)

Proposed changes

Automatic categorisation; allow UK spelling

{{editprotected}} Somebody recently added Category:Animal to one of my watched articles with a taxobox and it struck me that this ought to be redundant; the template could easily do this itself. In fact, the more I think about this, the more the template could automatically do things. I'll present this option first, then add a second once I've had a good think about it. I'm not sure whether the "category" attribute should override the default or not - this is easily modified. Code could easily be written to place things in a kingdom-level category; however, not being 100% sure of how categorisation should work, is this in fact what we want, or are things better placed solely in more specific sub-categories?

Secondly, as Wikipedia tries not to favour US or UK spelling, could the following amendments be made to the entire template? That way, the colour can be specified with or without a u and will be understood by the template. A "transparent" default should probably be specified for the first "{{{color}}}" anyway.

{{{color}}} → {{{color|{{{colour|transparent}}}}}}
{{{color|transparent}}} → {{{color|{{{colour|transparent}}}}}}

Verisimilus T 09:50, 1 July 2007 (UTC)

Automatic colour detection

I've written a sub-template, {{Taxobox colour}}. "transparent", where it appears above, can now be replaced with {{Taxobox colour|{{{regnum}}}}}: this will auto-detect the colour and remove the need to check which colour is appropriate and specify it in the template, whilst allowing the colour to be overruled if required. Verisimilus T 09:50, 1 July 2007 (UTC)

{{editprotected}} As per the preceding two points, to which no objection has been raised, please make the following amendments wherever the terms appear in the code:

{{{color}}} → {{{color|{{{colour|{{Taxobox colour|{{{regnum}}}}}}}}}}}
{{{color|transparent}}} → {{{color|{{{colour|{{Taxobox colour|{{{regnum}}}}}}}}}}}

The further points below may be worth considering; I'll give them more thought later and they can be addressed at a separate time, as they are of low urgency.

Verisimilus T 21:15, 6 August 2007 (UTC)

Done. Cheers. --MZMcBride 21:58, 8 August 2007 (UTC)

{{editprotected}}

Thanks for your implementation. Having spent a little time checking that it's working, I've noticed a couple of compatibility issues. Therefore, could the following amendment please be made to accommodate viruses, and non-word results? Cheers, Verisimilus T 18:19, 9 August 2007 (UTC)

{{Taxobox colour|{{{regnum}}}}} → #{{Taxobox colour|{{{regnum|{{{virus_group}}}}}}}}

Done. Cheers. --MZMcBride 19:06, 10 August 2007 (UTC)

Furhter automating

I've always been one for automation...

Just another thought; we could avoid the creation of redirects etc. by letting the user specify the kingdom without wikilinks, and allowing the template to deduce which kingdom they mean and provide a suitably wikilinked output. It'd probably take me 20 minutes to knock the code together and I'm meant to be doing lots of other things, so I thought I'd get some consensus as to whether this is worth doing or not in terms of whether it would make a noticeable difference to server load or page load times. Would the slickness added ease-of use outweigh these possible costs?

Verisimilus T 09:55, 1 July 2007 (UTC)

Discussion

I've refactored the discussion slightly for clarification. This template has a very high usage, so changes should be combined into single edits, rather than successive edits. It seems that there are various changes being proposed; I've disabled the editprotected tag for the time being to allow discussion and consensus to emerge before changes are made. If anyone wishes to comment on these proposed changes, please do so below. Cheers. --MZMcBride 18:42, 1 July 2007 (UTC)

What would happen to stuff like Ediacaran taxa, which are incertae sedis at the kingdom level? Dysmorodrepanis 22:18, 1 July 2007 (UTC)

I don't think either of the proposals would alter our handling of taxa like Dickinsonia. The color template and the kingdom-recognition thingy could both have a special setting for "incertae sedis"; or the settings could be done by hand for each article. (Probably the former is better). -- Visviva 01:17, 2 July 2007 (UTC)

There's a number of choices here:

1. Manually, as is currently done. Not a good option for Ediacarans because you have to learn the string #e0d0b0, and not forget the hash.

Why don't we simply use "tan" (#d2b48c) instead? Dysmorodrepanis 11:18, 4 July 2007 (UTC)

1. By recognising the term "incertæ sedis" and setting the colour if that term is present. Weakness: there's a lot of ways of saying "incertae sedis" - with and without italics, or alternatives such as "unknown" or "uncertains", for example; each of these scenarios would need pre-empting and correcting.
2. Set any unrecognised kingdom to #e0d0b0. Weakness: if someone specifies a kingdom in a non-anticipated way, it will show up as brown.
3. Set the colour to #e0d0b0 if no kingdom is specified.

Further, it would probably be worth adding an error message to the taxobox if the kingdom is unrecognised. I'll get to work on a candidate template to perform this function.

Verisimilus T 09:16, 2 July 2007 (UTC)

Unrecognised kingdom spotter

Sorry to break up the flow of the discussion - feel free to add to it wherever you deem it appropriate!

I've set up a template {{Taxobox unrecognised kingdom}} and think the best way to use it would be as such:

{{#if:{{{no_error_message|}}}||{{Taxobox kingdom check|{{{regnum}}}}}}}

I've considered turning the error message off is a colour is specified, but feel that we might as well encourage the editor to use the proper description for the kingdom anyway.

Verisimilus T 10:05, 2 July 2007 (UTC)

Hmm. How would this affect the many protist articles which now do not have Kingdom=Protista in their taxoboxes? Most have been switched to one of the supergroups. It'll help with vandals who put Kingdom=Fart, but I personally think it would be best to wait until the whole kingdom thing settles down, and their is near unanimous consensus in the taxonomic community. Werothegreat 01:50, 17 July 2007 (UTC)

This template would still be useful in at least 99% of articles, where there's no chance of organisms being unclassified as a plant or animal, say. I suppose the error message should only be displayed if neither Kingdom nor Color are specified. That way no existing article will be affected, but new taxoboxes can be added without the necessity of referring to the documentation. Verisimilus T 19:40, 22 July 2007 (UTC)

Section Authority

Suggest indenting all authority fields, as this will make the box read better.--algocu (talk) 18:57, 21 November 2007 (UTC)

Request for an additional field

Could I propose that the field "type locality" be added to the taxobox as an optional field? SP-KP 22:49, 1 July 2007 (UTC)

Sounds good to me. Of course ideally this information (in fact, all of the information in the taxobox) could be transcluded from Wikispecies, but interwiki transclusion seems to be going nowhere fast. Not sure why; we already have the technology to transclude image-description pages complete with templates, so it's somewhat bewildering that we still can't use Wikispecies for the purpose for which it was built. But oh well... I agree that a type_locality field would be very handy. -- Visviva 01:19, 2 July 2007 (UTC)

Against, because a) the type species field is hardly ever used correctly due to lack of access to the original information, and a type locality field would require the same information. For nearly half the extant bird species, for example, it would virtually be unusable for anyone who does not have access to Peter's Check-List. Do you have access to Peter's Check-List or know anyone who does? b) Wikispecies is anything but a good and reliable source; it is not well-maintained and for many if not most taxa, the information on WS is outdated by years or even decades, and ill-referenced to boot. Any such information could be added to the text... whenever it is needed. For most extant taxa, it's purely trivia. What about type localities of junior synonyms, which are more important (on average) than the type locality proper, as they have some taxonomic bearing and sometimes are actually what permits assigning a taxon to synonymy?

I think we should avoid like the plague overloading the taxobox with information, making it ever longer and longer. There are already too many "ugly stubs" like Eritini. The advantage of the taxobox is IMHO that it is so sleek and easily readable. Dysmorodrepanis 11:05, 4 July 2007 (UTC)

There's no requirement that a field be used just because it exists... but thinking it over, perhaps such information isn't really needed in the taxobox. If the events surrounding the original description of the species are worthy of note, the type locality can be addressed in the article text. If not, well, taxonomical information is what we have Wikispecies for.

Of course, like any wiki Wisp is only as good as the people contributing to it. The principal problem, as I see it, is that Wikipedia is effectively competing with Wikispecies; we don't include dictionary definitions or textbooks here, but we do include extensive taxonomic information (often far more than our simple mandate as an encyclopedia would indicate). But anyway... we stray from the topic. -- Visviva 12:43, 4 July 2007 (UTC)

Sarefo, who's a buddy of mine and heavily into spiders, always tries to include taxonomic information - in fact, if he creates a stub, it usually consists 80% of taxonomic information. I usually also add as much taxonomic info as I can find, especially for fossil birds, and there is a general trend among the Dino project to discuss type specimens and locations in the text, because they often have some significance. See for example Palaeopteryx. Dysmorodrepanis 17:28, 4 July 2007 (UTC)

I disagree that the info isn't relevant to the taxobox. It's taxonomic information, so surely that's the appropriate place for it? I take Dysmorodrepanis' point about the obscurity of the info for some taxa for some of the passerines, but that'll be resolved when HBW is complete in the next few years. And as Visviva says, I'm suggesting this as an optional field - it wouldn't appear unless editors add it. SP-KP 17:37, 4 July 2007 (UTC)

While for many animals, the type locality is not relevant, it is for many, if not most fossils and plants. However it remains an extremely obscure information of at best dubious use in non-taxonomical works. Circeus 18:05, 4 July 2007 (UTC)

More obscure/dubious than authority & date? If so, can you say why you feel that? SP-KP 18:34, 4 July 2007 (UTC)

Fossil range inadequate

May I suggest that "Fossil range" is re-worded somehow? I can't yet come up with a good description, but some groups are known to exist before they are fossilised. For example, fossils - even trace fossils - of Archaea are not universally accepted before about 1,000 million years ago, whilst isotopic evidence suggests that they existed from 2,700 million years ago or more; Dinoflagellates and Coccolithophores (if I recall correctly) leave chemical biomarkers such as steranes before their fossil record begins. Maybe "Geological record" would be a better term?

Whatever was decided, the parameter fossil_range could remain, with geological_range (or whatever) overriding it where it's specified; this would avoid extensive re-writing of existing articles.

Verisimilus T 10:14, 2 July 2007 (UTC)

Since the param is not restricted to a specific input, what keeps one from simply adding an "(but see text)" after the range? I use that all the time when it's appropriate. Assignment of ichnofossils to "true" taxa is always a somewhat inexact and subjective matter. With a system as you propose, it'll be only a matter of time until someone extends the fossil range of Aves into the Triassic based on Trisauropodiscus... Dysmorodrepanis 11:14, 4 July 2007 (UTC)

That's a good suggestion - thanks! Verisimilus T 19:26, 11 July 2007 (UTC)

See for example Epidendrosaurus. Dysmorodrepanis 03:49, 12 July 2007 (UTC)

Superdomain request

{{editprotected}}

Can we please add provision in the source code for a superdomain? This would be specifically for the Archaea and Eukaryote articles, allowing them to have the inclusive group Neomura in their taxobox. Werothegreat 16:40, 14 July 2007 (UTC)

This is not a simple request; someone will need to write and test the code, and then put up an editprotected tag for the code to be copied over here once there is agreement that it functions as desired. If you need help writing the code, you can ask at Wikipedia:Requested templates. — Carl (CBM · talk) 19:47, 15 July 2007 (UTC)

The code is:

|-valign="top"
{{#if:{{{superdomain|}}}|
{{!}} Superdomain:
{{!}} <span class="domain">{{{superdomain}}}</span><br /><small>{{{superdomain_authority|}}}</small>}}

Can someone please implement this? It's been here for a while, but nothing has been done with it so far... Werothegreat 21:18, 3 August 2007 (UTC)

Done. Please use sparingly. -- Visviva 03:56, 17 September 2007 (UTC)

New field

{{editprotected}}

Please could the additional field "Type locality" be added to the template. Feel free to message me on my talk page if clarification is required. SP-KP 16:49, 14 July 2007 (UTC)

Please write and test the code, and find consensus for it, and then put up a request for the code to be copied over here. Because only a few admins handle these requests, we don't usually have time to do the writing, testing, and discussion ourselves (on average there are over 20 of editprotected requests per day). If you need help writing the code, you can ask at Wikipedia:Requested templates. — Carl (CBM · talk) 19:49, 15 July 2007 (UTC)

Judging from the previous discussion, there doesn't seem to be a strong consensus for this. On reflection, I do not object; however, I would like to see comments from others before this is implemented. -- Visviva 00:13, 17 September 2007 (UTC)

Violation on WP:SELF

{{editprotected}}

The link to Wikipedia:How to read a taxobox on this template violates WP:SELF: "Any article in the article namespace that links to one in the Wikipedia namespace". Remember that a concern of self-references is that they "limit the use of Wikipedia as an open source encyclopedia suitable for forking, as permitted by our license". Look how the copy of Bacteria appears on answers.com. Zzyzx11 (Talk) 15:49, 15 July 2007 (UTC)

I agree that this should be removed - I'm not sure how useful the linked-to page is, anyway. Verisimilus T 16:12, 15 July 2007 (UTC)

The documentation is on a doc subpage and is not protected; you can edit it without admin assistance. — Carl (CBM · talk) 19:46, 15 July 2007 (UTC)

You appear to have misundestood the reqest, which was for the "i" imagemap to be removed from the template. Verisimilus T 20:49, 15 July 2007 (UTC)

Hm... it's been up for awhile, and I'd hate to de-link a help page someone obviously put a lot of work into, but I also have to admit it's not clear to me that we need this particular self-reference. If there are parts of the infobox which remain unclear, perhaps we could put some energy into making them more self-explanatory? – Luna Santin (talk) 23:01, 15 July 2007 (UTC)

The solution may be just to wrap the link in {{selfref|(code for the link)|2=}}, which will make it easier for mirrors to remove the link at their end, just like is done with disambiguation headers to projectspace. (Mirrors are supposed to blank Template:Selfref before rendering the pages, which would make the link disappear there.) --ais523 17:32, 16 July 2007 (UTC)

Huh, I haven't seen that one, before. Makes some sense, but there's still the issue of whether this particular self-reference is to be desired (seems open to discussion?). Might be an issue for the village pump, this talk page doesn't seem to be developing too much discussion. – Luna Santin (talk) 22:21, 16 July 2007 (UTC)

selfref doesn't seem to work in an imagemap. I could probably redo it as a div. — Carl (CBM · talk) 00:28, 17 July 2007 (UTC)

I say get rid of it. I've never liked it. Hesperian 00:34, 17 July 2007 (UTC)

I removed it. — Carl (CBM · talk) 01:33, 17 July 2007 (UTC)

"Need taxobox" template

A new template, Template:Needtaxobox, is available for the purpose of tagging articles that do not yet have a taxobox. The "What links here" function can be used to comb through articles needing a taxobox. Badagnani 19:00, 31 July 2007 (UTC)

The template "Taxobox needed" used to fulfil this role but the deletion brigade removed it. I personally found it very useful, but you may want to check its templates for deletion log to see why it was judged delete-worthy.

Also, you could add "[[Category: Articles lacking a taxobox]]" to the template to add all template-bearing pages to a category page, which is more merituous than the "What links here" for a number of reasons. Verisimilus T 12:15, 4 August 2007 (UTC)

After making a few redirects, I found the "old" template and just used that instead of the new one, which was very similar. So the one linked to is the old one. It has a few synonyms now, such as "needtaxobox" or "needstaxobox." Badagnani 14:27, 4 August 2007 (UTC)

Super, thanks: Maybe it wasn't deleted as I thought. Verisimilus T 15:50, 4 August 2007 (UTC)

No, the old one is definitely the only one. Redirects can be found at http://en.wikipedia.org/wiki/Special:Whatlinkshere/Template:Missing-taxobox , so if someone forgets the (long) template name, one can just type "Needtaxobox" or "Needstaxobox" and it will come up. Badagnani 08:45, 5 August 2007 (UTC)

New param

Can somebody please insert the following line under (I think) the "|NE|ne=...":

|NR|nr=''Not recognized''

Thanks. Dysmorodrepanis 15:32, 27 August 2007 (UTC)

Done. - UtherSRG (talk) 18:46, 27 August 2007 (UTC)

What's it for? Does the IUCN state when it doesn't recognise a species? —Pengo 21:20, 27 August 2007 (UTC)

Least Concern

{{editprotected}} Shouldn't the words "Least concern" under the conservation status be changed to "Least Concern"? That's the capitalisation in use on the IUCN Red List. Bart133 ^{(t) (c)} 22:24, 30 August 2007 (UTC)

 Done Well spotted. Neil ム 13:24, 31 August 2007 (UTC)

Automatically italicising genus and species names

Is there any reason we don't do this already? I can't think of one instance where the genus or species shouldn't be italicised!

If a change was made to the template, Taxobot could easily update all the articles as it passes through them to make other changes - it may as well do it all in one go!

Thanks

Verisimilus T 16:20, 1 September 2007 (UTC)

If you're going to change things, make sure that you can handle cases like Brocadia anammoxidans. Eugène van der Pijll 17:07, 1 September 2007 (UTC)

Thanks for pointing that out. This can be easily handled, but I'll have to bear it in mind when I write the code. Verisimilus T 17:39, 1 September 2007 (UTC)

How about Pied Raven? Dysmorodrepanis 14:38, 2 September 2007 (UTC)

Since the genus, species and sub-species names should be italicised, this would be handled in the same fashion as any other page. Verisimilus T 16:58, 2 September 2007 (UTC)

Please be aware that plant subspecies and varieties contain a rank term that should not be italicised; for example, Banksia integrifolia subsp. monticola. Hesperian 00:24, 17 September 2007 (UTC)

When this change is implemented, a pair of apostrophes will be added to the template code, with a space separating them from the {{{binomial}}} parameter (to accommodate Brocadia anammoxidans). The bot will then remove the outer pair of apostrophes, if present, from each page. Therefore, Banksia integrifolia subsp. monticola will not need any special consideration. Verisimilus T 20:08, 18 September 2007 (UTC)

So, suggested edit:

Effect: Automatically italicise species and genus names.

Reason for proposition: Generic and specific names must always be italicised. This edit means that this doesn't have to be dome manually in each box, making the creation of new taxoboxes easier and less confusing (it avoids having five apostrophes together where bold type is required).

Side effects: All unusual cases suggested can be dealt with (see above). The immediate consequence will be that existing taxoboxes will require de-italicising; this should be an arbitary task for a bot.

Specific details:

Replace

{{{genus}}} with ''{{{genus}}}''

{{{subgenus}}} with ''{{{subgenus}}}''

{{{type_genus}}} with ''{{{type_genus}}}''

{{{species}}} with ''{{{species}}}''

{{{species}}} with ''{{{subspecies}}}''

{{{type_species}}} with ''{{{type_species}}}''

{{{binomial}}} with ''{{{binomial}}}''

Thoughts welcome before I request the edit. Verisimilus T 00:08, 28 January 2008 (UTC)

It's a sensible suggestion, and I've thought about it myself, but in the end it doesn't work. Because sometimes the genus is bold, and sometimes it's linked, and sometimes it's linked to something other than the text, and sometimes it contains non-italic text. Accounting for all these cases would at best make the taxobox much more difficult or confusing to use, and at worst make it broken in some corner cases. E.g. In some cases you'd have to remember to bold, but not italicize the text. No big deal? But you've just made using the taxobox much less transparent, and requiring more specialized knowledge to use. Besides which, the transition period (running the bot and "retraining" everyone who uses the taxobox) would be a nightmare. —Pengo 00:07, 29 January 2008 (UTC)

I agree with Pengo. This is a bad idea. We'll be required to type bizarre markup like

Banksia integrifolia'' subsp. ''integrifolia

for the sole reason of saving a few 's? There is also the case of taxa with provisional names of the form "Genus sp. Location", which generally don't warrant articles but sometimes do if they are endangered - Polbot has created a number of these. Note that these don't finish with a '', so there would be no way to mark this up correctly. Hesperian 00:19, 29 January 2008 (UTC)

Automatic name detection

On this vein, the automatic naming could use some tweaking. When I've got consensus on the previous point, I'll propose one of the following edits:

Replace Taxobox/Archive 10 in the title of the taxobox with:

If genera automatically italicised per point above

{{#ifeq:{{PAGENAME}}|{{{genus}}}|''{{PAGENAME}}''|{{#ifeq:{{PAGENAME}}|{{{species}}}|''{{PAGENAME}}''|{{#ifeq:{{PAGENAME}}|{{{binomial}}}|''{{PAGENAME}}''|{{PAGENAME}}}}}}}}

If decision is made to leave taxoboxes as they are, i.e. require every genus to be manually italicised:

{{#ifeq:{{PAGENAME}}|{{{genus}}}|''{{PAGENAME}}''|{{#ifeq:{{PAGENAME}}|''{{{genus}}}''|''{{PAGENAME}}''|{{#ifeq:{{PAGENAME}}|{{{species}}}|''{{PAGENAME}}''|{{#ifeq:{{PAGENAME}}|''{{{species}}}''|''{{PAGENAME}}''|{{#ifeq:{{PAGENAME}}|{{{binomial}}}|''{{PAGENAME}}''|{{#ifeq:{{PAGENAME}}|''{{{binomial}}}''|''{{PAGENAME}}''|{{PAGENAME}}}}}}}}}}}}}}

Thanks. Verisimilus T 16:26, 1 September 2007 (UTC)

Erm... what would this do exactly, for those of us who can't interpret the Matrix visually? ;) Dinoguy2 00:21, 2 September 2007 (UTC)

Sorry. Been spending too long coding! It would italicise genus and species names in the title, without the need to specify them in the "name=" field. Verisimilus T 09:02, 2 September 2007 (UTC)

I've been digging through too much Polbot-related nonsense in the last weeks to state anything else than: please, no automatization! First we should clean up the mountain of —— that the last attempt created (see List of endangered animal species), lest we're gonna see things like Enders' S Small-eared Shrew, Lipochromis sp. nov. 'backflash cryptodon' or Rana-ladrona Enana-chiapaneca all over taxoboxes. Wikipedia's inclusiveness has reached an amazing level as regards endangered animals. But at the same time, its quality has dropped through the floor in these articles. I estimate up to one-quarter of all animal species articles to be faulty, in need of copyediting, and unfit for further automatizing.

(Why BTW do we also have List of endangered species?)

All such automatizing is bound to result in a small reduction in workload purchased with a drastic drop in quality. Dysmorodrepanis 14:36, 2 September 2007 (UTC)

Sorry not to make myself clear. Here's how this will work.

If the name of the page matches the genus, species or binomial name in the taxobox, and no "name" parameter is specified, the taxobox will display the name of the page as the title of the taxobox, in italics. If it doesn't match one of those three parameters, and no "name" parameter is specified, it will display the name of the page - as happens currently.

If you can see any way that this could mess up, or indeed change, any existing article; or if there is any way that this could reduce the quality of any article, please let me know.

By the way, Polbot's operator seems more than happy to undo any damage he causes - have you tried speaking to him about these issues? Verisimilus T 16:55, 2 September 2007 (UTC)

Ah, now I see. OK, that sould work cool. I thought it would invonve article text.

As regards Polbot: The situation is probably manageable. Furthermore, the sheer amount of edits to be corrected and the inability to do this automatically virtually makes it unworthwhile to do so in a dedicated effort. We'll get the errors by and by; most would require manual correction anyway. Dysmorodrepanis 01:43, 17 September 2007 (UTC)

We have List of endangered species because no one's made a good automatically generated list to replace it. Critically endangered species is a hand-crafted list, and, last time I looked (some time ago) it had a heap of less-than-critical inclusions, and what is included in the list is very arbitrary. I started on an automated list that would resemble other lists of species we have (i.e. with a bit of a cladistic structure), but I ran out of steam after considering other non-IUCN systems that should be included. The new red list is due out in about a week I believe, so I might have another go then (time permitting). Automation can be done well, but like with software in general, it often isn't. Beastie Bot only generated a handful of complaints, mainly regarding odd referencing styles it didn't recognise.. And now that <ref>ish referencing seems to be the norm, it would be easier to get it right. So please don't rubbish automation in general. I've been considering generating a paragraph about the conservation status (e.g. subspecies status, causes, status history) and sticking it in the talk page of every IUCN-assessed species so that it can be hand-added to the article if the points aren't already addressed. Maybe this would be a better way of going about automation. E.g. have Polbot only put basically the taxobox on the page and "xyz is a species of frog", and the rest in talk? —Pengo 00:53, 3 September 2007 (UTC)

Completely agree. Note that I wouldn't want to miss automatizing e.g. redlist references. Only when it comes to the article text and other such entities with much intra"specific" variation, bots usually mess things up. E.g. the name field in the IUCN redlist, which Polbot treats as multiple names that are all equally valid and have English standard orthography. It has to if it wants to work the field at all, probably (I think a few cases exist where the first name in the redlist is superceded by BirdLife or systematic/taxonomic changes). Dysmorodrepanis 01:48, 17 September 2007 (UTC)

{{editprotected}}
Perceived problem:

1. The "name" parameter is largely redundant.
2. Currently, if unspecified, it is replaced with the page's name.
3. When the page is named after a species or genus, the taxobox name should be italicised.

Edit requested: Please replace {{{name|{{PAGENAME}}}}} with {{{name|{{Taxobox name|{{{genus}}}|{{{species}}}|{{{binomial}}}}}}}}

Edit effect: If any of the "genus", "species", or "binomial" parameters specified in the template EXACTLY MATCH the name of the page, AND the "name" parameter is unspecified, the page's name in italicised form will be adopted as the name for the taxobox.

Proposed by: Verisimilus T 17:17, 20 September 2007 (UTC)

 Done - Nihiltres^(t.l) 16:26, 22 September 2007 (UTC)

Subsection request

{{editprotected}}

I noticed there is no Subsection in the Taxobox template when editing entries under Rhododendron. This very large genus includes subsections in the RHS classification. --Mgoodyear 20:27, 9 September 2007 (UTC)

What change are you proposing? Putting up an editprotected tag is the last step of changing a template. First the new code has to be written and tested, and agreed upon. — Carl (CBM · talk) 01:51, 13 September 2007 (UTC)

This appears to be correct; there should be a "subsectio" section. Specifically, following the "sectio" section, we should have the following code:

|-valign="top"
{{#if:{{{subsectio|}}}|
{{!}} Subsection:
{{!}} <span class="domain">{{{subsectio}}}</span><br /><small>{{{subsectio_authority|}}}</small>}}

I assume this is what was meant? -- Visviva 00:06, 17 September 2007 (UTC)

IUCN links broken

Earlier today I noticed that some of the IUCN Red List classification indicators are broken. For example, if you look at Python molurus, you'll see what I mean. In this case, the link to the image Status_iucn2.3_NT.svg is not working. Did somebody delete or rename these images? --Jwinius 20:34, 15 September 2007 (UTC)

Correction: apparently, the images are still there, but they're simply not being linked to. What's going on? --Jwinius 14:30, 16 September 2007 (UTC)

I think its just a server problem. There seems to be problems with quite a few images not loading. Should be working soon, i hope. Chris_huh^talk 14:41, 16 September 2007 (UTC)

Yep, it was server issues. —METS501 (talk) 14:57, 16 September 2007 (UTC)

I'm still seeing problems. Image:Status_iucn3.1_VU.svg is not appearing in the taxoboxes, even though the image is there. For example see Polar Bear. Similar images such as 3.1_CR and 2.3_VU are working fine. Is this also symptomatic of server troubles?--Yannick 03:48, 17 September 2007 (UTC)

Works now.--Yannick 22:51, 17 September 2007 (UTC)

"A server ran out of disk space. It has been fixed. This is the cause of most (all?) of the recent spike of broken thumbnails." (links: Wikitech-l, Signpost) —Pengo 02:46, 25 September 2007 (UTC)

plant autonyms

What are we going to do about full citations for plant autonyms, folks? The taxoboxes misplace the author citations. Here's some examples:

Banksia subg. Banksia

The taxobox reads "Banksia subg. Banksia L.f.", whereas it should read "Banksia L.f. subg. Banksia";

Banksia sect. Banksia

The taxobox reads "Banksia sect. Banksia L.f.", whereas it should read "Banksia L.f. sect. Banksia";

Banksia ser. Banksia

The taxobox reads "Banksia ser. Banksia L.f.", whereas it should read "Banksia L.f. ser. Banksia";

Banksia integrifolia subsp. integrifolia

The taxobox reads "Banksia integrifolia subsp. integrifolia L.f.", whereas it should read "Banksia integrifolia L.f. subsp. integrifolia".

Banksia armata var. armata

The taxobox reads "Banksia armata var. armata (R.Br.) A.R.Mast & K.R.Thiele", whereas it should read "Banksia armata (R.Br.) A.R.Mast & K.R.Thiele var. armata".

I can't see an obvious solution to this, but it really, really does need to be fixed. If we can't master basic nomenclature, we might as well pack up and go home. Hesperian 13:20, 17 September 2007 (UTC)

Actually I have manually tweaked some of these so that they read correctly, but that doesn't change the fact that this problem exists. Hesperian 13:21, 17 September 2007 (UTC)

Collapse feature

The use of this template in the Cape Hyrax article has a few spatial issues. Is it possible to collapse the template or sections of the template? --Aarktica 16:39, 21 September 2007 (UTC)

The only problems I'm seeing with my browser is that there are too many right aligned images beneath the taxobox. I would argue against collapsing taxoboxes. --Aranae 17:02, 21 September 2007 (UTC)

It was just a thought. The idea was to have a feature that would allow the box to be collapsed for aesthetic reasons. This would be analogous to the consolidation of Wikiproject banners on talk pages which have a show/hide option. --Aarktica 20:40, 21 September 2007 (UTC)

Arguably a not too shabby option for Classification, Map and Synonyms. The other sections probably contain too much information directly relevant to the page. Map does too of course, but the map's the one piece of taxobox that I also find hardest to tweak to get a good layout. Dysmorodrepanis 22:06, 21 September 2007 (UTC)

I guess this is rather different from ###px that can be used to resize pictures? --Aarktica 22:23, 21 September 2007 (UTC)

diversity link

i think it's inconsistent to link to a species list via the "Diversity" line, mainly because the other headings ("Scientific classification", "Type species") link to a general article about the subject. i would propose to really link to an article about diversity, and instead link to the species list from the line below, which mentions the number of species/genera etc. other than that, the taxobox is the best thing since computers started to have a monitor ;) --Sarefo 13:41, 25 September 2007 (UTC)

NEED ADDED: subpopulation conservation status listings

I am hoping to update the Sockeye salmon page with its soon to be released status assessment. The taxobox allows for the IUCN global listing to be entered, but for sockeye (as well as other species), the red listing gets evaluated at the subpopulation level as well.

I would like to update the taxobox to allow for this; it would essentially look the same as it does now, but also allow users to type in the names and status for individual subpopulations. Can this be accommodated? Thanks,--Slloyd01 22:45, 12 November 2007 (UTC)

Why not make new pages for the subpopulations, the way we make new pages for subspecies? - UtherSRG (talk) 22:50, 12 November 2007 (UTC)

In this particular case we are working with over 70 subpopulations. It would be a lot of work to create separate pages for each; not to mention there would probably be a lack of content other than the taxobox itself.--Slloyd01 23:04, 12 November 2007 (UTC)

In that case, wouldn't that mean adding 70 status assesments to the taxobox? That would not be appropriate, I think. You'd probably best put them in a separate section in the article itself. -- Eugène van der Pijll 15:47, 13 November 2007 (UTC)

Agreed. It probably doesn't make sense to include all the listings in the taxobox. It would be nice to include at least a summary of the listings there though. (e.g. 20 subpopulations are listed critically endangered, 10 endangered, 40 of least concern) Is there a way I could do that right below the global listing? It wouldn't need to have the graphic as well if that is too complicated. —Preceding unsigned comment added by Slloyd01 (talk • contribs)

As Eugene suggests, just put it in the article text. - UtherSRG (talk) 19:30, 13 November 2007 (UTC)

Imagemap

I think this should have an imagemap to the place where it says Least Concern, EExtinct, etc. Clicking on one of the bubbles will go to the right page. Remarks? Soxred93 has a boring sig 00:16, 14 November 2007 (UTC)

Conservation status: Fossil

Is there any article where this is actually the case, and a "fossil-range" wouldn't be more appropriate? I see hundreds of these things around and sometimes wonder whether the committee really meet to discuss the conservation status of trilobites etc...

Verisimilus T 10:35, 16 November 2007 (UTC)

No, "fossil" is not an official conservation status given by any organization other than by Wikipedia (the same goes for "pre-history" and "domesticated"). And it's there because it's been like that for a long time, and not for any particularly good reason. I guess in some cases it shows that a taxon is a fossil when the fossil range is not known or hasn't been added yet. I find it odd myself. —Pengo 12:46, 19 November 2007 (UTC)

{{editprotected}}

In that case, could the following edit please be made:

Replace:

|FOSSIL|Fossil|fossil=Extinct ([[fossil]])

with:

|FOSSIL|Fossil|fossil=[[Category:Invalid conservation status]]

Thanks, Verisimilus T 16:30, 20 December 2007 (UTC)

That would leave an empty div in the output, which is not best practices. If this needs changed, it's worth doing well. — Carl (CBM · talk) 17:39, 20 December 2007 (UTC)

Could we have it both ways, i.e.:

|FOSSIL|Fossil|fossil=Extinct ([[fossil]])[[Category:Invalid conservation status]]

? Just curious... -- Visviva (talk) 07:38, 23 December 2007 (UTC)

The first way is better in that it makes it clear to users that they shouldn't have put in "fossil" - empty divs are of course better avoided, but it won't take too long for the offending articles to be cleaned up. It seems odd to me to have an invalid conservation status appearing. Verisimilus T 14:10, 23 December 2007 (UTC)

{{editprotected}} This solution should meet everybody's concerns.

Replace:

|FOSSIL|Fossil|fossil=Extinct ([[fossil]])

with:

|FOSSIL|Fossil|fossil=n/a (fossil)[[Category:Invalid conservation status]]

Thanks, Verisimilus T 16:20, 25 January 2008 (UTC)

I changed it. — Carl (CBM · talk) 19:46, 27 January 2008 (UTC)

Taxobox colours

{{editprotected}}
In preparation for taxobox colour changes (discussed here, comments welcome), could the following code:

{{{color|{{{colour|#{{Taxobox colour|{{{regnum|{{{virus_group}}}}}}}}}}}}}}

be replaced with:

{{{color|{{{colour|#{{Taxobox colour|{{{regnum|{{{virus_group|{{{unranked_phylum|{{{phylum}}}}}}}}}}}}}}}}}}}}

This will enable the Taxobox colour template to correctly determine the appropriate colour for Rhizaria and Amoebozoa taxoboxes.

Many thanks,

Verisimilus T 20:46, 18 November 2007 (UTC)

Y Done - looks good. Nihiltres^{t.l} 04:38, 21 November 2007 (UTC)

Taxoboxes for Livestock species and Categories

(originally posted at WT:TOL on 12 November 2007) Is there some way we can make this less circular: See, e.g. Goat, the article is about the domesticated species (Capra aegagrus hircus), the taxobox puts it in Category:Domesticated animals, however, the article is in Category:Goats which is a subcat of Category:Livestock, which is in Category:Domesticated animals, which is unnecessarily duplicative. Also see, e.g. Chicken which is listed as domesticated and therefore in Category:Domesticated animals but Category:Chicken is in Category:Poultry is in both Category:Domesticated birds and Category:Livestock both of which are in Category:Domesticated animals. This is a problem with any species that is categorized as livestock or poultry. Is there any way to make the taxoboxes more flexible with respect to categorization?--Doug.^{(talk • contribs)} 00:54, 20 November 2007 (UTC)

I think this is a problem with the current category structure. The categories the taxobox should use should be a species-level category. This is how it is for the various endangerment level categories, such as Category:Critically endangered species. Perhaps Category:Domesticated species should be created and used by the taxobox? - UtherSRG (talk) 14:07, 7 December 2007 (UTC)

IUCN Red List status

Greetings. I run Polbot, the bot that created several thousand new species articles from IUCN data earlier this year. A representative from IUCN contacted me at User talk:Quadell#Conservation Status in Taxobox asking, in effect, if I could make a minor change to the Taxobox template. When status_system is used to indicate that the data comes from the IUCN, he asked if it could say "(IUCN Red List)" instead of "(IUCN)", since more people are familiar with the "Red List" name than are familiar with the IUCN acronym. Would there be any objections to me making this change to this template? All the best, – Quadell ^{(talk) (random)} 13:41, 7 December 2007 (UTC)

I'm good with this. And the link can be IUCN Red List. - UtherSRG (talk) 13:54, 7 December 2007 (UTC)

I went ahead and did the change. I can quickly revert if anyone objects. - UtherSRG (talk) 13:57, 7 December 2007 (UTC)

Hrm. It does make that line a bit long when the status itself is long, such as "Critically endangered". I think that's why we chose to use "IUCN" instead of "IUCN Red List". Perhaps just use "Red List" and keep it as a link to IUCN Red List? Or perhaps change the longer status to something shorter like "Crit. endangered"? - UtherSRG (talk) 14:03, 7 December 2007 (UTC)

Hi. IUCN staff here who requested the change. If using "IUCN Red List" for the reference makes too long of a line with the longer categories like Critically Endangered, then I would vote for keeping it like you already have it (IUCN), although I tested it on one CR species and the line was long but did not wrap to two lines nor did it appear to widen the taxobox at all - I thought it looked fine. We'd rather not see the category be abbreviated and using "Red List" alone is also not desirable. However, another small issue is that the categories are used on the IUCN Red List website with all words being capitalized, like "Critically Endangered", "Least Concern", etc Ichobar (talk) 14:31, 7 December 2007 (UTC)

Our capitalization issues are our own. :D That aside, I now think keeping it as "(IUCN)" will be better. The longer display would be longer than the status image (the bit with the circles representing the various statuses), and when the reference superscript link is also present, that make it even longer. I've reverted the change. - UtherSRG (talk) 14:41, 7 December 2007 (UTC)

I'm guilty of originally writing it "(IUCN)". My suggestion would be to change the heading from "Conservation status" to "IUCN Red List category" when it's appropriate. Then the (IUCN) bit can be left nice and short. —Pengo 10:45, 8 December 2007 (UTC)

I agree with that solution. "Conservation status" could include other things than the IUCN category, but it doesn't, so why not be precise?--Curtis Clark (talk) 15:25, 8 December 2007 (UTC)

Tasmanian Devil uses (or used) something other than the IUCN's status, and some of the statuses (like domesticated) are not IUCN. - UtherSRG (talk) 02:36, 9 December 2007 (UTC)

Yep, there's a list of different status systems we use at Wikipedia:Conservation status. However, we can tell when it's IUCN from "status_system = iucn3.1" (or = iucn2.3). I'll be getting Beastie Bot up and running again sometime and this time I'll add it to all the taxoboxes it fits (I didn't add it to everything last time because it wasn't being used). Then we can have it consistent and stuff, and make the title "IUCN Red List category" when only when it fits, and "Conservation status" other times. Hoorah. —Pengo 12:09, 20 December 2007 (UTC)

virus_group unknown

Hello Template Editors. I've been converting some taxoboxes to the new format, however, in some cases there is no virus group information in the old template. If I leave virus_group blank (no parameter) then the template code does not make the taxobox violet in color. Can we fix the switch statement in the code so that a blank virus_group entry still applies the color? Thanks. —Noah 04:37, 16 December 2007 (UTC)

Actually, the workaround is to just add "color = violet". I suppose I will just document that on the Template Taxobox page in the virus_group section. —Noah 01:24, 20 December 2007 (UTC)

Better to enter regnum = Virus, in case the colours change in the future. Thanks, Verisimilus T 11:07, 20 December 2007 (UTC)

That doesn't seem to work. If you put in regnum = Virus and leave out color = Violet then the taxobox does not get any color. —Noah 18:46, 22 December 2007 (UTC)

Ah. Try wikilinking "Virus". Sorry! Verisimilus T 22:38, 22 December 2007 (UTC)

TfD nomination of Template:Taxobox begin

Template:Taxobox begin has been nominated for deletion. You are invited to comment on the discussion at the template's entry on the Templates for Deletion page. Thank you. — —Noah 05:23, 19 December 2007 (UTC)

Need additional status

An additional status is needed:

|status=CRDOM

Results: Template:Taxobox/Status sandbox

There are creatures that are critical in the wild but so common in captivity that they are bred by the millions annually for laboratories and the pet trade.

— SMcCandlish [talk] [cont] ‹(-¿-)› 08:55, 24 December 2007 (UTC)

Is there an organization that lists species as such? And which species do you propose are "CRDOM"? - UtherSRG (talk) 14:09, 24 December 2007 (UTC)

I don't think there is an official list, but in many cases the IUCN redlist and pet trade figures should provide sufficient sourceing. I know that several Cobitidae would probably match the bill... Ameca splendens possibly too (I remember breeding them some years ago, and they were available readily enough. Not like guppies, but you could get them if you wanted to). Most of the taxa are fish, some arthropods perhaps too. Dysmorodrepanis (talk) 01:57, 4 January 2008 (UTC)

Order of sections--move conservation status lower

Although conservations status is important, it is not very useful to most readers. Consider the average third grader who wants the quick stats for his homework. The physical specifics of a species occur after the rather esoteric conservations status. My two cents... Msa11usec (talk) 01:35, 9 October 2008 (UTC)

Change in sections?

{{editprotected}} I tried a taxobox with diversity, type species and subdivision_ranks params, and it looks kinda crappy. The type species section would be placed more "logically" immediately after the last taxon in the main sequence, as they give taxonomic info. And if you have a subdivision_ranks as well as a diversity section - which is appropriate for most orders or higher - they ought to be grouped together as they say something about lower-level systematics. Dysmorodrepanis (talk) 02:02, 4 January 2008 (UTC)

N Declined. The template must be accompanied by a specific description of the request. Please post the exact code you would like to have changed. Sandstein (talk) 20:03, 6 January 2008 (UTC)

{{editprotected}} Switch positions of "diversity" and the entire block of "type_[rank]" sections. Result should be the "type_" section showing above "binomial" and the "diversity" sdection showing over range map. Perhaps move "diversity" below range maps, might look better. Dysmorodrepanis (talk) 00:42, 28 January 2008 (UTC)

(If I could tell where each part of code starts and ends, I would post that... but if I could tell, I'd have by now cared to get the rights to change it myself ;-) ) Dysmorodrepanis (talk) 18:49, 28 January 2008 (UTC)

Defer to user preferences for image size

I propose to change

{{{image_width|200px}}}

to

{{{image_width|frameless}}}

The effect of this change will be to defer to user preferences on thumb size, whenever the "image_width" parameter is not set.

There are two reasons to do this:

1. It is proper to respect image size preferences where possible; over-ruling them should be avoided unless absolutely necessary;
2. It is a personal annoyance of mine that many articles honour thumb size preferences throughout, but the taxobox doesn't, so that the taxobox image ends up a different size to all the other images, which looks silly.

You can see an example of the proposed change at Alyogyne huegelii, where has been manually fed an "image_width=frameless" parameter.

Hesperian 23:56, 4 January 2008 (UTC)

And so.... Looks like the taxobox and the image don't fit together now because of the extra whitespace to the sides of the image. A taxobox and its image should be sized together. - UtherSRG (talk) 00:56, 5 January 2008 (UTC)

Are you saying that the standard practice is to size the image to match the width of the text in the taxobox? I don't see any need for this; I think Alyogyne huegelii looks fine right now. And I don't also think this is actually happening in practice - I see no evidence of this in any of the featured articles on plants. Also, the text width depends upon the font size you view your webpages at, so just because it looks right on your screen doesn't mean it will look right on mine. And finally, I don't see how changing how we handle the absence of an "image_width" parameter has any bearing on this situation anyway. Hesperian 03:08, 5 January 2008 (UTC)

It does appear to be a sane default. Currently image sizes are fairly arbitrary, so using thumbnail size would make sense. I don't see the problem with the whitespace... It looks the same to me. —Pengo 05:56, 5 January 2008 (UTC)

This discussion appears to have generated little interest. But I see more support than opposition, so I have made the change. Hesperian 03:30, 6 January 2008 (UTC)

Great - seems a sensible move. Sorry I didn't see the discussion earlier! Verisimilus T 11:27, 6 January 2008 (UTC)

The taxobox is 200px wide by default. Now, for the vast majority of users, the taxobox image is 180px wide, creating 20px of undesirable white space. I think these changes need more consideration. Mgiganteus1 (talk) 13:26, 6 January 2008 (UTC)

In order to see what you mean, I changed my thumb size default to 180px, then 150px, and then to 120px. Frankly, I don't see anything wrong with the whitespace, even at 120px. It looks just fine to me. Clearly some of you find it unattractive, but the question is, is it so bad as to warrant over-ruling user preferences? Many people have small thumb preferences for good reason, such as bandwidth issues, and presumably the logged-out default is set to 180px for similar reasons. It is impolite to overrule user preferences, on such a widely used template, for such an insignificant reason. Hesperian 04:25, 7 January 2008 (UTC)

Go look at an animal species taxobox, which has a conservation status image, forcing the taxobox to be larger than the species' image. - UtherSRG (talk) 15:49, 7 January 2008 (UTC)

Ah, thanks, I had overlooked the status and range map image widths, which suffer from the same problem. That's fixed now. I realise this isn't what you were looking for here, but it resolves the immediate issue. Hesperian 04:09, 8 January 2008 (UTC)

If the white space is a problem, why not reduce the default width of taxoboxes to 180px? Wider pictures will stretch it. Verisimilus T 15:50, 7 January 2008 (UTC)

I think that makes it look crappy on larger pages. Taxoboxes, even and sometimes especially long ones, tend to bring visual structure to a page. People with very low screen resolutions will suffer though. On the other hand, for example the fish people have very many images that are quite wide but not at all high. Forcing them to 180px by default renders the image as an in-article resource kinda pointless, as one cannot make ot sufficient detail. Note that the focus/main picture of an article is exempt from the "no image widths please" rule. So much of the perception that there is some guideline requiring a change of SOP is erroneous.

From my personal experience, a width of 200 px and perhaps a bit more is the point from which most images start to become useful for naturalists, biologists etc.

In any case, 180px is less wide than most Commons, Wikispecies etc boxes. Thus so low a value is completely pointless. Dysmorodrepanis (talk) 00:32, 28 January 2008 (UTC)

Remember that any default value can be easily overruled in specific instances, e.g. with fish. I agree that there is a trade-off to be made between inclusivity (i.e. making Wikipedia useable by people with lo-res screens) and utility (i.e. actually being able to make things out). I suspect that this balance has been thrashed out somewhere else, with the result that thumbnail size defaults to 180px; therefore it seems that there ought to be a strong reason for changing to something else. Perhaps photographs of organisms do need to be larger than photographs of anything else; perhaps extra width on the taxobox makes the article's structure look more pleasing to some (high-resolution) users. Are these concepts strong enough to merit enforcement, or does it boil down to personal preference? Verisimilus T 10:45, 28 January 2008 (UTC)

Hmmmm... I don't really care what to the fall-back size is set to as long as it's not too large. I say "fall-back" rather than "default" because I envision it to apply only if no size attribute is given. In most taxoboxes it is given, adapted to the page's needs... so it's not really like anything would get broken. See for example the very large image at Passerine, which nonetheless is, well, excellent. Both aesthetically and from a scientific standpoint, because it illustrates well what systematically speaking is one of the most passerinish passerines out there - a member of the Passeroidea, the last major group of birds to evolve - in all its glory. I neither would nor could change anything about this image to make it any better, even despite it being of a size I would not use myself. It just... fits. Dysmorodrepanis (talk) 18:48, 28 January 2008 (UTC)

This change has been used to revert the image width in Cat by Hesperian and UtherSRG. There is no problem with "defer[ring] to user preferences on thumb size, whenever the 'image_width' parameter is not set", but that's quite different from claiming "thumbnail is best" on the lead image. As pointed out above, lead image is exempt from the "thumbnail rule" and Wikipedia:MOS#Images actually recommends the lead be not smaller than 300 px(although the rational is suspect) and even Wikipedia:Taxobox_usage#Images suggest a fixed width of more than 200 px. --Dodo bird (talk) 11:14, 25 April 2008 (UTC)

Your MOS comment is a misquote. That section does not recommend overruling the default thumb size. What it says is that if the default size is to be overruled, then it should be more than 300px, so that it isn't smaller than all the other images for users with 300px default thumb size. I think it is pretty clear that not overruling the default size is consistent with the MOS, whereas overruling with a size less than 300px is not. As someone with a default thumb size of 300px, I can confirm that overruling the lead image to be smaller than all the other images, makes an article look thoroughly stupid.

The taxobox usage page is terribly out of date - it hasn't been updated since this change went through at the start of this year. I'll get onto that.

Having said all that, I don't personally wish to remove any image sizes that have actually been thought about. I'm removing sizings because in the vast majority of cases no thought whatsoever has gone into them, and in those cases it is far better to return to the default. If you have thought deeply about the implications of over-ruling the thumb, and still think it should be done, then you won't hear any objections from me.

Hesperian 11:26, 25 April 2008 (UTC)